BPEL模型可以帮助我们更好地理解如何使用BPEL描述的业务流程，如图1所示。流程(Process)由一系列活动(Activity)组成;流程通过伙伴链接(Partner Link)来定义与流程交互的其他服务;服务中可以定义一些变量(Variable，在BPEL4WS中被称为Container);流程可以是有状态的长时间运行过程，流程引擎可以通过关联集合(Correlation Set)将一条消息关联到特定的流程实例。
图1 BPEL模型示意
1.伙伴(Partner)
在BPEL中，一个流程可以调用其他服务，也可以响应来自客户端的请求。也就是说BEPL流程实例既可以作为服务的请求者，也可以扮演服务的提供者。BPEL把与流程交互的其他服务称为伙伴(partner)。在异步通信环境中，流程与伙伴之间的会话可能是双向的，这在复杂的商务流程中非常常见。
在流程与伙伴的通信过程中，它们会扮演不同的角色。比如当订单流程被外部服务调用的时候，它作为“PurchaseOrderProcess”角色来提供服务，然而当它请求发货服务的时候，它则扮演“InvoicecClient”角色，如图2所示。由于在流程执行过程中，一个流程可能会调用多个伙伴服务，又可能接收多个伙伴的请求，因此为了消除在通信过程中的多义性，我们需要明确服务和流程所扮演的角色。
图2 订单流程示意
在BPEL中，这种流程与伙伴的合作关系是通过
元素来定义的。这样如果在流程的活动中需要指定与特定伙伴的交互，只需要引用partnerLink的名称即可。而且通过partner links的抽象，在流程建模时，我们不必指定具体的服务端点，而将流程与具体服务的绑定推迟到组装或运行时来完成。这种动态伙伴关系为流程带来了极大的灵活性，也增强了流程的可复用性。比如，我们在开发环境中使用的伪服务实现，在生产环境中无需须修改流程就可以将服务端点替换为主机应用。
在＜PARTNERLINK＞元素中，可以通过“myRole”和“partnerRole”属性来定义流程和伙伴的角色。如果流程作为服务的提供者，需要使用myRole属性，而当流程作为服务的请求者时，则使用partnerRole属性。
partnerLink通过引用partnerLinkType来定义流程与伙伴服务之间的通信接口(实际上是WSDL文档中的Port Type)。伙伴链接类型声明了两个(也可能是多个)服务之间的关系。服务链接类型定义了一组角色，其中每个角色指明一组Port Type，即明确了该角色所提供的服务接口。partnerLinkType通常被定义在WSDL文档中，被BPEL流程所引用。
下面的代码片段显示了如何利用partnerLink和partnerLinkType定义流程与伙伴的合作关系。我们实现了一个股票购买流程，在这个流程中需要通过伙伴StockQuote获取当前股票信息：
|
＜bpws:partnerLinks＞
＜bpws:partnerLink myRole="StockServiceRole" name="StockService" partnerLinkType ="ns:StockServicePLT"/＞
＜bpws:partnerLink name="StockQuote" partnerLinkType="ns:PartnerPLT" partnerRole ="partnerRole"/＞
…
＜/bpws:partnerLinks＞
|
我们还需要在流程对应的WSDL文档中定义partnerLinkType：
|
＜definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns: plnk="http:// schemas.xmlsoap.org/ws/2004/03/partner-link/" … ＞
＜plnk:partnerLinkType name="StockServicePLT"＞
＜plnk:role name="StockServiceRole"＞
＜plnk:portType name="wsdl0:StockService"/＞
＜/plnk:role＞
＜/plnk:partnerLinkType＞
＜plnk:partnerLinkType name="PartnerPLT"＞
＜plnk:role name="partnerRole"＞
＜plnk:portType name="ns:net.xmethods.services.stockquote. StockQuotePortType"/＞
＜/plnk:role＞
＜/plnk:partnerLinkType＞
＜import location="urn_xmethods-delayed-quotes.wsdl" namespace= "http://www. themindelectric.com/wsdl/net.xmethods.services.stockquote. StockQuote/"/＞
＜/definitions＞
|
2.变量(variables)
在BPEL中，我们可以使用变量来保存和传递流程的状态信息。变量的数据类型由WSDL定义，既可以是XML Schema内置的简单类型，又可以是自定义的复杂数据类型：
|
＜bpws:variables＞
＜bpws:variable name="symbol" type="xsd:string"/＞
＜bpws:variable name="UserInfo" type="ns1:UserInfoBO"/＞
...
＜bpws:variables＞
|
上面的代码，展示了如何在BPEL中使用元素来定义变量。值得注意的是，与常见的编程语言类似，BPEL中的变量是有作用域的;每个变量只有在定义它的作用域和所包含的作用域内才是可见的。在下面的章节中，我们将介绍如何使用BPEL来操纵和传递数据。
此外，WS-BPEL提供了一些内置的函数来支持变量内容的处理：
(1)getVariableProperty(variableName, propertyName)为获取变量属性函数：输入参数为变量名称和属性名称，结果为属性值。
(2)getVariableData(variableName, partName?, locationPath?)为获取变量数据函数：输入参数为变量名称、part名称，以及XPath表达式，其中partName，和locationPath为可选参数。输出结果为指定变量的全部或部分的数据内容。
3.活动(Activity)
BEPL流程是由一系列步骤所组成的，它们被称为活动。WS-BPEL定义了丰富的活动类型，一般来说可以把它们划分为两大类：基本活动和结构化活动。基本活动描述了流程内的一个具体步骤，比如接收请求、调用伙伴服务、变量赋值等。而结构化活动则描述了如何组织和管理流程的控制流。在下面的章节中，我们将对活动进行详细讲解。
4.关联集合(Correlation Set)
BPEL提供了声明性机制，以指定服务实例中相关联的操作组。一组相关标记可定义为相关联的组中所有消息共享的一组特性。这样的一组特性称为关联集合。每个关联集都在一个作用域中进行声明并属于该作用域。属于全局流程作用域的关联集称为全局关联集;属于局部作用域的关联集称为局部关联集。在流程开始时，全局关联集处于未初始化的状态。在其所属的作用域的执行开始时，局部关联集处于未初始化的状态。
相关集在其语义上类似于延迟绑定的常数。相关集的绑定由特别标记的消息发送或接收操作来触发。相关集在其所属的作用域的生存期中只能初始化一次。在初始化之后，它的值就可被认为是业务流程实例的标识别名。在多方业务协议中，相关集合非常有用。初始者流程发送启动会话的第一个消息，从而定义了标记该对话的相关集中的特性值。所有其他参与者通过接收提供相关集中的特性值的传入消息来绑定会话中的相关集。比如一个旅行社订票流程，当该流程启动之后，用户需要能够查询该流程状态，并能取消该流程，这就需要相关集的支持来确保后续的请求消息绑定到相同的流程实例中。
