Messaging Overview

Before we can understand "messaging," we must define a "message." Although no generally accepted definition exists, in the context of our XML discussion we can define a message as a self-contained unit of information. A message usually has a header, which contains control information about the message. Examples of control information are routing, authentication, and transactional data. A message also has a body, which contains the actual content of the message.

Messaging, therefore, is the process of passing messages between applications over a network using a transport protocol to perform a particular function.

The Beginnings of Messaging

Traditionally the term "messaging system" was often used to refer to a type of middleware system known as Message-Oriented Middleware (MOM). Common examples of MOM systems include Microsoft Message Queue Server (MMQS), IBM MQSeries, and Tibco Rendezvous. Among other features, MOM systems allow applications to exchange messages asynchronously so that the caller (the client) doesn't need to wait while the called application (the server) completes the request. Today messaging does not necessarily mean that a MOM system is being used to exchange and manage the messages. It doesn't even have to mean that you're sending messages asynchronously. Instead, messaging can be either synchronous or asynchronous, and MOM systems can be regarded as a special type of transport protocol used to enable messaging. Other common transport protocols used for messaging include HTTP and SMTP.

The Need for Messaging

To better understand the need for messaging, we will compare it to another distributed computing paradigm that has enjoyed widespread adoption: the Remote Procedure Call (RPC) paradigm. RPC today forms the basis for almost all distributed computing platforms, such as DCOM, CORBA, and Java RMI. RPC provides applications with the ability to make function calls across the network. (See the "The RPC Mechanism" sidebar.) By comparing these two paradigms you will get a better idea of the advantages and disadvantages of messaging as a distributed computing paradigm.

Messaging systems usually have little infrastructure because, in contrast to RPC, messaging generally does not support marshaling,unmarshaling and function invocation. Messages are transferred as they are, and messaging software makes no assumption about the structure of these messages. Applications using messaging must parse their own messages and invoke the appropriate functions to handle them. The only contract in a message-oriented system is that the client and server should agree about the format of the messages exchanged. In fact, several messages can be used together to invoke a given function. Messaging systems are, therefore, more loosely coupled than RPC systems because the client is more independent of the server. In addition, messaging systems can often support complex and flexible message formats such as hierarchical and binary data. RPC systems, however, generally support only common programming language data types such as integer, double, string, and sometimes array.

Because the RPC paradigm requires an infrastructure to handle the marshaling,unmarshaling, and function-invocation services, it is usually tied to a specific transport protocol. Messaging, on the other hand, can generally be transport-protocol independent. Still, using RPC is usually easier because it handles all the data packaging and method invocations for you. Messaging is useful when you need every last ounce of performance or your messages cannot be easily represented as method parameters. Table 7-1 summarizes the differences between message-oriented and RPC-oriented systems.

Table 7-1 Message-Oriented vs. RPC-Oriented Systems

Feature	Messaging	RPC
Coupling between client and server	Loose	Tight
Possible data structures	Complex, including hierarchical	Limited to common programming language data types such as integer and string
Implementation	Relatively difficult	Easy
Programming language	Independent	Tied to a set of programming language
Transport protocol	Can be bound to different transport protocols	Usually bound to a particular protocol

Messaging systems shine in situations where it would be difficult for both the caller and called parties to agree on a common function interface and operating platform. For example, two companies communicating over the Internet might have different business systems and might not want to use the same programming languages. In addition, they might prefer to communicate asynchronously so that neither will depend on the other's application being up and running.

Features of MOM Systems

Most MOM systems support guaranteed delivery of messages using a store-and-forward mechanism. Delivery is usually achieved by writing the incoming messages out to persistent queued storage. This mechanism will then deliver all the messages to the recipient when it becomes available. MOM systems usually provide two types of messaging models as well. One is point-to-point queuing and the other is referred to as publish-and-subscribe.

In the point-to-point messaging model messages are sent, through a given queue, from a sender to a single intended recipient or a group of recipients. When the recipient is a group, only one recipient in the group can consume each message. The MOM system ensures that each message is consumed only once by the next available recipient in the group.

In a publish-and-subscribe message model a sender can broadcast a message through a virtual channel to one group of recipients or more. MOM systems usually provide other enterprise-level features such as redundancy, load balancing, and transaction support.

Most mature organizations have legacy and new applications that have been implemented independently and cannot easily interoperate. Integrating these systems is called Enterprise Application Integration (EAI), and a MOM system is usually central to achieving integration. MOM systems can be used to help exchange and coordinate the data and events communicated between these systems in the form of messages, while letting the systems remain independent, both physically and architecturally.

MOM systems are also considered central to Business-to-Business (B2B) solutions because they allow organizations to cooperate without requiring them to have the same systems or to tightly integrate their systems through proprietary software.

The RPC Mechanism

RPC uses a request-and-reply communication model to allow a client application to invoke functions exposed by a remote server application that is listening for these requests. As far as the programmer is concerned, the remote invocation is similar to invoking an ordinary local function. The RPC Run-time System (RTS) providing the RPC mechanism handles all the underlying communication to make details look simple to the application programmer.

An RPC mechanism has two aspects: definition and execution. The definition, called the interface definition, is done before the RPC is actually made. It includes describing the function, its arguments, and the return value, including the associated data types. The format, or grammar, of this definition is called the Interface Definition Language (IDL). IDL is used to generate a piece of software called a stub or proxy that is linked to both the RPC client and server.

The execution starts when the client makes an RPC request. The stub linked to the client intercepts the request and redirects it to the client-side RTS. This RTS packages the arguments in a form suitable for transmission over a network. This process is known as marshaling. The client-side RTS then locates and invokes the server-side RTS that, in turn, invokes the appropriate server stub. The server stub performs the operations complementary to those of the client stub: unmarshaling the parameters passed to the function, calling the function, and marshaling the return parameters. This whole process is depicted in Figure 7-1.

Figure 7-1 Interaction of the RPC components.