Nigel,
I believe the JCA adaptor is more feasible as the community already got
enough experience with it and there are several implementations out there.
Cheers,
Masoud.
> ------------------------------------------------------------------------
>
> Nigel Deakin <mailto:nigel.deakin_at_oracle.com>
> July 8, 2011 6:01 PM
>
>
> 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
>
>
>
--
Software Engineer and Developer
http://kalali.me