Enterprise messaging is not a new concept. Messaging products such as IBM WebSphere MQ, SonicMQ, Microsoft Message Queuing (MSMQ), and TIBCO Rendezvous have been in existence for many years. Recently, several open source messaging products such as ActiveMQ have entered the market and are being used in enterprise production environments. Also, the introduction of Service-Oriented Architecture (SOA) has given rise to a new type of messaging product known as an Enterprise Service Bus (ESB). Although most ESBs allow for HTTP-based communications, messaging-based communication continues to remain the standard in most production enterprise systems.
A key concept of enterprise messaging is that messages are delivered asynchronously from one system to others over a network. To deliver a message asynchronously means the sender is not required to wait for the message to be received or handled by the recipient; it is free to send the message and continue processing. Asynchronous messages are treated as autonomous units—each message is self-contained and carries all of the data and state needed by the business logic that processes it.
In asynchronous messaging, applications use a simple API to construct a message, then hand it off to the Message-Oriented Middleware for delivery to one or more intended recipients (see Figure 1-1). A message is a package of business data that is sent from one application to another over the network. The message should be self-describing in that it should contain all the necessary context to allow the recipients to carry out their work independently.
Message-Oriented Middleware architectures of today vary in their implementation. The spectrum ranges from a centralized architecture that depends on a message server to perform routing, to a decentralized architecture that distributes the “server” processing out to the client machines. A varied array of protocols including TCP/IP, HTTP, SSL, and IP multicast are employed at the network transport layer. Some messaging products use a hybrid of both approaches, depending on the usage model.
It is important to explain what we mean by the term client. Messaging systems are composed of messaging clients and some kind of messaging middleware server. The clients send messages to the messaging server, which then distributes those messages to other clients. The client is a business application or component that is using the messaging API (in our case, JMS).
Enterprise messaging systems that use a centralized architecture rely on a message server. A message server, also called a message router or broker, is responsible for delivering messages from one messaging client to other messaging clients. The message server decouples a sending client from other receiving clients. Clients see only the messaging server, not other clients, which allows clients to be added and removed without affecting the system as a whole.
Typically, a centralized architecture uses a hub-and-spoke topology. In a simple case, there is a centralized message server and all clients connect to it. As shown in Figure 1-2, the hub-and-spoke architecture lends itself to a minimal amount of network connections while still allowing any part of the system to communicate with any other part of the system.
In practice, the centralized message server may be a cluster of distributed servers operating as a logical unit.
All decentralized architectures currently use IP multicast at the network level. A messaging system based on multicasting has no centralized server. Some of the server functionality (persistence, transactions, security) is embedded as a local part of the client, while message routing is delegated to the network layer by using the IP multicast protocol.
IP multicast allows applications to join one or more IP multicast groups; each group uses an IP network address that will redistribute any messages it receives to all members in its group. In this way, applications can send messages to an IP multicast address and expect the network layer to redistribute the messages appropriately (see Figure 1-3). Unlike a centralized architecture, a distributed architecture doesn’t require a server for the purposes of routing messages—the network handles routing automatically. However, other server-like functionality is still required to be included with each client, such as message persistence and message delivery semantics like once-and-only-once delivery.
A decentralized architecture usually implies that an IP multicast protocol is being used. A centralized architecture usually implies that the TCP/IP protocol is the basis for communication between the various components. A messaging vendor’s architecture may also combine the two approaches. Clients may connect to a daemon process using TCP/IP, which in turn communicates with other daemon processes using IP multicast groups.
Both ends of the decentralized and centralized architecture spectrum have their place in enterprise messaging. The advantages and disadvantages of distributed versus centralized architectures are discussed in more detail in Chapter 10. In the meantime, we need a common model for discussing other aspects of enterprise messaging. To simplify discussions, this book uses a centralized architecture as a logical view of enterprise messaging. This is for convenience only and is not an endorsement of centralized over decentralized architectures. The term message server is frequently used in this book to refer to the underlying architecture that is responsible for routing and distributing messages. In centralized architectures, the message server is a middleware server or cluster of servers. In decentralized architectures, the server refers to the local server-like facilities of the client.
Get Java Message Service, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
