Understanding the Role of MSMQ in this Application

Unlike other, more direct methods of data transfer, MSMQ uses the idea of messages to transfer data and a queue to hold those messages. (A queue is a sort of mailbox for messages.) At a minimum, there's a queue on the server that holds all messages the server components process. Each active component on the server has a separate queue. These components pick up messages from their queue whenever processing on the current message is complete.

In addition to the server queue, some clients also have a queue for local processing. The local queue gets emptied into the server queue anytime there's a connection between the client and the server. In short, messages can be viewed as the packets that normally get carried between client and server on a network. Obviously, this is a simplification of a more complex process, but it helps to start with this perspective of the functioning of MSMQ and the messages that it uses.

The obvious advantage in using MSMQ is that you gain the ability to perform disconnected application handling. The local client queue allows the client to continue processing information even when there's no direct connection to the server for handling the messages. MSMQ handles all message transfers in the background without the user 's knowledge. Figure 9-1 shows the relationship between the client and server, and the kinds of queue setups you can expect.

Figure 9-1: MSMQ helps the user continue working even when no connection between the client and server exists.

Notice that there are actually two client types: dependent and independent. Most versions of Microsoft Windows will let you set MSMQ up for either type of operation. However, Microsoft Windows XP creates an independent client-you can't install MSMQ as a dependent client. The main difference between the two types is that the independent client provides its own queue in addition to using the server queue, while the dependent client relies solely on a direct connection to the server.

The two client types have different uses. Obviously, you can't use a dependent client setup for a laptop computer that you intend to use on the road because the dependent client lacks a queue. However, a dependent client setup works for a desktop machine that's located in the same building as a server or on a WAN with a reliable connection. Using a dependent-client setup reduces the disk requirements for using MSMQ and can result in a slight performance boost because the messages appear only in one queue rather than two.

Note 

The actual performance cost of using MSMQ varies by connection type, client capabilities, server load, and application design. Most developers find that the user doesn't even notice the use of the queue when connected to the server. The performance hit for using a queued application is extremely small. In fact, given that using MSMQ makes it possible to work in disconnected mode, most users are quite happy to have an MSMQ application installed on their system.

We'll discuss the various MSMQ components as the chapter progresses. However, you need to have a basic understanding of what these components do before we get started. As shown in Figure 9-1, three elements are required for establishing and maintaining a message flow between the client and server:

• Recorder

• Listener

• Player

The recorder accepts the client output, creates one or more messages based on the content of that output, and then places those messages in the local message or sends them to a proxy server on the server. The local copy of MSMQ accepts the message the client creates and sends it to the server. The server copy of MSMQ places the message in the server's queue. When the listener sees a message in the server's queue, it removes the message and gives it to the player. The listener is a configured part of MSMQ. It isn't something MSMQ provides automatically-you need to set up linkage between the listener and the player. Finally, the player receives the message, unpacks it, and turns it into data for the server. In some cases, the player has to perform data manipulation to get the data into a format that's acceptable to server-side applications.

Note 

The message format used by various versions of MSMQ varies. The latest version of MSMQ-the one we'll use in this chapter- relies on XML formatting. Earlier versions of MSMQ relied on a custom data format. This data format affects only the local message storage. Two systems that want to transmit data must agree on the transfer protocol. Consequently, the local data storage issue affects only how you view messages in the various utilities that we'll discuss.

You can look at this process as similar to that used by an answering machine in your home. When someone calls and finds that you're not home, he or she leaves a message by talking to the answering machine instead of talking to you directly. The answering machine stores the message by using any number of methods. When you get home, an indicator on the answering machine tells you that you have one or more messages. Pressing a button on the answering machine normally plays the messages back for you, allowing to you to determine who's called in your absence. As you can see, the idea of disconnected communication isn't new; MSMQ represents a new implementation of an existing idea.

Like COM+, MSMQ can create message traffic that relies on transactions. Generally, you'll use this feature when working with a database or other application that requires a high level of data integrity because transactions do incur a performance penalty. MSMQ applications use a minimum of three transactions for every data transmission, even if it appears that only one transaction occurs. The following list summarizes the transaction events:

• Moving the message between the client application and the local queue

• Moving the message from the local queue and placing it in the server queue

• Removing a message from the server queue and tracking the message's progress on the server

This three-transaction approach makes it a lot less likely that an update will fail due to communication problems, which, in turn , makes the application more reliable. In addition, because a special MSMQ transaction occurs when delivering data from the client to the server, you can be sure each message gets transmitted successfully at least one time.

Throughout this chapter, I'll address the topic of queues in several ways. It's important to know which queue to use for each application need. There are two kinds of queues supported by MSMQ: application and system.

The application queue is created automatically by the application or manually by the administrator. The application uses this kind of queue for messages, administration, reports , and responses.

MSMQ creates the system queues. There are two types: dead letter and journal. Dead letter queues store messages the application didn't or couldn't process within a specific timeframe. Journal queues contain messages that reflect application, MSMQ, or system events.

Queues can also be public or private. Public queues are available for anyone to use, and the MSMQ Information Service (MQIS) tracks them. Applications normally use private queues for one-to-one communications such as a response from a server on a client machine. You'll learn more about these queues as the chapter progresses.