Craig,
Wow! Thanks for the response as that was definitely in line with what I was
looking for! =)
Aside from JPA and IoC frameworks/libraries, are there any other frameworks
that you have incorporated within your JAX-RS / Jersey resources for boiler
plate activities?
Thanks once again!
Andrew
On 2/5/09 11:29 AM, "Craig McClanahan" <Craig.McClanahan_at_Sun.COM> wrote:
> Andrew Feller wrote:
>> Thank you Farrukh for your response!
>>
>> I am familiar with Maven and can relate to some of your own earlier
>> experiences with it, however my employer doesn't have any plans to switching
>> to Maven at this time.
>>
>> Could you elaborate on how Maven helps you structure your Jersey REST
>> services? In particular, what kind of package layout do you use?
>>
>> In the past when we developed Struts 1/2 based applications, we would
>> typically organize classes based upon functionality: POJOs, Actions, DAOs,
>> etc. With the Jersey REST services we are trying to architect, the knee
>> jerk thoughts we have come up with off the bat are: Resources (classes where
>> REST requests are made to) and POJOs.
>>
>> I suppose another way to look at this question is: When developing a
>> typical, complete Jersey REST service, what are all of the different
>> elements that are required and what options for project layouts are
>> available?
>>
>>
> I can throw in some general thoughts about organizing things, based on
> my experience with JAX-RS and Jersey so far. Let's start by identifying
> the moving parts (with some comments thrown in about separation of
> concerns):
>
> * Data model classes -- typically tied to some persistence framework
> like JPA or Hibernate. Should *not* be tied to web APIs.
>
> * Business logic -- implementation of the actual behavior of your service.
> Might be Spring-activated beans, might be EJB session beans,
> might be POJOs ... whatever your favorite paradigm is for this kind of
> thing.
> But should *not* be tied to web APIs (for ease of testing). Will depend
> on the data model classes.
>
> * Resource classes -- JAX-RS specific resource classes that basically
> map incoming requests to calls on your business logic methods, and
> then maps the return values from the business logic into responses.
> In a small application you'll sometimes see the actual business logic
> embedded here, but I prefer to separate it if there's any complexity
> at all.
> My preference is that the resource class always accept and return
> entities that are your data model classes (rather than producing raw
> JSON or XML) and then rely on the JAX-RS providers mechanism to
> separate out the actual parsing and formatting logic. These classes will
> directly depend on your data model and business logic classes.
>
> * Providers -- If you are not using JAXB-based data model classes, or if
> you have specialized needs, you should provide suitable
> MessageBodyReader and MessageBodyWriter classes to do the
> parsing and formatting. For JAXB-based data model classes, you get
> the providers you need for free, courtesy of the JAX-RS infrastructure.
>
> If you think about it a bit, you'll see that any particular web service
> call will probably require stuff from all of these categories.
> Therefore, two different Java package architectures could easily make sense:
>
> * Separate package for each of the above categories (data models,
> business logic, resource classes, providers).
>
> * Separate package for each functional portion of your web service,
> combining related data model, business logic, resource, and providers.
>
> Which approach to take is somewhat an aesthetic choice, and also
> somewhat influenced by whether you want to leverage "package protected"
> access between your various classes. But I generally tend towards the
> first approach in my apps.
>
> One further consideration -- are the all or some of the clients for your
> web service going to be using Java? If so, a nice value add would be to
> add a "client SDK" type module, which encapsulates the web service
> calls. If you use Jersey Client for this, you can leverage the same
> data model classes and providers that are used on the server side (so,
> you would probably want to put those classes into different Eclipse
> projects so that both the client and the server can depend on them).
>
> You can see my notion of organization fleshed out in a sample
> application that was recently added to the Jersey trunk. See the
> contents (and README.txt file) of:
>
> * samples/atompub-contacts-models -- data model classes shared by client
> and server.
>
> * samples/atompub-contacts-server -- REST web service somewhat like the
> Google Contacts API, but with no real database behind it.
>
> * samples/atompub-contacts-client -- client SDK that can call the
> various web service methods.
>
> Hope this helps.
>
> Craig
>
>> Regards,
>> Andrew
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
--
Andrew Feller, Analyst
LSU University Information Services
200 Frey Computing Services Center
Baton Rouge, LA 70803
Office: 225.578.3737
Fax: 225.578.6400