J2EE and .NET Interoperability

About: This post outlines some of the architectural mechanisms and strategies for programmatic interoperability between J2EE and .NET

Hello,

According to a recent study, over 80% of large enterprises will have both J2EE and .NET systems deployed in their IT environments for the next few years. Although vendors supporting the respective paradigms are trying their best to win market share from each other and some trends have started to emerge, I believe that it will still take 5+ years for the market to decide an absolutely clear winner. In the meantime, many enterprise customers need to come up with strategies for interoperability between these technologies to make it a transparent experience for the user and avoid having technology-based silos.

Interoperability can be looked at from a variety of angles including management, monitoring, measurement, security/Identity management and federation, programmatic interaction etc. In this post, I have concentrated on the programmatic portion, based on interactions with many large enterprises; I have observed the following interoperability scenarios in the industry

1) .NET clients interacting with J2EE Servers - Most common

2) .NET servers interacting with J2EE Servers

3) .NET clients interacting with Java Clients (on the desktop)

3) .NET servers interacting with Java Clients - Least common

The common programmatic techniques for interoperability can be summed up in the following areas

1) Web Services

2) .NET Remoting

3) HTTP (REST),

4) Custom solutions

Web Services are the future of interoperability and more, all major vendors of J2EE and .NET related software are enabling their products to support Web Services standards and are making significant investments to overcome any deficiencies that may exist today. My personal advice is that you should look at Web Services as the first choice for .NET client to J2EE server and .NET server to J2EE server interoperability solution. Web Services offer a number of advantages over other approaches and adopting this as the strategy increases your chances of taking advantage of the investments being made by the software vendors. Please also note that using Web Services does not necessarily translate in to a low performance system and the standard stack is fairly mature in some of the areas while considerable work is occurring to finalize uncovered portion. It is a good idea to do an objective proof-of-concept to determine the viability of the Web Services approach.

.NET remoting is a Microsoft specification that has been implemented by companies such as Intrinsyc (http://j-integra.intrinsyc.com) and JNBridge (http://www.jnbridge.com). In a nutshell, these engines make .NET applications look like Java/J2EE applications to the calling Java/J2EE program and vice versa. There are a number of protocol and format choices with .NET remoting including binary communication and sharing in-process memory. .NET remoting can be a viable option for high volume systems as well as systems requiring features like call-backs.

Representation State Transfer (REST) over HTTP is typically used in scenarios where a .NET client is calling an HTTP based service (often a Java Servlet). This approach has its limitations but maybe useful for simpler web scenarios

Custom solutions have been implemented by a number of customers especially large enterprises that had to deal with interoperability issues a few years ago, there are valid business reasons for why an organization may choose to implement a custom solution (which typically involves writing a subset of a commercial interop engine, playing around with native programming (JNI) and implementing mappings), however, you should make an informed decision in terms of the development and maintenance costs associated with the code and the costs of keeping it in sync with the changes in the .NET and J2EE core technologies.

In conclusion, all of the above mentioned solutions are viable options for programmatic interoperability, the decision to choose a particular approach will depend on the business needs, future outlook, costs of implementation and maintenance and quality of service parameters.

Best regards,

Mohammad