On Sep 8, 2008, at 10:46 PM, Reza Rahman wrote:
> Marc,
>
> I agree that in a WebBeans based system, it is not that big of a
> deal what the exposure point is. The problem is threefold, however:
>
> 1. Not every EJB 3.x based system is going to also be a WebBeans
> system (definitely true in the sort term). This becomes even more
> unlikely if the system is not a JSF based system but say, a Struts
> 1/2 based system (this is what some of my own EJB 3 clients are, for
> whatever the reason). As a results, it could be cumbersome for a
> large subset of potential Java EE adopters to have to use WebBeans
> in order to get excellent facilities for directly exposing their
> service tier via JAX-RS.
>
> 2. If for no other better reason, EJB has a long history of exposing
> service tier code via various remoting protocols like CORBA, RMI and
> SOAP (via JAX-WS 2.0). This is why the most natural fit for JAX-RS
> is also EJB (probably as yet another interface based view to
> separate logic from transport protocol). That is what I believe most
> of the core adopters of Java EE would expect, unless there is really
> a good technical reason not to do it.
>
I strongly disagree that the most natural fit for JAX-RS is also EJB
because of the existing remoting protocols
RPC-based protocols like RMI, IIOP and WS-* fit naturally since the
local programming model is easily extended to a distributed
programming model. That has some advantages but also great
disadvantages when building applications for the Web. Steve Vinoski's
articles a good source at explaining why this is so.
Using HTTP as an application protocol and applying the RESTful style
is very different. I think Dan Diephouse expressed things very
concisely [1]:
Please keep in mind that REST and SOAP programming models don’t
mix well. There is this complete fallacy
going around (I succumbed to it too at one point) that you can
use the same service class or description to
build a RESTful and a SOAP based service. However, the
interactions and mappings should end up being
completely different from one to the other! One is message based
and one is resource based. You’re going to
have to design your service differently as they’re two completely
different beasts.
For me the key thing about EJBs is that they offer non-protocol-based
functionality like role-based security or transacted methods.
> 3. For better or for worse, EJB 3.x and Spring are still seen as
> direct competitors. Whatever the underlying dynamics, WebBeans,
> Guice or Seam are not seen to be in the same fundamental middleware
> component development market. This means that being able to expose
> JAX-RS services via Spring and not EJB, can be a serious competitive
> disadvantage for Java EE adoption because EJB is still seen as the
> "keys to the kingdom" so to say. It would be a shame if the source
> of such a disadvantage would be another Java EE specification
> (unless of source there is a profound technical reason to leave this
> gap)!
>
> Does this make sense? I'm trying to be as direct and plain as
> possible with a minimum amount of academic gymnastics and convoluted
> sophistry. I hope I'm being successful in coming across as such...
>
> FYI, I just spoke to Bill Burke about this since he has been so
> heavily involved with RESTeasy. He is definitely of the same opinion
> as I and is ready to help in any ways that you need in the EJB 3.1
> EG to get you anything that you might need. Albeit, I have not been
> able to get buy-in from Ken Saks quite yet, but thankfully he is
> someone who can be reasoned with (but he's no push-over either) :-)
>
Oh dear, is it as bad as that :-) I hope you don't think Marc or I
unreasonable.
Paul.
[1]
http://netzooid.com/blog/2008/02/05/right-tool-for-the-job/