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 13:46:13 -0400

Paul,

* Essentially they expose out IoC functionality that would is likely to
be hidden inside more traditional EJB EE 5 implementations.
- I'm still not sure how this directly effects Jersey/the JAX-RS spec
though, other than perhaps the perceived market demand, which changes by
day and is something that better EJB 3.1/JAX-RS integration could drive
:-).

* It was not obvious, and is perhaps not possible in some cases, to do
that for EJB in EE 5.
- That's what I'm trying to get at...what cases in particular?

* It most likely would. But what i would really like to see is IoC and
EJB POJOs in EE 6.
- Would you care to expand on this? You can the ability to inject
non-managed components to EJBs? What do you mean by EJB POJOs? You need
a handle to the actual bean instance? Why so? Or are you just talking
about Session Beans without interfaces (already slated for EJB 3.1).

* Take a look at the autowire Spring example in Jersey [1].
- Nice, but still not as powerful as placing a few annotations on an
EJB 3 bean and have all the infrastructure concerns be handled behind
the scenes :-). Kindly take a look at the JBoss RESTEasy implementation
examples...

* Stateless session beans are equivalent to singletons.
- I am guessing you are referring to Spring's singleton implementation?
That's definitely true. Does a single request mandate multiple calls to
a single bean instance that maintains state? That's the only case where
stateless session beans would not suffice? Or are you referring to the
need to inject resources from the JAX-RS end before a request can be
serviced? Again, I'm trying to understand the underlying concerns here a
little better?

* Yes. Although from a REST perspective this is not recommended as it
breaks stateless constraint.
- So how do Spring session scope beans fit in? Don't they have the same
problem?

* Yes, if such fields are annotated.
- Could you kindly give me an example so I can chat about it in the EJB
3.1 EG?

For illumination, could you tell me what is specifically barring the
same kind of integration that JAX-WS 2.0 has with EJB 3? Again, it's
particularly puzzling to me in view of the JBoss RESTEasy implementation
that does support seamless integration with EJB 3? What are the
challenges with Jersey that they did not have?

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!

Cheers,
Reza


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