Nigel,
I see no issue with this considering how prevalent JCA is.
John
On Fri, Jul 8, 2011 at 12:01 PM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> I'd like to start a disscussion about this JIRA issue:
> http://java.net/jira/browse/**JMS_SPEC-25<http://java.net/jira/browse/JMS_SPEC-25>
>
> This issue is about the best way to support the portability of JMS
> providers between Java EE application servers. At the moment there is no
> (mandatory) API that allows this to be done in a generic fashion which works
> with every such combination.
>
> As a result, if a JMS or Java EE vendor wants to integrate a given
> application server with a given JMS provider they need to provide custom
> code to do so.
>
> I see providing a standard interface between a JMS provider and a Java EE
> application server as helping two distinct groups of people:
>
> * Users of Java EE applications who need to be able to integrate their
> application with some separate system that uses a different JMS provider.
>
> * Java EE vendors who wish to support the use of their product with
> multiple JMS providers, and who don't want to have to create custom
> solutions for every JMS providers.
>
> Assuming we agree this is desirable feature of JMS 2.0, I think there are
> two clear alternative approaches to addressing this need: we could choose
> one, the other, or both (or a modified version of them):
>
>
> 1. Make JCA support mandatory
> -----------------------------
>
> This option would make the provision of a resource adapter conforming to an
> appropriate version of the Java EE Connector Architecture (JCA). This API
> was designed, subsequent to JMS 1.1, as a general interface to third-party
> "enterprise information systems". That's a rather vague term, but in
> practice, a reading of the JCA spec make it clear that it was designed with
> JMS providers in mind as well as other products. In particular, it is aimed
> at EISs that require:
>
> * connection pooling
> * integration with the XA transaction of the application server
> * authentication and suthorization
> * threads to do work with
> * asynchronous processing of inbound messages by MDBs
>
> So on the face of it, we already have an API which was designed for exactly
> this requirement. JCA is a well-established API which has been in use for
> many years. Several JMS vendors already offer JCA resource adapters to allow
> their product to work with any application server, so it is a natural next
> step to make provision of one mandatory.
>
> One comment I have heard is that a drawback of a JCA API is that it can
> only be used within a Java EE application server, and it would not be
> possible to build some other kind of container which offers features such as
> XA, connection pooling etc in a Java SE environment. I don't think this is
> true - I've worked on numerous resource adapter tests which instantiate and
> use a resource adapter with a home-grown connection pool, work manager etc.
>
> 2. Make JMS "Chapter 8" mandatory
> ------------------------------**---
>
> This option would make mandatory the optional Chapter 8 "JMS Application
> Server Facilities". This defines API for (just)
>
> * integration with the XA transaction of the application server
> * asynchronous processing of inbound messages by MDBs
>
> This wouldn't directly allow the JMS provider to plug into a foreign
> application server, since there is no requirement for an application server
> to support these interfaces either. It would therefore be necessary for
> either
>
> * application servers to be required support the JMS "Chapter 8" API
> directly
>
> * someone to write a JMS resource adapter which uses the "Chapter 8" API
> and JMS API to interface with the JMS provider. Since the "Chapter 8" API is
> narrower in scope than JCA this may limit the functionality available, but
> there may be benefit in creating a "market" for competing "Generic" JMS
> resource adapters, perhaps with additional functionality included.
>
> In considering this we should consider the fact that the "Chapter 8" API is
> much simpler than JCA. Does this mean that it is in practice inadequate for
> its purpose? Is there a risk that we will end up having to add API to JMS
> which is already defined in JCA?
>
> We may need to go through the deficiencies in detail, but here are two
> examples:
>
> The JCA interface ManagedConnection allows the application server to
> register a ConnectionEventListener, which is called whenever the application
> calls connection.close(), and which the application server can use to decide
> whether or not to put the ManagedConnection instance back in the connection
> pool. The "Chapter 8" API has no equivalent way of notifying the application
> server (or the JMS resource adapter) that such a change has taken place.
>
> The JCA interface ManagedConnectionFactory has a method
> createManagedConnection which allows a javax.security.auth.Subject to be
> passed by the application server to the JMS provider when a connection is
> created. However the JMS API (and the "Chapter 8" API) has no such facility.
>
> Conclusion
> ----------
>
> My view is that we should choose option (1), the JCA API, as a mandatory
> API for integration with an application server, because it provides the
> richest interface that allows direct access from the various features of an
> application server (such as connection management) to the JMS provider
> itself.
>
> No doubt there will be details we need to explore, but this is probably
> enough for an opening proposal.
>
> Comments?
>
> Nigel
>
>
>