that is transparent to the application.
This is very useful for business process
workflows and many other cases. Losing a message would make the application’s design very, very difficult, so the
app wants no gaps.
˲ Currency (deliver the latest—gaps or
no gaps). Sometimes the delay to fill in
the gap is more of a problem than the
gap. When watching the price for a specific stock or the temperature gauge
of a chemical process in a factory, you
may be happy to skip a few intermediate results to get a more timely reading.
Still, order is desired to avoid moving
back in time for the stock price or temperature.
Knowing What you Don’t Know
When sending messages
When a communicating application
wants to request some work to be done
by its partner, there are a few stages to
˲ Before you send the request. At this
point, you are very confident the work
hasn’t been done.
˲ After you send but before you receive
an answer. This is the point of confusion. You have absolutely no idea if
the other guy has done anything. The
work may be done soon, may already be
done, or may never get done. Sending
the request increases your confusion.
˲ After you receive the answer. Now,
you know. Either it worked or it did not
work, but you are less confused.
Messaging across loosely coupled
partners is inherently an exercise in
confusion and uncertainty. It is important for the application programmer to
understand the ambiguities involved in
messaging (see Figure 3). The interesting semantic occurs as an application
talks to the local plumbing on its box.
This is all it can see.
Every application is allowed to get
bored and abandon its participation in
the work. It is useful to have the messaging plumbing track the time since
the last message was received. Frequently, the application will want to
specify that it is willing to wait only so
long until it gives up. If the plumbing
helps with this, that’s great. If not, the
application will need to track on its own
any timeouts it needs.
Some application developers may
push for no timeout and argue it is OK
to wait indefinitely. I typically propose
the behavior of the
transport, it is
best to remember
what is promised.
Each message is
guaranteed to be
delivered zero or
that is a guarantee
you can count on.
they set the timeout to 30 years. That, in
turn, generates a response that I need
to be reasonable and not silly. Why is
30 years silly but infinity is reasonable?
I have yet to see a messaging application that really wants to wait for an unbounded period of time.
When your Plumber Does
Not understand you
Nothing beats a plumber who can alleviate your worries and make everything
“just work.” It is especially nice if that
plumber shares the same understanding of you and your needs.
Many applications just want to have
a multimessage dialog between two
services in which each accomplishes
part of the work. I have just described
what can be expected in the best case
when you and your plumber share clear
˲ How you should talk to your plumbing.
˲ Who you are talking to on the other
˲ How transactions work with your
data (and incoming and outgoing messages).
˲ Whether messages are delivered or
you skip messages to get the latest.
˲ When the sender knows a message
has been delivered and when it is ambiguous.
˲ When a service may abandon the
communication and how the partner
learns about it.
˲ How you test the timeout.
These challenges assume you have
met the plumber of your dreams who
has implemented great support for
your messaging environment. It is rarely that clean and simple. On the contrary, the application developer needs
to watch out for a slew of issues.
Some messaging systems offer guaranteed delivery. These systems (for example, MQ-Series)
1 will typically record
the message in a disk-based queue as a
part of accepting the send of the message. The consumption of the message
(and its removal from the queue) happens either as part of the transaction
stimulated by the message or only after
the transactional work has been completed. In the latter case, the work may
be processed twice if there is a glitch.
One challenge in the classic guar-anteed-delivery queue system occurs
when the application gets a message