BPEL 简明开发手册(7)

在eventHandlers中，onMessage和onAlarm两者之和至少要存在一个。

A. onMessage* ：0个或多个onMessage分支组成的事件信息，各个onMessage不互相排斥，包含的

属性如下：

一、 partnerLink=\： 描述两个web services之间接口关系； 二、 portType=\： 端口类型； 三、 operation=\： 调用操作； 四、 variable=\： 变量； 五、 相关集

?

相关集属性组：correlation：单个相关集；set=“ncname”：相关集集合名称；initiation：是否实例化该相关集，值为yes时，相关集被实例化，为no时，不实例化。缺省值为no。 六、 activity 嵌套在onMessage里的活动；

B. onAlarm* ：0个或多个onAlarm组成的警报事件组，当onMessage触发时，onAlarm就 不再被执

行，包含的属性如下：

一、 for=\： 警报的时间长度，是一个长度表达式； 二、 until=\： 警报的时间点； 三、 activity ： 嵌套在onAlarm里的活动；

其中，时间长度和时间点两个只有一个存在，用时间长度表达则不存在时间点表达，反之亦然。

7. Activity： 嵌套在scope内的活动，这个是唯一的，但是activity里面是可以嵌套的。

作用域scope 可以提供故障处理程序、补偿处理程序、事件处理程序和数据变量。整个流程process也可以定义为一个scope。scope里的元素是可选的。每个scope 有一个定义它的正常行为的主要活动。该主要活动可以是一个基元活动，也可以是一个复杂的结构化的活动，其中有任意深度的嵌套的活动。所有的嵌套的活动都共享该 scope。scope活动执行的过程中，如果有异常，则在异常处理程序里进行处理；如果异常处理程序中又抛出异常，则把异常向外层作用域抛出。

通过以上活动(Activity)的学习，对BPEL的基础知识应该有了比较详细的了解。BPEL主要就是由这些Activity组成的。 项目名称： 版本：<0.1> 文档名称：BPEL 简明开发手册 日期：<2006/11/25> 文档创建者：Sika Team 公司机密文件，请勿外漏

6. 合作伙伴链接类型、合作伙伴、服务引用

BPEL4WS 的很重要（可能也是最重要）的用例是描述跨企业业务交互，在这种交互中，每个企业的业务流程通过 Web 服务接口与其它企业的流程交互。为了在这种环境中真实地模拟业务流程的进行，一个重要的要求是模拟伙伴流程的能力。WSDL 已能在抽象级别和具体级别上描述由伙伴提供的服务的功能。业务流程与伙伴的关系通常是对等的，这需要在服务级别上有双向的相关性。换句话说，伙伴表示由业务流程提供的服务的消费者，同时，对于业务流程来说，伙伴又表示服务的提供者。这种情况的典型例子是基于异步消息传递（而不是基于远程过程调用）的交互。服务链接这个概念被用来直接模拟对等伙伴关系。为了定义与伙伴的关系的形式，服务链接定义了在交互的两个方向上用到的消息和端口类型。然而，实际的伙伴服务可以在流程中被动态的确定。为了表示描述伙伴服务所需的动态数据，BPEL4WS 定义了服务引用这个概念。

在这里有必要强调所用的服务链接概念和服务引用概念是初步的。目前，这些与 Web 服务相关的概念还没有广泛接受的规范，我们期待着在将来出现这些概念的标准定义。为了符合预期的未来标准，BPEL4WS 规范将被相应地更新。 合作伙伴链接

为了描述两个服务间的关系，服务链接类型定义了关系中每个服务所扮演的“角色”并指定每个角色所提供的 portType。下面举例说明服务链接类型声明的基本语法：

每个角色可以包括任意个 WSDL portType。

在常见的情况中，每个角色的 portType 产生于不同的名称空间。然而在有些情况下可以用来自相同名称空间的 portType 来定义服务链接类型的两个角色。在服务间定义“回调”关系的服务链接类型就会出现后一种情况。

服务链接类型定义可以是独立于任一个服务的 WSDL 文档的单独的构件。服务链接类型定义也可以被放在定义 portType 的 WSDL 文档中，这些 portType 也被用来定义不同的角色。

WSDL 1.1 的扩展机制被用来把 serviceLinkType 定义为新的定义类型并且在所有的情况下都是作为

元素的直接子元素被放置。这是为了支持 WSDL 目标名称空间规范的再利用，更为重要的是，也是为了支持导入 portType 的导入机制。如果服务链接类型声明链接了两个不同服务的 portType，那么服务链接类型声明可以被放在单独的（有自己的 targetNamespace 的）WSDL 文档中。

定义服务链接类型的语法如下： Page 33 6.1 项目名称： 版本：<0.1> 文档名称：BPEL 简明开发手册 日期：<2006/11/25> 文档创建者：Sika Team 公司机密文件，请勿外漏

以上定义了服务链接类型，其名称空间是 WSDL 文档元素的“targetNamespace”属性值。正如引用所有顶层 WSDL 定义那样，通过使用 QNames 来引用标识在 中的 portType。

请注意，在有些情况下定义包含一个角色（而不是两个角色）的服务链接类型是有意义的。在这种服务链接情形中，一个服务愿意链接任何其它服务而不对其它服务提出任何要求。

您可以在本规范中的各种业务流程示例中找到 partnerLinkType 声明的示例。 伙伴链接

在 BPEL4WS 中，与业务流程交互的服务被模拟成伙伴。每个伙伴由 partnerLinkType 来描述。同一个 partnerLinkType可以描述多个伙伴。例如，某个采购流程可以在它的事务中使用多个供应商，但是对于所有的供应商都使用相同的 partnerLinkType。

每个伙伴被命名，这个名称被用于与这个伙伴的所有服务交互。这一点很重要，例如，为了多个同时产生的同一种请求而使响应与不同的伙伴相关。属性 myRole 指出了业务流程的角色而属性， partnerRole 指出了伙伴的角色。 服务引用

WSDL 严格地区分 portType 和端口。PortType 使用抽象消息来定义抽象功能。端口提供实际访问信息，包括通信端点和（通过使用扩展元素）其它有关部署的信息（例如用于加密的公钥）。绑定使两者连结在一起。虽然服务的用户必须静态地依赖于由 portType 定义的抽象接口，但是在通常情况下可以动态地发现和使用包括在端口定义中的信息。

服务引用的基本用途是作为一种机制，用于服务的特定于端口的数据的动态通信。服务引用使您能在

Page 34 项目名称： 版本：<0.1> 文档名称：BPEL 简明开发手册 日期：<2006/11/25> 文档创建者：Sika Team 公司机密文件，请勿外漏

BPEL4WS 中动态地为某个服务类型选择提供者和调用它们的操作。BPEL4WS 提供使消息与服务的有状态实例相关的一般机制，所以携带中立于实例间的端口信息的服务引用在多数情况下是足够的。然而，一般来说，有必要在服务引用本身中携带额外的实例标识标记。

服务引用的语法结构是：

服务引用是 元素的限定名，其中的元素要么被直接插入在服务引用中，要么可以假定服务引用的接收方已经知晓该元素。以下是服务引用的最简单的示例：

如果不能假设服务可通过引用已被知晓，那么它的定义可被直接插入在服务引用中，以动态地表示 WSDL 文档的服务定义部分

本手册只是一个简明的参考手册，如果要研究BPEL或相关方面的内容，建议去读BPEL规范手册。 Page 35 项目名称： 版本：<0.1> 文档名称：BPEL 简明开发手册 日期：<2006/11/25> 文档创建者：Sika Team 公司机密文件，请勿外漏 Page 36

7. 参考手册

1. W3C 推荐“XML 规范”

2. W3C 纪要“Simple Object Access Protocol (SOAP) 1.1”

3. W3C 纪要“Web Services Description Language (WSDL) 1.1” 4. 业界倡议“Universal Description, Discovery and Integration 5. XLANG：Web Services for Business Process Design 6. WSFL：Web Services Flow Language 1.0

7. W3C 提议的推荐“XML Schema Part 1: Structures” 8. W3C 提议的推荐“XML Schema Part 2: Datatypes” 9. W3C 推荐“XML Path Language (XPath) Version 1.0”

百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说综合文库BPEL 简明开发手册(7)在线全文阅读。