We’ve published a new case study on how Graebel Companies, Inc., used the JNBridge JMS Adapter for .NET to leverage existing business logic and easily integrate JMS messaging with their .NET-based SOA framework.

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.

From our previous blog post, you can see that we’ve announced version 5.0 of JNBridgePro, which supports cross-platform transactions. This is a feature we’re really excited about. Up until now, you could have Java code inside a Java transaction call .NET code (or vice versa), but if something happened to cause a rollback on the Java side, the .NET side wouldn’t get rolled back. With the new version of JNBridgePro, transactions on the Java and .NET sides are transparently and seamlessly integrated. If there are active transactions on the Java and .NET sides, JNBridgePro will automatically join them, so that if either side fails, both sides are rolled back, and if both sides succeed, the transaction is committed on both the Java and .NET sides.

The picture below gives an idea of cross-platform transaction bridging in action:

JNBridgePro’s cross-platform transaction bridging will work with both .NET-to-Java and Java-to-NET (and bidirectional) projects, and it will work with any vendor’s JEE implementation.

If you’re creating financial or e-commerce software, you will likely have transactional requirements, and we encourage you to download and try the new version of JNBridgePro, which becomes available on Monday, November 16.

More information on cross-platform transactions in the new version of JNBridgePro can be found here.

We’ve just announced the forthcoming release of JNBridgePro 5.0 and v2.0 of the JMS Adapters for .NET and for BizTalk Server. The bits will be available on 11/16/09, and we’ll be demonstrating the new capabilities at PDC next week in Los Angeles.

JNBridgePro 5.0 adds support for cross-platform transactions between Java and .NET in both directions.

The JMS Adapter for BizTalk Server 2.0 adds support for request/response and solicit/response messaging patterns. Both adapters have greater architecture flexibility.

Read the full press release, and download new versions on or after next Monday, 11/16/09.

We’ve posted a new case study featuring Benefitfocus and our JMS Adapter for BizTalk Server.

Business Challenge

How to streamline incoming carrier data from JMS (Java Message Service) with a BizTalk enterprise application integration infrastructure — and do it within a two-month software development window.

Solution

Use an off-the-shelf BizTalk adapter — the JNBridge JMS Adapter for BizTalk Server — to integrate applications into the enterprise infrastructure without the cost, risk, and time-to-deploy associated with an open source or internally developed solution.

Read the entire case study here.

DevX has posted a new article: Java/.NET Interoperability: Web Services Aren’t Always the Answer, Mixing .NET and Java technologies with web services is often easy, but for many tasks web services are not the solution for Java/.NET interoperability.

Let us know what you think!

We’ve just announced that JNBridgePro is compatible with Windows 7.

You’ll need JNBridgePro v4.1.1 (or later), and you can download the latest version here.

A number of our users have begun using Windows 7. You’ll be happy to know that JNBridgePro works fine with Windows 7, with a few caveats. Here’s where things stand with the current version (4.1.0):

32-bit JNBridgePro: 32-bit JNBridgePro works just fine with Windows 7. The product installs smoothly, and the proxy generators work, as do the Visual Studio and Eclipse plug-ins. The only caveat is that if you are using shared memory and Java 6, you might see a message that contact with the Java side could not be made because msvcr71.dll is missing. This is actually a well-known issue with Java (see detailed discussion of the problem�here), and is the result of some very questionable design decisions by Sun; it has nothing directly to with JNBridgePro. The solution to the problem is to find a copy of msvcr71.dll (you can find one in the JDK 1.6’s bin folder), and place it in \Windows\System32 (or \Windows\SysWow64 if it’s a 64-bit operating system). When that is done, the problem will go away. Finally, all applications that use JNBridgePro will work fine; if the applications use shared memory and Java 6, add msvcr71.dll as described above.

64-bit JNBridgePro: In the 64-bit version of JNBridgePro, the installer will show an error when installing the Visual Studio plug-in. Simply hit the return key to pass through this error. If both Visual Studio 2005 and Visual Studio 2008 are on the machine, you will see this error twice. Once the installation completes, the standalone proxy generators will work fine, although the Visual Studio plug-ins will not be installed. All applications that use JNBridgePro will work without problem.

By the time of the release of Windows 7 (scheduled by Microsoft for October 22, 2009), we plan to release a new v4.1.1 of JNBridgePro that will address the two issues discussed above.

In the JNBridgePro documentation for the Eclipse plug-in, it only mentions support up through Eclipse 3.4 (Ganymede). However, the JNBridgePro Eclipse plug-in also supports Eclipse 3.5 (Galileo). Install and use it in the same way as you would with previous versions of Eclipse, and everything will work just fine.

We’ve posted the transcript for our interview on Connected Show! Episode 11, “JNBridge – Spanning Java & .NET” (the transcript starts about 27 minutes in). Peter Laudati, a Developer Evangelist for Microsoft, interviewed Wayne Citrin, CTO of JNBridge, at JavaOne. They talk about connecting Java and .NET applications using JNBridge. It’s just magic!