4 ． WorkingMemory:
Figure 4.1 WorkingMemory
WorkingMemory 是運作時規則引擎的主要類。它保持了所有被 asserted 進 WorkingMemory 的資料的引用，直到取消（ retracted ）。WorkingMemory 是有狀态對象。它們的生命周期可長可短。如果從一個短生命周期的角度來同一個引擎進行互動，意味着你可以使用 RuleBase 對象來為每個 session 産生一個新的 WorkingMemory ，然後在結束 session 後 discard 這個 WorkingMemory （産生一個 WorkingMemory 是一個廉價的操作）。另一種形式，就是在一個相當長的時間中（例如一個 conversation ），保持一個 WorkingMemory ，并且對于新的 facts 保持持續的更新。當你希望 dispose 一個 WorkingMemory 的時候，最好的實踐就是調用 dispose() 方法，此時 RuleBase 中對它的引用将會被移除（盡管這是一個弱引用）。不管怎樣最後它将會被當成垃圾收集掉。術語 WorkingMemory Actions 代表了對 WorkingMemory 的 assertions ， retractions 和 modifications。
4.1 Facts
Facts 是從你的應用中，被 assert 進 WorkingMemory 中的對象（ beans ）。 Facts 是規則可以通路的任意的 java 對象。規則引擎中的 facts 并不是“ clone ” facts ，它隻是持有到你的應用中資料的引用。 Facts 是你的應用資料。 String 和其他沒有 getter 和 setter 的類不是有效的 Fact 。這樣的類不能使用域限制（ Field Constraints ），因為使用域限制要依靠 JavaBean 标準的 getter 和 setter 來同對象互動。
4.2 Assertion
“Assertion” 是将 facts 告訴 WorkingMemory 的動作，例如 WorkingMemory.assertObject (yourObject) 。當你 assert 一個 fact ，它将被檢查是否比對規則。這意味着所有的比對工作将會在 assert 的過程中完成。盡管如此，當你完成 assert facts 之後，你還要調用“ fireAllRules() ”方法來執行規則。
當一個對象被 assert 後，會傳回一個 FactHandle 。這個 FactHandle 是一個代表在 Working Memory 中你的 asserted Object 的令牌（ token ）。當你希望 retract 或者 modify 一個對象的時候，這個令牌讓你用來同 WorkingMemory 進行互動。
Cheese stilton = new Cheese( " stilton " );
FactHandle stiltonHandle = workingMemory.assertObject( stilton );
WorkingMeomry 有兩種 assertion 模式： Equality 和 Identity （預設是 Identity ）。
Identity 模式下 WorkingMemory 使用一個 IdentityHashMap 來存儲所有的 asserted Objects 。這個模式下，當 asserted 的 Object 是同一個執行個體時，它傳回同一個 FactHandle 。
Equality 模式下 WorkingMemory 使用一個 HashMap 來存儲所有的 asserted Objects 。這個模式下，當 asserted 的 Object 相等時，它傳回同一個FactHandle 。
（ WorkingMemory.assertObject(yourObjcet) 隻是進行 assertion 的一種 regular 方法，還存在有一種稱為 logical assertion 的動作）。
4.3 Retraction
基本上就是 assert 的逆操作。當你 retract 一個 fact ， WorkingMemory 将不再跟蹤那個 fact 。任何被 activated 并依賴那個 fact 的規則将被取消。注意：完全有可能存在某條規則是依賴于一個 fact 的“不存在”（ non existence ）。在這種情況下， retract 一個 fact 将導緻一條規則被激活。對一個Fact 進行 Retraction ，必須用 assert 時傳回的那個 FactHandle 做為參數。
Cheese stilton = new Cheese( " stilton " );
FactHandle stiltonHandle = workingMemory.assertObject( stilton );
.
workingMemory.retractObject( stiltonHandle );
4.4 Modification
當一個 Fact 被修改了，會通知規則引擎進行重新處理。在規則引擎内部實際上是對舊的 Fact 進行 retract ，然後對新的 Object 再進行 assert 。要使用 modifyObject() 方法來通知 Working Memory ，被改變的 Object 并不會自己通知規則引擎。注意： modifyObject() 方法總是要把被修改的 Object做為第二參數，這就允許你把一個不可變對象替換為另一個新對象。
Cheese stilton = new Cheese( " stilton " );
FactHandle stiltonHandle = workingMemory.assertObject( stilton );
.
stilton.setPrice( 100 );
workingMemory.modifyObject( stiltonHandle, stilton );
4.5 Globals
Global 是一個能夠被傳進 WorkingMemory 但不需要 assert 的命名對象。大多數這些對象被用來作為靜态資訊或服務。這些服務被用在一條規則的RHS ，或者可能是從規則引擎傳回對象的一種方法。
List list = new ArrayList（）;
workingMemory.setGlobal( " list " , list);
setGlobal() 方法傳進去的命名對象必須同 RuleBase 中所定義的具有相同的類型（就是要同你的規則檔案中用 Global 關鍵字所定義的類型相同），否則會抛出一個 RuntimeException 。如果一條規則在你 setGlobal 之前調用了定義的 Global ，會抛出一個 NullPointerException 。
4.6 Property Change Listener
如果你的 fact 對象是 JavaBean ，你可以為它們實作一個 property change listener ，然後把它告訴規則引擎。這意味着，當一個 fact 改變時，規則引擎将會自動知道，并進行響應的動作（你不需要調用 modifyObject() 方法來通知 WorkingMemory ）。 Proxy libraries 将會幫助實作這一切。要讓Property Change Listener 生效，還要将 fact 設定為動态（ dynamic ）模式，通過将 true 做為 assertObject() 方法的第二個參數來實作：
Cheese stilton = new Cheese( " stilton " );
FactHandle stiltonHandle = workingMemory.assertObject( stilton, true ); // specifies t hat this is a dynamic fact
然後要在 JavaBean 中加入一個 PropertyChangeSupport 執行個體，和兩個方法： addPropertyChangeListener() 和 removePropertyChangeListener() 。最後要在 JavaBean 的 setter 方法中通知 PropertyChangeSupport 所發生的變化。示例代碼如下：
private final PropertyChangeSupport changes = new PropertyChangeSupport( this );
public void addPropertyChangeListener( final PropertyChangeListener l) {
this .changes.addPropertyChangeListener( l );
}
public void removePropertyChangeListener( final PropertyChangeListener l) {
this .changes.removePropertyChangeListener( l );
}
public void setState( final String newState) {
String oldState = this .state;
this .state = newState;
this .changes.firePropertyChange( " state " , oldState, newState );
5. Agenda:
Figure 5.1 . Agenda
Agenda 是 RETE 的一個特點。在一個 WorkingMemory Action 發生時，可能會有多條規則發生完全比對。當一條規則完全比對的時候，一個Activation 就被建立（引用了這條規則和與其比對的 facts ），然後放進 Agenda 中。 Agenda 通過使用沖突解決政策（ Conflict Resolution Strategy）來安排這些 Activations 的執行。
引擎工作在一個“ 2 階段”模式下：
<!--[if !supportLists]--> 1） <!--[endif]--> WorkingMemory Actions ：assert新的facts，修改存在的facts和retract facts都是WorkingMemory Actions。通過在應用程式中調用fireAllRules()方法，會使引擎轉換到Agenda Evaluatioin階段。
<!--[if !supportLists]--> 2） <!--[endif]--> Agenda Evaluation ：嘗試選擇一條規則進行激發（fire）。如果規則沒有找到就退出，否則它就嘗試激發這條規則，然後轉換到WorkingMemory Actions階段，直到Agenda中為空。
這個過程一直重複，直到 Agenda 是空的，此時控制權就回到應用程式中。。當 WorkingMemory Actions 發生時，沒有規則正在被激發。
下圖說明了這個循環的過程：
Figure 5.2 . Two Phase Execution
5 ． 1 Conflict Resultion
當有多條 rules 在 agenda 中，就需要解決沖突。當激發一條規則時，會對 WorkingMemory 産生副作用。規則引擎需要知道規則要以什麼順序來激發（例如，激發 rule A 可能會引起 rule B 被從 agenda 中移除。）
Drools 采取的沖突解決政策有 2 種，按照優先級排列如下： Salience ， LIFO （後進先出）。最易懂的政策是“ Salience ”，即優先級， user 可以為某個 rule 指定一個高一點的優先級（通過附給它一個比較大的數字）。高 Salience 的 rule 将會被優先激發。
5 ． 2 Agenda Groups
Agenda Groups 是劃分 Agenda 中 rules （其實是“ activations ”）的一種方法。在任意一個時刻，隻有一個 group 擁有“ focus ”，這意味着隻有在那個 group 中的 activations 才是有效的。
Agenda Groups 是在 grouped rules 之間建立一個“流”（ flow ）的簡便的方法。你可以在規則引擎中，或是用 API 來切換具有焦點的組。如果你的規則有很明确的多“階段”（ phases ）或多“序列”（ sequences ）的處理，可以考慮用 Agenda Groups 來達到這個目的。
每次調用 setFocus() 方法的時候，那個 Agenda Group 就會被壓入一個堆棧，當這個有焦點的組為空時，它就會被彈出，然後下一個組就會被執行。一個 Agenda Group 可以出現在堆棧的多個位置。預設的 Agenda Group 是“ MAIN ”，所有沒有被指定 Agenda Group 的 Activations 都被放到那個組中，這個組總是被放在堆棧的第一個組，并預設給予焦點。
5 ． 3 Agenda Filters
Figure 5.3. Agenda Filter
Filter 必須實作 AgendaFilter 接口，用來允許或禁止一個 activation 能夠被激發。 Drools 提供了下面幾種友善的預設實作：
<!--[if !supportLists]--> · <!--[endif]--> RuleNameEndWithAgendaFilter
<!--[if !supportLists]--> · <!--[endif]--> RuleNameEqualsAgendaFilter
<!--[if !supportLists]--> · <!--[endif]--> RuleNameStartsWithAgendaFilter
要使用一個 filter 就要在調用 fireAllRules() 方法的時候指定它。下面的例子将對所有名字以“ Test ”結尾的規則進行過濾：
workingMemory.fireAllRules( new RuleNameEndsWithAgendaFilter( " Test " ) );
6．事件模型（ Event Model ）
Event 包裡提供了規則引擎的事件機制，包括規則激發，對象被 asserted 等等。你可以使用事件機制來進行 AOP 程式設計。
有兩種類型的 Event Listener ： WorkingMemoryEventListener 和 AgendaEventListener 。
Figure 6.1. WorkingMemoryEventListener
Figure 6.2 AgendaEventListener
對兩個 EventListener 接口都提供了預設實作，但在方法中并沒有做任何事。你可以繼承這兩個預設實作來完成你自己的實作－DefaultAgendaEventListener 和 DefaultWorkingMemoryEventListener 。下面代碼說明了如何擴充一個 DefaultAgendaEventListner 并把它加到WorkingMemory 中，例子中隻完成了 afterActivationFired() 方法：
workingMemory.addEventListener( new DefaultAgendaEventListener() {
public void afterActivationFired(AfterActivationFiredEvent event) {
super .afterActivationFired( event );
System.out.println( event );
}
});
Drools 也提供了 DebugWorkingMemoryEventListener 和 DebugAgendaEventListener 兩個實作類，在這兩個類的方法中實作了 debug 資訊的輸出：
workingMemory.addEventListener( new DebugWorkingMemoryEventListener() );