jms-spec
  1. jms-spec
  2. JMS_SPEC-26

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

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      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.

        Activity

        No work has yet been logged on this issue.

          People

          • Assignee:
            Nigel Deakin
            Reporter:
            Nigel Deakin
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: