UML软件工程组织

面向对象技术应用:分布式对象中间件
作者:田景成 本文选自:51cmm 2002年10月11日

 

分布式对象中间件


90年代以来,计算技术逐步进入以网络为中心的新时期,用户迫切希望在网络上建立更为丰富的分布式客户/服务器应用;不仅实现数据共享,而且支持知识共享和各类计算资源的共享;并能实现包括整个企业在内的各个层次的的协同工作。

为适应上述要求,分布对象技术成为分布式计算环境发展的主流方向。其技术特点为:

1. 主要针对异构环境下的应用互操作问题;

2. 系统核心的对象管理将客户/服务器模型与面向对象技术结合在一起;

3. 提供面向对象的API;

4. 已经成为建立集成框架和软件部件标准的核心技术。

在此基础上,为解决大型应用系统的集成性与可扩展性之间的矛盾,中间件(Middleware)技术应运而生。

中间件是软件中介于在应用层和网络层之间的一个功能层次,使应用系统独立于由异构的操作系统、硬件平台与通信协议组成的底层环境。

中间件扩展了客户/服务器结构,形成了一个包括客户、中间件和服务器在内的三层结构及多层次结构,为开发可靠的、可扩展的、复杂的事务密集型应用提供了有力的支持。

中间件可以分为四种类型:

1. 基于RPC (Remote Procedure Calls) 的中间件。RPC是传统程序设计语言中过程调用的扩展,被调用的对象可以在分布系统中的任何物理平台上。OSF的DCE和SunSoft的ONC+等均属此类中间件。

2. 面向消息的中间件,支持基于消息传递的进程间通讯方式。这种中间件既适用于客户/服务器模型,也适用于对等网模型,一般比基于RPC的中间件具有更高的运行效率。典型的系统有:SunSoft的ToolTalk、PeerLogic的Pipes和Talarian的SmartSockets等。

3. 基于ORBs (Obecjt Request Brokers) 的中间件,此类中间件是面向对象应用程序的首选。消息通过ORB进行路由选择,ORB同时处理集成和安全方面的问题。Microsoft的OLE/COM/DCOM和OMG的CORBA均属此类中间件。

4. 数据库中间件,支持对异构的传统关系数据库的透明访问。现有的此类系统包括Sybase的Open Server、Oracle的SQL Connect和BEA公司的WebLogic等。


基于面向对象技术的应用软件体系结构


软件体系结构是一个程序或系统的构件的组织结构、它们之间的关联关系以及支配系统设计和演变的原则和方针。一般地,一个系统的软件体系结构描述了该系统中的所有计算构件,构件之间的交互、连接件以及如何将构件和连接件结合在一起的约束。

研究软件体系结构的首要问题是如何表示软件体系结构,即如何对软件体系结构建模。针对规模日益庞大、结构日益复杂的应用应用软件,系统模型的设计目标是提高实际应用系统的开放性和集成性,同时兼顾效率。

软件系统的开放性包括数据的开放性、功能的开放性和系统的可扩充性,是否具备良好的开放性基本取决于系统模型。软件系统的集成性是指通过一致的信息描述手段和处理机制将各功能子系统统一到同一个集成环境,集成性的好坏也基本取决于系统模型。软件系统的效率通常包括系统运行的效率和应用开发的效率。运行效率是系统运行时的时空复杂度,而应用开发的效率指开发的难易程度和执行效率。效率大部分取决于系统模型,也与系统的具体实现有关。

开放的系统模型使得子功能部件的集成易于实现,同时也必然提高应用开发的效率;集成和高效反过来又有利于更好地达到开放的目的。这三者相辅相成,其中又以开放性作为集成和效率的基础,只有开放才有集成,只有开放才有效率。

针对应用软件系统的开放性,曾先后出现了许多类系统模型,代表了应用软件技术与产业发展的不同阶段。各阶段中有代表性的系统模型依次为:以数据为中心的系统模型、以执行为中心的系统模型、面向对象的系统模型、和基于总线的系统模型。

以数据为中心的系统模型如图2a所示。这类模型将数据库放在系统的核心层次共享,各功能部件采用统一的数据描述,各子系统的开发过程完全独立;子系统间有统一的数据交换接口;整体的可扩充性好,可任意增加符合数据交换标准的应用程序。但是,这种模型整体结构松散,集成性不够良好;只能做到数据复用,不能做到功能复用,造成大量的代码冗余;由于应用相关数据的存在,难于定义符合所有应用需求的数据接口标准,因此会出现数据语义失真。从开放性的角度来讲,这类系统只具有数据开放性,不具有功能开放性,但其可扩充性很好。

以执行为中心的系统模型着眼于将不同的应用系统通过统一的执行中心来实现数据和用户界面的共享和一致,如图2b所示。这类模型将共有的计算和执行功能从应用程序中分离出来,放在执行中心,避免了代码冗余;用户与系统的交互与应用程序相分离,便于实现统一风格的用户界面;和数据库的任何数据交换都要通过执行中心进行,有利于数据的严格管理,保证了数据的一致性。这类模型解决了以数据为中心的系统模型的代码冗余及界面风格不统一等问题,但仍存在一些缺陷:执行中心的功能设计复杂,很难确切定义符合所有应用要求的功能集合,而且实现起来也相当困难;执行中心同时与用户界面和所有应用程序保持通讯,又管理着数据,负担过重,容易形成瓶颈。总之,这类模型既具有数据的开放性,又具有功能的开放性,可扩充性也好,整体上优于以数据为中心的系统模型。

随着面向对象技术的成熟,出现了更为简炼的面向对象的系统模型,与前两类模型的设计思想有较大差别,如图2c所示。其中,系统内核对象中封装的是能为用户界面对象和所有应用对象所共享的数据及相应的操作;用户界面对象中封装的是用户界面数据及相应的操作;应用对象中封装的是应用数据及相应的操作。所有这些对象通过相互间的通讯协调来完成指定的功能。从系统构成的角度来说,这类模型的结构是无中心的,系统由各对象实体构成,各对象实体具有平等的地位,这与以数据为中心和以执行为中心的模型不同。面向对象的系统模型的主要优点在于,数据和功能的合理封装降低了由于数据和功能的集中管理所带来的通讯上的开销和操作上的复杂性;另外,系统的无中心结构也使系统的构成变得更加灵活。从整体上看,面向对象的系统模型无论其开放性还是其有效性都要优于前两类模型。

面向对象模型比以往的模型有了很大的进步,但仍有不足:对象之间的联系是一种点对点的直接联系,当系统中对象数目增加时,通讯链接数将以平方级激增;同时,为支持通讯,每个对象实体都要维护一个包含所有对象实体功能服务信息的功能服务信息库,这部分信息不但重复,而且还要保证其一致性。这些开销都损害了系统的效率。更大的问题还在于:对象的接口没有一致的标准,造成向系统中扩充对象时的随意与不规范,不利于系统的维护以及对象的复用。

以面向对象为基础的组件和中间件技术的逐渐成熟又为应用软件系统的建模引入了新的思想,产生了基于总线的系统模型,如图2d所示。组件、中间件是继面向对象技术之后发展起来的新的软件工程技术,是面向对象技术的延伸。基于总线的系统模型仍然是一种面向对象的结构,但系统中的对象是按照规范设计的模块,这些定义良好的软件模块(组件)在系统中共存,并且充分地相互作用。按照这种结构,可以将若干组件组合起来,以建立更大和更复杂的系统。

这种模型的关键在于一种高效的总线结构,使组件之间能以一个公共的接口互相连接,做到组件的即插即用,无缝集成。这种模型的系统中,组件间的通讯链接数是线性的,并且由于各组件接口规范的一致性,通讯的复杂度大大下降,也提高了组件的互操作性。

根据组件在系统中地位的差异,应用软件系统中的组件可以分为两个层次:核心组件和应用组件。相对于核心组件来说,应用组件所要求的系统服务要少得多,请求服务的频度也较低。相应地,总线也可以分为核心总线和应用总线,从而形成双总线结构。在这种总线结构中,核心组件和应用组件之间仍然保持良好的互操作性,但应用总线屏蔽了应用组件的一部分服务请求,减少了核心总线上的流量,从而提高了应用软件系统核心的效率。

核心组件与核心总线构成了应用软件系统的原型和框架,在此基础上与各应用组件集成。

通常在分布式环境中,应用组件不是直接连结到应用总线(也称Broker)上,而是通过一个软件代理(Agent)间接地连在总线上,如图3所示。Agent的作用在于,一方面代理应用组件的复杂通讯过程,使应用组件更专注于功能的实现;另一方面将适应不同应用需求的组件内部的异构数据转换成同构数据,以保证Broker上通讯语言的统一。由此可见,在基于总线的系统模型中,Broker与Agent构成了介于应用组件(客户)与核心系统(服务器)之间的中间件。

『引自 软件工程专家网』

(责任编辑 Sunny)
  



版权所有:UML软件工程组织