JNBridge has enhanced their interoperability tool to enable native communication between Java to .NET applications deployed in the cloud or on the ground and in the cloud.
JNBridgePro makes it possible to access Java code from within .NET applications and .NET code from Java apps. The Java and .NET components may run in the same process and communicate over a shared memory, or within the same machine or across the network and communicated over TCP/IP, or within the cloud, communicating over HTTP/SOAP. Interoperability is realized by creating .NET proxies for all Java classes a .NET program written in C#, VB.NET, VC++, or any other .NET language, needs to access, or the other way around, Java proxies for the needed .NET classes. For that purpose, JNBridgePro comes with a standalone GUI that can be used to generate both categories of proxies, a Visual Studio plug-in for Java proxies, and an alternative Eclipse plug-in for .NET proxies.
JNBridgePro takes care of all the interoperability needs: marshaling/unmarshaling objects, data-type conversion, cross-platform exception handling and garbage collection. The framework does not need the source code of the proxied classes, but only the binaries. The .NET code runs on CLR while the Java code runs as on a JVM, there not being any cross-platform recompilation of the code.
The tool has been around for quite some time, since 2002 to be more precise, so it’s not really new, but its latest version adds the ability to interoperate between applications deployed in a cloud. All communication scenarios are allowed: intra-cloud, inter-cloud, ground to cloud, cloud to ground, or a combination of those, as depicted graphically below:
Across the Internet, JNBridgePro uses HTTP and SOAP to communicate between components. We talked to Wayne Citrin, CTO of JNBridge, about the interoperability solution chosen:
InfoQ: Can you talk about JNBridge’s cross-process communication? Shouldn't that be handled by message queuing and web service APIs instead so you can decouple specific instances of a given service?
Wayne Citrin: Yes, where you want to decouple multiple instances of a given service, you may want to use message queuing and web service APIs, but even in those “stateless” services the processing of a complex request may require complex intermediate state. Inside those services are multiple components, some of which may be implemented in Java and some of which may be implemented in .NET, and it’s perfectly appropriate to link them together in a more tightly coupled, stateful, way. The .NET and Java-based components could be running in separate processes on the same instance, in which case the JNBridgePro mechanisms would be more appropriate than more loosely coupled mechanisms. Alternatively, the Java and .NET could be running in the same process in a cloud component, and JNBridgePro can handle that.
In other cases, where legacy code in the cloud might not be messaging-enabled or web service-enabled and could not use these mechanisms, JNBridgePro can be used to support cross-platform/cross-process communication without having to make changes to the legacy application. Also, messaging and service-oriented APIs are usually rather limited, and don’t expose all the functionality that a particular module might offer through direct APIs – JNBridgePro allows access to an entire rich API, either in a single instance, in a single cloud, or between clouds, and the communication will have higher throughput than conventional web services or messaging.
Finally, even where web service APIs are used, not every cloud service provides both .NET-based and Java-based client stubs. In such cases, where client stubs do not exist for a particular platform, rather than generating the web requests directly, will likely be more convenient to use the other platform’s client library, and access it cross-platform through JNBridgePro’s in-process interop.