Here is a summary of my own priorities for JMS 2.0. This is naturally similar to those I mentioned in the original JSR
submission. I'm fully aware that other EG members have priorities not mentioned here.
Nigel
1. Simpler programming of Java EE applications that use JMS
My goal here is to allow JMS developers to benefit from the features that have been added to Java EE since JMS 1.1 was
released specifically to make application development simpler and easier. I'm thinking in particular of the introduction
of annotations in Java EE 5 and the addition of support for Contexts and Dependency Injection (CDI) in Java EE 6.
Discussions would need to bear in mind that CDI support is not required in the Java EE Application Client or in a Java
SE environment.
I think the greatest benefits would to allow developers to use resource injection to obtain MessageProducer and
MessageConsumer objects, avoiding the need for boilerplate code to create (and close) connections and sessions.
The annotation would need to support the various arguments supplied in the JMS API, such as destination, message
selector, noLocal flag. We would also need to consider how to handle transacted mode and ack mode, which are ignored in
a transactional context and could be omitted, and take account of the restrictions on calling setClientID,
setExceptionListener and setMessageListener.
The introduction of MDBs (which of course pre-dated JMS 1.1) offered a way of defining a Java method which consumed code
asynchronously without Java code, and Java EE 5 allowed them to be configured using annotations. This means that I don't
believe we need to devise a new way to define async message consumption. I've heard criticism of MDBs but feel that we
should seek to address them rather than try to invent an alternative.
I'm aware of the Seam JMS project, which may influence our thinking in what annotations we would define. However I'm
unconvinced about its idea of async message consumption using CDI events instead of using MDBs and would welcome hearing
others make a case for this.
2. Removal or clarification of ambiguities that have been discovered in the existing JMS specification
I know that over the years people have suggested that parts of the JMS spec are ambiguous and unclear. This means that
applications behave differently with different JMS providers, thereby reducing their portability.
I don't have a list of issues, but I know that others do and think we should allow time to seek out such issues and
attempt to rectify them, ideally by simply clarifying the spec or Javadocs and adding new compiance tests.
3. Clarification of the relationship between the JMS and other Java EE specifications
If you want use the JMS API in a Java EE application such as a EJB or servlet you soon discover that much of the JMS
spec (including the JMS javadocs) does not apply, at least in the EJB and web containers. For example, you aren't
allowed to create message listeners, you need to defined MDBs instead. You aren't allowed to create local transactions,
you need to use CMT or BMT transactions instead. You aren't allowed to set clientID on a connection. You aren't allowed
to perform client acknowledgement. Essentially, in a Java EE container, the JMS API is simply different. However this is
not explained in the JMS spec but is described in other specs, notably the EJB and Java EE platform specs.
Some of this information of necessity in other specs, but the absence of any mention of it in the JMS spec or javadocs
is confusing to users.
I would like the JMS expert group to review what it says about JMS in other specs and consider whether this material
should be moved to the JMS spec, duplicated in the JMS spec, or cross-referenced from the JMS spec. In addition the
javadocs need to be clarified to mention that some API is not allowed, or has a different effect, in a Java EE web or
EJB container.
I see this mainly as a documentation exercise. However this analysis will inevitably identify that some areas of
behaviour are not well defined. For example, the EJB spec states explicitly that in an "undefined transactional context"
it is not defined how the JMS provider should handle transactions. This means that vendors may behave differently which
reduces the portability of application. If possible this should be resolved.
4. Definition of a new mandatory API to allow any JMS provider to be integrated with any Java EE application server
JMS is almost unique in the Java EE world in that in additional to being an internal component of an application server
it is also a mechanism for connecting two application servers, possibly from different vendors. This means that there is
a clear requirement to be able to send messages from one applicaton server to a "foreign" application servers. Since JMS
does not define wire interoperability which means plugging a JMS client from vendor A into an application server from
vendor B.
Chapter 8 of the JMS 1.1 spec lists some optional API to support the integration of JMS providers in application
servers. Since this is optional not all JMS providers implement it. Those that do implement it discover that it leaves
some gaps, such how the receipt of a message by a ConnectionConsumer should be enlisted in an XA transaction.
However since JMS 1.1 was released, the Java Connector Architecture has been defined, with part of the JCA spec
specifically intended to allow JMS providers to be incorporated into the MDB, resource pooling and transactional
capabilities of an application server.
5. Adding support for PaaS and SaaS
The theme for Java EE 7 is "the cloud", and in particular support for PaaS (Platform as a service) and a limited form of
SaaS (software as a service). The JSR 342 (Java EE Platform) expert group is currently discussing what changes are need
to the platform to support this, and what implications this will have for component JSRs such as JMS. We will need to
monitor the work of JSR 342 and identify what changes are needed for JMS 2.0.
PaaS and SaaS support will probably be optional in Java EE 7, so it would be optional in JMS 2.0.
The most likely change needed will be to add support for multi-tenancy, in which two or more "tenants" may use the same
JMS provider whilst being compietely or partially isolated from one another. This might include the use of namespaces
(e.g. in destination names) to prevent tenants clashing on names, and some new way of passing tenant identity to the JMS
provider (instead of user/password) when a JMS connection is created. JMS 1.1 does not mandate any security behaviour
and we would to consider what degree of mandate is appropriate for 2.0.
6. Other enhancements as requested by the community and the expert group
I'm not submitting a long list of possible enhancements here, though I do expect other EG members to do so (Tom Barnes
will present some suggestions from Oracle). I see my role as spec lead as to make sure the EG reviews all these
proposals together with those submitted by members of the community.
I'll be looking to find out the degree of consensus on any particular change, how beneficial we think it would be, the
amount of work involved (both for the EG and for vendors) and the priority EG members give to it. This will allow us to
prepare a list of possible changes for JMS 2.0. No doubt some changes would be rejected wbilst others might be deferred
for a future JMS 2.1.