（计算机系统结构专业论文）基于编排与编制一致性的系统设计.pdf

大连理工大学硕士学位论文 摘要 编排( 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 ) 是常用于描述合成网络服务的两种方 式的语言。前者从一个整体的视角定义了系统中各服务之间的交互，而后者仅从一个服 务的角度定义了应调用什么服务以及应该何时调用，没有定义多方如何进行协作。根据 两者的特性，在设计服务组合系统时，可以先用编排来定义一个系统高层次上的服务交 互协议，再用编制描述具体某个服务的行为以实现编排层定义的协议，最后用流程语言 实现整个系统。这种做法的优点是：其一，提供了一种从上至下的实现服务组合系统的 方法；其二是能够支持系统的从下至上的一致性的验证。 这种系统设计方法的应用需要一个能够描述编排与编制的形式化系统做为依托。本 文分析了各种形式化方法的优劣，采用了进程代数范畴内的方法对编排编制进行形式化 描述。通过对一个理想的服务组合系统的设计模型的分析，总结了现有解决方案的不足， 针对这些不足，本文在语义模型中加入了状态的描述，增强了其表达能力，使其能够描 述确定性选择、分支等结构化流程；在系统中引入了三层的结构，分别为进程内部行为、 进程间的交互以及服务间的互操作，层次化了交互语义，以利于系统在不同层面上的单 独设计；针对目前服务组合系统的不确定性，文中实现了系统状态、服务位置、服务接 口以及服务功能的动态性语义，并举例进行了讨论；同时文章还给出了编制形式化系统 到w s - b p e l 流程的映射及转化算法，有助于以后执行代码的自动生成。 文章的最后给出了一个航空公司订票系统的设计过程。分别从编排和编制的角度设 计了系统的交互并发行为，根据外部可观察行为一致性原理，分析了错误的编制设计， 给出了正确的以及一个精化了的系统模型，同时进行了系统的一致性验证。最后给出了 形式化系统到流程语言转换之后的部分代码。 关键词：编排；编制；可观察行为一致性；形式化系统 大连理工大学硕士学位论文 c h o r e o g r a p h ya n do r c h e s t r a t i o nc o n f o r m a n c ef o rs y s t e md e s i g n a b s t r a c t o r c h e s t r a t i o na n dc h o r e o g r a p h ya r et w ol a n g u a g e sc o m m o n l yu s e df o rd e s c r i b i n gw e b s e l v i 嘲c o m p o s i t i o n t h ed i f f e r e n c e sb e t w e e no r c h e s t r a t i o na n dc h o r e o g r a p h ya r et h ef o r m e r o n ei sap e e rt op e e rm o d e la n di nab u s i n e s sp r o c e s st h e r ea l em a n yc o o r d i n a t o r s ；t h el a t e f o n ei sah i e r a r c h i c a lr e q u e s t e r p r o v i d e rm o d e l c h o r e o g r a p h yd e f i n e st h ec o o p e r a t i o n sf r o ma t o pv i e wm a n n e r , w h i l eo r c h e s t r a t i o nd e f i n e sw h e na n dh o wt oi n v o k eas e r v i c ef r o mo n e p o i n to fv i e w a c c o r d i n gt ot h e i rc h a r a c t e r i s t i c s ，w ec o u l du s ec h o r e o g r a p h yt od e s c r i b et h e p r o t o c o lo nt h eh i g h e rl e v e la n dt h eo t h e ro n ef o rd e f i n i n gt h ea c t i o no fe v e r ys i n g l es e r v i c e t l l i sa p p r o a c hh a st w oa d v a n t a g e s ：f i r s t l y , i tp r o v i d e sat o p - d o w nw a yf o rs y s t e md e s i g n ； s e c o n d l y , i ts u p p o r t st h ec o m f o r r n a n c ev e r i f i c a t i o n t h i sl 【i n do fd e s i g n i n gm e t h o dn e e d saf o r m a ls y s t e mw h i c hc o u l dd e s c r i b e c h o r e o g r a p h ya n do r c h e s t r a t i o n t 1 1 i sp a p e ra n a l y s e st h ea d v a n t a g e sa n dd i s a d v a n m g e so f d i f f e r e n tf o r m a lm e t h o d s a n du s 鹤a l g e b r ap r o c e s st of o r m a l l yd e s c r i b et h ec o m p o s i t i o n s y s t e m t h r o u i g ht h ea n a l y s i s o fat h e r o ys e r v i c ec o m p o s i t i o n ，w ec o n c l u d e dt h e d i s a d v a n t a g e so fc u r r e n ts y s t e ms o l u t i o n f o rt h e s ed i s a d v a n t a g e s ，w ea d d e dt h ed e s c r i p t i o n o fs t a t u s ，e n h a n c i n gt h ee x p r e s s i v ea b i l i t y , a n dm a k et h e mh a v et h o - - e a p a b i l i t yt od e s c r i b e c h o i c e ，s w i t c ha n do t h e rk i n do fs t r u c t u r e w ed e f i n eat h r e el a y e r e ds y s t e mw h i c ha r e i n t e r - p r o c e s s ，b e t w e e n p r o c e s sa n db e t w e e ns e r v i c e ，l a y e r e dt h ec o o p e r a t i o ns e m a n t i c sf o r d e s i g n i n gas y s t e mi nd i f f e r e n tl a y e r b e c a u s et h ec o m p o s t i o ns y s t e mi su n c e r t a i n ，i nt h e p a p e r ，w ei m p l i m 印ts y s t e ms t a t u sm o b i l i t y ，l o c a t i o nm o b i l i t y , i n t e r f a c em o b i l i t ya n df u n c t i o n m o b i l i t y , u s i n gs o m ee x a m p l e st oe x p l a i nt h a t m e a n w h i l ew eg i v et h em e t h o dt oc h a n g e f r o mo r h e s t r a t i o ns y s t e mt ob p e ll a n g u a g e ，w h i c hw i l lb eag r e a th e l pf o ra u t o m a t i c a l c r e a t i o no f c o d e s i nt h ee n do f t h ep a p e r , w eg i v ea ne x a m p l eo faa i r w a yp l a n et i c k e ts e l l i n gs y s t e m w e d e s i g nt h ec h o r e o g r a p h ya n do r c h e s t r a t i o nd e s c r i p t i o n a c c o r d i n gt ot h es y s t e mc o m f o r m a n c e ， w ea n a l y s eaf a u l to r c h e s t r a t i o nd e s i g na n dt h e ng i v ear i g h ta n dr e f i n e do n e t h em a p p i n go f t h ew h o l ef o r m a ls y s t e mt ob p e li sa l s op r o v i d e d k e yw o r d s ：c h o r e n g r a p h y ；o r c h e s t r a t i o n ；o b s e r v a b l eb e h a v i o rc o m f o r m a n c e ；f o r m a l s y s t e m i i i 独创性说明 作者郑重声明：本硕士学位论文是我个人在导师指导下进行的研究工 作及取得研究成果尽我所知，除了文中特别加以标注和致谢的地方外， 论文中不包含其他人已经发表或撰写的研究成果，也不包含为获得大连理 工大学或者其他单位的学位或证书所使用过的材料与我一同工作的同志 对本研究所做的贡献均已在论文中做了明确的说明并表示了谢意 作者签名：日期：竺：墨! ：芝 大连理上大学硕士研究生学位娩文 大连理工大学学位论文版权使用授权书 本学位论文作者及指导教师完伞了解“太连理工大学硕士、博十学位论文版权使用 规定”，同意大连理工大学保留并向国家有关部门或机构送交学位论文的复印件和电予 版，允许论文被查阅和借阅。本人授权大连理工大学可以将本学位论文的仝部或部分内 容编入有关数据库进行检索，也可采用影印、缩印或扫描等复制手段保存和汇编学位论 文。 作者签名 导师签名 兰壅拉： 酵上月翌同 大连理工大学硕士学位论文 1绪论 软件业从最初的面向过程、面向对象，到后来的面向组件、面向集成，直到现在的 面向服务，走过了一条螺旋上升的曲线。其实，自从上世纪7 0 年代提出“软件危机”， 诞生软件工程学科以来，软件业为了彻底摆脱软件系统开发泥潭，一直也没有放弃努力 在经典软件工程理论中，不管是瀑布方法还是原型方法，都是从需求分析做起，一 步一步构建起形形色色的软件系统。但是，需求变更像一个挥之不去的阴影，时刻伴随 着系统左右。每一个实际应用系统的开发者都饱尝了在系统进入开发阶段、测试阶段， 甚至上线阶段遭遇应接不暇的需求变更的极端痛苦。客户将变更的需求视为b u g ，也是 测试上现阶段的主要问题。 s o a 架构的提出，就是被人看成一场软件开发和架构的革命。s o a 并不是一个新 概念，有人就将c o r b a 和d c o m 等组件模型看成s o a 架构的前身。早在1 9 9 6 年， g a r t n e rg r o u p 就已经提出了s o a 的预言。不过那个时候仅仅是一个预言，当时的软件 发展水平和信息化程度还不足以支撑这样的概念走进实质性应用阶段。到了近一两年， s o a 的技术实现手段渐渐成熟了。 关于s o a ，目前尚未有一个统一的、业界广泛接受的定义。一般认为：s o a ，面向 服务的架构是一个组件模型，它将应用程序的不同功能单元服务( s e r v i c e ) ，通过服 务间定义良好的接口和契约( c o n t r a c t ) 联系起来。接口采用中立的方式定义，独立于具体 实现服务的硬件平台、操作系统和编程语言，使得构建在这样的系统中的服务可以使用 统一和标准的方式进行通信。这种具有中立接口的定义的特征被称为服务之间的松耦 合。 一个s o a 应用系统的大体框架结构。它大体上可以分为五个部分，如图i i 所示： 展现层( p r e s e n t a t i o n ) 为图中最上区，通过p o r t a l 等技术建立展现平台，方便用户在 这个界面上提出服务请求。业务处理建模( b u s i n e s sp r o c e s sm o d e l i n g ) 为图中的次上区， s o a 元模型从b t i ) a ( m o d e ld r i v e na r c h i t e c t u r e ) 中继承了平台无关模型来对业务处理过 程建模。这一部分独立于服务设计和部署层。模型驱动架构m d a 的主要缺陷是在模型设 计阶段就对需求有完整的描述，而且没有需求变更的反馈机制。s o a 通过添加敏捷方法 a m 来应对需求变更的情况。服务层( s e r v i c e s ) 为图中的中间区，整个s o a 的核心层， 它承上启下，对上响应业务模型，对下调用相关组件群完成业务需求，形成业务驱动 基于编排与编制致性的系统设计 p r e s e n t a t ；彻回回 点时q 辛屯p - _ 曩 ) 暑 1 暑 ic 1 m p o s i t es叫ervice 学( 耋 喜 器董丑基兰 詈量 萋! 量 o p 跏s y s t e m i o l 1 国e r l m 暴o i j e c t i i e i n t e i l i g e n c e i ll t e d lll 图1 i 面向服务架构 f i g 1 1 s 口“o r i e n t e da r c h i t t u r e 服务、服务驱动技术的s o a 事务处理格局。服务可以根据粒度分层。虽然细粒度提供 了更多的灵活性，但同时也意味着交互的模式可能更为复杂。粗粒度降低了交互复杂性， 但敏捷性却下降。企业组件层( e n t e r p r i s e c o m p o n t s ) 为图中的次下区，这里是相关组件 发挥作用的场所。这些组件是平台相关的。因为到了这一层，许多底层软硬件平台的特 性已经不再透明了。系统软件层( o p e r a t i o n a ls y s t e m ) 为图中的下区，这一层包括操作系 统、数据库管理系统、c r m 、e r p 、商业智能( b i ) 等异构系统，是一个集成的平台。除 此之外，诸如q o s 、安全性等也是s o a 架构的组成部分。 j a s o nb l o o m b e r g 在其p r i n c i p l e so fs o a ) ) 中指出，在抽象层次上，服务位于业务 和技术中间。面向服务的架构设计师一方面必须理解在业务需求和可以提供的服务之间 的动态关系；另一方面，同样要理解服务与提供这些服务的底层技术之间的关系。s o a 考虑的是下一个抽象层次：提供响应变化需求的能力是新的元需求，而不是处理一些业 务上的固定不变的需求。从硬件系统以上的整个架构都必须满足业务敏捷的需求，因为 大连理工大学硕士学位论文 在s o a 中任何的瓶颈都会影响到整个i t 环境的灵活性。s o a 工作的场景，更像是一个 活的生物体，而不是像传统所说的盖一栋房子。r r 环境惟一不变的就是变化，因此面向 服务架构设计师的工作永远不会结束。对于习惯于盖房子的设计师来说，要转向设计一 个活的生物体要求有崭新的思维方式。s o a 的基础还是一些类似的架构准则。 s o a 带给企业很多便利之处：可以集成现有系统，不必另起炉灶。能够方便组合松 耦合的服务，以提供更为优质和快速的响应，允许服务使用者自动发现和连接可用的服 务。松耦合系统架构使得服务更容易被应用所集成，或组成其他服务，同时提供了良好 的应用开发、运行时服务部属和服务管理能力。统一了业务架构，可扩展性增强。加快 了开发速度，减少了开发成本 1 1 课题研究的背景与问题的提出 近年来，随着电子商务的迅速崛起，网络应用从局部化发展到全球化。从 b 2 c ( b u s i n e s s - t o c u s t o m e r ) 发展到b 2 b ( b u s i n e s s - t o - b u s i n e s s ) ，从集中式发展到分布式。 w c bs e r v i c e s 作为一种新兴的网络应用模式，是一个崭新的分布式计算模型，是网络上数 据和信息集成的有效机制。单个w c b 服务可能只提供唯一的调用函数来完成一个单一 的功能，而将多个w e b 服务进行有机组合就可以完成一系列的复杂任务。从w e b 服务 中的支撑技术来看，很多关键问题有待解决，具有广阔的研究空间，但同时也存在很多挑 战。s o a 构架是独立于技术实现的。s o a 并不必用w e bs e r v i c e s 来实现，相反，w e b s e r v i c e s 也并不一定遵循s o a 标准。不过，w c bs e r v i c e s 的特性十分适合用来实现s o a 架构。w e bs e r v i c e s 之间能够交换带结构的文档( 比如x m l ) ，这些文档可能包含完全异 构的数据信息。这些文档可以同时附带关于数据的数据：元数据( m e t a d a t a ) 。换句话说， w e bs e r v i c e s 可以有较粗的粒度，这样较粗的粒度正好可以构成s o a 中服务的粒度。 作为一个具有发展前景的应用系统架构，s o a 尚处在不断发展中，存在许多有待解 决的难题： 首先是编排( c h o r e o g r a p h y ) 与编制( o r c h e s t r a t i o n ) 。统一协调分布式软件组件以便构 建有意义的业务流程是最复杂的，但它同时也最适合面向服务类型的集成，原因很显然， 建立在s o a 上面的应用软件被设计成可以按需要拆散、重新组装的服务。作为目前业 务流程管理( b p m ) 解决方案的核心，编排功能使1 1 r 管理人员能够通过已经部署的套装 或自己开发的应用软件的功能，把新的元应用软件( m e t , a - a p p l i c a t i o n ) 连接起来。事实上， 最大的难题不是建立模块化的应用软件，而是改变这些系统表示所处理数据的方法。 另一个s o a 面对的难题是定义事务和数据的业务语义( s e m a n t i c s ) 支持，这一直是 i t 管理人员面i 临的最棘手的问题。语义关系是设计良好s o a 架构的核心要素。在下一 基于编摔与编制一致性的系统设计 代网络服务技术中个性化服务是一个重要的研究方向，用户需要按照各自的意愿发现、 选择、调用和组合他们想要的服务，而这一切的前提条件就是要实现网络服务的语义互 操作性。事实上，这种语义的互操作性需要在现有s o a 体系结构中加入机器可理解的 层，而这种层次目前还没有很好的技术作为支持。当前的网络服务的标准技术( 例如 w s d l ! ，w s b p e l e 2 1 ，w s c d l t 3 1 ) 服务功能以及商务流的描述，但是都只是在语法的 层面上，因此业界需要一种定义良好的语义模型能够让机器自动的定义和分析所要描述 的进程，最终是r r 开发人员和业务人员从繁重的流程定义以及实施功能和数据模型中 解脱出来。为了解决语义的问题，当前主要有两种主要的解决方案。一个是给已经存在 的标准的服务组合语言以形式化的语义。一些形式化方法的研究人员目前正致力于形式 化b p e l 和w s c d l 的行为，在文献中【4 ，5 】给出了这两种语言的形式化模型以支持自动 分析和模型检测。另外一种常用的解决方案是o w l s 1 6 1 和i r s i l l p 】。o w l - s 语言是由 多个组织的研究人员联合提出的描述网络服务的存在论( o n t o l o g y ) ，o w l - s 语言既可以 描述一个简单的网络服务，也可以描述一个复杂的网络服务( 由多个服务组成) 。对于一 个复杂的网络服务，用户和服务之间有一个交互和会话，以便用户做出选择，提供条件 性信息，这都需要o w l - s 提供描述支持。i r s i io n t o l o g y 目前基于w s m o 标准，用以 支持能力驱动的网络服务调用。 还有一个困扰s o a 的难题是形式化建模。目前可用于服务的外部可见行为建模的方 法已经大量存在，比如w s b p e l 、w s c d l 、w s c i 和w s m o - c h o r e o g r a p h y 等等。但是 这些方法都没能提供一个完整的解决方案。w s b p e l 与基础通信框架联系紧密缺乏层次 模型而且不支持语义技术。w s c d l 虽然具有层次模型但同样缺乏语义支持且与基础通 信框架联系紧密。w s c i 的优点是与基础通信框架依赖较小，但缺乏层次模型与不支持 语义技术。w s m o - c h o r g r a p h y 的特点是支持语义技术与基础通信框架联系松弛但是缺 乏层次模型。 综上所述，对于s o a 来说，为服务层之上的业务处理建模层以及展现层提供一个 基于严格的语义的形式化框架是很有意义的，对面向服务的体系结构的发展具有深远的 影响，也是目前业界研究的一个重要的方向。 1 2 形式化工作的重要意义及国内外的相关研究 业务组合层或者称为服务组合层上的形式化方法分为形式化描述和建立在形式化 描述基础之上的形式化开发。形式化的描述就是用形式化的语言( 具有严格的语法语义 定义的语言) 做描述。形式化的软件开发，就是用形式化的语言来描述软件需求和特征， 并且通过推理验证来保证最终的软件产品是否满足这些需求和具备这些特征。这样的验 大连理工大学硕士学位论文 证当然得建立在严格的语法语义的基础之上的。形式化方法的开发目的就是希望能够提 供更好的理论、方法和工具扩大形式化方法的应用范围和使用价值。 对服务组合层形式化的意义在于它能帮助发现其它方法不容易发现的系统描述的 不一致，不明确或不完整，有助于增加软件开发人员对系统的理解，因此形式化服务组 合是提供软件系统，特别是s a f e t y - c r i t i c a l 系统的安全性与可靠性的重要手段。 服务组合的形式化能够起到的作用是多方面的： ( 1 ) 对服务组合要求的描述 服务组合要求的描述是服务组合开发的基础。比如说一般非形式化的描述很可能导 致描述的不明确和不一致。如果描述的不明确和不一致导致设计，编程的错误，将来的 修改所要付出的代价就非常大了。如果导致的错误没有被发现，则影响程序的可靠和使 用。服务组合形式化则要求描述的明确性，而描述的不一致性也就相对易于发现。 ( 2 ) 对服务问交互的描述 服务交互的描述和服务组合要求的描述一样重要。形式化方法的优点对于服务组合 要求的描述同样适用于服务组合设计的描述。另外由于有了软件要求的形式化描述，我 们可以检验软件的设计是否满足服务组合的要求。对于编程来讲，我们可以考虑自动代 码生成。对于一些简单的系统，形式化的描述有可能直接转换成可执行程序，这就简化 了开发过程，节约了资源和减少了出错的可能性。 ( 3 ) 形式化方法可以用于程序的验证，以保证程序的正确性 对于测试来讲，形式化方法可用于测试用例的自动生成，这可以节约许多时问和在 一定程度上保证侧使用例的覆盖率。 许多研究人员在s o a 框架下服务组合层的形式化工作上得到了重要的成果。h o n d a 等人提出了两种进程代数【8 9 】：一种从w s c d l 得到的灵感，另一种由p i 演算作为基础 而得来。他们形式化了这两种演算但是却没有给出他们之间的任何联系。d i j k m a n 和 d u m a s 用p e t r in e t s 来描述编排，编制和网络接口行为【1 0 l 。他们研究的重点是在一个编 制和一个给定的编排之间的关系。s c h i f a n e l l a 等人根据自动机理论定义了一个一致性的 理论，用来检验两个服务的互操作性，但是方法的局限在与只适用于两个服务的系鲥1 1 】。 还有一些其它的论文也讨论了一致性的问题【t 2 , 3 1 。前者讨论了服务行为规则的自动检 测，后者只适用于两个服务组成的系统。 1 3 各种服务组合形式化方法的比较 现在的服务组合的形式化主要分为两大阵营，基于流程的服务组合和基于人工智能 的服务组合。前者大多是研究工作流( w o r kf l o w ) 之后的一个主要的方向；后者则多来自 基于编排与编制致性的系统设计 研究s e m a n t i cw e b 领域的一个延伸。两大阵营都希望能够对流程进行形式化描述，以此 来实现流程再建模阶段的分析和验证。 在基于流程的服务组合的领域，主要是运用p e t r in e t s 和进程代数( p r o c e s sa l g e b r a ) 这两种主要的形式化方法，而在各种进程代数方法的应用中，p i 演算又是最常使用的一 种进程代数方法。在p e t r in e t s 和p ic a l c u l u s 的使用上，目前业界存在着不少的争论。 v a nd e ra a l s t 对p e t r in e t s 做了比较详细的评述【l 。三个优点分别是：首先，p e t r in e t s 是一个具有完整语义的图形化的语言，能够描述w f m c ( w o r k f l o wm a n a g e m e n t c o r p o r a t i o n ) 所定义的所有工作流的模型。其次，p e t r in e t s 是基于状态的，其它的流程 建模技术从非形式化的数据流图到形式化的进程代数都是基于行为的，而目前的工作流 管理系统正是基于状态的。另外，p e t r in e t s 还有很多分析工具。文章同样分析了p i c a l c u l u s 的不足，指出p i 演算并不能对所有的流程模型建模。p e l r in e t s 许多反对的声 音指出，使用p e t r in e t s 来描述是偏重使用流程来描述业务组合，这对于静态的业务也许 还可以行的通，但是对于动态的，大量的业务使用流程就不可行了。因为他不能支持对流 程定义的动态改变，而这一点对于动态业务组合是必须的。而p i 演算的在建模方面的最 大优点就是能有对动态的系统进行描述、推导和验证【”。”。 在基于人工智能的服务组合的领域，多应用诸如逻辑之内的语言，如描述逻辑、时 序逻辑等，主要是为了推理的需要。服务组合目前发展受到学术界和工业界两股不同力 量的推动，学术界重在借鉴人工智能的知识，如s e m a n t i c w e b 来解决服务之问的自动组 合，后者则注重服务组合以流程为基础。 在本文中，对于服务组合的建模采用了进程代数的方法。在分析了w s c d l 及 w s b p e l 的规范的基础上，针对进程内部和进程之间的基本行为定义了形式化模型。 这个模型有三个层次，分别是进程内部层、进程交互层以及服务交互层。基于这个模型 可以很好的对两种服务组合语言编排与编制建模，从而实现在s o a 框架下系统的描述、 推倒与验证。 1 4 本文的主要工作 论文作者以服务组合形式化描述、分析和验证伪主要方向，在阅读了大量的中外文 献的基础上，完成了如下的工作： ( 1 ) 介绍了编排、编制和w s b p e l 等概念； ( 2 ) 提出了一种基于外部可观察一致性的系统设计思路； ( 3 ) 给出了编排编制的形式化模型以及与w s b p e l 的映射； ( 4 ) 分析了基于互模拟理论的系统一致性原理； 大连理工大学硕士学位论文 ( 5 ) 给出了实际的案例，具体地基于外部可观察一致性原理完成了系统的描述、分 析与设计； 论文首先对实现整个系统使用的核心技术作了简要的介绍和说明。然后从对服务组 合的形式化建模出发，给出了形式化系统的语法语义以及一致性的定理。论文的后续部 分详细描述了一个具体系统的实现过程和技术细节，最后论文这个形式化框架加以总 结，并指出了需要进一步完善和扩展的工作。 基于编捧与编制一致性的系统设计 2 相关技术介绍 2 1 编排和编制 2 1 1 编排和编制的基本概念及区别 根据最近计算机科学协会的一项调查表明，大多数i t 公司的高级技术主管把电子 化地联系客户、供应商以及合作伙伴作为全球i t 管理中的首要问题。网络服务能够提 供一个基于标准的机制来解决这个问题。但是现存的问题是如今正在使用的生成业务流 的方法并没有被设计成能够跨企业进行通信的组件，而且这些方法也没有足够的灵活性 去处理网络服务的接口。 编排和编制是两种互补的服务组合语言，同过组合服务来生成业务流【仆】。这两种语 言某种程度上有所交叉，但是图2 1 从一个较高的视角表明了两者之间的关系。 编排 ( c h o r e o g r a p h y ) 嚣 请求 应答 骗 r 醌 请求 应答 图2 1 编排和编制 f i g 2 1c h o r e o g r a p h yv e r s u so m h c s t m t i o n 编排( c h o r e o g r a p h y ) 是一种可执行的业务进程，可以和内部以及外部的网络服务交 互。交互发生在信息层。交互可以包括业务逻辑和任务执行顺序，可以定义一个长久的、 事务的、多步骤的进程模型【1 9 1 。 编制( o r c h e s t r a t i o n ) 总是从一个参与者的角度去控制流程。这点不同于编排，编排 更加强调协作性，允许系统的所有参与者描述各自的交互。编排可以定义信息序列在不 大连理工大学硕士学位论文 同角色之间的交互顺序( 尤其是发生在网络服务之问的交互) ，而并不是只从一个参与者 的角度定义流程【2 0 j 。 编制关注于以一种说明性的( d e c l a r a t i v e ) 方式( 而不是编程的方式) 创建合成服务。 编制定义了组成编制的服务，以及这些服务的执行顺序( 比如并行活动、条件分支逻辑 等) 。因此，可以将编制视为一种简单的流程，这种流程自身也是一个w e b 服务。编制 流通常包括分支控制点、并行处理选择、人类响应步骤以及各种类型的预定义步骤( 例 如转换、适配器、电子邮件及w c b 服务等) 。 编排关注于定义多方如何在一个更大的业务事务中进行协作。编排通过各方描述自 己如何与其他w c b 服务进行公共消息交换来定义业务交互，而不是像编制中那样描述 一方是如何执行某个具体业务流程的。 在用编排来定义业务交互时，需要一个对业务流程在交互过程中所使用的消息交换 协议的正式描述，对在有状态的、长期运行的、涉及多方的流程中的对等的( p e e r - t o p e e r ) 消息交换( 同步的或异步的) 进行建模【2 i , 2 2 1 。 编制与编排的关键区别在于：编排是一种对等模型，业务流程中会有很多协作方； 而编制是一种层次化的请求者提供者模型，编制仅定义了应调用什么服务以及应该何 时调用，没有定义多方如何进行协作。 2 1 2 业务流程设计的要求 异步服务的调用在现今的i t 环境下是达到可靠性和可扩展性的重要因素。并发调 用服务的能力有助于提高流程的执行能力。实现一个异步的网络服务需要一个机制使得 双方的请求有着某种相关性。软件设计师常常用相关标识符来实现这种机制。 流程的结构同样需要提供一个方法去管理异常和事务性的整合。除了处理错误和超 时约束之外，编制的网络服务必须确保在持久的分布式事务中资源是可用的。传统的 a c i d ( a t o m i c i t y , c o n s i s t e n c y , i s o l a t i o na n d d u r a b i l i 劬事务已经不适用于持久运行的，分布 式的交互： ( 1 ) 原子性：这种严格的限制对于w e b 服务并不完全适用。w e b 服务合成的事务 处理复杂性在于w e b 服务的提供者及与其语义等价的其他w e b 服务的存在。比如，一个 w e b 服务的执行失败可以由与其语义等价的其他w e b 服务的执行来补偿。因此。在一个 复合w e b 服务的执行流程中的某些步骤的失败并不能确定整个流程执行的失败。 ( 2 ) 一致性：为了确保一致性，整个系统的运行必须能够被本地子系统完全监控。 但是由于w e b 服务严格的自治性及大量w e b 服务的存在使得上述的监控方法无法使用。 因此一个研究的关注点就是在w e b 服务严格自治条件下如何监控w 曲服务的一致性。 基于编挥与编制致性的系统设计 ( 3 ) 隔离性：通常情况下使用的锁定机制难以解决这个问题。不同的w e b 服务可 能支持不同的事务；某些w e b 服务根本不允许和不支持通过w e b 服务访问方式的锁定 机制；长期运行的业务任务所引起的延长的持续时间和通信延迟会使锁定资源变得是不 可行；不当的确保独立性会潜在地影响事务合成的性能。 ( 4 ) 持久性：传统的持久性在w e b 服务合成中完全需要被支持。也就是说当事务 完成其执行过程以后。即便某些步骤执行失败，它的结果也必须被持久保存下来。这一点 在w e b 服务合成中也是如此。 对a c i d 事务的各种特性进行放宽，一般通称为扩展事务( e x t e n d e dt r a n s a c t i o n s ) 。例 如，扩展事务处理模型可以将原子性放宽到允许部分参与者提交或异常终止，也可以将 隔离性放宽到允许协作用户观察部分结果。 通过作用域机制，b p e l 允许定义可在错误情况下一起被撤销的活动集。这样的活动 集是一些工作单元和一些事务。撤销己完成活动的所需操作被称为补偿处理程序 ( c o m p e n s a t i o nh a n d l 盯) 。作用域的故障处理程序可能使用补偿处理程序来撤销这个作用 域中进行的操作。在作用域中进行的活动要么已全部完成，要么全部被补偿。b p e l 提供 了以特定于应用程序的方式定义故障处理和补偿的能力，补偿处理程序允许流程的创建 者定义用于撤销一个工作单元并把数据恢复到执行该工作之前的样子的特定操作。在这 种环境中，w s t r a n s a c t i o n 规范被用来注册对l r t 实现提供的撤消通知感兴趣的参与 者。 由于被调用的w e b 服务、流程本身或网络等故障都可造成事务的终止，所以在b p e l 中补偿与故障处理机制密不可分。通过将事务封装成作用域来实现这个处理，可以将作 用域看作是一个可补偿的、可恢复的工作单元的封装。b p e l 能够在活动嵌套的不同级 别捕获并处理错误，可以在任何作用域中定义故障处理程序和补偿处理程序。有补偿处 理程序和故障处理程序的作用域可不受约束地任意深地被嵌套。 当故障在作用域中发生时，作用域中的正常处理被中断，发出的故障被传给捕获故 障的处理程序。每一个处理程序包含一个在作用域需要被补偿时运行的活动。在这样一 个处理程序中的活动必须看到容器数据与作用域完成时是一样的。由于各活动共享容器 和由w h i l e 活动引起的循环，所以支持补偿功能的正在完成中的作用域为数据保存一个 快照，以备处理程序将来可能要用到。一旦作用域成功地完成，它的补偿处理程序就已 准备好按相反的顺序被执行。 b p e l 中定义了两种补偿：显式补偿或隐式补偿。显式补偿的调用方法是使用 c o m p e n s a t 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 活动中调用。在没有显式处理程序的情况下，b p e l 提供缺省的 一1 0 大连理工大学硕士学位论文 补偿处理程序和故障处理程序。这些隐式处理程序的行为是按完成相应作用域的相反顺 序自动运行可用的补偿处理程序。 网络服务编制必须是动态、灵活并且适应性强，能够满足不断变化的业务需要。编 制引擎处理整体的流程，调用合适的网络服务，决定完成某个步骤。 2 1 3 业务流程执行语言 业务流程执行语言( b p e l ) 是为网络服务的行为在业务流程交互的领域建模。他提 供了基于x m l 的语法，用来描述在业务流中协调网络服务各参与方的控制逻辑。b p e l 的基础是w s d l 。w s d l 接口定义了具体的操作使得b p e l 决定以何种顺序组合他们。 w s d l 为每一个b p e l 流程定义了公共的入口节点和出口节点，w s d l 数据类型则描述 了流程所传递的信息。 b p e l 分为可执行的业务流程和抽象的业务流程。可执行业务流程为特定的业务交 互行为建模。抽象流程则侧重于规定不同参与者公共信息交换的协议。这种协议不可执 行，而且并不关注业务流程内部的细节。图2 2 描述了业务流程的结构。 “ 一 口 口 r广 圉园国 图2 2 业务流程结构 f i g 2 2 s t r u c t u r eo f b u s i n e s , sp r o c e s sf l o w 基于编排与编制致性的系统设计 2 1 4 网络服务编排接口和网络服务编排描述语言 w e bs e r v i c e s 编排接口( w s c i ) 是由s u n 、s a p 、b e a 以及i n t a l i o 提出，扩展了w s d l ， 定义了参与者之间的协作。w s c i 规定了系统整体编排和信息在网络服务之间的交互。 规范支持信息关联、顺序规则、异常处理、事务处理以及动态协作。 图2 3 表述了w s c l 只是描述网络服务之间的可观察的行为，他并没有声明任何可 以执行的业务流程。而且一个单独的w s c i 接口只是描述了一个参与者的信息交互。 图2 3w s c i 的协作 f i g 2 3 w s c ic o l l a b o r a t i o n w e bs e r v i c e s 编排描述语言( w s c d l ) 是继w s c i 之后出现的又一个网络服务编排 语言，于2 0 0 5 年1 1 月发布。w s c d l 的主要特性有以下几点。 ( 1 ) w s c d l 的参与者并不是局限在一个内部网中，而是分布地位于不同公司不同 站点。参与者利用网络服务来彼此通信，并把各自的公共服务接口写入w s d l 文档中。 大连理工大学硕士学位论文 ( 2 ) w s c d l 编排是全局的，但是并没有一个全局的、核心的控制引擎用以协调参 与者之间的交互操作。相反，每一个参与者都有各自的引擎来执行自己的业务流程。这 些业务流程中的交互行为要符合w s c d l 编排中的规则。 ( 3 ) 一个公司的业务流程可能有很多步骤，但是w s - c d l 只是关心外部可见的行 为。 ( 4 ) w s - c d l 并不能代替流程语言比如b p e l 、b p m l 或者x p d l 。这些语言适用 于对参与者的流程建模，而w s - c d l 适用于对全局的交互建模。 w s c d l 规范的对象模型如图2 4 所示： 图2 4w s - c d l 的对象模型 f i g 2 4w s - c d lo b j e c tm o d e l 1 3 基于编捧与编制致性的系统设计 2 2w s - b p e l 简介 w s b p e l 原名b p e l 4 w s 。是基于w s d l 建立的，除w s d l 外它还使用x m l 模 式定义、x p a t h 和w s - a d d r e s s i n g 等标准。b p e l 将微软的x l a n g 与i b m 的w s f l 连接 到一起。b p e l 的目的在于大规模编程，值得注意的是b p e l 不直接支持人机对话，b p e l 所描写的过程仅与w e b 服务通信，而这些w e b 服务却可以提供与用户的信息交换，但 它们不是用户本身。b p e l 本身提供一个基础，在这个基础上可以发展支撑新的应用的 支柱。比如在b p e l 本身的设置中就已经包括了抽象业务过程和可执行业务过程。其它 的支柱包括b p e l i 和b p e l 4 p e o p l e 。b p e l j 的目标在于将j a v a 语言结合到b p e l 中来 加速其操作过程，缺点是它与j a v a 息息相关不能没有j a v a 运行。i b m 和s a p 公司一 起发表了一份名为b p e i a p e o p l e 的白皮书，其目的是将b p e l 扩展为能够直接与人交换 信息。b p e l 使用块状结构，在定义局部环境时可以定义适用于这个环境范围内的变数。 此外故障处理、补偿处理和事故处理也可以与局部环境相连。b p e l 本身没有定义描写 过程模型的图像