组件对象模型（component object model，com）是微软公司于1993年创建的一种软件组件结构标准。目的是为了使应用程序更易于定制。把一个庞大的应用程序分成多个模块，每一个模块保持功能独立性，在协同工作时，通过相互之间的接口完成实际的任务。我们把每一个这样的模块称为com组件，这些组件可以在不同的计算机上用不同的程序设计语言单独开发，单独编译，单独调试和测试。当所有的组件开发完成后，把它们组合在一起就得到了完整的应用程序。

com是微软的activex，directx以及ole技术的基础，它被设计成一个动态互变组件的规范，为windows程序模块之间的相互通讯提供了统一的标准，只要客户和组件共同遵循这一规范，双方就可以透明地通讯。用com开发出来的组件实际上是一些小的二进制代码，可以给应用程序、操作系统以及其它组件提供一些服务。多个com组件对象可以连接起来以形成应用程序或组件系统，并且组件可以在运行时、不重新链接或编译应用程序的情况下被卸下或替换掉。

那JCom呢？

jCOM，即Java／COM桥，它是一种用软件实现的桥接机制，可以帮助Java应用程序快速访问微软的COM／DCOM组件。而且，微软的COM应用程序也可以通过这个机制访问基于Java的对象。jCOM不仅具有实现相对简单的特点，而且其最吸人的部分在于它的透明性。对Java程序员来说，COM对象看起来与其他Java对象没有什么不同。而对COM开发人员来说，远程Java对象看起来就象是本机COM组件。在这些对象中可以找到jCOM运行时刻引擎进行动态类型映射，因此从表面上屏蔽了数据类型间的差异。远程对象的数据类型被动态地转换成调用程序所使用的基元类型。对Java开发人员来说，COM数据类型表现得就象Java基元类型；而对COM开发人员来说，Java数据类型看起来就象是COM数据类型。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的网络负荷，并极大地提高系统性能。