Understanding Microsoft Message Queuing

[Previous] [Next]

As more and more business operations become dependent on computers, networks, and online databases to function, limitations on how conventional software works are increasingly apparent. For example, physicians in remote areas transmitting information to a medical center need to send and receive extremely crucial information over reliable communications channels. A mortgage brokerage needs to receive loan applications through the Internet, process them into a database, and automatically request credit reports and other information that will come from different sources at different times.

Overall, customer service requirements are forcing companies to look at integrating several existing applications in order to present a single, near-real-time view of the customer and his or her relationship to the company, often through the Web. Many events have to go on at once, and all events have to be secure and reliable while traveling over channels whose performance may be inconsistent. To fulfill these needs, a solution must meet the following three technical requirements:

• Applications must not need to know about each other's communication protocols, implementation details, or data organization in order to communicate.
• Sending applications may run at different times and thus must be able to send data asynchronously and move on to other work without waiting to connect to some receiving application.
• Data must not be lost, garbled, duplicated, or exposed to security risks even when transported over networks that do not provide these protections inherently.

In addition to integration, which takes the form of back-and-forth communication between applications, many companies want to make applications that are aware of each other's business events. A business event is an event in an application, such as a change of address, that may be of interest to another application but that doesn't require an answer from that application. Of course, in addition to technology requirements, the usual needs for solutions to be cost-effective, simple to use, and easy to integrate into existing systems must be met.

Microsoft Message Queuing, included as part of Windows 2000 Server, is an important technology in the construction of these solutions. Message Queuing is a developer's environment and, as such, is beyond the scope of this book. However, information on the uses of Message Queuing may help you decide what purposes it might serve in your particular enterprise.

What the Message Queue Does

Most distributed applications are built using synchronous communication technologies, such as remote procedure calls and remote data access. Synchronous communication works like a telephone call. You place a call to someone, he or she answers, and you can have a quick and usually efficient exchange of information. The problem arises when the person at the other end of the call doesn't answer. You must keep redialing at regular intervals until you get an answer—not quick and not efficient.

If the person at the other end of the phone line has voice mail, the communication becomes asynchronous. You can leave your message with some assurance that the other party will eventually retrieve the message and take appropriate action. In the meantime, you can get on with other tasks without having to interrupt them to repeatedly redial the phone.

Message Queuing implements asynchronous communications by enabling applications to exchange messages whether the applications are running at the same time or at different times. The applications can be on the same machine or on different machines on a network. The messages can contain data in any format that's understood by the sender and the receiver. When an application receives a request message, it reads the contents of the message and acts accordingly. The receiving application can send a response to the requesting application if that's desirable.

While the messages are in transit between senders and receivers, they are kept in waiting areas called queues, which is where the technology got its name. The queues protect messages from being lost and provide a central place for receivers to look for messages when they are ready. Applications make requests by sending messages to queues associated with the intended receiver. If a response is expected, the sender includes the name of a response queue (that the sender creates in advance) in the requests made to the receiver.