I got the chance to spend an hour this week with Dr. Wayne Citrin, CTO of JNBridge. He’s been refining a Java/.NET interoperability product for the last five years – starting out with a risky bet on .NET when it was only in Beta. Back then I was at BEA Systems, we tried to use jCOM as a bridge to Microsoft applications that customers needed to integrate with J2EE systems. There were reliability and configuration challenges with this approach, and we found that as .NET grew in our customer base, we could only advise them to use Web Services for interoperability.
WS for interoperability is a good choice when you can build well-defined contracts between systems and coarse-grained, loosely coupled integration is acceptable (despite the performance and reliability impacts). There are situations where tightly-coupled integration is necessary (specific security requirements; chatty communications), which is where I’d apply a product like JNBridge.
JNBridge handles the conversion of Java objects into .NET objects and vice versa – including management of references on both sides to ensure that object extent is handled correctly, and converting “by reference” and “by value” situations to their correct native implementation. I’m simplifying for brevity, but for more detail you can take a look here.
They have 3 modes of operation – XML/HTTP, Binary/TCP, and Shared Memory (for running on the same server). As we proceeded through the discussion, I was interested in how they dealt with the “complex object” issue, where a Java object contains other objects by reference.
When converting complex objects to Web Services, the antipattern is to marshal the entire object graph into a SOAP message, add getters and setters to the remote proxy that handle write-backs. This causes problems both in communication overhead and performance (that’s a lot of data to marshal to XML; plus this marshalling will happen every time the remote client needs to update a field in the complex object). There are other problems that I won’t get into here.
For these situations, it can work better to have a tightly-coupled integration layer – with JNBridge, you could use their Binary/TCP mode to have a conversion from Java to .NET objects happening on the J2EE server, and communicating with the .NET tier through native .NET remoting.
Another common interop request I hear from software architects is to have BizTalk or .NET interop with JMS (Java Message Service). This is an area that I haven’t seen great solutions to in the past. The best approach from performance and reliability standpoint should result from a tightly-coupled integration at the JMS Client layer; here I would consider deploying JNBridge in Shared Memory mode, with .NET application logic on the same machine as JNBridge and a JMS Client, which would remotely access a JMS Cluster via RMI or your Java protocol of choice.
Now if only Java were associated with Guinness we could call this approach a “Black-and-Tan”… as it is I’ll have to leave it “Half-and-half”.