We live in a highly asynchronous world. Just when you start to make that all-important business call to your supplier in Switzerland, he left the office and took the family out to dinner. Meanwhile, you end up with his voice-mail, so you leave him a message which he'll answer when he's next at his desk.
This scenario repeats itself in all shapes and forms millions of times per day around the world. Many business procedures involve the flow of work from one individual to another, each processing or adding value to the work in progress. Unfortunately, not every individual involved is connected to the networked system all the time. Therefore, there's a need to reliably queue the work while it's being relayed from one processing stop to another.
The flow of work from one agent to another is called workflow and many business procedures can be automated with workflow based systems. Fitting into the distributed computing perspective, the work performed by each agent can be considered a subtransaction, while the entire workflow itself can be considered as a single large transaction. In cases where a workflow consists of many subworkflows, this can be nested even further.
Now, without the availability of a reliable queuing mechanism, asynchronous workflow can't participate in the transaction world. This is because the typical delay between the processing steps of the workflow may be in terms of hours, days, or even weeks. Any mechanism of network sanity detection would consider such time delays as a network failure, and will cause the transaction-in-progress to fail, resulting in a rollback.
With the introduction of reliable queuing mechanisms, you can introduce the concept of a very long transaction in terms of duration, and computational integrity can be guaranteed. This is an absolute necessity in the handling of business procedure workflow.
One side benefit of having a reliable queuing mechanism in a distributed system is the ability to use it as an alternative transport. For example, imagine a world where DCOM is transmitted over a reliable queuing transport. This means that a link between inter-operating components can be broken, yet the request will be persistently queued at the source until the link is recovered minutes, hours, or even days later. At that time, the interaction between the components can continue. With the highly interactive nature of DCOM today (freshly evolved from OLE-centric, UI-focused COM), it's hard to imagine the practical implication of this ability. However, given time, as more and more transactional applications are delivered based on DCOM technology, the reliable queuing mechanism will become indispensable.
The Microsoft version of this queuing mechanism is code-named 'Falcon' and will become a fundamental enabler for the future world of robust DCOM based component computing.