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 11:52:49 -0400

Paul,

This appears to jive with what my thoughts were as to the implementation
side of things. To summarize, the real issue appears to be that the
integration is easier to do at the EJB 3 container level (just as it is
done for JAX-WS/the JBoss RESTEasy implementation) and cannot easily be
done via Jersey alone. On the other hand, it is a lot easier to
implement Spring integration? Is this a true statement? Is the same true
of WebBeans because it is giving you a direct reference to the
underlying bean implementation object instance?

Personally, I think it is a lot easier to use JAX-WS 2.0 with EJB 3 than
it is with Spring (less configuration, just works out of the box with an
annotation or two from a developer standpoint). I would hope that is
true of JAX-RS+EJB 3 built-in support at the Java EE container level?
FYI, I am simultaneously having the same discussion with the EJB
3.1/GlassFish lead Ken Saks, I'm hoping that'll make this a little
easier to do from the Jersey perspective, provided there is a sincere
willingness to do it from both ends.

If you were to get implementation support from the EJB 3 container
level, would this make things easier? Perhaps a callback before the
actual underlying bean instance is registered with the container? FYI, I
am thinking/hoping such a feature for all managed components will be
created at the Java EE 6 EG level, making all third-party
pluggability/extensibility a lot easier.

Could you clarify the following so I can have a more intelligent
discussion with the EJB 3.1 EG/spec lead?:

* The default life-cycle for resource classes in JAX-RS is per-request.
- So stateless session beans would indeed be a very good fit for this
model? And stateful session beans would be a good for the session based
life-cycle?

* Further more when using JAX-RS the interface of most importance is the
HTTP interface, thus anything that requires one to split interface from
implementation may be a distraction.
- From another perspective, a session bean JAX-RS annotated
interface/view would actually be a very natural fit/good OO practice,
just as it is for JAX-WS? Also, did you know interfaces have been made
optional for EJB 3.1 beans, so you don't have to have them if you don't
want to? So is it the case that you are currently not supporting JAX-RS
annotations on Spring interfaces rather than bean classes?

* if i obtain the remote EJB reference using JNDI the fields are
obviously not there for Jersey to operate on as it only has the
interface. Same for constructors.
- Not sure I fully understand. So Jersey needs to manipulate private
fields that are not exposed via the session bean contract? Is it that
you are using reflection to set private fields on the object reference
that you get from Spring? Is that why obtaining object references via
constructor vs. JNDI is an issue? In case of Spring, you would still not
be doing direct constructor initialization yourself, right? You would
still be letting the Spring application context do the bean
initialization for you?

Thank in advance,
Reza

Paul Sandoz wrote:
>
> On Sep 8, 2008, at 4:21 PM, Reza Rahman wrote:
>
>> Paul,
>>
>> I think I am missing something? Why just singleton session beans? Is
>> there are a hard requirement for JAX-RS resources to be stateful? Why
>> not stateless session beans too? At any rate, how does this really
>> differ from Spring/WebBeans component life-cycles? Spring singletons
>> are designed for stateless usage (state is shared across clients), as
>> is WebBeans request scoped beans?
>>
>
> The default life-cycle for resource classes in JAX-RS is per-request.
> Jersey's Spring integration supports per-request and singleton for
> Spring beans. Jersey also supports per-HTTP-session, which IIRC we
> also support with Spring. For those life-cycles it is possible to
> utilize a constructor (although for Spring the constructor is limited
> to Spring-based annotated parameters).
>
>
>> I am also not sure what you mean by field injection? EJB 3 supports
>> both method and field injection?
>
> The issue is that it is hard for me to integrate that support with EJB
> implementations. For example, if i obtain the remote EJB reference
> using JNDI the fields are obviously not there for Jersey to operate on
> as it only has the interface. Same for constructors. JAX-RS does have
> support for bean setters so it is not all that bad.
>
> With JAX-RS classes using Spring it is just a POJO there is no split
> between the implementation and the remote/home interfaces, but yet
> developers can utilize AOP, transacted methods etc. Jersey can easily
> obtain an instance of a Spring bean and still perform it's own
> injection on the instances (even for AOP wrapped instances). The
> Spring POJO approach fits very nicely with the Jersey POJO approach
> both of which IMHO improve the developer ease of use experience.
> Further more when using JAX-RS the interface of most importance is the
> HTTP interface, thus anything that requires one to split interface
> from implementation may be a distraction. In addition i can do
> everything in the Web tier, there is no need for an ear file.
>
>
>> Could you help me understand in what other ways you think session
>> beans are less flexible than WebBeans/Spring?
>
> Did the above help?
>
>
>> I am on the EJB 3.1 EG, so can certainly try to help in this regard
>> and would really like to understand the underlying issues. Is it
>> difficulty in looking up things from JNDI? If that's the case, EJB
>> session bean JNDI names are being standardized so names are portable
>> across application servers?
>
> The use of JNDI proved to be really easy :-) i dunno if i am standard
> names or not, more details in my next email after i commit the code
> (probably in about 10 mins).
>
> Paul.
>
>
>> Thanks in advance,
>> Reza
>>
>>
>> Paul Sandoz wrote:
>>> Hi Reza,
>>>
>>> WebBeans, or say Spring, would give me a way to get full EJB-related
>>> functionality without requiring that a resource class be a session
>>> bean i.e. it is much more flexible e.g. the life-cycle is not
>>> restricted to singletons, it is possible to inject on to fields. I
>>> have not looked into EJB Lite yet, so maybe that will improve
>>> things. I hope all this can be worked out in the 311 EG when to
>>> tackles EE6 integration.
>>>
>>> W.r.t. session beans being resource classes, i have a working
>>> solution. Once the code is committed back i will explain how things
>>> work.
>>>
>>> Paul.
>>>
>>> On Sep 8, 2008, at 3:29 PM, Reza Rahman wrote:
>>>
>>>> Paul,
>>>>
>>>> Good to hear that there is some plans to this end. A few other Java
>>>> EE vendors also responded that they intend to integrate EJB 3 and
>>>> JAX-RS in EJB 3/JAX-WS fashion.
>>>>
>>>> To me it makes the most sense in the scenario of exposing the
>>>> back-end service layer directly instead of getting yet another
>>>> layer involved (I'm not sure WebBeans would be use for service tier
>>>> implementations). As you mentioned, it wouldn't be too bad in terms
>>>> of utilizing the existing EJB services too - like transaction
>>>> management, security, asynchronous processing (added in EJB 3.1)
>>>> and scheduling (via the older timeouts facility, not the newer
>>>> cron-like declarative scheduling). Not all these services are
>>>> available directly via WebBeans.
>>>>
>>>> I think for most EJB 3 users, the CORBA interoperability part is
>>>> just a historical curiosity, although I am sure a lot of effort is
>>>> spent on this on the vendor end. Luckily, EJB Lite makes CORBA
>>>> interoperability optional for vendors (another EJB 3.1 feature).
>>>> However, I do see your point about the potential paradigm mismatch
>>>> between RPC and REST style code, I just wonder of that's really
>>>> enough of a reason not to do it.
>>>>
>>>> Cheers,
>>>> Reza
>>>>
>>>>
>>>> Paul Sandoz wrote:
>>>>> Hi Reza,
>>>>>
>>>>> It would indeed seem odd if JAX-RS would not have such
>>>>> functionality. The plan is to produce a maintenance release of
>>>>> JAX-RS that aligns with EE 6.
>>>>>
>>>>> With respect to Jersey you can obtain EE functionality for JAX-RS
>>>>> resource classes by using Spring [1]. In fact for EE 6 integration
>>>>> the current plan is to use WebBeans.
>>>>>
>>>>> IMHO the use of EJBs defined to be JAX-RS resources may be
>>>>> somewhat limited because (session) EJBs are designed for RCP-style
>>>>> interactions (CORBA, WS-*) thus resource methods may not make any
>>>>> sense in terms of equivalent calls using CORBA. What is more
>>>>> interesting is reusing some of the capabilities of EJBs. Having
>>>>> said that i think something should be possible, there may be two
>>>>> ways:
>>>>>
>>>>> 1) You can extend the Jersey servlet to register singleton
>>>>> instances of annotated EJBs obtain using JNDI lookup.
>>>>>
>>>>> 2) The Jersey servlet when in an EE environment could perform look
>>>>> up of registered classes using JNDI with
>>>>> class names as the JNDI names, and if instances exist register
>>>>> those as singleton instances.
>>>>>
>>>>> Paul.
>>>>>
>>>>> On Sep 7, 2008, at 7:07 PM, Reza Rahman wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am wondering if there are any concrete plans on supporting
>>>>>> JAX-RS annotations on EJB 3 Beans, perhaps as part of project
>>>>>> GlassFish? I am looking for something in the flavor that the
>>>>>> JBoss implementing RESTEasy, supports in terms of EJB 3/JAX-RS
>>>>>> integration? Since such integration already exists between JAX-WS
>>>>>> and EJB 3, it seems odd that JAX-RS should not have the same?
>>>>>>
>>>>>> Thanks in advance,
>>>>>> Reza
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>