Processing Orders with Messages

Team Fly

Page 373

As you can understand, not all operations can be placed into a transaction. If you're sending a message to a remote queue, you probably don't want to wait for the message to arrive at the destination queue (let alone be processed) before you commit the transaction. This is simply a limitation of loosely coupled systems. Message transactions are not the same as database transactions. However, there are mechanisms to ensure the integrity of messages, such as acknowledgments. In the following section we're going to learn yet another mechanism for message integrity—how to keep copies of the sent messages and process them again if they can't be delivered.

AUDITING MESSAGES

Transactions are invaluable in designing robust systems. Another technique, perhaps not as valuable but very useful, is the logging of messages. In addition to sending a message, you can create a copy of it and send it to a designated queue. If everything else fails, you can at least recover the message that wasn't delivered (or processed) and repeat it. Under each queue in the MSMQ snap-in there are two items: the Queue Messages item, where incoming messages are stored, and the Journal Queue, where MSMQ keeps copies of the outgoing messages. In effect, journal queues are equivalent to acknowledgment queues, in the sense that they keep track of the movement of the messages in a specific queue.

Messages are not copied to the corresponding journal queue by default. To create copies of the messages sent to a specific queue, set the UseJournalQueue property of the MessageQueue object that represents the queue to True. Every message sent to this queue will be copied into its journal queue. Earlier in the chapter we showed you how to retrieve acknowledgment messages from a queue and take appropriate action. A more robust technique is based on a combination of acknowledgment and journal queues. Let's assume that certain messages, such as messages about orders, must be processed within an interval of a few hours to a few days. If the message regarding an order isn't retrieved from its queue within the specified interval, a negative acknowledgment is sent to an acknowledgment queue (the acknowledgment message won't be sent unless the sending application has requested message acknowledgment). In addition, the sending application should also send copies of the messages into a journal queue. Another application can continuously remove messages from the acknowledgment queue (presumably, there won't be many messages in this queue) and retrieve their IDs. For every message that failed to be delivered (or retrieved from its queue), the application can retrieve the associated message from the journal queue and resend it. Alternatively, you can send it to a different queue, or log an error message. You can even send a mail message to an operator at the site that fails to read the messages. The most common scenario for message delivery failures is that the destination queue has been moved to another computer, or the user privileges on the remote computer have been altered.

MSMQ won't remove messages from the journal queues. Instead, you must write code to retrieve the messages of a journal queue using the techniques discussed earlier in this chapter.

Processing Orders with Messages

As you have realized by now, working with queues is fairly straightforward. In this section we'll put together all the information presented so far in the chapter to build a practical application that uses the MSMQ component. This section's example consists of a client application that takes orders and submits them to a specific queue and a server application that retrieves orders from the queue and

Team Fly