Asynchronous Interoperability: How to Decide

In this part of the book, you've seen a number of ways that asynchronous interoperability can be achieved between the .NET and J2EE platforms. This included creating a custom Web service wrapper for MSMQ, looking at the .NET SupportPac libraries supplied with WebSphere MQ, investigating how a Message Driven Enterprise JavaBean (MDB) can call a .NET Web service in a publish/subscribe model, implementing an MSMQ-MQSeries bridge to transfer messages between queues, and examining how BizTalk Server can orchestrate the flow of messages within a business process that uses Web services.

I'm often asked which method of asynchronous interoperability is most suited for a particular project or task. In general, the response tends to be driven by three goals:

• Dependability How reliable do you want the transfer of messages to be? How important is it if a message is lost? Do you need to perform transactions between one or more queues? If reliable messaging and transactions are key, wrapping the queuing API with a Web service won't suffice. With the implementation of reliable messaging and transactional specifications for Web services, this is starting to change, but for the time being this has to be an important consideration.

• Maintainability and manageability I always recommend looking at your existing infrastructure and accessing how maintainable or manageable interoperability will be. For example, if an organization has invested heavily in creating and deploying an MDB architecture, using the MDBs to call .NET Services via a Web service facade might be an attractive option. If such an investment hasn't been made, creating this infrastructure might add another layer of complexity to the problem.

• Message transit What do you want to do with the message? Is it acceptable just to take the raw byte representation of a message from one queue and deliver it to another, or are there some modifications that need to be made in transit? Likewise, should any logic be applied to the message as it's transferred between platforms? Answers to these questions determine whether the solution should be a natural bridge between two or more message queues, or whether a product such as BizTalk Server will offer a more comprehensive solution.

Regardless of the option that's best suited for your environment, I hope that the technology shown in these last four chapters has helped to demonstrate a number of permutations . Although point-to-point connectivity between .NET and J2EE is certainly a goal, asynchronous interoperability is often key to many successful enterprise applications.