级别： 初级 Paul Harmon (pharmon@slip.net)Cutter Consortium 分布式计算体系结构咨询服务部高级顾问
2000 年 6 月 01 日 对象管理组织 (OMG) 最近批准了一种新的服务器端组件模型，该模型是对 Microsoft 的 Transaction Server (MTS)/COM+ 和 Enterprise JavaBeans (EJB) 模型的挑战。Paul Harmon 讲述了这种模型的功能、推广前景以及 Microsoft 和 Sun 对它的反应。
在整个 1999
年中，只有两种服务器端的、面向事务处理的组件模型：MTS/COM+ 模型和
Sun 的 EJB 模型。在 1999 年即将结束时，OMG 经过投票批准了 CORBA
组件模型
(CCM)，从而引入了第三种服务器端的组件模型。在本文中，我想简要说明一下
OMG 的 CCM 规范的特点，然后展望一下它对软件开发可能产生的影响。
Microsoft 的 MTS/COM+ 实际上是一套集成在 Windows
操作系统中的产品，与之不同，OMG 的 CCM 模型类似于 Sun 的 EJB 模型
-- 它是一个已发布的规范，必须由公司或厂商实现以后才能使用。
稍为广义一点来说，OMG 的 CCM 规范是 Sun 的 EJB
规范与语言无关的超集。Sun 假定 EJB 组件和容器/服务器将用 Java
语言编写，并运行于已安装了Java 虚拟机和 Java
开发工具包的平台顶层。另一方面，CCM
规范设想组件和容器/服务器可用任何语言编写，并可运行于任何平台上。很明显，OMG
假定使用 CCM 的开发人员也将使用 CORBA 来提供中间件通信，但因为 EJB
规范现在也要求用因特网互操作性协议
(IIOP)，所以这一点并没有在这两种模型之间分出高低。
CORBA 组件模型的核心
从本质上讲，OMG 的 CCM 标准分为两个部分。一部分是核心 CCM
规范，它支持 EJB 组件，如果公司仅实现核心 CCM
规范，则他们实际上将有一个 CORBA 容器和服务器，可用来管理用 Java
语言编写的 EJB 组件。另一部分是扩展的 CCM 规范，它包括 EJB
组件和容器/服务器不具备的功能。对于同时实现 CCM
规范的核心部分和扩展部分的厂商，他们将能够同时支持 EJB 组件以及用
OMG 所支持的其他语言编写的组件。在这种情况下，开发人员将能够完成
EJB 模型目前的功能所无法完成的事情。
由于要支持更多的选项，CCM 比 EJB
模型更复杂，因为它必须支持运行于不同平台上的多种 OO 语言。OMG
的组件模型是作为 OMG 的元对象工具 (MOF)
的概要来定义的；这保证了模型本身更为严格。这也意味着它可与其他 MOF
概要系统地对接，这些概要包括统一建模语言 (UML)、XML 元交换
(XMI)、OMG 工作流程规范和 OMG
即将出台的业务对象标准等。除了便于链接到其他标准之外，CCM
的精确规范还支持比 EJB 功能更先进的几项功能部件。例如，尽管 EJB
模型支持组合描述符，但在描述组件时整个 EJB
元模型的精确性较差，因此限制了开发人员的能力发挥。相反，CCM
建立于其更精确的元模型基础之上，能支持更复杂的组合。使用
CCM，开发人员可以根据组件所声明的条件和实际使用的多个接口，或者根据组件所声明的信息和实际使用的事件，将这些组件连接在一起。同一个开发人员还可以说明哪些部分必须是与主机搭配的，哪些部分是必须与进程搭配的。
显然，实现 CCM
容器和服务器的厂商可以屏蔽大量细节，某些厂商可能选择创建一个支持部分
CCM 标准的实现 -- 正像 CORBA 厂商选择支持某些 OMG 服务而不支持其他
OMG 服务一样。事实上，到目前为止，我只听说两家厂商（IONA 和
BEA）承诺实现 CCM，并且他们都表示最初将只实现 CCM
模型的核心。因为核心 CCM 模型实际上只是 EJB 模型的 CORBA
容器，这代表厂商方面的最小承诺。
从使用 EJB 模型标准或 CCM
标准的公司都可以使用它们各自的规范这一意义来讲，这两个标准都是开放式标准。但
CCM 是更开放的标准，因为如果要更改 CCM，参加 OMG
的公司将需要对这一更改进行投票表决。相反，Sun 却可以随时更改 EJB
标准而无须和任何人协商，虽然这种情况不太可能发生。
基本情况就是这样，那么在未来几年内服务器组件市场有可能发生什么情况呢？
建立关系
显然，因为 CCM 规范在 1999
年末才批准，所以在厂商提供这一新模型的实现之前还需要一段时间。即使到那时，按我的推测，可能也只是核心
CCM 模型的实现，而不是整个规范的实现。在这种情况下，我不指望 CCM
标准最早能在 2001 年之前对组件市场有什么重大影响。而且，考虑到
MTS/COM+ 和 EJB 组件市场的建立如此之好，很难想象 CCM
会占领大部分服务器端组件的市场。
最初，CCM
市场将很可能由少数几家大公司推动。有几十家主要公司依赖于 CORBA
来集成企业应用程序，其中某些公司依赖于从商家获得的 CORBA
实现，另一些则依赖于他们自己开发的 CORBA 实现，后者将是首先转向 CCM
的公司，他们将使用 CCM 扩展其现有的 CORBA EAI
工作。换句话说，他们也希望能够用任何一种企业语言开发组件，而无须担心最终实施这些组件所用的语言或平台。之所以也使用
CCM，则是因为 CCM 保证可以与他们已采用的其他标准集成，包括 MOF、UML
和 XMI
等标准。当然，因为这些公司更富有经验并面临更复杂的建模问题，所以他们将发现
CCM 的某些高级功能部件为他们提供了胜过 EJB
模型的优势。其中某些公司将自己实现 CCM 并创建 CCM
服务器，而另外一些公司将很可能与某一现有的厂商合作，创建 CCM
容器和服务器实现。
但是，组件市场的主要部分仍会将注意力集中在 MTS/COM+ 和 EJB
模型上，因为已对 COM+ 和 EJB
模型作出承诺的公司任何时候都不会很快转向
CCM。大多数公司正在为转向面向因特网的业务模式而奋斗，他们将希望继续使用他们熟悉的模型
--
这些模型不仅为开发工具所支持，也受到历经数年测试的应用程序服务器的支持。
请回想一下，最初 Sun 并不打算将 CORBA 作为其 Java、JavaBeans 和
EJB 规范的一部分加以支持。它提出自己的 ORB：远程方法调用
(RMI)。某些 Java 开发人员仍然极其信赖 RMI。但是在最初的 Java
编程热逐渐减弱以后，Sun 认识到各公司不会一夜之间转向 Java 技术。Sun
还认识到，在开发人员开始使用 Java
语言进行企业开发时，它必须提供对非 Java
语言和旧的应用程序的支持。Sun 当时有两种选择，一种选择是，扩展其
RMI 协议使其支持其他语言，如果这样的话，RMI 实际上将变成第二个
IIOP；另一种选择是，将 EJB 模型链接到
IIOP，以使他们自己及其客户无须面对重新朔造 RMI 的问题，无须面对与
CORBA 竞争有关的问题。而 Sun 的选择是，并入了 IIOP。
当前组件集合的短期效应
我认为现在 Sun 和 EJB 模型处于与 OMG 的新 CCM 标准相似的关系中。CCM
标准尚未就绪，人们要了解 CCM
并开发出可以说明这一标准全貌的实现，至少需要两到三年的时间。同时，随着各公司使用
EJB 组件建立更大的应用程序，他们将日渐需要混合使用 Java
语言和其它语言建立的组件。更重要的是，开发人员将发现 EJB
模型中缺少一些功能，比如说，根据声明的条件和实际使用的多个接口将组件连接在一起的选择。到某个时候
-- 可能三年以后 -- Sun 将不得不决定是继续扩展 EJB
标准（这实际上是重新朔造 CCM），还是使 EJB 模型发展为 CCM。
换句话说，OMG 的 CORBA
组件模型在未来几年内不会是服务器端组件市场的主要竞争者。这一市场仍将由
MTS/COM+ 和 Enterprise JavaBeans
技术所支配。仅有少数几家大公司可能会在近期采用 CCM。然而，OMG
所做的工作是，创建了未来的组件模型。随着各公司对基于组件的开发变得更加熟悉，他们将认识到为什么需要
EJB 技术中没有的某些 CCM 功能部件。到某个时候，Sun 很可能会发展 EJB
模型以并入 CCM 的高级功能部件，正像它已将 IIOP 并入 EJB
技术以扩展其中间件功能一样。
参考资料
希望了解 EJB 模型可能的发展方向的开发人员可以研究 CCM 模型，以了解
OMG 的特别工作组是如何扩展 EJB 模型的。要获得 CCM 规范，请检查
OMG 网站。
关于作者
对本文的评价
| 
