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個“啟動過程”操作的初始性能，現在，隨著即將發布的版本，我們在單個應用程序服務器上具有的性能
十倍以上

翻譯自: https://www.javacodegeeks.com/2017/05/new-kie-persistence-api-7-0.html

kie-api

總結

以上是生活随笔為你收集整理的kie-api_7.0上的新KIE持久性API的全部內容，希望文章能夠幫你解決所遇到的問題。

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