最近InfoQ的站点上刊登了一系列关于.NET与Java互操作的文章,InfoQ中文站点计划五月底之前也将把这一系列文章翻译上线,于是仔细读了其中几篇文章,顺便对两种运行时环境下互操作的实现有了一点了解。
关于互操作这个话题,貌似不明真相的Ricepig同学曾放言说:JVM与CLR两个运行时环境下的互操作实现,除了服务层面上的集成,其余都是空谈。对此观点表示一定的保留意见,且不说早已存在的Java本地接口项目JNI和GlueGen的存在,单是最近发布的JNBridge 3.1就提供了Java 和.NET代码运行在JVM或CLR之上的跨平台机制,甚至可以实现不同语言程序运行时的内存共享。并且在分布式集群环境下,借助于JNBridge的跨语言平台的代码调用同样也可以实现。
还不太清楚互操作是否只是局限在不同语言类库间的相互调用,是否Java嵌入C语言代码也像C嵌入Python代码或C中嵌入汇编一样可以实现。如果真的是这样,运行在Java虚拟机和.NET通用语言运行时CLR之上的代码互操作将是很令人期待的技术。当然,互操作的实现最终还是需要借助于技术主导厂商之间的合作,比如微软与SUN提供技术上融合的解决方案。除此之外,性能问题也是互操作的需要考虑的因素之一,毕竟代码在非原生运行时环境下的执行效率还不清楚,但可以肯定的是,互操作应该会对单一平台的代码执行效率产生一定影响。
关于互操作这个主题,TSS的站点上也给出了一系列文章,包含消息传递、网络服务、分布式对象、商业流程整合等众多的内容,如果感兴趣可以进一步深入学习。
啥叫服务层面上的集成啊?
其实我觉得,如果是要.net和java互操作的话,还是SOA这种体系是未来的趋势,而且SOA更加广泛了,不单单支持这两种平台了。
要不就通过某种通讯协议互操作,比如说SOA,通过HTTP/SOAP,或者直接TCP/IP
要不就在CLR上写个Java编译器或者在JVM上写一个C#编译器。貌似这种解决方案基本不可能完整,因为达不到100%兼容。
至少我用过的Hessian这个东西效率就很低,特别是对于数据密集型应用,比如GIS,可以说是完全不可用。