Drools可执行模型还活着

总览

可执行模型的目的是提供规则集的纯基于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