6.4 Heterogeneous Asynchronous Drawbridges

As in all other heterogeneous cases, the heterogeneous asynchronous drawbridge situation occurs when we have two fortresses working together that are each built on different technology bases. And, as in the synchronous situation, we have two issues to deal with: the delivery engine and the infogram format.

The delivery engine is not necessarily a problem because at least some message queues run across different platforms. IBM's MQSeries, for example, falls in this category. Other platforms, such as Microsoft's MSMQ, do not. Even when the message queue is platform limited, good bridge products exist that can be used to link different message queues together.

So we can handle asynchronous heterogeneity in one of two ways. We can run a cross-platform message queue product on both platforms, or we can use native message queues on each platform and then use a message queue bridge to move infograms from one message queue to the other. The latter case is shown in Figure 6.3.

Figure 6.3. Drawbridges Using Message Queue Bridges

We also need to worry about the infogram format. Because the infogram format is really part of the formal treaty between the two fortresses, it is reasonable to deal with this issue as a treaty-specific issue. But we can also make use of a ready-made infogram format.

One obvious choice for a ready-made format is the same format that we use for heterogeneous synchronous drawbridges. Do you remember what that is? SOAP! Recall that SOAP doesn't care about delivery channels. It is just as happy to ride over a message queue as to ride over an HTTP request. This is not to say that you must use SOAP. It is just one of the work request formats (which is all an infogram is) that is widely understood . And over time, it is a format for which vendors are likely to offer increasing support.

That pretty much covers the heterogeneous case. The nice thing about drawbridges based on message queues is that they are inherently fairly heterogeneous.