后臺審核管理 ergo

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

規則的全包執行模型

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

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

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

給定規則單元的規則與單元聲明一起收集在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

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

規則單元被提交給調度程序執行。 規則單元可以決定產生其執行給其他單位的規則，有效地將其付諸實施。 例如：

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

但是規則單元也可能處于長期運行狀態 。 在這種情況下，
其他規則單元可以同時在同一時間運行; 由于可以跨單元共享數據源，因此可以通過交換消息來協調單元。

考慮以下示例：

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

規則單元以某種方式充當交換消息的“參與者” 。 但是，以一種非常獨特的方式，規則單元允許執行更復雜的執行鏈，這適合基于規則的推理。 例如，
考慮一下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中的模式匹配嚴格只針對單個消息 。 這并不奇怪，因為參與者一次處理一條消息。 在規則引擎中，我們可以編寫幾個規則，在執行時對工作內存的整個狀態做出React：這明顯不同于純粹的參與者模型設計，但同時在創建時提供了很大的靈活性。您可以編寫應用程序的業務邏輯的方式。

數據源

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

Kogito：ergo Cloud

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

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

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

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

用戶可以使用自動生成的/ monitoring-service端點發布事件。回復將是查詢的結果。 在我們的情況下：

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

答復將是查詢的結果。 在我們的情況下：

{"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" }] }

多云，有規則

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

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

后臺審核管理 ergo

總結

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

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