Tag Archive for: Web services

There’s been a lot of discussion of “€œJava/.NET interoperability” and “€œbridging” lately, whether it’s a discussion of Web services in Microsoft’s keynote at this past spring’€™s JavaOne, or the recent reporting about Eclipse tools for Silverlight or Java clients for Team Foundation Server. All of these things are useful and important in their way, but none of them strike me as being true “€œinteroperability.” They’€™re not ambitious enough. They’€™re too narrow. In a couple of recent articles for Software Development Times and DevX, I’€™ve discussed how our vision of Java/.NET interoperability is broader than this; I’d like to summarize these arguments here and present JNBridge’s view of what interoperability should be.

We see true Java/.NET interoperability as the ability to switch freely between Java and .NET technologies at any level, and as transparently as possible. You should be able to access a Java component from .NET. Instantiate a .NET class from Java. Call a Java method from .NET (or vice versa). Set or access a .NET field or property from Java. And, in doing this, freely use Java or .NET objects as arguments or the values being assigned, regardless of the methods being called or the fields being assigned. In other words, access anything Java from .NET; access anything .NET from Java.

Taken this way, a lot of what’€™s called Java/.NET interoperability out there really isn’€™t. TeamPrise’€™s Java clients for TFS (recently purchased by Microsoft) was recently called “a bridge from Java to .NET” in the trade press. It’s extremely useful stuff (I can’€™t wait to get my hands on a copy as part of the VSTS 2010 release), and it bridges between Eclipse and TFS, but Java/.NET interoperability or bridging it ain’t.

Somewhat more controversially, I’€™ll go out on a limb and say that Web services aren’t Java/.NET interoperability, either. They’re a way to intercommunicate between components that might be written using disparate technologies, but then so is communication through databases, or through sockets, or through text files in shared folders. Even if one of the participating sides is Java and the other is .NET, nobody would consider any of the latter mechanisms Java/.NET interoperability, and neither is Web services, for the same reason.

Think about it this way: could you access anything .NET from Java using a Web service? Could you embed a Windows Presentation Foundation control inside a Java Swing application using Web services? Not possible. Could you create a .NET client that communicated with a Java Message Service infrastructure using a Web service? It might be possible, but rather difficult. Could you use a Web service to access a .NET library from a Java program using a Web service? Yes, but it seems like an awful lot of work to create a Web service just to access a library.

So besides the intellectually pleasing aspects of being able to freely interchange .NET and Java wherever you like, are there any other advantages to true and complete interoperability? There sure are. Here’€™s a very brief list. If you want to learn more about any of these assertions, there’€™s a more in-depth treatment in my SD Times article.

• True interoperability is faster than Web services
• It’€™s more flexible than Web services
• It has a broader reach than Web services
• It provides more functionality than Web services
• It increases choice and lowers cost over Web services

Now that we’€™ve settled on a definition of true interoperability, what about “€œbridging”? You can bridge between lots of things. Web services can bridge between Java Web service clients and .NET Web services. TeamPrise bridges between Eclipse and Team Foundation Server. But neither of these can rightly be considered “a bridge between Java and .NET.” While there are other approaches to Java/.NET interoperability, a Java/.NET bridge needs to provide true interoperability between Java and .NET, while permitting the Java to continue running in a JVM and the .NET to continue running in a CLR. We believe that bridging is the best approach for Java/.NET interoperability: it provides the best combination of performance, flexibility, and evolvability (as the Java and .NET platforms evolve), and we clearly believe that JNBridgePro is the best bridging solution available.