????????本文對Java規則引擎與其API(JSR-94)及相關實現做了較詳細的介紹，對其體系結構和API應用有較詳盡的描述，并指出Java規則引擎,規則語言，JSR-94的相互關系,以及JSR-94的不足之處和展望。

　　復雜企業級項目的開發以及其中隨外部條件不斷變化的業務規則(business logic),迫切需要分離商業決策者的商業決策邏輯和應用開發者的技術決策，并把這些商業決策放在中心數據庫或其他統一的地方，讓它們能在運行時（即商務時間）可以動態地管理和修改從而提供軟件系統的柔性和適應性。規則引擎正是應用于上述動態環境中的一種解決方法。

　　本文第一部分簡要介紹了規則引擎的產生背景和基于規則的專家系統，第二部分介紹了什么是規則引擎及其架構和算法，第三部分介紹了商業產品和開源項目實現等各種Java規則引擎，第四部分對Java規則引擎API（JSR-94）作了詳細介紹，講解了其體系結構，管理API和運行時API及相關安全問題，第五部分則對規則語言及其標準化作了探討，第六部分給出了一個使用Java規則引擎API的簡單示例，第七部分給予小結和展望。

　　1、 介紹

　　1.1 規則引擎產生背景

　　企業管理者對企業級IT系統的開發有著如下的要求：(1)為提高效率，管理流程必須自動化，即使現代商業規則異常復雜(2)市場要求業務規則經常變化，IT系統必須依據業務規則的變化快速、低成本的更新(3)為了快速、低成本的更新，業務人員應能直接管理IT系統中的規則，不需要程序開發人員參與。

　　而項目開發人員則碰到了以下問題:(1)程序=算法+數據結構，有些復雜的商業規則很難推導出算法和抽象出數據模型(2)軟件工程要求從需求->設計->編碼，然而業務規則常常在需求階段可能還沒有明確，在設計和編碼后還在變化，業務規則往往嵌在系統各處代碼中(3)對程序員來說，系統已經維護、更新困難，更不可能讓業務人員來管理。

　　基于規則的專家系統的出現給開發人員以解決問題的契機。規則引擎由基于規則的專家系統中的推理引擎發展而來。下面簡要介紹一下基于規則的專家系統。

　　1.2 基于規則的專家系統(RBES)

　　專家系統是人工智能的一個分支，它模仿人類的推理方式，使用試探性的方法進行推理，并使用人類能理解的術語解釋和證明它的推理結論。專家系統有很多分類：神經網絡、基于案例推理和基于規則系統等。

　　RBES包括三部分：Rule Base（knowledge base）、Working Memory（fact base）和Inference Engine（推理引擎）。它們的結構如下所示：

圖1.基于規則的專家系統組成


　　如上圖所示，推理引擎包括三部分：Pattern Matcher、Agenda和Execution Engine。Pattern Matcher何時執行哪個規則；Agenda管理PatternMatcher挑選出來的規則的執行次序；Execution Engine負責執行規則和其他動作。

　　推理引擎通過決定哪些規則滿足事實或目標，并授予規則優先級，滿足事實或目標的規則被加入議程。存在兩者推理方式：演繹法（Forward-Chaining正向鏈）和歸納法（Backward-Chaining反向鏈）。演繹法從一個初始的事實出發，不斷地應用規則得出結論（或執行指定的動作）。而歸納法則是從假設出發，不斷地尋找符合假設的事實。
　　2、 規則引擎

　　2.1 業務規則
　
　　一個業務規則包含一組條件和在此條件下執行的操作，它們表示業務規則應用程序的一段業務邏輯。業務規則通常應該由業務分析人員和策略管理者開發和修改，但有些復雜的業務規則也可以由技術人員使用面向對象的技術語言或腳本來定制。業務規則的理論基礎是:設置一個或多個條件，當滿足這些條件時會觸發一個或多個操作。

　　2.2 規則引擎

　　什么是規則引擎？規則引擎是如何執行規則的？這可以稱之為"什么"與"如何"的問題。到底規則引擎是什么還是目前業界一個比較有爭議的問題，在JSR-94種也幾乎沒有定義。可以這樣認為充分定義和解決了"如何"的問題，"什么"問題本質上也迎刃而解。也許這又是一種"先有蛋還是先有雞"哲學爭論。今后標準規則語言的定義和推出及相關標準的制定應該可以給這樣的問題和爭論劃上一個句號。本文中，暫且這樣述說什么是規則引擎：規則引擎由推理引擎發展而來，是一種嵌入在應用程序中的組件，實現了將業務決策從應用程序代碼中分離出來，并使用預定義的語義模塊編寫業務決策。接受數據輸入，解釋業務規則，并根據規則做出業務決策。

　　2.3 規則引擎的使用方式

　　由于規則引擎是軟件組件，所以只有開發人員才能夠通過程序接口的方式來使用和控制它，規則引擎的程序接口至少包含以下幾種API：加載和卸載規則集的API；數據操作的API；引擎執行的API。開發人員在程序中使用規則引擎基本遵循以下5個典型的步驟：創建規則引擎對象；向引擎中加載規則集或更換規則集；向引擎提交需要被規則集處理的數據對象集合；命令引擎執行;導出引擎執行結果，從引擎中撤出處理過的數據。使用了規則引擎之后，許多涉及業務邏輯的程序代碼基本被這五個典型步驟所取代。

　　一個開放的業務規則引擎應該可以"嵌入"在應用程序的任何位置，不同位置的規則引擎可以使用不同的規則集，用于處理不同的數據對象。此外，對使用引擎的數量沒有限制。

　　2.4 規則引擎架構與推理

　　規則引擎的架構如下圖所示：

圖2. 業務規則引擎架構


　　規則引擎的推理步驟如下：a. 將初始數據（fact）輸入至工作內存(Working Memory)。b. 使用Pattern Matcher將規則庫(Rules repository)中的規則（rule）和數據（fact）比較。c. 如果執行規則存在沖突（conflict），即同時激活了多個規則，將沖突的規則放入沖突集合。d. 解決沖突，將激活的規則按順序放入Agenda。e. 執行Agenda中的規則。重復步驟b至e，直到執行完畢Agenda中的所有規則。

　　任何一個規則引擎都需要很好地解決規則的推理機制和規則條件匹配的效率問題。

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

　　規則條件匹配的效率決定了引擎的性能，引擎需要迅速測試工作區中的數據對象，從加載的規則集中發現符合條件的規則，生成規則執行實例。1982年美國卡耐基·梅隆大學的Charles L. Forgy發明了一種叫Rete算法，很好地解決了這方面的問題。目前世界頂尖的商用業務規則引擎產品基本上都使用Rete算法。

　　2.5 規則引擎的算法
　
　　大部分規則引擎產品的算法，基本上都來自于Dr. Charles Forgy在1979年提出的RETE算法及其變體，Rete算法是目前效率最高的一個Forward-Chaining推理算法，Drools項目是Rete算法的一個面向對象的Java實現，Rete算法其核心思想是將分離的匹配項根據內容動態構造匹配樹，以達到顯著降低計算量的效果。

　　3、 Java規則引擎
　
　　目前主流的規則引擎組件多是基于Java和C++程序語言環境，已經有多種Java規則引擎商業產品與開源項目的實現，其中有的已經支持JSR94，有的正朝這個方向做出努力，列出如下：

　　3.1 Java規則引擎商業產品

　　Java規則引擎商業產品主要有（Jess不是開源項目，它可以免費用于學術研究，但用于商業用途則要收費）：



　　3.2 Java規則引擎開源項目

　　開源項目的實現主要包括：

　　Drools - Drools規則引擎應用Rete算法的改進形式Rete-II算法。從內部機制上講，它使用了和Forgy的算法相同的概念和方法，但是增加了可與面向對象語言無縫連接的節點類型。

　　Mandarax 基于反向推理（歸納法）。能夠較容易地實現多個數據源的集成。例如，數據庫記錄能方便地集成為事實集(facts sets)，reflection用來集成對象模型中的功能。目前不支持JSR 94

　　OFBiz Rule Engine - 支持歸納法(Backward chaining).最初代碼基于Steven John Metsker的"Building Parsers in Java"，不支持JSR 94

　　JLisa - JLisa是用來構建業務規則的強大框架，它有著擴展了LISP優秀特色的優點,比Clips還要強大.這些特色對于多范例軟件的開發是至關重要的.支持JSR 94

　　其它的開源項目實現有諸如Algernon, TyRuBa, JTP, JEOPS, InfoSapient, RDFExpert, Jena 2, Euler, JLog, Pellet OWL Reasoner, Prova, OpenRules, SweetRules, JShop2等等。

　　4、 Java規則引擎API(JSR-94)

　　4.1 簡介

　　過去大部分的規則引擎開發并沒有規范化，有其自有的API，這使得其與外部程序交互集成不夠靈活。轉而使用另外一種產品時往往意味需要重寫應用程序邏輯和API調用，代價較大。規則引擎工業中標準的缺乏成為令人關注的重要方面。2003年11月定稿并于2004年8月最終發布的JSR 94（Java規則引擎API）使得Java規則引擎的實現得以標準化。

　　Java規則引擎API由javax.rules包定義，是訪問規則引擎的標準企業級API。Java規則引擎API允許客戶程序使用統一的方式和不同廠商的規則引擎產品交互，就像使用JDBC編寫獨立于廠商訪問不同的數據庫產品一樣。Java規則引擎API包括創建和管理規則集合的機制，在Working Memory中添加，刪除和修改對象的機制，以及初始化，重置和執行規則引擎的機制。

　　4.2 簡介Java規則引擎API體系結構

　　Java規則引擎API分為兩個主要部分:運行時客戶API(the Runtime client API)和規則管理API(the rules administration API)。

　　4.2.1規則管理API

　　規則管理API在javax.rules.admin中定義,包括裝載規則以及與規則對應的動作(執行集 execution sets)以及實例化規則引擎。規則可以從外部資源中裝載,比如說URI,Input streams, XML streams和readers等等.同時管理API提供了注冊和取消注冊執行集以及對執行集進行維護的機制。使用admin包定義規則有助于對客戶訪問運行規則進行控制管理,它通過在執行集上定義許可權使得未經授權的用戶無法訪問受控規則。

　　管理API使用類RuleServiceProvider來獲得規則管理(RuleAdministrator)接口的實例.規則管理接口提供方法注冊和取消注冊執行集.規則管理器(RuleAdministrator)提供了本地和遠程的RuleExecutionSetProvider.在前面已提及,RuleExecutionSetProvider負責創建規則執行集.規則執行集可以從如XML streams, input streams等來源中創建.這些數據來源及其內容經匯集和序列化后傳送到遠程的運行規則引擎的服務器上.大多數應用程序中,遠程規則引擎或遠程規則數據來源的情況并不多見.為了避免這些情況中的網絡開銷,API規定了可以從運行在同一JVM中規則庫中讀取數據的本地RuleExecutionSetProvider.

　　規則執行集接口除了擁有能夠獲得有關規則執行集的方法,還有能夠檢索在規則執行集中定義的所有規則對象.這使得客戶能夠知道規則集中的規則對象并且按照自己需要來使用它們。

　　4.2.2 運行時API

　　運行時API定義在javax.rules包中,為規則引擎用戶運行規則獲得結果提供了類和方法。運行時客戶只能訪問那些使用規則管理API注冊過的規則，運行時API幫助用戶獲得規則對話并且在這個對話中執行規則。

　　運行時API提供了對廠商規則引擎API實現的類似于JDBC的訪問方法.規則引擎廠商通過類RuleServiceProvider(類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)提供給用戶。

　　使用運行時Runtime API的代碼片斷如下所示:

  RuleServiceProvider ruleProvider = RuleServiceProviderManager.getRuleServiceProvider
　　　("com.mycompany.myrulesengine.rules. RuleServiceProvider");
  RuleRuntime ruleRuntime = ruleProvider.getRuleRuntime();
  StatelessRuleSession ruleSession = (StatelessRuleSession)ruleRuntime.createRuleSession(ruleURL, 
　　　null, RuleRuntime.STTELESS_SESSION_TYPE);
  List inputRules = new ArrayList();
  inputRules.add(new String("Rule 1"));
  inputRules.add(new Integer(1));
  List resultRules = ruleSession.executeRules(inputRules);  

　　Rule Markup language (RuleML)
　　http://www.ruleml.org/  Simple Rule Markup Language (SRML) 
　　http://xml.coverpages.org/srml.html  Business Rules Markup Language (BRML)
　　http://xml.coverpages.org/brml.html  SWRL: A Semantic Web Rule Language Combining OWL and RuleML
　　http://www.daml.org/2003/11/swrl/

　　多種規則語言的使用使得不同規則引擎實現之間的兼容性成為問題.通用的規則引擎API或許可以減輕不同廠家API之間的問題,但公用規則語言的缺乏將仍然阻礙不同規則引擎實現之間的互操作性.盡管業界在提出公用規則語言上做出了一些努力, 比如說RuleML,SRML的出現,但距離獲得絕大部分規則引擎廠商同意的公用標準還有很長的路要走。

　　6、 Java規則引擎API使用示例

　　6.1 設置規則引擎

　　Java規則引擎的管理活動階段開始于查找一個合適的javax.rules.RuleServiceProvider對象，這個對象是應用程序訪問規則引擎的入口。在J2EE環境中，你可能可以通過JNDI獲得RuleServiceProvider。否則，你可以使用javax.rules.RuleServiceProviderManager類：

javax.rules.RuleServiceProviderManager class:
String implName = "org.jcp.jsr94.ri.RuleServiceProvider";
Class.forName(implName);
RuleServiceProvider serviceProvider = RuleServiceProviderManager.getRuleServiceProvider(implName);    

  RuleAdministrator admin = serviceProvider.getRuleAdministrator();
  HashMap properties = new HashMap();
  properties.put("name", "My Rules");
  properties.put("description", "A trivial rulebase"); 
  FileReader reader = new FileReader("rules.xml");
  RuleExecutionSet ruleSet = null;
   try {
        LocalRuleExecutionSetProvider lresp =admin.getLocalRuleExecutionSetProvider(properties); 
        ruleSet = lresp.createRuleExecutionSet(reader, properties);
   } finally {
    reader.close();
   }  

  RuleRuntime runtime = rsp.getRuleRuntime(); 
　StatefulRuleSession session = (StatefulRuleSession)runtime.createRuleSession("rules",
       properties,RuleRuntime.STATEFUL_SESSION_TYPE);
　session.addObject(new Integer(1)); 
  session.addObject("A string");
  session.executeRules(); 
  List results = session.getObjects(); 
  session.release();  

何仁杰　梁冰

業務規則管理系統的基本原理是：用一個或多個規則引擎替換以程序代碼“固化”在應用系統中的業務邏輯。一個完善的BRMS可以對業務規則的整個生命周期實現全程管理。

業務規則的全生命周期管理如圖1所示。BRMS在應用系統中的地位與數據庫管理系統（DBMS）類似，處于比較基礎的位置，是其他高端應用的基石。圖2是GIGA Information Group 給出的IT架構中BRMS的位置圖。

業務規則管理如何實現？

業務規則

一個業務規則包含一組條件和在此條件下執行的操作，它們表示業務規則應用程序的一段業務邏輯。業務規則通常應該由業務分析人員和策略管理者開發和修改，但有些復雜的業務規則也可以由技術人員使用面向對象的技術語言或腳本來定制。業務規則的理論基礎是:設置一個或多個條件，當滿足這些條件時會觸發一個或多個操作。

規則引擎

這是一種嵌入在應用程序中的組件，它的任務是把當前提交給引擎的數據對象與加載在引擎中的業務規則進行測試和比對，激活那些符合當前數據狀態下的業務規則，根據業務規則中聲明的執行邏輯，觸發應用程序中對應的操作。

目前主流的規則引擎組件多是基于Java和C++程序語言環境。在2000年11月，Java Community Process（簡稱JCP） 組織開始著手起草Java規則引擎的API標準，即JSR 94 規范。參與JSR 94起草的有BEA、IBM、ILOG、甲骨文、Novell、ATG、Unisys、Fujitsu等著名的軟件企業。JSR 94 在2003年11月25日正式定稿，支持JSR 94標準的規則引擎也幾乎同時推向市場，包括ILOG 的JRules和Blaze的Advisor。

規則引擎的使用方式

由于規則引擎是軟件組件，所以只有開發人員才能夠通過程序接口的方式來使用和控制它，規則引擎的程序接口至少包含以下幾種API：加載和卸載規則集的API；數據操作的API；引擎執行的API。開發人員在程序中使用規則引擎基本遵循以下5個典型的步驟：創建規則引擎對象；向引擎中加載規則集或更換規則集；向引擎提交需要被規則集處理的數據對象集合；命令引擎執行;導出引擎執行結果，從引擎中撤出處理過的數據。使用了規則引擎之后，許多涉及業務邏輯的程序代碼基本被這五個典型步驟所取代。

一個開放的業務規則引擎應該可以“嵌入”在應用程序的任何位置，不同位置的規則引擎可以使用不同的規則集，用于處理不同的數據對象。此外，對使用引擎的數量沒有限制。

規則引擎的內部實現

規則引擎的基本機制是：對提交給引擎的數據對象進行檢索，根據這些對象的當前屬性值和它們之間的關系，從加載到引擎的規則集中發現符合條件的規則，創建這些規則的執行實例。這些實例將在引擎接到執行指令時、依照某種優先序依次執行。一般，規則引擎內部由下面幾個部分構成：工作內存，用于存放被引擎引用的數據對象集合；規則執行隊列，用于存放被激活的規則執行實例;靜態規則區，用于存放所有被加載的業務規則，這些規則將按照某種數據結構組織，當工作區中的數據發生改變后，引擎需要迅速根據工作區中的對象現狀，調整規則執行隊列中的規則執行實例。規則引擎的結構示意圖如圖3所示。

任何一個規則引擎都需要很好地解決規則的推理機制和規則條件匹配的效率問題。

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

規則條件匹配的效率決定了引擎的性能，引擎需要迅速測試工作區中的數據對象，從加載的規則集中發現符合條件的規則，生成規則執行實例。1982年美國卡耐基·梅隆大學的Charles L. Forgy發明了一種叫Rete算法，很好地解決了這方面的問題。目前世界頂尖的商用業務規則引擎產品基本上都使用Rete算法。

BOM賦予規則行業特性

業務規則一定是針對某種業務的，不同的業務有自己特有的業務模型——業務對象模型（Business Object Mode，簡稱BOM）。BOM為業務規則語言提供了絕大多數的詞匯，多由業務系統分析員設計，由開發人員具體實現。從面向對象的編程角度來看，BOM就是一個簡化的類圖，類圖中有類名、類的屬性、類的方法等。這些要素都將是業務規則語言中的基本“詞匯”。BOM的來源可以是Java對象模型、C++對象模型、XML Schema、Web服務定義等。

假定我們有一個簡單的寵物商店購物車應用程序，在這個應用程序中，顧客能夠在購物車中放入各種寵物和相關物品對象。這個應用程序的業務對象集合就可以有ShoppingCart(購物車)、Customer(用戶)、Item (條目)和ItemType(條目類型)這幾個類。

表述業務規則的語法就是業務規則語言。由于規則語言的使用者主要有兩類:業務人員和技術人員，所以規則語言一般也分為兩類：“面向程序技術”的規則語言，它技術性很強，可讀性較弱，比較適合IT 技術人員使用，一般每個規則引擎開發商都有自己的一套“面向程序技術”的規則語言語法，不過OASIS組織定義了不同應用情況下的規則語言規范，包括SRML（Simple Rule Markup Language），BMRL(Business Markup Rule Language)和RuleML（Rule Markup Language）等；“面向業務”的規則語言，它是業務人員使用的語言，必須具備非技術性和可定制性，通常它需要經過“翻譯”之后才能被規則引擎解析。BRMS必須提供這種“翻譯”機制，而開發人員要實現從“面向業務”規則語言到“面向程序”規則語言的映射。

“面向業務”的規則語言無論從語法上還是語句結構上都可能千變萬化，不同行業可能有自己的“行話”。一個好的BRMS應該提供一個完善的規則語言框架，能夠迅速地為業務人員定制不同的“行話”，否則業務人員還是無法真正成為業務規則的主人。

“單純”的規則如何互連?

業務規則有一個非常明顯的特性：單純性。每個業務規則只描述自己特有的條件和滿足條件的操作，業務規則本身并不關心它與其他規則的關系，如優先關系、互斥關系、包含關系等。每個業務規則本身可以有自己的屬性，稱元信息，可以用來處理規則之間相關性，例如引擎可以使用規則的優先級來依序執行規則的操作。

有些BRMS還提供一種稱為“規則流”的定制功能。規則流是一個圖表，定義了解決問題或執行業務流程的順序。類似于統一建模語言（UML）的活動圖，由一組任務以及定義這些任務之間執行順序的轉換邏輯組成。一個轉換由條件控制，只有當該限制條件為“真”時才能完成這種轉換。

這些任務可以是規則任務、函數任務或子規則流任務。規則任務包含一組要作為任務主體執行的規則，規則的執行邏輯由用戶設置的任務屬性嚴格控制。這些屬性決定規則的排序、規則觸發策略、執行算法等；函數任務包含要作為任務主體執行的腳本代碼；子規則流任務則包含任務開始后將依次執行的子規則流。

為了方便開發人員和業務人員管理業務規則，BRMS必須提供具有直觀用戶界面的工具來實現業務規則管理。規則管理工具至少應該具備以下功能：規則的定制和編輯、規則流的定制、決策表形式的規則定制、規則的查詢、規則有效期限的控制、規則的組織結構、規則模板的定制、規則庫訪問權限的控制、規則變更歷史的記錄、規則文檔的管理等。

·小資料2·

業務規則管理系統其實是一組工具集，它包括：規則引擎、規則庫、規則語言框架、規則管理集成開發環境。業務規則管理系統的基本工作原理如圖所示。

規則引擎（Rules Engine）

是執行業務規則的軟件組件，它嵌入在程序中，是業務規則管理系統的核心元素。規則引擎的類型有：簡單型、數據中心型和面向事務型。

規則庫（Rules Repository）及其服務機制

用于存儲規則和規則元數據（Meta Data）以及與規則有關的屬性。它提供一組工具用于存儲、分類、查詢、版本控制、權限控制、測試、提交等，規則的狀態和有效性可以跟蹤。規則庫可以依托文件系統或數據庫管理系統。

規則語言框架（Rules Language Framework）

規則語言一般分為兩類：“面向程序技術”的規則語言，使用者是技術人員；“面向業務”的規則語言，使用者是業務人員。規則語言框架則為定制“面向業務”的規則語言提供支持。

規則管理工具（Rules Management Tool）

用于管理、創建、修改和部署業務規則的圖形化工具，易用性強，除了開發人員外，業務人員也可以使用這套圖形化工具實現對規則的管理。

規則集成開發環境（Rules IDE）

一般規則集成開發環境只有規則編輯器，而高級的規則集成開發環境可以實現對規則和規則庫的管理：如規則的創建、分類、檢索、修改、版本控制、權限管理等；甚至可以實現對多個規則引擎的“在線”調試；對規則集合進行沖突檢查等。

一個完整的BRMS應該提供規則管理（Rules Management）、規則部署（ules Deployment）、規則分析（Rules Analysis）、規則定制和設計（Rules Design and Authoring）等功能。

（計算機世界報 第14期 B6、B7）

　　知道有java這個東西，是一年前的事。呵呵，不要誤會，我不是剛接觸電腦的小孩，過了年，我就是26歲了。
　　知道java，是因為我有個傻瓜老公，他會這個。
　　幾天前，他告訴我買了個網址（不要挑剔我的用詞，外行不是我一個人的錯），把他的blog連到那上面去。看他天天回家就“抱”著電腦，嘴角還傻傻地向上翹，我就納悶呀，blog我也知道，不就是一些悶騷的人說一些感性在先理性在后的話嗎？至于置我這個“掌門”于不顧嗎？趁他起身如廁之際，我急忙跑到電腦前，探個究竟。
　　BlogJava?
        就是這個東東呀！
　　恍然大悟，然后撓頭，累不累呀！
　　他在華為做研發，每天就用這個什么Java干活。華為那個可憎的XX公司，老總是個典型的資本家，天天要加班到很晚（九、十點鐘是正常），而且每四個星期還要有一個星期六義務奉獻。動輒罰款降薪，而且還要連帶你的上司一同受懲！置《勞動法》于不顧，大大的壞！！可是為什么這樣的辛苦，休息的時候還弄這個鬼鬼Java呀?哎呀，男人心，海底針呀！
　　我就在這個Blog上逛了逛，哦，這樣的人還真不少啊！難怪這家伙像看到親人了似的。
　　呵，呵呵，簡單的瀏覽之后，我確定這里有多個我老公的copy版。每天起來做的第一件事就是打開信箱收發郵件；電腦桌面要簡單，源文件里密密麻麻的才叫“眩”；上廁所雙擊開關，坐在馬桶上用《程序員》來打發時間。
　　不過我現在不會再抱怨了，雖然他依然聽不見我的問話，即使我站在電腦旁邊。我知道這是他唯一的心血，唯一的愛好，唯一的執著，唯一的事業，那么，我為什么不支持呢？
　　現在的我還是不懂得什么是Java，但是我驕傲，因為老公是個出色的“程序員”。他不理我并不是我的魅力不及電腦，不然怎么會把所有的薪水花在我這邊？沒有時間理我，算了。因為我也沒有那么多時間，我要收拾房間，搞好個人和“他”人衛生，還要花大量時間研究營養學，都說長久用電腦的人要多多補充的！
　　祝愿所有用Java賺錢的人身體健康，一生平安！