JMS Architecture

JMS clients normally connect to a central messaging hub supplied by the JMS provider. Clients exchange messages through this messaging hub instead of connecting to each other directly. In addition. clients use the services provided by the JMS provider for sending and receiving enterprise messages. A JMS system is typically composed of the following component parts:

• JMS providers

• JMS clients

• JMS messages

• Administered objects

Important 

JMS providers are software vendors who implement the interfaces defined in the JMS specification, and who provide added features like load balancing, clustering, persistence services, etc.

The examples in this chapter use the JMQ (Java Message Queue) implementation from Sun Microsystems. Messaging products either come as standalone products like SonicMQ from Progress Software or as a part of an application server suite like the WebLogic Server from BEA Systems. The open source community also has various JMS implementations, one of which is JBossMQ.

Important 

JMS clients are Java language applications that exchange JMS messages using the services provided by the JMS provider.

Portable JMS clients should use only the standard JMS interfaces in their application code and should not use any provider-specific implementation classes.

The JMS specification defines different kinds of messages that can be exchanged by JMS clients. JMS messages can be plain text messages or an entire serialized web of Java objects. The JMS specification defines the following types of message:

• Messages containing plain text.

• Messages containing serialized Java objects.

• Messages containing an un-interpreted stream of bytes.

• Messages containing a stream of Java primitives and strings.

• Messages containing a map of Java primitives and strings.

• Additionally JMS providers may provide their own message extensions. For instance, providers may provide messages that extend plain text messages that can support XML.

JMS providers implement the interfaces defined for the different JMS messages. We will be dealing with JMS messages in more detail in Chapter 3.

Important 

Administered objects are pre-configured objects stored in a namespace by JMS administrators for the use of JMS clients. An administrator is the person responsible for ensuring the proper day-to-day functioning of the JMS system.

Administered objects form the base for writing portable JMS applications. They are normally available for standard JNDI (Java Naming and Directory Interface) lookup even though the JMS specification doesn't make this a requirement. Administered objects can be stored outside the JMS provider in the namespace of any naming and directory service provider.

Connection factories are used for creating connections that may represent an open TCP/IP socket to the provider. All configuration information required for creating the connection is stored in the Administered object by the JMS administrators. Connections also act as factories for creating JMS sessions and are explained in further detail in the coming sections.

Sessions are single-threaded contexts for sending and receiving messages, and are used as factories for creating different kind of JMS messages. They are also used for creating objects that send and receive messages. These objects are called message producers and message consumers respectively.

Message consumers and producers are associated with specific message destinations/sources. A consumer can receive messages only from the message source it is associated with and a producer can send messages only to the message destination it is associated with.

The diagram below depicts the high-level architecture of a JMS system as explained above:

The JMS specification defines interfaces for all the JMS entities explained above. JMS providers provide implementation classes for these interfaces. Portable JMS clients need to be aware of only these interfaces and should not be using the provider-specific implementation classes in the application code. All these objects are explained in further detail in the coming sections.