search

jakartaee / messaging

Jakarta Messaging
https://eclipse.org/ee4j/messaging
Other
40 stars 33 forks source link

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

Open glassfishrobot opened 13 years ago

glassfishrobot commented 13 years ago

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

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.

glassfishrobot commented 6 years ago
glassfishrobot commented 13 years ago

@glassfishrobot Commented Reported by @nigeldeakin

glassfishrobot commented 12 years ago

@glassfishrobot Commented @nigeldeakin said: 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().

glassfishrobot commented 12 years ago

@glassfishrobot Commented @nigeldeakin said: 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.

glassfishrobot commented 7 years ago

@glassfishrobot Commented This issue was imported from java.net JIRA JMS_SPEC-26