续上。。
CORBA组件模型：第一部分，向组件式中间件(component middleware)演化
The CORBA Component Model， C/C++ Users Journal February 2004
Douglas C. Schmidt and Steve Vinoski
cnDeveloperw (ysf_gzb@21cn.net) 译
续上。。
中间件的演化
互联网的出现和飞速发展始于20世纪70年代，并带出了分布式应用的需求。然而若干年前，由于缺乏方法、工具及平台，这些应用很难开发。时至今天，各种各样的技术已经出现超过二十多年，这些技术用以减轻开发分布式应用软件的复杂性，并通过提供高级的软件基础设施给与支持。
在初期，里程碑包括了互联网协议的出现、基于交互处理通信(interprocess communication, IPC)的消息传递架构、微内核架构、以及Sun公司的远程过程调用(Remote Procedure Call, RPC)模型。下一代的则包括了OSF的分布式计算环境(Distributed Computing Environment, DCE)、IBM的MQ系列、CORBA和DCOM。最近，中间件技术已经演化到支持分布式的实时嵌入(distributed real-time and embedded)应用(如Real-time CORBA)，以及提供像组件模型(如CCM和J2EE)、Web-services(如SOAP)和模型驱动中间件(如CoSMIC)等更高层抽象的阶段。
上面论述到的中间件技术的成就，在上一代软件开发者常用操作系统、编程语言、网络和数据库产品中就已加入了中间件范例。通过解藕，特殊应用的功能和逻辑从分布式基础设施固有的附带复杂性分离出来。中间件使得应用程序开发人员集中精力编写特殊应用的功能，而不是翻来覆去的陷入与基础设施斗争的泥潭中。
过去二十年中的一个分水岭事件是20世纪80年代末90年代初分布式对象计算(distributed object computing, DOC)中间件的出现。DOC中间件代表了分布式计算系统和面向对象设计/编程两大主要IT领域的合并。开发分布式系统的技术致力于集成多台计算机为一个统一的可升级扩展的计算资源。同样地，开发面向系统则致力于通过创建可重用框架和组件来具体化成功模式和软件架构来减轻复杂性。所以，DOC中间件利用面向对象技术来有效地软性地数倍健硕地分散布置可重用服务和应用。
对象管理组织(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、缺乏通用应用程序服务器标准。CORBA 2.x没有指出通用应用程序服务器框架来执行公共服务器配置管理工作，包括初始化服务器及其QoS策略、公共服务(如通知或命名服务)提供，以及管理每个组件的运行时环境。尽管CORBA 2.x标准化了对象实现和对象请求代理(ORBs)之间的交互，服务器端的开发者仍然必须要确定：(1)对象实现是怎样安装在ORB中的；(2)ORB和对象实现如何交互。缺乏通用组件服务器标准造成紧密耦合、ad-hoc服务器实现，这增加了软件升级的复杂性和减少了基于CORBA的应用的可重用性、弹性。
3、缺乏软件配置和发布标准。在CORBA 2.x规范中没有标准的方法去分散布置和启动对象实现。因而，应用程序管理员必须依靠脚本和程序在目标机器上发布软件实现，配置目标机器和执行软件实现，然后，列示软件实现使他们准备好服务客户端。可是，软件实现经常修改去适应这种ad-hoc发布机制。与其他软件实现和服务交互的软件的最大限度重用的需求在日后会使该问题更加突出。缺乏更高层次软件管理标准导致系统更加难于维护，软件组件实现更加难以重用。
(待续。。。)
cnDeveloperw (ysf_gzb@21cn.net) 译
