這是我主學的JBoss Rules，給大家簡單總結一下。open和share這兩種思想希望大家傳承！
1、JBoss Rules簡介
JBoss Rules（Drools ）具有一個易於訪問企業策略、易於調整以及易於管理的開源業務規則引擎，符合業內標准，速度快、效率高。業務分析師或審核人員可以利用它輕松查看業務規則，從而檢驗是否已編碼的規則執行了所需的業務規則。
JBoss Rules 的前身是Codehaus的一個開源項目叫Drools。最近被納入JBoss門下，更名為JBoss Rules，成為了JBoss應用服務器的規則引擎。
Drools是為Java量身定制的基於Charles Forgy的RETE算法的規則引擎的實現。具有了OO接口的RETE,使得商業規則有了更自然的表達。
既然JBoss Rules是一個商業規則引擎，那我們就要先知道到底什么是Rules，即規則。在JBoss Rules中，規則是如何被表示的
1.1 規則文件
一個規則文件通常是一個以 .drl 擴展名結尾的文件。在一個 drl 文件中，你可以有多條 rules ， functions 等等。盡管如此，你也可以將你的規則分布在多個文件中，這有利於管理大量的規則。一個 DRL 文件是一個簡單的文本文件。
1.2 規則的結構
一個規則結構大致如下：
ATTRIBUTES
when
LHS
then
RHS
end
可以看到，這是非常簡單的。通常的標點符號都是不需要的，甚至連“ name ”的雙引號都是不需要的。 ATTRIBUTES 是簡單的，也是可選的，來提示規則的行為方式。 LHS 是規則的條件部分，需要按照一定的語法來寫。 RHS 基本上是一個允許執行 Java 語法的代碼的塊（以后將會支持 groovy 和 C ＃）。任何在 LHS 中使用的變量都可以在 RHS 中使用。
注意：每行開始的空格是不重要的，除非在 DSL （ Domain Specific Language ）語言中有特別的指明。
2、◆ 那么什么是規則引擎呢？
規則引擎由推理引擎發展而來，是一種嵌入在應用程序中的組件，實現了將業務決策從應用程序代碼中分離出來，並使用預定義的語義模塊編寫業務決策。接受數據輸入，解釋業務規則，並根據業務規則做出業務決策。
3、◆ 使用規則引擎的好處
■ 聲明式編程：規則引擎允許你描述做什么而不是如何去做
■ 邏輯與數據分離：數據保存在系統對象中，邏輯保存在規則中。這根本性的打破了面向對象系統中將數據和邏輯耦合起來的局面
■ 速度及可測量性：Rete算法、Leaps算法,以及由此衍生出來的Drools的Rete、Leaps算法，提供了對系統數據對象非常有效率的匹配
■ 知識集中化：通過使用規則，將建立一個可執行的規則庫。這意味着規則庫代表着現實中的業務策略的唯一對應，理想情況下可讀性高的規則還可以被當作文檔使用
■ 工具集成：例如Eclipse（將來可能在基於Web的界面上）這樣的工具為規則的修改與管理、即時獲得反饋、內容驗證與修補提供了辦法。審查與調試工具同樣也可用了
■ 解釋機制：通過將規則引擎的決斷與決斷的原因一起記錄下來，規則系統提供了很好的“解釋機制”
■ 易懂的規則：通過建立對象模型以及DSL（域定義語言），你可以用接近自然語言的方式來編寫規則。這讓非技術人員與領域專家可以用他們自己的邏輯來理解規則（因為程序的迷宮已經被隱藏起來了）
4、◆ 適合使用規則引擎系統的場合
■ 用傳統的代碼開發比較復雜、繁瑣
■ 問題雖然不復雜，但是用傳統的代碼開發比較脆弱，也就是經常修改
■ 沒有優雅的算法
■ 業務規則頻繁改變
■ 有很多業務專家、不懂技術開發
5、◆ 不適合使用規則引擎系統的場合
雖然規則系統看起來比較不錯，但是並不是任何地方都可以使用規則系統。很多簡單、固定的業務系統，可以不用使用規則系統。規則系統也不能用來作為標示重要的業務流程、不能用來作為工作流引擎。
有很多程序員把規則系統當成是一種動態修改配置。也就是把一部分代碼邏輯抽取到外面，統一存放起來。這樣，當一些配置修改的話，通過修改規則，就能修改代碼的一部分邏輯。如果把規則僅僅用在這個場合下的話，可以考慮采用腳本引擎。比如BeanShell、JEXL、Groovy等等。