request is still considered idempotent even if side effects exist.

Challenges of multimessage
interactions

Any message may arrive multiple times, even after a long while. Think of a messaging system as containing a bunch of Machiavellian gnomes who are watching your messages float by so they can interject a copy of a message at precisely the worst time for your application (see Figure 4). In most loosely coupled systems, messages may arrive multiple times. Furthermore, related messages may be delivered out of order.

A typical approach to this problem is to use request-response and then ensure the messages processed are idempotent. This has the benefit of the application seeing the delivery of the message via a positive response. If the application gets a response from its intended partner, then it is confident that the message has actually arrived. Because of retries, the receiving application may receive the message many times.

This challenge is further com-
pounded when multiple messages are
involved in making a piece of longer-
running work happen. The duration of
the work and the allowable failures for
the work must be considered, as in the
following cases:

figure 6. service behavior is in the eye of the beholder.

Service-A
Dialog
Dialog
Service-B
Service-C
Service-Perceived Dialog
Service-B presents
the façade of doing
the real work.

The real application work happens here

figure 7. transport and plumbing acknowledgments should not be visible to applications.

Service-A
Dialog
Service-Perceived Dialog
Dialog
Service-B
Service-C
Plumbing
Plumbing
Plumbing

Msg Ask

What Do you mean the Work is
Not Done on the Premises?

When Service A talks to Service B, you do not know where the work is really done. Service A believes it is doing work with Service B, while Service B may actually subcontract all the work to Service C (see Figure 6). This is not in itself a problem, but it can magnify the failure possibilities seen by Service A.

You cannot assume the work is actually done by the system you are chatting with. All you know is that you have a messaging protocol, and, if things are going well, appropriate messages come back from the named partner according to the protocol’s definition. You simply do not know what goes on behind the curtain.

You know a message has been delivered only when the answer comes back from the partner doing the work. Tracking the intermediate waypoints does not help to know that the work will get done. Knowing a FedEx package has reached Memphis will not tell you that your grandmother will receive her box of chocolates.

When a messaging transport sends an acknowledgment (ACK) to a sender, it means the message has been