DCOM Explained
by Rosemary Rock-Evans
Digital Press
ISBN: 1555582168   Pub Date: 09/01/98

Previous Table of Contents Next


Guaranteed Delivery/Delivery Assurance

What do we mean by guaranteed delivery? In middleware terminology, guaranteed delivery is a function that ensures that a message is guaranteed to arrive at its destination, despite failures, outages, server failure, client failure, middleware failure, and so on.

It is notoriously hard to achieve, as the more safeguards you build into a message queuing product to ensure it doesn’t lose a message—that its queues are protected from failure, that it has a protocol for removing messages from one queue as they are stored on the following queue—the slower the processing gets. The provision of this service thus tends to be something of a compromise—the vendor does the best they can to ensure the message is delivered but without compromising performance. Some of the best middleware products provide you with an option—various levels of service.

DCOM without MSMQ clearly does not support guaranteed delivery in the sense we mean it here, that a message is guaranteed to arrive despite failures. At this basic level, the client receives an error message if the message is not delivered. But MSMQ can support guaranteed delivery; thus, if the developer wanted to ensure a message was always delivered, he or she would use MSMQ.

The safeguards provided within MSMQ are quite extensive. When a client sends a message, the message is first placed on the transmission queue of the client machine. Transmission queues can be memory based (express) or disk based (recoverable), but in both cases they are logged, which means that any sort of machine failure would not result in the loss of a message—the log could be used to reconstitute the queue.

The message is then passed to the next transmission queue in the route in a series of hops, which will take the message to its final destination. A series of acknowledgments takes place between sending MSMQ module and receiving MSMQ module to ensure the message has reached the next stop on the route. Thus, at each stage an acknowledgment system is used to ensure the message has been transferred between transmission queues successfully. The client, however, is not sent acknowledgments—either en route or when the message reaches its final destination.


Figure 14.10  Guaranteed as “assured” delivery service

When the message has reached the final receipt queue, MSMQ transfers the message from the transmission queue on that host to the public or private queue. Both queues are disk based and as such protected against machine failure. The public queues are based on SQL Server and can as a consequence be logged as part of the normal DBMS procedures. These queues are also replicated, so even if SQL Server logging is not used, the replicated queue acts as a protection against disk failure.

The only rather remote point of failure in the sequence is the private queue, which is neither logged nor secured using a DBMS. As such, although it is safely stored on disk, if the disk crashes, messages could be lost. As the public queue is stored with the Registry, however, the disk failure could cause more catastrophic failure than just the simple loss of a queue, and as such the administrator may well consider supporting the configuration using disk mirroring and striping on Windows NT.

It is possible to get a situation where some messages are not delivered because they time out, the server doesn’t exist, or the queue disappears, but even then the message is not lost. Instead, the dead letter queue is used to store these messages, which can be handled separately under administrator control.

Deferred Delivery

Deferred delivery describes the ability of a message queuing product to (as is implied) defer the delivery of a message until the recipient is there. It does not mean that the message is deliberately held back but refers to the capability of a product to deliver a message even though various components on its route are temporarily unavailable or missing.

The same approach used to support guaranteed delivery in MSMQ also supports deferred delivery. If we use the example below again to explain the features in MSMQ:


Figure 14.11  Deferred delivery

We want to deliver a message from process A to process B. In the first place, the client can deliver the message to MSMQ even if all the machines along the subsequent route are unavailable. MSMQ will safe store the message on the queue.


Figure 14.12  A client process can send a message even if no other nodes are active

MSMQ can then subsequently move the message along the route, safe storing it as it goes along, even if the client process has shut down and no server process is running.


Figure 14.13  MSMQ can move the message between nodes, even if client and server applications are inactive

Once the server machine has the message on its transmission queue, it can deliver the message to the server process even if the client process, client machine, and all the machines en route have been disconnected from the server machine or the line between the server and other machines had failed.


Figure 14.14  A server can receive a message even if all other nodes are inactive

The server process can be triggered (notified) when the message arrives, but even if this method is not used, the message will wait on the receipt queue until the server process was loaded or restarted.


Previous Table of Contents Next