<< Back to previous view

[JMS_SPEC-26] Decide on the future of the optional Chapter 8 API "JMS Application Server Facilities" Created: 06/Jul/11  Updated: 24/Feb/12

Status: Open
Project: jms-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: Nigel Deakin Assignee: Nigel Deakin
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: eg pd20-underreview
Participants: Nigel Deakin

 Description   

Chapter 8 of the JMS 1.1 specification, "JMS Application Server Facilities", defines an API for use by application servers. It has two parts:

  • API to allow concurrent processing of a subscription's messages: the interfaces ServerSession, ServerSessionPool, ConnectionConsumer and the methods Session.setMessageListener(), Session.getMessageListener() and Session.run().
  • API to support distributed (XA) transactions: XAConnectionFactory, XAConnection and XASession.

This API is optional and has no compliance tests.

Should this API be made mandatory, like the rest of the JMS spec, or should it be formally pruned from the spec?

This will partly depend on the outcome of http://java.net/jira/browse/JMS_SPEC-25 (Standardise the interface between a JMS provider and a Java EE application server). If it is decided that the interface between a JMS provider and a Java EE application server should use these interfaces (rather than the Java EE Connector API) then clearly they should become mandatory.

However, irrespective of the outcome of http://java.net/jira/browse/JMS_SPEC-25 it may be beneficial to keep this API and make it mandatory since that would

1. allow the creation of a generic JMS resource adapter that can work with any JMS 2.0 implementation, and
2. allow the creation of non-Java EE frameworks that provide services such as XA transactions and async delivery to multiple consumers, but which don't support the Java EE Connector Architecture

However these potential benefits need to be offset against the additional burden this may place on JMS vendors.

Note that if it is decided that these interfaces are not needed, they would not be deleted from the spec but remain in their current optional state, in accordance with chapter EE.6.1.3 "Pruned Java Technologies" of the Java EE 6 specification, perhaps with an explicit statement of why they are not needed.

If it is decided that these interfaces are still required then there some improvements may be required to clarify, say, the integration with the transaction manager.



 Comments   
Comment by Nigel Deakin [ 26/Jan/12 10:37 AM ]

It would be worth updating the Javadoc for the optional Chapter 8 API to explain that these classes and methods are primarily intended for use by application servers. This is obvious to anyone reading the spec, but for some reason isn't spelled out in the javadoc for methods like Session.setMessageListener().

Comment by Nigel Deakin [ 16/Feb/12 10:18 AM ]

I asked a colleague for their comments on the Chapter 8 API, and they replied as follows:

The getXAResource call has proved relatively robust for directly integrating foreign providers like Tibco, Sonic, and IBM MQ.

I think the main issue I have with it is the multi-RM problem: correctly fronting a logical RM that's actually backed by an independent set of RMs. In particular the problem is that we must currently somehow return the entire set of in-doubt transactions for all RMs in an entire cluster when "XAResource recover()" is called, even for component RMs that may not be running. We've all already discussed this at length. Currently, each provider must come up with some sort of internal solution on its own - but this isn't easy. Advancing one or all of the JTA, JCA, or JMS specs would help...

Another relatively smaller problem is that it would help to know when a vendor has thread-affinity requirements for a transaction life-cycle on the XAResource (IBM MQ). Or, alternatively, to harden the spec so that it's illegal to require thread affinity by default. It's a bit painful for a container to enforce such a requirement.

A secondary issue is the ConnectionConsumer API. It is complex and it's not entirely clear how it's supposed integrate with a foreign TM, and we've found no strong need to make use of it when integrating foreign providers.

Generated at Wed Apr 16 09:20:03 UTC 2014 using JIRA 4.0.2#472.