计算机研究与发展
JOURNAL OF COMPUTER RESEARCH AND DEVELOPMENT
1999年 第36卷 第9期 Vol.36 No.9 1999



一种基于TriBus的软件集成框架
李保建　曾广周林宗楷
摘　要　文中提出了一种面向领域的软件体系结构类型.这种体系结构类型定义了过程、对象和Agent 3种软构件类型，设计了一种称为TriBus的软总线或连接器，规定了不同类构件之间通过TriBus的单向引用关系和同类构件之间的双向引用关系，并给出了这种软件体系结构类型在计算机辅助协同设计领域的应用实例.
关键词　软件体系结构，软构件，软总线，计算机辅助协同设计
中图法分类号　TP311.5
A SOFTWARE INTEGRATING FRAMEWORK BASED ON TriBus
LI Bao-Jian, ZENG Guang-Zhou, and LIN Zong-Kai
(CAD Laboratory at Institute of Computing Technology, Chinese Academy of Sciences, Beijing 100080)(Department of Computer Science, Shandong University of Technology, Jinan 250061)
Abstract　A domain-specific software architecture style is proposed in the paper here. In the architecture style, three software component types are defined: procedure components, object components and agent components. A software bus called TriBus is designed to facilitate interactions among these components and specify one way “citation” relations between different component types and two-way “citation” relations between components of the same type. An application example of the software architecture style in the domain of Computer Supported Collaborative Design is given.
Key words　software architecture, software component, software bus, computer supported collaborative design
1　引言
　　面向领域（domain specific）的软件体系结构是软件体系结构研究的一个重要方向.这类研究的目的是通过特定应用领域的开发提供可重用的软件产品族的构件（components）和框架（frameworks）.这种开发是基于以下思想即一组相关系统的共同方面可以抽取出来，从而可以在相对较低的成本下通过“实例化”共享设计来建造新的系统［1］.
　　关于面向领域的软件体系结构有几个问题值得一提，一是这里所提及的“领域”，其范围可窄可宽.二是这里所说的重用既包含构件库的重用，又包括集成构件的框架的重用.三是面向某一领域的软件体系结构不是唯一的，而是存在一个体系结构空间.
　　本文将提出一种面向领域的软件体系结构类型，我们称之为D3体系结构类型.关于这种体系结构类型的提出，涉及到我们采用的研究方法.在我们研究、设计与开发一种具体的计算机协同设计（CSCD）的层次操作模型与系统的过程中［2］，我们产生了从中抽取一种软件体系结构类型想法.因此其设计目标首先是指导一类CSCD（Computer Supported Collaborative Design）系统软件的开发.其次，在设计这种体系结构的过程中，我们发现其雏形也可能具有适用于更宽的范围譬如说其他CSCW领域、DPS（Distributed Problem Solving）领域等的潜力，因此我们增加了构件类型并设计了连接器，力图使之具有更宽的适用范围.
2　构件分类及其相互关系
　　我们将D3结构类型中的构件分成3类：过程构件、对象构件和Agent构件.下面分别给出它们的定义.
　　定义1. 过程构件具有纯粹变换性质，它可以对输入数据进行变换得到输出数据，也可以对全局数据或状态进行操作而使之改变.从构成上来说，过程构件可以由一组相关联或不相关联的过程或函数组成.这里的过程或函数没有自己的私有数据或状态，整个构件也没有自己的私有数据或状态.关联是指过程或函数间的调用关系.
　　定义2. 对象构件是具有自己的数据或状态，并能提供与其数据或状态相关的操作或服务的程序模块或（运行期间的）进程.
　　我们这里采用的是广义的对象概念.对象构件强调的是数据和操作的封装性.从外部来看，只要一个程序具有自己的数据和状态，并对外提供相关的操作或服务，就具备了作为对象构件的条件.例如，一个通常的数据库应用程序等加以构件化就可构成对象构件.
　　定义3. Agent构件即Agent.Agent是其状态可以看成由诸如信念(belief)、目标(goal)、意向(intention)及承诺(commitment)等心理成分构成的，相互之间用基于言语行为的通信原语诸如通知、请求、提议、接受、拒绝等进行交互作用和合作的，在一定的环境下持续自主运行的程序实体.
　　学术界对什么是Agent持有不同的观点.考虑到应用需要，我们采用了一种认知型(cognitive) Agent的观点.认知型Agent强调心态元素诸如信念、目标、意向等的明确表示［3，4］，而Agent的理性行为(rational behavior)正是这种表示的结果.
　　在我们的构件分类中，我们明确地将对象和Agent区分成两种不同的构件.这和将Agent作为一种特殊的对象的做法不同.虽然从某种意义上来说，可以将Agent看成一种特殊的对象，但两者之间至少存在下述差异：
　　(1) 对象状态和Agent状态的区别.对象的状态取决于其数据（属性）的取值，可以由于其操作（行为）而发生变化并且同样可以影响其行为.但对象的状态是一种未分化或无约束的状态，换句话说，对象具有哪些属性以及对这些属性的解释完全取决于个别的设计人员.Agent则不同，其状态可以明确地由信念、目标、意向等精神成分来描述.
　　(2) 对象和Agent都用消息进行通信，但对象消息是无约束或非类型化的，而Agent消息则明确地用言语行为理论加以类型化.Agent之间通过诸如通知、请求、提议、接受、拒绝之类的消息来实现交互作用.
　　因此，与其认为Agent是一种特殊的对象，不如认为Agent是一种更高层次的软件抽象.这种更高层次的抽象，可望对向DPS，CSCW等应用提供更加直接的支持.
　　3种构件之间的关系不是对等的.我们可以规定它们之间的引用关系如图1所示.我们将过程和函数调用、向对象传递消息和向Agent 发送通信原语统称为“引用”.构件之间的引用关系将构件分成3个层次：Agent构件层次，对象构件层次和过程构件层次.每个层次之内的构件允许相互引用；上层构件允许引用下层构件，反之则不然.这样规定的理由也是明显的：过程构件是纯粹变换性质的，没有自己的状态.而对象构件则有自己的数据和状态，Agent构件甚至有自己的心态.规定它们层次之间的单向引用可以避免复杂甚至不可预测的语义关系.不同类构件之间的单向引用关系和同类构件之间的双向引用关系也是D3体系结构类型的重要组成部分.

　→集合中/之间构件引用关系
图1　构件引用关系
3　TriBus
　　连接器(connector)是软件体系结构的主要组成部分之一，是构件与构件之间交互作用的中介.在D3体系结构中我们规定了如图1所示的引用关系并且我们将过程和函数调用、向对象传递消息和向Agent 发送通信原语统称为引用.因为构件是分散于网络上的，如何实现构件之间的引用关系，是一个重要的问题.我们没有为过程和函数调用、向对象传递消息和向Agent发送通信原语每一种引用分别设计不同的连接器，而设计了一种称为TriBus的软总线作为各种引用传输的中介.它的主要特色在于提供了Agent之间用通信原语进行交互作用的机制.因为Agent之间的通信原语交互是上下文有关的，因此每组相关的通信原语都需要特别的处理协议.由于Agent研究远未成熟，现有的软总线标准如CORBA等不可能提供我们所需要的Agent通信手段.
　　TriBus由标识总线（IdBus）、命令总线（ComBus）、数据总线（DataBus）集合和总线管理器（BusManager）组成，还提供用于构件与总线挂接的客户方和服务器方源代码库（客户方构件是发出引用的构件，服务器方构件是接收引用的构件.同一构件既可以是客户方也可以是服务器方构件）.其结构如图2所示.我们将TriBus实现为后台服务进程，分布于不同主机上的TriBus是对等的，它们通过消息相互联系.

图2　TriBus
　　BusManager负责外部消息的接收与分析，并根据分析的结果启动命令或标识总线.数据总线由命令总线启动.
　　IdBus包含构件命名、类型、地址或定位信息及引用接口描述库（以下简称Id描述库），支持跨平台的全局构件标识及引用接口空间，提供其存储、更新、检索等管理方法的应用程序接口（API），并负责处理不同主机上的标识总线之间的数据一致性问题（这里需要说明的一点是，尽管各个TriBus在引用关系方面是对等的，但在TriBus的数据一致性问题上，还是以某个选定的TriBus为标准,从而大大简化了设计）.
　　ComBus是TriBus中负责引用传输的部件，包含引用收发器、命令总线际协议ICP和构件适配器，其结构如图3所示.ComBus还给应用程序提供用于动态引用的API，产生应用程序和引用收发器之间的动态接口.

图3　命令总线(虚线框内)结构
　　引用收发器的功能之一是接收从应用程序发来的经由BusManager的具有统一编码格式的引用，判别是否发往本地的引用，若是则传送给（本地）构件适配器，并从构件适配器接收引用执行结果，否则将引用通过ICP实体转发给网络上的目的TriBus的命令总线并接收相应的结果.引用收发器的另一功能是根据所接收的引用的源地址、目的地址和引用参数而决定是否启动数据总线进行多媒体数据的传输或接收.
　　ICP协议的功能是负责网际命令总线之间的引用及结果的传输.ICP协议实体是一个复杂的实体.它针对不同的引用诸如过程与函数调用、对象之间的消息发送及Agent之间的通信原语提供不同的处理规程.
　　构件适配器负责本地构件的管理、向本地构件传送引用并接收引用执行结果.
　　DataBus集合是专门负责多媒体数据的网络传输的.每个DataBus是一个媒体传送协议实体，由媒体发送器和接收器组成，负责传送一种类型的媒体.多媒体传输这一任务是非常复杂的.媒体的多样性及网络多媒体应用的广泛性对网络传输及处理提出多样性的甚至是苛刻的要求.不能试图设计一个能支持多种媒体的各种应用的通用的DataBus集合，因此，在TriBus中，DataBus集合中每个DataBus都被设计成可装卸的.　　
　　构件之间利用TriBus进行通信，必须遵循统一的接口标准，必须与TriBus正确挂接.我们设计了一种IDL（接口定义语言）用于描述过程构件、对象构件和Agent构件的服务接口.构件总是用某种程序设计语言编写而成的，相对于IDL来说，称其为目标语言.应建立IDL到目标语言的映射规范.IDL编译器根据这种映射规范编写，它有两个职能：
　　(1) 根据构件服务接口IDL定义和TriBus提供的服务器方源代码库生成服务器方骨架（server side skeleton），构件的服务器方骨架是用IDL编译器的目标语言表示的，负责和TriBus挂接并从ComBus接收引用.
　　(2) 根据客户方构件对服务器方构件的静态引用、服务器方构件的服务接口IDL定义和由TriBus提供的客户方源代码库生成客户端桩（client side stub），客户端桩同样是用IDL编译器的目标语言来表示，负责客户方构件和TriBus挂接并向ComBus转发静态引用.
　　服务器方构件用构件注册器向IdBus注册.构件注册器调用IDL编译器生成构件的服务器方骨架，将构件源码和服务器方骨架进行编译和连接，并根据构件服务接口的IDL描述向IdBus注册.构件注册器还提供从IdBus中注销或替换某一构件的功能.
　　客户方构件可以以两种方式使用服务器方构件，一种是静态引用的方式，另一种是动态引用的方式.所谓静态引用方式是指客户方构件编译期间就安排好了的构件引用方式.静态引用方式的使用方法是：由IDL编译器根据要引用的服务器方构件服务接口IDL描述生成客户端桩，和包含了对服务器方构件引用的客户方构件一起编译连接生成客户方构件可执行代码.而动态引用的方式是指客户方构件直接调用TriBus提供的API在运行期间向IdBus查询服务器方构件及其接口并根据运行时条件通过API间接引用.
4　一个D3体系结构实例
　　体系结构类型(architectural style)和体系结构实例(architectural instance)是两个不同的概念.一个体系结构实例指一个特定系统的体系结构，而一种体系结构类型则定义一族体系结构实例的形式和结构应满足的约束.体系结构类型规定其实例可能具有的构件和连接器(connector)、拓扑约束以及语义约束等［1］.
　　我们将要介绍的一个D3体系结构实例是一个我们开发的计算机辅助对象图协同设计原型系统(CODDS)的体系结构.此实例的配置（configuration）如图4所示，我们选用了D3体系结构类型中的对象和Agent两种类型的构件，它们通过Tribus相互作用.

图4　CODDS系统体系结构示意图
　　在CODDS中，共享设计对象构件实际上是领域级设计系统.被设计的产品或对象是面向对象分析中类及其层次关系和聚合关系等的图形化表示.CODDS系统的外观像一个图形编辑器，但其共享设计对象构件的基本的图素是表示空类（仅有名字，没有属性）、属性以及层次与聚合等关系的几何图形，与一般的图形编辑器大不相同.可以施加于它们的操作（对象构件的方法）包括创建空类、添加与删除属性、建立与撤消继承或聚合连接关系等.
　　计算机辅助协同设计（CSCD）的目标是支持群体工作，开发一个有效的CSCD系统，群体工作的特点诸如地点上的分布性、时间上的同步与异步性、并发性等必须予以考虑［5］；群体协同的需求的诸如任务分解与装配、设计活动监控、冲突消解等必须在系统中有所反映以更好地支持人人交互.
　　为了将协同的需求集成到CODDS中，我们在领域级系统即共享设计对象构件和多个设计人员之间设置了由多个Agent构件组成的多Agent系统.每个设计者都有一个Agent助手，设计者可以直接地操纵他的Agent，每个Agent都可以直接操纵共享设计对象，但是设计者只能通过中间Agent层间接地操纵共享设计对象.
　　每个Agent的理性行为是由其心态元素诸如beliefs，desires，goals，intentions等所决定的.为了体现协同的某些需求与约束，直接反映每个Agent面向协同的理性行为，我们设计了一种心态元素称为Joint endeavor［2］.Agent通过诸如inform, request, consent, proposal, accept, refuse等通信原语相互作用.中间多Agent系统通过形成联合心态Joint endeavor并凭借它们交互作用的通信原语，从而将协同设计的某些约束与需求集成到系统中来.每个Agent构件由领域级用户接口和元级用户接口、监控模块、协作模块以及设计任务和Agent社团的内部模型等部分组成.设计人员通过领域级用户接口向其Agent传达对共享对象构件的操作信息，但这种操作要受到监控模块的监控，如果符合协同的约束，则由Agent根据接收到的操作信息对共享对象构件实施实际操作.元级用户接口则提供设计人员的协作手段.实际上，设计人员是经由元级用户接口通过在Agent之间相互传送通信原语来相互合作的.协作模块负责管理Joint endeavor，并根据Joint endeavor的规定来跟踪协同行为.
　　CODDS系统的体系结构完全符合D3体系结构类型的规定.Agent构件之间通过通信原语的相互作用，及它们对共享对象构件的操作关系，用D3体系结构类型的术语来说就是引用关系.但是所有Agent共享一个设计对象构件，不存在对象构件之间的相互引用关系.每个Agent既是服务器方构件，也是客户方构件，因为它们之间的引用关系是相互的.而共享设计对象构件由于只接收来自Agent的引用，因此仅仅作为服务器方构件向Tribus注册.
5　结语
　　上面我们介绍了D3体系结构类型中的构件、连接器及其相互关系，并介绍了一个D3体系结构实例.正如我们在引言中所说的，我们在设计这种体系结构类型的过程中，首先是面向一类CSCD系统的设计，但又不局限于此.D3体系结构类型的提出，仅仅是一个开始，进一步的研究工作应包括：
　　(1) 探索D3体系结构类型的其他适用范围，我们正在考虑将其应用到一个基于黑板模型的多Agent分布式问题求解系统中.
　　(2) 软件体系结构是需求和实现之间的桥梁.基于某种软件体系结构类型的软件开发，必然对软件需求与设计方法产生重大影响.因此基于D3体系结构类型的软件需求与设计方法值得我们进一步深入研究.
　　迄今为止的研究表明，D3体系结构类型对构件、连接器及其相互关系的规定是自然合理的，其应用前景也是光明的.
注：本课题得到国家“九五”重点科技攻关项目(项目编号96-729-01-01)及山东省自然科学基金(项目编号Y98G07103)资助.
作者简介：李保建，男，1964年10月生，博士研究生，主要研究方向为软件智能化技术与协同设计.
曾广周，男，1947年3月生，教授，主要研究领域为人工智能和软件工程.
林宗楷，男，1934年3月生，研究员，博士生导师，主要研究领域为工程数据库及协同设计.
作者单位；李保建　林宗楷　中国科学院计算技术研究所CAD开放实验室　北京　100080
曾广周山东工业大学计算机系　济南　250061
参考文献
1　　Garlan D, Perry D E. Introduction to the special issue on software architecture. IEEE Transactions on Software Engineering, 1995, 21(4): 269～274
2　　Li Baojian, Zeng Guangzhou, Lin Zongkai. A hierarchical operation model based on half-automated agent for collaborative design. In: Proc of Third International Workshop on CSCW in Design. Japan, 1998
3　　Shoham Y. Agent oriented programming. Artificial Intelligence, 1993, 60: 51～92
4　　Cohen P R, Levesque H J. Intention is choice with commitment. Artificial Intelligence, 1990, 42: 213～261
5　　Lin Zongkai. The appearance of CSCD making CAD technology to leap onto a new step. In: Proc of Second International Workshop on CSCW in Design. Bangkok, Thailand, 1997. 162～167
原稿收到日期：1997-12-29；修改稿收到日期：1998-10-06.
