scale by adding more servers when the demand increases. This opens up the question of how later messages can locate a service (running on a server) that remembers what happened before.

Here, the problem is framed by describing the kind of application under consideration by looking at services and how long-running work can run across them, and by considering the need for messaging across applications that evolve independently in a world where they share relatively simple standards.

messages and Long-Running Work

Sometimes related messages arrive much later, perhaps days or weeks later. These messages are part of the same piece of work performed by an application attempting to work across multiple machines, departments, or enterprises. Somehow the communicating applications need to have the information necessary for correlating the related messages.

Predictable and consistent behav-
ior is essential for message processing,
even when some of the participants
have crashed and restarted. Either the
earlier messages did not matter or the
participant needs to remember them.
This implies some form of durability
capturing the essence of what was im-
portant about the earlier messages so
the long-running work can continue.
Some systems do need the information
from the earlier message to process the
later ones but do not make provisions
for remembering the stuff across sys-
tem crashes.

figure 1. Applications talk to their local plumbing.

System
System
Service-S1

Interesting
Semantics
Here!

Service-S2

Plumbing P- 1

Plumbing P- 2

 

Messaging Transport
Messaging Transport

figure 2. sometimes, the plumbing will transactionally tie the consumption of the incoming message to changes in the application’s database and to outgoing messages.

Service

Serivce Private Data
Application Logic
Transaction
imagining a Dialog
Between two services