users@jersey.java.net

Re: [Jersey] Exposing EJB 3 Beans through JAX-RS

From: Reza Rahman <reza_rahman_at_lycos.com>
Date: Mon, 08 Sep 2008 16:46:46 -0400

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.

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) :-)

Cheers,
Reza


Marc Hadley wrote:
> On Sep 8, 2008, at 3:21 PM, Reza Rahman wrote:
>>
>> I would definitely like to see a bit more flexibility than having to
>> use WebBeans/believe there is a need for EJB 3.1/JAX-RS integration.
>> How can I provide further input into the decision making process for
>> this short of trying to join the JSR 311 EG? I can most certainly try
>> to gauge/build support for this by blogging/talking about my own
>> viewpoints if that is what could help.
>>
> IIUC, the goal of WebBeans is to unify the component model for the EJB
> and Web containers. I can understand the desire for a point-wise
> integration but it seems to me that supporting a unified model would
> be more beneficial overall. E.g. a bean could then be used as a JAX-RS
> resource class, a JSF managed bean and as an EJB session bean. I
> haven't been following WebBeans closely so far but from what I've seen
> there's very little work required to make an EJB session bean a WebBean.
>
> Marc.
>
>>
>> Marc Hadley wrote:
>>> On Sep 8, 2008, at 1:46 PM, Reza Rahman wrote:
>>>>
>>>> I'll be honest, I'd hate to see a potentially good technology like
>>>> JAX-RS be out of the reach of developers that would rather use a
>>>> plain EJB stack for reasons that are relatively easily solvable. I
>>>> definitely do hope for much better coordination between specs in
>>>> Java EE than that, particularly in the GlassFish project!
>>>>
>>> Sorting out integration with EE 6 is on the docket for JAX-RS 1.1, a
>>> maintenance release we are planning to align with the EE 6 schedule.
>>> Exactly what this will look like is still up for debate but the
>>> current thinking is outlined in section 6.2 of the spec
>>> (https://jsr311.dev.java.net/drafts/spec20080827.pdf).
>>>
>>> Personally I'd like to be able to say that a resource class can be a
>>> WebBean and leave it at that - I think that would give you what you
>>> are looking for. However, it remains to be seen if that will be
>>> feasible or not.
>>>
>>> Marc.
>>>
>>> ---
>>> Marc Hadley <marc.hadley at sun.com>
>>> CTO Office, Sun Microsystems.
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
>