Drools團隊在其Drools rule的基礎上也推出了工作流項目-Drools Flow，Drools被JBoss收購後，現在與jBPM應該說是同一個爹媽養的了，那麼Drools團隊為什麼執意又開發一個工作流項目呢？這個 Drools Flow又有那些新的特性或吸引人的地方呢？下面是筆者翻譯的Drools官方首頁（http://www.jboss.org/drools/drools-flow.html ）上的關于Drools Flow的特性介紹，以飨讀者，有翻譯的不當之處還望大家批評指正。
ps:TMD,他們官方網頁上竟然也有很多錯誤單詞
,還有一些語句真TMD的難翻譯，是偶水準的問題？
豐富的模組化支援
規則內建
統一标準的API和工具
可插入式的工作項
人工任務
Guvnor內建
調試
相關審計
業務活動監控
業務流程模組化标注
Drools Flow和jBPM
Drools Flow為Drools平台提供了工作流或者（業務）流程能力。一個業務流程或者工作流使用一個流程圖表描述了一系列需要執行的步驟的順序。這使得它更容易來描述一個各種不同任務的複雜組合。流程在描述基于狀态的，長時間運作的過程時特别有用。Drools Flow允許最終使用者使用這些流程來指定，執行和監控（一部分）他們的業務邏輯。Drools Flow流程架構可以很容易地嵌入到任何的Java應用中（作為一個簡單的Java元件）或者能夠以一個伺服器環境的模式獨立運作。
在以下的章節中，我們将要強調Drools Flow架構的的最重要的特性。
豐富的模組化支援
Drools Flow提供了必要的建構區塊，使得最終使用者通過在他們的畫闆上簡單地拖拽來建構他們的業務流程。這不僅包含标準的節點類型例如開始/結束節點或者分裂/會聚節點（對應于分支/t同步），而且包含合并了等待狀态，計時器，事件，組合節點等的更進階的節點。每個不同的節點類型都在下面的Drools Flow手冊中進行了詳細的解釋。
下面的實作是基于一個統一的流程架構來實作的，這個流程架構支援在同一個執行引擎上執行不同的流程模型。流程模型是基于簡單節點，連接配接和上下文的，這使得它容易地作為一個整體将新的節點類型引入已經存在的流程語言，甚至完全不同的語言。下面的架構為非功能性的關注例如持久化，事務，事件等提供了一般的解決方案。例如，我們已經擴充了Drools Flow來支援特定的OSWorkflow的節點，為已經存在的OSWorkflow使用者提供一個到Drools Flow流程引擎的簡單的遷移路徑。
規則內建
當談到定義業務邏輯時，流程和規則通常作為兩個不同的範式被關聯在一起。那些正在定義他們應用中的業務邏輯的最終使用者通常不願意被強制使用一種範式，而是想為他們邏輯的每一個部分選擇最适合的範式。業務流程和業務規則引擎的松耦合或許可以在某些案例中改進這種情況，但是這種途徑不允許流程和規則之間進行更進階的互動，然後将這個責任推給了內建這些産品的最終使用者。
我們認為最終使用者應該被允許可以無縫地結合流程和規則。這意味着：
? 規則可以定義哪些流程被調用
? （進階别的，領域特定的）規則可以指定那些流程中的決策
? 規則可以增大（或者覆寫）流程中的特定行為(例如處理異常的事例)
? 配置設定規則可以用來給（人工的）任務指定執行者
? 規則可以用來動态地更改流程的行為
? 非功能性的關注點可以從流程和現代化的使用規則中被移除
? 等
結論是，你的業務流程變得更适應改變。
統一标準的API和工具
能夠在運作期的引擎中內建流程和規則是無論如何也不夠的。最終使用者的學習曲線必須是盡可能地低。如果流程和規則被當作是完全不同的資産，那麼使用者負責學習，內建和管理兩個不同的産品。我們仍然認為在一個面向知識的途徑中，應用程式不是面向流程或者面向規則的，但是使用者可以在不同的範式中選擇，用以表現他們的業務邏輯。使用者面臨的所有的工具和接口，支援一個統一的環境的概念貫穿于整個的知識生命周期。
例如，下面的代碼片段展示了怎樣給一個知識基礎增加一個流程或規則是完全相同的：
KnowledgeBuilder b = KnowledgeBuilderFactory.newKnowledgeBuilder();
b.add(ResourceFactory.newClassPathResource("MyProcess.rf"), ResourceType.DRF);
b.add(ResourceFactory.newClassPathResource("MyRules.drl"), ResourceType.DRL);
同樣，我們提供了一個類似的API與運作期引擎進行互動，監聽由引擎産生的事件等。工具以一個類似的方式支援所有不同類型的知識（例如流程，規則，決策表等）。
可插入式的工作項
Drools Flow提供了必要的構模組化塊以不同的方式将任務組合為一個流程，需要被執行的任務通常是領域特定的。領域特定語言定位于一個特定的應用領域，是以能夠提供與使用者試圖解決的問題很相近的基礎結構。這使得流程能夠被更容易地了解并且自動文檔化。Drools Flow允許使用者通過定制可以很容易地擴充節點的調色闆，領域特定的工作項，如下圖所示，是利用在醫療領域的環境中的特定節點來模組化護理任務，處方，通知等。
這個示例也展示了一些檔案的自動處理：檔案查找，日志并且在歸檔，複制和發郵件之前驗證它們。
這些可插入式的工作項是：
? 領域特定
? 聲明性的（什麼，不是怎樣）
? 高層級（不是編碼）
? 對于上下文的定制（例如，測試）
這些工作項可以使它很容易地，以一個非常友好的方式內建外部的服務到你的業務流程中。我們目前為這些任務提供了預設的實作：
? 發送郵件
? 檔案查找
? FTP
? Google 月曆
? 即時消息
? REST服務
? REST feeds
? 建立歸檔
? 執行系統指令
? 資料轉化
通過社群的幫助，我們希望進一步地擴充這些預設的支援服務。
人工任務
業務流程的一個重要的方面就是人工任務管理。而一個流程中的某些工作可以被自動地執行，另一些任務需要與人工的參與者協同執行。Drools Flow通過一個特定的人工任務節點支援流程内部的人工任務的使用，這個人工任務節點代理這個互動。這個節點允許流程設計者來定義任務類型，參與者，與這個任務相關的資料等。
既然這個人工任務節點作為一個可插入式的工作項（參考上面）來實作，是以使用者可以內建任何他們想要的人工任務管了解決方案（後端的 與/或 使用者接口）。我們基于WS-HumanTask規範提供了一個預設的實作。這個規範描述了任務的生命周期和怎樣與任務管理服務（查詢任務，改變狀态等）做互動。
Guvnor（Guvnor是Drools的另一個開源項目，是一個管理大量規則的中央知識倉庫-譯者注）內建
Drools Guvnor提供了一個（以邏輯為中心的）倉庫用來存儲你的業務知識，還有一個基于web的環境，允許業務使用者來檢視和（在一定的限制下）有可能直接地更新業務邏輯。
流程可以被上傳到Guvnor，并且可以手動地，或者使用我們的Eclipse Guvnor工具增加一個知識包（與其它的知識資産相結合，例如規則，決策表等等）。這使得管理你公司的業務邏輯更加的容易，同時也更容易被業務使用者所了解。
(click to enlarge)
調試
Drools Eclipse IDE通過特定的視圖擴充了你通常的Eclipse調試體驗，這些視圖展示了目前正在運作的流程執行個體和它們所處的狀态。例如，下面的圖展示了一個流程中高亮的節點是正在執行并且等待被完成。
這使得它容易在執行期的任何點上發現你的應用的狀态，并且調試你的流程以防看到不期望的結果。注意，Drools IDE支援內建調試，這意味着你總是可以同步地看到你的所有的流程和規則的狀态。
相關審計
Drools Flow在流程執行的過程中生成事件，這允許我們建立一個包含必要資訊的審計日志來計算出在運作期将要發生的事情。這個審計日志可以是一個簡單的XML檔案（如下所示，可以在Drools IDE中以一個樹形方式可視化地看到），或者存儲到一個資料庫中（為了進一步的處理）。
更重要的是，這些審計特性不僅提供了關于你的流程執行的資訊，而且也包含你的應用中的規則。終端使用者不必去嘗試手工地收集兩個日志檔案（一個來自于流程引擎，另一個來自于規則引擎），而是可以看到一個內建的審計日志，展示出在執行期發生的事件。
業務活動監控
你需要積極地監控你的流程來確定你能盡可能早地探測到任何的異常和對不期望事件的影響。基于對那些事件的監控，業務活動監控可以實時監控你的業務流程和直接幹預（甚至可能自動地）的可能性。Drools Flow允許使用者基于流程引擎生成的事件來定義報表，并且使用事件處理規則（Drools Fusion）在特定的條件下進行有可能地直接幹預。
基于Eclipse BIRT(業務職能報表工具)，使用者能夠建立報表用來展示他們業務的關鍵績效名額。使用包含所有流程曆史資訊（基于在資料庫中記錄了所有的運作期事件的一個曆史記錄器）和任何你可能想要加入的其它資料源的預定義資料集，你可以容易地定義你自己的報表。Eclipse BIRT架構允許你定義資料集，建立報表，包含圖表，報表預覽，用web頁導出它們等。下面的螢幕截圖展示了一個圖表的示例。
(click to enlarge)
BPMN（業務流程模組化标注）
BPMN(業務流程模組化标注)是一個被業務使用者用來模組化業務流程而廣泛使用的工作流标注語言。BPMN定義了術語，不同的節點類型，以及這些節點怎樣被可視化，等等。那些熟悉BPMN的人或許發現使用一個相似的可視化工具可以很容易實作一個可執行的流程（可能基于一個BPMN的流程框圖）。是以我們建立了一個BPMN的皮膚用來将Drools Flow的概念比對到等同的BPMN可視化視圖上。
(click to enlarge)
Drools Flow 和jBPM
Drools Flow是一個社群項目。jBPM仍舊是JBoss的唯一的官方工作流産品。Drools Flow和jBPM是兩個獨立的項目。這是由于在Drools内部面向知識的平台（和在流程與規則之間的進階內建）中流程內建的需求而導緻的結果，而這個需求沒有被jBPM提供。jBPM4和Drools Flow都是基于一個具有可插拔的執行行為的流程架構的，在jBPM中指的是PVM（流程虛拟機）。然而，直到現在為止，jBPM和Drools Flow都沒有能夠達成一個統一的合并方式。然而，我們确信Drools Flow提供了一些至少可與jBPM項目相比的特性。
Drools 5是一個完全從底層重構的（不是重新實作），具有一些新的公共API和與規則，流程，作為一等公民的事件一起設計的任何特性，在沒有确信是無縫的，統一的和正交的之前沒有添加任何新的特性。因為流程、規則和事件被內建到一個引擎中，所有這三個範式都可以友善地利用公共的特性（當你增加一個特性到某一個範式時，它也同樣可以被其它的範式所通路）。沒有理由為了多個api和部署辦法，這些api和部署辦法至多會在複雜性上加重使用者的負擔，最壞的情況下是當兩個不同的項目一起使用時引入不比對。
使用兩個不同提供商的産品時，傳統的方式是強制使用者以面向流程或者面向規則的辦法來工作，這種方式恰好成為了妨礙，在他們應該使用哪一種工具來模組化哪一部分時通常很混亂。Drools是從以規則為中心或者流程為中心改變為一個更接近于行為模組化的項目，這種行為模組化對于使用者來模組化他們想要的問題具有更大的靈活性，對于軟體開發建立了一個更全面的方法（此處的術語，“全面的”用來強調整體的和它的各部分互相依存的重要性）。
我們并不認為在以流程為中心的方式内部，僅有規則內建或者事件處理內建沒有被考慮或者在事後被添加進來，而不是從一開始就作為一個基本的原則添加進來。這通常意味着對于一個被一個流程節點（具有所有的比對，編組，取消編組和作為結果的一緻性問題）調用的無狀态的規則會話來說，規則內建是有限的。以流程為中心的方式同時也強制使用者學習重複的，而不是不同的，api和部署方法，也不會提供一個用于支援業務知識（例如作為Drools核心的，一個統一的知識倉庫和管理工具，或者提供重要的特性，例如相關的審計日志和報表）的生命周期的工具鍊。
基于這些原因和其它的有差別的特性，并且具有足夠的社群認可和需求，我們仍然希望Drools Flow作為一個JBoss産品而被采納。