基于SOA的系统自动生成研究

基于SOA的系统自动生成研究

姓名：朱骏申请学位级别：硕士专业：计算机软件与理论指导教师：徐政权

20090526

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

摘 要

自动程序设计是使用自动化手段进行程序设计的技术和过程，后发展成为使用自动化手段进行软件系统生成的方法，被称为软件自动化。其目的在于提高软件生产率和软件产品质量。软件自动化过程通常包括从问题的非形式化描述到形式化的软件需求规格说明、功能规格说明、设计规格说明，再到可执行代码生成、调试以及确认交付的全过程。

传统的软件自动化方法通常是基于代码生成的，而这些方法难以适应大型系统构建的要求。基于软件复用的软件系统自动生成技术在此方面则很有潜力，与传统的软件自动化不同的是，这里的系统生成是基于可复用程序代码或称组件的。研究使用面向服务的架构，将可复用组件作为服务提供，根据项目的非形式化描述生成功能规格说明、设计规格说明，然后对服务库里的服务进行检索匹配，最后使用基于SOA（Service Oriented Architecture）的服务组装技术生成系统。研究的重点在于系统的自动生成，首先讨论了系统规格说明的自动生成、需求与服务组件的形式化描述以及服务的检索、匹配和组装技术，然后将人工智能技术和遗传算法用于软件系统自动化，同时结合SOA技术进行系统生成。

在上述系统自动生成理论的基础上，得到一个基于SOA的系统自动生成平台的设计方案，实现了自动生成系统框架AutoSOM。AutoSOM是一个基于SOA的系统生成平台，作为软件自动生成系统SoftMaker的重要组成部分，AutoSOM在企业服务总线的基础上构建了一个从需求理解到服务组装的系统生成平台，使用户需求得到充分的理解，减轻软件工程沟通环节的负担，对已有可复用的软件资产以服务的方式进行充分利用，并进行智能匹配组装、生成系统。本系统功能完全符合自动化程序设计的思想，根据用户非形式化的需求描述，即只要输入对系统各个方面的要求就可以自动生成基于SOA的系统解决方案。

关键词：自动程序设计，面向服务体系结构，遗传算法，人工智能，软件复用

I

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

Abstract

Automatic programming, which then evolved into a software generation technology called software automation, is a technology or process of program designing by automatic methods. The goal of automatic programming is to improve the productivity and quality of software. Traditional process of software automation is usually the whole process from requirement description to executive program consignation.

Traditional software automation methods are usually based on code generation which is not fit for constructing enterprise systems. The software automatic generation methods based on reusable component are potential in this field. Be different to traditional software automation, our study is based on reusable program component. We choose SOA (Service Oriented Architecture) as our system architecture, so the reusable software components here are offered as services. The unformulated requirement description will be changed into formulated specification, and the services in the service store will be queried and matched with the specification, then at last combined into a system on the basis of SOA. The key of this study is system automatic generation, mainly about changing the requirement description into a formulated specification, formulated descriptions of service component and its querying, matching and combining technology. In this work we use artificial intelligence technology and genetic algorithm in software automation, and then generate a software system with the SOA related technology.

On the basis of the above system generation theory, we proposed a solution for system automatic generation platform with SOA, implemented an automatic generation system architecture called AutoSOM, which is a platform to automatically generate software system. As an important component of SoftMaker, AutoSOM build a system generation platform on ESB, and it can help the software developer in aspects from requirement understanding to service combining. This system is designed with the idea of automatic programming, and it can automatically generate a propositional solution based on SOA according to the requirement description.

Key words: Automatic Programming, SOA, Genetic Algorithm, Artificial Intelligence, Software Reuse

II

独创性声明

本人声明：所呈交的学位论文是我个人在导师指导下进行的研究工作及取得的研究成果。尽我所知，除文中已经标明引用的内容外，本论文不包含任何其他个人或集体已经发表或撰写过的研究成果。对本文的研究做出贡献的个人和集体，均已在文中以明确方式标明。本人完全意识到本声明的法律结果由本人承担。

学位论文作者签名： 日期： 年 月 日

学位论文版权使用授权书

本学位论文作者完全了解学校有关保留、使用学位论文的规定，即：学校有权保留并向国家有关部门或机构送交论文的复印件和电子版，允许论文被查阅和借阅。本人授权华中科技大学可以将本学位论文的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存和汇编本学位论文。

保密□，在________年解密后适用本授权书。

本论文属于

不保密□。

（请在以上方框内打“v”）

学位论文作者签名：

指导教师签名：

日期： 年 月 日 日期： 年 月 日

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

1绪论

1.1课题背景

软件开发工作的繁琐与低效一直困扰着广大开发人员，这种情况在软件规模越来越大、复杂度越来越高的今天显得尤为突出。如果在条件允许的情况下将一些重复性工作交给计算机来完成，即使用自动化的手段进行软件的开发，无疑将大大提高软件生产率和软件质量。

在软件开发过程中使用自动化技术生成系统的行为被称为软件自动化。对于软件自动化这个概念，学术界有两种理解方式，广义的理解包括在软件开发过程中用到的所有计算机辅助行为和手段；狭义的理解则专指根据需求描述自动生成软件系统的技术和方法[1]。软件自动化的思想由来已久，自从软件诞生以来，研究人员就没有停止过对软件自动化的追求。然而，由于技术方面的原因，真正意义上的软件自动化从来就没有完整地实现过，但是在广大研究人员的不断努力下，也取得了很大成就，特别是以软件组件为基础的软件复用技术的发展，给软件自动化的实现开辟了新的思路和途径。

软件复用是指通过引进可用的软件资产进行系统开发的技术和行为。目前，软件自动化和软件复用技术是伴随着发展的，两者互为手段，软件复用的过程要用到自动化技术，而软件自动化又往往是基于软件复用的。软件复用可以根据操作过程分为组装方式和生成方式，组装方式靠集成已有的软件组件得到系统，而生成方式则使用规约和应用逻辑来生成所需系统。由于对复杂逻辑进行准确描述的难度很大，有关生成方式的软件复用研究至今还没取得有现实意义的成果。随着分布式组件技术的发展，研究人员逐渐发现，以组装方式进行的软件复用更适合构建企业级、分布式应用系统，而基于组件的软件开发也因此成为研究的热点。

软件组件是一个自运行的、能发布也便于合成的功能单元[2]。现在组件技术已经逐渐成熟并成为软件开发过程中的重要成分，在研究领域有3C模型、刻面模型和CCM（Common Component Model）模型这类概念模型用于形式化研究，在工业

1

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

界有COM/DCOM(Component Object Model, Distributed Component Object Model)、EJB（Enterprise Java Bean）等组件标准用于系统构建。这些标准化组件在软件开发中得到广泛运用，尤其是在大型信息系统的实施过程中，使用标准组件进行软件开发已经成为增强系统扩展能力和可维护性的主要手段。

然而，虽然有了各类组件模型以及相应的开发环境和技术，研究人员还是没有完整实现通过组件组装进行软件开发的理想，大多数情况下，开发人员仍然使用着手工编写代码的原始开发方法。原因很多，主要有以下几个方面：

(1) 使用组件组装进行系统开发通常需要用到复杂的开发方法和技术； (2) 大量存在的组件标准和异构的应用环境使得开发人员无从选择；

(3) 为满足各种应用系统的要求，组件需要具有较高的普适性，这也增加了组件开发与系统部署的难度。

因此，在组件复用的过程中，不使用自动化开发平台进行组件的动态获取和组装，就无法保证软件质量，在增大软件出错率的同时还会造成严重的性能问题。基于以上认识，研究者们要求使用能够被计算机理解的方式描述用户需求和组件结构，并创立一套基于组件技术的自动化方案和工具来进行软件自动化开发[3]。另一方面，为了解决分布式系统中组件构建技术和组件运行平台的异构性问题，面向服务体系结构作为分布式系统解决方案逐渐成为软件开发者的首选。面向服务体系结构是一个分布式组件模型，把软件功能单元作为服务提供，并通过标准接口和契约进行调用，以服务总线的方式进行集成，给企业级系统开发提供了更为灵活的实施方法[4]，也为基于组件复用的软件自动化开拓了广阔的前景。

1.2国内外研究现状 1.2.1软件自动化研究现状

随着软件产业的高速发展以及软件技术的不断进步，人们在长期的软件开发工作中积累了大量经验，并以此总结出一系列编程思想，而软件自动化技术在这些思想的带动下也逐渐成熟并开始应用于实际系统。

2

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

以往研究人员用于软件自动化实现的途径主要包括演绎综合、程序变换、归纳综合和过程实现[5]，并在这些方面取得了不少成就，比如J. Robinson提出的用于自动定理证明的归结原理、德国慕尼黑大学研制的用于程序变换的广谱系统等。然而由于种种原因，这些系统并没有得到实际应用[6]。

近年来，随着软件复用和软件组件技术的发展，基于组件复用的软件生成方法为实现软件自动化开辟了新思路。软件复用和组件技术的发展也经历了一个相当漫长的过程，软件复用的概念产生于1968年的NATO软件工程会议，在论文《大量生产的软件组件》中Mcllroy提出了组件和软件工厂的思想，并把软件复用看作是提高软件生产效率的主要途径[7-9]。由于技术方面的原因，这种思想直到80年代才慢慢成为现实，面向对象方法和技术的发展为组件复用提供了技术支持，在此基础上，软件复用技术的研究已取得了阶段性成果。在国际上，专家学者们提出了众多的组件模型，如3C模型、刻面模型等，微软的COM组件技术在其众多的软件开发工具中得到应用，而Sun的Java语言本身就是基于组件的。在国内业界，青鸟、中软等公司都通过组件复用来进行系统开发，并获得了一定范围内的成功。

随着组件技术的发展，软件自动化也有了新的发展动向，人们开始从组件复用的思路来进行软件系统自动生成技术的研究，Stanford大学的Koza教授提出的基于遗传算法的遗传编程在软件复用领域得到应用，也给软件自动化的研究指明了方向。Koza教授于1992年在《基于自然选择法则的计算机程序设计》中首次提出遗传程序设计的概念[10]，接着他又在1994年出版的专著《可重用程序的自动发现》进一步加深了对这种方法和技术的研究[11]。另一方面，其他研究人员也不断提出与此相关的理论和方法，使软件自动化的研究进入了一个全新的阶段。

目前，在国内也有很多学者开展了这个方面的研究，如国家智能计算机研究开发中心的薛锦云、冯圣中提出的形式化方法制导的软件自动化研究已被列为科技部重大研究专项，武汉大学软件工程国家重点实验室的康立山等人提出了基于程序重用的自动程序设计方法[12]，中南大学的王四春等人提出了基于遗传程序设计的软件组件挑选方法[13]。

3

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

1.2.2面向服务的体系结构

作为一种分布式系统构建模型，SOA（Service Oriented Architecture）于１９９６年由Gartner Group提出，其基本思想是把软件功能作为服务提供，虽然提出较早，但由于当时技术的不成熟，并没有广泛应用。随着Web服务以及相关技术的发展，SOA开始成为研究的热点，许多研究机构参与到SOA的研究之中，并取得了巨大的成就。在基础研究方面，国际计算协会创办了服务导向计算国际会议来发布SOA相关的创新成果，信息标准化组织OASIS也专门组织委员会对SOA标准进行了研究，并发布了SOA参考模型[14]。如今，SOA已经开始应用于业界，IBM、BEA等软件巨头都表示自己的产品完全支持SOA。　

在国内，中科院计算所、软件所对SOA技术都有研究，并取得一定的成果，不过目前国内对SOA的研究还处于发展阶段。由于SOA具有的良好跨平台和协议无关性，它被广泛的应用于企业级系统集成，这也推动了基于SOA的系统集成技术和集成框架的发展，如Dieter Fensel提出的集成服务框架WSMF（Web Service Modeling Framework）[15]；费操提出的通过元模型进行操作的服务集成框架[16]；黄英提出的关于业务集成的服务合成框架[17]；IBM公司的Websphere平台技术文档中也介绍了相应的企业应用集成方案；IONA公司研制出服务集成平台Orbix E2A系统。　

在本研究室，葛新宇对基于设计模式的服务集成框架进行了研究，杨文军提出了基于规则的服务动态组合框架，陈飞提出了基于工作流的服务动态组合模型。但是这些框架或原型系统都存在两个问题，第一，它们都是根据特定领域提出的具体方案，不具有普遍意义；第二，仍然需要手工的查找、匹配和集成系统，无法实现自动化生成。　

1.3研究内容和意义

软件自动化要求在没有程序员参与的情况下将形式化规格说明转换成可执行程序，也就是说不需要进行编程就可以获得解决现实问题的计算机程序。在软件工程领域，由于大型软件系统的复杂性，纯粹通过程序生成来获得满足用户需求的应用系统非常困难，于是研究人员逐渐将研究重点从程序生成转向以组件技术为基础的

4

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

系统自动组装方法。

根据当前的技术条件，完全自动地进行大型系统生成还是难以实现，但是在系统规模不断增大、开发过程更加复杂的情况下，自动的系统生成方法和系统自动生成平台的研究很有必要，特别是在组件的发现、匹配和组装等过程中，没有自动化工具的帮助，系统质量难以保证。本课题对用户需求、软件功能以及组件模型的形式化描述进行研究，给出一个服务组件模型，并在此服务组件模型和SOA的基础上使用相关算法进行语义相关的检索、匹配和组装。最后设计出一个系统自动化生成的解决方案，并实现了原型系统AutoSOM。该系统支持非形式化需求到形式化规格说明的转换，能够使用自动化的方法对服务组件进行获取和组装，实现自动化的软件复用和系统生成。

为了构建系统自动生成平台AutoSOM，论文围绕下面四个主要方面进行研究： (1) 需求的形式化描述

自然语言通常用于编写干系人之间的约定和系统开发文档，由于自然语言容易产生歧义且无法对系统进行精确描述，需要使用形式化的表述方式来保证软件产品的可靠性。从软件自动化的角度出发，为了自动或半自动地生成软件系统，这对形式化方法提出了更高的要求，这里比较了各种形式化方法的适用性并结合匹配算法的特点，使用断句分析提取系统需求并使用XML对需求进行形式化描述。

(2) 用于组件获取的遗传算法研究

研究致力于定义可复用组件的语义模型，设计并使用基于遗传算法的组件获取方案实现分布式系统中的服务发现、匹配和合成。遗传程序应用于自动程序设计领域已经取得成功，但只能获得程序而不是系统，如果把组件作为遗传程序的遗传个体，则可成为系统自动生成的重要途径。该研究设计了一种以语义Web服务为原型的服务组件模型，并提出了一套以遗传程序为中心的SOA系统自动生成方案，把服务组件当成遗传个体，以组件语义为遗传编码，用户需求作为自然选择条件，使用各种遗传算子改变基因并淘汰适应度低的基因型，最终获得满足需求的服务。

(3) 基于SOA的系统集成研究

组件组装是基于组件的软件开发的关键，而传统的组件技术由于结构复杂、协

5

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

议私有等方面的因素不能很好的满足企业级集成的需求，SOA由于其协议的通用性和平台、语言无关性成为组装系统的首选。对现有的SOA相关技术进行研究，并以服务总线的方式进行系统集成。

(4) 系统生成的自动化工具

系统的自动生成是软件自动化研究的目标，也是软件组件复用的最高境界。软件自动化需要有相关自动化工具的辅助，结合前面的检索、匹配算法和服务组装方案，给出面向用户需求的系统生成自动化设计方案，并实现了AutoSOM原型系统。

软件自动化的根本目标是提高软件生产率和软件质量。研究系统生成自动化平台AutoSOM的目的就是辅助软件系统生成的自动化，为用户提供自动化智能化的服务检索、匹配和组装方式，减少软件开发人员的工作量和参与程度，提高软件产品的质量，根据用户需求生成软件系统。

1.4论文的组织结构

本论文系统地介绍了基于SOA的服务组件自动获取和集成的相关理论和技术，提出了一种使用遗传程序设计自适应匹配服务并构造系统的方案，并给出了一个原型系统AutoSOM的实现。各章内容安排如下：

第一章是绪论，介绍了课题研究的背景和意义、国内外研究现状，以及论文的主要工作和组织结构。

第二章对软件开发过程中的自动化和形式化相关技术进行讨论，并对软件需求、服务组件的形式化与建模进行了研究。

第三章介绍了服务组件获取的全过程，对服务发现、匹配与合成算法分别进行了研究，并给出了使用本方案进行SOA系统生成的一般过程。

第四章介绍了SOA相关技术，对服务封装技术和系统集成技术进行了研究，并给出了使用总线进行服务集成的方案。

第五章详细介绍了系统自动生成平台AutoSOM的设计和实现，并与当前流行的WebSphere系统进行了比较。

第六章对全文的主要工作进行总结，并提出了下一阶段工作的展望。

6

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

2形式化与建模

软件是计算机的灵魂，自从计算机产生以来，硬件技术根据摩尔定律逐年翻番，而软件虽然也发展迅速，但始终跟不上硬件技术的发展速度，这和软件与日俱增的重要性成为矛盾。软件行业的现状不令人满意，其主要问题在于：第一，质量问题，在软件工程领域开发人员通常使用诸如可靠性、健壮性、易维护性、安全性等词汇来描述软件质量属性。而这些属性中的每一项都可能是造成软件无法满足要求的因素，而目前也没有一种银弹技术来满足所有的质量要求；第二，生产率问题，随着软件规模的增大和复杂性的提高，软件编制的工作变得日益繁琐，完全依赖手工开发的现状是每个软件工作人员的梦魇[18]。

软件人员一直努力需求一种提高软件质量和生产率的有效途径，使程序员从繁琐的机械性编码中解脱出来。软件自动化就是为此而生的一种技术，在软件开发过程中使用自动化技术，被认为是提高软件生产率和改善软件质量的根本途径。由于自然语言常有歧义且不够精确，使得用自然语言进行机器处理十分困难，因此这里必须采用形式化语言。在研制的系统中，非形式化的需求表述将被引导形式化，为了便于算法处理，这里使用自定的需求形式化结构，并以Web服务为基础提出一个服务组件模型GS（Genetic Service）模型。

2.1软件自动化概述

软件自动化是使用机器自动生成软件系统的手段和方法，狭义的理解主要指从规范化的功能规格说明自动生成计算机软件的过程[19]，广义的来看只要是通过计算机帮助进行软件生产活动都是某种程度的自动化。软件自动化的程度是相对的，比如编译系统就是一种低层的自动化。

2.1.1研究范围

研究人员尝试着以多角度进行软件自动化的研究，这些研究主要包括软件开发过程、规格说明、自动生成和自动验证四个方面的内容。

7

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

软件开发过程的研究涉及面较广，包括开发风格、开发模型、开发方法和工具等方面。开发风格指开发的外在表现，如自顶向下的分解与细化风格、自底向上的组合与集成风格等。开发模型是指开发的内部结构，如瀑布开发模型、螺旋开发模型等。开发方法和工具是实现开发模型的手段，开发方法如结构化程序设计方法、JACKSON方法以及基于组件的开发等。工具则有支持需求分析的分析工具、辅助设计的设计工具以及测试工具等。

规格说明是对软件各种属性的描述。软件实施按规格说明的要求进行，因此机器可理解的规格说明是软件自动化的基础。对规格说明的研究实质上就是形式化的研究，形式化是自动化的必要条件，使用什么样的形式化方法，使用什么样的形式语言，根据问题领域的不同而不同。自动生成是得到可执行程序的过程，这是软件自动化的关键，也是技术难点，并且随自动化层次越高，实施的难度越大。自动验证则是指软件系统正确性的自动验证，包括功能规格说明正确性、可执行程序正确性和转换过程正确性三个方面的工作。

2.1.2理论基础

为了解决软件自动化的相关问题，基础理论研究是不可缺少的，这些研究包括语言处理、人工智能和数理逻辑等方面。

语言处理是不可缺少的，由于人特别是普通用户通常使用的是自然语言，而机器却很难理解各种不精确有歧义的自然语言，这样人与机器的沟通就成为一个待解决的问题，因此有必要给人机的自然交互搭成一座桥梁，这座桥梁是双道的，包括自然语言的形式化和机器语言的自然化。

人工智能的研究必不可少，比如原型系统使用遗传程序对GS服务组件进行自动匹配就需要进化计算方面的知识，再比如机器学习应用于软件系统就可以使系统获得通过自我调节来适应环境的功能。

数理逻辑不可或缺，动态的系统生成过程的描述需要对动态逻辑进行研究，这也是本课题研究的理论基础。

8

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

2.1.3实现途径

一般来说，软件自动化的基本实现途径包括演绎综合、程序转换、归纳综合与过程实现。所谓演绎综合就是将数学定理证明中的演绎综合方法应用于程序生成，将证明过程中的步骤与计算步骤相对应。这种方法要求使用形式逻辑对规格说明进行描述，通常用于小程序的推导。

相对而言，程序转换途径的适用范围更广。顾名思义，程序转换就是将初始程序逐步转换使其合乎需求的过程，其整个开发流程可由一系列程序转换来完成。每次转换由开发人员选定的规则来实现，而系统的正确性则由清晰的过程结构以及完备的开发文档来保证。

与演绎综合相反，归纳综合是通过反映系统属性的用例归纳出程序。其实现方法大体上说有输入输出法和轨迹法两种，前者通过给定的一组输入输出二元组，逐步归纳演化导出合适的程序，后者通过所给实例的运行轨迹逐步导出程序。

过程实现是对规格说明各种元素进行映射而获得程序的方法。如果规则说明中的各种元素转换目标和映射结果明确，就能使用过程实现。其实现方法和程序编译原理基本相同，即使用某种语言来描述软件属性，然后使用该语言的编译程序自动生成目标程序。这种途径实现效率较高，但是从非算法性成分映射到算法性成分困难较大，因此通常只用于自动化层次较低的系统[20]。

当然，除了以上基本途径外，还包括基于知识的程序综合途径和这里所研究的基于可复用组件的系统构造方法。基于可复用组件的软件自动化与传统的软件自动化的区别在于操作粒度的大小，前者以集成标准组件的方式生成系统，类似于工业生产中的零件装配生产线，而后者仅限于程序语句和表达式的操作。由于软件工业的发展，软件系统规模越来越大，操作粒度更大的标准化组件进行系统生成的方式显然更适于满足软件自动化的要求。

2.2需求模型与形式化

通常来说，软件需求是指软件系统必须满足的所有功能、和质量属性的描述。系统是否满足需求是衡量一个软件系统质量的主要标准，也是软件开发终极目

9

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

标，而高效地获取软件需求和准确地描述软件需求也就成了软件工程研究的重点。

这里的研究关注点是自动化生成系统，显然以自然语言的需求描述方式不符合机器处理的要求，因此需求的形式化也是必然选择。

2.2.1面向问题领域的需求建模

面向问题领域的需求分析是采用问题领域划分的方式进行需求分析的一种分析方法，也是一种需求建模方法。面向问题领域的需求分析将问题领域进行逐层划分，最后生成层次树型结构，而层次树型结构正是下一章算法操作的数据结构，这里借鉴这种需求分析方法进行需求建模。

这里所说的问题领域指的是问题所处的客观世界[21]，问题领域是问题存在的基础和外部环境，问题不能离开问题领域而存在。为了满足用户的要求，计算机程序需要和问题所处的客观世界发生相互操作，这就表示一些操作将在问题域与机器域的重叠处进行。Jackson认为，良好的软件设计以充分的需求描述为前提，而充分的需求描述包括三个方面的内容，这三个方面指的是问题域、机器域和公共域[22]。问题域代表用户需求与现实环境，用需求分析文档来描述。机器域代表计算机程序代码。而公共域代表前两者的接口，描述的是计算机程序在系统环境中运行的效果，由需求规格说明文档来表示，如图2-1所示。

图2-1 需求分析文档、规格说明和程序之间的关系

需求分析文档可分为问题领域的相关知识表达（用K表示）和用户需求（用R表示）两方面。如果用S表示需求规格说明，则有如下关系：

K,S⇒R 2-1

10

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

由上述式子可以看出，由于问题知识通常在一定范围内是不变的，因此表述清晰的需求规格说明可以充分表达用户需求。

面向问题领域的分析方法以边界清晰的问题领域划分为基础。研究人员在分析复杂问题的时候通常采用困难分解的方法，在软件设计领域也是如此。结构化程序设计就是问题分解方法的典型应用，它采用自顶向下逐层分解的方法进行程序设计，这也是面向问题领域分析的基本方法[23]。由于每个功能层次都可能有多种划分方式，而在分解过程结束之前却无法评判划分方式的优劣，这里使用并行处理的方式对问题领域进行划分[24]。

由于功能划分按照自顶向下逐步求精的方式进行，最终的需求模型必定是一个层次结构，比如一个校园信息化系统可分解为学籍管理、成绩管理、奖学金管理、课程管理等部分。而每个部分又可继续分解，如学籍管理可分为休学、毕业、退学和降级等部分，如图2-2所示。

图2-2 校园信息化领域划分

当然，实际的应用系统远比此图复杂，但从整体上说通过问题领域划分建立的需求模型是层次结构的模型。

2.2.2需求的形式化描述

为了使需求模型更加规范、无歧义且便于机器处理，必须使用形式化的方法描述需求。应该说规格说明的形式化不只是一种技术，而是多种技术的综合运用，它

11

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

需要将这些技术统一起来对系统的各个方面进行描述。通常使用的形式化方法需要用到集合论和形式逻辑基本理论，比如Z、VDM和B方法[25]。第五章所设计的应用系统提供将非形式化的需求引导转化为这些方法描述的功能，但由于第三章的服务匹配算法是基于树型结构的，故这里不对这些方法做进一步描述，有兴趣的可以参考相关文献。

在这里的研究中将问题领域和需求模型看作是层次结构，可以用树结构来表达。而XML语言可以很好的描述树型结构并且和Web服务相关技术有共同的理论技术，在实现上有大量相关技术可以运用，因此，可以认为XML是描述层次化需求模型的最好选择。上一节的问题划分用XML的形式化描述如下。

<需求 名称=\"校园信息化\" id=\"1\">

<需求 名称=\"学籍管理\" id=\"2\" pid=\"1\"> <需求 名称=\"申请休学\" id=\"4\" pid=\"2\"> <输入>学生基本信息 <输入>申请理由 <输出>审批结果 <输出>复学时间

<需求 名称=\"毕业处理\" id=\"5\" pid=\"2\"> <输入>全部学生信息

<输出>符合毕业条件的学生信息

<需求 名称=\"课程管理\" id=\"3\" pid=\"1\"> <需求 名称=\"课程查询\" id=\"9\" pid=\"3\"> <输入>课程名称 <输入>课程编号 <输入>开课老师 <输出>课程相关信息

<需求 名称=\"选课\" id=\"11\" pid=\"3\"> <输入>学生信息 <输入>课程信息 <输出>选课结果

12

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

2.3服务组件模型

在SOA方法学中，服务组件无疑是其中的核心概念，在工业上用于SOA的组件标准也有不少，如Sun的JBI（Java Business Integration）组件和IBM的SCA（Service Component Architecture）组件就是其中较为出色的两个组件标准，但无论是这些SOA专用组件也好还是曾经的Web服务、EJB也好，都没有一个统一的包含清晰语义描述的模型。这里根据组件模型的一般性原理，在考虑添加语义行为描述的同时参考当前流行的一些组件模型设计方案，给出了一种富语义的服务组件模型，并以此作为服务检索匹配算法的操作对象和服务组件复用的理论基础。

2.3.1服务组件模型的一般原理

通常来说，一个好的服务模型必须准确充分地描述服务在构建和运行过程中的特征属性和核心元素，它将是所有工业标准的抽象和依据，也是服务组件开发和服务组合的理论基础。

服务组件作为一种可复用资产，其形式化表述即要遵循可复用资产表述的一般要求又要符合服务组件的自身特点。在可复用资产的形式化表述问题上，美国国防部软件复用促进文献给出这样七条要求以供参考[26]：(1)资产描述的形式化；(2)规模的可变性；(3)演变过程的记录；(4)面向对象方案的实施；(5)不带内部实现描述的规格说明；(6)多重保障的安全性；(7)人的因素。另一方面，作为服务组件，又必须满足跨平台、协议和语言无关的分布式系统构建需求。

因此，综合可复用资产的上述要求以及服务组件自身的特点，可以得到好的服务模型应该遵循的一般原理：

(1) 规范化，应该使用标准的机器可理解的方式表述服务，以免造成定义不清和语义表述的模糊性；

(2) 可变性，服务组件模型是各种服务实现方法的抽象，要在必要时能够进行扩展和变换，满足不同实现技术的要求，也要为新技术的出现留下余地；

(3) 全面性，服务组件模型要综合考虑各方项目干系人的需求，尽可能全面的反应服务在各种语境中的不同应用；

13

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

(4) 充分性，应该具有充分描述各种组合关系的能力，能够描述通过继承、聚合等各种形式生成的系统；

(5) 通用接口和标准协议，在分布式系统中的跨平台调用要求服务组件模型使用通用接口和标准协议进行交互；

(6) 企业级，服务组件模型基于分布式企业应用背景，服务模型要能够支持企业级服务组件的描述。

这里的服务组件模型将基于以上原则并结合SOA系统的特点来构建，并使之适用于下一章的遗传程序设计。

2.3.2服务组件的概念模型

这里研究定义一个服务组件概念模型GS模型，该模型不包含任何具体开发技术和实现方法，且富于语义描述，为下一章的服务自动发现、匹配和组合奠定基础。本模型的建立是依据上一节的一般原理和SOA体系结构的特点，并参照了GP-CBD模型、SCA组件模型以及一些传统组件模型如3C模型、刻面模型等。

定义2.1 服务组件由组件接口、组件契约和组件实现三部分组成，即

SC=I2C 2-2

这里SC（Service Component）表示服务组件，第一个I表示接口（Interface），接口在不同的工业模型里表现不同，对于EJB是interface，COM的接口是IDL，而在Web服务里接口是WSDL，第二个I表示实现（Implementation），而 C则表示契约（Contract）。接口、契约和实现都可以有多个，这三个符号代表的都是集合，而服务组件则是这三个集合的笛卡尔积。

接口与实现分离是进行组件复用的技术基础，而将语义与接口、实现分离实现富语义组件则是为了实现组件优化检索、匹配和组合的基本要求，也是缩小组件创建者和组件使用者认识差别的需要。以往的组件通常将语义隐含在接口里，接口由于其使用技术不同导致的异构性使得其中的语义很难被充分运用，而且由于缺乏专用的语义表达使组件的自动发现、匹配和组合面临很大困难。因此，将语义出来是必要的，语义在这里的概念模型里表达为契约。

14

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

契约是指在运行过程中，组件之间相互合作的动态结构以及组件服务之间相互依赖的静态关系，用来表示组件的上下文语义环境[27]。

定义2.2 契约由静态的服务内容和动态的服务行为组成，并基于一定的应用环境表达。可以由如下公式表达

Contract=Content×Behavior×Context 2-3

对于服务组件来说，服务内容可有多个，服务行为和上下文环境也可有多个，契约依然表述为它们的笛卡尔积。用形式化的语言描述契约是发展趋势，下一节将讨论使用OWL-S（Ontology Web Language for Service）语言描述服务组件契约。

图2-3给出了前文定义的GS模型体系结构。

图2-3 GS组件模型的体系结构

从图中可以看出，接口、契约和实现是GS模型的三个组要部分，而契约又可以由内容、行为和语境三部分来表达。

下面将GS模型与其他组件模型进行比较，比较对象为主要参考模型GP-CBD模型、3C模型、刻面模型。

15

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

(1) 与GP-CBD模型比较，GS模型和GP-CBD模型在本质上是一致的，只是根据基于SOA的框架特色进行了适当改装，比如将契约用服务内容和服务行为来描述，以便于服务组件的发现与匹配。另外，GS模型在GP-CBD模型的基础上进行了适当的简化，比如GP-CBD模型的7个方面的描述改为3大组成部分。契约的名称和发布也被视做唯一而不在模型中标识出来。可以认为，GS模型更适合服务组件的自动发现、匹配和合成等过程。

(2) 与3C模型比较，3C模型从概念（Concept）、内容（Content）和语境（Context）三个方面对组件进行描述[28]。可以看出，3C模型没有对语法和语义进行明显区分，其接口和语境中均包含语法和语义的成分，因此可以认为它和GS模型是正交的。

(3) 与刻面模型比较，刻面模型通常用于组件的分类与查找，很多流行的组件模型实际上都是使用的刻面描述。该方法用一个词组或短语表示组件的一个方面，并根据关键词在语境中表现出的含义进行分类。刻面模型只包含语义元素且格式规范，便于形式化和计算机处理，应用非常广泛。事实上，GS模型的语义部分同样可以使用刻面模型，只是当前已经进入实践领域的刻面模型如REBOOT库还存在标准化程度不高，表达能力不强等缺点。

表2-1是对四种模型的六个主要方面进行的对比分析： GS

抽象性 高

形式化 强 强 强 强

应用性 是 是 否 是

复杂度 低 高 中 低

描述能力 强 强 不详 弱

关注点分离 是 是 不详 不详

GP-BCD 低 3C 刻面

高 高

表2-1 GS模型和现有组件模型对比

2.3.3服务组件的语义描述

GS模型的主要特点在于语法和语义分离的结构，这种结构如果没有标准化的语义模型支持也无法成为富语义的服务组件。另外，由于SOA属于企业级、分布式体系结构，而基于SOA的系统集成所用到的组件服务也必定是黑盒的，这种特性在提

16

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

高了系统的可扩展性的同时也加大了语义问题的处理难度。因此，有必要在GS模型的基础上加强语义结构的形式化和标准化。

下面就给出一个简单的语义模型，并使其符合Web服务的特点。

定义2.3 服务语义是对服务的解释，包括服务的内容、意义和用法，由服务定义、服务领域和服务环境三部分描述，即

S=D2C 2-4

上式中S表示服务组件语义，两个D分别表示服务定义和服务领域，C表示服务环境，它与2-3式的契约表述兼容。契约重在描述内容，而此模型重在描述语义结构。

服务定义是指对服务个体语义的描述，它直接决定服务组件的语义，语义定义可以表示为树结构。服务语境是指组件服务匹配、组装的上下文环境，它可以影响服务组件语义，定义元素只有融合了语境元素，才能充分表达服务语义。

领域模型是对服务领域的抽象描述，它描述语义的基本概念，同样表现为层次结构，其顶层为整个现实世界。从语义的角度上看，一个服务组件对应于一个领域模型。如果一个领域模型能充分必要的描述一个服务组件，那么该领域模型的语义元就代表该组件的语义。比如软件复用领域模型可用图2-4来表示。

图2-4 软件复用领域模型示例

上图的表述是相当简陋、不完整、不规范、非标准的。事实上，目前还没有建

17

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

立一个国际公认的领域模型标准，OMG正试图建立一个这样的行业标准，这可能是一个长期的过程。这里必须说明的是，如果不进行标准化，再好的语义描述方法也没有任何意义。

2.4组件模型的参考实现

GS组件模型可以通过现有的工业服务组件标准如SCA、JBI等进行改装实现。这里的实现采用给Web服务添加语义信息的方式，这种经过改装的Web服务被称为语义Web服务。学术界对语义Web服务已经有了一定程度的研究，并给出了基于本体的语义Web服务描述语言OWL-S。

众所周知，Web服务描述语言WSDL（Web Service Description Language）只是描述Web服务接口语法定义的语言，不包含语义描述，而OWL-S则是专门针对服务语义提出的。OWL-S拥有一个完备的本体库用来进行服务语义的描述，以服务需求和影响为依据导出结果。语义Web服务体系结构如图2-5所示。

图2-5 语义Web服务体系结构

使用语义Web服务要先通过本体知识来对服务进行规范化表达，再对添加了语义表达的Web服务来进行自动化的服务发现、匹配和组合。语义Web服务是语义网和Web服务复合的产物，OWL-S将本体领域知识用于Web服务，而本体具有结构清晰和知识表述丰富等优点，使得语义Web服务具有强大的语义描述能力[29]。由图2-5可以看出，语义Web服务体系结构基本符合GS模型。

18

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

2.5本章小结

为了使用自动化方法对服务组件进行搜索、匹配和组装，要求对代表问题域的需求和代表方案域的服务组件分别建模，并使之适合于相关算法操作。

本章是后续各章的基础，首先对软件自动化的现有技术方法进行了综述，然后是对需求建模使其成为树型结构并用XML语言描述，完成需求的形式化描述。接着提出了一个富语义的服务组件模型，完成对服务组件的形式化描述，形式化的需求和形式化的服务组件将成为下一章算法的操作对象。最后使用OWL-S语言描述的语义Web服务作为该模型的参考实现。

19

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

3服务组件的获取

面向服务体系结构（SOA）是跨平台、协议无关的分布式体系结构，基于SOA的开发包括服务组件的检索发现、匹配和集成过程。在这种体系结构中，服务组件的发现是基于整个互联网平台的，而互联息是海量的，如果使用人工查找的方式进行服务的检索将是相当繁琐的工作。当然，现今的企业系统开发也并非纯手工打造，也会用到一些辅助工具，比如搜索引擎之类。这些工具对服务的发现通常是基于关键词的，存在很多问题，比如高匹配低精度问题，动则搜到相关不相关的数万个结果让人无所适从，还有对词汇敏感度过高等一系列问题。因此，研究出一种对服务组件进行自动发现和匹配的方法势在必行。

另一方面，目前的SOA应用系统主要是将已有系统进行集成，而基于SOA的开发也停留在开发组件、集成组件的传统开发方式上，并没有大规模地利用互联网上的已有服务。此外，从系统开发的自动化程度来看，现有的SOA系统都是静态的，集成的服务组件都是事先给定的、功能已知的，并没有动态的对互联网进行自动检索发现并匹配组件，没有充分利用到SOA跨平台整合的优势。本章将给出标准化服务组件动态搜索、匹配与合成的方案，其中自动化服务匹配方案是基于前文定义的GS模型的一个遗传程序框架，自动化服务合成方案是基于OWL-S的语义Web合成，最后将给出一个基于GS组件的一般开发过程。

3.1服务组件的发现

服务发现是进行服务匹配和组合的基础，目前常用的服务发现方案主要是基于UDDI（Universal Description, Discovery, and Integration）技术的。UDDI把服务注册信息作为关键词，并对此进行匹配来发现服务，主要是对服务的各种属性值进行匹配[30]。同搜索引擎技术一样，UDDI也存在着准确率不高的问题。

为了准确地获取所需服务，学者们通过大量地研究发现服务语义在服务发现方面具有重要价值，通过给定语义模型和相似度计算的方法来挑选最优服务是一条可行路径。测试结果显示，对于互联网上的海量服务，如果对每个服务进行精确匹配

20

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

必然会影响效率，对于动态组合并不断演化的服务来说这种效率的影响将不是一次性的，每次优化的过程都会进行一次全范围的精确匹配，实在没有必要。而且本研究的服务获取过程的特点是分步进行，服务发现、匹配与组合过程分别，那么在服务发现过程只需对服务进行初步筛选，把精确匹配并使得服务最优化的过程交给服务匹配算法来完成。这样服务的选择就分两步进行，首先是初步挑选得到候选服务，然后对候选服务进行精确匹配。由于候选服务的数量相对于初选前要少很多，这样服务匹配的效率会更高。

假设初选算法对服务筛选的平均时间是t1，匹配算法对服务匹配的平均时间是

t2，服务总数为n，平均筛选率为

t2⋅nnt1⋅n+t2⋅

p

=

1

,(p>1)，那么使用分步匹配方法的加速比为： p1t11+t2p

3-1

如果t1远小于t2的话，那么加速比近似的等于p。

这里采用基于领域分类的方法进行服务的筛选，即使用OWL-S中的profile规范中的serviceCategory来描述服务类型，计算服务需求和候选服务的相似度，设置一定的阈值，把相似度大于该值的服务加入候选列表[31]。

3.2服务组件匹配与演化

本节将使用基于遗传算法的遗传程序设计方法来进行服务组件的匹配与演化。遗传算法是模拟遗传变异和自然选择过程的仿生计算模型，是一种通过模拟生物进化过程获取最优解的方法，由美国Michigan大学Holland教授于1975年率先给出。遗传程序设计是采用遗传算法的思想进行自动程序设计的一种方法，由Stanford大学的Koza教授于19年提出，它使用层次化的树形结构来进行演化计算，可以被看作是具有定向搜索能力的结构优化算法。

遗传程序通常运用于自动程序设计领域，它使用树结构来描述问题的解[32]。如果把树的叶子结点看成数据对象，中间结点看作操作这些对象的方法和过程，那么每个树结构代表着解决问题的一个方案，并由此得到对应的程序结构[3]。遗传程序通

21

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

过遗传变异等仿生手段对上述结构进行优化，最终获得满足要求的计算机程序。

如果把语义模型和服务组件看作是一对一，那么将表示成树结构的语义模型进行动态生成、演化使其适应服务运行的上下文环境就可以得到满足要求的服务组件，本章的服务组件自动匹配算法便是基于这种思想的，它适于对服务组件的动态匹配。如果把这种服务组件实例化为语义Web服务，则可以使用语义匹配的方式在整个互联网上进行服务匹配。

3.2.1遗传程序的适用性

服务的自动匹配和遗传程序在思想上是相通的，都是在解空间动态搜索、逐步演化获得最优解。技术与非技术因素决定的服务使用事实上也存在“适者生存”似的竞争，这在哲学意义上是普遍一致的。

下面从几个方面说明两种思想的相通性。

(1) 动态演化，服务组件要求根据需求的变化具有动态演化的能力，而遗传程序本身就是一种不断进化的模型，通过对人工选择环境的适应性差别来淘汰个体达到演化的目的。

(2) 个体性，服务组件要求是自描述且能运行的，而遗传程序中的每一个个体都是一个的结构。

(3) 环境适应性，服务组件要求根据需求环境来匹配挑选组件，而遗传程序正是通过对环境的适应度大小来淘汰个体。

(4) 优化升级，服务组件要求能够通过升级和维护使得组件更加完善、更加满足用户需求，而遗传程序中的个体由于环境选择的压力使得优秀个体保持高存活率来优化个体。

(5) 并行性，应用于分布式企业系统构建的服务组件来源的多样性和服务匹配目标同一性使得服务匹配需要以并行的方式进行，而遗传算法从本质上来说是适于并行计算的。

由上所述，遗传程序的思想与服务组件自动匹配具有很高的契合度，将遗传程序用于服务组件匹配将会促使SOA系统往自动化智能化方向发展。

22

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

3.2.2算法设计方案

遗传程序设计使用树结构来描述个体，其叶子节点和非叶子节点分别表示操作对象和操作过程。比如一个普通程序过程通常由条件过程、分支过程、循环过程、标准函数、表达式和运算符组成，这里把它们定义为一个函数集

F={f1,f2,f3...fn}

而其操作对象通常由各种数据结构、语义项或者可复用代码组成，也可以定义为一个操作对象集合

X={x1,x2,x3...xn}

对于任意一个以F中的元素为非叶子节点，X中的元素为叶子节点的树结构，都代表着一个普通程序过程。

如果要进行遗传变换，那这里还需要一个初始的树结构集合作为第一代个体。初始个体可以随机生成，一种常用的方案是随机地在集合FΥX中挑选元素ｎ作为树的节点，如果元素n∈X，那么ｎ将成为叶子节点不再生长，如果n∈F，那么根据ｎ的操作对象个数决定ｎ的子节点的个数，子节点同样采用以上方法递归的生成。这样生长出来的树是完全随机的，也将作为遗传选择的基础。为了避免树的深度过大，也可以定义叶子节点的深度小于给定的深度。　

接下来要定义个体的适应性，适应性是描述个体优劣的基本属性，也是决定个体生存概率的重要因素。通常有四种适应性描述方法，包括原始适应度、标准适应度、调整适应度和归一化适应度，其他三种适应度都是由原始适应度经过一定的数学变化得到的，这里只介绍原始适应度。　

对于数学计算过程来说原始适应度和误差正相关，可以描述为个体返回值和真实值的差的绝对值的总和，可以由式子表示为　

f=∑r(i)−t(i)　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　３－２　

i=1n

上式中r(i)表示个体对于输入应用对象i的返回值，ｔ表示真实值，ｎ是应用对象个数。当然，也可以用各项平方和的平方根来表示。　

遗传程序设计常用的几个基本遗传算子有复制、交叉和变异。复制表示父代个

23

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

体不经任何变化生成子代个体，父代个体可以由多种方法选择，常用的比例选择法即是按适应度大小分配概率的选择方法。交叉是由两个父代个体分别选择交叉节点交换子树生成子代的方法。由于复制和交叉都无法生成新基因，容易导致过早收敛，而变异有利于种群的多样性，通常变异采用随机删除某个节点及其子树，并重新生成新子树的方法。　

由于遗传程序是不断进化的，可以永远进行下去，所以必须告诉程序什么时候可以终止。通常的终止条件有两个，一个是群体进化到最大值，一个是问题得到成功求解，对于没有准确答案的问题可以采用近似条件来决定终止。

3.2.3程序实现框架

根据第二章的服务组件模型，组件语言由定义、领域和语境三部分组成，其中定义和语境共同描述单个组件实例，可以通过语义特征建模表述为语义特征树结构，其中树节点表示语义特征项，语义特征项之间的泛化关系和聚合关系均由父子节点结构层次化表示。领域空间则可以看作语义特征项的词汇表，语义特征项是领域空间元素的实例。

这样领域空间D相当于上一节中的FΥX，由于领域空间也是层次结构，其叶子节点集合相当于Ｘ。每一棵语义特征树对应于一个服务组件，在遗传算法中称为遗传个体编码，这样就可以使用上一节的算法方案对服务组件进行匹配、演化。接下来给出遗传算法的相关对应要素表达。　

适应性度量可以使用组件语义特征树和需求树的相似性度量，假设用tr和tc分别表示需求树和组件特征树，相似性　

d(tr,tc)=minLength(Tran)Tran∈Edit∗∧Tran(tr)=tc　　　　　　　　　　　　　　　　３－３　Length(Tran)表示将组件语义特征树变换成为需求树的步数。d表示变换操作的最小

{}步数，其值越小匹配程度越高。

假设F是初始组件语义特征树的集合，即初始种群，R表示需求特征树，

copy(F,x)表示个体复制方法，cross(F,x,y)表示交叉方法，aberr(F,x)表示变异方

法，fit(R,x)表示选择结果，term()表示终止准则，optim(F)表示最优解，pcop(x)、

24

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

pcr(x)和pabe(x)分别表示个体复制、交叉和变异的概率，s用来存放最优解，程序

的基本框架如图3-1所示。

图3-1 组件匹配演化程序基本框架

由于GS组件模型是一个演化模型，因此GS组件具有一定的生命周期，它将经历检索、选择、遗传操作、验证、度量、合成和部署、运行以及登记共八个阶段。在GS组件群体中，具有较高复用价值的组件得以保留，更新演化后的组件又作为新的可复用组件继续进化。

3.3服务组件的动态组合

服务组件的组合本质上是指原子服务之间的关联结构。静态的服务组合是通过人工的方法获得相关服务以及服务之间的关联结构，然后再使用诸如BPEL（Business Process Execution Language）之类的描述语言描述为业务流程。而动态组合则包含两层含义，一方面是相关服务的发现是机器自动完成，另一方面服务的组合不是固定不变而是不断演化的。　

事实上由于遗传算法具有个体进化的功能，上一节的算法框架同样适用与服务

25

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

的动态组合。不过这里更倾向于把上节算法用于挑选服务，而把优化组合服务的任务分出来用其他算法完成。本节设计一种基于语义相似度的排序算法进行服务的组合选择，然后使用OWL-S语言对语义Web服务的组合过程进行描述[33]。　

3.3.1服务组合算法

由于服务组件通常是顺序组合的，即后继服务的输入使用前驱服务的输出，其数据流结构大体上可以用拓扑图来表示，如图３－２所示。　

图３－２　Web服务组合序列　

如果将满足需求的服务定义为对合乎要求的输入能够得到正确的输出，那么上图中任一条路径都构成满足要求的服务组合。那么服务组合问题就成了路径选择问题，如果以服务质量等因素作为路径长度，这也就成了一个拓扑图的最短路径问题，可以使用最短路径算法如Dijkstra算法解决。不过由于最短路径算法通常要反复扫描路径，对于基于异构的分布式互联网的Web服务组合来说会造成严重的效率问题[34]。这里，研究将给出基于语义关联度的算法，首先先给出几个定义。　

定义３．１　　给定两个GS服务组件GS1,GS2，如果其领域相交、语境相容，且满足Output(GS1)⊇Input(GS2)，那么称GS1语义关联GS2，记作GS1→GS2，其中GS1称为前驱服务，GS2称为后继服务。　

定义３．２　　服务组合代表处理服务请求的一个服务序列GS1,GS2...GSn，且对任意i∈{x1≤x≤n−1,x∈N}，有GSi→GSi+1成立。　

定义３．３　　假设λ(x,y)表示服务x和服务y的语义关联度，TD表示完全满足需

26

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

求的标准服务，服务组合的满意度就是组合服务和TD的相似程度。对于服务组合GS1,GS2...GSn，其满意度SD可以这样计算：　

SD=λ(TD,GS1)⋅λ(GSn,TD)⋅∏λ(GSi,GSi+1)　　　　　　　　　　　　　　　　　　　　　３－４　

i=1n−1

其中语义关联度的计算方法研究已有很多成果可直接运用，这里不再赘述。　

如果将一个拓扑图中每个结点的后续结点按照语义关联度排序，那么经过这种排序的拓扑图将对应唯一的拓扑序列。那么算法可以这样描述，根据关联度排序顺序搜索服务序列，如果满意度达到一定的值则停止搜索。假设request表示服务需求，L表示存放服务组合序列的数据结构，A表示经过语义关联度排序的服务拓扑结构，

next(x)表示x在语义关联度有序的拓扑序列中的下一个服务，getMaxSD(A,x)表示

获得与x关联度最大的后继服务，rel(x,y)表示关联度，sat(L)表示满意度，程序主要过程描述如图３－３所示。　

图３－３　基于语义关联度的服务组合程序基本框架　

上述方案综合考虑了服务语义、服务质量和服务组合效率问题，能够在尽可能短的时间内获得满足需求的服务组合。在语义网领域，已经有学者证明过使用智能规划进行服务组合的可能性，但目前来看实际的应用还存在不少问题，如OWL-S描

27

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

述和规划算子的映射问题、快速定位到特定规划分支问题。　

3.3.2组合过程的描述

服务组合过程的描述方法很多，如BPEL、WSCI（Web Service Choreography Interface）、WFMC（Workflow Management Criterion）等，目前工业界用的比较多的是BPEL，在企业SOA领域，BPEL与SCA、SDO共称为SOA铁三角。然而，以上这些描述方法都是基于静态服务组合的，且不包含语义信息。这里的服务组合是动态的、基于语义的，因此可以使用OWL-S来对语义Web服务组合进行描述。　

上一章提到，OWL-S是一种基于本体的语言。本体是哲学中的一个概念，后来被知识工程学者借来用于领域知识的获取，但对于本体的定义方面学术界并没有达成一致。在人工智能领域，本体被定义为“构成相关领域词汇的基本术语和关系，以及利用这些术语和关系构成的规定这些词汇外延的规则的定义”，这个定义事实上给出了创建本体的过程。计算机界比较流行的是１９９３年Gruber给出的一个定义“本体是概念模型的明确的规范说明”。后来，Borst对此稍做修改，成为“本体是共享概念模型的形式化规范说明”。根据这个定义，研究过程中整个Web服务获取过程都是和本体有关的，需求模型和GS服务模型的定义和领域本体相关，服务发现是基于领域语义分类的，服务匹配和组合过程都和领域本体、语言学本体相关。从这个角度来看，这里使用基于OWL-S来描述服务组合过程，也体现了一致性[35]。　

为了精确地对Web服务进行语义表述，OWL-S定义了一个丰富的本体库，使用该本体库中知识表述的Web服务可以容易地被计算机理解。OWL-S的本体描述分为服务的轮廓（Profile）、模型（Model）、基点（Grounding）三类，分别表示服务的功能、工作方式和访问方式，其组成结构可由图３－４表示。　

图３－４　OWL-S服务本体结构　

28

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

为了更好的描述服务的组合过程和服务组合的结果，这里把服务分为原子服务和组合服务两种，用OWL-S语言描述如下：　

The most general class of process

由于服务的组合是一个编排服务的过程，复合服务的内部是按给定顺序执行，类似于一般程序过程，因此这里把服务看作一个过程，原子服务对应于原子过程，组合服务对应于组合过程。原子过程是最小且不可细分的过程单元，而组合过程则是由原子过程或其他组合过程通过一系列控制结构连接而成，可用OWL-S语言描述如下：　

根据以上服务过程的定义，在加上OWL-S本体库中诸如顺序（Sequence）、选择（Choice）、循环（Repeat）之类的控制结构，就可以描述复杂的服务组合过程。以下是使用OWL-S描述的图书馆预定图书的服务组合，其中控制结构使其包含的服务按规定的顺序执行，输入输出的数据类型用hasInput和hasOutput属性进行匹配。　

29

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

以上服务组合由三个服务构成，它们按顺序控制结构执行。后面两个输入输出参数描述为同样类型，使得参数类型能够在组合过程中匹配。　

3.3一般开发过程

同传统的基于组件的开发过程一样，基于GS组件开发过程也可分为领域工程和应用工程两部分。实际上，整个开发过程可以简单地描述为获得需要的服务和使用服务构建系统两个过程，这个开发流程可以用图３－５来描述。　

图３－５　基于ＧＳ组件的系统开发过程　

30

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

接下来对一个完整的基于GS服务组件的企业级ＳＯＡ应用系统开发要经历的过程进行详细描述。　

（１）需求分析和领域分析，这个过程将建立形式化的需求和形式化的领域模型。　（２）　服务发现，根据需求分析结果和领域模型对服务语义进行分类筛选并获得一组候选服务。　

（３）服务匹配，对候选服务使用遗传程序进行语义的精确匹配，选出最优服务。　（４）　服务组合，根据语义关联度对后继服务进行排序，选择最优的服务组合方式。　（５）服务组合过程描述，使用OWL-S对服务的组合控制过程进行描述。　（６）服务的装配，在应用系统中使用原始服务或重新发布的服务组合，这个阶段也可以称为系统集成。　

本章重点关注的是服务的发现、匹配和组合过程，尽可能的实现系统的自动化生成，对于OWL-S描述的语义信息在不同服务之间匹配的问题目前还是使用手工的方式，有待进一步研究实现自动化。

3.4本章小结

本章主要讨论了服务组件的组合过程，包括服务的发现、匹配与组合三个部分。首先讨论了服务的发现方法以及将筛选和匹配过程分离的原因。接下来研究了基于遗传程序的服务组件匹配和演化算法，并给出了算法的实现框架。然后对服务组件的动态组合方法进行研究，并给出了组合过程的规范描述。最后给出了基于GS组件的企业级系统开发过程。

对于基于GS组件的企业级系统开发过程，本研究分为6个步骤，前5个步骤已经分别讨论，下一章我们将讨论的是服务的装配过程。

31

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

4面向服务的系统集成

企业系统集成本不属于软件开发阶段的工作，其产生和发展主要是为了解决大量异构的、分散的企业遗留系统之间的交互问题，即信息孤岛问题[36]。而SOA最初也是为了解决企业系统集成问题而产生的，后来由于通过SOA集成的系统具有良好的可复用性和灵活可变性，研究者扩展了SOA的应用范围，使其逐步发展为包含开发模型、运行环境、构架风格和相关方等在内的一整套软件生产方案，覆盖软件开发的所有工作流程[37]。把SOA扩展到整个软件开发过程充分的发挥了SOA在构建分布式系统上的优势，但这并不会改变其本质，基于SOA的开发过程本质上还是一个系统集成的过程。

传统的系统集成方案有很多，比如点对点的集成、基于消息的集成等，这些方案都有紧耦合、协议私有、容易被防火墙拦截等问题[38]，而面向服务集成的产生也正是为了解决这些问题。由于SOA通过标准的、技术中立的方式来定义相关接口和契约，使得所有系统中的服务以共同的和规范的形式进行理解、调用，为分布式系统集成带来了前所未有的交互能力。SOA也是一种基于组件的体系结构，只不过其中的组件功能被封装成服务进行发布，这就涉及到异构组件封装成服务的问题，本章将对把COM组件和EJB组件封装为服务的方法进行讨论，然后对服务总线集成技术进行研究。

4.1相关技术介绍

SOA是一个完整的软件系统构建体系，它以服务的构建和集成为核心，包括建模、开发、装配、运行和管理等范畴。SOA采用业务驱动的系统构建模式，使业务和技术分离，采用松耦合的、灵活的体系结构来满足不断变化的业务需求。随着SOA在企业系统中的广泛使用，其相关的技术也成井喷式发展，形成一个庞大的体系，这里仅对服务集成相关方面进行讨论，主要包括以下几种技术。

JBI（Java Business Integration）是Sun公司提出的一个规范，主要用于对Java组件进行集成，包括标准化消息路由、约束组件和服务引擎三部分。众所周知，目

32

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

前的Java EE容器主要有Servlet容器、EJB容器和JMS容器三类，这些容器都使用特有的传输协议，相互之间无法进行交互，JBI以松散耦合的、插拔可配置的方式将这些不同容器提供的服务集成起来[39]。

SCA（Service Component Architecture）是以IBM和BEA为首的几家公司共同推出的SOA编程模型。SCA组件能够任意使用各种传输协议，可以导入不同类型不同语言实现的组件，为大型分布式系统提供了良好的集成环境。SCA是一种跨协议、跨平台且语言无关的组件模型，在构建服务网络方面具有无可比拟的优势，实现了组件接口和传输协议的松散耦合，提供了基于SOA开发的简化解决方案[40]。

SDO（Service Data Object）是SCA的配套数据规范，它使用全新的数据结构和信息模型，以于数据源和具体实现技术的方式访问数据，实现了数据代码与业务代码的解耦，它统一了异构数据源如XML数据、关系数据库等的访问处理方式[39]。很多公司已在其Java EE平台上支持了SCA/SDO，并提供了C++版本。

BPEL（Business Process Execution Language）是进行服务组合和服务编排的标准技术，是用于自动化任务执行流程的形式化语言。使用BPEL编排的流程以标准化方式在Web服务之间进行交互，这种服务编排是可视化的、可定制的、灵活的和便于管理的[39]。SCA、SDO和BPEL是实现SOA的核心技术，被称为SOA编程模型的铁三角。

4.2服务封装技术研究

随着信息技术的发展，企业在其信息化建设中积累了大量遗留信息系统组件，而互联网上也存在用领域工程的方式创建的为数众多的异构组件，要在面向服务体系结构中使用这些组件的功能就有必要将这些组件封装成服务，本节将对两种常见组件封装成Web服务的技术方法进行讨论。

4.2.1封装COM组件

COM组件是微软公司发布的组件模型，在Windows平台的系统开发中应用广泛。从存储特征上看，COM组件通常表现为以动态链接库（DLL）或可执行文件（EXE）

33

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

形式存在的一段二进制程序代码，每个COM组件通常可包含多个接口，而每个接口则可包含多个实现特定功能的函数声明。COM组件给出的是一个二进制标准，可以使用多种编程语言来实现，微软的很多技术包括ActiveX，DirectX以及OLE都是基于COM建立的[41]。

包装COM组件成为Web服务，实际上可以看作是在运行的COM组件和调用者之间加入一个服务代理层，使得COM组件能够以服务的方式被不同的请求者访问。事实上由于Visual Studio 2005的强大功能，将COM组件封装成Web服务并不需要大家做太多工作，直接在Web服务项目中加入对COM组件的引用即可。

下面是一个用C#开发的加减运算COM组件部分代码：

ｎａｍｅｓｐａｃｅ　ＣａｌｃｕｌａｔｅＮａｍｅｓｐａｃｅ　｛　

　　ｐｕｂｌｉｃ　ｃｌａｓｓ　ＣａｌｃｕｌａｔｅＣｏｍ　　　｛　

　　ｐｕｂｌｉｃ　ＣａｌｃｕｌａｔｅＣｏｍ（）　｛　　　／／构造函数逻辑　　　｝　

　　ｐｕｂｌｉｃ　ｄｏｕｂｌｅ　Ａｄｄ（ｄｏｕｂｌｅ　ｘ，　ｄｏｕｂｌｅ　ｙ）　｛　ｒｅｔｕｒｎ　ｘ　＋　ｙ；　｝　　　ｐｕｂｌｉｃ　ｄｏｕｂｌｅ　Ｓｕｂ（ｄｏｕｂｌｅ　ｘ，　ｄｏｕｂｌｅ　ｙ）　｛　ｒｅｔｕｒｎ　ｘ　－　ｙ；　｝　

｝ 　　｝　

接着在Web服务程序中导入对该COM组件实现的声明，并将该声明引用到组件命名空间，然后在程序中创建组件对象并调用相关方法：

ｕｓｉｎｇ　ＣａｃｕｌａｔｅＮａｍｅｓｐａｃｅ；　ｎａｍｅｓｐａｃｅ　ＣａｌｃｕｌａｔｅＣｏｍ＿Ｓｅｒｖｉｃｅ　｛　　　　　　　　　　　　　　　　　　　

　［ＷｅｂＳｅｒｖｉｃｅ（Ｎａｍｅｓｐａｃｅ＝＂ｈｔｔｐ：／／ｌｏｃａｉｈｏｓｔ／ＷｅｂＳｅｒｖｉｃｅ１＂）］　

　ｐｕｂｌｉｃ　ｃｌａｓｓ　ＣａｌｃｕｌａｔｅＣｏｍ＿Ｓｅｒｖｉｃｅ：Ｓｙｓｔｅｍ．Ｗｅｂ．Ｓｅｒｖｉｃｅｓ．ＷｅｂＳｅｒｖｉｃｅ　　｛　

　ｐｕｂｌｉｃ　ＣａｌｃｕｌａｔｅＣｏｍ＿Ｓｅｒｖｉｃｅ（）　｛　ＩｎｉｔｉａｌｉｚｅＣｏｍｐｏｎｅｎｔ（）；　｝　　＃ｒｅｇｉｏｎ　

　ｐｒｉｖａｔｅ　ＩＣｏｎｔａｉｎｅｒ　ｃｏｍｐｏｎｅｎｔｓ　＝　ｎｕｌｌ；　　ｐｒｉｖａｔｅ　ｖｏｉｄ　ｌｎｉｔｉａｌｉｚｅＣｏｍｐｏｎｅｎｔ（）｛　｝　

　ｐｒｏｔｅｃｔｅｄ　ｏｖｅｒｒｉｄｅ　ｖｏｉｄ　Ｄｉｓｐｏｓｅ（ｂｏｏｌ　ｄｉｓｐｏｓｉｎｇ）　　｛　

34

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

　ｉｆ　（ｄｉｓｐｏｓｉｎｇ　＆＆　ｃｏｍｐｏｎｅｎｔｓ　！＝　ｎｕｌｌ）　　｛　　

ｃｏｍｐｏｎｅｎｔｓ．Ｄｉｓｐｏｓｅ（）；　　｝　

　｝　

　＃ｅｎｄｒｅｇｉｏｎ　

　［ＷｅｂＭｅｔｈｏｄ（Ｄｅｓｃｒｉｐｔｉｏｎ＝＂Ａｄｄ＂）］　　ｐｕｂｌｉｃ　ｄｏｕｂｌｅ　Ａｄｄ（ｄｏｕｂｌｅ　ａ，　ｄｏｕｂｌｅ　ｂ）　　｛　

　ＣａｃｕｌａｔｅＣｏｍ　ｍａｔｈＣＯＭ　＝　ｎｅｗ　ＣａｃｕｌａｔｅＣｏｍ（）；　　ｒｅｔｕｒｎ　ｍａｔｈＣＯＭ．Ａｄｄ（ａ，　ｂ）；　　ｂａｓｅ．Ｄｉｓｐｏｓｅ（ｄｉｓｐｏｓｉｎｇ）；　

　｝　

　［ＷｅｂＭｅｔｈｏｄ（Ｄｅｓｃｒｉｐｔｉｏｎ＝＂Ｓｕｂ＂）］　　ｐｕｂｌｉｃ　ｄｏｕｂｌｅ　Ｓｕｂ（ｄｏｕｂｌｅ　ａ，ｄｏｕｂｌｅ　ｂ）　　｛　

　ＣａｃｕｌａｔｅＣｏｍ　ｍａｔｈＣＯＭ＝ｎｅｗ　ＣａｃｕｌａｔｅＣｏｍ（）；　　ｒｅｔｕｒｎ　ｍａｔｈＣＯＭ．Ｓｕｂ（ａ，ｂ）；　

｝ 　｝　

　｝　

4.2.2封装EJB组件

EJB是Sun公司发布的Java分布式组件模型，是Java EE系列技术平台的核心，主要用于开发和部署服务器端的业务逻辑功能。Java EE被广泛运用于企业级分布式应用系统的构建中，这也使得企业信息系统中存在很多包含EJB或者普通Java Bean的遗留系统。EJB分为实体Bean、会话Bean和消息Bean三类，会话Bean又可分为有状态会话Bean和无状态会话Bean。接下来将对封装无状态会话Bean的方法进行讨论[42]。封装POJO（Plain Old Java Object）的方法和封装EJB大致相同，这里将不再单独对封装POJO进行示范。

封装EJB就是将要封装的Bean定义添加到server-config.wsdd中。首先将无状态会话Bean加入到Service元素下面。其中元素Service的provider属性为“java：EJB”，这里和POJO有点不同，POJO为“java：RPC”，然后进行如下定义。

35

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

其中，参数beanJndiName用于描述EJB描述文件ejb-jar.xml中的元素；参数homeInterfaceName表示远程home接口；remoteInterfaceName表示远程接口。如果传输参数中有自定义的类或者异常类，则需要在Service元素中再定义一个beanMapping元素。下面以SaveProjInfo为例进行说明。

public interface SaveProjInfo extends javax.ejb.EJBObject {

}

public void saveProjInfo(UserAccount userAccount)

throws javax.naming.NamingException,

javax.ejb.FinderException, javax.ejb.CreateException, java.rmi.RemoteException;

在上述无状态会话Bean的接口中，方法saveProjInfo的输入参数是自定义类UserAccount，需要在server-config.wsdd中添加定义，如下所示。

languageSpecificType=\"java:cn.edu.hust.sm.model.UserAccount\"/>

创建完server-config.wsdd，封装工作也就完成了，可以发布了[42]。

4.3服务总线与系统集成

SOA使用服务总线进行服务集成，服务总线通过插拔配置的方式灵活地集成所需服务。基于总线的集成由基于消息的集成方式发展演化而来，且具有更高的可靠性和更好的异步通信能力，实现了服务请求者和服务提供者的解耦合。本节首先对几种常见的企业总线进行对比研究，并介绍了总线对企业系统集成的支持，然后介绍了使用Synapse服务总线进行集成的方法。

36

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

4.3.1企业服务总线

服务总线是SOA的基本功能和关键结构，它提供相应的通信接口来进行应用系统之间的相互调用，并对其中的信息安全进行管理。目前已经投入使用的服务总线很多，按运作方式可分为开源总线和企业总线，按标准可分为Sun的JBI标准和IBM、BEA等的SCA标准，接下来将对几种常用的总线实现进行讨论。

ServiceMix总线是一个完整地实现了JBI规范的开源服务总线。ServiceMix使用事件驱动的方式构建，支持多种服务引擎，如Quartz、Cache、Groovy等，支持多种组件绑定，如Email、RSS、SAAJ等。ServiceMix主要由三部分组成，包括服务引擎组件、绑定组件和JBI容器。

CXF（Celtix and Xfire）是由Celtix和Xfire结合而成的产物，也是一个开源总线。Xfire是一个高性能的Web服务实现，这也使得CXF性能较高。与其他服务总线不同的是，CXF以提供各种服务为目标，它适合于创建各种传输协议的服务。

Synapse服务总线主要用来集成axis2创建的服务，它是一个易用的、轻量级的基于XML和Web服务管理的服务代理。Synapse实质上是一个基于XML的管理和配置环境，它不具有开发模型，只能通过XML的配置对已有的服务进行集成。

Mule是最早的开源服务总线，而且一直有新版本发布，使用者较多。Mule是一种全新设计的总线，它有自己的服务创建方式，不以JBI为开发标准而又支持JBI，它支持多种绑定，有自己的总线集成技术，也可以集成流程管理。总的来说，Mule的构架思想介于SCA构架思想和JBI构架思想之间。

Aqulogic是BEA推出的SOA核心产品，其服务总线是一个配置支持和方案驱动的服务总线。它以服务制导的集成为实现目标，对各种Web服务实行集中管理。其基本原理就是以代理的身份介于服务调用者和提供者之间，由此实现客户端和服务端的解耦。

Websphere服务总线是IBM的一整套SOA解决方案之一，它实现服务的集成。该总线功能强大，能够实现服务之间的消息路由、传输协议的转换、消息格式的转换等功能，这些功能主要通过中介流组件来实现。IBM相应推出的WID（WebSphere Integration Developer）是中介流组件的主要开发工具。

37

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

4.3.2服务总线对企业集成的支持

服务总线技术通过适配和代理等方式实现了服务请求者和服务提供者之间的松散耦合，它使用通用接口代替系统内部接口完成系统之间的各种操作，从而实现了异构平台之间的相互调用。企业信息系统只要封装成Web服务，并在其他系统中选择这些服务，就能通过服务总线集成到其他系统。

服务总线属于分布式体系结构，主要具有消息转换、服务代理和事件驱动等方面的特征。开发人员可以利用这些特征来进行异构平台上的消息传递、服务集成以及事件驱动的通信[43]。而企业信息系统通常是分布式系统，使用服务总线进行系统集成具有先天的适用性。

服务总线是SOA的核心和支撑技术，用服务总线集成企业系统，可以通过相应的管理方案和服务层次，使得集成的系统与企业任务相互对应。服务总线在消息传递、服务调用、质量控制、系统集成、系统安全以及监控管理等方面都具有优越的表现，因此成为企业系统集成的最佳选择。

4.3.3使用Synapse集成服务

Synapse是一个轻量级的服务集成总线，具有服务代理、服务路由、修改消息和集成外部服务等功能。Synapse不具有服务创建和发布功能，只能集成其他服务容器创建的服务。

这里以奖学金管理系统集成为例对Synapse集成axis2创建的服务进行介绍。学校奖学金种类通常有很多，比如学业奖学金、才艺奖学金、单项奖学金等。用ApplicationAgency代表奖学金申请代理服务，SchoService表示各种奖学金服务，通过axis2创建这5个不同的外部服务如下：

http://localhost:8888/axis2/services/ApplicationAgency http://localhost:8888/axis2/services/SchoService0 http://localhost:8888/axis2/services/SchoService1 http://localhost:8888/axis2/services/SchoService2 http://localhost:8888/axis2/services/SchoService3

38

华　　中　　科　　技　　大　　学　　硕　　士　　学　　位　　论　　文　

图4-1显示了Synapse进行奖学金管理系统集成的结构图。

图4-1 Synapse进行服务集成的结构

首先，要求为每个URL来创建一个不同的路由，比如在客户端使用的访问路径“/axis2/services/ApplicationAgency”和“/axis2/services/SchoService0”之间还是有很大差别的，所以先使用URL进行初步选择，把选择到的“ApplicationAgency”和以SchoService为前缀的所有服务进行区分。这里研究人员采用Synapse为此提供的source=”get-property(‘To’)”的命令，取出所要调用的外部服务提供者的URL内容，如果提供者的URL形式类似于regex=”.*/ApplicationAgency.*”，则把服务请求转发给“/axis2/services/ApplicationAgency”；如果其URL形式与上述形式不合，那必定是调用奖学金服务，那么再根据消息内容，也就是消息内容中的奖学金类型编号，调用与之相对应的奖学金服务，取出奖学金类型编号采用source=”//m0:getQuote/arg0”，如果符合，那么调用Scho0的服务，依次类推，其配置文件如下。