Understanding JMS Architecture

The JMS API is an abstraction of the interfaces and classes that JMS clients use to handle messages when in communication with a JMS provider. This is analogous to the use of JDBC as a unified API to access data sources, as you learned on Day 9, “Using JDBC to Connect to a Database,” or JNDI to access naming and directory services, as you learned on Day 4, “Using JNDI for Naming Services and Components.” JMS is not a messaging system by itself; it's an API to access an existing messaging system. The JMS architecture is best illustrated by Figure 13.1.

Figure 13.1 depicts all the layers that constitute JMS architecture, and the relationships between them. The following is a brief description of each layer, and the function it performs:

• JMS clients: Send and receive messages through a JMS provider.

• JMS messages: Applications define a set of messages that are used to communicate information between its clients.

• JMS API: Unified interfaces and classes to be used by all JMS clients.

• JMS provider: The messaging system (MOM) that implements JMS in addition to other administrative and control functionality required of a full-featured messaging product.

• Administered objects: Administered objects are pre-configured JMS objects created by the JMS provider's administrator for the use of clients. Administered objects are not shown in Figure 13.1.

JMS specification defines these architecture components to facilitate writing portable enterprise applications. It does not address certain operational functionality such as

• Clustering. JMS does not address load balancing or fail-over; support is left to the JMS provider.

• Security and administration. The JMS API does not provide control privacy and integrity of JMS messages. Security is considered to be a JMS provider-specific aspect.

• Error notification. MOM vendors (JMS providers) send proprietary notification messages to clients. JMS does not attempt to standardize these messages. Developers should be aware of these messages to avoid any portability issues.

A number of JMS providers offer products of varying JMS support. Some of these products are SonicMQ from Progress, FioranoMQ from Fiorano, WebLogic from BEA, MQSeries from IBM, and the open source JBossMQ from JBoss.

Administered Objects

One of the objectives of the JMS architecture is writing portable and configurable applications. For JMS clients to be portable, they must be isolated from any proprietary aspects of JMS providers. This is done by defining JMS-administered objects. These objects are created and configured by a JMS provider's administrator and then registered in a JNDI namespace. Later, they are accessed by JMS clients through looking them up in the JNDI service. Administrators create these objects using a JMS provider-specific administrative tool.

There are two main two types of JMS administered objects:

• ConnectionFactory: The object a client uses to create a connection with a JMS provider.

• Destination: The object a client uses to specify the destination of messages it sends and the source of messages it receives.

Administered objects not only hide JMS provider-specific configuration details from JMS clients, but they also abstract JMS administrative information into Java objects that are easily organized and administered from a common management console.