初步了解 Corba 的模块模型概况

分布式计算中间件，如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结构的好处。