Decide on the future of the optional Chapter 8 API "JMS Application Server Facilities"

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](https://java.net/jira/browse/JMS_SPEC-25 "Standardise the interface between a JMS provider and a Java EE application server") (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](https://java.net/jira/browse/JMS_SPEC-25 "Standardise the interface between a JMS provider and a Java EE application server") 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.