（计算机软件与理论专业论文）支持业务模板的集成化web+services组合研究.pdf

支持业务模板的集成化w e bs e r v i c e s 组合研究 摘要 l t 技术在当今企业内的作用变得越来越明显，已经从过去的电子化办公工 具发展成为企业流程变革与创新的重要支撑力量。业务流程与i t 技术的融合是 未来的发展趋势，而基于w e bs e r v i c e s 的粗粒度服务组合技术是实现这种融合 的有效途径，因为它为传统的软件开发提供了一种全新的体系结构：通过对一些 预定义的w e bs e r v i c e s 进行组合，可以快速地为不断变化的业务需求提供合适 的应用系统。论文提出了支持业务模板的集成化w e bs e r v i c e s 组合方法，以业 务环境建模为起点，以业务流程建模为核心，用自动化工具进行两个模型之问的 映射，并能把图形化描述的业务流程模型编译成实现w e bs e r v i c e s 组合的b p e l ( b u s i n e s sp r o c e s se x e c u t i o nl a n g u a g e ) 代码，从而实现从业务流程到应用系 统的集成化开发过程。这种方法采用模型间的智能转换技术，把业务人员对系统 的需求建模和技术人员对系统的设计实现集成在一起，可以尽量减少由于业务人 员和技术人员之间的知识结构差异而导致的业务需求与系统实现之间的偏差；通 过业务模板中定义的规则，自动从流程模型中抽取服务的流程上下文信息，并根 据流程上下文信息从u d d i 服务器中查找所需的服务，提高了服务查找的准确 性，从而提高了构建新系统的效率。论文最后以一个供应链的例子介绍了这种方 法的使用。 关键词：w e bs e r v i c e s 组合，业务流程建模，面向服务的架构，业务流程执 行语言，服务匹配 中图分类号：t p 3 1 1 5 g l 支持业务模板的集成化w e bs e f v i c e s 组台研究 a b s t r a c t a b s t r a c t t h et e c h n o l o g yo fw e bs e r v i c e sc o m p o s i t i o nw i l lh e l pt h ei n t e g r a t i o no f b u s i n e s so p e r a t i o na n dt h eu n d e d y i n gi ts y s t e m ，t h u sf a c i l i t a t eb u s i n e s s p m c e s so p t i m i z a t i o na n di n n o v a t i o ni ne n t e r p r i s e s w e bs e r v i c e sc o m p o s i t i o n g i v e san e wb l u e p r i n tf o rs o f t w a r ed e v e l o p m e n t ：n e ws y s t e m sc a nb eb u i l tb y c o m b i n i n ge x i s t i n gw e bs e r v i c e s t h i sp a p e rp r o p o s e dan e wa p p r o a c hf o r i n t e g r a t e dw e bs e r v i c e sc o m p o s i t i o n i nt h i sa p p r o a c h ，c o n s t r u c t i n gan e w s y s t e mi n v o k e st h r e ep h a s e s ：b u s i n e s se n v i r o n m e n tm o d e l i n g ，b u s i n e s s p r o c e s sm o d e l i n g ，a n df i n a l l yc o m p i l i n gt h eg r a p h i c a lp r o c e s sm o d e li n t ob p e l s c d p f f it h a tc a nb ed e p l o y e do nab p e l r u n t i m ee n g i n e 1 1 1 i sa p p r o a c hh a s t w o a d v a n t a g e s ：1 ) b yi n t e g r a t i n gt o g e t h e rt h ew o r k so fb u s i n e s sr e q u i r e m e n t a n a l y s i sa n ds y s t e mi m p l e m e n t a t i o n ，t h i sa p p r o a c hm a yh e l pb n d g et h e k n o w l e d g eg a pb e t w e e nb u s i n e s se x p e r t sa n di tp r o f e s s i o n a l s ；2 1u s i n gt h e r u l e sa n do t h e ri n f o r m a t i o ni nab u s i n e s st e m p l a t e ，p r o c e s sc o n t e x tc a nb e e x t r a c t e df r o map r o c e s sm o d e la n du t i l i z e di n s e a r c h i n gq u a l i f i e dw e b s e r v i c e s ，w h i c hi sm o r ee f f i c i e n tt h a nt h et r a d i t i o n a lk e y w o r d s - b a s e dw e b s e r v i c e sd i s c o v e r y a tt h ee n do ft h i sp a p e r it h e r ei sad e m o n s t r a t i o ns h o w i n g h o wt od e v e l o pas u p p l y - c h a i n m a n a g e m e n ts y s t e mu s i n gt h i sa p p r o a c h k e yw o r d s ：w e bs e r v i c e sc o m p o s i t i o n ，b u s i n e s sp r o c e s sm o d e l i n g ， s e r v i c e o r i e n t e da r c h i t e c t u r e ，b u s i n e s sp r o c e s se x e c u t i o nl a n g u a g e ，w e b s e r v i c em a t c h i n g w 论文独创性声明 本论文是我个人在导师指导下进行的研究工作及取得的研究成果。论文中除了特 别加以标注和致谢的地方外，不包含其他人或其它机构已经发表或撰写过的研究成 果。其他同志对本研究的启发和所做的贡献均已在论文中作了明确的声明并表示了谢 意。 作者签名：丝茎壅臼期：垒幽 论文使用授权声明 本人完全了解复旦大学有关保留、使用学位论文的规定，即：学校有权保留送交 论文的复印件。允许论文被查阅和借阅：学校可以公布论文的全部或部分内容，可以 采用影印、缩印或其它复制手段保存论文。保密的论文在解密后遵守此规定。 作者签名： ! 垒重垒导师签名： 支持业务模板的集成化w e bs e r v i c e s 组合研究 第一章绪论 1 1 研究背景 第一章绪论 目前，全球企业正向着电子商务的运营模式转变，企业内部与外部的连接逐 渐紧密，甚至融为一体，这种变化也深刻影响着企业的信息系统。在i b m 与清 华大学合作进行的一次中国c e o 调研中发现，大部分企业已经认识到业务与技 术的融合至关重要威功的创新企业能够让技术战略有效地支持业务目标，他们 不再只是简单地把技术视作企业业务战略的助推器，而是帮助企业改变战略环境 取得竞争优势的核心要素r q o 企业期望通过增加在i t 方面的投资来提高企业的工作效率和响应速度，以 此创造更多的商机。但是，由于传统的信息系统往往是为不同的单位或部门独立 设计的，由此形成的一个个信息孤岛并不能在应用系统之间共享业务处理流程和 信息、不能有效地协同工作、不能对外部世界的快捷变化做出快速的反应。因此， 这就要求企业尽可能地对这些应用系统进行集成，将业务流程、应用软件、硬件 和各种标准联合起来，在多个企业应用系统之间实现无缝连接，使它们像一个整 体一样进行业务处理和信息共享。 图卜1 互相协作的企业信息系统 图1 - 1 展示了一个抽象的供应链中的各个角色。一般来说，一个供应链涉及 到外部的客户、供货商、第三方物流、银行等合作企业，以及内部的生产、质检 第1 页，共6 5 页 支持业务模板的集成化w e bs c r v c c s 组合研究第一章绪论 等部门，可以把所有这些涉及到的合作企业和内部部门看成一个虚拟的企业联 盟。这个企业联盟接受客户的订单，然后从供货商处订购零配件，经过生产和质 检等环节，把最终产品运输给客户，并通过银行完成所有的付款活动。 图1 1 正中的浅色椭圆表示整个企业联盟的业务流程，而周围的五个深色椭 圆分别表示各个合作企业和内部部门的业务流程。每个合作企业和内部部门都有 自己的信息系统来支持各自的业务流程，而这些信息系统又要互相合作，以支持 整个企业联盟的业务流程。 那么我们要解决的问题则是：如何把各个合作企业和内部部门的信息系统集 成在一起，来支持整个企业联盟的业务流程。其实这就是一个企业信息系统集成 的问题。 以c o r b a 和r m i 为代表的传统的企业信息系统集成技术，实现了以数据 为中心的集成；而要实现真正的企业级的集成，必须实现以流程为中心的集成圈。 w e bs e r v i c e s 技术为这种以流程为中心的企业信息系统集成提供了极大的 便利。各个企业的信息系统都以w e bs e r v i c e s 的形式对外提供服务，那么从外 部来看，每个w e bs e r v i c e 都是一个黑盒子，可以独立完成自己的功能，而各 个w e bs e r v i c e s 之间又可以由于其平台无关性而方便地集成在一起。 w e bs e r v i c e s 的组合就是把互相独立的w e bs e r v i c e s 集成在一起，形成一 个具有特定内部逻辑的新的w e bs e r v i c e 。从企业联盟的角度看，通过w e b s e r v i c e s 组合可以把企业联盟内各个企业的内部流程方便地整合成一个新的组 合流程，而这个新流程的出发点是整个企业联盟的业务需求。从技术层面来看， w e bs e r v i c e s 组合技术解决了传统的企业应用集成技术中的标准不统一的问 题，是一种建立在几乎所有厂商和产品都支持的国际化标准之上的解决方案；而 从业务层面来看，通过w e bs e r v i c e s 组合技术，可便于将技术与业务进行衔接， 快速地根据业务变化情况来构造相应的信息系统。 1 2 国内外研究现状 在传统的信息系统开发领域，较为常用的方法是面向对象的开发和基于组件 的开发【l 。随着面向服务思想 s l 的出现，用服务组合的方法来构建系统成为了目 前的研究热点。而w e bs e r v i c e s 技术是目前把一个信息系统封装成服务的主要 方法，基于w e bs e r v i c e s 的服务组合的方法( 简称为w e bs e r v i c e s 组合) 可 以降低系统开发的难度和复杂度，提高系统对复杂多变的业务需求的适应能力。 技术人员可以通过对已有w e bs e r v i c e s 的组合，设计并实现一套完整的解决方 第2 页，共6 5 页 支持业务模板的集成化w e bs e r v i c e s 组合研究第章绪论 案来适应复杂多变的业务需求。由于这些w e bs e r v i c e s 遵循了标准的协议，如 s o a p ( s i m p l eo b j e c ta c c e s sp r o t o c 0 1 ) 明，w s d l ( w e bs e r v i c e sd e s c r i p t i o n l a n g u a g e ) 【7 】，u d d i ( u n i v e r s a ld e s c d p t i o n ，d i s c o v e r y , i n t e g r a t i o n ) 8 等，这极大 地简化了系统集成的复杂性。 w e bs e r v i c e s 组合为企业信息系统集成提供了一个新的方向。在这个领域 中，需要解决的问题包括：组合流程的描述语言及其运行环境、组合流程的建模 方法及相关工具、w e bs e r v i c e s 的自动查找与匹配、运行时的管理( 监控、事 务处理、异常处理) 等。其中，在描述语言及其运行环境方面，已经有了国际标 准和较为成熟的商业化产品的支持，而其它方面则还有待完善，是目前的研究热 点。本文的研究内容则集中在组合流程的建模方法和相关工具，以及w e b s e r v i c e s 的自动查找与匹配方面。 在w e bs e r v i c e s 组合中，一般可以通过某种脚本语言来描述最终的组合流 程，并在支持该脚本语言的引擎上部署和运行系统。这种脚本语言被称为服务组 合语言，比较成熟的服务组合语言主要有b p e l ( b u s i n e s sp r o c e s se x e c u t i o n l a n g u a g ef o rw e bs e r v i c e s ) 凹和w s c d l ( w e bs e r v i c e sc h o r e o g r a p h y d e s c r i p t i o nl a n g u a g e ) ”q ，其中b p e l 得到了i b m 、o r a c l e 等企业的广泛支持。 b p e l 建立的流程模型具有一个业务核心实体，该实体通过调用其它系统的 服务接口来实现业务流程。但这与企业整体系统的实现还有一定的差距，因为一 个企业整体系统可能会分成不同的模块，各个模块之间相互独立，具有各自的执 行流程。这些相对独立的模块有可能存在于供应链系统中的其它企业，也有可能 存在于一个企业中的不同部门，因此有必要为这些互相协作而又相对独立的模块 提供一个整体视图。我们在b p e l 的基础上进行了深入的研究，提出了一种支持 业务模板的w e bs e r v i c e s 组合，为整个系统提供了一个业务环境模型，并通过 智能转换技术来帮助业务核心实体创建业务流程模型。 在服务组合建模方面主要有两种方法，一种是服务间自组织方式，即通过本 体( o n t o l o g y ) 等技术来描述服务的语义和服务质量等信息，使得计算机可以根 据一定的方式进行自动推理，从而实现服务组合1 1 1 03 】；另一种是模型驱动方式， 结合模型驱动的架构( m o d e ld r i v e na r c h i t e c t u r e ， m d a ) i 14 j 的思想，设计较 易理解的模型并生成相应的脚本，从而实现服务组合，o r a c l eb p e lp r o c e s s m a n a g e 一1 司中的建模方式就属于这一种。有一些研究结合了上面两种做法1 1 日， 另一些研究则提出了面向业务人员的服务组合思想【1 7 。与它们不同的是，我们 为业务人员与技术人员分别提供了业务视图和i t 视图，较好地分离了不同参与 人员的关注点，并利用模型转换规则，有效地提高了业务流程建模的效率。 第3 页，共6 5 页 支持业务模板的集成化w e bs e r v i c e s 组合研究第一章绪论 在服务查找和匹配领域，学术界提出的主要方法是基于语义的服务查找。文 献【19 】提出了基于服务语义和服务质量的服务匹配，文献【2 0 】提出了基于服务语义 和用户偏好的服务匹配，文献【2 1 j 提出了基于服务语义和关系模型的服务匹配， 文献1 2 2 提出了根据语义相似度来查找服务并对服务进行排序的思想。这些研究 的基本思想都是对服务的输入输出参数进行语义相似度匹配，即从技术层面出 发，为服务的每一个输入参数和输出结果添加语义信息，在查找服务时，由用户 提供两种语义信息，一种是期望的输入参数的语义信息，另一种是期望的输出结 果的语义信息。服务查找程序根据每个服务的实际输入参数与期望输入参数的语 义匹配度，以及实际输出结果与期望输出结果的意义匹配度，来确定每个服务的 语义相似度，并最终返回给用户若干个语义相似度最高的服务。而我们提出的基 于流程上下文信息的服务查找，则在上述研究的基础上，不光利用了技术层面的 语义信息，还利用了业务层面的语义信息来帮助查找，可以迸一步提高查找的准 确性。 1 3 研究内容和意义 在实际应用中，w e bs e r v i c e s 组合所面临的困难主要有以下几点： 业务需求的复杂多变：在一个企业中，进行信息化系统建设时，业务需求是 最难理解和表达的，往往需要构建同样复杂的信息系统来满足这些复杂的业务需 求。同时，由于业务会随着市场而变化，业务需求也会发生相应的变化，这要求 现有系统也必须能够灵活地适应这种变化。 技术人员对领域知识的不了解导致业务需求无法被合适地表达：技术人员在 开发企业信息系统时，需要花费大量的时间和精力去理解业务需求，但往往无法 完全理解并应用i t 技术进行解决。 缺乏一个合适的集成开发环境：尽管已存在一些基于b p e l 的开发工具，但 目前还没有能够在s q a 环境下把业务需求分析和信息系统构建紧密结合起来的 可视化集成开发环境。而这样的开发环境对于提高开发效率是十分重要的。 为此，我们提出了一种支持业务模板的w e bs e r v i c e s 组合方法，并提供了 这种方法所需的相关工具。这是一种自上而下的信息系统构建方法，为整个开发 过程提供了下面三种视图： 业务视图一一主要负责业务环境模型的建立，并可通过领域相关的业务模板 来降低建模的复杂度。该视图由熟悉业务的人员操作。 l t 视图一一它收到由业务环境模型经过智能转换而得到的业务流程模型的 第4 页，共6 5 页 支持业务模板的集成化w e bs e r v i c e s 组合研究第一章绪论 框架，并由技术人员将此框架细化成为一个具体的业务流程模型。该视图由熟悉 设计与实现的技术人员操作。 脚本视图一- - i t 视图中的业务流程模型可以被自动转换成b p e l 脚本和相 应的w s d l 接口描述文件。最终设计完成的b p e l 脚本可以被部署到b p e l 引 擎中，实现系统的部署和运行。 此外，我们对传统的u d d i 服务器进行了扩充，可以根据自定义的流程上下 文信息来查找所需的w e bs e r v i c e s ，并按用户指定的标准对这些满足条件的 w e bs e r v i c e s 进行排序，可以帮助用户在进行业务流程建模时快速找到所需的 w e bs e r v i c e s 。 现有的基于语义的服务查找与匹配，都是单纯从技术层面去考虑语义匹配 度，我们认为这是不够的。因为这要求在查找一个服务时，必须准备好全部的可 用参数，但有时候恰恰是根据找到的服务再去想办法获得所需的参数。而我们提 出的基于流程上下文信息的服务查找与排序方法，除了技术层面的参数语义外， 还从业务层面考虑，为每个服务添加领域特定的信息，例如某个服务在某个业务 领域中的角色等。但由于对服务的语义描述方法不是我们的研究重点，为了降低 复杂度，我们没有采用其它研究中常见的复杂的o w l - s 语言来为服务添加语义， 而只是采用了简单的带有命名空间的字符串来描述。比如，用 “i n f o r m a t i o n s e r v i c e ：s t o c k q u o t e ”来表示信息服务这一业务领域中的股票实 时信息提供者这一角色。 相对于技术层面的语义信息来说，业务层面的语义信息更加固定，也更加容 易获得。比如，我们可以很容易地确定要查找某个可以提供股票行情的服务，但 不容易确定我们可以提供给该服务的可用信息有哪些。 我们的研究可以为业务专家和技术专家提供一致的工作环境，业务专家和技 术专家可以分别在自己熟悉的领域内进行建模，我们提供的自动模型转换功能有 助于减少两类人员对业务需求理解上的差异，而基于流程上下文的服务查找则有 助于技术专家快速找到所需的服务，提高构建信息系统的效率，进而提高信息系 统构建对业务需求变化的反应速度。 在i b m 公司的资助下，我们基于开源平台e c l i d s e 嘲设计开发了一个集成化 开发环境s b m w ( s e r v i c e - o r i e n t e db u s i n e s sm o d e l i n gw o r k s h o p ) ，可以支持业 务环境建模、业务流程建模、模型编译的整个过程。同时，我们以开源的i u d d l l 2 4 1 和u d d l 4 j 硼为基础，对它们进行了扩充，在u d d i 服务器和客户端a p i 两个方 面都能够支持基于流程上下文的服务查找。 第5 页，共6 5 页 支持业务模板的集成化w e bs e r v i c e s 组合研究第一章绪论 1 4 论文的组织结构 论文余下的部分组织如下： 第二章介绍了w e bs e r v i c e 、面向服务的架构、w e bs e r v i c e s 组合、业务 流程执行语言等基础理论知识，以及为了实现论文提出的理论而进行的开发工作 中使用到的j u d d i 、u d d l 4 j 、e c l i p s e 插件机制等工具和技术。 第三章介绍了支持业务模板的集成化w e bs e r v i c e s 组合的理论，给出了相 关的概念，定义了相关的模型，并介绍了实现过程中的关键技术。 第四章简要介绍了用于实现我们提出的这种理论的集成化开发平台 s b m w ( s e r v i c e o r i e n t e db u s i n e s sm o d e l i n gw o r k s h o p ) ，并用一个简化的供应 链案例介绍了如何在s b m w 的帮助下使用本文提出的方法。 第五章总结全文，并展望了进一步的工作。 第6 页，共6 5 页 支持业务模板的集成化w e bs e r v i c e s 组合研究 第二章相关知识与技术 第二章相关知识与技术 2 1w e bs e r v i c e s w e bs e r v i c e s 是基于网络的、分布式的模块化组件，它执行特定的任务， 遵守具体的技术规范，这些规范使得w e bs e r v i c e s 能与其他兼容的组件进行互 操作p 司。w e bs e r v i c e s 试图解决的主要问题是数据和应用程序集成的问题，是 将技术性的功能转换成面向业务的计算任务的问题。 w e bs e r v i c e s 通过一系列标准和协议来保证程序之间的动态连接。其中最 基本的协议包括：s o a p 嘲。w s d 一。u d d i f s i 。 s o a p 简单对象访问协议( s i m p l eo b j e c ta c c e s sp r o t o c o l ，s o a p ) 是一个基于 x m l 的、用于在分布式环境下交换信息的轻量级协议。s o a p 在服务请求者和 服务提供者对象之间定义了一个通信协议，这样，在面向对象编程环境中，该请 求对象可以在提供的对象上执行远程方法调用。s o a p 的优点在于它完全和厂商 无关，相对于平台、操作系统、目标模型和编程语言可以独立实现。 w s d l w e bs e r v i c e s 描述语言( w e bs e r v i c e sd e s c r i p t i o nl a n g u a g e 。w s d l ) 用 来描述服务的接口，在服务请求者和服务提供者之间定义了一种契约。w s d l 将服务的接口与实现隔离开来，服务请求者只需要关心w s d l 文档中描述的消 息格式等信息，而不用去关心服务提供者的内部实现细节。例如，根据一个w e b s e r v i c e 对应的w s d l 文档产生一个j a v a 的代理对象，它能够像本地对象一样 实现服务，但是实际上代理对象仅仅处理请求的创建和响应消息的解析。不管 w e bs e r v i c e 是否用j a v a 、c 撑或者其他的语言实现，生成的j a v a 代理对象都 能够从w s d l 描述中调用任何的w 曲s e r v i c e 。 u d d i 统一描述、发现和集成( u n n e m a ld e s c r i p t i o n ，d i s c o v e r ya n di n t e g r a t i o n 。 u d d i ) 规范是一个在需要发现服务的请求者和发布服务的提供者之间的中介， 提供了一组公用的a p i ，使得服务代理得以实现。u d d i 为发布服务和发现所需 服务定义了基于s o a p 消息的标准接口，将发布和发现服务的s o a p 请求解释 为用于基本数据存储的数据管理功能调用。 第7 页，共6 5 页 支持业务模板的集成化w e bs e r v i c e s 组合研究第二章相关知识与技术 w e bs e r v i c e s 体系结构基于三种角色( 服务提供者、服务注册中心和服务 请求者) 之间的交互嗍。交互涉及发布、查找和绑定操作。服务提供者定义w e b s e r v i c e 的服务描述并把它发布到服务注册中心。服务请求者使用查找操作来从 服务注册中心检索服务描述，然后使用服务描述与服务提供者进行绑定。图2 1 显示了这些操作、提供这些操作的组件及它们之间的交互。 图2 - 1w e bs e r v i c e 体系结构中的角色与交互 服务提供者( s e r v i c ep r o v i d e r ) ：从企业的角度看，这是服务的所有者。从体 系结构的角度看，这是托管访问服务的平台。 服务请求者( s e r v i c er e q u e s t o r ) ：从企业的角度看，这是要求满足特定功能 的企业用户。从体系结构的角度看，这是寻找并调用服务，或启动与服务的交互 的应用程序。服务请求者角色可以由浏览器来担当，由人或无用户界面的程序( 例 如，另外一个w e b 服务) 来控制它。 服务注册中一e , , ( s e r v i c er e g i s t r y ) ：这是可搜索的服务描述注册中心，服务提 供者在此发布他们的服务描述。在静态绑定开发期间或动态绑定执行期间，服务 请求者查找服务并获得服务的绑定信息( 在服务描述中) 。对于静态绑定的服务请 求者，服务注册中心是体系结构中的可选角色，因为服务提供者可以把描述直接 发送给服务请求者。同样，服务请求者可以从服务注册中心以外的其它来源得到 服务描述。 从技术层面来看，w e bs e r v i c e s 可以更方便地处理数据，并且允许软件更 自由地进行通信。在w e bs e r v i c e s 技术出现之前，要实现跨多个操作系统、编 程语言和硬件平台集成软件应用程序，一直是一个非常困难的紧耦合问题。而 w e bs e r v i c e s 使用基于x m l 语言的协议来描述要执行的操作以及要与其它 第8 页，共6 5 页 支持业务模板的集成化w e bs e w i c c s 组合研究第二章相关知识与技术 w e bs e r v i c e s 进行交换的数据，可以用真正与平台无关的方式来描述任何数据， 以实现异构系统间的数据交换，因此实现了松耦合的应用程序。 从业务层面来看，可以将w e b 服务视为一些工作单元，每个单元处理特定 的功能任务。再往上一步，可以将这些任务组合成面向业务的任务，以处理特定 的业务操作。因此，一旦由技术人员设计并构建好w e bs e r v i c e s 之后，业务流 程设计师就可以通过使用这些w e bs e r v i c e s 来解决业务层面上的问题。w e b s e r v i c e s 有助于在组织内的业务人员和技术人员之间架起一座桥梁，使技术人员 更容易将业务人员描述的业务活动与相应的技术实现相关联。 由于是基于x m l 的应用，w e bs e r v i c e s 在拥有x m l 带来的一切优势的同 时，也不可避免地继承了x m l 所带来的一些限制。与传统的基于普通文本或二 进制数据的传输相比，在传输、解析x m l 数据时，会消耗大量的c p u 资源、 内存资源和网络资源。 而w e bs e r v i c e s 本身也具有一些缺点阁。在目前的标准下，w e bs e r v i c e s 还只是一种无状态的服务，无法保存客户端服务调用者的任何信息。这是由w e b s e r v i c e s 的本质所决定的。w e bs e r v i c e s 在本质上是要为应用程序之间提供数 据通讯的标准，为企业应用之间动态地提供粗粒度的服务，所以w e bs e r v i c e s 并不适合于非常精细的基于会话的方法调用以及复杂的事务处理。 企业应用集成是目前w e bs e r v i c e s 应用最看好的方向之一阁。大多数企业 内部都有着各种各样的应用系统，运行在不同的平台上，各个系统的开发语言也 各不相同。由于现代企业信息自动化要求的提高，各个系统之间的互动和相互通 讯也就随之变得异常重要。因此，保护原有投资、重用遗留系统是当前很多中大 型企业的重要任务。由于遗留系统的运行平台是异构环境，因此企业应用集成的 代价一般来说是很高的。但如果使用w e bs e r v i c e s 作为应用集成的手段，将会 大大降低集成的成本。w e bs e r v i c e s 与平台和语言无关的特性，以及各种平台 和环境下的开发工具都是企业应用集成的利器。另外，在开发新的应用系统时， 仍然需要考虑和其他系统的集成，需要考虑调用其他系统的功能，和被其他系统 所调用。使用w e bs e r v i c e s 作为系统与外部交流的接口，能够使新的系统和别 的系统之间保持松耦合的关系，保持较高的可扩展性。 2 2s o a 面向服务的体系结构( s e r v i c e o r i e n t e da r c h i t e c t u r e ，s o a ) 并不是一个新 概念，有人就将c o r b a 和d c o m 等组件模型看成s o a 架构的前身。早在1 9 9 6 第9 页，共6 5 页 支持业务模板的集成化w e b $ c r v i s 组合研究第二章相关知识与技术 年，g a r t n e rg r o u p 就已经提出了s o a 的预言，不过那个时候仅仅是一个。预言 。，当时的软件发展水平和信息化程度还不足以支撑这样的概念走进实质性应用 阶段期。 关于s o a ，且前尚未有一个统一的、业界广泛接受的定义。一般认为，s o a 是一个组件模型，它将应用程序的不同功能单元( 称为服务) 通过这些服务之间 定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独 立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统 中的服务可以以一种统一和通用的方式进行交互m 。 s o a 不是一种语言，也不是一种具体的技术，更不是一种产品，而是一种 软件系统架构，它尝试给出在特定环境下推荐采用的一种架构，从这个角度来说， 它其实更像一种架构模式( p a t t e r n ) ，是一种理念架构，是人们面向应用服务的解 决方案框架。s o a 是以服务为中心的，具有下面一些重要特征鲫： 服务的封装性( e n c a p s u l a t i o n ) 。将服务封装成用于业务流程的可重用 组件的应用程序。它提供信息或简化业务数据从一个有效的、一致的状 态向另一个状态的转变。服务的a p i 保持不变，使得用户远离具体实现 上的变更。 服务的可重用性( r e u s a b i l i t y ) 。服务的可重用性设计显著地降低了成本。 为了实现可重用性，服务在运行时只与特定处理过程的上下文相关，而 独立于底层实现和客户需求的变更。 服务的互操作性( i n t e r o p e r a b i l i t y ) 。互操作并不是一个新概念。在 c o r 队、d c o m 、w e bs e r v i c e 中就已经采用互操作技术了。在s o a 中，通过服务之间既定的通信协议进行互操作，主要有同步和异步两种 通信机制。s o a 提供服务的互操作特性更利于其在多个场合被重用。 服务是自治的( a u t o n o m o u s ) 功能实体。服务是由组件组成的组合模块， 是自包含和模块化的。s o a 非常强调架构中提供服务的功能实体的完全 独立自主的能力。传统的组件技术，如n 盯r e m o t i n g 、e j b 、c o m 或者c o r b a ，都需要有一个宿主( h o s t 或者s e r v e r ) 来存放和管理这些 功能实体；当这些宿主运行结束时这些组件的生命期也随之结束。这样 当宿主本身或者其它功能部分出现问题的时候，在该宿主上运行应用服 务就会受到影响。s o a 架构中非常强调实体自我管理和恢复能力。常见 的用来进行自我恢复的技术，比如事务处( t r a n s a c t i o n ) ，消息队列 ( m e s s a g eq u e u e ) ，冗余部署( r e d u n d a n td e p l o y m e n t ) 和集群系统 第1 0 页，共6 5 页 支持业务模板的集成化w e bs e r v i c e s 组合研究第二章相关知识与技术 ( c l u s t e r ) 在s o a 中都起到至关重要的作用。 服务之间的松耦合度( 1 0 0 s e l y c o u p l e d ) 。服务请求者到服务提供者的绑 定与服务之间应该是松耦合的。这就意味着，服务请求者不知道提供者 实现的技术细节，比如程序设计语言、部署平台等等。这个松耦合使会 话一端的软件可以在不影响另一端的情况下发生改变，前提是消息模式 保持不变。 服务是位置透明的( 1 0 c a t i o nt r a n s p a r e n c y ) 。服务是针对业务需求设计 的，需要反应需求的变化。要想真正实现业务与服务的分离，就必须使 得服务的设计和部署对用户来说是完全透明的。也就是说，用户完全不 必知道响应自己需求的服务的位置，甚至不必知道具体是哪个服务参与 了响应。 从技术角度而言，s o a 带来了“松散耦合”的应用程序组件。正是得益于 这个松散耦合特性，才使得能够将服务组合为各种应用程序。这样还大幅度提高 了代码重用率，可以在增加功能的同时减少工作量。所有交互都是基于“服务契 约”进行的，服务和访问服务的客户并未彼此绑定。 从业务的角度来说，面向服务的架构的重点在于开发能帮助企业完成业务任 务的技术，而不是通过技术约束来规定企业的行动。例如，销售过程( 制造、运 输和收到货款) 可能会涉及数十个步骤和若干不同的数据库和计算机系统。但就 其实质而言，此过程包含一系列业务活动，面向服务的架构基于这些实际的业务 活动来进行组织。 尽管实现s o a 可以采用各种不同的技术，比如分布式对象( c o r b a ，j 2 e e ， c o m d c o m ) 、面向消息的中间件等，但w e bs e r v i c e s 是目前实现s o a 最好 的方式。基于w e bs e r v i c e s 技术的s o a 具有以下优势鲫： w e bs e r v i c e s 是被广泛接受的国际标准，这意味着企业不必受制于个别 厂商的专有解决方案。 w e bs e r v i c e s 在各种软硬件平台上都得到了很好的支持，因此可以实现 各种解决方案间的互操作，使企业可以使用不同厂商的、具有单项优势 的产品。 w e bs e r v i c e s 具有不同的粒度，小到一个简单的公式计算，大到一个完 整的业务操作，都可以封装成w e bs e r v i c e s ，因此既可以支持企业内的 集成，也可以支持企业间的集成。 第1 1 页，共6 5 页 支持业务模板的集成化w e bs e r v i c e s 组合研究 第二章相关知识与技术 2 3w e bs e r v i c e s 组合与b p e l w e bs e r v i c o s 实现了粗粒度的可重用的计算资源，而w e bs e r v i c e s 组合要 解决的问题则是，如何按照一定的逻辑结构将已有的w e bs e r v i c e s 组合成一个 新的流程，以实现单个w e bs e r v i c e 无法实现的新的功能。 w e bs e r v i c e s 组合的最大作用在于，使得技术人员可以最大限度地重用已 有的计算资源，加快新系统的开发，提供对业务的支持，加快了技术对业务变化 的反应速度。如果说结构化编程技术实现了函数层次的重用，面向对象技术实现 了对象层次的重用，那么w e bs e r v i c e s 组合技术则实现了更高层次的业务操作 的重用，包括企业内部的业务操作的重用和企业间的业务操作的重用。旅行社案 例是一个经常在各种文献中被引用的例子：航空公司提供了预订机票的w e b s e i c e ，宾馆提供了预订房间的w e bs e r v i c e ，银行提供了信用卡验证的w e b s e r v i c e ；而旅行社通过w e bs e r v i c e s 组合技术，可以将这些w e bs e r v i c e s 组 合在一起，为旅行者提供更高层次的一体化解决方案，利用航空公司、宾馆、银 行提供的标准的服务接口，自动完成机票预订、宾馆房间预订、信用卡验证等一 系列步骤，同时还可以为旅行者提供额外的增值服务，例如自动选择价格最低的 宾馆。 目前，实现w e bs e r v i c e s 组合的主要方法有两种：以b p e l ( b u s i n e s s p r o c e s se x e c u t i o nl a n g u a g e ) 为代表的0 r c h e s t r a t i o n 方法，和以w s - c d l ( w e b s e r v i c e sc h o r e o g r a p h yd e s c n p t i o nl a n g u a g e ) 为代表的c h o r e o g r a p h y 方法。 这两种方法的主要区别是：0 r c h e s t r a t i o n 方法假定在流程执行的整个范围内存 在某个中心控制点，而c h o r e o g r a p b y 方法则假定合作者们共同参与流程的控制。 b p e l 是一门用于自动化业务流程的形式规约语言。按照b p e l 标准用 x m l 文档描述的流程能在w e b 服务之间以标准化的交互方式得到精心组织。这 些流程能够在任何一个符合b p e l 规范的平台或产品上执行。所以，通过允许 用户在各种各样的创作工具和执行平台之间移动这些流程，b p e l 能够保护他们 在流程自动化上的投资。b p e l 已经在软件供应商中获得大量认可，i b m 和 o r a c l e 都将b p e l 用于各自开发的新款流程服务器中，从而使b p e l 的地位大 为提升。b p e l 的出现取代了原有的i b m 的w e bs e r v i c e 流程语言( w e bs e r v i c e f l o wl a n g u a g e ，w s f l ) 刚和微软的x l a n g 3 1 1 ，它集w s f l 和x l a n g 两家之 长( 前者支持而向图形的流程，后者则支持流程的结构化构造) ，形成了一个支持 以很自然的方式实现各种类型的业务流程的规范。b p e l 支持两种截然不同的使 用情形：实现可执行的业务流程和描述不可执行的抽象流程。 第1 2 页，共6 5 页 支持业务模板的集成化w e bs c r v l c c s 组合研究第二章相关知识与技术 b p e l 支持的业务流程能够指定一组w e bs e r v i c e s 操作的可能执行顺序、 这些w e bs e r v i c e 间共享的数据