|
| |
| Sun Java System Message Queue 3 2005Q1 Technical Overview | |
Chapter 1
Conceptual FoundationsSun Java™ System Message Queue (Message Queue) provides reliable, asynchronous messaging that can integrate distributed applications and components across an enterprise. Processes running on different platforms and operating systems can connect to the service to interact with each other.
Message Queue is a standards-based messaging solution that implements the Java™ Message Service (JMS) open standard. In addition, Message Queue provides the interoperability, security, scalability, availability, manageability, and other features required by large-scale enterprise deployments.
This chapter provides the conceptual foundation for Message Queue. It covers the following topics:
If you are already familiar with JMS concepts and terminology, you can skip to Chapter 2, "Introduction to Message Queue."
Enterprise Messaging SystemsEnterprise messaging systems enable independent distributed applications or application components to interact through messages. These components, whether on the same host, the same network, or loosely connected through the Internet, use messaging to pass data and to coordinate their respective functions.
For large numbers of components to be able to exchange messages simultaneously and to support high density throughputs, the sending of a message cannot depend upon the readiness of the consumer to receive it. If a message consumer is busy or offline, the system must allow for a message to be received when the consumer is ready. This de-coupling of the sending and receiving of a message is known as asynchronous message delivery.
The asynchronous messaging model lends itself extremely well to the task of integrating complex systems, where it is neither feasible nor desirable for one component to hold up another in the process of doing work. While asynchronous messaging gives up some of the control that synchronous systems allow, it adds great flexibility to the interplay of components. It also adds robustness, inasmuch as the failure of one component does not translate into the failure of the whole.
Requirements of Enterprise Messaging Systems
Enterprise application systems typically consist of large numbers of distributed components exchanging many thousands of messages in round-the-clock, mission-critical operations. To support such systems, in addition to supporting asynchronous messaging, an enterprise messaging system must meet the following requirements:
Reliable delivery. Messages from one component to another must not be lost due to network or system failure. This means the system must be able to guarantee message delivery.
Security. The messaging system must support basic security features: authentication of users, authorized access to messages and resources, and over-the-wire encryption.
Scalability. The messaging system must be able to accommodate increasing loads—increasing numbers of users and increasing numbers of messages—without a substantial loss of performance or message throughput. As businesses and applications expand, this becomes an important requirement.
Availability. The messaging system must function with very little down time. This means that when failures occur, the system contains enough redundancy to continue to provide messaging services.
Manageability. The messaging system must provide tools for monitoring and managing message delivery. An administrator must be able to optimize system resources and to tune system performance.
Centralized (MOM) Messaging
Message Queue uses a centralized messaging system, as shown in Figure 1-1. In such a system, each messaging component maintains a connection to one central message service. Components interact with the message service through a well-defined interface.
An alternative peer-to-peer system, in which every messaging component maintains a connection to every other component, is illustrated in the left of the figure. A peer-to-peer system allows for fast, secure, and reliable delivery; however, the code for supporting reliability and security must reside in each component. The sending and receiving of a message are closely coupled, making asynchronous delivery hard to achieve. As components are added to the system, the number of connections rises geometrically, so the system scales poorly. Centralized management is also problematic in a peer-to-peer system.
Figure 1-1 Centralized vs. Peer-to-peer Messaging
In the centralized system, the preferred approach for enterprise messaging, the message service provides for routing and delivery of messages between components, and is responsible for reliable delivery and security. Because components in this system are loosely coupled, asynchronous messaging is easier to achieve.
As messaging components are added to the system, the number of connections rises linearly, making it easy to scale the system by scaling the message service. In addition to connecting messaging clients, a central message service also provides an administrative interface that can be used to configure behavior, monitor performance, and tune the service to satisfy the needs of each messaging client.
Basic Message Service Architecture
The basic architecture of a centralized messaging system is illustrated in Figure 1-2. It consists of message producers and message consumers that exchange messages by way of a common message service. Any number of message producers and consumers can reside in the same messaging component (or application).
A message producer uses the message service programming API to send a message to the message server. The message server routes and delivers the message to one or more message consumers that have registered an interest in the message. A consumer uses the message service programming API to receive messages. The message service is responsible for guaranteeing delivery of the message to all appropriate consumers.
Figure 1-2 Message Service Architecture
Perhaps the best metaphor for this process is that of exchanging mail: Although a piece of mail is addressed to its eventual receiver, the mail is routed through the post office, resting in several intermediate locations before its recipient retrieves it from the mailbox.
Java Message Service (JMS) BasicsMessage Queue is an enterprise messaging system that implements the Java Message Service (JMS) open standard: it is a JMS provider. JMS concepts are therefore fundamental to understanding how the Message Queue service works.
The JMS specification prescribes a set of rules and semantics that govern reliable, asynchronous messaging. The specification defines a message structure, a programming model, and an API.
This section explains JMS concepts and terminology needed to understand the remaining chapters of this book. It covers the following topics:
JMS Message Structure
In Message Queue data is exchanged using JMS messages. According to the JMS specification, a message, created by a producing client, is composed of three parts: a header, properties, and a body.
Header
A header is required of every JMS message. Header fields contain values used for routing and identifying messages.
The header values can be set in a number of ways:
For information about the header fields defined by JMS, see the Message Queue Developer’s Guide for Java Clients or the Message Queue Developer’s Guide for C Clients. These header fields allow you to define the destination of the message, the time of expiration, its priority, and so on.
Properties
A message can include optional header fields, called properties. They are specified as property name and property value pairs. Properties, which can be thought of as extensions of the message header, might include information about which process created the data, the time it was created, and the structure of each piece of data. The JMS provider might also add properties that affect the processing of the message, such as whether it should be compressed or how it should be discarded at end of life.
The JMS provider can use message properties as selectors to sort and route messages. A producing client can place application-specific properties in the message, and a consuming client can choose to receive only messages whose properties have particular values. For instance, a consuming client might indicate an interest only for payroll messages concerning part-time employees located in New Jersey. Messages that do not meet the specified selection criteria are not delivered to the client.
Selectors simplify the work of consuming clients and eliminate the overhead of delivering messages to clients that don’t want them. However, they add some overhead to the message service, which has to process the selection criteria. Message selector syntax and semantics are outlined in the JMS specification.
Message Body Types
The type of a JMS message determines the contents of its body, as specified in Table 1-1.
JMS Programming Model
The JMS programming model supports the architecture of an asynchronous messaging service: JMS clients exchange messages by way of a JMS message service. A JMS provider furnishes the objects needed to carry out JMS messaging; these objects implement the JMS application programming interface (API).
This section describes the programming objects needed for JMS messaging and introduces the delivery models (point-to-point and publish/subscribe) used to send and receive messages.
Programming Objects
The objects used to set up a JMS client for delivery of messages are shown in Figure 1-3.
Figure 1-3 JMS Programming Objects
In the JMS programming model, a JMS client uses a connection factory object (ConnectionFactory) to create a connection over which messages are sent to and received from a JMS message server. A connection object (Connection) represents a client’s active connection to the message server.
Both allocation of communication resources and authentication of the client take place when a connection is created. It is a relatively heavyweight object, and most clients do all their messaging with a single connection.
The connection is used to create session objects (Session). A session is a single-threaded context for producing and consuming messages. It is used to create messages as well as the message producers and consumers that send and receive them, and it defines a serial order for the messages it delivers. A session supports reliable delivery through a number of acknowledgement options or through transactions.
A client uses a message producer object (MessageProducer) to send messages to a specified physical destination, represented in the API by a destination object. The message producer can specify default message header values, such as delivery mode (persistent vs. non-persistent), priority, and time-to-live, that govern all messages sent by the producer to the physical destination.
Similarly, a client uses a message consumer object (MessageConsumer) to receive messages from a specified physical destination, represented in the API as a destination object. There are two types of destination, queue and topic, depending on the message delivery model.
A message consumer can use a message selector to have the message service deliver only those messages whose properties match specific selection criteria.
A message consumer can support either synchronous or asynchronous consumption of messages.
- Synchronous consumption means the consumer explicitly requests that a message be delivered and then consumes it.
- Asynchronous consumption means that the message is automatically delivered to a message listener object (MessageListener) that has been registered for the consumer. The client consumes a message when a session thread invokes the onMessage() method of the message listener object.
Programming Domains: Message Delivery Models
JMS supports two distinct message delivery models: point-to-point and publish/subscribe.
Point-to-point (Queue Destinations) A message is delivered from a producer to a single consumer. In this delivery model, the destination type is a queue. Messages are first delivered to the queue destination, then delivered from the queue, one at a time, to one of the consumers registered for the queue. Any number of producers can send messages to a queue destination, but each message is guaranteed to be delivered to—and successfully consumed by—only one consumer. If there are no consumers registered for a queue destination, the queue holds messages it receives, and delivers them when a consumer registers for the queue.
Publish/Subscribe (Topic Destinations) A message is delivered from a producer to any number of consumers. In this delivery model, the destination type is a topic. Messages are first delivered to the topic destination, then delivered to all active consumers that have subscribed to the topic. Any number of producers can send messages to a topic destination, and each message can be delivered to any number of subscribed consumers.
Topic destinations also support durable subscriptions. A durable subscription represents a consumer who is registered with the topic destination but who can be inactive when messages arrive in the destination. The consumer receives the message when it becomes active again. If there are no consumers registered for a topic destination, the topic only holds messages for inactive consumers with durable subscriptions.
These two message delivery models are handled using three sets of API objects—with slightly different semantics—representing different programming domains, as shown in Table 1-2.
Table 1-2 JMS Programming Domains and Objects
Base Type
(Unified Domain)Point-to-Point Domain
Publish/Subscribe Domain
Destination (Queue or Topic)1
Queue
Topic
ConnectionFactory
QueueConnectionFactory
TopicConnectionFactory
Connection
QueueConnection
TopicConnection
Session
QueueSession
TopicSession
MessageProducer
QueueSender
TopicPublisher
MessageConsumer
QueueReceiver
TopicSubscriber
1Depending on programming approach, you must specify a particular destination type.
The unified domain was introduced with JMS version 1.1. If you need to conform to the earlier 1.02b specification, you can use the domain-specific API. Using the domain-specific API also offers the advantage of a clean programming interface that prevents certain types of programming errors: for example, creating a durable subscriber for a queue destination. However, the domain-specific APIs have the disadvantage that you cannot combine point-to-point and publish/subscribe operations in the same transaction or in the same session. If you need to do that, you should choose the unified domain API.
The example applications included with the Message Queue product as well as many of the code examples in the Message Queue documentation use the separate programming domains.
Reliable Messaging
The delivery mode of a message can be set either to persistent or non-persistent; this mode governs the reliability of message delivery.
- Persistent messages. are guaranteed to be delivered and successfully consumed exactly once. Persistent messages are not lost in case of message service failure. Reliability is at a premium for such messages.
- Non-persistent messages are guaranteed to be delivered at most once. Non-persistent messages are lost in the case of a message service failure. Reliability is not a major concern for such messages.
There are two aspects of ensuring reliability in the case of persistent messages. One is to ensure, through the use of acknowledgments and transactions, that message production and consumption is successful. The other is to ensure, by placing messages in a persistent store, that the message service does not lose persistent messages before delivering them to consumers.
The following sections describe these two aspects of ensuring reliability.
Acknowledgements/Transactions
Reliable messaging depends on guaranteeing the successful delivery of persistent messages from a message producer to a physical destination on a message server and from that physical destination to a message consumer. This reliability can be achieved using either of two general mechanisms supported by a JMS session: acknowledgements or transactions. In the case of transactions, these can either be local or distributed (under the control of a distributed transaction manager).
Acknowledgements
Acknowledgements are messages sent between client and message service to ensure reliable delivery.
In the case of message production, the message service acknowledges that it has received delivery of a message, placed it in its destination and stored it persistently. The producer’s send() method blocks until the acknowledgement returns.
In the case of message consumption, the client acknowledges that it has received delivery of a message from a destination and consumed it, before the message service deletes the message from that destination. JMS specifies different acknowledgement modes that represent different degrees of reliability. In some of these modes, the client blocks waiting for the message server to confirm that it has deleted a message and therefore cannot redeliver the message.
Local Transactions
A session can be configured as transacted, in which case the production and/or consumption of one or more messages can be grouped into an atomic unit—a transaction. The JMS API provides methods for initiating, committing, or rolling back a transaction.
As messages are produced or consumed within a transaction, the message service tracks the various sends and receives, completing these operations only when the JMS client issues a call to commit the transaction. If a particular send or receive operation within the transaction fails, an exception is raised. The client code can handle the exception by ignoring it, retrying the operation, or rolling back the entire transaction. When a transaction is committed, all its operations are completed. When a transaction is rolled back, all successful operations are cancelled.
The scope of a local transaction is always a single session. That is, one or more producer or consumer operations performed in the context of a single session can be grouped into a single local transaction.
Since transactions span only a single session, you cannot have an end-to-end transaction encompassing both the production and consumption of a message. (In other words, the delivery of a message to a destination and the subsequent delivery of the message to a client cannot be placed in the same transaction.)
Distributed Transactions
The JMS specification also supports distributed transactions. That is, the production and consumption of messages can be part of a larger, distributed transaction that includes operations involving other resource managers, such as database systems. In distributed transactions, a distributed transaction manager tracks and manages operations performed by multiple resource managers (such as a message service and a database manager) using a two-phase commit protocol defined in the Java Transaction API (JTA), XA Resource API Specification. In the Java world, interaction between resource managers and a distributed transaction manager are described in the JTA specification.
Support for distributed transactions means that messaging clients can participate in distributed transactions through the XAResource interface defined by JTA. This interface defines a number of methods for implementing two-phase commit. While the API calls are made on the client side, the JMS message service tracks the various send and receive operations within the distributed transaction, tracks the transactional state, and completes the messaging operations only in coordination with a distributed transaction manager—provided by a Java Transaction Service (JTS).
As with local transactions, the client can handle exceptions by ignoring them, retrying operations, or rolling back an entire distributed transaction.
Persistent Storage
The other aspect of reliability is ensuring that a message service does not lose persistent messages before they are delivered to consumers. This means that when a persistent message reaches its physical destination, the message server must place it in a persistent data store. If the message server goes down for any reason, it can recover the message and deliver it to the appropriate consumers.
A message server must also persistently store durable subscriptions. Otherwise the message server, in case of failure, would not be able to deliver messages to durable subscribers who become active after a message has arrived in a topic destination.
Messaging applications that want to guarantee message delivery must specify messages as persistent and deliver them either to topic destinations with durable subscriptions or to queue destinations.
JMS Administered Objects
Two of the objects used in the JMS programming model, connection factories and destinations, can vary with a provider’s implementation of the JMS specification.
- The connection factory object is used to create connections whose behavior depends on the protocols and mechanisms used by the provider to deliver messages.
- The destination object is used to specify the name of physical destinations on the broker and depends on the specific naming conventions and capabilities of the physical destinations on the message server.
To allow providers maximum flexibility in defining these objects while allowing clients to be portable, the JMS specification defines administered objects (for connection factories and destinations) that encapsulate provider-specific information. These objects are created and configured by an administrator, stored in a JNDI namespace (object store), and accessed by clients through standard JNDI lookup code.
Administered objects allow JMS clients to use logical names to look up and reference provider-specific objects. In this way, client code does not need to know specific naming or addressing syntax or the configurable properties used by a provider. This makes the code provider-independent.
The section Administered Objects provides additional information about the administered objects used in Message Queue.
