《BPEL4WS规范v1.0（Web 服务的业务流程执行语言）.doc》由会员分享，可在线阅读，更多相关《BPEL4WS规范v1.0（Web 服务的业务流程执行语言）.doc（101页珍藏版）》请在三一办公上搜索。
1、Web 服务的业务流程执行语言（BPEL4WSBusiness Process Execution Language for Web Services）版本 1.02002 年 8 月 9 日作者（按字母顺序）：Francisco Curbera，IBMYaron Goland，BEA SystemsJohannes Klein，MicrosoftFrank Leymann，IBMDieter Roller，IBMSatish Thatte，Microsoft（编辑）Sanjiva Weerawarana，IBM 整理：langway 电子邮件：langway2000Copyright 200
2、1-2002 BEA Systems, International Business Machines Corporation, Microsoft Corporation, Inc. All rights reserved.提供、分发或以其它方式传播本规范所包含的信息并未授予您使用 IBM 或 Microsoft 或 BEA 和或任何其它第三方所拥有或控制的知识产权的许可证（无论是明示的还是默示的）。IBM、Microsoft、BEA 和或任何其它第三方可能拥有与本文档内容有关的各项专利权、专利应用权、商标权、版权或其它知识产权。提供本文档并未授予用户使用 IBM 或 Microsoft 或
3、 BEA 或任何其它第三方的专利、商标、版权或其它知识产权的任何许可证。此处举例所用的公司、组织、产品、域名、电子邮件地址、徽标、人员、地点和事件均属虚构。无意也不应推测为与任何真实的公司、组织、产品、域名、电子邮件地址、徽标、人员、地点或事件有任何关联。此处包含的规范和信息以“按现状”的基础提供，并在适用法律许可的最大范围内被允许，IBM 和 Microsoft 和 BEA 以“按现状并可能存在各种错误”的基础提供本文档，特此声明免除所有（无论是明示的、默示的，还是法定的）其它保证和条件，包括（但不限于）对与本文档有关的适销性、适用于某特定用途、响应的准确性或完整性、结果、技艺精湛的成果、无
4、病毒和无疏忽的默示保证、责任或条件（如果有的话）。此外，对所有权、平静享用、平静占有、与描述相符或与本文档有关的知识产权的非侵权性不提供任何保证或条件。在任何情况下，IBM 或 MICROSOFT 或 BEA 都不对任何其它方获取替代产品或服务的费用、利润损失、使用损失、数据丢失、或者任何意外的、有连带关系的、直接的、间接的或特殊的损害负责，不管这类损害是由合同、侵权或保证引起的，还是由此外的方式或与本文档有关的任何其它协定引起的，也不管该方是否已被预先告知可能发生这类损害。摘要本文为指定基于 Web 服务的业务流程行为定义了一种表示方法。这种表示方法被称为 Web 服务的业务流程执行语言（B
5、usiness Process Execution Language for Web Services）（以下简称为 BPEL4WS）。用 BPEL4WS 表示的流程只能通过使用 Web 服务接口来导出和导入功能。描述业务流程的方式有两种。可执行业务流程可以模拟业务交互中的参与者的实际行为。相对而言，业务协议使用流程描述来指定涉及协议的每一方能相互看到的消息交换行为，但并不公开他们的内部行为。业务协议的流程描述被称为抽象流程。BPEL4WS 应被用来模拟可执行流程和抽象流程的行为。BPEL4WS 提供了正式指定业务流程和业务交互协议的语言。这样做是为了扩展 Web 服务交互模型并使它支持业务事
6、务。BPEL4WS 所定义的可互操作的集成模型应该能够促进在企业内和企业间的自动流程集成的扩展。状态这里发布的是 BPEL4WS 规范的最初的公开草案。我们期待着不少扩展被增加到 BPEL4WS 的功能集（在本文的末尾将简要地讨论这些扩展）。BPEL4WS 代表了 XLANG 和 WSFL 规范中的概念的融合。BPEL4WS 规范取代了 XLANG 和 WSFL。BPEL4WS 和相关规范以“按现状”的基础提供，仅供审阅和评估。IBM、Microsoft 和 BEA 希望在不久的将来向您征稿，并得到您的建议。IBM、Microsoft 和 BEA 都不以任何方式作出关于这些规范的保证或表示。目
7、 录1. 引言6-72. 词语约定83. 与 WSDL 的关系94. 定义业务流程10-244.1. 第一个示例10-164.2. 业务流程的结构16-224.3. 语言的可扩展性22-234.4. 业务流程的生命周期23-245. 服务链接、伙伴和服务引用25-285.1. 服务链接25-265.2. 伙伴26-275.3. 服务引用27-286. 消息属性29-306.1. 动机296.2. 定义属性29-307. 相关性31-367.1. 消息相关性31-327.2. 定义和使用相关集32-368. 数据处理37-438.1. 表达式37-398.1.1. 布尔表达式388.1.2. 值
8、为截止期限的表达式388.1.3. 值为持续时间的表达式388.1.4. 一般表达式38-398.2. 容器39-408.3. 赋值40-438.3.1. 赋值的原子性428.3.2. 赋值示例42-438.4. 抽象流程与可执行流程间的差别总结439. 基本活动44-489.1. 每个活动的标准属性449.2. 每个活动的标准元素449.3. 调用 Web 服务操作44-459.4. 提供 Web 服务操作469.5. 更新容器内容479.6. 发出故障信号479.7. 终止服务实例479.8. 等待47-489.9. 不做任何事4810. 结构化的活动49-5710.1. Sequence
9、4910.2. Switch5010.3. While5010.4. Pick51-5210.5. Flow52-5710.5.1. 链接语义5410.5.2. 死路删除（Dead-Path-Elimination，DPE）54-5510.5.3. Flow 图的示例55-5610.5.4. 链接和结构化的活动56-5711. 作用域58-6511.1. 业务流程中的错误处理5911.2. 补偿处理程序59-6211.2.1. 定义补偿处理程序59-6111.2.2. 调用补偿处理程序61-6211.3. 故障处理程序62-6511.3.1. 隐式故障处理程序和补偿处理程序63-6411.3.
10、2. 活动终止的语义6411.3.3. 故障处理程序和补偿处理程序中的故障处理64-6511.4. 可序列化的作用域6512. 示例66-8112.1. 运输服务66-7012.1.1. 服务描述6612.1.2. 消息属性67-6812.1.3. 流程68-7012.2. 贷款审批71-7412.2.1. 服务描述71-7212.2.2. 流程72-7412.3. 多个启动活动75-8112.3.1. 服务描述75-7712.3.2. 流程77-8113. 未来的发展方向 82-8313.1. 作用域82-8313.1.1. 容器8213.1.2. 事件处理程序8213.1.3. 重叠作用域
11、8213.1.4. 原子作用域8213.1.5. 补偿82-8313.2. 生命周期和查询8313.2.1. 暂挂恢复8313.2.2. 查询8313.3. 服务组成8313.4. 与 WS-Transaction 规范的关系8314. 安全性注意事项8415. 致谢8416. 参考资料84附录 A 标准故障85附录 B 属性和缺省值86附录 C 协调协议87-88BPEL4WS 作用域的协调协议附录 D - XSD 模式89-101BPEL4WS 模式89-99服务链接类型模式99-100服务引用模式100消息属性模式100-1011. 引言Web 服务的努力目标是通过使用 Web 标准实现
12、应用程序间的通用的互操作性。Web 服务使用松散耦合的集成模型以支持各种领域（包括企业到消费者、企业到企业和企业应用程序集成）中的各种系统的灵活集成。以下基本规范最初定义了 Web 服务空间：SOAP、Web 服务描述语言（Web Services Description Language，WSDL）和统一描述、发现和集成（Universal Description，Discovery，and Integration，UDDI）。SOAP 为基本服务的互操作性定义了 XML 消息传递协议。WSDL 采用了用于描述服务的公共语法。UDDI 为系统地发布和发现服务提供了所需的基础结构。这些规范共同
13、使应用程序遵循一个松散耦合、与平台无关的模型来找到对方并进行交互。系统集成需要的不仅仅是通过使用标准协议来进行简单交互的能力。仅当应用程序和业务流程能够通过使用标准流程集成模型来集成复杂的交互时才能发挥 Web 服务作为集成平台的全部潜力。WSDL 所直接支持的交互模型仅仅是同步或不相关的异步交互的无状态模型。业务交互的模型通常假设在涉及双方或多方的有状态的长期运行的交互中的同步和异步对等消息交换序列。为了定义这种业务交互，需要对业务流程在其交互中所用的消息交换协议的正式描述。这种业务协议的定义涉及准确地指定涉及协议的每一方都能相互看到的消息交换行为但并不公开它们的内部实现。出于两个原因，需要
14、把业务流程行为分为公共部分和内部部分（或私有部分）。一个原因是企业显然不想让它的业务伙伴知道它的所有的内部决策和数据管理。另一个原因是（即便并不是这种情况）通过把公共流程和私有流程分开，您能够改变流程实现的私有部分而不会影响到公共业务协议。必须用平台无关的方式来明确地描述业务协议，业务协议必须包括在跨企业业务中的所有重要行为部分。这样，每位参与者可以理解业务协议并为遵守它而做准备，每位参与者不必进行人工协商，目前，人工协商的过程大大增加了建立跨企业自动业务流程的难度。描述业务协议需要哪些概念？这些概念与描述可执行流程所需的概念之间是什么关系？为了回答这些问题，请从以下几个方面来考虑： 业务协议
15、总是包括数据相关的行为。例如，供应链协议依赖于这样的数据：定单中的单项产品的数量、定单的总价或交付的截止期限。在这些情况下定义业务目的需要使用条件和超时构造。 对于业务协议来说，指定异常条件及其后果（包括恢复序列）的能力至少与定义“一切正常运行”时的行为的能力一样重要。 长期运行的交互包括多个工作单元，这些单元常常是嵌套的，每个单元有自己的数据要求。业务协议常常要求颗粒度不同的工作单元的结果（成功或失败）的跨伙伴协调。 如果我们想为跨企业业务协议提供准确的可预测的服务行为描述，那么我们需要一种丰富的流程描述表示方法，它的许多特点使我们想起了可执行语言。公共消息交换协议与可执行内部流程的主要区别
16、是内部流程用丰富的私有方式来处理数据，但在公共协议中并不需要描述这些数据。在考虑业务协议的数据处理部分时，对比网络通信协议和业务协议是有益的。网络协议定义了在通信线路上传输的协议信封的形式和内容，这些协议所描述的协议行为完全由这些信封中的数据来决定。换句话说，在有关协议的数据和“有效负载”数据之间存在清楚的物理分界线。在业务协议中，这种分界线是模糊的，这是因为有关协议的数据往往被嵌入在其它应用程序数据中。BPEL4WS 使用消息属性这个概念来识别嵌入在消息中的有关协议的数据。属性可被看作有关公共部分的“透明的”数据，与之相对的是内部私有函数使用的“不透明的”数据。透明的数据直接影响公共业务协议
17、，不透明的数据主要是对后端系统有重要意义，它影响业务协议的唯一方式是产生不确定性，因为它影响决定的方式是不透明的。我们的原则是被用来影响业务协议的行为的任何数据必须是透明的，所以必须被视为属性。不透明的数据的隐式影响表现为涉及业务协议的服务行为中的不确定性。请考虑购买协议的示例。卖方的服务接收购买定单并根据多个标准（包括商品是否有货和买方的信用）做出接受或拒绝的响应。显然，决定过程是不透明的，但是决定的事实必须在外部业务协议中作为行为的多种选择被反映出来。换句话说，协议要求在卖方的服务行为中有类似 switch 活动的东西但分支的选择是不确定的。通过把不确定的或不透明的值（通常是从可能的值的枚
18、举集中选出）赋给消息属性，可以模拟这种不确定性。这样，属性可被用于定义表示各种行为选择的条件行为而不公开实际决策过程。为了表示公共行为的本质同时隐藏私有部分，BPEL4WS 显式地允许使用不确定的数值。定义业务协议和定义可执行业务流程所需的概念非常相似。定义业务协议所需的概念和定义可执行业务流程的所需的概念组成了统一体，BPEL4WS 被设计成包括这个统一体。BPEL4WS 所定义的模型和语法可被用于描述基于流程和它的伙伴间的交互的业务流程的行为。与每个伙伴的交互是通过 Web 服务接口进行的，在接口级别上关系的结构被封装在我们称之为的服务链接中。BPEL4WS 流程定义了与这些伙伴交互的多个
19、服务交互是怎样协调的以达到业务目的，还定义了这种协调所需的状态和逻辑。BPEL4WS 还引入了一些系统的机制来处理业务异常和流程处理故障。最后，BPEL4WS 引入了一种机制，以用于定义在发生异常时或伙伴请求撤销时流程中单个或合成活动是怎样被补偿的。应用 BPEL4WS 的基本概念的方式有两种。通过使用抽象流程概念，BPEL4WS 流程可以定义业务协议角色。例如，在供应链协议中，买卖双方是两个不同的角色，双方都有自己的抽象流程。他们的关系通常被模拟成服务链接。抽象流程使用所有的 BPEL4WS 概念但它对待数据处理的方式反映了描述业务协议公共部分所需的抽象程度。具体地说，抽象流程仅处理有关协议
20、的数据。BPEL4WS 提供了把有关协议的数据识别为消息属性的方式。另外，抽象流程使用不确定的数值来隐藏行为的私有部分。BPEL4WS 也可被用来定义可执行业务流程。流程的逻辑和状态决定了在每个业务伙伴那里进行的 Web 服务交互的性质和顺序，从而决定了交互协议。虽然从私有实现的角度来看并不需要完整地定义 BPEL4WS 流程，但是 BPEL4WS 为仅依赖于 Web 服务资源和 XML 数据的业务流程有效地定义了可移植的执行格式。此外，这种流程的执行以及与它们的伙伴交互的方式是一致的，与托管环境的实现所用的支持平台或编程模型无关。即便在私有实现部分使用平台相关的功能的情况下（这在许多情况下是
21、很有可能的，在多数的实际情况下更有可能），BPEL4WS 中抽象流程和可执行流程间的基本概念的模型的连续性可能将包含在业务协议中的公共部分作为流程或角色模板进行输出和输入，同时保持协议的目的和结构。从充分利用 Web 服务的角度来看，可以论证这是使用 BPEL4WS 的最有吸引力的前景，因为它支持大大提高自动化程度的工具和其它技术的开发从而降低了建立跨企业自动的业务流程的成本。BPEL4WS 位于几个 XML 规范之上：WSDL 1.1、XML Schema 1.0 和 XPath1.0。WSDL 消息和 XML Schema 类型定义提供了 BPEL4WS 流程所用的数据模型。XPath 为
22、数据处理提供支持。所有的外部资源和伙伴被表示成 WSDL 服务。BPEL4WS 所提供的可扩展性能支持这些标准的未来版本，即用于 XML 计算的 XPath 和相关标准。2. 词语约定本文中的关键字“必须（MUST）”、“绝不可以（MUST NOT）”、“需要的（REQUIRED）”、“应该（SHALL）”、“将不（SHALL NOT）”、“应该（SHOULD）”、“不应该（SHOULD NOT）”、“推荐的（RECOMMENDED）”、“可以（MAY）”和“可选的（OPTIONAL）”将按 RFC2119 13 中的描述来解释。名称空间 URI（常规形式是“some-URI”）表示 RFC2
23、396 14 中定义的与应用程序相关或与内容相关的某个 URI。本规范使用非正式的语法来描述 XML 片段的 XML 语法，如下： 本语法以 XML 实例的形式出现，但其中的值代表数据类型而不是值。 粗体显示的语法是还未在本文中介绍过的语法，或在示例中有特别的意义。 是某些“其它”名称空间的元素的占位符（象 XSD 中的 #other）。 字符按以下方式被附加到元素、属性和 ：“?”（0 个或 1 个）、“*”（0 个或更多个）、“+”（1 个或更多个）。字符“”和“”用以表示所包含的项应作为一个与“?”、“*”或“+”字符有关的组被处理。 被“|”分隔且被“(”和“)”并排在一起的元素和属性
24、应被理解为语法的候选式。 XML 名称空间前缀（在下文中定义）被用来指出被定义的元素的名称空间。 以 ?xml 开头的示例包含足够的信息，这些示例符合本规范；其它示例是片断，需指定更多信息才能符合本规范。 所提供的 XSD schema 和 WSDL 定义是语法的正式定义 xml-schema1WSDL。3. 与 WSDL 的关系BPEL4WS 依赖于以下基于 XML 的规范：WSDL 1.1、XML Schema 1.0 和 XPath 1.0。在这些规范中，WSDL 对 BPEL4WS 语言的影响最大。BPEL4WS 流程模型位于由 WSDL 1.1 所定义的服务模型之上。位于 BPEL4
25、WS 流程模型核心的是由 WSDL 描述的服务间的对等交互概念；流程及其伙伴都被建模成 WSDL 服务。业务流程定义了怎样协调流程实例与它的伙伴间的交互。在这个意义上，一个 BPEL4WS 流程定义提供和或使用一个或多个 WSDL 服务，还通过 Web 服务接口提供流程实例相对于它的伙伴和资源的行为和交互的描述。也就是说，BPEL4WS 定义了交互中某个角色的业务流程遵守的消息交换协议。BPEL4WS 业务流程的定义也遵循 WSDL 的分离模型，即把业务流程使用的抽象消息内容与部署信息（消息和 portType 与绑定和地址信息）分开。具体地说，BPEL4WS 流程用抽象 WSDL 接口（po
26、rtType 和操作）来表示所有的伙伴以及与这些伙伴的交互；它并不引用流程实例使用的实际服务。BPEL4WS 流程是可重用的定义，可以不同的方式在不同的情况下被部署同时在它们之间保持一致的应用程序级别的行为。请注意，BPEL4WS 流程的部署的描述超出了本规范的范围。4. 定义业务流程描述业务流程的方式有两种。可执行业务流程模拟业务交互中的参与者的实际行为。在可执行流程中，并不把业务流程分成从外部可看见的（或者说“公共”）部分和内部部分。相对而言，业务协议使用的流程描述指定了涉及协议的每一方的相互可以看见的消息交换行为并隐藏它们的内部行为。涉及业务协议的流程被称为抽象流程。一般来说，抽象流程是
27、不可执行的。它们应被用来耦合 Web 服务接口定义与行为规范，这些行为规范既被用于约束业务角色的实现，也被用于以准确的词汇来定义业务协议中的每一方可以期望的对方行为。BPEL4WS 应被用来定义这两种流程。两者之间的差异仅限于这两种流程中用于数据处理的不同功能集。在数据处理这一节中，这些差异被准确地定义。4.1. 第一个示例在详细描述业务流程的结构之前，这一节先讲述一个用于处理购买定单的 BPEL4WS 流程的简单的示例。这样做的目的是为了介绍 BPEL4WS 的最基本的结构和一些基本概念。这个很简单的流程操作被表示在下图中。带点的线表示序列。任意地把序列组成一组表示并发的序列。实心箭头表示用
28、于并发活动间的同步的控制链接。请注意这张图并不是 BPEL4WS 流程的正式图解表示法。这张非正式的图被用来帮助读者理解。当收到客户的购买定单后，流程初始化三个并行的任务：计算定单的最终价格、选择承运人以及为定单安排生产和运输。虽然有些处理可以并行地进行，但是三个任务之间存在相互依赖的控制和数据。具体地说，在计算最终价格时需要运输价格，在全面安排实现计划时需要运输日期。在完成这三个任务后就可以开始处理发票并把发票交给客户。在下面的 WSDL 文档中显示了由服务提供给它的客户的 WSDL portType（purchaseOrderPT）。为了简单起见，业务流程所需的其它 WSDL 定义被包含在
29、同一个 WSDL 文档中；具体地说，该文档还定义了一些 Web 服务的 portTypes，这些 Web 服务提供价格计算、运输选择和调度以及生产调度功能。请注意在 WSDL 文档中没有 bindings 或 service 元素。通过仅仅引用涉及流程的服务的 portType 并且不引用它们可能的部署，BPEL4WS 流程被“抽象地”定义。以这种方式定义的业务流程允许在兼容的服务的多次部署中再次使用业务流程定义。在 WSDL 文档末尾的服务链接类型表示购买定单服务和与之交互的每一方的交互（请参阅服务链接、伙伴和服务引用）。无论 BPEL4WS 业务流程是为一种还是多种服务而定义的，服务链接类
30、型可被用来表示这些服务间的依赖关系。每个服务链接类型最多可定义两个“角色”名称并列出每个角色必须支持的 portType 以便交互被成功执行。在这个示例中，“purchaseLT”链接类型和“schedulingLT”链接类型仅列出一个角色，这是因为在相应的服务交互中，其中的一方提供了所有的被调用操作：“purchaseLT”服务链接表示流程与请求客户之间的连接，其中只有购买定单服务需要提供服务操作（“sendPurchaseOrder”）；“schedulingLT”服务链接表示购买定单服务与时间安排服务间的交互，其中只有后者的操作才被调用。其它两个服务链接类型“invoiceLT”和“sh
31、ippingLT”定义了两个角色，这是因为发票计算的用户和运输服务（发票或运输安排）的用户都必须提供回调操作以使异步通知被异步地发送（“invoiceCallbackPT”portType 和“shippingCallbackPT”portType）。 接下来定义定单服务的业务流程。在这个流程定义中有四个主要部分： 部分定义了流程使用的数据容器，用 WSDL 消息类型来提供它们的定义。容器使流程可以根据被交换的消息保存状态数据和流程历史。 部分定义了在处理定单期间与业务流程交互的各方。其中的四个伙伴对应于定单的发送方（customer）、价格的提供者（invoiceProvider）、承运人（
32、shippingProvider）和生产调度服务（schedulingProvider）。服务链接类型和角色名称描述了每个伙伴。这些信息标识了业务流程和伙伴必须提供以使该关系成功的功能，也就是购买定单流程和伙伴需要实现的 portType。 部分所包含的故障处理程序定义了在对调用评估和批准服务所产生的故障作出响应时必须执行的活动。在 BPEL4WS 中，无论是内部故障还是服务调用所产生的故障都由限定名称来标识。具体地说，在 BPEL4WS 中，用来标识每个 WSDL 故障的限定名称由包含相关 portType 定义和故障定义的 WSDL 文档的目标名称空间和故障的 ncname 组成。然而，值得注意的是，由于 WSDL 1.1 并不要求故障名称在操作被定义的名称空间中是唯一的，所以无法区分所有共享相同名称且被定义在相同名称空间中的故障。尽管 WSDL 有这样严重的限制，BPEL4WS 还是为故障提供了统一的命名模型，希望 WSDL 的未来版本会提供更好的故障命名模型。 余下的流程定义包含购买请求的正常执行的描述。在流程定义之后的部分中将解释这些描述的主要元素。 partner name=customer serviceLinkType=lns:purchaseLT
