Craig,
Very neat!
Are you still working on the jersey-multipart project? If so, have you
considered any type of utility classes for working with multipart
attachments? Aside from the Java Mail API library, is there any library you
recommend for determining MIME types from input streams?
Thanks again Craig,
Andrew
On 2/5/09 1:23 PM, "Craig McClanahan" <Craig.McClanahan_at_Sun.COM> wrote:
> Andrew Feller wrote:
>>
>> 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?
>>
> In some cases I've used session EJBs (that is, the REST web service is an EJB
> client) or interacted with some of our existing SOAP-based web services, but
> that's about it. With your code factored as I recommend below, the actual
> resource classes tend to be really simple -- so simple you don't need a lot of
> extra frameworks or overhead :-).
>
> By the way, I'm in the midst of updating the contacts sample app to use the
> cool new security context stuff that Paul committed to jersey-server last
> night. With that, you'll be able to use annotations to declare what roles are
> required to execute each resource method, and Jersey will return a 403 for you
> if the requesting user doesn't have the needed role. Really sweet, and should
> be done by tomorrow or so.
>
> Craig
>>
>>
>> Thanks once again!
>> Andrew
>>
>> On 2/5/09 11:29 AM, "Craig McClanahan" <Craig.McClanahan_at_Sun.COM>
>> <mailto: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