I'd like to start a disscussion about this JIRA issue:
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