java規則引擎你應該知道的幾點東西，不妨來看看呦！

由于時間的問題，已經很久沒有來寫東西，突然寫起來還有點手生，今天來給大家講一下有關java的規則引擎的一些東西，比如向開源的drools等等，好了，廢話不多說了，大家一起來看看。

規則引擎的原理

　　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所示。

　 　當引擎執行時，會根據規則執行隊列中的優先順序逐條執行規則執行執行個體，由于規則的執行部分可能會改變工作區的資料對象，進而會使隊列中的某些規則執行實 例因為條件改變而失效，必須從隊列中撤銷，也可能會激活原來不滿足條件的規則，生成新的規則執行執行個體進入隊列。于是就産生了一種“動态”的規則執行鍊，形 成規則的推理機制。這種規則的“鍊式”反應完全是由工作區中的資料驅動的。

　　任何一個規則引擎都需要很好地解決規則的推理機制和規則 條件比對的效率問題。規則條件比對的效率決定了引擎的性能，引擎需要迅速測試工作區中的資料對象，從加載的規則集中發現符合條件的規則，生成規則執行實 例。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知識的朋友給你們推薦59biye網的java教程，好了希望對你們有所幫助。