This section gives an overview of JMS.A JMS application is comprised of the following elements:

  • JMS clients. Java programs that send and receive messages using the JMS API.
  • Non-JMS clients. It is important to realize that legacy programs will often be part of an overall JMS application and their inclusion must be anticipated in planning.
  • Messages. The format and content of messages to be exchanged by JMS and non-JMS clients is integral to the design of a JMS application.
  • JMS provider. As was stated previously, JMS defines a set of interfaces for which a provider must supply concrete implementations specific to its MOM product.

Administered objects. An administrator of a messaging system provider creates objects that are isolated from the proprietary technologies of the provider.

Administered objects

Providers of MOM products differ significantly in the mechanisms and techniques they use to implement messaging. To keep JMS clients portable, objects that implement the JMS interfaces have to be isolated from the proprietary technologies of a provider.

The mechanism for doing this is administered objects. These objects, which implement JMS interfaces, are created by an administrator of the provider’smessaging system and are placed in the JNDI namespace.
The objects are then retrieved by JMS programs and accessed through the JMS interfaces that they implement. The JMS provider must supply a tool that allows creation of administered objects and their placement in the JNDI namespace.

There are two types of administered objects:

  • ConnectionFactory: Used to create a connection to the provider’sunderlying messaging system.
  • Destination: Used by the JMS client to specify the destination of messages being sent or the source of messages being received.
READ  JMS-Point-to-point interfaces

While the administered objects themselves are instances of classes specific to a provider’s implementation, they are retrieved using a portable mechanism (JNDI) and accessed through portable interfaces (JMS). The JMS program only needs to know the JNDI name and the JMS interface type of the administered object; no provider-specific knowledge is required.


JMS defines a set of high-level interfaces that encapsulate various messaging concepts. In turn, these interfaces are further defined and customized for the two messaging domains — PTP and pub/sub.

The high-level  interfaces are:

  • ConnectionFactory: An administered object that creates a Connection.
  • Connection: An active connection to a provider.
  • Destination: An administered object that encapsulates the identity of a message destination, such as where messages are sent to or received from.
  • Session: A single-threaded context for sending and receiving messages. For reasons of simplicity and because Sessions control transactions, concurrent access by multiple threads is restricted. Multiple Sessions can be used for multithreaded applications.
  • MessageProducer: Used for sending messages.
  • MessageConsumer: Used for receiving messages.

The following table identifies the domain-specific interfaces inherited from each high-level interface.


PTP domain

Pub/sub domain