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
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-
figure 1. Applications talk to their local plumbing.
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.
Serivce Private Data
imagining a Dialog
Between two services