Large IT organizations investing in service oriented architectures (SOA) will soon have to contend with getting .NET and J2EE to work together. Heterogeneity rules the day in most large enterprises, so the question isn’t if interoperability is necessary but rather when. The increasing focus on service-based architectures will lead to composite application development that will incorporate both .NET as well as J2EE-based components.

This article will briefly cover three primary patterns for interoperability between these two major component platforms. In no particular order of priority or importance, the technologies employed in these patterns are as follows -

• Bi-directional J2EE/.NET Bridging
• Message Queuing Middleware
• Web Services Interface

Bridging technology for J2EE and .NET operates by providing a synchronous channel between both platforms, enabling inter-process communication to occur seamlessly at run time. Current bridging technologies will typically utilize the .NET Remoting Protocol as the communication mechanism between both environments. .NET Remoting provides a framework to enable interactions with remote .NET objects, including services for handling object activation and remote method invocation. For this to work across a J2EE environment, the bridging technology must implement the .NET Remoting stack in Java.

Bi-directional bridges work by generating proxies that expose server-side components to the client. As shown in Figure 1 below, the Java client may access server side .NET CLR components through proxies. These proxies expose the CLR components to the Java client as though they were native Java components.

Although not illustrated in Figure 1, a .NET client may similarly access EJB components on the server through .NET proxies. Although bridges are often used for client-to-server interoperability, they may also be employed between applications. The limitation with using runtime bridges is that the available products are relatively new, leveraging proprietary technology. There are also some concerns with performance. Yet it remains a very compelling option, especially when bridging between client and server components.

Traditional message queuing middleware (MQM) may also be used for interoperability between J2EE and .NET applications. MQM technology utilizes asynchronous messaging between application components which carry certain advantages over synchronous request-reply mechanisms. One key advantage is that messages can be reliably sent without the need for a continuous high bandwidth channel. The MQM product will guarantee delivery of messages between the J2EE and .NET platforms.