8.1. Messaging Architectures

Let's begin with a discussion of how one might send data between clients in an enterprise application. Consider the architecture shown in Figure 8-1. All clients are tightly coupled. This arrangement makes each client aware of other clients in a many-to-many relationship. In a Remote Procedure Call (RPC) environment (such as Java RMI), each business method represents a call which may be remote across a network. Because these calls are synchronous, the client's thread blocks and cannot proceed until the business method completes.

Tightly coupled RPC architectures can have problems. If one client goes down, the effect can easily ripple through the system and make other clients wait for their synchronous calls to complete (which may never happen). In general, most client failures will have an immediate impact on the system. Perhaps the biggest problem with this arrangement is that it is difficult to administer. All clients must be informed if you add or delete another client, and upgrades to the system affect each client separately.

Figure 8-2 shows a loosely coupled architecture where clients send messages asynchronously through a message server.This hub-and-spoke arrangement represents a more flexible architecture for many enterprise applications. Instead of sending data directly from one client to another, the data is sent to a destination managed by a message server. Although we show only a single message server here, the centralized server is often implemented as a cluster of fault-tolerant machines. If one of the servers goes down, another server in the cluster can continue to handle client requests. In an asynchronous architecture, clients communicate only with a message server. Each client, therefore, is decoupled from the other clients in the system.

Loosely coupled architectures with a centralized message server have several advantages. Clients only see the message server; hence, they can be added or removed with minimal impact to the system. Data sent from a client does not require an immediate response from another application. Guaranteed delivery is also possible with a store-and-forward mechanism. This means that the message server saves a message in persistent storage if it is intended for a client that is temporarily down or unavailable. When the intended client comes back up, the message server delivers the message data automatically.

There are many examples of systems that use a loosely coupled architecture with a central message server. A stock quote system, for example, could broadcast stock quotes as asynchronous messages to any client that wants to be informed periodically. In a Business-to-Business (B2B) system, messaging allows business subsystems (accounting, inventory, sales, etc.) to communicate with each other without having to be tightly integrated. And with the world-wide web, messaging offers a safe and secure way to transmit data around the globe.

Although decentralized architectures with different server protocols are certainly possible with enterprise messaging, we will focus on the Java Message Service (JMS) in this chapter. JMS is part of the J2EE platform and works well with the hub-and-spoke architecture that we've shown you. Although JMS is a big subject by itself, we'll present an overview of JMS, so that you'll understand how to use it with message-driven beans.