There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.
People as well as programs receive messages for one of two reasons:
A message sent to you and your device (e.g., an iPhone or BlackBerry) is configured to work in so-called push mode: the other party can push messages for you even if you aren’t necessarily eager to get them immediately after they were sent.
At any given time you decide to check if there messages for you. You press the refresh button on your iPhone or your application makes a call from the client to the server. This mode is called polling.
This chapter starts with a quick example of how to perform the push
by making a direct call to a
MessageBroker, which comes with LiveCycle Data
Services (LCDS) and BlazeDS. Next,
it discusses the existing world of custom adapters and message channels.
You’ll see how to implement a use case with guaranteed message delivery
and take care of the proper sequencing of messages.
At this writing, the newly released LCDS 3.0 promises support for
reliable messaging to guarantee that no message is lost in case of network
failure (check out the
<reliable> tag in the configuration file for Data Management Services). Data-throttling support will ...