News Stay informed about the latest enterprise technology news and product updates.

The faces of .NET/Java interoperability

Web Services remain the primary tool for developers interested in integrating the functionality of .NET and Java applications. Sometimes speed is not a particular issue. But some developers face a much tougher challenge when looking to optimize performance and maximize security for tightly coupled applications.

Web Services remain the primary tool for developers interested in integrating the functionality of .NET and Java applications. Sometimes speed is not a particular issue. But some developers face a much tougher challenge when looking to optimize performance and maximize security for tightly coupled applications.

In these cases, they can turn to the built in Java Native Invocation (JNI) interface, but face problems with seemingly subtle problems that can balloon up to major challenges down the road, noted Alex Krapf, co-founder and President of Codemesh. In order to address these challenges a number of vendors have emerged to provide bridging (i.e. JNBridge and Codemesh) and translation tools (i.e. Mainsoft) between the Java and .NET domains. The tools promise superior application performance, improved security, and help overcome many of the subtle programming differences between the .NET and Java realms.

"These tools are not so much oriented towards interoperability as conversion and migration," said Ray Valdez, analyst, Gardner. He stressed that for most projects, interoperability done using Server Oriented Architectures (SOA) are still the most universal.

Yacov Cohen, President of Mainsoft said, "When you do Web services properly, you can have a system where if one component changes, you don't have to redesign the whole system. This is great for setting up interoperability with business partners. But we are seeing an abused system of Web services when you are using them to design an internal system. You can get into performance bottlenecks, where every time you want to communicate, you have to serialize your data into XML and SOAP. When you are making tens of thousands of calls per second, Web services don't make sense. For example you don't want to use Web services for ATM transactions."

Developers only need to go beyond this when they have some tightly integrated systems running on one machine and they need the Java and .NET code running in the same process or the same container, noted Valdez. Generally when people do this kind of conversion they have .NET code and Java code and decide their future is one or the other and this is a kind of intermediate step, and then they decide to do emulation, bridging, conversion, or cross compilation.

When sped is key

The absolute best performance comes from translating code into the target platform so that the final executable is entirely compatible, noted Krapf. He explained, "If you could have a perfect translation solution, it would most likely be superior to bridging because you would be reducing the number of moving parts that make up your application. The problem is that it is almost impossible to create a perfect translation solution."

Mainsoft translates, while JNBridge and Codemesh bridge. The Mainsoft suite of tools translates a subset of the possible .NET APIs, translate into Java, so that a developer can implement their entire application in a Java container. But these tools are limited to J2EE. Krapf said, "By focusing in on J2EE, Mainsoft has a well defined model. But you get into messy areas if you want to cover the entire area of Java."

"If you are trying to develop a rich client interaction, you will not try and cross compile, Java EE is more server based," said Cohen.

Bridge solutions for interop

Bridging solutions like JNBridge and Codemesh Juggernaut provide a happy middle ground. They provide a significant performance boost over SOA approaches, and provide tools to overcome some of the impedance mismatch between Java and .NET programming environments.

For example, Net has different naming conventions in terms of casing and what should and should not be the first character in a name, noted Krapf. He explained, "There are a lots of ways to create the transformation in the bridge. This is one of the reasons we have a GUI-based code generator, which is the first tool our customers use for defining what they want to do. It offers complete control over types. Java has 5000 different types and the bridge does not need to expose that. Very often, the programmer only needs a small subset of types. Our tool allows you to set the types you need. You can also set the properties so you can support the Java programmer that need to do something in .NET"

OEM developers have demands that go beyond the typical user. For example, a company publishing a JAR file might have customers who would like to access this Java functionality in C++ or .NET. They want to create this integration capability for customer and then bundle these into their products. The OEM wants to make this look as much like .NET as possible.

The real differences between the bridging approaches lie in the subtle distinctions that each vendor addresses in their tools. What Krapf calls, "the nefarious aspects of integration problems which you rarely understand at first. We focus on the APIs, performance, and flexible ways of configuring the generated project. You are not limited to DLLs."

According to Cohen, one of the limitations of current bridging technologies is that they don't cover all the distinctions between programming models. He noted, "One of the challenges with bridging is that differences between the data structures in Java and .NET can create problems. While on paper, Web services and bridging would solve the problem really well, it does not fully solve it. For example, if I need to log in and provide a Windows security descriptor, these low level issues are pretty tough traps for enterprise developers between .NET and Java."

Krapf acknowledged that bridging suffers from performance issues when you have two different technologies used concurrently. He said, "That means there will always be some impedance mismatch. For example in debugging you might go to C++ then Java and back again. The entire focus of our tools is to make these little impedance mismatches as small as possible, but I would never claim they are not there."

Wayne Citrin, CTO of JNBridge believes there are significant advantages with bridging compared to cross compiling. Citrin explained, "With bridging, Java behaves as it is supposed to. If you are doing translation it is quite possible you could be introducing subtle errors. The other difference is one of evolvability. What happens when the .NET libraries change, and Microsoft adds new APIs. Then I have to go back and make the changes, and until I do, the user is stuck. In a matter of minutes you can create a new set of proxies."

Another difference is that the bridging allows the developers more options in terms of where to deploy the completed applications and how they communicate. Citrin explained, "Cross compiled code ends up running in the same JVM as the Java it is interoperating with. In our case, we have the flexibility of having the Java and .NET to be deployed anywhere."

For example, the CLR hosting .NET code and JVM hosting Java code could be deployed to run in the same process, or across a wide area network such as a client/server application. When running on the same process, JNBridge takes advantage of the CLR hosting API within .NET and the Java Native Invocation Interface within Java. Citrin said, "While these things are provided by the vendors they are difficult to use. In our shared memory communication mechanism that connects the two, we have papered over those complexities and difficulties, so the developer does not have to worry about this stuff."

JNBridge enables thee basic deployment models: shared memory in which applications run in the same process; binary interfaces which can be accessed across a local or wide area network; and, traditional Web Services interfaces. In all of these scenarios the code remains the same, and if the developer wants to change models, he merely has to change a few configuration files.

The shared memory and binary models are able to exchange messages at a rate of almost 600 times that of SOAP. Citrin said that developers almost never use SOAP because of these performance improvement except in rare instances like having to traverse firewalls that only pass HTTP traffic.

Dig Deeper on .NET Architecture Best Practices

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.