現代業務流程管理系統的曆史可以追溯到工作流系統。簡單地來講，工作流定義了業務流程中的參與者(Who)、所執行的工作(What)及何時執行(When)。在企業IT環境中，工作流軟體通常與企業應用內建(Enterprise Application Integration，EAI)系統結合在一起，成為企業應用的“黏合劑”，實作業務流程的自動化和流水線化。
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提供了聲明性機制，以指定服務執行個體中相關聯的操作組。一組相關标記可定義為相關聯的組中所有消息共享的一組特性。這樣的一組特性稱為關聯集合。每個關聯集都在一個作用域中進行聲明并屬于該作用域。屬于全局流程作用域的關聯集稱為全局關聯集;屬于局部作用域的關聯集稱為局部關聯集。在流程開始時，全局關聯集處于未初始化的狀态。在其所屬的作用域的執行開始時，局部關聯集處于未初始化的狀态。
相關集在其語義上類似于延遲綁定的常數。相關集的綁定由特别标記的消息發送或接收操作來觸發。相關集在其所屬的作用域的生存期中隻能初始化一次。在初始化之後，它的值就可被認為是業務流程執行個體的辨別别名。在多方業務協定中，相關集合非常有用。初始者流程發送啟動會話的第一個消息，進而定義了标記該對話的相關集中的特性值。所有其他參與者通過接收提供相關集中的特性值的傳入消息來綁定會話中的相關集。比如一個旅行社訂票流程，當該流程啟動之後，使用者需要能夠查詢該流程狀态，并能取消該流程，這就需要相關集的支援來確定後續的請求消息綁定到相同的流程執行個體中。