以下WS-BPEL Element皆以 2.0版本做說明。
| 類別 | 包含的元素 |
| 與後端系統的互動 | <partnerLinks> / <partnerLinkType> <correlationSet> <variables> <messageExchange> |
| 服務之間互動的基本活動 | <receive> / <reply> <invoke> |
| 事件處理 | <eventHandler> <onEvent> <pick> <onMessage> <onAlarm> <wait> |
| 資料處理的活動 | <assign> <validate> |
| 結構化流程控制的活動 | <sequence> <flow> <while> <if> / <else> <repeatUntil> <forEach> |
| 異常處理及恢復 | <throw> / <rethrow> <faultHandlers> <catch> / <catchall> <compensationHandlers> <compensate> / <compensateScope> <terminationHandlers> |
| 擴展及其他 | <empty> <exit> <scope> <extensionAssignOperation> <extensionActivity> <import> <documentation> |
基於上述這些的分類內容，我僅將書上提到的一些簡單範例與使用時機介紹做些筆記：
- 夥伴連結( partnerLink / partnerLinkType)
業務流程一般都會涉及其他服務的互動，在BPEL中這種互動關係是通過定義partnerLink / partnerLinkType來實現的。
partnerLinkType 定義了服務在互動中扮演的角色，並為角色指定了 portType，每一個角色對應WSDL中的一個 portType，參考以下範例：
<plnk:partnerLinkType xmlns:plnk="http://docs.oasisopen.org/wsbpel/2.0/plnktype"
name="EBayLT">
<plnk:role name="EBaySearchProvider" portType="ns:ShoppingInterface" />
</plnk:partnerLinkType>
利用WSDL 1.1 提供的擴展性，partnerLinkType在 WSDL檔中被直接定義為<wsdl:definitions>的子元素，它既可以和portType一起定義在WSDL文件中，也可以先在單獨的WSDL檔中定義，然後再導入到定義了 portType的 WSDL文件中。
partnerLink在 WSBPEL中代表與流程互動的服務，它是通過partnerLinkType定義的，類似於partnerLinkType的實例。
partnerLink有兩個重要的屬性 - myRole , partnerRole，其中myRole定義的是流程在互動中所扮演的角色，partnerRole則定義了互動中伙伴連結服務所扮演的角色。myRole和partnerRole至少有一個要被指定，以下是範例參考。
<partnerLinks>
<partnerLink name-"NCName" partnerLinkType="QName" myRole="NCName"? partnerRole="NCName"? initializePartnerRole="yes|no" ? />+
</partnerLinks>
partnerLink可以在WSBPEL的<process> or <scope>中宣告，在宣告的範圍中 partnerLink的名字需唯一。
- 變數( variable )
業務流程中的狀態，有些書上有提到可以透過序列化外部儲存，或者放db，甚至放client端，但這些都會需要額外的I/O 資源，在既有的BPEL規劃中，就已經有可以進行資料交換儲存的設計，WS-BPEL可以使用XML Schema 以及 WSDL 的 message types 來定義變數類型，對資料變數的操作使用XPath / XSTL
<variables>
<variable name="BPELVariableName" messageType="QNmae"? type="QName"? element="QName"?>+ from-spec?
</variable>
</variables>
messageType, type, element 用來定義變數的類型，其中 messageType 引用在 WSDL中定義的訊息類別， type引用 XMLScehma的資料類型，而element則引用在XML Schema中定義的元素，一個變數只能通過上述三者之一來定義，初始化則通過設定值或接收來自夥伴連結服務的訊息，WS-BPEL 2.0使用 XPath 1.0來運算變數，根據變數定義方式的不同，有不同的方法來取得變數的內容，對於使用 type , element 定義的變數，可使用 $vaName 來代表該變數所表示的 root element，然後 透過 / 可依次取得該變數的子元素，參考以下使用XML Schema 定義的 searchRequest 元素...
<element name="searchRequest">
<complexType>
<sequence>
<element name="keywords" type="string"></element>
<element name="lowprice" type="tns:Price"></element>
<element name="highprice" type="tns:Price"></element>
<element name="pageIndex" type="int"></element>
<element name="EntriesPerPage" type="int"></element>
</sequence>
</complexType>
</element>
在WS-BPEL中可以透過以下指令取得變數： $searchRequest /e:keywords
若是messageType定義的變數，方法就又不同了，因為messageType是由多個part元素組成，而每一個part又是由變數所定義的，
對於這類的變數取得規則是： $varName.part //xxelement
當然WS-BPEL提供了內置的函數來實現對變數內容的處理，像是 getVariableProperty, doXslTransform等等。
- 關聯( Correlation )
關聯是WS-BPEL中很重要的一個特性，業務流程都是有狀態的，運作的時間一般都很長，同一時間內有同一業務流程的多個實例在運行，這樣就會導致一個問題：用戶的下一個請求應該交給業務流程的哪一個instance來處理? 答案顯然是應該交給之前已處理了該用戶請求的業務流程instance來處理，因為該業務流程instance中儲存了對該用戶處理的 status，沒有這些status就不能進一步處理該用戶的請求，WS-BPEL提供的關聯機制正是用來解決這個問題的。
WS-BPEL提供的是宣告的機制，用來指定一個服務instance中相關聯的操作組合。他定義了一組可以被所有訊息共用的屬性，這組屬性被稱為關聯集合(CorrelationSet)。關聯集合可以在global or local 宣告，他類似於延後被設定的常數，一開始沒有被初始化，直到被帶有特殊標記的 receive or send操作設定值，之後就保持不變。在有多方參與的業務流程中，起始方發起第一條訊息，定義關聯集合中暑性的值，其他各方接收訊息，設定各自的關聯集合中屬性的值，這樣就可以保證sesssion可以被一致性的往下go !!
- 請求( invoke )
invoke用來使用 web service，可以是單向或雙向的，其中內含眾多的子tag，在此不一一贅述，指挑幾個重點來記錄：
<invoke partnerLink="NCName"> - 這屬性用來飲用夥伴連結服務
<invoke portType="QName"> - 指定介面
<invoke operation="NCName"> - 指定對應的操作
<invoke inputVariable="BPELVariableName"> - 為輸入的參數，也可以透過 <toPart>來設定
<invoke outVariable = "BPELVariableName"> - 為輸出的參數，可以透過<fromPart>指定
<catch> - 處理例外錯誤的資訊
- 接收與應答 ( receive / reply )
一般通過<receive>活動接收來自夥伴連結的請求，然後通過<reply>活動給夥伴連結一個回饋的資訊，如果只是單向的通信就不需要有<reply>。<receive>活動是阻塞型的活動，整個流程的後續活動會一直阻塞，直到收到相匹配的訊息。
在<receive createInstance="yes|no">，表示是否要建立一個流程的instance，很顯然地必須設為yes，如此BPEL引擎則為其建立相應的 flow instance ，以便處理後續的邏輯。
- 事件處理 ( eventHandlers )
WS-BPEL定義了兩種事件類型- onEvent / onAlarm
onEvent對應於WSDL中某個操作的輸入訊息到達，而onAlarm則是基於時間，當到達某個時間點時，該事件被觸發
- 選擇事件處理 ( pick )
pick活動是一系列的事件-活動的組合，在運行時阻塞，直到某個事件的發生，其對應的活動才被執行，這裡事件也有兩種類型 - onMessage / onAlarm。
onMessage是對應於該事件等待接收訊息，而onAlarm則跟 eventHandlers定義的一樣。
- 等待 ( wait )
這裡的tag標記乍看之下真的會讓人以為在寫程式，其主要目的是等待某段時間後才恢復流程執行，參考以下這個會讓你覺得你不是在寫XML。
<wait standard-attributes>
standard-elements
(
<for expressionLanguage="anyURI"?>duration-expr</for>
|
<until expressionLanguage="anyURI"?>deadline-expr</until>
)
</wait>
- 設定值( assign ) , 結構化流程控管, 錯誤處理 等等 直接查閱手冊...
- 空值( Empty ) - 啥都不做，可以用在捕捉異常，又不須特別處理時
- 退出( Exit ) - 退出活動，用來立即退出流程的instance
- Scope元素
WS-BPEL的 root element 是 process，如果說process相當於主程序的話，那麼scope就類似於主程序中的一個子函數，Scope元素提供了一個上下文，其中可以定義變數、夥伴連結鏈結、訊息交換、關聯集合、事件處理、異常處理、補償處理以及結果處理。
Process元素沒有標準的屬性和元素，因為他不是活動
Process元素沒有補償處理和結果處理
Process元素沒有isolated屬性
沒有留言:
張貼留言