站长统计app进入网址,免费网站建站有哪些,百度招聘平台,html中文网站模板kie-api这篇文章介绍了即将到来的Drools和jBPM持久性API。 创建持久性api#xff08;不绑定到JPA#xff09;的动机是因为Drools和jBPM中的持久性直到7.0.0发行版才允许将替代性持久性机制与JPA完全集成。 尽管JPA是一个出色的api#xff0c;但它与传统RDBMS模型紧密地结合在… 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依赖项。 这是一组新的依赖项 dependencygroupIdorg.drools/groupIdartifactIddrools-persistence-api/artifactIdversion7.0.0-SNAPSHOT/version /dependency dependencygroupIdorg.jbpm/groupIdartifactIdjbpm-persistence-api/artifactIdversion7.0.0-SNAPSHOT/version /dependency 关于此重构中的类的第一件事要提到的是KIE组件用于KieSessionsWorkItemsProcessInstances和CorrelationKeys的持久性模型不再是JPA类而是一个接口。 这些接口是 持久会话 对于JPA实施此接口由SessionInfo实施。 对于即将到来的MapDB实现将使用MapDBSession。 持久工作项 对于JPA实施此接口由WorkItemInfo和MapDBWorkItem对于MapDB实现 PersistentProcessInstance 对于JPA实施此接口由ProcessInstanceInfo和MapDBProcessInstance用于MapDB实施 重要的是如果您正在使用JPA实现并且希望继续使用与以前相同的类则可以使用它。 所有接口都准备好与这些接口一起使用。 这将我们带入下一个重点 PersistenceContextProcessPersistenceContext和TaskPersistenceContext重构 版本6中的持久性上下文接口取决于模型的JPA实现。 为了与其他持久性机制一起使用必须将它们进行重构以与运行时模型分别为ProcessInstanceKieSession和WorkItem一起使用在本地构建实现并且能够在其他组件的请求下返回正确的元素 ProcessInstanceManagerSignalManager等 同样对于TaskPersistenceContext之类的组件在任务服务代码中使用了多个动态HQL查询这些查询在其他持久性模型中无法实现。 为了避免这种情况他们被更改为使用与标准更相关的特定机制。 这样其他持久性机制可以以不同的方式使用不同的过滤对象以创建所需的查询。 任务模型重构 当前任务模型关联任务和内容评论附件和截止日期对象的方式还取决于JPA存储该信息的方式或更准确地说取决于ORM关联这些类型的方式。 因此如果需要引入了任务持久性上下文接口的重构来为我们建立组件之间的关系。 大多数方法仍然存在并且仍然可以使用不同的表但是如果我们只想使用Task将所有内容绑定在一起作为对象NoSQL实现的方式我们现在可以使用。 对于JPA实施它仍然按ID关联对象。 对于其他持久性机制如MapDB它只是将子对象添加到任务对象中可以从内部索引中获取该对象。 任务模型发生的另一件事是之前我们有不同的接口来表示彼此不兼容的任务TaskInternalTask​​TaskSummary等。 对于JPA这是可以的因为它们将代表相同数据的不同视图。 但是总的来说这种界面混合的动机是允许对基于表的存储进行优化这绝不是一件坏事。 但是对于基于非表的存储这些优化可能没有意义。 使这些接口兼容可以实现从存储中检索到的运行时对象以实现多个接口而不会破坏任何运行时行为的实现。 使这些接口兼容可以被视为第一步进一步的改进将是使这些接口彼此延伸以强调模型并简化实现。 但是对于其他类型的实现例如MapDB直接获得Task对象要比创建其他对象便宜得多如果接口要求我们需要能够返回Task并使它作为TaskSummary工作。现在所有接口都匹配相同的方法名称以允许这样做。 可扩展TimerJobFactoryManager / TimerService 在版本6上TimerJobFactoryManager的唯一可能的实现在构造中由TimeJobFactoryType枚举的值绑定。 进行了重构以扩展现有类型以允许动态添加其他类型的计时器作业工厂 MapDB案例 如果需要可以重新实现所有这些接口以创建完全不同的持久性模型。 对于MapDB这正是完成的工作。 对于仍在审查中的MapDB实施有三个新模块 org.kiedrools-persistence-mapdb org.kiejbpm-persistence-mapdb org.kiejbpm-human-task-mapdb 旨在使用MapDB实现类来实现所有Task模型。 希望为KIE组件提供另一种类型的实现的任何人都可以按照以下步骤进行操作 创建用于将持久性API项目与持久性实现机制依赖项混合的模块 根据具有所有必要配置和注释的给定接口创建模型实现 创建您自己的Process | TaskPersistenceContextManager类以实现如何存储持久对象 创建您自己的管理器WorkItemManagerProcessInstanceManagerSignalManager和工厂并使用所有必要的额外步骤来持久化模型。 创建您自己的KieStoreServices实现该实现创建具有所需配置的会话并将其添加到类路径中 您并不孤单MultiSupport案例 MultiSupport是一家丹麦公司已使用此重构创建自己的持久性实现。 他们提供了一个归档产品该产品专注于创建O1档案检索系统并且对使用与档案相同的持久性机制来使内部流程正常工作非常感兴趣。 我们致力于实现一个可以增加大型数据库响应时间的实现。 鉴于其用于查找和检索数据的内部机制他们能够创建具有数百万个活动任务的实现而响应时间几乎没有降低。 在MultiSupport中我们使用持久性api基于内部存储引擎创建了量身定制的商店-我们的动机是提供无限的可伸缩性扩展的搜索功能简单的分发以及我们通过JPA实现而难以实现的性能。 我们认为这可以用作展示新的持久性api可以走多远的方式。 使用当前的JPA实现和专用SQL Server我们已经达到了每秒少于10个“启动过程”操作的初始性能现在随着即将发布的版本我们在单个应用程序服务器上具有的性能 十倍以上 翻译自: https://www.javacodegeeks.com/2017/05/new-kie-persistence-api-7-0.htmlkie-api