> On 08/08/2011 08:36 PM, Markus KARG wrote:
> >>> * Will AsyncContext be injectable into a message driven bean (MDB)?
> >> This is needed for integrating EJB with JAX-RS in the most simple
> way.
> >> If the MDB gets triggered (e. g. by JMS or by a ERP JCA connector)
> it
> >> must be able to propagate this event to the AsyncContext. Or do you
> >> plan to extend support for MDBs in a way that MDBs can be JAX-RS
> >> resources, just like SLSBs?
> >>
> >> No. But MDB should be able to directly call EJBs or send HTTP
> requests
> >> to arbitrary JAX-RS resources, which seems enough.
> >
> > We're having a rather long history using EJB, especially MDBs, so I
> need to say that we are heavily interested in interoperability of any
> kind of new event APIs with MDB (here: JAX-RS events). That means in
> particular, that we would vote for some kind of merge between JAX-RS
> resource and MDB. An MDB should be able to get triggered by @POST for
> example (which technically is rather simple, as the message passing
> interface of an MDB is not defined, so defining any arbitrary message
> passing method with @POST will do it), and any kind of EJB
> (particularly MDBs triggered by JMS) should be able to trigger a a JAX-
> RS event to resume those request that is waiting on it. I actually do
> not insist of events support in JAX-RS as you know, but my strong
> belief is that IF we're gonna do it, we should do it RIGHT. Which
> means, as JAX-RS is part of Java EE, it should be more integrated with
> EJB. It looks odd that an EJB must use HTTP to resume a suspended
> request, as for example embedded se
> rvers will potentially run both in the same VM. There is a merger
> between JSF managed beans and SBs already, so why not a merger between
> JAX-RS resources and MDBs?
> >
> FWIW, I'd like to point out that support for EJBs as JAX-RS resources
> is actually rather painful to implement and
> certainly not "technically rather simple". EJBs are managed by a
> different container and often have a lifecycle that
> collides with the default JAX-RS resource lifecycle. This alone causes
> lots of issues around EJB instance management,
> provisioning and injection which are very hard to solve in a way that
> works for all the corner cases. Personally, I
> think it was a mistake from the very beginning to allow exposing EJBs
> as JAX-RS resources directly. Unlike JAX-RS
> resources, EJBs are primarily meant to be back-end objects IMHO. One
> should be able to inject other JavaEE artifacts
> including EJBs into JAX-RS resources, but as for this mixed mode, it
> seems that was not really thought through well.
>
> Marek
I understand your concerns and arguments, but as I am viewing it from the user's side (and there are more users than providers in the end) I have to object in part:
It is hard to make people clear that JSF managed beans and SBs are merged, JAX-RS and SBs are merged, but JAX-RS and MDBs will not be merged. Don't get me wrong, but users just don't care about the fact that JAX-RS vendors have technical problems to add this last step. Also, as JAX-RS and SBs are already merged, and as MDBs are rather similar to SLSBs, I still think that it is not so much to do as you just need to add the missing brick, not the complete EJB stuff as you already did that. If we always abstain from doing something just because it is complex and lots of work, then we are not providing something for the users but solely for the vendors. And I actually hope that the target of an API are primarily users.
Also I have to say that I really like the idea of merging JAX-RS and EJB, because there are lots of small applications that do not care for layers. They just consist of a monolithic server build from few EJBs calling JPA. That EJBs directly implement SOAP using a single annotation. Adding REST with few annotations just feels natural for small apps. I am a long term MDB user and I hoped for so many years that one day there will be a JMS replacement using http. And now this could happen. It would be great for programmers. Please, for a few minutes, do not think in terms of what it costs Oracle or what complexity it will provide to you as a Jersey implementor, but just sit back and look at it as a programmer that wants to add http based messaging ontop of his single-ejb-application. You actually force this programmer to double his code just because you personally fear the amount of work and complexity. His life could be as easy as writing some annotations, if you just are willing to make it happen.
Regards
Markus