目前，Java社區推動並發展了一種引人注目的新技術——Java規則引擎（Rule Engine）。利用它就可以在應用系統中分離商業決策者的商業決策邏輯和應用開發者的技術決策，並把這些商業決策放在中心數據庫或其他統一的地方，讓它們能在運行時可以動態地管理和修改，從而為企業保持靈活性和競爭力提供有效的技術支持。
規則引擎的原理
1、基於規則的專家系統（RBES）簡介
Java規則引擎起源於基於規則的專家系統，而基於規則的專家系統又是專家系統的其中一個分支。專家系統屬於人工智能的范疇，它模仿人類的推理方式，使用試探性的方法進行推理，並使用人類能理解的術語解釋和證明它的推理結論。為了更深入地了解Java規則引擎，下面簡要地介紹基於規則的專家系統。RBES包括三部分：Rule Base（knowledge base）、Working Memory（fact base）和Inference Engine。它們的結構如下系統所示：
圖1：基於規則的專家系統構成
如圖1所示，推理引擎包括三部分：模式匹配器（Pattern Matcher）、議程（Agenda）和執行引擎（Execution Engine）。推理引擎通過決定哪些規則滿足事實或目標，並授予規則優先級，滿足事實或目標的規則被加入議程。模式匹配器決定選擇執行哪個規則，何時執行規則；議程管理模式匹配器挑選出來的規則的執行次序；執行引擎負責執行規則和其他動作。
和人類的思維相對應，推理引擎存在兩者推理方式：演繹法（Forward-Chaining）和歸納法（Backward-Chaining）。演繹法從一個初始的事實出發，不斷地應用規則得出結論（或執行指定的動作）。而歸納法則是根據假設，不斷地尋找符合假設的事實。Rete算法是目前效率最高的一個Forward-Chaining推理算法，許多Java規則引擎都是基於Rete算法來進行推理計算的。
推理引擎的推理步驟如下：
(1)將初始數據（fact）輸入Working Memory。
(2)使用Pattern Matcher比較規則庫（rule base）中的規則（rule）和數據（fact）。
(3)如果執行規則存在沖突（conflict），即同時激活了多個規則，將沖突的規則放入沖突集合。
(4)解決沖突，將激活的規則按順序放入Agenda。
(5)使用執行引擎執行Agenda中的規則。重復步驟2至5，直到執行完畢所有Agenda中的規則。
上述即是規則引擎的原始架構，Java規則引擎就是從這一原始架構演變而來的。
2、規則引擎相關構件
規則引擎是一種根據規則中包含的指定過濾條件，判斷其能否匹配運行時刻的實時條件來執行規則中所規定的動作的引擎。與規則引擎相關的有四個基本概念，為更好地理解規則引擎的工作原理，下面將對這些概念進行逐一介紹。
1)信息元（Information Unit）
信息元是規則引擎的基本建築塊，它是一個包含了特定事件的所有信息的對象。這些信息包括：消息、產生事件的應用程序標識、事件產生事件、信息元類型、相關規則集、通用方法、通用屬性以及一些系統相關信息等等。
2)信息服務（Information Services）
信息服務產生信息元對象。每個信息服務產生它自己類型相對應的信息元對象。即特定信息服務根據信息元所產生每個信息元對象有相同的格式，但可以有不同的屬性和規則集。需要注意的是，在一台機器上可以運行許多不同的信息服務，還可以運行同一信息服務的不同實例。但無論如何，每個信息服務只產生它自己類型相對應的信息元。
3)規則集（Rule Set）
顧名思義，規則集就是許多規則的集合。每條規則包含一個條件過濾器和多個動作。一個條件過濾器可以包含多個過濾條件。條件過濾器是多個布爾表達式的組合，其組合結果仍然是一個布爾類型的。在程序運行時，動作將會在條件過濾器值為真的情況下執行。除了一般的執行動作，還有三類比較特別的動作，它們分別是：放棄動作（Discard Action）、包含動作（Include Action）和使信息元對象內容持久化的動作。前兩種動作類型的區別將在2.3規則引擎工作機制小節介紹。
4)隊列管理器（Queue Manager）
隊列管理器用來管理來自不同信息服務的信息元對象的隊列。
下面將研究規則引擎的這些相關構件是如何協同工作的。
如圖2所示，處理過程分為四個階段進行：信息服務接受事件並將其轉化為信息元，然後這些信息元被傳給隊列管理器，最後規則引擎接收這些信息元並應用它們自身攜帶的規則加以執行，直到隊列管理器中不再有信息元。
圖2：處理過程協作圖
3、規則引擎的工作機制
下面專門研究規則引擎的內部處理過程。如圖3所示，規則引擎從隊列管理器中依次接收信息元，然後依規則的定義順序檢查信息元所帶規則集中的規則。如圖所示，規則引擎檢查第一個規則並對其條件過濾器求值，如果值為假，所有與此規則相關的動作皆被忽略並繼續執行下一條規則。如果第二條規則的過濾器值為真，所有與此規則相關的動作皆依定義順序執行，執行完畢繼續下一條規則。該信息元中的所有規則執行完畢後，信息元將被銷毀，然後從隊列管理器接收下一個信息元。在這個過程中並未考慮兩個特殊動作：放棄動作（Discard Action）和包含動作（Include Action）。放棄動作如果被執行，將會跳過其所在信息元中接下來的所有規則，並銷毀所在信息元，規則引擎繼續接收隊列管理器中的下一個信息元。包含動作其實就是動作中包含其它現存規則集的動作。包含動作如果被執行，規則引擎將暫停並進入被包含的規則集，執行完畢後，規則引擎還會返回原來暫停的地方繼續執行。這一過程將遞歸進行。
圖3：規則引擎工作機制
Java規則引擎的工作機制與上述規則引擎機制十分類似，只不過對上述概念進行了重新包裝組合。Java規則引擎對提交給引擎的Java數據對象進行檢索，根據這些對象的當前屬性值和它們之間的關系，從加載到引擎的規則集中發現符合條件的規則，創建這些規則的執行實例。這些實例將在引擎接到執行指令時、依照某種優先序依次執行。一般來講，Java規則引擎內部由下面幾個部分構成：工作內存（Working Memory）即工作區，用於存放被引擎引用的數據對象集合；規則執行隊列，用於存放被激活的規則執行實例;靜態規則區，用於存放所有被加載的業務規則，這些規則將按照某種數據結構組織，當工作區中的數據發生改變後，引擎需要迅速根據工作區中的對象現狀，調整規則執行隊列中的規則執行實例。Java規則引擎的結構示意圖如圖4所示。
圖4：Java規則引擎工作機制
當引擎執行時，會根據規則執行隊列中的優先順序逐條執行規則執行實例，由於規則的執行部分可能會改變工作區的數據對象，從而會使隊列中的某些規則執行實例因為條件改變而失效，必須從隊列中撤銷，也可能會激活原來不滿足條件的規則，生成新的規則執行實例進入隊列。於是就產生了一種“動態”的規則執行鏈，形成規則的推理機制。這種規則的“鏈式”反應完全是由工作區中的數據驅動的。
任何一個規則引擎都需要很好地解決規則的推理機制和規則條件匹配的效率問題。規則條件匹配的效率決定了引擎的性能，引擎需要迅速測試工作區中的數據對象，從加載的規則集中發現符合條件的規則，生成規則執行實例。1982年美國卡耐基·梅隆大學的Charles L. Forgy發明了一種叫Rete算法，很好地解決了這方面的問題。目前世界頂尖的商用業務規則引擎產品基本上都使用Rete算法。
Java規則引擎API——JSR-94
為了使規則引擎技術標准化，Java社區制定了Java規則引擎API（JSR94）規范。它為Java平台訪問規則引擎定義了一些簡單的API。
Java規則引擎API在javax.rules包中定義，是訪問規則引擎的標准企業級API。Java規則引擎API允許客戶程序使用統一的方式和不同廠商的規則引擎產品交互，就如同使用JDBC編寫獨立於廠商訪問不同的數據庫產品一樣。Java規則引擎API包括創建和管理規則集合的機制，在工作區中添加，刪除和修改對象的機制，以及初始化，重置和執行規則引擎的機制。
1、Java規則引擎API體系結構
Java規則引擎API主要由兩大類API組成: 規則管理API(The Rules Administrator API)和運行時客戶API(The Runtime ClIEnt API)。
1)規則管理API
規則管理API在Javax.rules.admin中定義，包含裝載規則以及與規則對應的動作(執行集 execution sets)以及實例化規則引擎。規則可以從外部資源中裝載，比如URI，Input streams， XML streams和readers等等。同時規則管理API還提供了注冊和取消注冊執行集以及對執行集進行維護的機制。使用admin包定義規則有助於對客戶訪問運行規則進行控制管理，它通過在執行集上定義許可權使得未經授權的用戶無法訪問受控規則。
規則管理API使用類RuleServiceProvider來獲得規則管理器(RuleAdministrator)接口的實例。該接口提供方法注冊和取消注冊執行集。規則管理器提供了本地和遠程的RuleExecutionSetProvider，它負責創建規則執行集（RuleExecutionSet）。規則執行集可以從如XML streams， binary streams等來源中創建。這些數據來源及其內容經匯集和序列化後傳送到遠程的運行規則引擎的服務器上。在大多數應用程序中，遠程規則引擎或遠程規則數據來源的情況並不多。為了避免這些情況中的網絡開銷，API規定了可以從運行在同一JVM中規則庫中讀取數據的本地RuleExecutionSetProvider。規則執行集接口除了擁有能夠獲得有關規則執行集的方法，還有能夠檢索在規則執行集中定義的所有規則對象。這使得客戶能夠知道規則集中的規則對象並且按照自己需要來使用它們。
2)運行時客戶API
運行時API在Javax.rules包中定義，為規則引擎用戶運行規則獲得結果提供了類和方法。運行時客戶只能訪問那些使用規則管理API注冊過的規則，運行時API幫助用戶獲得規則會話，並在這個會話中執行規則。
運行時API提供了對廠商規則引擎API的訪問方法，這類似於JDBC。類RuleServiceProvider提供了對具體規則引擎實現的運行時和管理API的訪問，規則引擎廠商通過該類將其規則引擎實現提供給客戶，並獲得RuleServiceProvider唯一標識規則引擎的URL。此URL的標准用法是使用類似於“com.mycompany.myrulesengine.rules.RuleServiceProvider”這樣的Internet域名空間，這保證了訪問URL的唯一性。類RuleServiceProvider內部實現了規則管理和運行時訪問所需的接口。所有的RuleServiceProvider要想被客戶所訪問都必須用RuleServiceProviderManager進行注冊，注冊方式類似於JDBC API的DriverManager和Driver。
運行時接口是運行時API的關鍵部分。運行時接口提供了用於創建規則會話(RuleSession)的方法，規則會話是用來運行規則的。運行時API同時也提供了訪問在service provider注冊過的所有規則執行集(RuleExecutionSets)。規則會話接口定義了客戶使用的會話的類型，客戶根據自己運行規則的方式可以選擇使用有狀態會話或者無狀態會話。無狀態會話的工作方式就像一個無狀態會話bean。客戶可以發送單個輸入對象或一列對象來獲得輸出對象。當客戶需要一個與規則引擎間的專用會話時，有狀態會話就很有用。輸入的對象通過addObject() 方法可以加入到會話當中。同一個會話當中可以加入多個對象。對話中已有對象可以通過使用updateObject()方法得到更新。只要客戶與規則引擎間的會話依然存在，會話中的對象就不會丟失。
RuleExecutionSetMetaData接口提供給客戶讓其查找規則執行集的元數據(metadata)。元數據通過規則會話接口(RuleSession Interface)提供給用戶。
2、Java規則引擎API安全問題
規則引擎API將管理API和運行時API加以分開，從而為這些包提供了較好粒度的安全控制。規則引擎API並沒有提供明顯的安全機制，它可以和J2EE規范中定義的標准安全API聯合使用。安全可以由以下機制提供，如Java 認證和授權服務 (JAAS)，Java加密擴展(JCE)，Java安全套接字擴展(JSSE)，或者其它定制的安全API。使用JAAS可以定義規則執行集的許可權限，從而只有授權用戶才能訪問。
3、異常與日志
規則引擎API定義了javax.rules.RuleException作為規則引擎異常層次的根類。所有其它異常都繼承於這個根類。規則引擎中定義的異常都是受控制的異常(checked exceptions)，所以捕獲異常的任務就交給了規則引擎。規則引擎API沒有提供明確的日志機制，但是它建議將Java Logging API用於規則引擎API。
JSR 94 為規則引擎提供了公用標准API，僅僅為實現規則管理API和運行時API提供了指導規范，並沒有提供規則和動作該如何定義以及該用什麼語言定義規則，也沒有為規則引擎如何讀和評價規則提供技術性指導。
結束語
規則引擎技術為管理多變的業務邏輯提供了一種解決方案。規則引擎既可以管理應用層的業務邏輯又可以使表示層的頁面流程可訂制。這就給軟件架構師設計大型信息系統提供了一項新的選擇。而Java規則引擎在Java社區制定標准規范以後必將獲得更大發展。
