一、jCOM简介
据Gartner的研究分析，在名列全球前1000名的企业中，大约90%都混合应用了java和Windows技术。然而，Java技术和微软技术分别提供了丰富但却迥然不同的解决方案，或至少说这两种方案之间的差异是巨大的。
为了解决这一矛盾，Sun率先提出了JNI解决方案。JNI，即Java本机接口，是编写Java本机方法和把Java虚拟机嵌入到本机应用程序中的标准编程接口。Java本机接口的主要目的就是保证本机方法库在不同平台上的Java虚拟机中的二进制兼容性。使用JNI编写程序，就可以很方便地做到程序的跨平台可移植。尽管如此，Sun提供的JNI解决方案只是底层的API包装，在实际开发中用到大量Java/COM互操作时，直接从JNI级进行开发显然效率并不高。
为此，大大小小的公司甚至个人都试图提供全部或局部的Java/COM互操作解决方案。例如，WebLogic提供的jCOM技术，bridge2java（IBM提供的基于Java本机接口和COM技术，答应把ActiveX对象轻易地集成到Java环境中），jacoZoom（是一个java类库—它答应你在java程序中使用ActiveX控件和ActiveX服务器，基于Java本机接口和COM技术，答应使用于Windows平台上的任何java环境中），J-Integra for COM（http://j-integra.intrinsyc.com/），还有一个小型的JCom桥接库（http://sourceforge.net/PRojects/jcom/，它也支持从Java中调用COM对象，例如Excel工作簿，VB的COM对象等）。其中，WebLogic提供的jCOM技术为微软的COM对象和Java对象提供一个稳定、无缝的机制，让这两种对象可以协同工作。
jCOM，即Java／COM桥，它是一种用软件实现的桥接机制，可以帮助Java应用程序快速访问微软的COM／DCOM组件。而且，微软的COM应用程序也可以通过这个机制访问基于Java的对象。jCOM不仅具有实现相对简单的特点，而且其最吸人的部分在于它的透明性。对Java程序员来说，COM对象看起来与其他Java对象没有什么不同。而对COM开发人员来说，远程Java对象看起来就象是本机COM组件。在这些对象中可以找到jCOM运行时刻引擎进行动态类型映射，因此从表面上屏蔽了数据类型间的差异。远程对象的数据类型被动态地转换成调用程序所使用的基元类型。对Java开发人员来说，COM数据类型表现得就象Java基元类型；而对COM开发人员来说，Java数据类型看起来就象是COM数据类型。
本文将重点讨论BEA的Java/COM解决方案。
二、jCOM工作原理
jCOM声称以双向方式工作，实际只是答应在Java和COM组件之间，在任意一个方向上通信—Java对象可以调用COM组件，COM组件又可以调用Java对象。当然，在这两种不同的分布式组件框架之间，有着两种截然不同的底层体系结构负责线路级通信。在运行时，jCOM内部设置了一个双协议栈环境，实现对底层两个彼此独立的基础结构的支持(参考图1）。对于COM组件，有一个在DCE远程过程调用之上的COM／DCOM实现。对于Java对象，有一个在Java远程方法IIOP（Internet Inter-ORB）之上的远程方法调用（RMI）实现。调用要通过这些协议栈，并通过内部的协议转换进行处理，内部的协议转换能够有效地屏蔽掉低一级的协议。对于EJB来说，来自COM客户的调用看起来就似乎是来自Java客户的调用。对于COM组件来说，来自Java客户的调用看起来就好象是来自一个普通的COM客户。
jCOM提供了能够自动生成更高级别COM／DCOM代理以及RMI存根的工具。客户程序用COM／DCOM代理以及RMI存根在这两个不同的基础结构间封装并传送调用。jCOM可以设置成本机模式，这样就可以利用本机操作系统的动态链接库，从而减轻DCOM的网络负荷，并极大地提高系统性能。
下面看一下Java对象如何调用COM对象：
import com.jCOMSample.account.*;
clsaccount account=new clsaccount();
double accountbalance=getaccountbalance("Xiao Wang");
图1演示了当Java对象访问COM组件的时候事件产生的标准流程。首先，jCOM为要访问的COM组件生成—个代理对象，Java对象开始调用这个代理对象。然后，代理对象与jCOM运行时引擎通信，jCOM运行时引擎又把代理对象的消息封装成远程过程调用的COM／DCOM形式，通过TCP／ip发送到Windows环境里的COM组件。在最低的一层上，jCOM使用服务器上的标准Java网络类进行调用。
图1.jCOM运行时刻环境 点击看原图
