Page #100 (Chapter 9. Message Queuing)

< BACK  NEXT >

[oR]

Message-Based Queuing

The idea behind message-based queuing is very simple. As shown in Figure 9.1, a queue manager maintains a number of queues and provides the ability to create or delete queues (1). A queue stores messages addressed to it (2). An application builds a message and sends it to a specific queue (3). Some other part of the application (or some other application) can then read the message and remove it from the queue (4). If needed, this reader can respond by sending another type of message to some queue (5) that the original sender (or somebody else) can read (6).

Figure 9.1. Basic message-based queuing.

The queue manager, the sender, and the receiver may all be on different machines.

As the messages flow through a separate process (the queue manager), the receiver need not be online when the messages are sent. Likewise, when the messages are being received, the sender need not be online.

What kind of data can be passed in the message?

A message is a flexible way for two applications to exchange information. The contents of the message are not fixed; a sender can send any kind of data. However, in order for the receiving application to interpret the data, the sender and the receiver must agree on the format of the message.

The Need for Queuing

Why do we need message queuing?

Consider the case when component A is communicating with another component, B, that is installed on a remote machine. Based on some user action, A sends some data to B via some interface method.

If the remote machine is unreachable (for example, if the network is down) or if the remote machine has been shut down, the interface method call will fail. To address such situations, some applications prefer storing the data locally and sending it to the remote machine whenever the machine is up and online. For such applications, it is acceptable if the data is not transferred immediately, as long as it is done soon enough.

A separate queue manager can be used to provide this asynchronous mode of operation. Component A would then send the data to the queue manager and let the queue manager worry about storing the data and deal with any network connectivity issues.

Using a separate queue manager also addresses issues related to performance and scalability. When a client makes an interface method call, the call may take considerable time to execute, even if the server resides on the local machine. Meanwhile, the caller is blocked. As a result, other users trying to access the caller lose responsiveness (and patience). Recall the frustration you went through when the NASDAQ was down by more than 100 points and you were desperately trying to sell the stocks you owned but your brokerage system was just not responding.

Message queuing doesn t just solve the problem of a server not being online; the clients can be offline and still do some work. For example, a salesman who is on the road can enter a sales order on his laptop that is not connected to the corporate network at that time. He can later connect to the server to process the data generated during the offline operation.

Consequently, if you wish to develop an enterprise application that is scalable, responsive, and requires that all the participants need not run at the same time, you will need to use some form of message queuing.

Why Use MSMQ?

One can certainly write code to handle asynchronous communication to take care of cases when the remote machine is not reachable, perhaps by storing the data in a local database and then pushing it to the remote machine when it comes back online. However, wouldn t it be better if someone else provides this infrastructure so that you can focus on your business needs? MSMQ provides this infrastructure.

MSMQ, however, goes far beyond queuing messages. It provides a broad range of features for message-oriented applications:

1. The MSMQ architecture provides a unifying way to organize computers across a large enterprise. It groups machines in physical proximity and offers a cost-based message routing between the groups, resulting in highly scalable networking.

2. MSMQ offers exceptional security features. It is completely integrated with the Windows 2000 security environment and permits access control to be enforced on all the operations. Message senders can be authenticated to the receivers. Furthermore, messages can be encrypted for transmission across the network.

3. MSMQ provides auditing on all the operational activities.

4. For important messages, MSMQ provides guaranteed delivery.

5. MSMQ provides built-in transaction support and is completely integrated with the COM+ transaction service.

6. The architecture enables connectors to be built. A connector makes it possible to communicate with foreign (non-Windows) systems such as IBM s MQSeries and other message queuing products.

7. The data transport mechanism is very efficient. As a matter of fact, the performance difference between MSMQ and RPC is insignificant.

8. And most importantly it provides easy-to-use COM components. ^[1]

   ^[1] MSMQ also provides a rich set of C language APIs. Our focus is on the COM components, however.

< BACK  NEXT >