Conceptually, Message Queuing is quite simple. Ordinary interaction with an object works like a telephone call: both the client and server participate in a real-time exchange of information. Calling a remote component or XML Web service is conceptually the same. Technically, an XML Web service call is an exchange of a request and response message. In the .NET way of thinking, these two steps are tightly bound together into a single operation. The proxy class sends a request message and stops to wait for a response message before execution can continue. This guarantees that a certain unit of time is always spent waiting for the server to complete its work. Messaging is more like sending a fax or an e-mail. A message is sent, and no response is returned (although one might be expected at a later time). The recipient is free to deal with the message immediately or ignore it entirely. The client continues independently, without being notified about the success of the operation or its outcome. However, some messaging services can provide features such as guaranteed delivery or message confirmation for critical tasks. Clearly, messaging is poorly suited to tasks in which the client needs an immediate answer. However, messaging is ideal in situations where the client just needs to trigger an action or submit a request. When used for this purpose, messaging is fast and efficient because no waiting is required. Messaging is also extremely scalable because an application can receive dozens of messages in an instant and set them all aside for later processing. The message recipient has the luxury of choosing how and when to deal with the received messages. In return, clients don't have to worry about being tied up waiting for a long call to complete if the server is already dealing with several other requests. Some ideal scenarios for messaging include the following:
|