【正文】 的結(jié)果。接受對自己或任何已經(jīng)分配的選擇方案。規(guī)則被激發(fā)，并且設(shè)置了第一個座位的安排，為“分配座位”規(guī)則執(zhí)行所需的路徑和上下文狀態(tài)就建立好了。但 3 與 4 以及 1與 2的位置會隨意排列。一個激活規(guī)則中一個更近期的模式實(shí)體放在一個與遠(yuǎn)期的模式實(shí)體相關(guān)的激活規(guī)則之前?！?l”和“ r”指左邊和右邊，“ s”是 sean,“ n”是客人姓名。 Daniel P. Miranker 的論文 Effects of Database Size on Rule System Performance: Five Case Studies中提出了五個基準(zhǔn)分析。 這個測試框架建立在 FIT 和 JSR94之上，對于 Jboos 規(guī)則來說是一個獨(dú)立的項(xiàng)目。下一節(jié)介紹了一個規(guī)則測試組件。更進(jìn)一步說，測試在規(guī)則頻繁變動的環(huán)境下，比規(guī)則更重要。 . Web Services 一種發(fā)布規(guī)則的可能方式是將規(guī)則暴露為 Web 服務(wù)。 . 一些部署方法 這節(jié)包含一些部署的建議。系統(tǒng)包含 droolspiler規(guī)則編譯器組件構(gòu)建規(guī)則。當(dāng) RuleBase 被整體更新時，這是一個有用的選項(xiàng)，對短期存在的 working memory。在這種情況下，使用 PackageBuilder 從 DRL 源碼建立Package，但是它是可以被部署的二進(jìn)制 Package 對象。例如說，規(guī)則可以從一個有許多使用中的 working memory 的 rulebase中刪除， RETE網(wǎng)絡(luò)將自動調(diào)整以刪除該規(guī)則而不需要將其它 fact重新設(shè)置一次。許多組織對于產(chǎn)品線的更改有配置管理流程。這個模塊中有許多例子。當(dāng)節(jié)點(diǎn)被共享后，它將減少內(nèi)存的占用，并提升性能。這個方法不一定每次都能適用。通過對兩者評估，可以得到通用性的規(guī)則比硬編碼常量規(guī)則的速度更快。 Say we run a mega online store and customers can define their favorites in each of the categories (books, videos, music, toys, electronics, clothing). What happens if a customer has different levels for each category. Using the hard coded approach, one might have to add more rules. If we change the rule and make it more generalized, the same rule can handle multiple categories. If ?lvl // 綁定 remendation level 到 lvl 變量 ?rcat // 綁定 remendation category 到 rcat ?id // 綁定 account id 到 id ?id // 通過 id 找到 favorites 列表 ?rcat // 將 favorite 匹配到 remendation category ?lvl // 匹配 favorite level 到 remendation level Then remend all items in the favorites 如此看來，使規(guī)則具有動態(tài)性，并由數(shù)據(jù)驅(qū)動的價(jià)值在哪里呢？顯然，硬編碼規(guī)則要比讓規(guī)則具有通用性更快，但是會影響性能。我們不希望將所有 Customer 都裝載到規(guī)則引擎中。 If == abcd == basic ..... Then // do something 上面規(guī)則示例的基本問題是，規(guī)則有太多硬編碼值。這些情況是在智能 AI 系統(tǒng)中，其中的規(guī)則引擎在執(zhí)行時將產(chǎn)生新的規(guī)則，術(shù)語和 Fact。例如在“ Manners 64 example”測試中，如果我們關(guān)閉右輸入內(nèi)存索引，我們可以獲得下面的結(jié)果 Manners 64 僅使用 BetaNode 左輸入內(nèi)存索引 : 142020 毫秒運(yùn)行時間 以上甚至比不使用索引更糟糕。一旦所以被定義，當(dāng)查詢被執(zhí)行后，一個查詢計(jì)劃組件被數(shù)據(jù)庫系統(tǒng)用來評估運(yùn)行該查詢的最佳性能的辦法，有時使用索引，有時不用。 如果我們使用“ mother”屬性對 BetaNode 內(nèi)存進(jìn)行索引，當(dāng)新的一個 Person對象設(shè)置到內(nèi)存時，它只需要匹配之前有相同 mother屬性的對象（有相同 mother屬性的可能不只是 Person 對象，因此要進(jìn)行匹配）就行了，通過索引可以非常高效率的完成這個過程。 因此，當(dāng)單個對象進(jìn)入節(jié)點(diǎn)的右輸入時，它嘗試對左輸入內(nèi)存中的每一個組元進(jìn)行匹配，以找到滿足 BetaNode 的約束。通常的建議是不要隨意估測，準(zhǔn)確度量，剖析和計(jì)劃。 ( list, globalList )。 List results = new ArrayList()。 createRuleSession(....)方法返回一個RuleSession 實(shí)例，它必須轉(zhuǎn)義為 StatefulRuleSession 或StatelessRuleSession。 當(dāng)注冊 RuleExecutionSet 時必須指定名稱，用于取回它。 例 . 當(dāng)注冊 LocalRuleExecutionSet 時指定 DSL // 獲得 RuleAdministration RuleAdministration ruleAdministrator = ()。 LocalRuleExecutionSetProvider ruleExecutionSetProvider = ( null )。RuleAdministration 提供對 RuleExecutionSet 進(jìn)行管理的 API，使用該 API 可以注冊一個 RuleExecutionSet，然后可以用 RuleRuntime 來返回RuleExecutionSet。 . 如何使用 JSR94分為兩部分工作。第六章 . Java 規(guī)則引擎 API . 簡介 Drools 提供了一個 Java 規(guī)則引擎 API（ JSR94）的實(shí)現(xiàn)，它允許在一個 API 中支持多個規(guī)則引擎。因此當(dāng)我們?yōu)閳?jiān)持使用 JSR94的程序員提供 API 的同時，我 們強(qiáng)烈建議使用 Drools API。 RuleServiceProvider提供對 RuleRuntime和 RuleAdministration 的 API訪問。 例 . 使用 RuleAdministration API 注冊 LocalRuleExecutionSet // 獲得 RuleAdministration RuleAdministration ruleAdministrator = ()。 Dsl 可以獲得一個讀取流或一個字符串（包含 dsl 內(nèi)容）作為值。 // 為 drl 和 dsl建立 RuleExecutionSet RuleExecutionSet ruleExecutionSet = ( reader, properties )。屬性映射可以是 null，或者可以用來指定全局變量，這個在下一節(jié)說明。 ( new PurchaseOrder( even more cheese ) )。 map = new ( )。 end . 參考書目 如果你需要了解 JSR 94 的更多信息，請 參考以下文章索引 1. Official JCP Specification for Java Rule Engine API (JSR 94) ? 2. The Java Rule Engine API documentation ? 3. The Logic From The Bottom Line: An Introduction to The Drools Project. By N. Alex Rupp, published on in 2020 ? s 4. Getting Started With the Java Rule Engine API (JSR 94): Toward RuleBased Applications. By Dr. Qusay H. Mahmoud, published on Sun Developer Network in 2020 ? 5. Jess and the API. By Ernest FriedmanHill, published on in 2020 ? 第 7 章 . 性能調(diào)整 . 性能考慮 在任何復(fù)雜的應(yīng)用中，許多事情可能會對性能造成影響。每一個 BetaNode 有兩個內(nèi)存，每一個輸入有一個：左輸入內(nèi)存和右輸入內(nèi)存。因此如果之前已經(jīng)有 1000 個 Person 對象在 working memory 中，如果我們再設(shè)置進(jìn)來一個新的Person 對象，它需要與之前的 Person 對象進(jìn)行 1000次匹配。對于大多數(shù)企業(yè)應(yīng)用來說一個計(jì)劃良好索引編排是基本要求，這通常是數(shù)據(jù)庫管理員的責(zé)任。 每個系統(tǒng)有它自己的特性，有時候它可能可以對性能作出更好的調(diào)整。 . 大型 Ruleset 對于本節(jié)，巨大的 RuleSet 定義如下： ? 1500 – 小型 ruleset ? 5002020 – 中型 ruleset ? 2020+ 大型 ruleset ? 10,000 – 巨大型 ruleset 在某些情況下，規(guī)則引擎不得不處理超過 50萬 或 100 萬條規(guī)則。檢查規(guī)則，并看看是否向下面例子所示。在規(guī)則中包含客戶的 accountId 硬編碼沒有任何好處，因?yàn)槲覀冎幌Ｍ?guī)則引擎評估激活的部分。如果我們改變規(guī)則，使它更具有通用性，同樣的規(guī)則可以處理多個分類。當(dāng)規(guī)則數(shù)量增加時，單個規(guī)則的執(zhí)行更佳。對于這個問題的解決方案是改變域?qū)ο?，能夠以一種更簡潔的方式表達(dá)商業(yè)模型。這樣可以允許 RETE 規(guī)則引擎共享這些節(jié)點(diǎn)。另外，你可以下載droolsexamples 模塊，這是一個自包含的 Eclipse 項(xiàng)目。 因?yàn)槊總€組織都有不同，因此需要不同的部署模式。 可以有許多更靈巧的辦法實(shí)現(xiàn)上面的案例， Drools 規(guī)則引擎十分的動態(tài)，意味著許多組件能夠被動態(tài)交換（ rules,packages）甚至有 working memory 正在使用的時候。 PackageDescr, PackageBuilder, RuleBaseLoader . Package 這種方法最具有靈活性。 RuleBase 是可序列化的，因此它們能夠被當(dāng)作二進(jìn)制部署單元。 . 部署模式 . 進(jìn)程內(nèi)規(guī)則構(gòu)建 在這種情況下，規(guī)則以源碼方式提供到運(yùn)行時系統(tǒng)。運(yùn)行時系統(tǒng)只需要 droolscore 庫引用，就可以使用().addPackage(deserialized package object)載入該文件。當(dāng)新的規(guī)則生效時，這可以給與更多的控制。 你可以在規(guī)則編寫前提供測試來規(guī)定規(guī)則的行為。 顯然，對于規(guī)則測試，其它非源代碼驅(qū)動的架構(gòu)在某些環(huán)境下也可以用來測試規(guī)則。這些情景然后可以作為測試保存，增 加當(dāng)規(guī)則發(fā)生變更時仍然按照用戶希望的工作的保證性。 圖 . Manners 小姐的客人 . 基準(zhǔn)分析 在 1991 年 Brant, Timothy Grose, Bernie Lofaso, amp。要特別注意的一點(diǎn)是，每一行有一個 pid 都比下一個要小，它的意義將會在“分配座位”規(guī)則的描述中說明。與每一個激活規(guī)則相關(guān)的模式實(shí)體按照遞減順序來決定位置。例如， a 實(shí)例激活規(guī)則 1和 2， b實(shí)例激活規(guī)則 3 和 4，如果 a比 b先設(shè)置，則規(guī)則 3和 4在 agenda 中將排在 1和 2前面。在這個“分配第一個座位”規(guī)則中執(zhí)行順序并不是十分重要，但在“分配座位”規(guī)則中非常重要。該規(guī)則為 WorkingMemory 中所有的客人的所有座位安排建立叉集算法（ cross product）解決方案。 ( )。因此，如果你直接將一個 OPS5 程序移植到CLIPS 中，但是使用默認(rèn)的深度沖突解決策略，你只能在偶然情況下獲得正確的行為。 unsigned int dependentsf : 1。當(dāng) Manners 在 Clips 中使用寬度（ Breadth）策略執(zhí)行時不會進(jìn)入無限循環(huán)，在下一節(jié)會說明，它同樣不會根據(jù)座位的最高 pid 來激發(fā)已激活的規(guī)則，從沒有發(fā)現(xiàn)這種解決方案。 } } rule pathDone() { when { context : Context( state == ) seating : Seating( pathDone == false ) } then { ( true )。這再次說明在 Agenda中的應(yīng)當(dāng)按任意順序執(zhí)行的激活規(guī)則同樣遵循 LIFO/FIFO策略。 ? 對客人的興趣使用數(shù)組，代替將它們作為單獨(dú)的 fact 設(shè)置。 Leaps 避免完全的叉集算法測試，僅僅留意主要的連接，因此當(dāng) Rete 可能建立數(shù)以百計(jì) 的激活規(guī)則時， Leaps僅僅建立一個，這導(dǎo)致了速度的量級增加