It may be helpful to look at a few business examples of where message queuing can be used to provide a more effective application. Remember, not every application is suitable for message queuing. In fact, used in the wrong place for the wrong application, message queuing can sometimes cause more harm than good. Based on the guidelines that were outlined in the last section, let's look at some business cases as see how message queuing can be applied there.
Let's say you have an organization that relies on a group of mobile sales personnel. These sales personnel both present the products of the company to prospective buyers and generate orders based of what the buyer wants. In this business, it is critical for the sales person to have up-to-date information about the products that are available to sell. It is also critical for them to be able to show the products and generate orders without having to connect their laptop to a phone line. By now, you should see at least two applications for message queuing.
For the first application, the home office can produce updates and additions to the sales catalog application. These changes can then be routed to the individual sales personnel through a message queue. The message queuing system will hold these messages until the user connects their computer to the network. At that time the message queuing manager on the salesperson's computer will receive those messages that are waiting for it on the central queuing manager. The messages will then be delivered to the catalog application on the user's computer, which will process the updates contained in the messages.
A similar scenario, yet flowing in reverse, will allow the salesman to write orders on their laptop. The sales orders will be packaged as messages and held by the local machine's queue manager. When the queue manager can again communicate with the other queues in the company, it can send these messages on their way to the order-processing queue. By marking these messages as recoverable, they are guaranteed to be delivered even if one of the systems in between has a failure. The message queuing system can automatically provide the acknowledgment that the message successfully arrived at the destination.
Another example, which we will look at in greater detail at the end of the chapter, is the use of message queuing in a web application. If you think about each web page or set of web pages that a user may access as an application, then an easy way to pass information from one application to another is through queuing. ASP currently has technologies that permit communication between pages in the same web application, through the use of the
object. But what if the communication needs to be between two separate web applications? In the case study that we have been looking at for the past few chapters, we have shown the client end of a bookstore application. But what happens after the consumer decides they want to buy? Well, an order has to be generated. There are people who need to know about the order so they can pull the books in the order from inventory. Others who will need to package the books for shipment. There may also be a way for the author to be notified that someone has purchased one of his or her books.Session
Since we are working in the web world, there is no concept of a continually running shipping or author-notification application. Each of these applications will be run when the interested party accesses the web page that corresponds to that application. So what is the best way to connect applications that may not be running at the same time? Yes, this is another example of where message queuing can be used. At the end of the chapter, we will look at how the placing of the order will generate an order list that can be created when the stock clerk runs his application. We will also look at how the author can find out which books were purchased, and by whom. But first, lets spend a little time looking at the system that will actually run all of this: Microsoft Message Queue Server.