一种基于代数规约的面向服务集成方法∗

兰 斌 刘冬梅 陈 颖 何娟娟

（南京理工大学计算机科学与工程学院 南京 210094）

1 引言

面向服务计算（Service-oriented Computing，SOC）是一种新兴的分布式计算范型，它使用面向服务架构（Service-oriented Architecture，SOA），通过整合服务来构建软件解决方案［1］。SOA支持更加快速地开发业务流程以及更加轻松地对业务流程进行改变，可以使组织更迅速地适应他们业务环境的改变。Web服务凭借其平台无关、软件模块松耦合性、异构平台互通性和高重用性等特征成为了SOA实现的首要选择。

受到面向服务趋势的影响，许多现有的非面向服务软件系统为了更灵活、更快地响应不断改变的消费者需求，将进行面向服务的重新设计和集成。目前对Web服务已经有了比较充分的研究，对服务接口模型的设计以及服务组合的建模研究，成果丰硕［2～3］。但在面向服务集成的灵活性上还存在一些问题，一方面以逆向工程技术为主的白盒方法从现有代码中恢复业务逻辑，再根据业务逻辑开发全新的Web服务。虽然提高了依赖源代码的事务处理效率，但业务逻辑恢复难以保证完整性，同时通过源代码侵入系统容易影响系统的稳定性。另一方面以形式化技术为主的黑盒方法通过适配器来传输请求数据和应用程序响应数据。虽然避免了侵入系统内部，但通用性和响应变更的及时性方面都不够理想。因此，面向服务集成仍是当前研究的热门课题。

本文分析服务集成的白盒与黑盒方法，提出一种基于代数规约的灰盒方法。首先在系统的形式化描述的基础上，结合数据流分析提取系统的核心业务逻辑，其次将改进的聚类分析算法应用于服务鉴别，然后设计和开发新的功能组件来实现服务功能，最后通过实际的应用案例和实验分析验证了本文方法的有效性。

2 相关工作

现有的研究中，面向服务集成的方法主要分为黑盒方法和白盒方法两大类［4］。

黑盒方法是通过适配器来传输请求数据和应用程序响应数据，解决了系统和集成环境接口不匹配的问题从而实现系统面向服务集成［5～6］。Mehta等通过一个细粒度的组件模型明确定义应用程序界面，以递增的方式实现面向服务集成［9］。Canfora等通过屏幕抓取技术动态分析用户交互行为，收集系统返回的屏幕序列和交换的消息并分类包装在SOA接口中作为Web服务来被访问［7］。Li等提出了一种基于有穷状态自动机描述的黑盒系统的服务集成方案［8］，给出了包装方案的参考模型，并对模型内的主要包装组件的功能进行了描述。在理想情况下，这种集成方法仅分析应用程序界面，忽略系统的内部构件。但是由于系统的多样性和消费者需求的不断变化，这种方法在通用性和响应需求变更的及时性方面都存在问题。在许多情况下，借助白盒现代化工具研究待集成系统的内部结构是很重要的。

白盒方法通过逆向工程技术从现有代码中恢复业务逻辑，然后根据业务逻辑开发全新的Web服务［10］。Chen等使用特征分析来实现面向服务的集成［12］，特征分析包括识别系统特征、构建特征模型，以及通过特征定位技术在待集成系统中定位特征的实现。Li Xiang等针对Java语言的面向对象系统构造了一种描述软件行为和依赖关系的图模型，并在此基础上给出了面向服务的系统分解算法［11］。Alahmari等从服务粒度出发，定义7种不同粒度的服务原模型。通过描述业务程序的业务逻辑和对实体的CRUD操作，结合原模型来定位候选服务的粒度和数量［13～14］。这种集成方法简化了系统，节省了维护费用，并提高了依赖源代码的事务处理效率。但是这种方法很难完美地恢复业务逻辑，通过源代码侵入系统后系统的稳定性也存在问题。

Zhang等综合前两种方法提出了灰盒的集成方法［17］，将面向对象程序中的函数、过程和类定义为要聚类的实体，根据标识符名称来定义特征，采用更加强调功能的分层聚类方法提取服务。后续又提出高层次的形式概念分析和低层次的程序切片分析组合实现服务提取［16］，形式概念分析捕获可重复使用的代码段、基于符号有向图的切分算法剔除无用代码并调整实现实体的松耦合组件化。该方法虽然能够准确地定位功能代码块，但后续的服务提取操作仍对系统有一定的入侵性，很难保证不会对系统的稳定性造成影响。

在已有的研究中，形式化方法凭借其准确、规范的描述和验证软件系统行为和性能的优势被广泛地采用。由于代数规约高度抽象、完全独立于实现细节，很适合对系统进行抽象描述。本文以系统的代数规约描述为基础，将描述类的类子模型定义成聚类的实体，根据类和业务逻辑的关联定义特征，采用改进的聚类分析算法提取服务，最后基于业务逻辑设计和开发实现服务功能的新组件。与之前的研究相比，本文提出的方法更少对系统进行入侵，保证稳定性的同时具有更高的灵活性。

3 基于代数规约的面向服务集成

基于代数规约的面向服务集成主要分为三个步骤：“自底向上”的代数规约描述类结合“自顶向下”的逻辑分析用于系统的理解与分析、聚类分析方法用于服务的鉴别、服务封装技术用于服务的封装，最后将非面向服务系统集成到SOA中作为Web服务并验证服务功能。

3.1 系统的理解与分析

在面向服务环境下，服务集成是面向数据和功能的，因此系统的理解与分析主要分为面向数据的“自底向上”类描述和面向功能的“自顶向下”逻辑分析，如图1。

图1 面向服务集成系统理解图

3.1.1 “自底向上”的类描述

本文采用代数规约语言SOFIA对系统进行语义描述，称之为系统的类子模型。SOFIA是Liu等在大量案例研究的基础上提出的面向服务软件的代数规约语言［20］，它由若干个规约单元构成，每个规约单元描述一个类子Sort。

定义1（类子模型）三元组

R（Relation）表 示 类 之 间 的 关 系 ，R=Si,Sj,r ，Si，Sj表示第i、j个类，r表示两个类间具体的关系，包括extends关系和uses关系。

A（Attribute）表示类的成员变量，包过类变量和实例变量。

O（Operation）表示类的函数，包过除构造函数及成员变量get/set函数之外的所有成员函数。

以第4节中MTAC类描述中的FunctionExpression类子模型为例，其主要的SOFIA语言规约如下：

Spec FunctionExpression；

extends Expression；

uses String，Function，Expression，Namespace，Bool，

VariableExpression，Integer，Vector；

Attr

name：String；

function：Function；

args：Expression；

Operation

simplify（Namespace，Bool）：Expression；

differentiate（Namespace，VariableExpression）：Expression；

toString（Integer）：String；

prettyPrint（String，Integer，Integer）：PrettyPrintBox；

getAllVariables（Vector）：void；

equals（Object）：Bool；

hashCode（）：Integer；

End

为了更好地区分类子模型间的关系，我们将uses关系分为Attribute-uses关系和Operation-uses关系。以FunctionExpression类子模型为例，它与Expression呈extends关系；与Function和Variable-Expression分别呈Attribute-uses关系和Operation-uses关系。

通过对源代码数据流分析得到系统核心流程图。核心流程图由数据、过程和决策组成，是系统核心功能流程的体现。数据是过程的输入输出，过程是系统功能实现的基本组成部分，决策是数据分流的依据。

结合核心流程图对类子模型进行精简。剔除与核心流程图中数据、过程和决策无关的类。这些类是面向对象系统常用的如用户界面、弹窗提示等功能的实现类，在服务鉴别过程中不需要用到这些类。此操作不对源代码做任何的修改，只是从类子模型中剔除这些无关类，降低类子模型的复杂度，从而加快后续处理的速度。

3.1.2 “自顶向下”的逻辑分析

计算系统核心流程图中除去循环决策之后的圈复杂度，根据流程图的圈复杂度确定基本路径，基本路径集合表示为P={p1,p2,…,pk}，其中 pk表示第k条基本路径。

通过阅读已有的系统开发文档、人工操作、用户评价等方式理解系统核心功能，结合核心流程图中的基本路径设计相应的操作用例验证核心功能的正确性并分析得出系统的业务逻辑，业务逻辑集合表示为L={ }bl1,bl2,…,blk，其中blk表示第k个业务逻辑。

3.2 服务鉴别

聚类技术已经在许多学科中广泛应用多年。聚类分析是根据数据集的大小关系和相似度，将数据集中的实体组合成群集。应用聚类分析前，需要定义聚类实体集、两个实体之间的相似度和一个聚类算法。应用聚类分析后，需要对结果进行评估和解释［18］。本文在系统理解与分析的基础上改进聚类算法用于服务鉴别。

3.2.1 改进的聚类分析算法

从系统核心流程图来看，每个核心流程实际上是过程调用数据来完成特定的系统部分业务逻辑。业务逻辑是对业务实体及相关业务规则的封装，可以通过类子模型来描述。因此，本文在提取业务逻辑的时候选用的X样本点集合是以类子模型为基础，以类子模型间依赖关系的强度作为关联值。本文定义“关键类子模型”与“非关键类子模型”，作为关联值矩阵的行和列，进行关联值计算。

关键类子模型，是指从核心流程图中挑选出核心的、关键的类子模型，挑选的原则是分清业务相关类子模型的主次关系。我们依据核心流程图中业务逻辑相关过程来确定关键类子模型，如果某类子模型涉及到的过程权重较大，即该类子模型用于实现核心的功能业务，则将其作为“关键类子模型”的候选者。除去关键类子模型之外的其他类子模型称为非关键类子模型。改进算法如下：

输入：代数规约语言SOFIA描述的类子模型

输出：作为服务的类子模型集合

算法过程：

1）划分m个“关键类子模型”的样本点记为X={Xi}(i=1,2,…m)；划分n个“非关键类子模型”的样本点记为X={Xj}(j=1,2,…n)；

2）求任意两个样本点的过程关联值Pij和业务逻辑关联值Lij；

3）计算m+n个样本点的关联值Vij，得到以 Xi为行，Xj为列的关联值矩阵D；

另一类研究则是以温特为代表的建构主义理论。温特将文化定义为“社会共有知识”，包括微观结构中的共同知识和宏观结构中的集体知识。他认为，大部分国家所处的重要结构是由观念而不是物质力量构成的。国际生活的特征取决于国家与国家之间相互存有的信念和期望，即霍布斯、洛克、康德三种文化哪一种占主导地位。它们分别基于三种角色关系，即：敌人、竞争对手、朋友。而共有观念形成后则会塑造国家的身份，进而影响其利益与行为。[9]

4）设定阈值Vmin；

5）ifVij≥Vmin，thenXiXj放 入 一 个 聚 集（∈collect i）；

6）ifXiXk∈collect iandXkXj∈collect i，then XiXkXj∈ collect i；

7）将collect i转化为作为服务的类子模型集合。

对于某些特殊情况：1）如果类子模型对应的所有关联值都小于Vmin，那么有必要根据这些类子模型对应的业务功能，将这些非关键类子模型单独作为一个服务的类子模型集合或者舍去不予考虑；2）如果某个非关键类子模型Xj与多个关键类子模型Xi(i=1,2,…,m)的关联值都相等，且都大于Vmin，则需比较所有Vij(i=1,2,…,m)的大小，然后将Xj分配给Vij值最大的那个关键类子模型。

3.2.2 确定关联值

由于业务逻辑和类子模型不是孤立存在的事物，它们通过相互作用以完成系统特定的功能需求。综合考虑以上因素，本文提出关联值计算公式：其中Ip和Il分别代表Pij和Lij的权重系数，根据两者在具体系统的相对重要性来确定数值。Pij表示过程关联值，Lij表示业务逻辑关联值，关联值Vij为两者加权和。

类子模型间的过程关联主要通过类子模型关系来表示，因此，我们需要依据类子模型来计算类间的过程关联值。3.1.1介绍了类子模型间的关系，本文设定extends关系为类子模型间最紧密的关系，其过程关联值为3；uses关系中的Attribute-uses关系为次紧密关系，其过程关联值为2；uses关系中的Operation-uses关系为微紧密关系，其过程关联值为1；除以上三种关系之外的皆为稀疏关系，过程关联值为0。

除了需要确定类子模型间的过程关联值以外，还需要结合系统核心流程图和业务逻辑来计算类子模型间的业务逻辑关联值。业务逻辑关联值的计算公式如下：

我们以关键类子模型和非关键类子模型作为矩阵的行和列，分别计算其过程关联值表Pij和业务逻辑关联值Lij，得到过程关联值矩阵和业务逻辑关联值矩阵，最后，由关联值计算公式Vij=Ip×Pij+Il×Lij计算得到关联值矩阵D。由于在业务逻辑关联值的计算中往往一个业务逻辑涉及多个类子模型，我们设定阈值公式：

3.3 服务封装

从本质上说，封装就是将非面向服务系统中的业务逻辑包装成Web服务，使这些Web服务能对外提供服务［15］。封装者可以直接调用系统的事务处理程序，接收返回的结果再传给Web服务的消费者，为此封装者要知道系统中事务所能完成的工作以及输入输出参数。服务的封装包括以下步骤：

1）新功能组件的开发

识别后的服务需要经过封装形成Web服务。考虑到系统的稳定性，开发实现了服务的功能的新功能组件来作为SOA和系统底层实现的中间层结构，实现松耦合组件化的同时保证了系统的稳定性。按照自底向上的原则，先实现简单服务的功能组件，然后根据组合服务的调用关系在简单服务功能组件的基础上组合开发实现组合服务功能。

2）服务接口的开发

服务接口开发主要分为消息类型的定义和服务的描述。根据新功能组件的输入输出类型定义服务对应的输入输出消息类型。通过Web服务描述语言（WSDL）对服务功能、服务可以支持的操作，以及每个操作接受和返回的参数进行描述。

3）消息的传输

因为服务是面向消息的，因此传输机制对于服务是必需的。SOAP使用基于XML的数据结构和超文本传输协议（HTTP）的组合定义了一个标准的方法来使用Internet上各种不同操作环境中的分布式对象。因此要实现Web服务需集成SOAP处理器以支持消息在Web上的传输。

4 应用实例：MTAC

本文选取开源软件MTAC（More than a Calculator）进行服务集成。MTAC是一个功能强大、小而易用的数学计算工具软件，它具有计算、求导和函数图像绘制等功能。它的很多功能都能作为Web服务集成在面向服务环境中。

经过初步的类子模型描述得知MTAC由72个类、5869行代码组成。其中抽象类个数为3、总方法数为293、总属性数为168。如表1所示。

表1 MTAC类子模型度量

通过对源代码进行数据流分析得到系统核心流程图，如图2所示。由图可知，MTAC核心过程分为表达式解析、数字运算、功能运算和求导运算；核心数据为表达式；核心决策为表达式类型决策、变量个数决策、求导决策和计算完成决策。根据3.1.1节类子模型精简原则，我们剔除了8个系统主界面类子模型、12个功能界面类子模型、8个异常类子模型、3个静态内部类子模型和1个主程序入口类子模型。精简后的类子模型规模大小为40，包含两个抽象类。

图2 MTAC核心流程图

从系统核心流程图中除去循环决策之后的圈复杂度为4，因此可以确定基本路径有4条，图2中以 pi(i=1,2,3,4)表示4条基本路径。

通过阅读程序说明文档和人工对程序进行操作等面向功能的“自顶向下”的逻辑分析，结合核心流程图中的基本路径得出以下4个业务逻辑：

1）纯数字的数字表达式运算业务逻辑bl1；

2）单个变量的求导运算业务逻辑bl2；

3）多个变量的功能表达式运算业务逻辑；

4）单个变量的功能表达式运算业务逻辑。

其中3）、4）业务逻辑涉及的类子模型是相同的，因此我们将3）、4）合并成一个业务逻辑：

变量的功能表达式运算业务逻辑bl3

为了清晰可见，本文实验过程中将Function的25个子类按照功能特性合并成3个类子模型用作聚类分析，分别以Function1（S16）、Function2（S17）和Function3（S18）表示。MTAC参与聚类分析的类子模型和类的对应关系如表2所示。

表2 MTAC类子模型度量

按照3.2.1关键类子模型的挑选原则选取“关键类子模型”，结果用集合｛Si}（i=4，5，9，12）表示；其余类子模型为“非关键类子模型”，结果用集合｛Sj｝（ j=1，2，3，6，7，8，10，11，13，14，15，16，17，18）表示。

根据本文3.2.2节过程关联值设定规则，分析关键类子模型和非关键类子模型之间的关系，得到过程关联值矩阵1。

矩阵1过程关联值矩阵

下面求类子模型之间的业务逻辑关联值，由上文业务逻辑的分析过程我们得知，纯数字的数字表达式运算业务逻辑bl1涉及的类子模型有S4、S5、S7、S8、S11、S15，其中对 S5、S8、S11、S15会进行多次调用，所以对应矩阵值为2；单个变量的求导运算bl2涉及的类子模型有 S2、S4、S5、S8、S9、S10、S11、S12、S13、S16，其中 S5、S9、S10、S11、S12、S13、C16需调用多次，所以对应矩阵值为2；变量的功能表达式运算业务逻辑bl3涉及的类子模型有 S2、S4、S5、S9、S10、S11、S16、S17，其中S2、S9、S10、S11、S17进行多次调用，同理他们的矩阵值为2。建立0-1包含矩阵（如果某业务逻辑涉及到类子模型 Si，就将 Si的矩阵值记为 1，否则记为 0），另外考虑类子模型的调用次数，单次调用为1，多次调用为2。

继续考虑每个业务逻辑 bli所占的权重，本文通过每个业务逻辑关联的功能个数来定义Wi，比如变量的功能表达式运算W3=13/25=0.52，同理Wi=｛1，0.24，0.52｝（i=1，2，3），将这些权值乘以0-1包含矩阵得到业务逻辑关联矩阵，如矩阵2所示。

矩阵2业务逻辑关联矩阵

对照矩阵2，根据式（2）计算出关键类子模型和非关键类子模型的业务逻辑关联值Lij，结果如矩阵3所示。根据式（1）计算关联值，取 Ip=0.4，Ip=0.6，综合矩阵1和矩阵3，得到关联值矩阵4。

矩阵3业务逻辑关联值矩阵

矩阵4关联值矩阵

根据式（3）可以计算出阈值Vmin=0.499。结果显示，两个关键类子模型S4和S9聚合了类子模型S2，但是 V42=0.856

实验结果表明，从MTAC系统中可以提取以下粗粒度、松耦合的服务：表达式解析服务；算术表达式计算服务；功能表达式计算服务；表达式求导服务。由于业务逻辑是用户需求功能的体现，所以在服务提供时需要将服务进行组合以实现相应的业务逻辑，最后以组合服务的形式体现给用户使用：表达式解析服务+算术表达式计算服务实现纯数字的数字表达式运算业务逻辑、表达式解析服务+功能表达式计算服务实现变量的功能表达式运算业务逻辑、表达式解析服务+表达式求导服务实现单个变量的求导运算业务逻辑。

图3 MTAC Web服务的WSDL描述文档

最后，利用服务封装技术对服务进行封装。在MyEclipse中创建了一个简单的Web服务和Web服务客户端，开发与服务对应的功能组件和接口，并使用Apache Tomcat和REST框架的自下而上策略进行部署。图3显示了WSDL中的MTAC Web服务的接口描述。图4显示了从Web服务客户端测试生成的MTAC Web服务时的屏幕截图。

图4 测试生成的Web服务

5 结语

本文通过分析当前面向服务集成方法的局限性，从业务逻辑和形式化描述系统出发，结合聚类技术和服务封装技术提出了一种基于代数规约的面向服务集成的灰盒方法。这种方法提供了更高的适应性，能更好地理解系统，使得维护变得更加简单。通过实际的应用案例MTAC及其实验分析验证了本文方法的有效性。本文的工作还有待进一步完善。首先，人工的参与和决策在规模较大的系统中难以保证准确性和完整性。其次，对集成后系统的功能验证还仅局限于实验参与人员的手动测试。在未来的研究中，将从服务鉴别自动化和服务验证两方面对本文的方法进行优化和改进。一方面优化聚类算法，提供一套可用于鉴别不同类型业务逻辑的度量准则，实现非面向服务系统中服务的自动化鉴别。另一方面结合代数规约语言SOFIA在Web服务自动化测试的研究成果［18～19］，对服务进行验证。