NetBpm 組織架構（4）

標籤：des   blog   http   使用   os   strong   檔案   io   

大牛的傑作，贊一個

轉自：NetBPM工作流程的架構設計及實現淺析

 

讀前的話：由於本文涉及內容頗多，若有地方讀來不很明白，建議先跳過，整體上有個認識後，再回過頭來理解。作者認識有限，若有錯誤，歡迎斧正：）原文地址： NetBPM工作流程的架構設計及實現淺析（轉載請保留）

NetBPM組件介面

    NetBPM由一系列的組件構成，每一個組件都實現一個核心介面（採用Facade Pattern）。不同組件各自負責的核心功能根據WfMC規範而來。
    NetBPM介面圖：

 

1. 為流程開發人員提供的介面（Process Developer）：該介面負責載入流程定義到NetBpm引擎。首先，流程開發人員依照nPdl建立一個流程定義，並將其打包成流程定義壓縮包（該包包含一個商務程序的所有資訊），然後通過NetBPM Web介面或者是其他方式把流程定義壓縮包載入到NetBPM引擎，在載入過程中流程定義壓縮包將會被解析被儲存到NetBPM資料庫中。
2. 為使用者提供的介面（User）：這裡使用者表示執行流程的人。流程運行主要有2種行為：開始一個流程和執行一個活動（activity）。開始一個流程將建立該流程的一個流程執行個體，一個流程執行個體對應流程定義的一次執行。一個流程執行個體包含了一個或多個並行的flow-of-execution（見flow）。對於處在activity-state(活動節點，見nPdl)的flow，系統一定會指派一個具體的人（或者組）或者第三方來執行活動（activity）。執行活動是Execution Interface的第二種行為。當然了，運轉介面還會實現一些其他的方法如擷取工作清單，擷取有效流程定義列表等。  
3. 外部IT系統（External IT Systems）和NetBpm引擎之間的介面：外部IT系統能以2種方式實現和NetBPM的互動。
   •  系統發起互動：系統直接和外部IT系統互動。當系統想要觸發流程中的某一個action時，它必須使用上面提到的Execution Interface。
   •  流程發起互動：對於流程發起互動這種類型來說，需要有Interactors。這些Interactors是流程定義的一部分，它包含在流程定義包內（實際上Interactors就是能夠訪問FlowContext的.NET程式集，也就是我們後面要說到的包含委託類的程式集合）。Interactors在FlowContext（FLOW運行上下文環境）和外部IT系統之間建立起了通訊渠道。
4. 組織架構資料（Organisational Datastore）和NetBpm之間的介面：仔細想想，NetBpm是不是還缺了點什麼，沒錯，那就是組織架構的資訊：比如說人、團隊、部門、角色等。因為在現實情況中，對於不同的組織圖，組織架構資訊可能被儲存在不同類型的資料庫中，如LDAP系統，關係型資料庫等。為了讓NetBPM能夠在一個現實的組織架構中實現快速部署，NetBPM把所有的組織架構資訊都聚集在一個組件（Organisation Component）中。這種做法也就是我們通常說道會話門面模式（Session Façade Pattern），它使得NetBPM訪問來自不同資料來源的組織架構資訊變得更為簡單。

     下面我們逐步介紹NetBPM的各個組件，下面是NetBpm組件結構圖：

 定義組件(Definition Component）

     該組件實現核心介面IDefinitionSessionLocal，用來解析、載入流程定義壓縮包，並將其儲存到資料庫中。此外，它還提供擷取某個流程定義，擷取所有有效流程定義列表等和流程定義相關的方法。

運轉組件(Execution Component)

     該組件實現了核心介面IExecutionSessionLocal，它是NetBPM引擎推動核心，如前面如述，它主要實現2個方法：開始一個流程執行個體（Start ProcessInstance）和執行一個活動(Perform Activity）。另外，它還提供擷取使用者工作清單，取消流程執行個體等輔助流程運轉的方法。

組織架構組件(Organization Component)

     該組件實現介面IOrganisationSessionLocal，它把所有的組織架構資訊都聚集在一起，包括Users、Groups和Memberships。運轉組件在為activitie-state指定執行者時，需要有關user和group的資訊。這些資訊將以唯讀模式由組織架構組件向運轉組件提供。下面是NetBPM預設的組織架構組織資料模型。在此基礎上，我們可以很方便的實現自訂的適合實際項目需求的組織架構組件，以和我們的使用者資料庫或者是LDAP系統相關聯。

     NOTE：NetBPM源碼中實現的只是一個簡單的組織架構模型，但它提供了一種思考方向，我們可以很方便在此基礎上進行擴充來實現滿足切實需求的自訂群組織架構組件：）

日誌組件(Log Component)

     該組件實現介面ILogSessionLocal，用來記錄工作流程引擎的操作痕迹，象屬性值的更新（如使用者提交的表單被上級打回重新填寫，那麼就會出現多次表單資料，這就是一種屬性更新），委託類的調用情況等都會被記錄下來儲存到資料庫中。

任務調度組件(scheduler component)

     該組件實現介面ISchedulerSessionLocal，在現實的商務程序中，我們經常會遇到需要定時觸發某個任務的需求，任務調度組件正是作用於此。引擎或者是第三方把需要在某個時刻執行的任務資訊（包括任務執行環境、執行時間等）封裝成Job儲存到資料庫中。任務調度組件將按照指定的時間間隔不停的掃描任務表，根據執行時間對比來執行定時到了的Job。

管理監控組件(Admin Component)

     該組件用來對流程定義，流程執行個體執行情況等進行監控。（源碼待完善）下面是NetBpm核心項目在Visual 該組件用來對流程定義，流程執行個體執行情況等進行監控。（源碼待完善）

 下面是NetBPM核心項目在Visual Studio解決方案中的源碼結構圖，所有組件都包含在Workflow檔案夾下，每一個檔案夾分別對應實現了一個核心組件。
 

 NetBpm中的幾個重要概念flow

     flow不知道翻譯為什麼好，在JBPM中叫做Token，翻譯為令牌，這裡我們就叫做flow吧。它代表activity-states（活動節點，見nPdl）的一個“thread of execution”，相當於是一次流程執行個體執行過程中在流程定義模板中的令牌（還真難描述清楚，看下面一起理解：））。前面說了，一個流程執行個體代表一個流程定義的一次執行。如所示，流程執行個體的狀態可以看成是一顆flows樹。 

      當開始一個流程執行個體後，在start-state(開始節點，見nPdl，start-state實際上可以看做是一種特殊的activity-state)引擎將自動產生一個名為root的flow。flow中包含了該流程執行個體的相關資訊，如屬性值、流程定義資訊、flow所在activity-state的執行者等。root flow在遇到fork（分散節點，見nPdl）之前，將更新其帶有的即時資訊（如執行者、屬性值等），這些即時資訊隨著流程的運轉而變化。遇到fork後，根據ForkHandler委託類，root flow將分散成若干（>1個）forked flow（我們可以把root flow稱為這些forked flow的父flow）。若是分散為多個，則此時forked flow將並行運行，父flow則暫時退隱，只至到join（匯聚節點,見nPdl）匯聚，引擎將根據join定義的JoinHandler委託類來確定啟用父flow的機制。

     NOTE：關於fork和join機制，請參考nPdl fork、join小節一起理解。

attributes（屬性）

     attribute用來表示流程執行個體中的變數。一個attribute-instance(屬性執行個體，也就是屬性值)代表一次流程執行個體執行過程中對應屬性的執行個體。屬性一般有幾種，一種是activity-state（包括start-state）需要使用者或者第三方來填寫（更新）的屬性（一般對應使用者Web介面表單上要填寫的值），一種是角色對應的屬性，還有一些用作識別屬性（用來儲存某些資訊以方便後面的節點運用這些資訊處理邏輯判斷）。

1. serializer（屬性的序列化）: 
   
   Serializer和HtmlFormatter都是委託類，Serializer負責把屬性執行個體在.NET-Objects和文本兩種狀態間進行轉換，以方便把屬性值存入和取出資料庫。而Htmlformatter主要用來聯絡屬性值和Web Forms顯示時對應的http-text。
2. attribute的範圍:attribute-instances（屬性執行個體）和flow有關。在process-definition(流程定義根節點，見nPdl)節點中定義的attribute和root-flow關聯，而在concurrnet-block(並行運行塊，見nPdl)中定義的局部attribute執行個體則和forked flow關聯。一個flow能夠“看見”和它關聯的所有屬性以及該flow的父flow的所有屬性。

引擎運行時上下文環境（Execution Context）

     

因為圖片太大，關於繼承IHandlerContext的介面關係圖查看點擊這裡

     ExecutionContext（ExecutionContextImpl類型的對象，我們暫且翻譯為運行時上下文環境：）） 包含了引擎在運行時和流程執行個體相關的所有有用資訊（上文中提到的flowcontext就是一種ExecutionContext），它在委託類（包括流程定義壓縮包中程式集中定義的委託類）和流程引擎之間建立起了相互聯絡的渠道，這是非常關鍵的。如上面ExectutionContext 類圖所示，ExecutionContextImpl實現了下面這些介面：IAssignmentContext、IDecisionContext、IForkContext、IActionContext、IJoinContext、IProcessInvocationContext、ITaskContext，這些介面都是為匹配特定的委託類而設計，它們規範了一種特定的上下文環境，如IActionContext匹配action類型委託類，IDecisionContext匹配DecisionHandler類型委託類等，而ExectutionContext是所有這些特殊的運行時上下文環境的一個綜合。當引擎在運轉組件把ExectutionContext作為參數傳送到具體類型的委託類時（關鍵：這就是委託類和流程引擎建立聯絡的方式），ExecutionContext對象將“拆箱”成為特殊的Context，如：把ExecutionContext對象傳給action類型的委託類Run（）方法時，ExecutionContext對象將拆箱為ActionContext對象以限制其能夠調用的方法。

     如“繼承自IHandlerContext的介面”圖中所示，這些介面都繼承了同一個介面IHandlerContext。IHandlerContext是一個規範了最基本的委託類處理上下文環境的介面，實現該介面的繼承幾口也就都要實現IHandlerContext中定義的方法，當然每一種繼承它的特定介面又都可以具有其特定的方法。我們先看公用介面IHanlderContext類圖：如上IHandlerContext介面圖所示，這些介面都繼承了同一個介面IHandlerContext。IHandlerContext是一個規範了最基本的委託類處理上下文環境的介面，實現該介面繼承介面的類也就都實現了IHandlerContext中定義的方法。當然，每一種繼承它的特定介面又都可以具有其特定的方法。我們先看公用介面IHanlderContext類圖：

     大多數的方法，我們從方法名稱就可以看出其具體作用了，這裡重點介紹下GetAttribute（）方法和GetConfiguration（）方法，這是我們在寫委託類實現時，要經常用到的2個方法。GetAttribute（）用來擷取流程執行個體中的屬性值，包括流程前面處理者產生的屬性值（如使用者填寫表單的值）和前面處理引擎事件中設定的表示屬性值（註：IActionHandler具有SetAttribute（）方法，該方法經常用來識別屬性值，供後面程式邏輯用）等。而GetConfiguration（）用來擷取流程定義中設定的parameter(參數，請nPdlparameter小節)。

     下面再來看幾種典型的特定上下文環境介面：

• IAssignmentContext：為IAssignmentHandler委託類提供引擎上下文環境，該介面定義了擷取組織架構資訊的方法，具體實現方法見類圖。
• IActionContext：為action提供引擎上下文環境，注意其具有SetAttribute的方法，可以為流程執行個體中的屬性賦值，具體實現方法見類圖。
• IForkContext：為IForkHandler委託類提供引擎上下文環境，它定義了如何從父flow分散forked flow的方法，見類圖。
• IJoinContext：為IJoinHandler委託類提供引擎上下文環境，它定義了擷取其他並行flows的方法，見類圖。
• IProcessInvocationContext: 為IProcessInvocationHandler委託提供引擎上下文環境，實現方法見類圖。
• 其他的委託類型上下文環境除了實現基本IHandlerContext方法外，沒有特定的方法，請參考IHandlerContext方法。

委託類

     在前面我們一直提到委託類，那麼委託類到底是什麼呢？這裡委託的概念指的不是.NET Framework中delegate，這裡可以理解它為“委託、代為處理”這樣的概念就好。

     NetBPM被設計成通用的流程處理引擎，NetBPM核心執行引擎只負責處理最基本的商務程序邏輯，所有不定的邏輯都被委託給一系列的介面，這些介面稱作Delegation Interfaces（委託介面），而實現這些介面的類就是委託類。流程定義約定在什麼場合使用什麼委託類型，引擎和委託類如何關聯也在流程定義中完成。

    為了達到最大的可擴充性，流程開發人員在流程定義時可以選擇下面任意一種委託類實現方式：

1. 使用已經在NetBpm引擎中實現的有效委託類。（具有通用性的委託建議採用這種方式在引擎中定義，以便重用）
2. 使用自訂的委託類，以.NET程式集的形式通過流程定義壓縮包動態載入。

     正是方式2這種形式給NetBPM帶來了極大的靈活性，把只適合於某個特定流程的的程式邏輯（這些往往佔了大多數）以.NET程式集的形式定義在流程定義壓縮包中，NetBpm通過流程定義組件將其解析並儲存至資料庫。當引擎運轉流程需要調用委託類時，引擎利用反射技術執行個體化出委託類對象，然後利用上文介紹的運行時上下時環境（ExecutionContext）建立起委託類和引擎之間的互動渠道，這真是一個令人興奮的設計：）

     下面是NetBpm中的委託類型（建議和ExecutionContext一節一起理解）：

• AssignmentHandler：
         實現介面IAssignmentHandler, 它可以和組織架構中的IT-System相互連信，用來為activty-state指定執行者。IAssignmentHandler具有唯一的方法SelectActor(IAssignmentContextassignerContext)，其中的assignerContext是其和引擎聯絡的渠道;
• ActionHandler：實現介面IActionHandler，它用來執行一段流程引擎外完成的程式邏輯，關於action在哪裡執行，什麼時候執行等在流程定義中被定義。actions可以被看作一系列流程執行事件的偵聽介面，它具有方法Run(IActionContext actionContext)，actionContext是它和引擎聯絡的渠道。
• DecisionHandler：實現介面IDecisionHandler，它用來選擇決定走哪一條transition（邊,見nPdl），具有方法Decide(IDecisionContext decisionContext)，該方法返回選擇要走的邊的名稱，decisionContext是其和引擎聯絡的渠道。
• ForkHandler：實現介面IForkHandler，當執行到fork節點時，Forkhandler用來決定從fork流程的邊中哪些邊需要“forking”。它具有方法Fork(IForkContext forkContext)，forkContext是其和引擎聯絡的渠道。註：forkhandler可以在同一條邊上分散多個forked flow。
• JoinHandler：實現介面IJoinHandler，當執行到join時，JoinHandler決定是否要啟用父flow，它具有方法Join(IJoinContext joinContext)，joinContext是其和引擎聯絡的渠道。
• Serializer：實現介面ISerializer，具有方法Serialize(Object valueObject)和Deserialize(String text)，該委託介面負責用來轉換屬性值，把屬性值在.NET-objects（.NET對象）和text-format(文本)之間轉換。其中，text-format(文本)用來儲存屬性值到資料庫中。
• HtmlFormatter：實現介面IHtmlFormatter，該委託主要用來在屬性值和其相對應的web介面元素之間建立聯絡，同時負責解析web介面元素具有的值。若移植到ASP.NET平台，該介面建議重寫。
• ProcessInvocationHandler：實現介面IProcessInvocationHandler，該委託實現收集子流程的初始化資料、收集處理結果、指定完成子流程後要流入的邊等方法，processInvocationContext是其和引擎聯絡的渠道。

................///////////////////////////.............是否要添加委託類的例子

流程定義版本問題流程定義的名稱與版本

     包含在一個流程定義壓縮包中的資訊叫做流程定義。NetBpm中，流程是由欄位name來區分的，也就是說引擎根據流程的name來判斷兩個流程是否相等。在流程定義包中不能指定版本，當一個流程定義被引擎載入後，NetBpm將檢查是否有該流程定義的舊版本。如果有，NetBpm將自動化佈建該新載入進來的流程版本為所有存在的舊版本流程定義中最高版本數目基礎上加1。

流程執行與版本

     當調用運轉組件擷取流程定義列表方法時，只能擷取到每個流程的最高版本流程定義。這樣做保證了使用者總是從最新版本的流程定義開始一個流程執行個體。當新的流程版本載入到NetBpm時，所有正在啟動並執行舊版本的流程執行個體將保持在原來流程定義方式下運行。

委託類與版本

     關於版本的另外一個方面是委託類。不同版本流程定義的委託類不是共用的，也就是說每個流程在執行時只會“看到”它自己流程定義的委託類。 

異常處理機制

     NetBpm作為一個整合平台，當流程運行時，肯定會依賴公司很多其他的IT資源，一旦這些依賴導致流程執行時出現錯誤，NetBpm提供了3種解決機制：

1. 忽略錯誤
2. 把錯誤記錄檔記錄下來（預設採用的機制）
3. 錯誤執行復原操作（rollback）

    執行復原機制中，流程執行個體將會被復原到執行activity之前的狀態。如果是對NetBpm 調用Eecution Interface時發生流程錯誤，所有的流過的transition（邊）都會執行復原。

流程定義元素類圖

     關於流程定義的詳細情況，參見nPdl。

 

 

NetBpm中使用的架構或組件

     NetBpm中用到的架構、組件、工具比較多，它們大都是優秀的開源項目。如Castle，NHibernate，Log4Net, NVelocity，NUnit，NAnt等，不要被這些架構嚇倒，實際上，它們僅僅只是“架構”而已：）

IOC容器――Castle

     NetBpm使用了Castle架構，主要用它來實現IOC（控制反轉或者說依賴注入），以依賴注入的方式載入核心組件，如DBClassLoader，流程定義組件，運行組件，日誌組件，組織架構組件，任務調度組件等。在Web程式啟動的時候，根據設定檔，所有的核心組件都將註冊到Caslte IOC容器中，以後當需要使用某個組件的時候，只需利用系統提供的ServiceLocator（服務載入工具類）從容器中擷取執行個體即可。另外，在任務調度組件中也有用到Castle的Startable Facility（註：大家把facility理解為注入性質的，對Castle IOC核心容器的功能擴充組件。Castle本身內建實現了一些faciltiy，開發人員也可以自訂facility）,該facitlity主要用來自動運行程式（這裡用來自動間隔掃描任務表，進行任務調度）。

     Castle是.NET平台下一個功能強大的優秀開源架構，關於Castle的更多資訊，請看Castle官方網站。另外TerryLee的部落格中關於Castle的中文資源也很豐富。

資料持久層―― NHibernate

     NetBpm中NHibernate組件是作為Castle的一個facility存在的，它用來實現NetBpm資料持久層， 並方便的實現了事務支援。關於NHibernate的更多資訊，請看NHibernate官方網站，關於NHibernate作為Castle的facility相關請看這裡。

樣本web層――MonoRail

     大家在Demo示範體驗的時候，一定很奇怪，沒有看到熟悉的.aspx頁面，而是.rails頁面，為什麼呢？答案就是NetBPM的Web層採用的是MonoRail架構，而不是我們熟悉ASP.NET架構。MonoRail是Caslte架構下針對web層編程的一個子架構，它從Ruby Rails擷取靈感而來，採用架構清晰分工明確的MVC模式。NetBPM採用的使用NVelocity作為頁面解析引擎的MonoRail，它只是對NetBPM核心API的一個Web介面示範樣本，用來告訴我們該怎樣從Web層調用NetBpm API。所以，雖然MonoRail有其獨到之處，但是在其被普及並有好用工具支援之前，我們只需簡單瞭解下它的運行機制，用以熟悉web層如何利用NetBpm API，不需要瞭解它太多。用我們熟悉的ASP.NET實現Web部分顯然是更好的選擇：）。關於MonoRail的更多資訊，請看這裡。

系統日誌 ――Log4Net

     log4net大家一定不陌生了，NetBpm使用它來記錄系統日誌，關於log4net的更多資訊，請看Log4Net官方網站，網上中文資源也很豐富.

單元測試工具――NUnit

     單元測試工具NUnit一直是大家用來單元測試的利器。 NetBPM源碼中已經建有幾個測試工程。關於NUnit的更多資訊，請看NUnit官方網站。

     註：移植到.NET Framework 2.0下，可能要更改其版本。

後記

     NetBPM的設計無疑是巧妙的，但是現階段的它顯然還不是一個完美的工作流程引擎，缺乏如JBOSS這樣的強大後盾作支援，中途又遇上強敵WF，NetBPM遠沒有其兄弟JBPM風光，更新沒有它快（JBPM已經出3.0版本了），擷取的支援也少許多， 但是.NET平台下能有這樣一個優秀的開源工作流程項目是十分可貴的，如果您正在WF中苦苦掙紮，也許，開源的NetBPM將帶給您一個驚喜：） 

待寫：NetBPM工作流程nPdl詳解，一個NetBPM現實生活中請假審批樣本