后臺審核管理 ergo

這是第二后 一系列更新的Kogito主動性和我們的努力，使Drools的云。 在本文中，我們將深入研究規(guī)則單元的詳細信息，并向您展示為什么我們對它們感到興奮。

規(guī)則的全包執(zhí)行模型

如果您一直在仔細檢查Drools手冊，以在每個最新發(fā)行版中尋找新功能，則您可能已經(jīng)注意到，該術(shù)語
統(tǒng)治單位已經(jīng)坐在那里一段時間了，這是一項極為實驗性的功能 。 簡而言之，規(guī)則單元既是規(guī)則的模塊又是執(zhí)行的單元 —之所以不稱其為模塊是為了避免與JVM模塊混淆。 在Kogito，我們正在重新研究并擴展我們的原始原型。

規(guī)則單元收集一組規(guī)則以及對該規(guī)則所作用的工作存儲器的描述。 工作存儲器的描述被編寫為帶有DataSource字段的常規(guī)Java類。 每個數(shù)據(jù)源代表工作存儲器的類型化分區(qū) ，并且存在具有不同功能的不同類型的數(shù)據(jù)源。 例如，在下面的示例中，我們使用了僅附加數(shù)據(jù)源，稱為
數(shù)據(jù)流。

public class MonitoringService implements RuleUnitMemory {private final DataStream<Event> events = DataSource.createStream();private final DataStream<Alert> alerts = DataSource.createStream(); }

給定規(guī)則單元的規(guī)則與單元聲明一起收集在DRL文件中

package org.kie.kogito.rules.alerting unit MonitoringService rule IncomingEvent when// matches when a temperature higher than 30 °C is registered (OOPath syntax)$e : /events # Temperature[ value >= 30 ] // Temperature is an Event subclass thenSystem.out.println("incoming event: "+ $e.getMessage());alerts.append( new WarningHighTemperature($e) ); end

單位中的每個規(guī)則都可以查看在相應(yīng)類中聲明的所有數(shù)據(jù)源。 實際上，一個單元的類和DRL文件的集合構(gòu)成一個整體 ：您可以將這樣的整體視為
一個單一的 類 ，其中字段是范圍限于當前單位的全局變量 ， 方法是規(guī)則 。 實際上，字段的使用取代了DRL全局變量的使用。

規(guī)則單元被提交給調(diào)度程序執(zhí)行。 規(guī)則單元可以決定產(chǎn)生其執(zhí)行給其他單位的規(guī)則，有效地將其付諸實施。 例如：

rule IncomingEvent when// matches when a temperature higher than 30 °C is registered (OOPath syntax)$e : /events # Temperature[ value >= 30 ] // Temperature is an Event subclass then// Suspend execution of this unit, yield to the HighTemperatureUnitHighTemperatureUnit.createInstance(events).run(); end

但是規(guī)則單元也可能處于長期運行狀態(tài) 。 在這種情況下，
其他規(guī)則單元可以同時在同一時間運行; 由于可以跨單元共享數(shù)據(jù)源，因此可以通過交換消息來協(xié)調(diào)單元。

考慮以下示例：

package org.kie.kogito.rules.alerting unit MonitoringService rule IncomingEvent when// matches when a temperature higher than 30 °C is registered (OOPath syntax)$e : /events # Temperature[ value >= 30 ] // Temperature is an Event subclass thenSystem.out.println("incoming event: "+ $e.getMessage());alerts.append( new WarningHighTemperature($e) ); end

規(guī)則單元以某種方式充當交換消息的“參與者” 。 但是，以一種非常獨特的方式，規(guī)則單元允許執(zhí)行更復(fù)雜的執(zhí)行鏈，這適合基于規(guī)則的推理。 例如，
考慮一下Akka手冊中的示例 ：

override def receive: Receive = {case RecordTemperature(id, value) =>log.info("Recorded temperature reading {} with {}", value, id)lastTemperatureReading = Some(value)sender() ! TemperatureRecorded(id)case ReadTemperature(id) =>sender() ! RespondTemperature(id, lastTemperatureReading)}

如您所見，Akka中的模式匹配嚴格只針對單個消息 。 這并不奇怪，因為參與者一次處理一條消息。 在規(guī)則引擎中，我們可以編寫幾個規(guī)則，在執(zhí)行時對工作內(nèi)存的整個狀態(tài)做出React：這明顯不同于純粹的參與者模型設(shè)計，但同時在創(chuàng)建時提供了很大的靈活性。您可以編寫應(yīng)用程序的業(yè)務(wù)邏輯的方式。

數(shù)據(jù)源

值得在數(shù)據(jù)源上花一些時間。 數(shù)據(jù)源構(gòu)造可以看作是對傳統(tǒng)工作內(nèi)存的分區(qū)和抽象 。 將提供不同類型的數(shù)據(jù)源：功能齊全的數(shù)據(jù)存儲區(qū)可能支持添加，刪除和更新值，從而允許在工作內(nèi)存上進行更多傳統(tǒng)操作； 而受限的僅追加數(shù)據(jù)流將更易于與外部數(shù)據(jù)源和數(shù)據(jù)接收器（例如Camel連接器）集成。 這樣的約束對于啟用更高級的用例（例如并行，線程安全的執(zhí)行和
在OpenShift集群的各個節(jié)點之間持久共享通道 （例如：Kafka），實現(xiàn)了完全分布式的規(guī)則引擎。

Kogito：ergo Cloud

并行和分布式用例很有趣 ，但是我們需要一步步走到那里。 但是，這并不意味著第一步不會像以自己的方式那樣令人興奮。

對于Kogito，我們要強調(diào)云原生的無狀態(tài)用例，其中
控制流程使用流程進行了外部 化，并借助
Quarkus我們可以將其編譯為超快速的本機二進制文件。 因此，我們將在接下來的幾周內(nèi)完成并發(fā)布以下規(guī)則單元 自動化REST服務(wù)實施 。

在此用例中， 規(guī)則單元的基于Java的類型化聲明為
自動映射到REST端點的簽名。 POST到端點意味著實例化該單元，將數(shù)據(jù)插入數(shù)據(jù)源，觸發(fā)規(guī)則，返回響應(yīng)有效負載。 使用用戶提供的查詢來計算響應(yīng)。 例如，考慮以下示例：

package org.kie.kogito.rules.alerting unit MonitoringService query Alerts(Alert alert) alert := /alerts # Warning // select all sub-type Warning end

用戶可以使用自動生成的/ monitoring-service端點發(fā)布事件?；貜?fù)將是查詢的結(jié)果。 在我們的情況下：

{"events": [ { "type": "WarningHighTemperature", "value": 40, "timestamp": "2019-07-12T18:25:45.000Z" }] }

答復(fù)將是查詢的結(jié)果。 在我們的情況下：

{"events": [ { "type": "Temperature", "value": 10, "timestamp": "2019-07-12T18:25:43.000Z" },{ "type": "Temperature", "value": 25, "timestamp": "2019-07-12T18:25:44.000Z" },{ "type": "Temperature", "value": 40, "timestamp": "2019-07-12T18:25:45.000Z" }] }

多云，有規(guī)則

我們已經(jīng)提出了對我們在Kogito及以后的下一代規(guī)則引擎的愿景。 無狀態(tài)用例只是邁向邁向規(guī)則引擎真正創(chuàng)新之舉的第一步。 在接下來的幾個月中，我們將致力于為并行（本地）和分布式（在Openshift上）調(diào)度和部署單元提供更好的支持，敬請期待。 同時，我們確實希望聽到您關(guān)于我們正在采取的方向的信息。

翻譯自: https://www.javacodegeeks.com/2019/08/kogito-ergo-rules-encompassing-execution-model.html

后臺審核管理 ergo

總結(jié)

以上是生活随笔為你收集整理的后台审核管理 ergo_Kogito，ergo规则—第2部分：规则的全面执行模型的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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