使用Infinispan创建自己的Drools和jBPM持久性

我在这里发表的原始文章：

您好，欢迎来到我打算向您展示如何创建自己的Drools和jBPM持久性实现的帖子。我已经为流口水对象开发了基于infinispan的持久性方案，并且在此过程中学到了很多东西。如果您想做某种事情，我打算给您一些指导。

为什么？

如果您正在阅读本文，那么您可能已经有了一个“为什么”来重新定义流口水使用的持久性方案，但是回顾一些很好的理由来做这样的事情是很好的。最重要的是，您可能会认为出于一个或多个原因，为流口水设计的JPA持久性方案无法满足您的需求。我发现的一些最常见的是：

给定的模型不足以进行我的设计：为持久化流口水组件（会话，流程实例，工作项等）而创建的当前对象当前尽可能小，以使数据库具有最佳性能，并且大部分可操作数据存储在映射到Blob对象的字节数组中。这种方案足以使drools和jBPM运行时正常运行，但对于您的域可能还不够。您可能希望将运行时信息保存在一种方案中，该方案更易于从外部工具查询，而这样做则需要丰富数据模型，甚至创建自己的模型。

我正在使用的持久性与JPA不兼容：目前有很多持久性实现不再使用我们曾经知道的数据库（分布式缓存，键值存储，NoSQL数据库），并且该模型通常需要额外的映射和特殊功能坚持存放在这样的仓库中。这样做，有时JPA并不是我们的理想之选

每次加载drools组件时，我都需要从不同的来源加载特殊实体：当我们拥有复杂的对象和/或外部数据库时，有时我们希望新模型以特殊的方式与我们拥有的对象相关联。也许我们想确保我们的会话以特殊的方式绑定到我们的模型，因为这对我们的业务模型有意义。为此，我们必须更改模型

怎么样？

为了为我们的会话创建自己的持久性方案，我们需要清楚地了解JPA方案是如何构建的，并将其用作构建自己的持久性方案的模板。此类图显示了如何实现知识会话的JPA持久性方案：

看起来很复杂，对吧？不用担心我们将逐步了解它的工作原理。

首先，您可以看到我们有两个StatefulKnowledgeSession的实现（或者，如果您使用的是Drools 6，则为KieSession ）。一个完成所有“管脚魔术”的任务是StatefulKnoweldgeSessionImpl ，而我们将要使用的任务是CommandBasedStatefulKnowledgeSession 。它与持久性无关，但是通过将每个方法调用都包含在命令对象中并将其执行导出到命令服务中，对持久性有很大帮助。因此，例如，如果您对这种类型的会话调用fireAllRules方法，它将创建一个FireAllRulesCommand对象，并将其交给另一个类执行。

这种基于命令的实现使我们能够准确地完成在drools环境中实现持久性所需的工作：它使我们能够在对会话的每次方法调用之前和之后实现操作。那就是SingleSessionCommandService的地方
该类很方便：此命令服务包含一个StatefulKnowledgeSessionImpl和一个PersistenceContextManager。每次必须执行命令时，此类都会创建或加载SessionInfo对象，并告诉持久化上下文将其与StatefulKnowledgeSessionImpl的所有状态一起保存。

那是最复杂的部分：实现会话持久性的部分。几乎所有其他内容的持久性都可以通过一组给定的接口轻松完成，这些接口提供了一些方法来实现如何加载与会话相关的所有其他内容（流程实例，工作项和信号）。只要创建一个合适的经理及其工厂，就可以委托他们将任何东西存储到任何地方（或者做任何您想做的事情）。

因此，看完所有组件之后，现在是开始思考如何创建自己的实现的好时机。在此示例中，我们创建了一个基于Infinispan的持久性方案，并将向您展示实现该方案的所有步骤。

步骤1 ：（重新）定义模型

在大多数情况下，当我们想以自己的方式持久流口水时，我们可能会想尽办法做到。即使我们不希望更改模型，也可能需要向模型添加特殊注释才能与您的存储框架一起使用。另一个原因可能是您想以一种特殊的方式存储所有事实，以便与其他旧系统进行交叉查询。只要您了解所创建的模型，那么每次您在知识会话上调用方法时，持久性方案都会对它进行序列化和反序列化，就可以按照您希望的方式进行字面上的重新定义。因此，请始终尝试使其保持简单。

这是我们为这种情况创建的模型：

没什么花哨的，只是流口水相关的所有事物的扁平化模型。我们对这种模型不太有想像力，因为我们只是想向您显示可以更改它。

在该模型中要注意的一件事是，我们仍然保存这些对象的所有内部数据的方式与为JPA持久性存储数据的方式几乎相同。唯一的区别是JPA将其存储在Blob中，而我们将其存储在Base64加密的字符串中。如果要更改字节数组的生成和读取方式，则必须创建自己的以下接口实现：

org.kie.api.marshalling.Marshaller进行知识讲座
流程实例的org.jbpm.marshalling.impl.ProcessInstanceMarshaller

但是提供一个示例可能会花费大量时间，甚至可能需要整本书来解释，因此我们将跳过。

步骤2：实现PersistenceContext

在某些情况下，重新定义PersistenceContext和PersistenceContextManager就足以实现您的所有持久性要求。 PersistenceContext是一个对象，负责实现工作项和会话对象的持久化，方法是实现持久化工作项和会话对象的方法，并通过ID查询它们并将它们从特定的存储实现中删除。 PersistenceContextManager负责为所有应用程序创建一次或在每个命令的基础上创建PersistenceContext。 comand服务将在需要时使用它来持久化会话及其对象。

在我们的案例中，我们使用Infinispan缓存作为存储实现了PersistenceContext和PersistenceContextManager。不同的PersistenceContextManager实例将可以通过Environment变量访问所有配置对象。我们已经使用Environment中已定义的键来存储Infinispan相关的对象：

EnvironmentName.ENTITY_MANAGER_FACTORY用于存储基于Infinispan的CacheManager
EnvironmentName.APP_SCOPED_ENTITY_MANAGER和EnvironmentName.CMD_SCOPED_ENTITY_MANAGER将指向Infinispan缓存对象。

您可以在这里看到该代码：

在这一点上，我们有一些非常重要的步骤来重新定义我们的流口水持久性。现在，我们需要知道如何配置我们的知识会议以使用此组件。

步骤3：为我们的工作项目，流程实例和信号创建经理

现在我们有了持久性上下文，我们需要教会会议如何正确使用它们。知识会话具有一些可以配置的管理器，这些管理器使您可以修改或更改默认行为。这些经理是：

org.kie.api.runtime.process.WorkItemManager ：它管理工作项目的执行时间，将其与适当的处理程序连接，并在工作项目完成时通知流程实例。
org.jbpm.process.instance.event.SignalManager ：它管理何时向进程发送信号或从进程发送信号。由于流程实例可能被钝化，因此需要
org.jbpm.process.instance.ProcessInstanceManager ：它管理在创建，启动，修改或完成流程实例时要采取的动作。

这些接口的JPA实现已经可以与持久性上下文管理器一起使用，因此大多数时候您不需要扩展它们。但是，与Infinispan相比，我们必须确保流程实例的持久性要比JPA多，因此我们必须以不同的方式实现它们。

一旦有了这些实例，就需要为每种类型的管理器创建一个工厂。接口名称相同，但后缀“ Factory”除外。每个用户都接收一个知识会话作为参数，从中可以获取环境对象和所有其他配置。

步骤4：配置知识会话

现在我们已经创建了不同的经理，我们将需要告诉我们的知识会议以使用它们。为此，您需要使用SingleSessionCommandService实例创建一个CommandBasedStatefulKnowledgeSession实例。顾名思义，SingleSessionCommandService是一个用于一次针对一个会话执行命令的类。 SingleSessionCommandService的构造函数接收创建适当会话并对其执行持久化方式所需的所有参数。这些参数是：

KieBase ：具有用于会话运行时的知识定义的知识库。
KieSessionConfiguration ：我们在其中配置管理器工厂以创建和处理工作项，流程实例和信号。
环境：用于其他目的的一袋变量，我们将在其中配置持久性上下文管理器对象。
sessionId（可选） ：如果存在，则此参数在存储中查找已存在的会话。否则，它将创建一个新的。

同样，在我们的示例中，我们使用的是Infinispan，它不是基于引用的存储，而是基于值的存储。这意味着一旦您对infinispan说要存储一个值，它将存储它的一个副本而不是实际对象。流口水持久性中的某些内容通过基于引用的存储进行管理，这意味着您可以告诉框架持久化对象，更改其属性，并在提交事务后查看存储在数据库中的那些更改。使用infinispan不会发生这种情况，因此您必须在命令执行完成后实现对缓存值的更新。对我们来说幸运的是，SingleSessionCommandService允许我们通过实现拦截器来做到这一点。

拦截器基本上是您自己的命令服务，用于包装默认命令。您可以告诉每个命令在每次执行之前或之后添加更多行为。这里有一些图表来解释它是如何工作的：