J2EE and .NET interoperability through .NET remoting

About: This post outlines further details about implementing J2EE and .NET interoperability through .NET remoting

Hello,

In my November 25, 2005 post I outlined the following four strategies for interoperability; 1) Web Services, 2) .NET Remoting, 3) HTTP (REST), and 4) Custom solutions. This particular blog post focuses on .NET remoting that allows for binary and XML communication between Java/J2EE and .NET systems.

In the context of interoperability, .NET remoting is a Microsoft specification that has been implemented by companies like J-Integra (http://j-integra.intrinsyc.com) and JNBridge (http://www.jnbridge.com). It is a framework that allows implementation of solutions where features like high performance and call back capabilities are required. .NET remoting allows for binary and XML encoding, synchronous or asynchronous communication and provides services like lifecycle management across application boundaries. .NET remoting engines like J-Integra generate proxies that allow .NET applications to invoke Java/J2EE systems as if they were just another.NET system, it also allows Java/J2EE to invoke the .NET applications as if they were Java/J2EE objects, in short, either .NET or Java/J2EE system can be in control of the execution flow.

 .NET remoting can be used to implement interoperability between Java (swing) clients and .NET applications on the desktop as it allows for sharing of memory as well as communication through sockets, however, in my opinion; it’s most common use in the industry remains in the area of invoking J2EE servers from .NET clients and for communication between J2EE and .NET servers.

During the 1997-2001 timeframe a number of companies made significant investments in implementing Java/J2EE systems, however the early focus of Java/J2EE on completely web-based enterprises slowed the pace of innovation on the client side and with the release of .NET and Microsoft’s understanding of the needs of business users, .NET quickly took a leadership position on the desktop.  The IT managers (those who did not feel religiously about Java or .NET) realized that in many instances the needs of the business users can be better fulfilled by developing .NET solutions that could be developed faster than their Java counterparts and allowed users to harness the powers of .NET on the client while preserving the investments that the organization has made in Java/J2EE on the server side. .NET remoting was a natural choice in these instances as it allows for invocation of Java/J2EE servers by .NET applications by using TCP, HTTP (SOAP over HTTP) and RMI/IIOP. The solutions based on the RMI/IIOP channel have gained momentum as they provide an elegant solution which maintains clean separation amongst the two systems, while allowing for high performance, stateful interoperability  

One of the key choices that must be considered before implementing a .NET remoting solution is implementing interoperability through Web Services e.g. exposing the J2EE servers as a web service rather than using the .NET remoting, RMI/IIOP solution. My opinion is that you should use Web Services if you can, however, if your business needs cannot be fulfilled through web services because of performance or other requirements then .NET remoting might be the next best choice.

Companies that provide .NET remoting solutions using the RMI/IIOP channel include J-Integra (http://j-integra.intrinsyc.com) e.g. the J-Integra Espresso is a solution where the Object Request Broker (ORB) has been written in C# and has been developed entirely as managed code which means that it allows clients & servers written in any .NET language e.g. C#, C++, ASP.NET etc. to access the ORB and interoperate with J2EE servers.

There has been some discussion about how the upcoming Windows Communication Foundation (code named Indigo) will impact solutions that have been implemented using .NET remoting. Please note that .NET remoting is NOT going to disappear when Indigo is released i.e. it is NOT being removed from the framework.  It is true that Indigo is the next wave of evolution and it will be in your interest to upgrade your .NET remoting solution to it based on your business requirements and environment. You can minimize your future upgrade effort by avoiding the use of custom .net remoting channels and sinks as upgrading those would be significantly more involved.

In conclusion, .NET remoting is a viable and valid choice for implementing certain types of interoperability solutions; it is an approach currently being used in the industry for systems of all sizes and complexities and along with Web Services it allows you to take advantage of both Java/J2EE and .NET to serve the needs of the business.

Best regards,

Mohammad