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

Brief overview of JSR 343: JavaTM Message Service 2.0

Well, as many of us already know Oracle submitted the JSR for Java EE 7 which is sort of an umbrella JSR for many update in already existing specifications, new versions of some JSRs and some completely new JSRs which will be part of the grand Java EE 7 – JSR 342.

One of these JSRs is the JSR 343 which introduces a new version of JMS into the platform as an evolution of its previous version, JSR-914, and will unify the JMS usage with what added to the platform in the past 8 years.

The following represent some very simple usecases of JMS in the enterprise while complex multiphase transactional usecases are not unusual when MDBs and XA data sources are involved.

  • JMS itself is for asynchronous communication and widely used to communicate some execution instructions from one node or point to another or a set of other points. For example long running queries can be queued using a JMS queue to get processed by another point in the system while the query client is not blocked for the query result.
  • Or it can be used to communicate a common set of instructions to many interested parties which may or may not be around the communication happens, durable subscriptions and persisted topics. For example when clients need to get an ordered set of update messages to update a localcache when they get online after some times. Each client will get its own copy of messages it should receive when getting online.

JMS API provides enough functionalities to realize most of our design out of the specification and the minor features and functionalities not included in the JSR while required by some designs are covered by the vendor specific pack of enhancement and tweaks provided in the broker level and through the vendor specific API.

You may ask if the current JMS API provides all we need, why a new JSR should be put on the table, the answer mainly relies on the theme for Java EE 7 which is making Java EE more cloud friendly and sort of cloud enabled by nature rather than by product.

The details of JMS 2.0 spec goals are listed at the JSR homepage but a brief list can be seen as follow:

  • Community requested features and enhancements.
  • Make the JSR more cloud friendly based on how Java EE 7 will define “to be cloud friendly”
  • Cleanup of some ambiguity in the relation of JMS with other Java EE specs.
  • Make the API easier to use, more annotations and more generics will be involved for the least of the things or maybe reducing number of boxes and lines in the aove figure  could help many to start with the API faster.
  • Make necessary changes to benefit from the JSR-299 or Contexts and Dependency Injection to easier and more unified use of API.

In the follow up posts I will iterate over each one of these bullet points in more details.

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 :-).