Message Queuing offers two main advantages to a distributed application:
We'll look at each of these features in turn, and see how we can take advantage of them in our applications.
Disparate System Communication
When we build an application under the DNA methodology, the interface, components and data store drivers will usually be talking to each other using COM and DCOM. If we need to communicate with a component or a system that doesn't support COM, we have a problem. Of course, this also applies the other way round. Message queuing provides a way for applications that run on a different operating system, or that live in a non-compatible environment, to talk to our applications.
It does this by providing a platform-independent system of storing and forwarding messages that can be interpreted by a different application. Rather than communicating directly through operating system and inter-process calls, both applications agree on a standard format for the data so that both can interpret it. It's like the situation where you meet someone from Spain who doesn't speak English and you can't speak Spanish, but you both speak another language—say Russian. By agreeing on this as the standard for your conversation, the only limitations are your grasp of the intermediate language.
Connectionless Communication
Even when two systems natively speak the same language, such as COM or DCOM in the Windows case, direct and continuous communication is not always possible. Take, for example, a traveling salesperson who goes round the country collecting orders, using the interface to your application on their mobile computer. For most of the day they won't be connected to the office network, and so their orders have to be stored locally and then transmitted to the invoicing office as a batch.
However, you'll want to be sure that these orders all get processed, and that none are duplicated. This means that it's a good idea to implement transactions that encompass the taking of the order and its processing within the office. To be able to do this, you need to have a way for the mobile application to store the orders, and tell the interface (i.e. the salesperson and the customer) that the transaction succeeded. Otherwise, it would be impossible to place an order—the transaction would be aborted because the 'office end' of the process would not indicate success.
Normally the 'other half' of the transaction can take place only when the mobile computer is connected to the office network. However, message queuing allows this to occur by standing in for the office half of the transaction. It accepts the instructions and tells MTS that the process completed OK, and that it can commit the transaction. Once connected to the office system, it passes on the instructions to the other half of the application for it to process. Effectively, it's making a promise to the mobile application that the process will complete successfully, and that it can get on with the next one.