Proposed features and functionalities of JavaTM Message Service 2.0, JSR-343
This is the second entry on the series of articles I will write on JMS 2.0. You can find the first entry here. In this article I will iterate over the suggested features which might be included in the JMS 2.0 based on the final decisions by the expert group.
I classified the features into some meaningful categoriz which are as follow:
The API ease of use
The first set that I am going to cover is around the ease of use of the API which despite being elegant is a little hard to start with specially for new developers whom look for the asynchronous communication solutions in Java EE platform. The features and changes proposed for this part are as follow:
- As usual the backward compatibility is a trend which the EG is going to adhere. Any application working with JMS 1.1 will continue to work with JMS 2.
- The API wont get harder to use despite the additional features which are going to be included in the next version.
- Using JMS from Java SE will be possible with JMS 2.0 as it is with JMS 1.1
- API is going to get simpler by using more annotations and integration of the JMS API with the CDI
- Using the MDBs is going to get simpler and MDBs is going to see a revamp as did other EJB types in previous versions of Java EE.
- The API should make less use of unchecked exceptions
Changes interesting to vendors
These are a set of proposed changes to make it easier for the JMS vendors and application server vendors to implement the JMS interface to their JMS brokers as well as integrating the broker into different application servers.
- An standard interface will be defined to make it possible for any any compliant application server to integrate with any of compliant JMS implementation. It is more likely to happen through the JCA adapter and making it mandatory.
- “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.”
- Clarifying the relation between JMS provider and other Java EE services and APIs specially the transaction manager. It will be more about documentation rather than implementations.
Other enhancements and changes
- Defining the transport security at the API level for sake of more portability.
- Message compression for faster transport…
- Timed messages which will be delivered by the provider to the consumer on schedule specified for the message.
- Asynchronous send with call back enabled acknowledge in order not to block the client until server sends back the acknowledge.
- supporting message consumption from the same session by multiple threads
- Deprecate JMS 1.0 Queue and Topic specific interfaces in favor of JMS 1.1 unified interfaces
- Ability to send objects directly, without need to wrap in a javax.jms.Message
- Standardise the “connection string” to define server IPs, timeouts, etc, as in ActiveMQ, OpenMQ, etc.
- Standardizing the interaction between Clint and the provider in clustered environment to make the applications more portable from one farm of JMS providers to another.
I am member of the JMS 2.0 expert group but this post or any other post in my personal blog does not reflect the expert group opinion or the opinion of my employer on the subject unless you could not see this paragraph at the end of the post . The EG is not going to be held responsible to provide any of these features in the JMS 2.0 as the spec is still open and nothing is finalised. It is just to give you a overview of what is being discussed in the EG. To find more information about the JMS 2.0, take a look at the JCP page for the spec at http://www.jcp.org/en/jsr/detail?id=343 or its homepage at Java.net at http://java.net/projects/jms-spec/pages/Home