針對自動工作流系統使用傳統SOA建模工具存在的效率低下等問題，提出了一種基于Petri網思想進行SOA架構應用的方法，并從使用Petri建模進行服務識別和使用Petri中間件進行流程管理這2個方面詳細闡述了SOA架構應用的具體內容，為此類工作流系統進行SOA架構應用改造提供了參考。

　　【關鍵詞】面向服務的體系結構 服務識別 Petri 工作流 中間件

　　SOA(Service-Oriented Architecture，面向服務的體系結構)是構造分布式計算的應用程序的方法，它將應用程序功能作為服務發送給最終用戶或者其他服務，通常認為 SOA是一種技術架構或者架構風格。基于這種架構，業務流程或業務的變化可以通過服務編排調整快速適應，實現業務的敏捷性。隨著SOA的快速發展，基于 SOA架構的中間件產品也成為網絡化商業系統的主要設計思路。

　　由于企業的業務現狀、遠景需求及IT系統現狀等的差異，SOA架構存在不同的構建思路，但一般來說，SOA的開發、維護和使用的基本原則可以歸納為：

　　(1)可重復使用，模組性，可組合性，構件化以及具有交互操作性;

　　(2)服務的識別和分類，提供和發布，監控和跟蹤;

　　(3)符合開放標準(通用的或行業的)。

　　從基本原則可以看出，SOA架構的重點是要找到可重用的服務，同時這些服務滿足離散、自治和無狀態等基本條件;其次是服務本身可以組合和編排，以滿足流程整合的需要。

　　2 SOA服務識別的難點

　　SOA參考架構可總結為業務能力組件化及組件能力的服務化。服務識別的過程是通過自頂向下的分析，可以將流程的功能點逐層細分，直到最后一級的原子能力，再通過原子能力按照SOA架構的思想自底向上逐層組裝，分析出可以重用的能力，重新編排為服務。

　　服務識別是SOA架構實施的難點之一。因為當實施SOA架構時，業務系統一般已經具有一定規模，業務人員以及技術人員對業務系統的系統劃分、模塊劃分已經有一定約定俗成的概念，容易先入為主。無論是往下的逐層細分，還是向上的逐層組裝，都需要參考SOA架構做出思維上的改變。

　　因此，需要引入一些成型的流程建模工具來引導這個過程。目前SOA的服務識別有很多成型工具和模式，比如BPM(Business Process Management，業務流程管理)和BPEL(Business Process Execution Language，業務流程執行語言)，但是這些工具和模式也并非適合所有的系統。一方面，建模工具本質上是用于輔助設計，這些企業級別的工具和模式覆蓋面過于大，復雜程度高，分析的周期也較長，對于自動工作流較多的系統，輔助設計過程中往往需要較為簡單輕巧的工具;另一方面，純設計層次的建模與有工作流引擎參與的建模實際是存在不同的，完成服務識別后，再轉化為可以為工作流引擎使用的服務也比較困難。

　　3 Petri網思想在SOA架構中的應用

　　SOA架構設計本身是一種思維改變的過程，已經成型的系統會存在很多固定的模塊劃分和功能劃分，造成SOA實施困難，需要采用一些建模工具來輔助思維。使用建模工具進行建模時，應該覆蓋2個要點：首先，建模工具是輔助設計的過程，選擇合適的建模工具是必要的;其次，純設計方式流程建模和SOA 的建模方式是有所區別的。建模工具既要符合SOA的設計模式，也要貼近目前的業務實際，更要讓建模的結果在SOA工作流引擎中能夠無縫銜接。

　　Petri網是分布式系統的建模和分析工具，可以清晰地描述系統中的進程和功能模塊的順序[1]。研究領域趨向認為Petri網是所有流程定義語言之母，理論上所有的流程建模工具使用的方法都可以用Petri網的概念來表達。由于Petri網相對BPM和BPEL這些工具更為簡單及靈便，因此用于描述流程上相對簡單的自動工作流系統，則更具有明顯的優勢。

　　相對于BPM和BPEL這些工具，Petri建模的優勢在于：一方面，建模元素比較簡單，更加注重流程本身;另一方面，代碼邏輯和Petri圖能夠一一對應，可以更加有效地利用原有的應用實現而不用擔心全部推倒重來。

　　3.1 Petri建模介紹

　　Petri網是對離散并行系統的數學表示[2]，作為一種能夠用來有效地分析系統的并發、異步和不確定行為[3]，并能有效描述系統靜態和動態的圖形化模型，Petri網被廣泛應用于生產制造領域、計算機領域、過程控制和專家系統等領域。Petri網既有嚴格的數學表述方式，也有直觀的圖形表達方式。

　　Petri網是過程模型，由庫所和變遷兩類節點、有向弧以及令牌等元素組成。

　　(1)Petri網的元素定義

　　◆庫所(Place)：圓形節點;

　　◆變遷(Transition)：方形節點;

　　◆有向弧(Arc)：庫所和變遷之間的有向弧;

　　◆令牌(Token)：庫所中的動態對象，可以從一個庫所移動到另一個庫所。

　　(2)Petri網的規則

　　◆有向弧是有方向的;

　　◆兩個庫所或變遷之間不允許有弧;

　　◆庫所可以擁有任意數量的令牌。

　　如果一個變遷的每個輸入庫所(input place)都擁有令牌，該變遷即為被允許(enable)。一個變遷被允許時，變遷將發生(fire)，輸入庫所(input place)的令牌被消耗，同時為輸出庫所(output place)產生令牌。

　　3.2 使用Petri建模進行服務識別

　　Petri網模型本身具有子網的概念，可以將變遷逐層下轉到最底層的原子變遷，也可以將所有Petri子網模型合成一個更大的Petri網模型，用來描述整個系統的動態行為模型[4]，這與SOA服務識別的過程是高度契合的。

　　(1)子網逐層向下分解

　　用Petri建模的思想，可以通過“映射”的思想和方法，按目前的詳細設計或者代碼邏輯將應用模塊用Petri圖畫出。Petri網中的庫所元素映射為程序數據，Petri網中的變遷元素映射為程序函數和方法，系統模型中的各對象子網映射為程序中的類[5]。對主要以數據驅動的自動工作流的程序，按照程序的狀態，Petri網的建模一般如圖1所示：

　　圖1 數據處理程序狀態的建模

　　Petri網的每個變遷都可以理解成子網，特別是針對圖1的數據處理的變遷，也可以按照代碼的實際邏輯，分解成如圖2所示的子網：

　　圖2 數據處理子網的建模

　　上圖的每個變遷也可以繼續理解成子網的概念，按照代碼邏輯繼續往下建模，直到變遷不可再繼續細分，這正符合了SOA逐層細分的理念。

　　(2)變遷組裝成服務

　　SOA服務要求具備可重用性，需要將可重用的組件能力開放為服務，這個可以映射為Petri可重用的子網。將每個變遷細化到“原子”級別的變遷后，首先需要對變遷進行分析，通過對變遷的輸入輸出令牌進行抽象，將能抽象成相同輸入輸出令牌的變遷視為一種服務，則這個變遷具備了SOA要求的可重用性。

　　重用度最高的同時也最容易分析的是系統底層的原子能力，如操作系統資源、數據庫操作的服務，這些服務目前已經有成型的模式，此處不再贅述，主要難點在于業務級別的服務分析。對于業務級別的服務分析，重點應關注應用處理數據的狀態。

　　圖1示意了進程級別程序狀態的建模，如果將數據狀態的部分抽離出來，進一步考慮這個數據在整個應用中的狀態，可以形成如圖3所示的處理過程(忽略了異常處理)：

　　圖3 Petri針對系統中數據狀態的建模

　　圖4是進程級別數據狀態的建模，結合前文第一步子網逐層往下分解的結果，可以將整個數據處理的過程形成一張大的Petri網模型，然后對這張Petri網模型進行分析，就可以進行服務的識別。

　　圖4 服務按照服務狀態和數據狀態的建模

　　服務識別的過程可以按照以下步驟進行：

　　◆可重用性分析：橫向與其他數據的處理邏輯比較，通過Key-Value的方式對變遷輸入輸出的抽象，整理出可以重用的變遷，也就是可以轉化為服務的變遷。

　　◆服務粒度設計：服務是需要通過工作流引擎來進行流程控制的，變遷的粒度不應該太細。如果太細，可能會影響整個數據處理的性能，需要在流程監控與性能之間做權衡的考慮。

　　◆數據流程監控分析：有些變遷雖然不可重用，但由于需要對數據的流程進行監控，需要將它轉化為服務。

　　◆服務的校驗：完成服務的識別后，可以通過Petri建模對服務進行建模。一方面，需要對模型本身進行校驗，Petri可以提供形式化方法，以數學為理論基礎，為系統設計的正確性、安全性提供了一種有效的驗證手段[6];另一方面，需要考慮是否滿足工作流引擎的需要，對于自動工作流的系統，服務的Petri模型一定是同時關注服務狀態和數據狀態的(見圖4)，如果不滿足這個條件，那么服務是無法被工作流引擎所調度的。

　　使用Petri建模將變遷組裝成服務，可以很好地貫徹SOA組件能力開放為服務能力的理念，可重用的組件能力映射為可重用的子網，服務接口的抽象可以映射為輸入令牌和輸出令牌的抽象。由于Petri網建模的本質就是事件驅動的概念，因此能夠符合工作流中間件的邏輯，也便于工作流中間件對服務控制和監控。

　　3.3 使用Petri中間件進行流程管理

　　使用Petri的另外一個優勢就是可以采用引入中間件的概念，構建內部的流程管理平臺。Petri的令牌驅動模式能夠很好地抽象自動流程較多的系統。對于流程管理，其核心是判斷流程中的每個環節下一步該做什么，這點可以通過Petri圖令牌的當前位置來體現，如果某變遷的上游庫所都有令牌，則接收上游庫所的令牌，觸發變遷點火，再由變遷將下游所有庫所的令牌屬性賦值。

　　按照上述思路可以構建一個Petri中間件，在界面上進行Petri建模，并定義好變遷的輸入輸出。應用(HLA)使用中間件提供的API進行研發。實際運行時，應用通過中間件的Agent與Master進行交互，完成流程控制與流程監控的目的，如圖5所示：

　　圖5 Petriware中間件體系架構

　　(1)Petri中間件的功能架構

　　由于Petri本身就是使用事件驅動的概念來進行建模，所以在SOA服務用Petri完成建模后，直接可以為Petri中間件服務，不需要考慮設計層面的服務與有中間件參與的服務的轉變。Petri的建模圖形也完全可以表達應用邏輯，通過應用與中間件的交互，做到對于流程和應用的監控。

　　Petri中間件的功能架構如圖6所示：

　　圖6 Petri中間件的功能架構

　　Petri中間件由Petri網建模、Petri網調度控制、Petri網接入服務、監控服務組成，各功能模塊的功能簡述如下：

　　◆Petri網建模：以Petri網數據模型為基礎，提供Petri網設計與配置的可視化設計管理工具;

　　◆Petri網調度控制：以Petri網設計與配置為依據，驅動令牌在庫所間進行流轉的同時實現業務邏輯控制與實現;

　　◆Petri網接入服務：以標準化的API接口，統一規范應用的接入，降低系統應用與控制的耦合性;

　　◆監控服務：以Petri網為基礎，對系統進行抽象并分層監控與管理，展示系統運行態全境。

　　(2)Petri中間件調度控制

　　在系統流程的開發中，中間件可將應用作為令牌(業務數據)的處理者，應用負責消耗中間件分配的令牌，完成指定的業務邏輯，并生成新的令牌反饋業務處理結果。因此，在流程的處理中，可以認為變遷是業務能力在Petri圖中的表示元素，其與應用之間存在特定的對應關系。

　　在流程的設計階段，根據業務流程控制的需要，設計者需為流程中不同的變遷指定待實現的功能，并為其指定輸入與輸出的內容。即設計者需為業務能力，也就是變遷指定輸入內容(輸入令牌屬性)、輸出內容(輸出令牌屬性)。

　　在流程的運行階段，中間件根據已設計流程配置，驅動令牌在不同變遷間的流轉，以完成業務功能。即中間件負責指導應用接下來的變遷，并將上游變遷輸出的令牌發送給應用程序;應用程序接收到中間件發送的應該執行的變遷以及發送的令牌后，從令牌中獲取設計時指定的令牌屬性，進行相應的業務處理。應用程序業務處理結束后，中間件負責告知應用程序，新增令牌并設置設計時指定的令牌屬性后，將令牌發送給中間件。

　　4 結束語

　　由于自動工作流較多的系統偏向于數據的流轉，在這類系統中使用目前常用的建模工具會使服務識別過程過于復雜和繁瑣。Petri建模是從子網到原子變遷的逐層分解、再由變遷組裝成服務，其整個過程符合SOA架構設計的原則，將Petri建模應用于SOA服務識別，可簡化分析過程，提高架構設計的效率;同時，在開發過程中可以用Petri構建中間件，直接用于SOA的流程監控和業務監控。因此，基于Petri建模在自動工作流較多的系統中存在優勢。如果進一步考慮Petri與SOA架構中ESB理念結合，Petri網也可以在ESB模式中有相當廣闊的前景。