Here are some minutes from a phone call that John, Reza and I had yesterday. One-line-summary: Reza and John have agreed
to work together and produce a more detailed proposal along the lines described below, which could then be reviewed by
this EG. Many thanks! Nigel
On the call: Nigel, John, Reza
Minute taker: Nigel
Reza and John have offered to work together to develop proposals to address "(JMS_SPEC-33) Improving the JMS API with
API simplifications, annotations and CDI"
The purpose of this call was to agree on the scope of that proposal, and a suitable phasing.
Scope
-----
The proposal would be aimed at improving the way that JMS was used in Java EE applications.
Improving the way that JMS is used in Java SE applications was considered hightly desirable but a secondaery requirement.
Phasing
-------
Nigel explained that he thought any proposals should be divided into two phases:
Phase 1: Improving the API for sending and for synchronously receiving messages
Phase 2: Improving the API for asynchronously receiving messages
Phase 1 was a higher priority than Phase 2 because whereas Java EE applications currently have no choice other than to
use the JMS API for sending and for synchronously receiving messages, applications that asynchronously receive messages
can (and must) use MDBs which are declarative and already completely hide the JMS API.
Dependencies
------------
Phase 1 could probably be built as a later on top of the existing, or slightly modified, JMS API. It would have minimal
dependencies on the Java EE platform or on other Java EE specs.
Phase 2 would require close integration with the Java EE platform, for the same reason that means MDBs are implemented
in the platform rather than the JMS provider. There would be dependencies on changes to the Java EE platform and to
other Java EE specs.
Nigel explained that he was advocating this two-stage approach becayse Phase 2 looked as if it would take more time and
require more negotiation with other groups, and he didn't want this to prevent the EG making rapid progress with Phase 1.
Phase 1 in more detail
----------------------
We discussed Phase 1 in more detail. It was agreed there were two main possible approaches:
1. A new API which used resource injection and annotation. The SEAM JMS project was suggested as an example of this
approach. Reza had already published some examples of such an API.
2. A simplified "plain old" Java API, not using resource injection or annotation, which provided various utility methods
for sending and synchronously receiving messages. The Spring JMSTemplate class was suggested as an example of this approach.
In both cases, whilst the goal would to devise something that would use the existing JMS API, this would not preclused
small changes to the JMS API if this would allow a simpler API overall. One suggestion providing message factory methods
which didn't depend on a Session object.
It was likely that the RI for both approaches could be used by other vendors, though it was not intended to precluse
vendors offering their own implementations.
There was also a third option, to develop a completely new JMS API, not using resource injection or annotation, and NOT
built on top of the existing API. This wasn't something EG members have suggested so far and although it might be worth
including in any review of options, it didn't seem a likely option.
Timscales
---------
Reza and John suggested that would aim to have some proposals that they could share with the EG in about two weeks.