CORBA组件模型 (2)

续上。。

CORBA组件模型：第一部分，向组件式中间件(component middleware)演化

The CORBA Component Model， C/C++ Users Journal February 2004

Douglas C. Schmidt and Steve Vinoski

cnDeveloperw (ysf_gzb@21cn.net) 译

 

面向对象技术的使用还相关地间接引来许多类似的零碎小问题，需要开发人员用繁细(因而经常带来差错和沉闷)的编码约定和风格来联系

在一起。所以，这种方法在当开发大型系统时要求重大工作超越既有的一些支持服务的原始对象和事件。需要有一种途径去把较大的单元

打包在一起，这些单元由需要提供高层性能的现成部分的集来组成(有时是不同种类的)，包括他们所支持的属性。举例来说，一个典型的
性能可能需要引发所有各种类型的对象，如触发某种职责的事件、管理次序和接受状态改变的事务处理，以及负责错误情况的容错处理等

。若当他们一一实现并可用时，他们需要分别地仔细地接合在每个实例中，这些实例是整个应用的一个处理一些特定部分的完全模块。

对象管理组织(OMA)在CORBA 2.x规范中为构建简易分布程序(portable distributed applications)定义了高级DOC中间件标准。CORBA 2.x

专注于接口，本质上，接口(Interface)建立了客户端和服务端的约定，即客户端如何观察和访问服务器所提供的服务的方式。CORBA尽管

有先进的性能，然而，CORBA 2.x标准却有如下局限性：
1、缺乏功能边界性(functional boundary). CORBA 2.x对象模型把所有接口都当作约定了client/server形式。然而，这种对象模型没有

提供标准的装配机制来减少协作对象之间执行的依赖性。举例，对象需要明确的察觉和连接到那些自己要依靠来执行的其他对象。可是，

建立复杂的分布式应用程序，开发者必须明确的规划好那些相互依赖的服务和对象接口之间的连接，而这却是些额外的工作--不得已的脆

弱的不可重用的实现。
2、可扩展性。由于组件相对于对象是在更高层次上描述的，继承对实现多态的意义就不那么至关要紧。对象是单元的实例、封装类型、接

口和行为，均是所用到的问题域(problem domain)的实体的模型(可能是物理的)。典型地他们实现在一种特定语言并有一些布局上的需求

，每个交互操作的对象必须满足。相反地，一个组件无须表现为以一种特定语言实现的类，或与其它组件共享二进制兼容性(虽然实践上可

能这样做)。因而，组件能被看作是功能提供者，它能被用别的语言编写的相同组件替代。这种扩展性是方便的，通过扩充接口设计模式(E

xtension Interface design pattern)，定义一套标准协议来创建、组合和展开相互作用的组件群(groups of interacting components)

。
3、高层执行环境。组件模型定义了运行时执行环境--“容器”，即操作比通过对象访问要更抽象。容器操作环境为运行时的组件定义和强

制策略提供了额外的控制层次。相反地，在使用对象时对下部构造的直接依赖会强迫组件功能演化从运行时下部构造的演化分离出来。

(待续。。。)

cnDeveloperw (ysf_gzb@21cn.net) 译