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 的进程内互操作来进行跨平台访问。
评论