Overview

What is JMS?

JMS (short for Java Messaging System) is a Message-Oriented Middleware (MOM) API developed by Sun a couple of years ago. The primary reason behind the effort was to create a unified Java API for message-oriented application programming and avoid being forced to use vendor-specific APIs, instead. You program against the API, but at runtime you will need a particular JMS implementation, called a JMS provider, from a vendor. There exist several different JMS providers; the one used in JBoss is called JBossMQ.

JMS is handy to use when some (or all) of the following requirements are part of a project:

  • Systems decoupling

  • Asynchronous behavior

  • One-to-many, many-to-many or many-to-one semantics

  • Guaranteed delivery

JMS and J2EE

JMS was developed before Enterprise Java Beans (EJBs) and the Java 2 Enterprise Edition (J2EE) framework were developed. It's therefore no surprise that there is no mention of EJB or J2EE in the JMS specification.

In the first generations of the EJB and J2EE specifications there was no mention of JMS, either. Up to, and including, EJB version 1.1, JMS was not a required API that a container provider had to make available to the beans. In J2EE 1.2 there was a requirement stating that the JMS interface had to be available, but it was not a requirement to also include a JMS provider; as a result, there was no guarantee that you could really use your JMS code.

This has changed in EJB 2.0 and J2EE 1.3. A J2EE 1.3-compliant application server has to include a JMS provider. Since J2EE 1.3 also requires EJB 2.0, two additional JMS features have also been added:

  • A new type of bean has been defined. Called a Message Driven Bean (MDB), this type of bean acts as a JMS subscriber, thus introducing asynchronous invocation to EJBs.

  • The treatment of JMS as a resource. For consistency, JMS publishing (sending) from a bean needs to be able to participate in the global transaction environment of the bean. This requires that JMS be considered a container-managed resource, much like a JDBC connection. In this scenario the transaction of a JMS session will be managed by the container and the session will be treated like any other transactional resource accessed from the same method.

JMS and JBoss

JBoss has had support for JMS since version 2.0. Support for Message Driven Beans was added in version 2.1 and JMS as a transacted resource has been available since version 2.4.

The JMS architecture of JBoss includes the following elements:

  • The JMS provider. Called JBossMQ, this is the part of JBoss that implements the JMS 1.0.2 specification, including the optional parts, such as the Application Service Facility (ASF) in Chapter 8. JBossMQ handles everything that has to do with ordinary JMS: creating queues or topics, persistence, performance.

    JBossMQ was created by Norbert Lataille in the spring of 2000. Hiram Chirino sort of took over the responsibility in late 2000 and added (among other things) ASF and XA support. Paul Kendall and David Maplesden have made recent contributions.

    JBossMQ has its own CVS module and its own mailing list, spyderMQ, where the core JBossMQ programmers hang out.

  • Message Driven Beans. They are part of the JBoss core EJB container system and they are fully specification-compliant. Peter Antman initially wrote this, but Hiram Chirino and Jason Dillon (among others) have also made large contributions.

  • A resource adapter. In JBoss 2.4, Peter Antman added a resource adapter for JMS architected as a J2EE Connector. It is meant to be used for all non-asynchronous JMS tasks from within an EJB in JBoss.