Brief Introduction to Enterprise Messaging

Enterprise messaging is one of the most widely used and most important technologies for integrating various disparate enterprise applications. The Java Message Service (JMS) API provides a standard interface for interacting with enterprise messaging services. The BEA WebLogic Server 8.1 provides an enterprise-class means for not only implementing such services, but also for configuring such services with your applications. Before we delve into the JMS API and how it is used inside of BEA WebLogic Server, it's important to have a foundation in enterprise messaging service concepts.

A messaging service is software that provides support for passing messages between distributed applications in a reliable, asynchronous, loosely coupled, language-independent, platform-independent, and often configurable fashion. Messaging services accomplish this task by encapsulating messages that are sent between a sender and a receiver and by providing a software layer that sits between distributed messaging clients. A messaging service also provides an interface for messaging clients to use that isolates the underlying message service implementation such that heterogeneous clients can communicate using a programmer-friendly interface. Such an infrastructure can also be viewed as an event notification type service in which messages are events, and the delivery of these messages between messaging clients acts as sort of an event notification mechanism. In this section, we explore the various facets of messaging services utilized by enterprise systems.

Message Service Locality

Figures 12.1 and 12.2 depict two types of messaging service implementations. Figure 12.1 shows the most common type of messaging service implementation, in which some middleware software implements the functionality of a messaging service to receive asynchronously generated messages from a message producer and route them to a message consumer. A messaging client utilizes the services of the centralized messaging service in a transparent fashion via a messaging client interface. Figure 12.2 depicts a messaging service implementation in which the messaging software is embedded directly into a thick messaging client.

Most of our discussions here assume the use of messaging middleware. Messaging middleware enhances the reliability and availability of a messaging service by virtue of a focus on the use of centrally managed persistent and redundant mechanisms in the middleware. Messaging middleware also alleviates the need for clients to manage connections to multiple messaging service endpoint locations by allowing a connection between a messaging client and a messaging service middleware server.

Point-to-Point Messaging

Figure 12.3 depicts one type of messaging service used for point-to-point communication between a message producer and a message consumer. A message producer sends a message to a particular consumer identified by some name (for example, "Foo"). This name actually corresponds to some queue in the message service used to store the message until it can deliver the message to the consumer associated with that queue. The queue may be persistent to help guarantee the delivery of a message even in the event of a message service failure. That is, a persistent queue can be read by a backup message service instance and used to deliver messages to a message consumer even if the primary message service fails.

Publish-Subscribe Messaging

Figure 12.4 depicts another popular model of messaging known as the publish-subscribe messaging service. With publish-subscribe, a message publisher publishes a message to a particular topic. Multiple subscribers can register to receive messages that have been published to a particular topic. Topics can be hierarchically arranged and can further enable the publication of messages and subscriptions to receive messages within a particular topic context. For example, we might subscribe to receive only those messages published specifically to the Stocks topic, or subscribe to receive all of those messages published to the Stocks topic and its subtopics, such as OTC.

Message Filtering, Synchronicity, and Quality

In the event that a message consumer desires to receive only certain messages based on some function of the message attributes, a message filtering scheme may be employed. Message filtering involves distinguishing between which messages should be delivered and which messages should not be delivered to a message consumer as a function of some filtering criteria. The filtering criteria are described in some language (for example, SQL) and can refer to attributes and values of a message. Thus, for example, you may subscribe to messages from a Stocks topic but filter out those messages whose StockSymbol attribute does not match the stock symbols in your stock portfolio.

Although various models of messaging exist, all messaging services share a common attribute of asynchronicity. Messages are sent by message producers to message consumers and do not require that the message producer block processing until the message is received. However, typical remote method invocation protocols, such as RMI and CORBA, implement calls by default such that the distributed client does block until the call completes (that is, synchronous calls). Asynchronous calls thus offer a certain level of time-independence for the message producers and consumers.

As we've already alluded, a message service can also provide a certain level of assurance associated with message delivery. Reliability and availability of message delivery provide a Quality of Service (QoS) that can often be specified at various levels. Mission-critical messages must have a higher QoS than lower-priority messages. Many messaging services provide a means to designate the QoS at the connection, message type, and individual message levels.

MOM

The terms Message-Oriented Middleware (MOM) and messaging service are nearly synonymous. MOM is simply an implementation of a messaging service, albeit in a fashion that is standard for a particular type of MOM system. A MOM API defines how distributed applications should utilize an underlying MOM message channel or queue for communicating messages to one another. Messages are passed between applications via MOM in a way that does not block the sender of that message. That is, the sender can send a message and allow the MOM to ensure that it gets to the intended receiver without waiting for a response from the receiver.

MOM implementations can implement one or more types of messaging models. For example, one MOM implementation may employ simple point-to-point messaging. Another MOM implementation may implement a more sophisticated publish-and-subscribe model, and perhaps provide a server to manage message queuing in a centralized fashion and using redundant middleware server processes for enhanced reliability and availability.

MOM has historically been so popular that various organizations have been created and have gotten involved in providing standardization of MOM approaches. However, different underlying MOM implementations still abound. Because MOM is such a core part of an enterprise application, the Java Message Service was defined to provide a standard MOM API for Java-based applications usable in a J2EE context. As you'll see in the next section, JMS provides a standard means for interfacing with messaging systems and thus implements a standard Java-based interface to MOM.