2008/11/19 Paul Sandoz <Paul.Sandoz_at_sun.com>:
>
> The REST style is independent of protocol but the architecture you apply the
> style does not have to be. JAX-RS makes no attempts to be protocol
> independent (but see later). Being protocol independent is an architectural
> decision you should make based on your requirements.
Yes, of course, it was indeed our requirements that lead us to opt for
a protocol-independent infrastructure based on messaging. We have to
support al least 3 kinds of protocols, HTTP/S, IMAP/PO3 and JMS.
> I recommend you support two different Jersey-based containers:
>
> 1) Using HTTP; and
>
> 2) Using SMTP and mapping the SMTP request/response to Jersey
> ContainerRequest and ContainerResponse
> that can then be passed to WebApplication.handle.
Since we opted to be protocol-independent I think our approach of
keeping two separate layers on the "client side", Connectors and
Resources, is justified. And thus being the Resource layer the
responsible to supply the connector(s) with the appropriate resource
instance for a particular path/verb/mimeType.
So I just made some changes to my Resource layer to correctly order
the methods (AbstractSubResourceMethod) following the spec, for what I
just used your UriTemplate.COMPARATOR.
BTW, I did upgraded to Jersey 1.0 without problems, and strangely the
question with the Matrix param didn't occur, I still receive all my
params as a Map. That's strange in light of what you said and what
the docs say. I'll have to take a closer look to that,
> A WebApplication instance created can be shared between the two. It is quite
> easy to support containers, for example look at MuleSource [1]. My guess is
> the mapping from an SMTP request to a ContainerRequest should be rather
> simple for what you require.
When we first start discussing our REST architecture we had a very
heated debate between using a ESB or not. My boss had the opinion of
using Mule and I had more or less followed the opinion of Steve
Vinoski in his much debated blog post "The ESB question".
We finally followed my (actually Steve's) opinion (and my boss is not
known for changing his opinion lightly) and that's why we are using a
"light" messaging infrastructure with "independent", "decoupled"
connector/resource architecture that allows us to create and connect
connectors as we go along.
I should mention also that we looked at Restlet as a alternative but
we decided for our "lighter" version.
> You can also look at the code for the ServletContainer and the
> GrizzlyContainer for other examples.
I think we are now stable enough to go ahead (even more considering
our time constraints) with our use of Jersey + Spring Integration.
I would like to know more about the integration of Jersey with the
Spring IoC because I'll really like to have access to those "injected
interfaces" like the UriInfo that will save me lot's of work. I hope I
can do it soon.
In the meantime, many thanks for your support, if I can contribute at
least with some ideas I would be very happy to do it.
Cheers.