正如您以前所知，面向服务架构（SOA）支持创建企业应用，并且通过利用松散耦合的、粗粒度的、业务级别的、可重用的服务来进行通信。很多标准已经推出，有些标准以平台独立方式描述这些服务（通过WSDL），有些标准用于在服务之间传递消息结构（XML Schema、XML、SOAP等）。这些服务通常根据实际业务功能来实现。

在真实世界中，大多数过程不是孤立操作的。它们的调用通常与其他服务的操作协同工作，并且有很多规则用于确定哪个服务被调用以及何时调用。例如，保险服务可能需要在购买保险之前先获得报价。在一个描述这些服务的WSDL文档中，这将不会是很明显的。

由于服务提供者的选择可能需要根据某些标准动态选择，因此服务也可能变化。所有这些变化的服务就好像舞者跳舞需要舞台一样。而且，每个舞者需要知道下一步怎样走，以及如何以舞伴期望的方式响应他的上一步。

在过去几年里，围绕SOA的许多新标准纷纷提出来处理这些问题，尤其是其他一些棘手的问题，比如可靠交付、事务支持、安全、管理和策略定义。本文将考察以下两点：注重业务流程定义的BPEL4WS，以及提供动态的与传输无关的机制来确定服务端点的WS-Addressing。

抓住合作伙伴

Web服务的业务流程执行语言（Business Process Execution Language for Web Services，BPEL4WS）提供了业务流程的正式规范，该规范以平台独立方式明确捕获组成特定流程的服务如何进行交互。它直接被WSDL（Web 服务描述语言）支持，并且利用了其中许多的概念，WSDL提供了同步或者无关异步消息的无状态定义，BPEL4WS扩展了这一点，可以定义排序、规则、有状态数据、错误处理、恢复选项和管理服务调用操作的合作伙伴关系。

WSDL和通过BPEL4WS定义的流程之间的重要关系之一就是合作伙伴关系。这种关系通常是双向会话，合作伙伴一方要么是流程使用的服务提供者，要么是流程提供的服务消费者。这种会话的双向性在异步通信环境中尤为重要。

这种合作伙伴关系通过在业务流程的BPEL4WS规范和每个进行交互的合作伙伴中定义的partnerLinkType和partnerLink来定义。应该注意的是，这些合作伙伴不必是业务合作伙伴，因为在单独的组织中，组织内部其他系统中它们通常是服务提供者，或者甚至是相同系统中的业务组件。

partnerLinkType允许在两个服务（实际上是WSDL文档中的portTypes）之间定义一个关系。每一个链接类型可以最多有两个对应于服务提供者和消费者的角色（异步或者不需要回答的服务可以只有一个）。每一个链接类型可以有多个partnerLink定义，它们定义流程在特殊关系中扮演的是提供者角色还是使用者角色，以及它们在这个关系中的实际合作伙伴是谁。这允许多个实际合作伙伴被包含在单个交易类型中（比如从许多供应商获得报价）。

这样的结果就是，合作伙伴关系有效地定义了需要被流程实现的portTypes和继承这个关系的合作伙伴。如果所有合作伙伴都按同一规范来运作，但扮演不同的角色，那么对每一个需求就不会存在多义性了。

服务有如舞蹈

一旦合作伙伴关系被定义，就需要确定与执行流程有关的步骤。BPEL4WS规范主要由显式定义服务之间的控制和数据的各种（嵌套）活动组成。

这些活动可以有多种类型，并提供了多种方法来定义流程的外部接口、与流程中服务进行通信、条件分支和迭代、连续和并发执行、错误处理机制以及修正事务的自动配置。

毕竟这是一个高级别的业务流程定义语言，能支持编程语言需要的所有必要的语法构造。任何对工作流环境熟悉的人都会发现BPEL4WS非常熟悉——分割、联接、互斥事件处理、警报和触发器全都得到支持。下图展示了一个例子，说明了BPEL4WS如何处理购买订单的流程。

这个流程从接收订单时开始。三条通道（价格计算、发运和生产）同步进行。通道间的连接等待发运信息和发运时间表。一旦所有三个通道都完成，发货单将被发送到下订单者。

大多数服务调用和相应的接收信息都是异步的。通过订单号（PO Number）、消费者号码或其他包含在消息中的简单属性，返回的异步响应与特定的购买订单流程实例关联起来。

决策和数据处理依赖于特定BPEL4WS流程所选择的表达式和查询语言。所有这些语言默认是Xpath，它需要被所有实现方式所支持，但这可以通过语言扩展来取代。

如上所述，BPEL4WS流程实例可以是有状态的。定义流程时，在消息调用传递时需要声明一组变量，并且当这个特定实例重新进入时需要维持它的状态（比如，从前一个异步调用接收到回复时）。这些变量通常是粗粒度的复杂类型，比如一个购买订单，并且这些变量使用WSDL消息或者XML模式来定义。

在典型环境中，单个流程的多个实例可以在任何时候被激活。当流程收到消息的时候，使用正确的实例（和相关的有状态数据）是最基本的。要维持这种调用之间的状态，采用了一种称为相关集合的构造。这些构造利用了简单类型（比如string、integer等）的属性来识别接收特定消息的流程的特定实例。例如，如果许多订单当前正在处理，这时收到一条表明订单已经发运的消息。该消息的订单号字段就能够用于识别在这些正处理的订单里哪一个已通知发运。

BPEL4WS流程定义是独立于执行的。也就是说它们不会规定服务实例的使用，或者数据线路格式和涉及的协议。BPEL4WS集成平台的提供者只需要支持服务选择、处理协议和数据传输。根据端点选择特定服务可以通过提供Web服务寻址(WS-Addressing)的扩展包来实现。

可以获得号码吗？

在利用WSDL的通用服务模型中，服务的端点可以通过以下方法获得：

通过WSDL文档的服务元素获得。

通过查找UDDI（统一描述、发现和集成）目录下绑定模板获得。

或者非正式地通过电子邮件、书面说明等获得。

所有这些机制导致服务和实现端点的静态绑定。在很多情况下，需要一个更加动态的模型来处理运行时配置、有状态服务和改变网络拓扑结构。

通过引入一个表示到服务端点引用的标准构造，WS-Addressing解决这些问题。每一个引用必须包含一个地址（就像URI一样，可以是物理地址或者逻辑地址），可以包含附加的属性，这些属性有助于唯一地识别出这个引用，并且也可选择指定端口类型、服务名和访问该端点的相关策略。这些引用可以是消息部分或者包含在消息头中，用于指定传给谁、来自哪里、答复谁，以及发送错误报告。

虽然WS-Addressing规范被设计用于适应各种服务的绑定（也就是说，某种通信协议上的某种数据线路格式），有关如何使用消息头的默认绑定和规范是SOAP规定的。

这些消息头的标准是互操作性和简单化设计的基本要素。地址信息总是放在相同位置（不是设计决定），并且能够用于唯一地识别服务和特定的服务实例。在跟踪特定消息时，可选的消息ID（MessageID）字段允许答复或者与错误相关。

由于地址信息包含在头部，所以消息在通信伙伴之间传递时也就能够被网络节点动态重写。这方面的例子在上一个图已经展示， 也就是Broker执行地址转换的部分。

结束语

BPEL4WS允许定义一个业务流程，在这个流程里合作伙伴需要以平台独立和实现独立的方式进行协作。有两种形式的BPEL4WS流程：抽象的和可执行的。抽象流程大多数用于保证特定流程涉及的所有合作伙伴在同一个规范下工作。它们清晰地定义了公共接口和策略，每个合作伙伴都必须紧遵循它。可执行流程可以是公共的，但是在定义私有服务执行时也非常有用。

尽管重点讨论了长期事务和会话管理，但即使是最简单的业务（复合）服务也可以用BPEL4WS来定义。由于整个流程的公共接口也由WSDL规范定义，所以很容易明白，对于较大和较复杂的流程，如何能够从细粒度但仍然复合的服务中构建。

有了WS-Addressing，这些业务流程会更具动态性。合作伙伴端点可以动态地配置，所有参与流程的各方都知道如何将消息与特定流程实例关联起来或者彼此关联起来。通过在技术领域引入一致性（以前有很多定义的方式，但不便于通过一个规范直接实现自动化），这两个标准承诺未来将改变企业管理它们业务流程的方法。