Implementing J2EE-.NET interoperability using WebSphere MQ: part 1: new SupportPac allows use of the same messaging middleware on both platforms.(Interoperability)

It is today's reality that most companies are using both J2EE and .NET environments for their software implementation. Until recently, the prevalent solution for integration of these two environments has been HTTP-based Web services.

**********

Although this solution works well in many cases, it suffers from the following drawbacks:

1. Most implementations today are synchronous and based on the synchronous nature of the underlying HTTP protocol.

2. Reliable messaging is difficult to implement using HTTP.

3. Load balancing in an HTTP-based environment requires a client-side load-balancing implementation, which is usually quite difficult when compared to server-side load balancing.

4. Client and server application life cycles have to be synchronized in order for Web services-based communications to work.

Some of these problems can be easily alleviated by using messaging software that provides guaranteed message delivery, asynchronous communications, and ease of server-side load balancing.

So far, while the J2EE world has standardized on JMS, the .NET world usually relies on MSMQ and MSMQ bridges provided by third-party vendors. The release of the WebSphere MQ support for .NET--SupportPac MA7P (www-3.ibm.com/software/integration/support/supportpacs/individual/ma7p.html)--provides a new integration mechanism by using the same messaging middleware on both platforms.

We will discuss a simple interoperability example between a .NET client (via WebSphere MQ SupportPac MA7P) and a J2EE server (using WAS v5). Sample source code is provided for both environments.

Overall Implementation Architecture

The use of message queuing for communications between applications requires the introduction of additional components--queues (see the Queue Manager sidebar)--to serve as a main communication vehicle.

As shown in Figure 1, usage of queuing for application-to-application communication leads to a very loose coupling between applications. In this case applications don't talk to each other, but rather use intermediary queues. The consumer application puts a request message into the (request) queue, which is picked by the producer application actually fulfilling the request. When the request is processed, the producer application puts the result message into the (reply) queue, which is picked up by the consumer application.

Instead of depending on locations and interfaces of participating applications, queue-based communications are dependent only on the format of the …