Communication reliability

One of the most important things to consider when designing communication between two systems in an enterprise is reliability: Does the sender need to know if messages were delivered to the receiver? If an error occurs on the receiver, does the sender need to know? Does the sender need to know what type of error occurred?  Do messages need to be received in the order they were sent? What about receivers that may go offline or networks that go down? Does communication need to participate in a transaction so state consistency is maintained across multiple systems?

Before designing interfaces and selecting network protocols, it's necessary to understand the reliability requirements of the communication and how requirements align with the capabilities of protocol standards and industry techniques. Because the matrix of communications protocol capability and techniques as related to reliability is rather complex, it's useful to categorize communication reliability requirements based the following:

1. Unordered: Unordered is useful for providing information to one or more interested receivers quickly. Communication is one way and does not block. Receivers cannot return information back to the sender and senders don't know if communication with receivers was successful.
2. Receive-reply: For communication to a single receiver, Receive-reply requires a sender wait for a reply or timeout. Both information and errors can be returned in the reply and senders know if communication was successful. 
3. Ordered: Provides ordered communication with one or more receivers. Information cannot be returned from receivers to senders but errors can. When configured to return errors, Ordered communication blocks but otherwise can be configured to be non-blocking.
4. Guaranteed: A form of Ordered communication, Guaranteed cannot return information or errors but guarantees delivery even if the receiver isn't running when sent.
5. Transactional: Either configured as Receive-reply or Ordered, Transactional can return information to the sender if configured as Receive-reply, can always return errors, and can further participate in a transaction as a durable resource.

In communication design, reliability requirements informs everything from the design of the interface operations to protocol selection and is a crucial part of creating a robust enterprise system. Capturing reliability requirements in the form of a few simple categories is a practical way to express business needs in terms real-world protocols and industry techniques can address.