kie-api_7.0上的新KIE持久性API

kie-api

这篇文章介绍了即将到来的Drools和jBPM持久性API。创建持久性api（不绑定到JPA）的动机是因为Drools和jBPM中的持久性直到7.0.0发行版才允许将替代性持久性机制与JPA完全集成。尽管JPA是一个出色的api，但它与传统RDBMS模型紧密地结合在一起，并具有从那里继承的缺点-难以扩展，并且难以在不断扩展的系统上获得良好的性能。使用新的api，我们可以集成各种通用的NoSQL数据库，并创建紧密定制的持久性机制，以实现最佳性能和可伸缩性。

在撰写本文时，已经实现了几种实现-默认的JPA机制，Inifinispan和MapDB的两个通用NoSQL实现后端（将作为贡献提供），以及在本文中不久将讨论的单个定制NoSQL实现。

Drools和jBPM持久性机制中所做的更改，其新功能，以及如何为KIE组件构建全新的持久性实现，是即将添加新的MapDB集成实验模块的基础。现有的Infinispan改编版已进行更改，以适应新的结构。

由于这种重构，除非我们的特定持久性实现基于JPA，否则我们现在可以在不依赖JPA的情况下为KIE提供其他持久性实现。但是，它暗示了一组更改：

创建drools-persistence-api和jbpm-persistence-api

在版本6中，大多数持久性组件和接口仅存在于JPA项目中，在这些项目中必须从其他持久性中重用它们。我们必须重构这些项目以重用这些接口，而不必每次都添加JPA依赖项。这是一组新的依赖项：

<dependency><groupId>org.drools</groupId><artifactId>drools-persistence-api</artifactId><version>7.0.0-SNAPSHOT</version>
</dependency>
<dependency><groupId>org.jbpm</groupId><artifactId>jbpm-persistence-api</artifactId><version>7.0.0-SNAPSHOT</version>
</dependency>

关于此重构中的类的第一件事要提到的是，KIE组件用于KieSessions，WorkItems，ProcessInstances和CorrelationKeys的持久性模型不再是JPA类，而是一个接口。这些接口是：

持久会话
：对于JPA实施，此接口由SessionInfo实施。对于即将到来的MapDB实现，将使用MapDBSession。
持久工作项
：对于JPA实施，此接口由WorkItemInfo和MapDBWorkItem（对于MapDB）实现
PersistentProcessInstance
：对于JPA实施，此接口由ProcessInstanceInfo和MapDBProcessInstance用于MapDB实施

重要的是，如果您正在使用JPA实现，并且希望继续使用与以前相同的类，则可以使用它。所有接口都准备好与这些接口一起使用。这将我们带入下一个重点

PersistenceContext，ProcessPersistenceContext和TaskPersistenceContext重构

版本6中的持久性上下文接口取决于模型的JPA实现。为了与其他持久性机制一起使用，必须将它们进行重构以与运行时模型（分别为ProcessInstance，KieSession和WorkItem）一起使用，在本地构建实现，并且能够在其他组件的请求下返回正确的元素（ ProcessInstanceManager，SignalManager等）

同样，对于TaskPersistenceContext之类的组件，在任务服务代码中使用了多个动态HQL查询，这些查询在其他持久性模型中无法实现。为了避免这种情况，他们被更改为使用与标准更相关的特定机制。这样，其他持久性机制可以以不同的方式使用不同的过滤对象，以创建所需的查询。

任务模型重构

当前任务模型关联任务和内容，评论，附件和截止日期对象的方式还取决于JPA存储该信息的方式，或更准确地说，取决于ORM关联这些类型的方式。因此，如果需要，引入了任务持久性上下文接口的重构来为我们建立组件之间的关系。大多数方法仍然存在，并且仍然可以使用不同的表，但是，如果我们只想使用Task将所有内容绑定在一起作为对象（NoSQL实现的方式），我们现在可以使用。对于JPA实施，它仍然按ID关联对象。对于其他持久性机制（如MapDB），它只是将子对象添加到任务对象中，可以从内部索引中获取该对象。

任务模型发生的另一件事是，之前，我们有不同的接口来表示彼此不兼容的任务（Task，InternalTask，TaskSummary等）。对于JPA，这是可以的，因为它们将代表相同数据的不同视图。

但是总的来说，这种界面混合的动机是允许对基于表的存储进行优化，这绝不是一件坏事。但是，对于基于非表的存储，这些优化可能没有意义。使这些接口兼容可以实现从存储中检索到的运行时对象以实现多个接口而不会破坏任何运行时行为的实现。使这些接口兼容可以被视为第一步，进一步的改进将是使这些接口彼此延伸以强调模型并简化实现。

（但是对于其他类型的实现，例如MapDB，直接获得Task对象要比创建其他对象便宜得多，如果接口要求，我们需要能够返回Task并使它作为TaskSummary工作。现在，所有接口都匹配相同的方法名称，以允许这样做。）

可扩展TimerJobFactoryManager / TimerService

在版本6上，TimerJobFactoryManager的唯一可能的实现在构造中由TimeJobFactoryType枚举的值绑定。进行了重构以扩展现有类型，以允许动态添加其他类型的计时器作业工厂

MapDB案例

如果需要，可以重新实现所有这些接口以创建完全不同的持久性模型。对于MapDB，这正是完成的工作。对于仍在审查中的MapDB实施，有三个新模块：

org.kie：drools-persistence-mapdb
org.kie：jbpm-persistence-mapdb
org.kie：jbpm-human-task-mapdb

旨在使用MapDB实现类来实现所有Task模型。希望为KIE组件提供另一种类型的实现的任何人都可以按照以下步骤进行操作：

创建用于将持久性API项目与持久性实现机制依赖项混合的模块
根据具有所有必要配置和注释的给定接口创建模型实现
创建您自己的（Process | Task）PersistenceContext（Manager）类，以实现如何存储持久对象
创建您自己的管理器（WorkItemManager，ProcessInstanceManager，SignalManager）和工厂，并使用所有必要的额外步骤来持久化模型。
创建您自己的KieStoreServices实现，该实现创建具有所需配置的会话，并将其添加到类路径中

您并不孤单：MultiSupport案例

MultiSupport是一家丹麦公司，已使用此重构创建自己的持久性实现。他们提供了一个归档产品，该产品专注于创建O（1）档案检索系统，并且对使用与档案相同的持久性机制来使内部流程正常工作非常感兴趣。

我们致力于实现一个可以增加大型数据库响应时间的实现。鉴于其用于查找和检索数据的内部机制，他们能够创建具有数百万个活动任务的实现，而响应时间几乎没有降低。

在MultiSupport中，我们使用持久性api基于内部存储引擎创建了量身定制的商店-我们的动机是提供无限的可伸缩性，扩展的搜索功能，简单的分发以及我们通过JPA实现而难以实现的性能。我们认为，这可以用作展示新的持久性api可以走多远的方式。使用当前的JPA实现和专用SQL Server，我们已经达到了每秒少于10个“启动过程”操作的初始性能，现在，随着即将发布的版本，我们在单个应用程序服务器上具有的性能
十倍以上