（计算机软件与理论专业论文）基于语义web服务的业务流程可视化集成开发平台实现研究.pdf

基于语义w e b 服务的业务流程町视化集成开发f 台实现研究 摘要 摘要 面向服务的体系架构( s e r v i c e o r i e n t e d a r c h i t e c t u r e ，s o a ) 是一种新兴的软 件体系结构，能够帮助企业实现快速流程集成与应用集成。w e b 服务是现阶段实 现s o a 的最佳技术选择。在w e b 服务的发展过程中，已经形成了一系列为业界 广泛接受的标准，其流程集成、可视化、语义应用等方面得技术也取得一定进展。 如何利用这些成果来实现基于语义w e b 服务的业务流程可视化集成开发平台，支 持企业快速构建基于w e b 服务的动态流程电子商务系统是本文及作者所在团队 的主要研究内容。 本文的研究基础和实验环境基于作者所在研究小组的“多模型驱动的面向服 务协同开发环境”课题，其中包括来自i b m 华生研究中心和加拿大国家研究院 的合作伙伴。本团队从分析现有的s o a 与w e b 服务的特点入手，提出以w e b 服务为基本组件、以s o a 为架构来创建企业电子商务系统，并以此为基础，研 发了“多模型驱动的面向服务协同开发环境”。本文结合该环境，研究了w e b 服 务流程可视化建模与语义w e b 服务，实现了该环境的核心内容之一“基于语义 w e b 服务的业务流程可视化集成开发平台( s o a 平台) ”。该平台通过业务、流 程、服务三个视图的协同工作，将面向特定行业的业务模型、面向服务的流程模 型与语义w e b 服务模型相结合，支持面向服务的快速业务方案设计、开发与配 置，支持业务咨询师与技术咨询师的协同工作。该方案能够填补业务流程与信息 系统间的差异，帮助企业构建动态的基于w e b 服务的业务流程实现，进而构建 面向服务的电子商务系统，更好地实现随需应变。在本文的最后，一套零售供应 链的案例被用于验证本文的研究思路。 关键词：s o a ，w e b 服务，流程建模，语义w e b ，b p e l 4 w s ，s a w s d l 中图分类号：t p 3 9 3 基于语义w e b 服务的业务流程町视化集成开发r 台实现研究 a b s t t a c t a b s t r a c t 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 ) i se m e r g i n ga san e ws o f t w a r ea r c h i t e c t u r e s t y l e ，w h i c h c a nh e l p e n t e r p r i s e sa c h i e v ep r o c e s si n t e g r a t i o na n da p p l i c a t i o n i n t e g r a t i o nq u i c k l y w e bs e r v i c e sa r et h eb e s tt e c h n o l o g yc h o i c et oi m p l e m e n ts o a t h e r eh a v e b e e ns e v e r a lw e l l a c c e p t e dw e bs e r v i c e ss t a n d a r d s ，s e v e r a lo t h e r t e c h n o l o g i e ss u c ha sp r o c e s si n t e g r a t i o n , p r o c e s sv i s u a l i z a t i o n ，a n ds e m a n t i c sa r e e m e r g i n g t h i sp a p e ra n dt h er e s e a r c ht e mf o c u so nh o w t oi m p l e m e n tas e m a n t i c w e bs e r v i c e sb a s e db u s i n e s sp r o c e s sv i s u a li n t e g r a t i o np l a t f o r mw h i c hc a nh e l p e n t e r p r i s e sb u i l dd y n a m i ce b u s i n e s ss o l u t i o nq u i c k l yw i t he x i s t i n gt e c h n o l o g i e s t h er e s e a r c hb a s i so ft h i sp a p e ri st h e “m u l t i m o d e ld n v e ns e r v i c e o r i e n t e d c o l l a b o r a t i v ed e v e l o p m e n te n v i r o n m e n t p r o j e c tc a r d e do u tb yt h er e s e a r c ht e a m t h e t e a ma n a l y z e se x i s t i n gs o aa n dw e bs e r v i c e st e c h n o l o g y , p u tf o r w a r dt h ei d e at o b u i l de - b u s i n e s ss o l u t i o nb a s e do ns o aw i t hw e bs e r v i c e sa sb a s i cc o m p o n e n t sa n d d e v e l o p s t h e “m u l t i m o d e ld r i v e ns e r v i c e o r i e n t e dc o l l a b o r a t i v ed e v e l o p m e n t e n v i r o n m e n t b a s e do nt h i se n v i r o n m e n t , t h i sp a p e rf o c u s e so nw e bs e r v i c e sp r o c e s s v i s u a lm o d e l i n ga n ds e m a n t i c s ，a n di m p l e m e n t so n eo ft h ec o r e sc o m p o n e n t so ft h e e n v i r o n m e n t ，b u s i n e s sp r o c e s sv i s u a li n t e g r a t i o nd e v e l o p m e n tp l a t f o r mb a s e do n s e m a n t i cw e bs e r v i c e s ( s o ap l a t f o r m ) ”t h i sp l a t f o r mc o m b i n e si n d u s t r y s p e c i f i c b u s i n e s s ，s e r v i c e s - o r i e n t e dp r o c e s sm o d e la n ds e m a n t i cw e bs e r v i c e st h r o u g ht h e c o l l a b o r a t i o no fb u s i n e s sv i e w , p r o c e s sv i e wa n ds e r v i c ev i e w s o ap l a t f o r ms u p p o r t s t h ed e s i g n ，d e v e l o p m e n ta n dc o n f i g u r a t i o n i ta l s oh e l p st h eb u s i n e s sa n dt e c h n i c a l c o n s u l t a n t st oc o l l a b o r a t eo ns o l u t i o nc o n s t r u c t i o n s o l u t i o n sp r o v i d e db ys o a p l a t f o r mc a nf i l lt h eg a pb e t w e e nb u s i n e s sp r o c e s s e sa n di n f o r m a t i o ns y s t e m s ，h e l p e n t e r p r i s e st oa c h i e v ed y n a m i cw e bs e r v i c e s - b a s e dp r o c e s s ，a n dt of u r t h e rc o n s t r u c t s e r v i c e o r i e n t e de - b u s i n e s ss o l u t i o n s t h el a s tp a r to ft h i sp a p e rp r o v i d e sac a s es t u d y o fr e t a i ls u p p l yc h a i nt ov e r i f yi d e a s k e y w o r d s ：s o a , w e bs e r v i c e s ，p r o c e s sm o d e l i n g , s e m a n t i cw e b ，b p e l 4 w s ， s a w s d l 论文独创性声明 本论文是我个人在导师指导下进行的研究工作及取得的研究成果。论文中除 了特别加以标注和致谢的地方外，不包含其他人或其它机构已经发表或撰写过的 研究成果。其他同志对本研究的启发和所做的贡献均已在论文中作了明确的声明 并表示了谢意。 作者签名：虽厶蘧聋日期：上生丑业 论文使用授权声明 本人完全了解复旦大学有关保留、使用学位论文的规定，即：学校有权保留 送交论文的复印件，允许论文被查阅和借阅；学校可以公布论文的全部或部分内 容，可以采用影印、缩印或其它复制手段保存论文。保密的论文在解密后遵守此 规定。 作者签名：匦盘玺 导师签名： 日期： 堆十语义w e b 服务的业务流程町视化集成开发平台实现研究第一幸绪论 1 1 研究背景 第一章绪论 随着经济的发展，企业的规模r 益扩大，业务日益繁多，产生的信息也呈几 何级数增长。为了处理这些信息，计算机系统在企业中发挥着日益重要的作用， 为企业提供了业务处理、管理控制、决策支持等多方面的支持。企业为了实现某 个业务功能，通常都会开发一套信息系统来进行支持。按照现有的系统构建方式， 企业业务流程一般都是包含在程序逻辑中的。而市场环境与客户需求的不断变化 则要求企业的业务流程也能随之迅速改变。但是包含在程序逻辑中的流程难以做 到这一点，因而信息系统反而限制了企业的发展。同时随着企业的发展，信息系 统也会越来越多，它们使用的平台、技术、规范等都各不相同。同时随着的产业 的发展，企业自j 的竞争己不再限于单个企业白j ，而是逐渐演变为产业链之间的竞 争。同一产业链间的企业所使用的信息系统更是差异巨大。为了在企业各部门之 间、企业与企业之间实现信息的共享，就必须将这些异构系统全部集成起来。但 是由于现有系统使用了不同的技术开发，运行在彼此不兼容的平台上，将其集成 在一起需要很大的花费。统计资料显示，企业在r r 方面的投资最大的一部分就 用于业务集成，占总投资额的3 5 。随着业务的日益复杂和系统规模的不断扩大， 这方面的费用仍将居高不下”1 。 在这种背景下，面向服务的体系架构( s e r v i c e o r i e n t e d a r c h i t e c t u r e ，s o a ) 作为一种新兴的软件体系架构诞生了。s o a 相对于以往的软件体系架构最大的 优点就是平台与技术无关性。无论原先的系统是用什么技术开发的、运行在何种 软硬件平台上，只要遵从了s o a 统一的标准与接口，就可以将这些系统集成在 一起。s o a 的标准与接口都只是描述性的，只规定了服务需要提供的功能，对 于服务在地层使用何种技术实现、运行在何种平台上不作任何规定。这样就能在 充分利用企业现有投资与技术的基础上，大幅提高企业应用集成的效率，并大大 降低集成的费用。因而s o a 正日益成为企业信息系统中主流的软件体系架构与 应用集成模式。1 。 s o a 作为一种新的软件体系结构，应该具有与之相对应的软件开发方式与 工具。作者所在研究团队在这方面进行了积极的探索，在“多模型驱动的面向服 务协同开发环境”课题上取得了相当的成果。，该课题也成为本文的直接 研究背景。 基于语义w e b 服务的业务流程可视化集成开发平台实现研究 第一章绪论 1 2 论文研究内容与目的 s o a 作为一种新兴的软件体系架构，有着以往的技术所不可比拟的巨大优 势，正同益得到业界的认可与重视。作为目前s o a 最佳实现手段的w e b 服务， 也已经有了一系列为业界所广泛接受的标准协议，包括用于描述w c b 服务的 w s d l ，用于发布、注册、发现w e b 服务的u d d i ，用于绑定调用w e b 服务的 s o a p ，以及用于将w e b 服务组合为复杂流程的b p e l 4 w s 。在此基础上，也出 现了一些支持w c b 服务流程集成的平台。但是由于上述协议都仅仅限于对w c b 服务技术层面的建模，因而以此为基础构建的平台也只能支持这一层面的建模， 不能支持对企业实际业务场景的建模，也不能支持从业务模型转换为基于w e b 服务的技术模型。但是这一功能却是企业实际需要的，因为其能帮助企业实现从 业务模型到技术模型的快速系统实现，缩短信息系统对业务变化的响应时间。因 而在集成平台中提供基于w e b 服务的业务流程可视化建模是本文的第一部分内 容。 当前用户为了得到需要的w e b 服务，需要通过u d d i 进行查找。但是u d d i 的查找是基于关键字而非基于语义的，因而在匹配的准确度与效率上不尽如人 意，并且这些查找工具并未能与现有集成平台进行整合。还有一些基于语义的查 找工具由于其使用技术与现有业界标准兼容性不佳，也未能在集成平台中得到整 合。本文试图通过为w e b 服务的描述添加语义的方式，提高查找的精确度，并 将其整合到集成平台中，使由上一步得到的基于w e b 服务的技术模型能顺利转 化为真j 下能运行的信息系统，这是本文研究的第二个问题。 总之，本文研究的w c b 服务流程集成平台旨在为企业从业务分析与建模到 s o a 流程建模再到w e b 服务发现的全过程提供支持，使企业能快速创建基于 s o a 的业务解决方案。其中，在集成平台中解决基于w e b 服务的业务建模与流 程建模及其转换问题和w e b 服务的语义查找问题是本文研究的两大关键。 1 3 论文关键技术 为了在集成平台中实现基于w e b 服务的业务流程可视化建模，本文将主要 研究w c b 服务流程集成技术、流程可视化技术、业务流程建模技术、业务流程 与w c b 服务流程的转化技术。而为了在集成平台中实现w e b 服务的语义查找与 匹配，本文将研究w e b 服务的语义表达技术、语义的匹配技术。 2 基于语义w e b 服务的业务流程可视化集成开发平台实现研究第一章绪论 1 4 论文的组织 作者所在团队在现有的s o a 与w e b 服务的基础上，结合电子商务与企业应 用的实际需求，提出了基于s o a 与w e b 服务的业务流程建模方案，并研究了基 于s a w s d l 的语义在w e b 服务中的应用。基于以上方案，本文实现了课题的核 心之一s o a 平台，通过业务、流程、服务为核心的三层视图来支持业务建模、 流程建模与服务建模。本文的具体章节安排如下： 第一章绪论，概括了整篇文章的研究背景、主要内容与组织结构； 第二章关键技术现状分析，介绍了s o a 与w e b 服务的特点及其关系，分析 了w e b 服务相关技术与本课题关键技术的现状，参考了国内外应用现状，并选 定了本课题将要采用的流程集成与语义服务协议标准。 第三章s o a 平台总体设计，概括了s o a 平台的需求，介绍了其整体架构， 详细描述了s o a 平台如何以业务、流程、服务三层视图为核心实现其所涉及的 两项关键技术，并分析了其中包含的核心组件与算法。 第四章s o a 平台系统实现，介绍了s o a 平台及其两大关键技术在e c l i p s e 与g e f 基础平台上的具体软件与算法实现。 第五章案例研究，通过一个零售供应链的案例来描述并验证s o a 平台的方 案与思路。 第六章总结与展望，总结了现有研究工作，并对下一阶段工作进行了展望。 3 基于语义w e b 服务的业务流程可视化集成开发平台实现研究第一二章关键技术现状分析 第二章关键技术现状分析 2 1s o a 与w e b 服务技术 s o a 作为一种新兴的软件体系结构与分布式计算方式，目前业界还未能形 成统一的认识，下面是业界的一些机构对于s o a 的看法： i b m 将s o a 定义为：“一个组件模型，它将应用程序的不同功能单元( 称 为服务) 通过这些服务之问定义良好的接口和契约联系起来。接口是采用中立的 方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这 使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进彳亍交互。” e 1 8 s e r v i c e a r c h i t e c t u r e t o m 将s o a 定义为：“本质上是服务的集合。服务间彼 此通信，这种通信可能是简单的数据传送，也可篚是两个或更多的服务协调进行 某些活动。服务问需要某些方法进行连接。所谓服务就是精确定义、封装完善、 独立于其他服务所处环境和状态的函数。”“” l o o s e l y c o u p l c d c o m 将s o a 定义为：“按需连接资源的系统。在s o a 中，资 源被作为可通过标准方式访问的独立服务，提供给网络中的其他成员。与传统的 系统结构相比，s o a 规定了资源间更为灵活的松散耦合关系。”。1 g a r t n e r 则将s o a 描述为：“客户端服务器的软件设计方法，一项应用由软 件服务和软件服务使用者组成s o a 与大多数通用的客户端朋艮务器模型的不 同之处，在于它着重强调软件组件的松散耦合，并使用独立的标准接口。”。” s o a 中最为关键的是“服务”的概念，w 3 c 将服务定义为：“服务提供者完 成一组工作，为服务使用者交付所需的最终结果。最终结果通常会使使用者的状 态发生变化，但也可能使提供者的状态改变，或者双方都产生变化。”图2 1 所示的是目前业晁最为认可的s o a 的架构图。 4 基于语义w e b 服务的业务流程町视化集成开发半台实现研究第二章关键技术现状分析 图2 1s o a 基本架构 s o a 体系架构中一般包含三种角色：服务提供者、服务使用者与服务注册 中心。提供者创建服务与服务描述，并将描述发布到注册中心；使用者通过注册 中心查找并发现所需服务的描述，再通过描述得到服务的具体信息；最后请求者 与服务提供者绑定，并调用服务。当然在这个体系架构中，服务注册中心并不是 必须的，服务请求者与提供者之间完全可以通过其他的方式来获知对方的存在， 并就服务的描述、绑定、调用等事宜达成一致“。 目前业界一般认为s o a 具有以下几个方面的特征： 1 松散耦合 与以往的分布式技术不同，s o a 架构下系统各个组件之间的耦合度相当低。 服务请求者与服务提供者之间以服务接口作为契约，从而完成服务的绑定与调 用。服务接口只定义了服务的功能，但不对服务的具体实现作任何规定。不同的 服务提供者只要遵循统一的服务定义，即使其实现方式截然不同，但这些服务对 于请求者来说都是能满足其功能要求的。同时又因为服务是通过注册中心来发现 的，从而使这种服务的切换更为便利，大大降低了s o a 中系统组建的耦合度。 2 标准化的接口 s o a 中的服务都遵循标准化的规范定义的接口。这些标准化的规范规定了 服务服务本身的信息、服务提供的功能、调用服务的消息、消息的封装格式等。 但是标准对服务的具体实现细节不作任何规定。标准是由业界的各大厂商与机构 共同制定，并且为业界一直接受的。这就解决了以往各大厂商分别推出自己的分 布式技术，但是这些技术不仅定义接口，而且对实现也做严格规定的问题。只要 遵从标准接口。各个服务提供商可以采用不同的实现方式，充分发挥自身的优势。 5 幕f 语义w e b 服务的业务流程可视化集成开发f 台，实现研究第一二章关键技术现状分析 3 粗粒度服务 与以往软件系统中的子程序和对象相比，s o a 中服务的粒度通常是比较粗 的。一项服务应该实现的是一组业务上的或技术上的功能。服务的使用者可以通 过将多个粗粒度的服务组合起来，迅速的形成复杂的应用逻辑。如果服务的粒度 过细的话，会导致服务的组合变得十分复杂，同时交互的效率也会大大降低。当 然在服务内部，可以通过细粒度的面向过程或者面向对象的方法来实现。s o a 适用的是粗粒度的较高的应用层面。 4 技术无关性 以往的分布式计算模式都是和具体技术紧密绑定的，例如微软的d c o m 、 s u n 的r m i 、o m g 的c o r b a 。也就是说这些技术中的分布式组件都必须采用 同样的编程语言编写，运行在同一个厂商的平台下。而不同厂商、不同平台、不 同语言的分布式组件间难以相互沟通。这直接导致了企业应用集成的难度与费用 居高不下。在s o a 中，标准只规定服务的功能等接口部分，不服务的具体实现 技术不做规定。不同的厂商可以采用不同的技术与平台来实现同一个服务接口。 采用不同技术的服务可以十分容易的通过标准协议进行交互。用户在使用时完全 不用关心服务的实现技术与运行平台，并且可以在不同技术实现的服务间实现无 缝转换。 人们通常会把s o a 与w e b 服务混为一谈，但事实上它们并不是相同的概念。 s o a 与w e b 服务是两个不同层面的概念。s o a 是一种软件结构与分布式计算模 式，着重概念，面向商业应用。而w e b 服务则是一种具体的技术框架，着重技 术实现。因为最常见的情况就是用w e b 服务来实现s o a ，因而人们容易混淆两 者的区别。事实上其他分布式技术，例如c o b r a ，也可以用来实现s o a ，但是 相比w e b 服务有着明显的缺陷。因而就现阶段而言，w e b 服务是实现s o a 的最 佳技术选择。s o a 的各种特性，在w e b 服务中都有着具体的体现。 w 3 c 在其推荐标准中提出了w e b 服务的参考架构，如图2 2 所示“1 。w e b 服务中主要涉及服务请求方与服务提供方。一个典型的w e b 服务的调用过程如 下：首先请求方与提供方需要通过某种方式了解到对方的存在，一种常见的方式 是通过u d d l 等服务注册中心。其次，双方需要对服务的接口描述达成一致，其 中可能会涉及到语义。然后，请求方需要将具体的请求信息，如输入输出参数、 w e b 服务u r l 等输入请求客户端。客户端可以是桌面应用程序、w e b 应用程序、 b p e l 4 w s 流程等。提供方则通过w e b 服务的平台将服务在w e b 上发布。当前 的各种流行平台，如i b m 的w e b s p h e r e 、微软的a s e n e t 、a p a c h e 的a x i s 等， 均对w e b 服务提供了支持。最后，w e b 服务客户端与w e b 服务进行交户，完成 w e b 服务的调用。 摹f 语义w e b 服务的业务流程可视化囊成开发、f 台实现研究第二章关键技术现状分析 图2 2w e b 服务参考架构图” 虽然当前w e b 服务在业界尚未得到大规模的应用，各个平台对其的支持也 存在一定的差异，但各大厂商与组织对w e b 服务的很多特性都是一致认同的， 那就是相对于传统的分布式计算技术，w e b 服务有如下特点哑1 ： 1 标准化。w e b 服务所采用的消息协议s o a p ，接口描述协议w s d l ，发 布与查找协议u d d i ，流程协议b p e l 4 w s 等都是标准化的协议，由w 3 c 或 o a s i s 等官方组织发布与维护，而以往的分布式技术均使用各平台与厂商的私 有协议。 2 流程独立。以往构建信息系统时。企业的业务流程都是内嵌于程序代码 逻辑中的，一旦外部环境或内部需求发生改变，难以实现流程动态的随需应变。 而w e b 服务可以通过流程描述机制将业务流程从程序代码中独立出来，像配置 文件一样单独存在。这样的话就可以做到使流程根据需要实时更改。 3 松散祸合。w e b 服务采用w s d l 来描述其接口。w s d l 中的接口描述部 分只规定了w e b 服务的名字、输入输出参数等内容，而服务实现部分则可以根 据服务提供商的不同而改变。不同的w e b 服务只要采用相同的接口描述，服务 的使用者就可以在这些服务间实现动态更改。 4 平台与技术独立性。w e b 服务的所有协议都不对具体技术平台做任何规 定，因而服务提供商可以基于任意的平台与技术来构建服务，只需遵从标准的协 议与接口即可。当前s u n 的j 2 e e 、微软的n e t 等平台都对w e b 服务提供了支持。 基于语义w e b 服务的业务流程可视化集成开发平台实现研究第二章关键技术现状分析 而这些不同平台开发的w e b 服务对使用者来说并不存在本质的区别。 5 粗粒度服务。一个服务描述w s d l 文件包含一组相关的操作，组成一个 w e b 服务，实现一组业务功能。从这个意义上说，w e b 服务的粒度是比较粗的。 6 高度可集成能力。由于w e b 服务采用了业界普遍接受的标准防议与交互 方式，因而在应用集成时企业只需要将现有遗留系统的功能封装成w e b 服务， 就可以通过w e b 服务的标准方式在其他系统与业务流程中调用，大大降低应用 集成的难度与费用。 从上述几点可以看出，w e b 服务与s o a 在很多特性上是相同的，w e b 服务 是现阶段实现s o a 的最佳技术方案。 正如t c p ，口一样，w 曲服务的技术框架中也存在着为位于不同层次、发挥 着不同功能的协议”1 ，这些协议共同组成了w e b 服务的协议栈，如图2 3 所 示。下文将对其中主要的三个协议s o a p 、w s d l 与u d d i 进行介绍。 漉珏! i 办泼b i l j l 4 w s 发m j 焱铆嘶没u d d i 棱i l 粕述孙 ；cw s d l 澎息协议s o a p 杯记魏i ；x m l 织输渤议h t t pf t ps m t p 图2 3 w e b 服务协议栈 简单对象访问协议( 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 消息的传递，可靠的传输、防火墙规则等作任何规定。虽然 s o a p 本身只是一种无状态的单项消息交换模型，但用户可以通过将其与应用相 关的协议相结合来创建更为复杂的交互模型“。s o a p 目日订最新的版本是1 2 。 s o a p 主要包括以下几个部分： 8 基于语义w e b 服务的业务流程可视化集成开发平台实现研究第一二章关键技术现状分析 1 s o a p 消息框架，定义了一个s o a p 消息中可以包含哪些信息，谁来处 理这些信息，以及哪些信息是必需的，哪些信息是可选的。一个s o a p 消息就 是一个x m l 文档，其根元素为e n v e l o p e 。e n v e l o p e 提供了对s o a p 消息的封装， 在每一个s o a p 消息中都是必需的。e n v e l o p 下又可以包含两个子元素：h e a d e r 与b o d y 。s o a ph e a d e r 在s o a p 消息中是可选的，但是一旦出现的话就必须是 e n v e l o p e 的第一个字元素。h e a d e r 下的每一个子元素都被称为h e a d e rb l o c k ，其 中包含的数据和应用程序实际的业务数据是无关的，主要用于提供各种控制信 息。s o a pb o d y 在每个s o a p 消息中都是必须存在的，并且如果有s o a ph e a d e r 的话，必须出现在h e a d e r 之后。b o d y 也可以包含多个子元素，其中的数据就是 应用程序要通过这个s o a p 消息交换的实际数据。为了报告s o a p 协议与应用程 序中的各种错误，s o a p 消息框架还专门定义了一个元素f a u l t 元素。f a u l t 是 b o d y 下的子元素，其下又包含多个子元素，包括必需的c o d e 、r e a s o n 元素和可 选的d e t a i l 元素。图2 4 显示了w 3 c 给出的s o a p l 2 消息的结构。 图2 4s o a p 消息的结构1 2 s o a p 编码规则，定义了一套编码机制，用于交换应用程序中使用到的 实例数据。s o a p 编码基于一个简单的类型系统，该类型系统包含了程序设计语 言、数据库与半结构化数据中的类型系统的共同特性。在这里一个类型要么是只 包含一个部分的简单类型，要么是由多个部分组合而成的复合类型，其中每个部 分又可以是简单类型或者复合类型，当然复合类型分解到最后必然都是简单类 型。s o a p 编码就定义了一套规则，描述了如何将这种类型化对象进行编码。 3 s o a pr p c 表示，定义了如何用s o a p 来表示远程过程调用与应答，也 就是定义了一套通用的用于远程过程调用的请求与响应表示方式，目的是为了以 一种程序语言无关的方式来支持远程过程调用时的信息交换。r p c 表示并不指 9 基于语义w e b 服务的业务流程町视化集j 毙开发，f 台实现研究第二章关键技术现状分析 定具体的s o a p 绑定协议，在m 1 甲绑定中r p c 请求与响应会被映射成h t y p 请求与q 目应，其他绑定中也会有不同的映射。为了进行r p c 调用，必须提供如 下信息：s o a p 目标节点的地址；方法或子程序名；参数类型，名称与实际值； 与具体的绑定相关的属性值：其他任何可选的h e a d e r 数据。 4 除了s o a p 消息框架、编码规则和r p c 表示，s o a p 规范还定义了s o a p 的绑定，其中最常见是m 1 p 绑定，因为h t y p 有着诸多的优势“，使用h t r p 绑定就意味着s o a p 也可以享受这些优势。s o a ph t t p 绑定定义了如何利用 h 1 r p 来完成s o a p 消息的传输。 2 1 2w s d l w e b 服务描述语言( w e bs e r v i c ed e s c r i p t i o nla n g u a g e ，w s d l ) ，是现阶段 业界用于描述w e b 服务接口的标准协议，目前最新的是2 0 版“”，但之前的1 1 版仍在广泛使用中。1 。可以认为一个w s d l 文档就对应于一个w e b 服务。w s d l 文档的根元素是 元素，其下的内容主要可以分为两部分。第一部分 是抽象接口定义，第二部分是具体实现描述。接口部分定义了w e b 服务的接口、 名称、输入输出参数及类型，这些内容是独立于任何实现层的协议的。实现部分 则具体描述了w e b 服务的u r i 、在调用时将与何种消息格式与传输协议相绑定。 w 3 c 定义的w s d l 2 0 文档的结构如图2 5 所示”“： 目圉目藤 ”r _ 葡五n l 型! 竺! ! f ! 圉：。囡 陌 ”匕j 塑篓j 一 ”圈罔 l $ ”q “a b nif = 膏1 i o t e v 舳e l l s m a y h a o 口q 埔自m 聪目n a t 目n d 。* h 图2 5w s d l 文档架构示意图 1 0 基于语义w e b 服务的业务流程町视化集成开发f 台实现研究第一二章关键技术现状分析 抽象接口包含以下主要元素： - 定义该w s d l 文档中用到的x m l 类型和元素( ) 。 ：定义w e b 服务中的一项操作，以及该操作的输入输出参数 ( ， ) ，这些参数就是在 q a 定义的元素。 ：是多个相关 的集合，定义了这些 组成的 w e b 服务的访问入口。 具体实现则包含以下主要元素： ： 与 指定实际访问时所需的具体消息格式 与传输协议，最常见的分别是s o a p 与h t i p 。 ：为这个w s d l 文档定义的w e b 服务提供名字，并通过 子元素定义该w e b 服务的访问端点，通常是w e b 资源的u r l 。 抽象接口部分与w e b 服务的具体实现无关，使相同的w e b 服务接口能够在 多个不同实现问得到复用。而实现部分则提供了访问w e b 服务所需的u r l 以及 具体的消息格式与传输协议，对相同的w e b 服务接口可能有不同的实现方式。 w s d l 对抽象接口与具体实现的分离定义，大大提高了w e b 服务接口的复用程 度。但是当前w s d l 的主要问题是缺乏语义表达能力，限制了w e b 服务的自动 化处理能力“。 2 l3u d d i 统一描述、发现和集成( u n i v e r s a ld e s c r i p t i o n ，d i s c o v e r y , a n di n t e g r a t i o n ， u d d i ) 提供了一组基于标准的规范用于描述和发现w e b 服务。u d d i 使得企业 能够通过i n t e r n e t 相互发现、获取彼此的信息并调用提供的w e b 服务“”。u d d i 目前最新的版本是3 0 2 。 u d d i 中最重要的组成部分是u d d i 注册中心，维护着商业实体及其所提供 的w e b 服务等信息。u d d 3 0 2 规范中，u d d i 注册中心所维护的信息的结构应 如图2 6 所示。 基于语义w e b 服务的业务流程可视化集成开发甲台实现研究第二帝关键技术现状分析 图2 6u d d i 核心数据结构“7 1 如图2 6 所示，保存在注册中心的u d d i 核心数据有四部分组成： 1 商业实体( b u s i n e s s e n t i t y ) ，也就是通常所说的白页，包含了提供服务的 企业的基本信息，如企业名称、经营范围、联系信息等。它还包括该企业的任何 一种标识符，如d u n & b r a d s t r e e td u n s o 号码。 2 商业服务( b u s i n e s s s e r v i c e ) ，也就是通常所说的黄页，与商业实体是多 对一的关系。商业服务描述了商业实体所提供的一组相关w e b 服务的具体信息。 在这罨，w e b 服务可以根据不同的分类标准与法则进行划分，从而形成不同的商 业服务组合，以更好的满足注册中心客户的需要。 3 绑定模板( b i n g d i n g t e m p l a t e ) ，也就是通常所说的绿页，与商业服务是 多对一的关系。绑定模板描述了使用商业服务中某个具体的w e b 服务时所必需 的技术信息，包括w e b 服务的u r l 、应该使用何种方式与协议去调用等。 4 技术模型( t m o d e l ) ，定义了u d d i 中一种可重用的概念，例如一种w e b 服务的类型、一项w e b 服务协议或者一套分类系统。技术模型主要用于为用户 提供参考，使其能更好的了解如何与u d d i 中的w e b 服务进行交互。 u d d i 注珊中心会给每个实体指定一个唯一的标识符，叫做唯一通用标识符 ( u n i q u eu n i v e r s a li d e n t i f i e r ，u u i d ) 。u u i d 在每个注册中心中都是唯一的，且 一旦生成就不会变化。其格式是一组十六进制的字符串。利用u u i d 就可以引用 与之相关联的实体。一个注册中心中创建的u u i d 只在该注册中心中有效。 为了操作注册中心维护的数据，u d d i 规范为用户提供了一组标准的a p i ， 每个u d d i 注册中心都必须实现。u d d i a p i 中最重要的是用于查询与发布w e b 服务的两组a p i 。前者使得服务的请求者能在u d d l 中查找其所需要的实体与服 务，后者则使服务提供者能对u d d i 中的实体与服务进行添加、修改、删除等维 护操作。 摹于语义w e b 服务的业务流程可视化集成开发f 台实现研究第一二章关键技术现状分析 当前u d d i 的同样缺乏语义表达能力，其查找与匹配主要基于关键字，也限 制了w e b 服务的自动化处理能力“3 。 2 2w e b 服务流程集成技术 以s o a 方式来构建应用系统，w e b 服务就是系统的基本组成构件。而为了 将用w e b 服务实现业务流程的自动化，必须使用流程集成技术将w e b 服务组合 为流程，并交由执行引擎进行处理。“”。w e b 服务的流程集成已经成为业界各 大厂商与组织关注的重点之一，并提出了各种标准，其中尤以b p e l 4 w s 最为引 人注目。 b p e l 4 w s ( 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 ef o rw e bs e r v i c e s ) 是 m i c r o s o f t 、m m 、s a p 等公司推出的用于组合w e b 服务的业务流程描述语言， 基于x m l 定义，目前最新的版本是1 1 版。b p e l 4 w s 能够把多个w e b 组合集 成起来，并支持各种复杂的控制结构，从而创建出对应于业务需求的流程“1 。下 文将简述b p e l 4 w s 的结构。 用b p e l 4 w s 创建出来的流程最终也会发布成一个w e b 服务，因此也需要 用w s d l 来描述。描述b p e i a w sw e b 服务的w s d l 文件除了一般的 、 和 等定义外，还包括 定义，用于描述流程 中用到的合作伙伴类型。b p e i a w s 将流程中用到的所有w e b 服务都视为合作伙 伴，因此定义合作伙伴类型就是指定流程中涉及的w e b 服务的w s d l 的u r l 。 定义了合作伙伴w e b 服务后，就可以定义业务流程了。一个典型的b p e l 4 w s 文档结构如下所示，业务流程对应于根元素 元素。 ? ? ? 7 7 7 1 3 摹千语义w e b 服务的业务流程可视化集成开发，f 台实现研究 第二章关键技术现状分析 7 a c t i v i t y 从中可以看出b p e i a w s 业务流程主要包含以下几个部分： ，用于定义流程中用到的业务链接； ，用于定义参与流程的业务伙伴： ，用于保存流程中用到的数据； ，用于处理流程的相关性； ，用于定义处理异常情况的活动； ，用于定义补偿活动； ，用于定义事件处理器； a c t i v i t y ，包含流程涉及到的各种活动，可以为以下的任意一种： ，指定从哪个业务伙伴处接收消息，同时要指定的还有业务伙伴的 p o n t y p e 、o p e r a t i o n 、以及将业务伙伴发送过来的数据放到那个变量中，用于启 动流程，同步异步流程均可； ，指定对哪个业务伙伴做出响应，同样要指定业务伙伴的p o r t t y p e 与o p e r a t i o n ，用于异步流程； ，用于调用某个业务伙伴的w e b 服务，需指定p o r t t y p e 与o p e r a t i o n ： ，用于变量间的赋值； ，流程发生错误时用来抛出异常； ，将流程立即终止； ，用于指定流程应等待一段时间或一直等到指定的时刻； ，标示流程在此不做任何操作： ，用于撤销已完成的活动的效果； ，该范围内的活动按照设计时的顺序先后执行； ，根据判断条件，选择多条路径中的一条执行； ，只要判断条件为真，则重复执行该范围的活功； ，再多条路径中选择一条执行； ，多条路径中活动不分先后同时执行； ，定义一个范围，在其中又可以定义上文所提到的各种a c t i v i t y ，同 时该范围还可以包含其自身的v a r i a b l e 、f a u l t h a n d l e r s 、c o m p e n s a t i o n h a n d l e r s 和 e v e n t h a n d l e r s 。 由于b p e l 4 w s 本身的特性，作者所在团队选用b p e l 4 w s 作为w e b 服务 的流程集成的技术。 1 4 基十语义w e b 服务的业务流程可视化集成开发，f 台实现研究 第二章关键技术现状分析 2 3w e b 服务流程可视化技术 目前已有一些业界厂商推出了自己的w e b 服务可视化流程建模工具，在w e b