Queues and Messages

Team Fly 

Page 342

delivered, MSMQ can generate an acknowledgment message to indicate that the delivery of the original message failed.

Consider an application that runs on a salesperson's portable machine. The salesperson should be able to record orders on the go, but can't assume a connection to a server at the company's headquarters. The orders should be uploaded to the company's server as soon as possible, so that they can be processed in a timely fashion. What we just described here is a loosely coupled system: the order-taking application on the portable computer and the server at the company work together, but they can't be connected at all times. Data is stored in the portable machine and is uploaded when the two computers are connected. One of the basic requirements of a loosely coupled system is that information be safely stored locally until the two systems are connected and can exchange information. Messaging is an excellent mechanism for moving information from one machine to another.

As you know, messages are an ideal mechanism for passing information between remote computers. You can also send messages to a queue on the same computer. A simple technique to develop multithreaded applications is to create messages that represent specific tasks and leave them on a queue, rather than process each task. Another application can retrieve the messages from the queue and perform the task described by each message. This type of application isn't really a multithreaded application, but it's an efficient mechanism for running tasks in the background while the front end is free to interact with the user, as long as the tasks need not communicate with one another. If the number of tasks exceeds the capacity of a single workstation, you can have multiple workstations process the messages in the queue.

Queues and Messages

A message queue is a structure for storing messages, much like a first in, first out (FIFO) queue. Messages are stored in the queue according to their priority and the time they arrived. Messages with the same priority are stored in the queue in chronological order (the order in which they're received) and are read in the same order. When you read a message, the oldest message in the queue will be returned. You can change the default order by setting the priority of the messages you write to the queue. Messages with higher priorities are read before messages with lower priorities, even if they haven't been in the queue as long. The order of the messages in the queue is determined by MSMQ and you can't change the order of the messages in a queue after their arrival.

The messages themselves are serialized objects. Although we can create simple text messages, we rarely do. We create one or more custom classes that represent physical entities (such as orders, products customers, and so on) and our messages are instances of these custom classes. The custom classes must be marked as serializable, so that MSMQ can serialize the corresponding objects either in binary or XML format. At the receiving end we read a Message object from the queue, cast it to the appropriate type, and process it in our application.

Unlike mail messages, queue messages have a well defined structure, which must be known to both the sending and receiving end. In effect, they're equivalent to the messages we exchange through our mail software, but meant to be understood and processed by applications, not humans. In the same sense, MSMQ is equivalent to a mail client that can send and receive messages. The queue, finally, is equivalent to a message store.

The process of passing messages between two machines (whether they're mail messages or MSMQ messages) is inherently asynchronous: the sending machine isn't blocked until the message

Team Fly 


Visual Basic  .NET Power Tools
Visual Basic .NET Power Tools
ISBN: 0782142427
EAN: 2147483647
Year: 2003
Pages: 178

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net