users@jersey.java.net

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

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Mon, 08 Sep 2008 18:38:09 +0200

On Sep 8, 2008, at 5:52 PM, Reza Rahman wrote:

> 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?
>

I am presuming the functioning of Spring and WebBeans will be similar
in terms of POJO-based development. Essentially they expose out IoC
functionality that would is likely to be hidden inside more
traditional EJB EE 5 implementations.

 From the perspective of what JAX-RS offers i do think it is easier to
provide full JAX-RS support with the likes of Spring integration. It
was not obvious, and is perhaps not possible in some cases, to do that
for EJB in EE 5.

Plus as well what was driving this was demand, more people were
demanding spring integration than EJB integration :-)


> 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?

Take a look at the autowire Spring example in Jersey [1].


> 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.
>

OK. There is definitely a willingness to JAX-RS integration with EE
integration. This discussion is helping understand things a bit better.


> If you were to get implementation support from the EJB 3 container
> level, would this make things easier?

It most likely would. But what i would really like to see is IoC and
EJB POJOs in EE 6.


> 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.
>

I think it is important to take a very close look at what WebBeans may
have to offer.


> 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?

No, per-request means that an instance of the resource class is
created per-request. It means you can utilize constructors and fields
on the class and not have to deal with concurrency.

Stateless session beans are equivalent to singletons.


> And stateful session beans would be a good for the session based
> life-cycle?
>

Yes. Although from a REST perspective this is not recommended as it
breaks stateless constraint.


> * 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?

IMHO there is really no advantage to create an interface and then
implementing it just for the sake of it, that just obfuscates things
and adds more baggage when one can just as easily do it as a POJO
because as i said it is the HTTP interface and not the RPC interface
that is important. If one finds that many resource classes share
common stuff, then one can re-factor and share interfaces and abstract
implementations with many classes as desired without breaking the
contract of the HTTP interface. IMHO it allows for much more
implementation flexibility without breaking clients.


> 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?

You mean EJB POJOs?


> So is it the case that you are currently not supporting JAX-RS
> annotations on Spring interfaces rather than bean classes?
>

We support annotations on interfaces as specified by JAX-RS, this
should work on Spring-based interfaces that are implemented by Spring
beans. Or just normal POJOs that implement annotated interfaces.


> * 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?

Yes, if such fields are annotated.


> 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?
>

Yes, that is the only area we could not solve because there is nothing
in the Spring API to say construct this and here are the parameters i
know about, you work out the rest. BTW we presented this use-case to
the WebBeans guys.

It would be really great to support the intermixing of JAX-RS and
other annotated parameters in the constructor. It is possible when
Jersey invokes, we have added support to get access to Spring beans
from annotated constructor parameters.

BTW the Spring is implemented as a plug in layer, there is really not
a lot to it. It is possible to plug in WebBeans or Guice (some
developers have experimented with that). I am wondering if this is the
right later to also plug in EE 6 support.

Paul.

[1] http://download.java.net/maven/2/com/sun/jersey/samples/spring-annotations/0.11-ea-SNAPSHOT/spring-annotations-0.11-ea-SNAPSHOT-project.zip


> 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
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>