總覽

可執行模型的目的是提供規則集的純基于Java的表示，以及方便的Java DSL以編程方式創建這種模型。 該模型是低級別的，旨在為用戶提供所需的所有信息，例如用于索引評估的lambda。 這樣可以使其保持快速運行，并避免在此級別上進行過多的假設。 預計將來會有更高層次的表示形式出現，這可能會更加關注最終用戶。 這項工作還高度補充了單元工作，它提供了一種面向Java的方式來提供數據和控制流程。

細節

該模型具有足夠的通用性，可以獨立于Drools，但可以編譯為一個普通的Drools知識庫。 因此，可執行模型的實現已分為兩個子項目：

drools-canonical-model是完全獨立于Drools的規則集模型的規范表示

drools-model-compiler將規范模型編譯為Drools內部數據結構，使其可由引擎執行

可執行模型的引入在不同領域帶來了一系列好處：

• 編譯時間 ：在Drools 6中，一個kjar包含了drl文件和其他Drools工件的列表，這些工件定義了規則庫以及一些實現約束和后果的預生成類。 從Maven存儲庫下載kjar并將其安裝在KieContainer中時，需要從頭開始解析和編譯這些drl文件，這使得此過程非常緩慢，特別是對于大型規則集。 相反，現在可以在kjar中封裝實現項目規則庫的可執行模型的Java類，并以更快的方式從中重新創建KieContainer及其KieBases。 kie-maven-plugin在編譯過程中會自動從drl文件生成可執行模型源。
• 運行時 ：在可執行模型中，所有約束都定義為Java lambda表達式。 相同的lambda也用于約束評估，這可以擺脫對解釋的評估的mvel和轉換字節碼中基于mvel的約束的jitting過程，從而導致緩慢的預熱過程。
• 未來的研究 ：可執行模型將允許試驗規則引擎的新功能，而無需以drl格式編碼它們并修改drl解析器以支持它們。

可執行模型DSL

為可執行模型設計DSL的第一個迭代時，一個目標是擺脫模式的概念，并將規則視為表達式（約束）和動作（結果）的流。 因此，我們將其稱為Flow DSL。 此DSL的一些示例在此處提供 。

但是，在實施Flow DSL之后，很明顯，避免明確使用模式的決定使我們不得不實施一些既具有復雜性又具有性能成本的額外邏輯 ，因為為了正確地重新創建模型期望的數據結構， Drools編譯器有必要將那些看似無關的表達式組合在一起。

因此，已經決定在第二個DSL中重新引入模式，我們將其稱為模式DSL 。 這樣就可以繞開那些必須填補人為語義空白并且在運行時也很耗時的表達式分組算法。

我們認為兩種DSL都適用于不同的用例，因此我們決定保留并支持這兩種。 尤其是Pattern DSL更安全，更快（即使更冗長），因此這將是在通過kie-maven-plugin創建kjar時自動生成的DSL。 相反，Flow DSL更加簡潔，更接近于用戶希望以Java編程方式定義規則的方式，我們計劃通過后處理器自動生成定義模型的模型部分，從而使其不再那么冗長。索引和屬性反應性。 換句話說，我們期望模式DSL將由機器編寫，流DSL最終將由人編寫。

程序化構建

如前一節中鏈接的測試用例所證明的那樣，可以用Java以編程方式定義一個或多個規則，然后使用流暢的API將它們添加到模型中。

Model model = new ModelImpl().addRule( rule );

一旦有了該模型，該模型完全獨立于Drools算法和數據結構，便可以按照以下方法創建一個KieBase

KieBase kieBase = KieBaseBuilder.createKieBaseFromModel( model );

另外，也可以通過從普通的drl文件開始，將它們添加到KieFileSystem來創建基于可執行模型的kieproject。

KieServices ks = KieServices.Factory.get(); KieFileSystem kfs = ks.newKieFileSystem().write( "src/main/resources/r1.drl", createDrl( "R1" ) ); KieBuilder kieBuilder = ks.newKieBuilder( kfs );

然后使用buildAll（）方法的新重載來構建項目，該方法接受一個類，該類指定要構建的項目類型

kieBuilder.buildAll( ExecutableModelProject.class );

這樣做，KieBuilder將生成可執行模型（基于Pattern DSL），然后生成結果KieSession

KieSession ksession = ks.newKieContainer(ks.getRepository().getDefaultReleaseId()).newKieSession();

如本文檔第一部分所述，它將與基于lambda表達式的約束一起使用。 同樣，通過將不同的項目類傳遞給KieBuilder，也可以從Flow DSL生成可執行模型。

kieBuilder.buildAll( ExecutableModelFlowProject.class );

但是，對于討論2種不同的DSL時所解釋的內容，為此目的最好使用基于模式的DSL。

Kie Maven插件

為了使用kie-maven-plugin生成嵌入可執行模型的kjar，有必要在pom.xml文件中添加與兩個之前提到的實現模型及其編譯器的項目相關的依賴項：

<dependencies><dependency><groupId>org.drools</groupId><artifactId>drools-model-compiler</artifactId></dependency><dependency><groupId>org.drools</groupId><artifactId>drools-canonical-model</artifactId></dependency> </dependencies>

還將插件添加到插件部分

<build><plugins><plugin><groupId>org.kie</groupId><artifactId>kie-maven-plugin</artifactId><version>${project.version}</version><extensions>true</extensions></plugin></plugins> </build>

這里已經準備好生成可執行模型的pom.xml文件的示例。 默認情況下，kie-maven-plugin仍會生成基于drl的kjar，因此必須使用以下參數運行插件：

-DgenerateModel=<VALUE>

其中<VALUE>可以是三個值之一：

YES NO WITHDRL

YES和WITHDRL都將使用實現與原始項目中的drl文件相對應的可執行模型的Java類來生成Java并將其添加到kjar，不同之處在于第一個將從生成的kjar中排除drl文件，而第二個還將添加它們。 但是，在第二種情況下，由于無論如何，KieBase都是從可執行模型構建的，因此drl文件將僅起文檔作用。

未來發展

如預期的那樣，下一個目標之一是使DSL（尤其是流量）更加用戶友好，尤其是使用后處理器生成可以自動推斷的所有部分，例如與索引和屬性反應性有關的部分。

從可執行模型的角度來看，我們特別通過在規則單元上完成的工作改進了規則的模塊化和編排。圍繞pojo-ification的重點補充了圍繞純Java DSL的研究方向，并且我們已經有一些簡單的示例說明了可執行模型和規則單元可以混合使用。

翻譯自: https://www.javacodegeeks.com/2018/02/drools-executable-model-alive.html

總結

以上是生活随笔為你收集整理的Drools可执行模型还活着的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。