構(gòu)建業(yè)務(wù)流程

1、構(gòu)建業(yè)務(wù)流程，第2部分-WebLogic Integration 開發(fā)最佳實踐文章工具推薦給朋友-打印文章時間：2004-12-22作者：Vijay Mandava, Anbarasu Krishnaswamy瀏覽次數(shù)：酸本文關(guān)鍵字：本文是在BEA WebLogic Integration 8.1上構(gòu)建業(yè)務(wù)流程的最佳實踐中的第二篇。第一部分 (WLDJ，第3卷，第6期)關(guān)注于團隊開發(fā)和維護的最佳實踐。在本文中，我們著重于創(chuàng)建具 有可伸縮性、可恢復(fù)性、異常處理、有保證的傳送以及高性能的業(yè)務(wù)流程的最佳實踐。本文適用于 WLI應(yīng)用程序的開發(fā)人員和設(shè)計人員。閱讀本文的第一部分流程的版本控制最佳實踐指定

2、流程文件的版本。原因很容易忽視版本控制，原因是流程無需任何版本就可以工作。但是對流程進行版本控制確實很 重要的，特別是對于那些長期運行的流程而言。升級一個流程時，如果流程沒有指定版本，那么未 決(in-flight)實例要么終止，要么部署失敗，這依賴于服務(wù)器的運行模式。如果服務(wù)器運行在迭代 (iterative)模式，則流程中止，如果服務(wù)器運行在生產(chǎn)(production)模式，則部署失敗。細節(jié)利用WebLogic Workshop的版本控制功能，您可以對業(yè)務(wù)流程進行更改，而無需中斷任何當 前正在運行的流程實例。當您指定一個業(yè)務(wù)流程的版本時，您就創(chuàng)建了一個業(yè)務(wù)流程的子版本，該 流程共享相同的公

3、共URI (接口)作為其父流程。在運行時，被標記為活動的流程版本是那些被外 部客戶端通過公共URI所訪問的流程。您可以為業(yè)務(wù)流程指定版本，但不能為與該流程相關(guān)聯(lián)的單獨控件或者其他與業(yè)務(wù)流程相關(guān)的 組件(例如schema和轉(zhuǎn)換)指定版本。當您指定一個業(yè)務(wù)流程的版本時，您也必須指定該流程 的子流程的版本，指定父流程的版本后，子流程的版本并不能被自動指定。所調(diào)用子流程的版本取 決于它所采用的版本策略。兩個可用的策略分別是松散藕合（調(diào)用時確定版本）和緊密藕合（調(diào)用 父流程時設(shè)置版本）。這里要重點指出的是，版本之間的不同并不是徹頭徹尾的，原因是所有的版本都是同一個接口 的不同實現(xiàn)。這也就意味著，不同版本

4、可以有相同的請求、回調(diào)方法（callback methods）以及靜 態(tài)消息代理訂閱（static message broker subscriptions）。異常處理最佳實踐為流程創(chuàng)建相應(yīng)的異常處理。為所有流程創(chuàng)建全局異常處理。原因在業(yè)務(wù)流程的任何階段出現(xiàn)已檢查的或者未經(jīng)檢查的異常是很自然的事情。應(yīng)當在業(yè)務(wù)流程中 對異常進行適當?shù)奶幚怼Ｈ绻惓]有被顯式地處理，那么該流程就可能中止且永遠不會重試。這 也可能導(dǎo)致消息未被處理或者消息丟失。細節(jié)可以在三個級別上創(chuàng)建異常處理：全局異常處理針對一組節(jié)點針對單個節(jié)點一般來說，異常會向上傳播，從節(jié)點異常路徑到組異常路徑，再到全局異常路徑，直到它被處 理為

5、止。換句話說，與節(jié)點相關(guān)的異常路徑會首先執(zhí)行，然后是與組相關(guān)的路徑，再后是與起始節(jié) 點相關(guān)的路徑（全局路徑）。異常只會被處理一次，除非您的異常處理路徑拋出一個異常；然后異 常會再次按照相同的順序向上傳播。對您的業(yè)務(wù)流程，您可以利用這種特性并創(chuàng)建滿足特定異常處 理需要的異常路徑邏輯。對于非事務(wù)性資源而言，可以在異常處理中進行補償事務(wù)處理?；謴?fù)最佳實踐在流程級和/或JMS隊列級設(shè)置適當?shù)膔edelivery屬性。原因在流程中出現(xiàn)異常的地方，事務(wù)會回滾，同時流程可能會中止。如果沒有設(shè)置合適的redelivery 屬性，那么用來啟動流程的消息將被移到錯誤隊列。移入錯誤隊列的消息將不會被業(yè)務(wù)流程再次進

6、行處理。相反，一個內(nèi)部消息驅(qū)動bean將會讀取該消息并調(diào)用該業(yè)務(wù)流程的全局異常處理。避免發(fā)生這種情況的一個推薦的方法是為retry count和retry delay都設(shè)置較高的值。細節(jié)流程級的屬性是：Retry count:指定在第一次嘗試執(zhí)行業(yè)務(wù)流程失敗后流程引擎應(yīng)該試圖執(zhí)行該業(yè)務(wù)流程的次 數(shù)。Retry delay:指定兩次重試之間的時間間隔(以秒為單位)。確保重試次數(shù)和重試間隔合適。重試次數(shù)和重試間隔的乘積應(yīng)該超過運行JTA恢復(fù)的時間。如果需要調(diào)整重試次數(shù)和重試間隔，您可有以下的選擇：在您的 JPD 中認真設(shè)置 retry count 和 retry interval為每個 JPD 工

7、程(WebApp)的 async 和錯誤隊列(error queues)設(shè)置 retry count 和 retryinterval o注意這將會中斷JPD上顯式retry設(shè)置，但它是最容易的，也是推薦使用的方法。消息代理通道最佳實踐最好使用JMS header值，而不是使用文檔號。原因使用header值的速度遠遠快于使用一個文檔元素，因為前者無需進行解析。細節(jié)消息代理通道和Java Message Service (JMS)主題有相似的屬性，但它經(jīng)過了優(yōu)化，以便和 WebLogic Integration流程、控件和事件生成器(event generator)一起使用。我們推薦創(chuàng)建多個 通道

8、(channel)，而不是讓多個JPD用訂閱篩選器(subscribtion filter)來監(jiān)聽單個通道。最佳實踐創(chuàng)建業(yè)務(wù)流程來使用失效通道(dead letter channel)中的消息。原因如果該通道沒有訂閱者，或者由于篩選條件不滿足而導(dǎo)致已注冊的訂閱者不匹配，那么該消息 被置入失效通道。如果該失效通道沒有訂閱者，置于該通道上的消息就會因被丟棄而丟失。細節(jié)當一個消息被發(fā)布到一個通道，同時未找到匹配的訂閱者，則該消息會被重新發(fā)布到一個和該 通道類型相對應(yīng)的失效通道。WebLogic Integration提供了如下的失效通道：/deadletter/xml/deadletter/stri

9、ng/deadletter/rawData例如，一條發(fā)布到一個XML通道(即消息類型Type = xml的通道)的非匹配消息被發(fā)送 到/ deadletter/xml通道。在設(shè)計時，當您創(chuàng)建MB Publish和MB Subscription控件時失效通道 是可用的。您的業(yè)務(wù)流程可以發(fā)布和訂閱該失效通道。例如，當設(shè)計錯誤處理時您可以使用失效通 道一您可以創(chuàng)建這樣一個業(yè)務(wù)流程，它包含對失效通道的靜態(tài)訂閱和處理已發(fā)布到這些通道上的非 匹配消息的設(shè)計錯誤處理代碼。WebLogic Integration Administration Console 中的 Message Broker 模塊可讓您對應(yīng)

10、用程序中的 所有Message Broker通道，包括失效通道進行監(jiān)管。BP事務(wù)邊界最佳實踐在進行流程設(shè)計的同時要記住事務(wù)邊界(transaction boundaries)。原因流程中存在隱式的事務(wù)邊界，它們將影響業(yè)務(wù)的行為。如果對其視而不見，它將導(dǎo)致無法預(yù)期 的結(jié)果。添加事務(wù)性邊界將會為流程定義引入一個抑止點(quiescent point)。細節(jié)在WebLogic Integration中，流程在本質(zhì)上是面向事務(wù)的。流程每步的執(zhí)行都是在JTA事務(wù) 的環(huán)境中進行的。事務(wù)確保了一個或者更多的操作將作為一個工作的最小單位來執(zhí)行。如果事務(wù)處 理中的某個操作失敗的話，那么所有的操作都將回滾，于是應(yīng)

11、用程序返回到其先前的狀態(tài)。對業(yè)務(wù) 流程邏輯的設(shè)計決定了該流程是有狀態(tài)的還是無狀態(tài)的，于是也決定了給定流程環(huán)境中存在一個或 者多個事務(wù)處理。當您創(chuàng)建一個流程的時候，根據(jù)流程中放置基本構(gòu)成元素(例如，control receive或者client receive)的位置而形成了隱式事務(wù)邊界。在您添加流程節(jié)點的同時，流程中的事務(wù)邊界會隨著更改。 您也可以創(chuàng)建顯式的事務(wù)邊界，方法是選取相鄰的節(jié)點并在一個與那些應(yīng)用程序隱式創(chuàng)建的事務(wù)所 分開的事務(wù)中進行聲明。流程所訪問的資源也可以是事務(wù)處理的一部分，這取決于資源的本質(zhì)和提 供該訪問的控件。可引入隱式事務(wù)邊界的一些節(jié)點是：Event choiceParal

12、lel nodesControl receives無狀態(tài)流程最佳實踐最好用無狀態(tài)流程，而不是有狀態(tài)流程。原因有狀態(tài)流程是作為實體bean而實現(xiàn)的，當存在抑止點時它們將被持久存儲在數(shù)據(jù)庫中。細節(jié)無狀態(tài)流程是只在內(nèi)存中執(zhí)行的流程，并且不會在數(shù)據(jù)庫中永久存儲其狀態(tài)。從技術(shù)上講，它 被編譯成一個無狀態(tài)會話beano無狀態(tài)流程所支持的業(yè)務(wù)情況涉及到短期運行的邏輯且有較高的性能需求。由于它不在數(shù)據(jù)庫 中持久存儲其狀態(tài)，所以它對較低的延遲時間、較高的性能執(zhí)行進行了優(yōu)化。這里舉一個示例，一 個無狀態(tài)流程異步接收來自客戶端的消息，對消息進行轉(zhuǎn)換，然后利用一個控件按照異步或者同步 模式將其發(fā)送給一個資源。另外一個

13、示例是，一個無狀態(tài)流程以一個消息代理訂閱(message broker subscription)開始，對消息進行轉(zhuǎn)換，并將其發(fā)布到另一個消息代理通道?，F(xiàn)實中較為常用的情 形是對一個長期運行的業(yè)務(wù)事務(wù)進行建模。這可通過向通道發(fā)布消息將其構(gòu)建為松散藕合的一組無 狀態(tài)業(yè)務(wù)流程。由于無狀態(tài)流程被編譯成無狀態(tài)會話bean，這就確保了數(shù)據(jù)成員只包含非特定實例(non-instance-specific)數(shù)據(jù)。您不能顯式地將一個流程配置為無狀態(tài)的。在默認情況下，一個業(yè)務(wù)流程是無狀態(tài)的，直到您 向數(shù)據(jù)流中添加了任何的基本構(gòu)成結(jié)構(gòu)，譬如等待一個回復(fù)或者一條消息。這反過來強迫事務(wù)邊界 和流程變?yōu)橛袪顟B(tài)的。因此，

14、如果流程只運行在一個事務(wù)中的話，該流程就是無狀態(tài)的。有狀態(tài)流程有狀態(tài)流程指的是運行在一個以上事務(wù)中的流程。這樣的流程在數(shù)據(jù)庫中有持久存儲的狀態(tài)， 并被編譯成一個實體beano有狀態(tài)流程所支持的業(yè)務(wù)情況涉及到復(fù)雜的、長期運行的邏輯，并且因此有特定的可靠性和恢 復(fù)需求。通過添加有狀態(tài)節(jié)點或者強加事務(wù)邊界邏輯的方式就能使一個流程變成有狀態(tài)的流程(參 見事務(wù)邊界)。例如，一個流程接收消息，進行轉(zhuǎn)換，將其發(fā)送給一個業(yè)務(wù)伙伴，然后等待一個異 步響應(yīng)，這樣一個流程就是有狀態(tài)流程，因為“等待”的動作強加了一個事務(wù)邊界?？梢鹨种裹c的節(jié)點列表是：Control receiveEvent choice (起始節(jié)點

15、除外)Parallel branching有些控件通常需要一個control receive并因此將會強制一個流程變成有狀態(tài)的。這些控件的 一個部分列表包括：WorklistTimer異步雙向流程JMS訂閱消息代理訂閱有狀態(tài)流程由于其在數(shù)據(jù)庫中有狀態(tài)，所以其性能不及僅使用內(nèi)存的(memory-only)無狀態(tài) 流程。然而，狀態(tài)的持久存儲往往是必要的，因為它可以確保：在系統(tǒng)停機的等待期間內(nèi)，流程可以恢復(fù)并繼續(xù)執(zhí)行而不會丟失數(shù)據(jù)。在此等待期間內(nèi)，系統(tǒng)資源會被有效的利用。在此期間，該實體bean可能會被鈍化(passivated)，這將釋放服務(wù)器上的內(nèi)存。您不可以顯示地將一個流程配置為有狀態(tài)的。當位

16、于流程頂部的流程起始節(jié)點有一個綠環(huán)時， 您就知道該流程何時是有狀態(tài)的。并行節(jié)點最佳實踐在使用并行節(jié)點之前，先要了解它們。原因使用并行節(jié)點可以隱式地改變流程的行為。并行節(jié)點可改變流程的事務(wù)處理行為和狀態(tài)行為。并行節(jié)點所謂的并行也僅僅是邏輯概念上的并行。細節(jié)業(yè)務(wù)流程中的并行執(zhí)行分支是邏輯上的并行；物理上它們是由業(yè)務(wù)流程引擎順序執(zhí)行的。業(yè)務(wù) 流程在和外部系統(tǒng)進行通信時，如果涉及到等待外部系統(tǒng)的響應(yīng)的話，那么業(yè)務(wù)流程就會從這種邏 輯上的并行機制受益。在一個執(zhí)行分支等待響應(yīng)的同時，并行流中的另外一個執(zhí)行分支可以繼續(xù)執(zhí) 行。并行分支只是在它們的終止點上被同步。在多個分支的終端定義了一個結(jié)合條件（join

17、condition） 來確定分支的終端是如何終止總體并行活動的（parallel activity）。有效的結(jié)合條件是AND和OR。WebLogic Integration 數(shù)據(jù)庫最佳實踐為WLI數(shù)據(jù)庫和應(yīng)用程序數(shù)據(jù)庫使用分開的schema （而不是物理數(shù)據(jù)庫）。原因這將WebLogic Integration表與應(yīng)用程序表分開，所以可應(yīng)用不同的策略。細節(jié)即便在您只有一個共享數(shù)據(jù)庫的情況下，為WebLogic Integration和應(yīng)用程序使用分開的 schema （分開的用戶）是一個好方法。有時WebLogic Integration可能會在開發(fā)模式中迅速地 創(chuàng)建表，這說明WebLogic

18、 Integration用戶ID需要創(chuàng)建許可，但是應(yīng)用程序數(shù)據(jù)庫用戶通常沒 有被賦予這種特權(quán)。這也將WebLogic Integration表與應(yīng)用程序表分了開來，從而有助于數(shù)據(jù)歸 檔和維護。配置超時最佳實踐關(guān)聯(lián)超時路徑以確保業(yè)務(wù)流程最終會結(jié)束。原因這個事件可能永遠不會發(fā)生，該業(yè)務(wù)流程可能會永遠阻斷（blocked）o細節(jié)您可在一個節(jié)點上、一組節(jié)點上或者整個流程上設(shè)置超時。當流程開始時，起始節(jié)點上的定時 器啟動。當業(yè)務(wù)流程到達該執(zhí)行點時，節(jié)點或者節(jié)點組上的定時器啟動。結(jié)束語軟件開發(fā)的藝術(shù)在過去的幾年中發(fā)生了顯著的變化，現(xiàn)實中所有的軟件工程都要使用實現(xiàn)特定 模塊的框架。正在建設(shè)中的項目利用不同服務(wù)級別的協(xié)議與分散的系統(tǒng)進行集成，同時業(yè)務(wù)領(lǐng)導(dǎo)者 們期望著在宏觀業(yè)務(wù)流程級別上實現(xiàn)可視化和管理。在與這種趨勢保持協(xié)調(diào)一致的同時，我們期望 在今后的5年中業(yè)務(wù)流程管理系統(tǒng)會和數(shù)據(jù)庫一樣普及。在本文中，我們討論了在BEA WebLogic I