Workflow definition section

1.8 Our framework

3.1.3 Workflow definition section

由於架構使用 BPEL[9] 來實踐服務導向架構 [2] 流程處理部份，所以

<Workflow DefinitionSection >中<targetBPEL>代表 SDL 所對應之 BPEL[9]的 URI，<targetBPEL>中<targetpartnerLink>代表 BPEL[9]所對應之 partnerLink，

<targetpartnerLink> 中 <targetmyRole> 和 <targetpartnerRole> 代表 partnerLink 中 myRole 和 partnerRole，由 myRole 的 partnerLinkType 進而對應到 web service 的 WSDL 中<portType>，<targetmyRole>中的<WSSL>對應針對

此 WSDL 的網路服務安全語言文件進而取得確保訊息傳遞時的安全相關安全機制，<targetpartnerRole>中的<WSSL>對應針對此 WSDL 的網路服務安全語言文件進而取得確保訊息傳遞時的安全相關安全機制。範例如下：

圖 3.7 Workflow definition section 範例 3.1.4 Serialization definition section

BPEL[9]使用步驟為單位達到流程處理的功能，步驟分為基本步驟和結構步驟，基本步驟為 Invoke、Receive、Reply、Assign、Throw、Wait、Empty、

ExtensionActivity 、 Exit 、 Rethrow ，結構步驟為 Sequence 、 If 、 While 、 RepeatUntil、Pick、Flow、ForEach。

< WorkflowDefinitionSection>

< /WorkflowDefinitionSection>

功能需要將步驟賦予一個可以唯一識別的代號，然而 BPEL[9]定義的步驟卻並無定義可以唯一識別的代號，為了達到這個功能特別借用 BPEL[9]中一個特別的步驟，它就是 Documentation Activity。Documentation Activity 就如其單字意義一樣只有註解功能，使人可以了解立即包含他的步驟的功用可以用

Documentation Activity 內之內容加以人們易讀的文字說明註解其功用。

SDL 特別利用 Documentation Activity 沒有流程處理的功能的特性，用以描述步驟之可以唯一識別的代號，此方法說明如下：

圖 3.8 步驟唯一識別的代號

其中[AId[A00001]]中的 A00001 為 Invoke 的唯一識別的代號，而 Initial Price Calculation 說明註解，如此便克服了 BPEL[9]定義的步驟卻並無定義可

以唯一識別的代號的問題。

Serialization definition section 中 <Serialization definition section>一個<Activities>。<Activities>中包含數個<Activity AId=‛…‛

ActivityType = ‛…‛>，<Activity AId= ‛…‛ ActivityType = ‛…‛>中包含一個 <DynamicBehaviorLogic> ，一至數個 <SerializationVariable TargetVariable=‛…‛ >。

<DynamicBehaviorLogic>中包含一個類似 BPEL[9] <if> 步驟[9]如圖 1.7 動態行為處理邏輯 If 語法，為了安全考量對工作流程而言確是常常需要知悉較

[AId[A00001]]Initial Price Calculation

</Documentation>

</Invoke>

低階層 WS-Security 執行時的狀況來判斷決定工作流程的執行路徑，定義了四個擴充布林函數 ActivityIsExecuted (ActivityName)，SequenceIsExecuted (AN1,AN2,AN3,…)，IsEncryptedValidated(ActivityName)，IsSignedValidated (ActivityName)，兩個擴充函數 Encrypt(Key,S1,S2,…)，Sign(Key,S1,S2,…)

<DynamicBehaviorLogic>中的<condition>bool-expr</condition>如圖 1.8 動態行為處理邏輯 If 語法，採用 BPEL[9]一樣 WS-BPEL Boolean expressions 類似 XPATH Boolean expressions 加上四個擴充布林函數，在這裡特別再說明上四個擴充布林函數特性:

1. ActivityIsExecuted(ActivityName)：步驟其識別 ID 為 ActivityName 在此程序實體是否已經執行過，已經執行過傳回真，否則傳回假。

2. SequenceIsExecuted(AN1,AN2,AN3,…)：步驟其識別 ID 依序為

AN1,AN2,AN3,…在此程序實體是否已經依序執行過，已經依序執行過傳回真，否則傳回假。

3. IsEncryptedValidated(ActivityName): 步驟其識別 ID 為 ActivityName 是否可解密，可解密則傳回真，否則傳回假。

4. IsSignedValidated (ActivityName): 步驟其識別 ID 為 ActivityName 是否簽章驗證有誤，簽章驗證有誤傳回假，否則傳回真。

<DynamicBehaviorLogic>中的 if 步驟如圖 1.8 動態行為處理邏輯 If 語法定義了兩個擴充函數 Encrypt (Key,S1,S2,…)，Sign (Key,S1,S2,…)。

1. Encrypt(Key,S1,S2,…)：使用 Key 加密 S1,S2,…所指示之資料 2. Sign(Key,S1,S2,…)：使用 Key 簽章 S1,S2,…所指示之資料

而一至數個 <SerializationVariable TargetVariable=‛…‛ > ，

<SerializationVariable TargetVariable=‛…‛>中包含數個<XPath>或不包含任何<XPath>，其中<XPath>內容表示該元素及該元素所包含之元素要序列化，比較特別的是當不包含任何<XPath>表示該變數全都要序列化，TargetVariable 指出要序列化的 BPEL[9] Variable ，此外 <SerializationVariable TargetVariable=‛…‛>中也可以有一個<condition>bool-expr</condition>，

Condition 採 BPEL[9] Boolean expression 類似 XPATH Boolean expressions 定義當條件為真(true)時序列化。Serialization definition section 範例如下:

</SerializationVariable>

Encrypt(‘Keydef1’,'$Rec/ItemName','$Rec/ItemID',…) Sign(‘Keydef2’,'$Rec/ItemName','$Rec/ItemID',…)

</sequence>

</DynamicBehaviorLogic>

</Activity>

</SerializationVariable>

Encrypt(‘Keydef3’,'$Rec/ItemName','$Rec/ItemID',…) Sign(‘Keydef2’,'$Rec/ItemName','$Rec/ItemID',…)

</sequence>

</DynamicBehaviorLogic>

</Activity>

< Activity AId=‛A0003‛ ActivityType =‛Invoke‛>

<Condition>…</Condition> '$Rec/ItemID',…)

Sign(‘Keydef2’,'$Rec/ItemName', '$Rec/ItemID' ,…)

</sequence>

<else>

Encrypt(‘KeydefN’,'$Rec/ItemName', '$Rec/ItemID',…)

Sign(‘Keydef2’,'$Rec/ItemName', '$Rec/ItemID',…)

圖 3.9 Serialization definition section 範例

SerializationVariable Condition 處理方式如圖 3.10 SerializationVariable Condition 處理流程，BPEL 轉變成 BPEL’後 Condition 邏輯會依據 SDL 的內容影響序列化的內容。

圖 3.10 SerializationVariable Condition 處理步驟

ActivityIsExecuted(ActivityName) 擴充布林函數處理方式如圖 3.11 轉換成 BPEL’後會呼叫序列化 Web service，因為序列化 Web service 透過程序實體才可能得到程序之前執行狀態，進而達到 1.7 節 Dynamic behavior in workflow security issue 中所提出的執行狀況判斷的功能，而

SequenceIsExecuted(AN1,AN2,AN3,…) 擴充布林函數處理方式也如圖 3.12 只是其傳入的參數多於一個，而傳入的參數的順序代表是否程序實體執行順序序列有

Assign

Assign Variable A to Variable B

Assign

Invoke Serialization Web Service

Condition Boolean expression

Aid=A0001 PC=1

Variables=&#60... &#62 true

false

… ^.

</Activities>

</SerializationDefinitionSection>

符合的，透過布林運算子的運用能夠達到平行運算模式條件判斷，例如

SequenceIsExecuted(‘A0001’,’A0002’) and SequenceIsExecuted(‘A0003’,’A0004’)可以表示 A0001、A0002 執行順序和 A0003、A0004 執行順序是平行運算。

IsEncryptedValidated(ActivityName) 擴充布林函數處理方式如圖 3.12 轉換成 BPEL’後會呼叫 WSSL Proxy Web service，因為 WSSL Proxy Web service 透過 WSSL API 才可能得到 Encrypted 資料是否能夠解碼，進而達到 1.7 節 Dynamic behavior in workflow security issue 中所提出的 Security 的狀況判斷的功能，

IsSignedValidated (ActivityName) 擴充布林函數處理方式轉換成 BPEL’也後會呼叫 WSSL Proxy Web service，因為 WSSL Proxy Web service 透過 WSSL API 才可能得到簽章是否有效。

圖 3.11 ActivityIsExecuted(ActivityName)擴充布林函數步驟

圖 3.12 IsEncryptedValidated(ActivityName)及 IsSignedValidated (ActivityName)擴充布林函數步驟

Serialization 以步驟為單位將步驟使用的變數序列化，透過

Serialization Web Service 將步驟執行前加上參數設定前置 Assign 步驟，將步驟執行後加上 Invoke 步驟呼叫 Serialization Web Service，Serialization Web Service 包含:

1. Serialization Register Web Service：註冊 Serialization ID 作為 Serialization 識別用途，同時也可提供為儲存檔名，使用 UUID 為其格式可以有效確保，在網際網路上沒有重複一樣之 UUID，原因是 UUID 之產生以網路卡、時間、電腦環境等參數產生發生重複的機率很低很低。

2. Serialization Begin Web Service：註記序列化起始時間及第一個 Receive 或 Pick 步驟變數。

3. Serialization Activity Web Service：序列化步驟變數。

4. Serialization End Web Service：序列化 Reply 步驟變數，及註記序

列化結束時間。

序列化文件為 XML 文件，其階層式表示法如下:

圖 3.13 序列化文件為其階層式表示法序列化文件為 XML 文件如圖 3.14

 ProcessInstant (Element)

 PId (Attribute)

 InitTime (Attribute)

 Mode (Attribute)

 Activity+ (Element) i. AId (Attribute) ii. PC (Attribute)

iii. InvokeEngine (Attribute) iv. STime (Attribute)

v. Mode (Attribute) vi. Variables (Text) vii. Tree Structure

 TimeStamp (Element) i. PId (Attribute)

ii. FinishTime (Attribute)

圖 3.14 序列化文件範例

XSLT 是 Extensible Stylesheet Language Transformations 縮寫，為 W3C 制定標準此處採用 XSL Transformations (XSLT) Version 1.0 W3C Recommendation 16 November 1999 版本，主要用途用來轉換 XML 文件成另一種格式的 XML 文件，此處為了達到 uniform representation 的目的將步驟變數序列化，使用如下列 XSLT：

圖 3.15 為了步驟變數 uniform representation 之 XSLT 加上 BPEL[9]中特別定義將 XSLT 1.0 納入其 BPEL[9]標準中，並定義 bpel:doXslTransform 函數執行 XSLT 1.0，其函數語法如下：

object bpel:doXslTransform(string, node-set, (string, object)*) 透過 XSLT 及 bpel:doXslTransform 函數使得變數轉換為變數字串。

如圖 3.16 透過 Serialization Web Service 將 BPEL[9]的步驟後加上 Invoke Serialization Web Service 的步驟達到序列化的目的，為了能夠記錄程序的執行順序 BPEL’會加上兩個特別的變數 Pid 及 PC，其中 Pid 儲存 UUID 格式的字串用來識別程序實體而 PC 基本上隨著步驟執行而執行加一計算，用來針對平行運算執行時能確時記錄程序的執行順序其操作模型如下圖。

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

version="1.0">

<xsl:output omit-xml-declaration="yes"/>

<xsl:template match="text()"/>

<xsl:template match="/" priority="1">

<xsl:apply-templates/>

</logcontent>

</xsl:template>

<xsl:template match="*" priority="2">

<<xsl:value-of select="name()"/>>

<xsl:apply-templates/>

<xsl:if test="text()">

<xsl:value-of select="text()"/>

</xsl:if>

</<xsl:value-of select="name()"/>>

</xsl:template>

</xsl:stylesheet>

圖 3.16 Serialization operation model

3.1.5 Digital signature section

Digital signature section 主要是要定義簽章，以免 SDL 被串改，參考 XML-Signature Syntax and Processing W3C Recommendation 12 February 2002 標準，語法如下。

BPEL BPEL’

=BPEL Activity

=Serialization Invoke

Activity

圖 3.17 Digital signature section 語法

(<Reference URI? >

(<Transforms>)?

</Reference>)+

</SignedInfo>

(<KeyInfo>)?

(<Object ID?>)*

</Signature>

</DigitalSignatureSection>

3.2 Fault Recovery Model

錯誤回復[13]一般來說是指當系統發生異常導致系統無法正常運作時所採取的一種處理使得系統狀況由錯誤狀態回復至正常狀況。錯誤回復處理方式一般又分為兩種：前向式錯誤回復[13]及後向式錯誤回復(Backward Recovery)[13]，

回復技術主要目的是為了使系統狀況由錯誤狀態回復至正常狀況，而前向式錯誤回復採取的方式找到一個可以使系統正常運作狀態來達到錯誤回復功能，此種方式比後向式錯誤回復有較少重複資料(Overhead)，但是前向式錯誤回復雖然將系統狀況由錯誤狀態回復至正常狀況但是與真正的未發生錯誤前可能不是百分之百一樣。後向式錯誤回復則是採用將之前已儲存(一般來說是週期性的儲存)的系統狀況來達到由錯誤狀態回復至正常狀況，此種方式可以達到錯誤回復至真正的未發生錯誤前百分之百一樣，但是有較多重複資料。

在本架構下由於程序實體已序列化，所以採取後向式錯誤回復相當容易達成，主要要克服的問題是如何將程序實體由序列化轉換成可運作的程序實體，一般是要靠 BPEL Engine 來提供一些功能。在此提供 ActiveBPEL(TM) engine4.0 中相關的功能，由於 ActiveBPEL(TM) engine4.0 中提供一些管理功能 Web service 可能設定 BPEL Process 變數，其中 BpelEngineAdmin (wsdl) 中 getVariable Web service 可以用來取得 Process 的 Variable 變數內容而 setVariable Web service 可以用來設定 Process 的 Variable 變數內容，不過整體來說對錯誤回復由於頇仰賴 BPEL Engine 來提供一些功能往往有很多的限制，提出一個 Failover Model 來達到失敗轉移，進而達到當錯誤發生時可以利用備份伺服器取代使得使用者根本不知道曾經有錯誤發生過。

3.3 Failover Model

失敗轉移是當故障發生時或異常終止以前的伺服器能夠自動切換到冗餘或備用伺服器，不頇要任何人為干預，通常使用者沒有察覺伺服器已經自動切換到冗餘或備用伺服器。首先為了達到失敗轉移的功能除了原本主伺服器(Master BPEL Server)頇要增加一個監督伺服器(Monitor Server)及一個備份伺服器 (Backup BPEL Server)，監督伺服器功能為監督主伺服器是否正常運作並且作為提供服務窗口，當主伺服器發生故障或異常終止時監督伺服器會將備份伺服器啟用叢集伺服器(cluster server)來當監督伺服器。

若是單以功能面來說也可以使用 BPEL Engine 來達到監督伺服器的功能，監

在文檔中在SOA架構下支援程序實體安全的研究 (頁 42-0)