Fire-and-Forget - Enterprise Integration Patterns 2

Fire-and-Forget

Contents⇐ PrevNext ⇒

A participant has identified a conversation partner and wants to pass information.

How can one participant notify another efficiently?

Simple notifications may not require a response from the recipient.
Some transport protocols, such as socket connections over TCP, are inherently bidirectional. Still, the interaction is more efficient of the initiator does not have to wait for the result data to be received.
Reliable messaging systems guarantee that a message is being delivered.
Some messaging channels deliver the message to multiple recipients. In such a case the sender would have to be prepared to receive multiple responses, often without knowing how many there will be.

The originator sends a Fire-and-Forget message and does not expect any response from the recipient.

The Fire-and-Forget conversation involves the following participants:

The Originator initiates the conversation by sending a message.
The Recipient receives messages.

Fire-and-Forget is the simplest of all conversations. If it was any simpler, we'd have no interaction at all. Therefore, Fire-and-Forget provides the loosest of all possible couplings: the Originator does not need to know anything about the Recipient, including how many there are or what they do with the message.

The Fire-and-Forget conversation is stateless because there is no conversation state to be taken care of. In a Pipes-and-Filters architectural style [2], all components communicate using Fire-and-Forget. This kind of stateless interaction results in highly scalable Messaging systems.

The simplicity and loose coupling of Fire-and-Forget comes at a price: error handling is not possible because there is no feedback regarding message delivery. Therefore, Fire-and-Forget has to use Guaranteed Delivery or be content with "best effort" delivery, where messages may be lost. Besides lost messages errors can also occur at the application level, fore example, if the recipient is unable to process a message correctly due to invalid or corrupt data. As the Recipient has no way of sending feedback to the initiator (it may not even know who the Originator is), it can't do much besides route the bad message to an Invalid Message Channel.

Fire-and-Forget is most effective with asynchronous communication channels, which do not require the Originator to wait until the message is delivered to the Recipient. Instead, the Originator can pursue other tasks as soon as the messaging system has accepted the message.

Example: Messaging Systems

Most messaging systems, such as JMS-compliant systems or IBM Websphere MQ provide Fire-and-Forget communication by default. These systems implement Guaranteed Delivery, so that no messages are lost even if the receiver or the messaging is temporarily unavailable. Messaging Patterns (see Messaging Patterns Overview) are based on Fire-and-Forget.

Example: UDP Packets

On local networks, applications can send Fire-and-Forget messages through UDP (User Datagram Protocol). UDP is connection-less, and does not require a sync up between sender and receiver. Therefore, it is extremely efficient. However, UDP is not reliable, and carries "at most once" semantics for message delivery. Packet order is also not guaranteed.