An Overview of the JMS Architecture and Messaging
| The first step in understanding JMS from a programming or administration perspective is becoming familiar with the architecture of a simple JMS application. As illustrated in Figure 15.1, a simple JMS application is comprised of the following components and messaging concepts: Figure 15.1. The high-level architecture of a JMS application.
JMS provides client interfaces tailored for each of these messaging domains. Note Non-JMS clients are programs that use a messaging product's native client API instead of the JMS API. If the application predated the availability of the JMS API, it is likely to include both JMS and non-JMS clients. Messaging DomainsMessaging systems are divided into two categories or domains. These are the Point-to-Point (PTP) and Publish/Subscribe (Pub/Sub) domains. The JMS specification does not require JMS providers to support both messaging domains. However, WebLogic Server, and most competing products, implement both. Note Before the JMS API existed, most messaging products supported either the point-to-point or the publish/subscribe approach to messaging. The Point-to-Point Messaging DomainThe defining concept in the point to point domain is the message queue. Producers send messages to a queue, which serializes the messages into a linear order. Hence, when consumers receive messages from the queue, the messages are taken in a first-in, first-out (FIFO) order, as illustrated in Figure 15.2. Every message in the queue is associated with a single producer and more importantly, a single consumer. However, multiple producers and consumers can share a single message queue. Queues have the added advantage of holding messages until they are consumed. Many applications use message queues as a way of deferring certain non-essential or time-consuming tasks (like logging) to be handled when resources are available. Figure 15.2. The characteristics of a point-to-point messaging domain. The JMS API does not define how queues are created or managed. In WebLogic Server, developers and administrators use the WebLogic Administration Console to create, manage, and configure message queues. Administrators will normally create and configure queues and developers will write clients that access them. The Publish/Subscribe Messaging DomainIn the Publish/Subscribe domain the topic is the analog of the queue. Message producers publish messages to a topic and multiple consumers (called subscribers ) receive messages from the topic, as illustrated in Figure 15.3. Figure 15.3. The characteristics of the publish/subscribe messaging domain. Note Having publishers publish to a topic instead of a list of subscribers ”and the anonymity between publishers and subscribers ”decouples the publishers and subscribers. Topics retain messages for as long as it takes to distribute them. However, there is a timing dependency between publishers and subscribers, where a topic can only consume messages after a client has created a subscription to that topic, and the subscriber must be active in order for it to consume messages. The JMS API relaxes this timing dependency by enabling clients to create durable subscribers, which guarantees messages will be delivered to them, even if the subscribers are inactive for a period. When a disconnected durable subscriber comes back online, the topic delivers all the waiting messages to that durable subscriber. Hence, when all messages for a topic must be received, a durable subscriber should be used. If missed messages are tolerable, non-durable subscribers should be used. Note Support for durable subscribers is applicable only to the Pub/Sub messaging domain. A stock ticker application is an example of a scenario where pub/sub messaging domain would be applicable, as a topic can be created for each stock. When the price of the stock changes, the new price is reflected in the topic. The MOM would at this point be responsible for broadcasting the stock price (message) to the connected subscribers to that specific topic (stock). In some non “JMS-based broadcast messaging systems, subscribers receive all messages within the system. The client then has to implement some sort of filtering solution. In fact it is often the case that every client must filter out important messages from noise. The problem with such a system is twofold. First, every client must do this filtering. Second, the message server has to deliver messages to clients who will eventually filter them out. This wasted effort has tremendous performance implications. JMS enables message consumers to register a message selector with the JMS provider, which defines filtering logic indicating which messages will be delivered to the consuming client. Importantly, this filtering is performed by the JMS provider and not by the client. Therefore the server does not have to send any unnecessary messages. Note Message selectors are not specific to the publish/subscribe domain. Messaging Consumption and DeliveryJMS message consumption occurs in one of two ways:
JMS message delivery covers a range of once-and-only-once to at-least-once delivery. In the once-and-only-once delivery mode, a message is guaranteed by the JMS provider to arrive at the intended destination, and it is sent once. To implement a guaranteed delivery, the JMS provider uses a store-and-forward mechanism and rigidly defined message acknowledgments. Note The store-and-forward mechanism is implemented by a JMS provider using a persistent backing store (file or JDBC database). In the at-least-once delivery mode, the JMS provider is permitted to lose a message once in a while. An example of an at-least-once delivery mode is the broadcast of stock price information, where if a message does not reach its intended destination, another message will be sent quickly. This type of delivery mode typically uses non-persistent messages, which are stored in the memory of the JMS provider and are guaranteed to be delivered at least once unless there is a system failure. If a connection is closed or recovered, all non-persistent messages that have not yet been acknowledged will be redelivered. Once a non-persistent message is acknowledged , it will not be redelivered. Messaging Domain InterfacesThe JMS API defines several interfaces that message servers must implement to support the two messaging domains. Client applications will interact with the server using these interfaces. Each interface has two forms to support the PTP and Pub/Sub domains. Table 15.1 shows the base interface and the specialized versions for the two domains. Table 15.1. JMS Interfaces for PTP and Pub/Sub Domains
 |
EAN: 2147483647
Pages: 360