介绍:
分布式计算中间件，如Corba，快速发展，当激烈的和全球的竞争使以传统方式开发和维护复杂的系统越来越困难的时候。Corba 可以让你调用在分布是对象上的操作，而不用关心它的应用底层的环境。传统的Corbar定义了一个软总线框架，制定了有标准接口的对象服务，利用Corba我们可以集成和组合大型，复杂的分布式应用系统。但传统的Corba有它的缺点：
No standard way to deploy object implementations:
没有标准的配置对象应用的方式。如：没有标准的方式分布对象应用，在它们的执行上下文安装，或在特定的ORB激活应用。因此，系统设计者必须用ad hoc策略去实例化在系统中的对象。进一步说，因为对象可能要互相依靠，实例化可能在一个大型的系统变得复杂。
??Lack of support for common programming idioms for CORBA servers:
Corba 的说明提供了丰富的应用服务的特性。在某些的应用域，仅仅有限的特性被应用。结果，通过能自动产生应用普通应用实例Corba代码的工具能支持必须的特性，是期望的。如：在Corba 2.2说明中，介绍了POA，它是一个引导客户端的请求到具体的对象应用的机制。POA提供了标准的API去登记对象应用，去活，或激活对象应用。POA是灵活的Corba编程模型模块，并且提供了大量的规则配置它的行为。然而，重要一类应用仅仅用其中的一部分，但是服务开发者不得不去学习如何配置许多的规则，为了得到想要的行为。
??Difficulty extending object functionalities:
传统的Corba对象模型，对象仅能通过继承来扩展它的应用。为了支持新的新的界面，应用开发者必须：1 定义新的，从要求的界面继承，的IDL界面； 2 应用新的界面；3 分配应用到服务器端。然而，多重继承在Corba Idl 是易碎的，因为重载在IDL是不可以的，因为像C的语言缺乏重载。
因此，以上的介绍限制了应用。进一步说，应用可以需要暴露相同的IDL界面多次，为了允许开发者多个应用或多个服务的实例，通过一个入口点。相反，多重继承使暴露相同的界面多次或决定哪一个是提供给客户端最原始界面，提供成为不可能。
??Availability of CORBA Object Services is not defined a priori:
Corba说明没用要求在运行时，哪一个对象服务是提供的。结果，对象开发者必须用 ad hoc 策略去配置和激活这些服务。
??No standard object lifecycle management:
虽然Corba对象服务定义了生命周期服务，但它并不是要求的。因此，客户端要明显内容去管理对象的生命周期，以 ad hoc
方式。进一步说，通过生命周期服务控制的Ｃｏｒｂａ对象的开发者必须明白这个事实，和必须定义附加的界面去控制对象生命周期。定义这些的界面使单调的过程，应该自动进行，但较早的Corba说明缺乏。
CORBA说明的不足，早先的和包括在VERSION 2.3的，以上列出的，经常导致紧密的结合度，和难于设计，重用的，展开的，维护的和扩展的 ad-hoc 对象应用。
为了弥补以上的不足，OMG接受了CORBA Component Model（CCM）作为CORBA 3的一部分。CCM扩展了传统的CORBA对象模型，通过定义允许应用开发者去应用，管理，配置，和展开集成了Corba服务的模块的特性和服务，如容忍度，安全事务和事件服务，在一个标准的环境。CCM标准不仅提高了服务器软件重用性，也为动态的Corba应用配置提供了巨大的灵活性。 随着Corba的应用增加，CCM表现了出适合可升级的，应用要求严格的client/server应用。这章，我们描述CCM定义的主要的特性和服务，并图示CCM结构的好处。
模块开发者定义模块应用支持的IDL界面；下一步，利用CCM提供的工具应用模块。结果的模块应用被打包进动态连接苦。最后，CCM提供的分配机制用于分配模块，在模块服务器上（component server）。模块服务器是通过处理过程主管应用，通过相关的DLL。因此，在模块服务器上，模块执行和提供，去处理客户端的请求。一个好处是，CCM标准了开发的流程，下面，我们在CCM中的描述模块，从客户端的观点和模块开发者的观点，而且，我们描述了为支持CCM，ORB的扩展。
Client View
下面，我们介绍从CLIENT的视点来看模块是什么和如何应用模块。
一个模块 Foo 实例的参考曾现给client端，像一个有规则的Corba对象指引到界面Foo的实例。因此，对模块不清楚的Client端能调用操作，通过一个到模块对象等价界面的对象指引，能唯一鉴别这个模块实体。通过有规则的Corba对象，抹开的等价界面能从另外的界面继承，称作模块的支持界面。如我们开始提到的，用继承是难以扩展Corba对象的。因为对象不能和多个界面相连，用一个单一的应用实体。为了解决这个问题，CCM增加facets到模块中，Facets，也是提供的界面，是模块提供的界面，通过继承不必要连接到模块的支持界面。CCM多面体在设计上和Extension Interface 模式一致，类似于COM（Microsoft's Component Object Model）中的模块界面。
在Corba::CCMObject界面内，一个导航界面被定义，所有的等价的模块界面继承于它。Clients用在导航界面，列举的所有模块提供的多面体。因此，任何的拥有对多面体的指引的Client能用标准的get_component()操作取得到模块等价界面的引导。
增加多面体到CCM对象模型显著提高了模块的重用性。例如，新的界面能在新的模块提供，不会影响到存在的模块客户端。进一步，新的客户端能检查是否一个模块提供一定的界面，通过有标准的CCM浏览界面。因为 CCM允许几个无关界面和一个模块应用实体的绑定。客户端不需要清楚知道模块的应用细节，为了用它提供的可选择界面。
Component Lifecycle Management:
对于模块服务器，正确处理生命周期管理问题和对于客户端，帮助模块服务器管理它们的模块实例的生命周期 ，是很重要的。例如：一个模块能同时像多个Client端输出多个服务。同样，一个模块服务器能容许多的模块。而且，一个模块服务器必须知道何时创建一个模块实例和何时移去，为了防止资源的泄漏。虽然Corba对象服务说明定义了Liftcycle服务，但并不是一定要的，对于普通的Corba对象。因此，Corba开发者经常应用它们自己的 ad hoc生命周期管理策略。实际上，Corba说明的灵活性把客户端和对象界面的特定应用紧密结合起来。为了标准化模块生命周期管理界面，因此，CCM介绍了一个新词，“home”，指明每一模块的生命周期管理策略。客户端能用`home'界面去控制它使用的每一模块实例的生命周期。每一home界面准确管理一种模块的类型。Home 可能是有键的或无键的。无键的 home 经常支持factory操作，创建新的模块的实例。相反，有键的支持finder操作，客户端能用索引进入持久模块的实例，通过用客户端提供的key。为了向模块服务器表明一个特定的模块不再需要，客户端能调用remove_component()操作，在home策略界面上去通知模块服务器，模块服务器能决定如何去除模块。
Component Usage Scenarios:
为了用模块，客户端必须先得到模块`home'界面，然而，客户端要求一个标准的启动机制去定位模块的home界面。为了简化自举过程，提供的模块的home的指引，能存在中心数据库。因此，所有的需要自举自己的客户端向中心数据库得到指引。为了进入中心数据库，CCM说明定义了HomeFinder 界面，和Corba的命名服务相似。客户端开始用标准的Corba自举API resolve_initial_references(“HomeFinder”)去得到对象到HomeFinder 界面的指引. CCM HomeFinder 应用 客户端用来定位的模块home的目录服务， 得到对home界面的引导， 这时，调用正确的工厂方法去创建或发现目标模块的指引.
