CCM 简介

组件

为什么要用软件组件：

1．组件可以替换和升级

2．降低了系统复杂度，分而治之

3．可重用

组件，定义为

1．功能和数据之间的协同定位，产生聚合

2．封装软件模块以减少耦合；将组件的使用者与数据存储和功能实现隔离

3．不论状态如何，提供一个唯一的身份ID

基于组件的软件的目标是，在系统内，创建工作良好的高聚合的模块；通过不同任务模块的分离，降低组件的耦合度。这就要求系统设计人员从一个对象规范向显式定义对象依赖的表达转变，并通过为依赖定义接口来实现面向对象原理的扩展。

CCM与EJB和COM

直到1999，仅有两种server-side transaction processing-oriented 组件模型：MTS/COM+ model and Sun's EJB model。直到1999年底，CORBA（语言中性、平台无关、发行商中性，可谓分布式对象计算中间件的典范，）3.0提出了第三种server-side 组件模型：CCM。

作为CORBA 3.0的亮点，CCM，是为了与Microsoft Transaction Server (MTS)/COM+, .Net（平台专有的）和Java（语言专有的）进行竞争提出的，规范了一个创建即插即用（plug-and-play）对象的框架；这将有助于集成其它基于对象的技术，特别是Java和EJB；CCM实现了CORBA与Java, COBOL, COM/DCOM, C++, Ada, and Smalltalk等的无缝集成。

尽管CCM部分地是基于EJB的，但CCM远不止于此，如OMG主席兼CEO，Richard Soley所说：CORBA不只关于Java的，尽管我们为将Java集成到平台中做了大量工作，但我们还需要这样一个模型工作在C++，COBOL，Small Talk，ADA等其它语言上，那就是CCM。把语言偏好放在一边，CCM所做的就是将如何定义组件接口标准化了。

CCM不象MTS，而与EJB非常相似。OMG的CCM规范是Sun的EJB规范的语言中性的超集；CCM规范假定组件和容器（containers/servers）可以用任何语言实现并可以在任何平台上运行，前提是用CORBA提供中间件的通讯支持。

CCM远比EJB模型复杂，因为它要提供许多选项支持不同平台上的面向对象语言。OMG的组件模型定义为OMA的元对象设施（Meta Object Facility，即MOF）的一个轮廓，这保证了模型本身更严格；这也意味着它可以系统地与其它MOF轮廓交互，如UML、XMI、OMG的工作流规范、以及OMG将来的商业对象标准。除了有助于与其它规范的衔接外，CCM更精确的规范提供了比EJB更高级的特征。如，尽管EJB模型支持组装描述器（assembly descriptor），但从总体上元模型在描述一个组件上不太精确，因此束缚了开发人员的手脚；相反，CCM建立在更精确的元模型之上，并支持更复杂的组装。使用CCM，基于声明的支持和利用的多个接口，或者基于声明的发布和利用的事件，开发者可以有效地将这些组件联系起来。同一开发者还可以描述那些部分是主机协同定位的那些是进程协同定位的。

另外，CORBA3.0增加了CORBA脚本语言规范，这将简化CORBA开发，并使得使用脚本组合组件成为可能。

Inprise, IBM, BEA Systems, and IONA Technologies都声明将支持CORBA3.0。但Oracle, Sun and IBM好象对CCM的出现失去了兴趣。

显然，实现CCM容器和Server的产品可以隐藏许多细节，有些还可以只实现CCM规范的一部分——就象有的CORBA产品可能就选择支持几个OMG服务。目前，只有两家商家提出实现CCM（IONA 和BEA），并也都只是实现核心CCM。

CORBA 2.x的缺陷

尽管传统的CORBA（包括2.3以前的版本）对象模型提供了一个标准的中间件框架使得CORBA对象可以互操作，CORBA定义了软总线使得客户程序可以激发对象上的操作而不管这个对象在本地还是远处，并提供了有标准接口的对象服务（如naming, trading, and event notification.）使得开发人员能使用不同供应商提供的服务来集成和组装庞大的分布式应用和系统，但还是有一些需求没有解决（这些缺陷容易导致紧耦合）：

l 没有一个配置对象实现的标准方式，如，对象实现的发布、安装、激活等。因此系统设计人员就不得不使用特别地策略来实例化系统中地所有对象。

l 缺少对CORBA server中公共编程术语地支持，期待着能自动生成公共用例程序。如，尽管POA提供了对象注册、激活、去活地标准接口和足够灵活地策略来配置服务地行为，但很多应用程序只需要其中地部分配置，而且开发人员还要学习这些策略以得到期望地行为。

l 难于扩展对象地功能。在传统地CORBA对象模型中，对象只能通过继承（而不是组合）来扩展，应用程序开发人员必须先定义一个IDL接口、实现该接口、并在所有server中配置该实现。但CORBA IDL的多重继承是有缺陷的，因为有的语言不支持重载；另外，应用程序可能用同一个IDL接口多次发布服务的多个实现或多个实例，但多重继承使得不可能不止一次的发布同一接口或客户确定哪一个最下层的版本。

l 能够利用多种CORBA对象服务并不见得是好事。CORBA规范并没有强制运行时使用哪一个CORBA对象服务，对象开发人员不得不在设计系统时用特别的策略来配置或激活这些服务。

l 没有标准的对象生命周期管理。尽管CORBA对象服务定义了生命周期服务，但其使用也不是强制性的。因此，客户需要显式的知识通过特殊的方式来管理对象的生命周期。另外，通过对象生命周期管理对象，开发人员必须明白这个事实，并必须定义辅助接口来控制对象的生命周期。定义这些辅助接口是比较枯燥的，可能的话，CORBA规范应将这一过程自动化。

OMG IDL 总是允许您创建基于继承的对象关系。然而，很多时候，我们的设计需要支持包含多个接口的对象，而这些接口是通过组合而不是通过继承来构造的。对象继承允许您依照另一个类来定义这个类的实现，而对象组合允许您通过将对象集合或组合在一起来定义一个类。OMG IDL 需要表达组合和继承的能力。

CCM规范

概述

CCM规范扩展了CORBA2.x，包括events, exported interfaces and methods, special configuration interfaces, pass-by-value (mobile code), and messaging/asynchronous invocation等。

OMG的CCM标准分为两部分核心的CCM规范和扩展的CCM规范。

核心的CCM规范支持EJB组件；如果只实现了核心的CCM规范，就意味着有了一个CORBA container和server来管理用Java写的EJB组件。

扩展的CCM规范包含了远远超出EJB组件和容器/Server的能力。实现了核心和扩展CCM规范的产品将能够支持EJB的组件和用OMG所支持的其它语言写的组件；开发人员就能够做超过现在的EJB模型的能力的工作了。

CCM通过定义一些特征和服务以允许应用程序编程人员实现、管理、配置和使用由在标准环境下的CORBA服务集成的组件来扩展CORBA对象模型，这些CORBA服务包括persistence, security, transaction, and event services等。CCM标准不只使得服务方更多的软件可重用，而且为动态配置CORBA应用程序提供了更大的灵活性。

用CCM开发的一个例子：

组件的开发者定义组件实现所有支持的IDL接口，并使用CCM供应商所提供的工具实现组件。如此这般，组件实现接下来可以被打包到一个DLL中。最后，利用CCM供应商所提供的装配机制将组件装配到一个组件server中，这个server是一个通过加载相关DLL来宿主组件实现的独立的进程。这样，组件就组件server中运行，并可以处理客户请求了。

CCM的主要贡献就是以CORBA作为其中间件框架将上面所描述的循环的开发过程标准化了。

Client View

定义一个组件:

interface A, B; // Forward declaration.

component Foo supports A, B // Definition of equivalent interface

{ // and its supported interfaces.

provides W, X, Y, Z; // Facets (provided interfaces.)

. . . // Other component definitions.

};

一个组件Foo实例的引用看起来和接口Foo实例的一个普通的CORBA对象的引用一样。因此，一个对组件没有意识的客户程序可以通过组件的等价接口（equivalent interface，interface Foo）的对象引用来激活操作，等价接口唯一标识该组件实例。作为一个普通的CORBA对象，组件的等价接口可以继承于其它接口，这些接口称为支持接口（supported interface）。

为使用对象组合，CCM在组件中增加了小平面（facet，晶面或许更确切些），又称为提供接口（provided interface），这些接口是由组件提供的，并不一定和supported interface有关。CCM 的facet是根据Extension Interface模式设计的，和Microsoft的COM中的接口相似。

CORBA::CCMObject中定义了一个Navigation接口，所有的组件的等价接口都继承于CORBA::CCMObject。客户可以使用Navigation接口上的操作来枚举组件所提供的所有的facet。这样，客户程序只要由一个facet的引用就可以用标准的get_component()操作得到组件的等价接口的一个引用。在CCM对象模型中增加facet大大增强了组件的可重用性。

Component Lifecycle Management:

对于server来说，正确的处理组件的生命周期管理是重要的，同样，对于client来说帮助组件server管理它们的组件实例的生命周期也是重要的。为将组件生命周期管理接口标准化，CCM引入了一个新的关键字home来指定每个组件的生命周期管理策略。

客户程序可以用home接口来控制它所使用的组件实例的生命周期。每个home接口准确地管理一类组件。一个home可以是keyed也可以是keyless。keyless类型的home通常支持factory的操作以创建组件的新的实例；相反，keyed类型的home通常支持finder的操作以允许客户程序能通过它们所提供的键来检索持久组件实例。客户端可以通过调用home接口上的remove_component()操作来通知组件server以指示某个组件实例已经不再需要了。组件server则根据它实现的策略来决定如何删除该组件。

Component Usage Scenarios:

要使用一个组件，客户必须先得到该组件的home接口。然而，客户端需要一种标准的引导机制来定位组件的home接口。为简化这个引导过程，所能得到的组件的home的引用可以集中存储在一个中心数据库中，这样，所有要自引导的客户端就可以从中心数据库来得到一个引用。为使用这个中心数据库，CCM规范定义了一个HomeFinder接口，该接口类似于CORBA 可互操作名字服务INS。客户程序先用标准的CORBA引导API resolve_initial_references(“HomeFinder”)来得到HomeFinder接口的对象引用。CCM HomeFinder实现了组件home的一个目录服务，客户可以用它来定位并获得所要得到的组件的home的引用。一旦，客户得到了home接口的一个引用，它就激活适当工厂操作来创建或查找目标组件的引用了。

Component Developer View

Components:

CCM规范扩展了CORBA IDL以支持组件。正如在CORBA对象模型中定义对象接口一样，组件开发者使用IDL定义来定制组件所支持的操作。

一般来说，组件编程模型鼓励通过组合而不是继承来重用组件。为此，CCM 组件可以提供无关的接口（facet）并支持客户端的接口导航。然而，由于组件可以安装到组件server中，而组件server并没有任何逻辑知识来配置和实例化安装其中的组件，因此，组件需要另外的通用接口来帮助组件server安装和管理它们。在CCM中，组件可以通过成为port的一系列接口与外部实体，如ORB服务，其它组件，或者客户交互，这定义了一个调整组件配置的标准机制。

port机制有四种：

l facet

l receptacle

为使用组合，组件需要将它的部分操作委派给其它组件，这样就必须得到其它组件的引用，CCM称这些引用为“object connections”，并称这些关联的port名字为receptacle。receptacle提供了一种通用方式将某种类型的对象和组件关联起来。这样，组件就可以关联其它对象，包括其它组件，并激活这些对象上的操作。组件开发者可以使用receptacle来指示是否要将组件与其它对象或者组件关联。一个插座是一个抽象，具体地在一个组件上表现为一系列建立和管理关联的操作。一个组件可能展示零个活多个插座。

l event source /sink

除了可以通过激活操作相互作用外，组件还可以通过检测其它组件的状态并当状态改变事件发生时作出响应来相互作用。这种松耦合的交互是基于Observer模式的，该模式普遍应用于分布式应用的开发。组件开发者通过在组件定义中声明事件源和事件槽facet来定制组件的兴趣，发布或者订阅事件。

CORBA组件模型支持发布/订阅事件模型，该模型是设计来也CORBA notification服务相适应的。该模型所暴露的接口提供了一个简单的编程接口，它的语法可以映射到CORBA notification语法的一个子集。

l attribute

为有助于配置组件，CCM规范扩展了attribute的概念。通过配置工具属性可以用来预置组件的设置值，并存取属性的操作产生异常。组件开发者可以利用这一特点，要想在系统配置完成后修改配置属性的话就可以抛处一个异常。规范并没有限制只能将属性作为配置之外的用途，但作为配置参数是直接支持的。

这四个CCM port机制都可以为组件客户程序使用。除facet外，其它port机制基本上都是为了让CCM装配框架配置组件的。

Component home:

组件开发者可以为要管理的组件提供多个home接口以实现不同生命周期的管理策略。这些不同的生命周期策略可以用来客户化组件实例的缓冲策略活在创建时刻修改组件的行为。

Home接口上的操作分为两类：

l 由组件模型定义的操作。在某种意义上，这些操作的默认实现必须由组件使能的ORB产品提供，不要求用户编程或者介入。这些操作的实现必须有可以预测的一致的行为。因此，这些操作所要求的语法做了详细的规范。为方便起见，称这些操作为正规操作。

l 由用户定义的操作。这些操作的语法是由用户提供的实现定义的。几乎不能对这些操作的行为做任何假设。为方便起见，称这些操作为非正规操作。

Component Configuration:

在CCM中，当组件安装到组件server中时会自动配置。Port机制提供了配置组件的接口，如，可以设置对象连接，可以订阅或发布事件，可以设置组件属性。然而，应用开发人员仍然需要表达一个组件的固定配置，如，必须连接什么样的组件、组件将使用什么样的事件通道来发布和接收事件。CCM规范定义了一个标准的组件配置接口，Components::StandardConfigurator，以帮助组件server配置组件。为提高组件实现的灵活性，组件开发者可以扩展该配置接口以指定如何培植他们的组件。可选地，home接口可以获得一个组件配置对象的引用以在组件实例化的时候配置组件。

一个复杂的组件可能需要几个操作来发布/订阅事件，并在配置完成前建立对象连接。为防止客户访问一个未初始化完的组件，CCM框架将组件操作的状态分为configuration phase和operation phase。CCM在每个组件接口中定义了一个标准操作configuration_complete()。该操作将被组件配置接口调用以实现从configuration phase 向operation phase的转变。组件开发者可在configuration pahse后限制访问某些只能配置的操作。

Component Implementation Framework (CIF):

许多商业应用使用组件来模型化现实世界中的实体，如雇员、银行帐户和股票代理等。通常，这些实体由数据库实体代表，并永久保存。

CIF为构造组件实现定义了一个编程模型。组件和组件home的实现在CIDL中描述。CIF使用CIDL描述来生成编程框架skeleton以使得基本的组件行为自动化，包括导航、身份查询、激活、状态管理、生命周期管理等。作为一个编程抽象，CIF是设计来与现存的POA框架相适应的，但将开发人员与其复杂性相隔离。

CIF定义了一个用来管理组件的持久状态和构造组件实现的编程模型。组件拥有持久状态，指当这些组件的实例向永久数据映射的时候，这些永久数据都能回忆起来，不论何时组件实例激活。

CCM定义了一种描述性语言，CIDL，以描述组件和组件home的实现和持久状态。

CIDL所生成的实现称为executor。Executor包含了一些自动实现，并提供了钩子方法以允许开发人员可以增加定制的组件专门的逻辑。Executor可以打包到DLL中，并可以安装到支持特定目标平台和编程语言的组件server中。

另外，CIDL服务生成组件描述器（XML格式），它描述了组件的特征以及所描述的组件所需要的服务的类型。

Containers:

组件实现依赖于POA将到达的客户请求派发到相应的仆从上。CCM container实现了如何让组件于本地的运行时环境互作用，如创建它的POA等级树和定位CCM定义的通用服务等，并能在某个事件发生时通过回调通知组件。CCM container编程模型定义了一系列的API以简化开发和（或）配置CORBA应用。一个container封装一个组件实现并使用这些API向所管理的组件提供运行时环境。容器是为CORBA组件实现提供的server的运行时环境。该环境是用一个装载平台实现的，这样的平台是一个应用server或一个象IDE的开发平台。典型地，一个装载平台提供了一个健壮的运行环境以支持大量用户并发。

典型地，这个运行时环境提供如下特征：

l 激活或钝化组件实现以保护有限的系统资源，如主内存。

l 为常用的服务提供一个适配层，包括Transaction, Persistence, Security, and Notification services。该适配层免去了客户程序通过前向转发请求到CCM管理的真正的服务来定位这些服务的麻烦。

l 为回调提供一个适配层，容器和ORB可以用来在感兴趣的事件发生时通知组件，如来自事务服务或通知服务的消息。

l 管理POA策略以决定如何创建组件的引用

客户程序直接访问组件的外部接口，组件通过container的API访问ORB的功能。每个container管理一个由CIF定义的组件实现。对于所管理的所有接口，Container创建它自己的POA。这些接口可以如下分类：

外部API：这类接口由组件提供，并包括等价接口，facets，和组件的home接口。客户可以直接访问外部接口。

容器API：这类接口包括组件用来访问container支持的服务的内部接口，以及container可以在组件上调用的回调接口。

通过这些接口的协作，container为所管理的组件提供了访问它的POA和其它CCM使能的ORB所提供的服务。

CCM container还管理组件仆从的寿命，有四种类型的仆从寿命策略——methode，session，component，container——用来控制组件激活和去活的定时。

CCM供应商应定义一个ServantLocator来负责支持这些策略。一旦安装，POA就委派激活和钝化仆从的责任给这个ServantLocator。

method和session策略使得ServantLocator为每次激活方法或会话都要激活和钝化组件；而component和container策略分别将仆从的寿命策略交由组件和容器来决定。高质量的CCM容器应提供组件实例的缓存和与executor的动态连接和断连，以达到组件性能和资源利用之间的平衡。

Component Categories:

CCM规范期望不同应用能通过不同的方式使用组件。如，有些应用总是将组件实例映射到一个特殊的持久数据存储中，而其它的将根本没有持久状态。为此，CORBA对象模型定义了CORBA usage model，该模型将对象引用分类为暂态或持久的。CCM component category model模型扩展了原来的CORBA usage model，以定义container API类型和CORBA usage模型的合法组合。组件开发者在CIDL文件中指定组件的组件目录，并且编译器服务生成和指定的组件目录相匹配的适当的接口。

service组件没有状态，并且只控制系统的行为，如wrappers for legacy procedural 应用。session组件，如iterator对象，维护一个暂时的状态，该状态通常与事务相关联。process组件，如business process对象，有一个客户不客见的持久状态，并可能与事务相关联。entity组件，如inventory组件，可能具有与事务相关联的操作，并有对客户可见的持久状态，实体组件必须通过键进行索引。

为管理有和没有持久状态的组件引用，容器编程模型定义了两类容器接口：（1）session container接口，用来管理暂态组件，和（2）entity container接口，用来管理持久组件。容器编程模型用CORBA usage模型来指定在一个container、它的POA和CORBA服务，如Notification和Transaction服务，之间所要求的交互模式。进一步，CCM容器编程模型可以采用POA的高级特征来实现多个CORBA对象使用单个仆从。另外，为保护内存资源，一个容器可以决定是否在需要的时候激活对象。

Packaging and Deployment:

经验表明建立可重用的组件必须在提供定义良好的作用域合理的功能和提供足够的灵活性和通用性以达到为多种可能应用程序可用之间做处艰难的折衷。

在大规模的分布式系统中，组件实现可能被多个server装载，通常这些server用不同的实现语言，不同操作系统，不同的编译器。甚至，组件实现常常依赖于其它的组件实现。

为解决组件的打包和装载以及协同定位等问题，CCM定义了标准的技术和模式以简化组件开发者打包和装载组件的工作。CCM使用Open Software Description(OSD)来描述组件及它们之间的依赖性，OSD是由WWW协会制定的XML Document Type Definition（DTD）。组件打包到DLL中，包描述器是符合OSD DTD的XML文档，包描述器描述了DLL的内容以及其依赖性。

组件可以依赖于其它组件，另外，组件可能要求它所依赖的组件通过包描述器协同定位。

除在CIF中定义了组件描述器外，CCM OSD还定义了component assembly descriptor，这些描述器特征化了关键的组件装载信息，如汇编指令和交叉连接的拓扑结构。可以定义个标准的汇编接口以支持自动装载。CCM使能的ORB所支持的汇编机制利用在组件描述器和其它开发者所指定的汇编指令工作。装载机制允许新的或修改的组件的远程安装和激活。

ORB扩展

CCM规范增加了许多ORB扩展以简化CCM框架的实现。这些扩展中的大部分并不直接影响组件开发人员实现组件，但有些扩展帮助开发人员提高组件的性能或简化必要的工作。扩展主要包括如下几个方面：

Locality-constrained interfaces:

CCM引进了新的关键字local来定义仅限本地使用的接口的定义，并减少了一些模棱两可的地方。这对以server为中心的组件开发是非常重要的，因为这有助于提高性能和减少内存裂痕。

Extensions to the Interface Repository:

IR是一个标准的CORBA机制以允许应用程序在运行时发现IDL接口和数据类型的定义。事实上，IR提供了CORBA的内省能力。CCM扩展了IR以支持组件，并提供遍历所有组件接口的操作。接口内省在CCM编程模型中起了主要的作用，因为这使得在运行时组件能够适配一个不了解的组件。尽管IR定义了一个组件内省机制，但继承于CCMObject的内省机制会更有效，因为在其上激活操作是协同定位的。

Extension to IDL Language:

在以往的CORBA规范中，IDL编译器依赖于C预编译器的原文包含能力来导入外部的IDL构造；同时用#pragma指令来定义IR ID。不幸的是，这些特征导致了不同于C/C++语言的外部构造，另外C预编译器的原文替换并没有考虑IDL的作用域规则。因此，CCM规范扩展IDL语言的构造为导入定义在一个单独文件中的IDL类型的声明，并定义了一个标准的机制来控制IR ID。

OMG CIDL符合OMG IDL同样的词法规则，尽管为描述组件实现增加了一些新的关键字。OMG CIDL语法是OMG IDL语法的一个扩展，OMG CIDL是一个描述性的语言，CIDL文件必须使用“.cld”扩展名。

一个组件的定义是一个接口定义的特殊化和扩展。component 关键字是 CIDL 的添加物之一。component 允许 IDL 设计者在其主体内包含该组件的任何属性声明，以及连同一起的组件平面（组件暴露给外界的接口）和容器（组件使用的接口）的声明与该组件可能需要的任何事件的源和接收器。然而，请注意，方法中不允许包含 component 关键字。这是因为我们不是在创建接口－我们是在组合接口来形成“组件”。

有两个组件水平：basic和extended，都是通过组件home管理的，但它们所具有的能力是不同的。基本组件提供了一种简单的机制来组件化一个标准的CORBA对象，它在功能上与Enterprise JavaBean中定义的一个EJB非常相似；扩展组件提供了更丰富的功能。基本组件不支持facet。

所有平面、容器、事件源、事件接收器和属性的声明都映射到生成等价接口（CIDL 规范用这个术语来称谓）的操作。我的理解是 CORBA 3.0 CIDL 编译器会为您从组件定义自动生成等价接口。

等价接口中的操作允许组件的客户机检索其平面的引用。除此之外，所有组件从组件基本接口 CCMObject 那继承，该基本接口提供了带一般导航操作（通过 Components::Navigation 接口）的等价接口。

Components::Navigation 功能：

module Components {

valuetype FacetDescription {

public CORBA::RepositoryId InterfaceID;

public FeatureName Name;

};

valuetype Facet:FacetDescription {

public Object ref;

};

typedef sequence<Facet> Facets;

typedef sequence<FacetDescription> FacetDescriptions;

exception InvalidName{};

interface Navigation {

Object provide_facet(in FeatureName name)

raises (InvalidName);

FacetDescriptions describe_facets();

Facets provide_all_facets();

Facets provide_named_facets (in NameList names)

raises (InvalidName);

boolean same_component(in Object ref);

};

生成等价接口是用来提供组件接口导航。所有组件接口都会继承它。如果您熟悉 COM 世界，这会使您想起来自 IUnknown 的 QueryInterface() 和在 CoCreateInstanceEx() 中使用的 Multi_QI 结构。通过该导航提供类似以下的行为：

l provide_facet() 方法返回由 name 参数表示的平面的引用，或者如果没有发现由那个 name 参数表示的平面，则返回 InvalidName 异常。

l describe_facets() 操作返回由组件提供的所有平面的序列。返回的值类型 FacetDescription 将包含 RepositoryId 和该平面的名称。

l provide_all_facets() 类似于 describe_facets，但返回的值类型现在将包含支持每个平面的对象的引用。

l provide_named_facets() 将取一列名称，并返回包含 names 参数中平面的描述和引用的序列（在结构上与 provide_all_facets() 中返回的结构是一致的）。

l same_component() 将允许客户机决定是否两个引用属于同一个组件实例。该方法是组件实现相关。

基于 CORBA 的系统，IDL 是基本的构建技术。通过扩展 CIDL，OMG 维护了其语言和平台的中立，但推动了结合坚实工程原则的软件标准。