jsr343-experts@jms-spec.java.net

[jsr343-experts] JMS 2.0 Priorities: Proposal from Adrian Johnson and Shivajee Samdarshi (TIBCO Software Inc.)

From: Adrian Johnson <ad_at_tibco.com>
Date: Mon, 20 Jun 2011 13:39:17 -0700

TIBCO Enterprise Message Service, TIBCO's JMS implementation, is a key product for TIBCO.
We use it internally as well as selling it as a standalone product to our customers. Many
of our customers use the product inside an App Server environment but many do not. Hence
one of our priorities has to be to ensure that JEE does not become a requirement.

As implementers we welcome the desire to improve and clarify certain aspects of the
current spec. An area that is problematic for our customers is the interface with JEE. We
often find that when an App Server vendor releases a new version, there is quite a lot to
do to ensure EMS works in that environment. One suggestion would be to require support for
JCA to make this more straightforward.

In our experience the 1.1 Spec is not very clear when it comes to interactions with
Transaction Managers. In particular, what are the responsibilities of the JMS Provider,
the TM and the App Server during recovery.

Our experience has also shown that the current CLIENT_ACKNOWLEDGE mode doesn't support
Message consumption in several threads very well. We were forced to add a mode that allows
acknowledgment of a particular Message and would recommend adding this to the Spec.
Further more we have found that with such a mode, it is useful to be able to recover
individual Messages as well. This should also be added to the Spec.

Another area for improvement would be the ConnectionConsumer interface. Can this be
improved or simplified as a way to make App Server integration easier?

Lastly, we support the ideas around making the API more modern and easier to use for
programmers but do feel that part of the reason why the Spec has been unchanged for so
long is that it is very compact and does what it does quite well. We don't want to see
this compromised just for the sake of change. That being said here is a short list of some
suggestions for improvements to the API:

o Make use of new language features such as Generics
o Removal of Queue and Topic specific interfaces in favor of general ones
o Decouple the creation of a Message from a Session

Adrian Johnson & Shivajee Samdarshi.
-- 
Adrian Johnson
TIBCO Software Inc
ad_at_tibco.com