Bevorzugte Methoden für die Interaktion mit einer Regelengine

Wir verwenden ILOG für DotNet und haben ein Pilotprojekt im Einsatz.

Hier ist eine Zusammenfassung unserer unreifen Regeln Architektur:

1. Der gesamte Datenzugriff erfolgt außerhalb der Regeln.
2. Regeln werden auf die gleiche Weise wie Code implementiert (Quellcodeverwaltung, Release-Prozess, yada yada).
3. Projekte (Dienste), die Regeln verwenden, haben einen Verweis auf ILOG.Rules.dll und new-up RuleEngines über eine benutzerdefinierte Pooling-Klasse. RuleEngines werden zusammengefasst, da es sehr aufwendig ist, einen RuleSet an eine RuleEngine zu binden.
4. Fast alle Regeln werden geschrieben, um Assert'd-Objekte zu erwarten, anstatt RuleFlow-Parameter.
5. Da die Regeln im selben Speicherbereich ausgeführt werden, sind die Instanzen, die durch die Regeln geändert werden, die gleichen Instanzen im Programm - dies ist die sofortige Weitergabe des Status.
6. Fast alle Regeln werden über RuleFlow ausgeführt (auch wenn es sich um einen einzelnen RuleStep im RuleFlow handelt).

Wir betrachten RuleExecutionServer als Hosting-Plattform sowie RuleTeamServerForSharePoint als Host für die Regelquelle. Schließlich werden Regeln außerhalb des Code-Release-Prozesses für die Produktion bereitgestellt.

Das Haupthindernis in all unseren Regelbemühungen ist das Skillset Modellieren und Regelnerstellen.

Ich mochte das Zentralisierungsargument nie. Es bedeutet, dass alles in die Regelengine eingekoppelt wird, die zu einem Abladeplatz für alle Regeln im System wird. Ziemlich bald kann man aus Angst vor dem Unbekannten nichts ändern: "Was werden wir brechen?"

Ich ziehe es vor, Amazons Idee von Dienstleistungen als isolierte, autonome Komponenten zu verfolgen. Ich interpretiere das so, dass Dienste ihre Daten und ihre Regeln besitzen.

Dies hat den zusätzlichen Vorteil, den Regelbereich zu partitionieren. Ein Regelsatz wird schwieriger zu pflegen, wenn er wächst. besser, sie auf eine überschaubare Größe zu halten.

Wenn Teile des Regelsatzes freigegeben sind, würde ich eine datengesteuerte DI-Methode bevorzugen, bei der ein Service seine eigene Instanz einer Regel-Engine haben und beim Start die allgemeinen Regeln aus einer Datenbank laden kann. Dies ist möglicherweise nicht machbar, wenn Ihre iLog-Lizenz mehrere Instanzen zu teuer macht. Das wäre ein Fall, in dem Produkte, die helfen sollen, tatsächlich architektonische Entscheidungen diktieren, die Trauer bringen. Es wäre ein gutes Argument für eine weniger teure Alternative (z. B. JBoss-Regeln in Java-Land).

Was ist mit einem datengesteuerten Entscheidungsbaum-Ansatz? Ist eine Rete-Regel-Engine wirklich notwendig, o ist die "Enterprise-Tool" -Entscheidung Ihre Wahl?

Ich würde versuchen, die Regelengine so einzurichten, dass sie so weit wie möglich vom Rest des Unternehmens abgekoppelt ist. Ich würde es nicht zu Datenbanken oder Diensten rufen, wenn ich könnte. Besser, die Verantwortung der Objekte zu übernehmen, die um eine Entscheidung bitten. Lassen Sie sie die notwendigen Web-Services und Datenbanken aufrufen, um die notwendigen Daten zu sammeln, sie an die Rules-Engine zu übergeben und sie ihre Sache machen zu lassen. Kopplung ist dein Feind: Versuche dein System so zu gestalten, dass es minimiert wird. Es ist eine gute Möglichkeit, Regel-Engines isoliert zu halten.

Ich habe nicht viel zu sagen über die Frage "welcher Server", aber ich würde Sie dringend bitten, Entscheidungsdienste zu entwickeln - abrufbare Dienste, die Regeln verwenden, um Entscheidungen zu treffen, die aber den Geschäftszustand nicht ändern. Wenn die anrufende Anwendung / Dienst / Prozess entscheiden, welche Datenänderungen als Ergebnis des Aufrufs des Entscheidungsdienstes vorgenommen werden und die aufrufende Komponente die vom Entscheidungsdienst vorgeschlagene (n) Aktion (en) tatsächlich initiiert, erleichtert dies den Entscheidungsdienst immer wieder wieder (über Kanäle, Prozesse usw.). Je sauberer und weniger an den Rest der Infrastruktur gebunden ist, desto entscheidungsfähiger ist der Service, desto mehr wiederverwendbar und überschaubar wird es. Die Diskussion hier auf ebizQ könnte in dieser Hinsicht lesenswert sein.

Nach meiner Erfahrung mit Rules-Engines haben wir eine ziemlich einfache Reihe von Methoden angewendet, um die Interaktion mit der Rules-Engine zu steuern. Vor allem waren dies immer kommerzielle Rules-Engines (iLog, Corticon) und nicht Open Source (Drools), daher war die Bereitstellung lokal auf jedem der App-Server aufgrund der Lizenzkosten nie wirklich eine praktikable Option. Daher sind wir immer mit dem zentralisierten Modell gegangen, wenn auch in zwei Hauptgeschmacksrichtungen:

• Remoteausführung des Webdiensts - Auf die gleiche Weise, wie Sie in Ihrer Frage angegeben haben, rufen wir SOAP-basierte Dienste auf, die vom Produkt rules engine bereitgestellt werden. Innerhalb des Web-Service-Bereichs sind wir auf mehrere Optionen gestoßen: (1) "Boxcar" -Anforderungen, die es der Anwendung ermöglichen, Regelverarbeitungsanforderungen in Warteschlangen einzureihen und sie im Gegensatz zu einmaligen Nachrichten in Chunks zu senden; (2) Stellen Sie die Threading- und Prozessoptionen des Anbieters ein. Dies umfasst die Möglichkeit, Entscheidungsdienste nach Funktionen zu trennen und jeweils ein W3WP und / oder Webgärten zuzuteilen. Es gibt sehr viele Feinheiten, die Sie mit Boxcars, Threads und Prozessen erreichen können. Die richtige Mischung ist eher ein Versuch und Irrtum (und Sie kennen Ihre Regelsätze und Daten) als eine exakte Wissenschaft.
• Remote-Aufruf der Rules Engine in Process - Ein klassischer Batch-Trick, um den Overhead von Serialisierung und Deserialisierung zu vermeiden. Rufen Sie in der Ferne einen Aufruf ab, der einen In-Process-Aufruf an die Regelengine auslöst. Dies kann entweder geplant (z. B. Batch) oder basierend auf Bedarf (d. H. "Boxcars" von Anforderungen) erfolgen. In beiden Fällen kann ein Großteil des Overheads der Serviceaufrufe vermieden werden, indem direkt mit dem Prozess und der Datenbank interagiert wird. Nachteil dieses Prozesses ist, dass Sie nicht über IIS oder Ihren EJB / Servlet-Container verfügen, der die Threads für Sie verwaltet, und Sie müssen es selbst tun.