Communications - May 2012

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 consider:

˲ 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

When considering
the behavior of the
underlying message
transport, it is
best to remember
what is promised.
Each message is
guaranteed to be
delivered zero or
more times!
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 notions of:

˲ How you should talk to your plumbing.

˲ Who you are talking to on the other side.

˲ 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.