Summary

In Chapters 8 and 9, you saw alternatives for connecting Java clients to MSMQ and for connecting .NET clients to WebSphere MQ. Both these chapters pointed out that although connectivity is possible, the alternatives discussed don't really offer a true message queue experience. The XML Web service wrapper for MSMQ lacks reliability and transactional support, and .NET can access only a subset of the WebSphere MQ classes.

The MSMQ-MQSeries bridge that ships with Host Integration Server offers a viable alternative to these two approaches. Using this bridge allows clients to use their native message queuing implementations ( System.Messaging for .NET, and the IBM Java libraries for WebSphere MQ), which guarantees reliability and transactional message queue qualities.

If you have an existing investment in Active Directory, want to perform message transfer between MSMQ and WebSphere MQ queues, and need a supported product, the MSMQ-MQSeries bridge might be a good fit for you.

The bridge does have some drawbacks, however, which can affect implementation. First, it's dependent on an Active Directory installation, which is a consideration for J2EE-only environments. For this purpose, this chapter presented the steps required to configure the directory correctly. In addition, the bridge lacks the ability to process any messages while they're in transit. To understand when this might be important, imagine requiring that only messages meeting certain criteria are transferred, or requiring that the message schema must be changed as it flows between queues. The sample showed a great example of this, where the .NET client uses an XML structure to create messages, while the Java client is expecting a raw stream of bytes. The transformation of the message was the responsibility of the Java client and something that the bridge could not do automatically.

Now also imagine a requirement to communicate with other message- based systems (for example, queuing products other than WebSphere MQ or host-based systems). At this point, we're talking about a very different solution. To address some of these requirements, we'll look at a product named Microsoft BizTalk Server in the next chapter. We'll also summarize the four chapters on asynchronous interoperability to review what you've learned.