Chapter 6. Asynchronous Drawbridges

You might think that most interfortress communication would occur across synchronous drawbridges. What is there not to love about synchronicity? It is the world of immediate gratification. You want an answer, you get an answer. But it turns out that, at least in the fortress world, patience pays. Asynchronicity has many benefits, but it does require a mind shift. That's the goal of this chapter: to shift your mind.

The history of asynchronous drawbridges is quite different from that of synchronous drawbridges.

Synchronous drawbridges, as I discussed in Chapter 5, are all based on component technology. In that discussion, components were seen as just one part of a larger software platform, whether it was WebSphere, WebLogic, or .NET. It should be no surprise, therefore, that synchronous drawbridges favor the homogeneous (single-platform) world.

Asynchronous drawbridges evolved differently. They are based on message queues. Message queues have been around for a long time, although they are underappreciated by today's developers, most of whom grew up in an object-oriented culture. Objects are the ultimate in immediate gratification: They live in your process, and they do what you want them to do when you want them to do it.

Unlike components, message queues were intended, from the very beginning, to be independent of the underlying software platform. Thus it is not a coincidence that whereas synchronous drawbridges, with their component heritage, favor the homogeneous case, asynchronous drawbridges, with their message queue heritage, favor the heterogeneous case.

Most large enterprises do not standardize on a single technology platform. Therefore the more flexible heterogeneous communications technologies are more important for most organizations than are the relatively limited homogeneous communications technologies. For this reason, if for no other, we will want to pay close attention to asynchronous drawbridges.

Just to make sure we are "in sync" on asynchronicity, let me review the basics. Assume that a donor and a recipient fortress are connected by an asynchronous drawbridge. When the donor wants to communicate with the recipient, it creates an infogram. For an asynchronous drawbridge, the infogram takes the form of a message queue message. The donor now sends the infogram to the recipient.

The fact that the drawbridge is asynchronous has at least three implications. First, the donor does not know when the recipient will get the message and therefore does not know when the recipient will start the requested workload. Second, if multiple messages are being sent, the donor does not know the order in which they will be delivered. Third, the donor does not expect any information to be returned from the recipient.