kie-api

這篇文章介紹了即將到來的Drools和jBPM持久性API。 創(chuàng)建持久性api（不綁定到JPA）的動機(jī)是因為Drools和jBPM中的持久性直到7.0.0發(fā)行版才允許將替代性持久性機(jī)制與JPA完全集成。 盡管JPA是一個出色的api，但它與傳統(tǒng)RDBMS模型緊密地結(jié)合在一起，并具有從那里繼承的缺點-難以擴(kuò)展，并且難以在不斷擴(kuò)展的系統(tǒng)上獲得良好的性能。 使用新的api，我們可以集成各種通用的NoSQL數(shù)據(jù)庫，并創(chuàng)建緊密定制的持久性機(jī)制，以實現(xiàn)最佳性能和可伸縮性。

在撰寫本文時，已經(jīng)實現(xiàn)了幾種實現(xiàn)-默認(rèn)的JPA機(jī)制，Inifinispan和MapDB的兩個通用NoSQL實現(xiàn)后端（將作為貢獻(xiàn)提供），以及在本文中不久將討論的單個定制NoSQL實現(xiàn)。

Drools和jBPM持久性機(jī)制中所做的更改，其新功能，以及如何為KIE組件構(gòu)建全新的持久性實現(xiàn)，是即將添加新的MapDB集成實驗?zāi)K的基礎(chǔ)。 現(xiàn)有的Infinispan改編版已進(jìn)行更改，以適應(yīng)新的結(jié)構(gòu)。

由于這種重構(gòu)，除非我們的特定持久性實現(xiàn)基于JPA，否則我們現(xiàn)在可以在不依賴JPA的情況下為KIE提供其他持久性實現(xiàn)。 但是，它暗示了一組更改：

創(chuàng)建drools-persistence-api和jbpm-persistence-api

在版本6中，大多數(shù)持久性組件和接口僅存在于JPA項目中，在這些項目中必須從其他持久性中重用它們。 我們必須重構(gòu)這些項目以重用這些接口，而不必每次都添加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>

關(guān)于此重構(gòu)中的類的第一件事要提到的是，KIE組件用于KieSessions，WorkItems，ProcessInstances和CorrelationKeys的持久性模型不再是JPA類，而是一個接口。 這些接口是：

• 持久會話
  ：對于JPA實施，此接口由SessionInfo實施。 對于即將到來的MapDB實現(xiàn)，將使用MapDBSession。
• 持久工作項
  ：對于JPA實施，此接口由WorkItemInfo和MapDBWorkItem（對于MapDB）實現(xiàn)
• PersistentProcessInstance
  ：對于JPA實施，此接口由ProcessInstanceInfo和MapDBProcessInstance用于MapDB實施

重要的是，如果您正在使用JPA實現(xiàn)，并且希望繼續(xù)使用與以前相同的類，則可以使用它。 所有接口都準(zhǔn)備好與這些接口一起使用。 這將我們帶入下一個重點

PersistenceContext，ProcessPersistenceContext和TaskPersistenceContext重構(gòu)

版本6中的持久性上下文接口取決于模型的JPA實現(xiàn)。 為了與其他持久性機(jī)制一起使用，必須將它們進(jìn)行重構(gòu)以與運行時模型（分別為ProcessInstance，KieSession和WorkItem）一起使用，在本地構(gòu)建實現(xiàn)，并且能夠在其他組件的請求下返回正確的元素（ ProcessInstanceManager，SignalManager等）

同樣，對于TaskPersistenceContext之類的組件，在任務(wù)服務(wù)代碼中使用了多個動態(tài)HQL查詢，這些查詢在其他持久性模型中無法實現(xiàn)。 為了避免這種情況，他們被更改為使用與標(biāo)準(zhǔn)更相關(guān)的特定機(jī)制。 這樣，其他持久性機(jī)制可以以不同的方式使用不同的過濾對象，以創(chuàng)建所需的查詢。

任務(wù)模型重構(gòu)

當(dāng)前任務(wù)模型關(guān)聯(lián)任務(wù)和內(nèi)容，評論，附件和截止日期對象的方式還取決于JPA存儲該信息的方式，或更準(zhǔn)確地說，取決于ORM關(guān)聯(lián)這些類型的方式。 因此，如果需要，引入了任務(wù)持久性上下文接口的重構(gòu)來為我們建立組件之間的關(guān)系。 大多數(shù)方法仍然存在，并且仍然可以使用不同的表，但是，如果我們只想使用Task將所有內(nèi)容綁定在一起作為對象（NoSQL實現(xiàn)的方式），我們現(xiàn)在可以使用。 對于JPA實施，它仍然按ID關(guān)聯(lián)對象。 對于其他持久性機(jī)制（如MapDB），它只是將子對象添加到任務(wù)對象中，可以從內(nèi)部索引中獲取該對象。

任務(wù)模型發(fā)生的另一件事是，之前，我們有不同的接口來表示彼此不兼容的任務(wù)（Task，InternalTask??，TaskSummary等）。 對于JPA，這是可以的，因為它們將代表相同數(shù)據(jù)的不同視圖。

但是總的來說，這種界面混合的動機(jī)是允許對基于表的存儲進(jìn)行優(yōu)化，這絕不是一件壞事。 但是，對于基于非表的存儲，這些優(yōu)化可能沒有意義。 使這些接口兼容可以實現(xiàn)從存儲中檢索到的運行時對象以實現(xiàn)多個接口而不會破壞任何運行時行為的實現(xiàn)。 使這些接口兼容可以被視為第一步，進(jìn)一步的改進(jìn)將是使這些接口彼此延伸以強(qiáng)調(diào)模型并簡化實現(xiàn)。

（但是對于其他類型的實現(xiàn)，例如MapDB，直接獲得Task對象要比創(chuàng)建其他對象便宜得多，如果接口要求，我們需要能夠返回Task并使它作為TaskSummary工作。現(xiàn)在，所有接口都匹配相同的方法名稱，以允許這樣做。）

可擴(kuò)展TimerJobFactoryManager / TimerService

在版本6上，TimerJobFactoryManager的唯一可能的實現(xiàn)在構(gòu)造中由TimeJobFactoryType枚舉的值綁定。 進(jìn)行了重構(gòu)以擴(kuò)展現(xiàn)有類型，以允許動態(tài)添加其他類型的計時器作業(yè)工廠

MapDB案例

如果需要，可以重新實現(xiàn)所有這些接口以創(chuàng)建完全不同的持久性模型。 對于MapDB，這正是完成的工作。 對于仍在審查中的MapDB實施，有三個新模塊：

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

旨在使用MapDB實現(xiàn)類來實現(xiàn)所有Task模型。 希望為KIE組件提供另一種類型的實現(xiàn)的任何人都可以按照以下步驟進(jìn)行操作：

創(chuàng)建用于將持久性API項目與持久性實現(xiàn)機(jī)制依賴項混合的模塊

根據(jù)具有所有必要配置和注釋的給定接口創(chuàng)建模型實現(xiàn)

創(chuàng)建您自己的（Process | Task）PersistenceContext（Manager）類，以實現(xiàn)如何存儲持久對象

創(chuàng)建您自己的管理器（WorkItemManager，ProcessInstanceManager，SignalManager）和工廠，并使用所有必要的額外步驟來持久化模型。

創(chuàng)建您自己的KieStoreServices實現(xiàn)，該實現(xiàn)創(chuàng)建具有所需配置的會話，并將其添加到類路徑中

您并不孤單：MultiSupport案例

MultiSupport是一家丹麥公司，已使用此重構(gòu)創(chuàng)建自己的持久性實現(xiàn)。 他們提供了一個歸檔產(chǎn)品，該產(chǎn)品專注于創(chuàng)建O（1）檔案檢索系統(tǒng)，并且對使用與檔案相同的持久性機(jī)制來使內(nèi)部流程正常工作非常感興趣。

我們致力于實現(xiàn)一個可以增加大型數(shù)據(jù)庫響應(yīng)時間的實現(xiàn)。 鑒于其用于查找和檢索數(shù)據(jù)的內(nèi)部機(jī)制，他們能夠創(chuàng)建具有數(shù)百萬個活動任務(wù)的實現(xiàn)，而響應(yīng)時間幾乎沒有降低。

在MultiSupport中，我們使用持久性api基于內(nèi)部存儲引擎創(chuàng)建了量身定制的商店-我們的動機(jī)是提供無限的可伸縮性，擴(kuò)展的搜索功能，簡單的分發(fā)以及我們通過JPA實現(xiàn)而難以實現(xiàn)的性能。 我們認(rèn)為，這可以用作展示新的持久性api可以走多遠(yuǎn)的方式。 使用當(dāng)前的JPA實現(xiàn)和專用SQL Server，我們已經(jīng)達(dá)到了每秒少于10個“啟動過程”操作的初始性能，現(xiàn)在，隨著即將發(fā)布的版本，我們在單個應(yīng)用程序服務(wù)器上具有的性能
十倍以上

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

kie-api

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。