【IT168 评论】JNBridge公司已经对他们的互操作工具进行了改善，从而让部署在云中的Java和.NET应用，或者部署在本地和在云中的应用之间能够进行本地通信。

　　JNBridgePro让我们可以从.NET应用中访问Java代码，也让我们可以从Java应用中访问.NET代码。Java和.NET组件可能会运行在同一个进程中，通过共享内存进行通信，也可能位于同一台计算机中，跨网络通过TCP/IP协议进行通信，还可能都在云中并通过HTTP/SOAP进行通信。我们可以为所有Java类创建.NET代理，然后使用C#、VB.NET、VC++或者其它.NET语言来访问这些Java类，从而实现这种互操作性;或者使用另一种方式，也就是为需要的.NET类创建Java代理。为了达到这个目的，JNBridgePro中带有可以独立运行的GUI，我们可以使用它来生成各种代理，此外还有为了创建Java代理的Visual Studio插件，以及为了创建.NET代理的Eclipse插件。

　　JNBridgePro会负责处理所有互操作的需求： marshaling/unmarshaling对象、数据类型转换、跨平台异常处理和垃圾回收。框架不需要代理类的源代码，只需要二进制文件就可以。.NET代码运行在CLR中，而Java代码运行在JVM中，对代码不需要进行跨平台的重新编译。

　　这种工具已经出现有一段时间了，更准确地说是从2002年就出现了，所以，其实它已经不是新生事物了，但是它的最新版本新增了让部署在云中的应用可以进行互操作的功能。它支持所有通信场景： 局域云(intra-cloud)、广域云(inter-cloud)、本地到云、云到本地、或者这些类型的组合，如下图所示：

　　当跨Internet的时候，JNBridgePro会在组件之间使用HTTP和SOAP进行通信。我们采访了JNBridge的CTO Wayne Citrin，向他询问关于选择互操作解决方案的问题：

　　InfoQ： 你能谈一下JNBridge的跨进程通信吗? 那不是应该通过消息队列或者web服务API来处理的吗，那样你可以使特定的实例与给定的服务解耦。

　　Wayne Citrin:是的，当你想要让多个实例与给定的服务解耦的时候，你可能会想到使用消息队列和Web服务API，但是，即便是在那些“无状态”的服务中，对与复杂请求的处理也可能需要复杂的中间状态。在那些服务中会有多个组件，其中一些可能是在Java中实现的，而还有一些可能是在.NET中实现的，这时使用一种紧耦合且带有状态的方式把它们连接在一起就会更加合适。基于.NET和Java的组件可以运行在同一个实例的不同进程中，在这种情况下，JNBridgePro机制可能比松耦合的机制更合适。或者，Java和.NET可以运行在云组件的相同进程中，JNBridgePro也可以对其进行处理。

　　在其它情况下，云中的遗留代码可能无法使用消息或者web服务，也无法使用这些机制，我们也可以使用JNBridgePro来支持跨平台/跨进程的通信，而不需要对遗留应用程序做变更。 另外，消息和面向服务的API通常会有很多限制，并且不会暴露出特定的模块通过直接API所提供的所有功能——JNBridgePro让我们可以访问所有丰富的API，不管是在单独的实例中、在单独的云中，还是在云之间，和传统的web服务或者消息相比它都会拥有更高的吞吐量。

　　最后，即便是在使用web服务API的地方，也并不是每个云服务都提供基于.NET和基于Java的客户端stub。 在这样的情况下，针对特定的、不存在客户端stub的平台，我们不会直接生成web请求，而可能会采用更方便的、使用其他平台的客户端程序库的方式，并通过JNBridgePro的进程内互操作来进行跨平台访问。