It's time for a quick update on where we are in the development of JMS 2.0.
Where are we now?
-----------------
Back in June I asked you to submit your priorities for JMS 2.0 which I summarised in a single email (the subject line
was "JSR 343: Summary of priorities so far". A short while later I received additional lists from Tom and from Graham.
I have now reviewed almost all of these, logged them in JIRA (with a tag of "eg") and sent at least one email to start
discussions on it.
Here's a list of these issues
http://java.net/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+JMS_SPEC+AND+Tags+%3D+eg
(Also see the link "Shortlist of issues raised by expert group members" on
http://java.net/projects/jms-spec/pages/Home#Useful_JIRA_queries )
To allow you to get an idea of which issues I have "captured" in this way, and which I have left, below is the same list
of EG priorities I circulated in June, with a note of the JIRA issue I raised. You should be able to track down the
emails on this topic by looking for the issue number (e.g. (JMS_SPEC-50)) in the subject line.
I've appended Tom's and Graham's priorities (which arrived later) to the end.
Some issues I haven't picked up, mainly because I wasn't quite sure how to proceed and I wanted to focus on those where
I was. I do intend to go back to these, but if you'd like to make a detailed proposal for any of those please let me know.
What next?
----------
1. Please review the list of issues in the above list (and the corresponding email threads) and let me know (by replying
to this email) if you think I have missed anything that you would consider a "priority" for the early draft.
2. Some of these topics were raised by me on behalf of other EG members. I'd like to ask the people who originally
suggested them to read my proposal and confirm (by replying to the relevant email thread) whether my proposals satisfy
your requirement.
3. We still need a proper proposal for (JMS_SPEC-41) "Support topic hierarchies" . I'd like to ask Tom, who proposed
this, to work with me in drawing up a proposal.
4. As far as I am considered all the issues in the above list are now on the table and I would appreciate comments from
members of the expert group. Please make comments by replying to the relevant email thread. There has already been
plenty of discussion on some topics, of course, but some have received few comments. Some proposals are still a bit
vague. In this case I am asking for comment on the principle - and for help in turning them into concrete proposal. In
other cases the proposal is already quite clear - in that case I shall presume that the absence of comments means that
you are happy with it in principle.
5. Starting in a week's time I want to start wrapping up some of these issues and writing the proposal into the draft
spec. Obviously I'll only do this when there's clear consensus - some topics are still definitely unresolved - and where
a proposal is clear and there has been no dissent, I'll consider that there is consensus unless someone says otherwise.
I'll send specific emails on each topic as I begin to do this.
6. Is this clear? Please say so if not, or if you have any other proposals as to how we do this.
Nigel
REVIEW OF EXPERT GROUP "PRIORITY LIST" FOLLOWS
----------------------------------------------
General, overriding issues which need to be kept in mind
--------------------------------------------------------
(THESE ARE JUST GENERAL PRINCIPLES)
* Any changes need to be backwards compatible: applications which are written to JMS 1.1 will continue to work (Reza).
* We need to make sure that we don't lose sight of the need to be able to use JMS outside of a Java EE environment: Java
EE must not be a requirement. (Adrian/Shivajee)
* One of the reasons why JMS has been successful has been its small, simple API. Let's not see this compromised just for
the sake of change (Adrian/Shivajee).
[My reaction is to accept all three of these as principles we should follow. Any objections?]
Major new API features
----------------------
* We should provide a modern, easier-to-use API, probably using annotations and CDI (Nigel, John, Reza, Julien,
Clerbert, Masoud). There seemed to be a variety of ideas of how we might do this, and we will need to explore these in
detail. Whilst I think we mostly see this as a feature for Java EE containers, there seems to be interest in offering
features to those using a Java SE environment as well.
(IN JIRA AND EMAIL THREAD STARTED)
http://java.net/jira/browse/JMS_SPEC-33
* There was a view from several of you that we should work to improve or replace MDBs as a way to asynchonously consume
messages in a Java EE container. (Emran, Adam, Clebert, Julien). There was also a suggestion that we remove the
restriction that prevents a application calling MessageConsumer.setMessageListener() within an EJB or web container
(Clebert). This is all closely-related to the previous issue. [Given that MDBs are already defined using annotation,
I'd like to understand better what it is that people feel are the problem with MDBs. I'm aware that the introduction of
CDI observers in Java EE 6 means that we have two alternative means of async notification: events and messages, and two
alternative types of callback: observers and message-driven beans, which poses the question of whether they can be
combined] And as with the previous issue, there was a suggestion that we would try to offer features to those using a
Java SE environment as well.
(STILL REMAINING)
Better integration with Java EE
-------------------------------
* We need to standardise the interface between a JMS provider and a Java EE application server, to allow portability of
JMS providers between application servers. (Nigel, Adrian/Shivajee). The frontrunner here is to mandate the provision of
a JCA resource adapter, though an alternative may be to extend and make mandatory the existing Chapter 8 API.
(IN JIRA AND EMAIL THREAD STARTED)
http://java.net/jira/browse/JMS_SPEC-25
* Decide on the future of the optional Chapter 8 API "JMS Application Server Facilities", which defines API for use by
application servers, including ConnectionConsumer, XAConnection, XAResource (Adrian/Shivajee, Nigel). This is optional
and has no compliance tests. Should we make it mandatory or simply drop it? If we make a JCA API mandatory is this still
needed? Experience has shown that this chapter leaves some issues undefined and that improvements would be necessary if
we decide not to drop it.
(IN JIRA AND EMAIL THREAD STARTED)
http://java.net/jira/browse/JMS_SPEC-26
* Clarify how the JMS provider should interact with Transaction Managers. In particular, the responsibilities of the
JMS Provider, the TM and the App Server during recovery need to be clearly defined. (Adrian/Shivajee)
(IN JIRA AND EMAIL THREAD STARTED)
http://java.net/jira/browse/JMS_SPEC-28
* We need to clarify the relationship between the JMS and other Java EE specifications. This is mainly a documentation
exercise, especially for those methods which are forbidden or modified in a EJB or Web container, but there are some
ambuguities, especially when the transaction context is undefined. (Nigel).
(IN JIRA AND EMAIL THREAD STARTED)
http://java.net/jira/browse/JMS_SPEC-27
* Define more mandatory activation config properties for JMS MDBs
(IN JIRA AND EMAIL THREAD STARTED)
http://java.net/jira/browse/JMS_SPEC-30 (Emran)
Other API changes
-----------------
The following, more specific API issues were raised:
- The API should make less use of unchecked exceptions (Reza). Reza point out that in many cases the application doesn't
know what to do when a javax.jms.JMSException is thrown, so for methods to declare that they throw a checked exception
is not always helpful. [We would need to maintain backwards compatibility (which Reza also states the need for), which
would limit the scope to change things. Also, some providers do rely on throwing exceptions to notify the client that
they need to retry an operation, perhaps the real issue is that this is non-standard.
(IN JIRA AND EMAIL THREAD STARTED) (
http://java.net/jira/browse/JMS_SPEC-35)
- Compression/decompression (Emran). I take it that this is a request for an API which would allow a client to define
whether a message is compressed in transit. [JMS providers are currently free to decide for themselves whether to
compress a message, and many do, so the question here is whether we need to allow clients to control this via the API
rather than via provider configuration features. ]
(IN JIRA AND EMAIL THREAD STARTED) (
http://java.net/jira/browse/JMS_SPEC-38)
- Timed messages (ability to send a message which the provider will deliver at a configured time in the future) (Emran, Tom)
(IN JIRA AND EMAIL THREAD STARTED)
http://java.net/jira/browse/JMS_SPEC-44
- Sending/receiving messages in batches (Emran, Clebert).
(IN JIRA AND EMAIL THREAD STARTED)
http://java.net/jira/browse/JMS_SPEC-36
- API to asynchronously send a message, with the server invoking a callback to acknowledge receipt (Clebert)
(IN JIRA AND EMAIL THREAD STARTED)
http://java.net/jira/browse/JMS_SPEC-43
- Improve existing API method Connection.createSession(boolean transacted, int acknowledgeMode). Can we have a single
argument? (Julien) Do we need a different API for use in a BMT/CMT transactional context? (Nigel)
(IN JIRA AND EMAIL THREAD STARTED)
http://java.net/jira/browse/JMS_SPEC-45 (see also below)
- Add support for message consumption from the same session by multiple threads. This implies the need to be able to
acknowledge individual messages. (Adrian/Shivajee)
(STILL REMAINING)
- Make use of new language features such as Generics (Adrian/Shivajee). [I've separately asked Adrian/Shivajee to
clarify what they have in mind.]
(STILL REMAINING)
- Deprecate JMS 1.0 Queue and Topic specific interfaces in favor of JMS 1.1 unified interfaces (Adrian/Shivajee). Adding
the @Deprecated annotation is easy enough, but do we want to formally announce that we will remove them from a future,
non-backwards-compatible, version of the spec?
(IN JIRA AND EMAIL THREAD STARTED)
http://java.net/jira/browse/JMS_SPEC-47
- Decouple the creation of a Message from a Session (Adrian/Shivajee). [I would comment: what alternative mechanism did
you have in mind?]
(STILL REMAINING - though John has made a proposal in his AtInject document)
- Ability to send objects directly, without need to wrap in a javax.jms.Message (John)
(STILL REMAINING - though has made a proposal in his AtInject document)
- We need to "scan all of the implementations" and look for features to standardise in the spec. (Masoud) [If you're
offering to do this, please do.]
(STILL REMAINING)
- Standardise the "connection string" to define server IPs, timeouts, etc, as in ActiveMQ (Julien). Currently JMS
doesn't define a connection string, and expects any connection config to be defined in the connection factory which is
currently vendor-specific. Also provide standard API on connection factories to create connections with secure transport
(Emran).
(IN JIRA AND EMAIL THREAD STARTED)
http://java.net/jira/browse/JMS_SPEC-45 (see also above)
Quality of service (QoS) features
---------------------------------
- Extend the spec to define clustering and failover behaviour (Emran, Julien). [The existing spec deliberately leave
this to vendors to define their own behaviour; perhaps what we should be focussing on is addressing areas where
different clustering and failover behaviour hinders portability of applications between providers. For example, whether
a failover causes a JMSException, or causes the transaction to be rolled back.]
(STILL REMAINING)
Support for Java SE environments
-----------------------------
- the API should not rely on JNDI for creating connection factories and destination objects (Julien, Clebert). [I think
the issue here is not so much JNDI but the idea that the creation of connection factories and destination objects is
provider-specific and non-portable and so should not be done directly by the application. We would need to consider
whether by removing this principle (presumably for Java SE clients only) we would be reducing the portability of
applications.]
(IN JIRA AND EMAIL THREAD STARTED)
http://java.net/jira/browse/JMS_SPEC-46
- the API should mandate pooling of JMS resources when used in a Java SE environment (Julien). [I suppose the issue here
is the extend to which we are expecting a JMS client to itself be a kind of lightweight container providing services
such as connection pooling that are already available in, say, the Java EE application client container.]
(STILL REMAINING)
- define the concept of a JMS "container" for use within a Java SE environment which would offer various services,
including CDI (John)
(STILL REMAINING)
Supporting cloud-related features in Java EE 7
----------------------------------------------
- We need to monitor the activities of the Java EE platform EG and identify any changes to the JMS spec that are needed
to support cloud-related features in Java EE 7 (Nigel). Since two members of the JMS EG are also on the Java EE EG (Reza
and Adam) I hope they can help with this. I'll also follow the Java EE EG and keep in contact with the spec leads.
(STILL REMAINING)
Tom Barnes's Priorities
-----------------------
In no particular order:
# (+1 to existing proposal for) a modern, easier-to-use API, with annotation & CDI goodness.
# (+1 to existing statement that) we don't lose sight of the need to be able to use the JMS API outside of a Java EE
environment. Java EE must not be a requirement. Java EE and SE JMS behavior and API should be as similar as possible.
# Support topic hierarchies (also known as subject hierarchies or wildcard subscriptions). IIRC, some vendors map topic
hierarchy nodes to subscriptions on a single topic, while others map each node to an entire topic (eg, a hierarchy of
topics). Topic hierarchies provide an intuitive solution for optimized message filtering, routing, and replication.
Support would also be helpful for simplifying the integration of JMS applications into messaging environments that
already depend on topic hierarchies (the mapping into and out of the JMS API becomes more straight forward). Most JMS
vendors and (and other pub/sub products) already support topic hierarchies, and they are integral to a variety of
standards, including AMQP, Web Services Event Notification, and the Bayeaux protocol.
(IN JIRA AND EMAIL THREAD STARTED)
http://java.net/jira/browse/JMS_SPEC-41
# Support shared topic subscriptions. The idea is to support multiple concurrent message consumers from different
sessions on the same durable or non-durable subscription. This would allow applications to use multiple threads to
consume messages from the same topic subscription using the vanilla javax.jms.* API, offering much greater scalability.
(IN JIRA AND EMAIL THREAD STARTED)
http://java.net/jira/browse/JMS_SPEC-40
# Make support for the JMSXDeliveryCount message property mandatory (this is optional in JMS 1.1). This wouldn't need to
be perfectly correct -- a "best effort/volatile" implementation would probably be adequate -- but support for it would
allow arbitrary containers and applications to more easily detect problem messages and handle them accordingly.
(IN JIRA AND EMAIL THREAD STARTED)
http://java.net/jira/browse/JMS_SPEC-42
# Provide a mandatory API that (1) would allow the creation of a generic JMS resource adapter that can work with any JMS
2.0 implementation, and (2) would allow the creation of non-Java EE frameworks that provide services such as XA
transactions and resource pooling, but which don't support the Java EE Connector Architecture. One specific advantage
of (1) is that it allows vendors to provide a generic JMS resource adapter which can be configured, managed and
monitored in the same way regardless of JMS provider. The mandatory API could probably be based on the existing JMS 1.1
Chapter 8 API (XAConnection, XASession, ConnectionConsumer etc), with some changes to resolve gaps in the existing API,
plus perhaps a simplification involving replacing XAConnectionFactory, XAConnection and XASession with a new method
getXAResource() on Session.
(Possible covered in)
http://java.net/jira/browse/JMS_SPEC-26
# Clarify the specification to state that support for XA transactions should work with any JTA transaction manager and
not be restricted to a transaction manager supplied by the vendor.
(STILL REMAINING)
Graham Wallis's Priorities
--------------------------
* Specification of a standard means of connecting to a JEE appserver - my preference is for JCA
(IN JIRA AND EMAIL THREAD STARTED)
http://java.net/jira/browse/JMS_SPEC-25
* Disambiguation of the specification, and resolving of contradictory statements
(STILL REMAINING)
* Improvements to documentation - especially the point about relationships between JMS and other JEE specs
(STILL REMAINING)
* Adoption of functional updates that will improve performance or other areas
(STILL REMAINING)