Architektur des Geschäftsregel-Frameworks
In der folgenden Abbildung wird die Architektur des Geschäftsregel-Frameworks gezeigt.
Architektur des Microsoft Geschäftsregel-Frameworks
In den folgenden Abschnitten werden einige der Framework-Komponenten beschrieben.
'Policy'-Klasse
Ein Policy-Objekt ist eine einzelne instance einer Geschäftsrichtlinie und stellt die Schnittstelle bereit, die von regelbasierten Anwendungen verwendet wird. Dank dieser Abstraktion müssen sich Anwendungsentwickler nicht weiter um die folgenden Punkte kümmern: den Speicherort für den Regelspeicher, das Extrahieren von Regelsätzen aus dem Regelspeicher, das Initiieren von Instanzen der zugrunde liegenden Regel-Engine sowie die Gewährleistung, dass lang andauernde Fakten an die Engine übergeben werden. In vielen Szenarien verwendet eine regelbasierte Anwendung gleichzeitige Instanzen des Policy-Objekts . Diese gleichzeitig ausgeführten Instanzen können dieselbe Richtlinie darstellen, verschiedene Versionen derselben Richtlinie oder unterschiedliche Versionen von unterschiedlichen Richtlinien.
'RuleEngine'-Klasse
Das RuleEngine-Objekt dient als Ausführungs-Engine für Geschäftsrichtlinien. Es verwendet drei Plug-In-Komponenten (Konvertierer, Rückschluss-Engine und Überwachungsinterceptor) für die Implementierung. Ein RuleEngine-Objekt verwendet ein RuleSet-Objekt , das eine Geschäftsrichtlinie als Eingabe darstellt, und verwendet den Translator, die Rückschluss-Engine und den Nachverfolgungs-Interceptor, der für den Regelsatz konfiguriert ist, um die vom Regelsatz definierte Geschäftsrichtlinie zu implementieren.
Fact Retriever
Ein Faktenabrufer ist eine optionale benutzerdefinierte Plug-In-Komponente, die lang andauernde Fakten für die Verwendung von Geschäftsrichtlinien erfasst. Weitere Informationen finden Sie unter Erstellen eines Fact Retrievers.
Vor der Ausführung stellt ein Policy-Objekt instance seine RuleEngine-instance für den Fact Retriever zur Verfügung, sodass es die Möglichkeit hat, den Faktensatz im Arbeitsspeicher der Regel-Engine zu aktualisieren. Weitere Informationen finden Sie unter Kurzfristige Fakten im Vergleich zu Long-Term Fakten.
Aktualisierungsdienst für die Regel-Engine
Der Aktualisierungsdienst für die Regel-Engine bietet dynamische Aktualisierungen der Geschäftsrichtlinien in einer verteilten Umgebung. Eine automatisch gestartete Microsoft Windows NT-Dienstanwendung ist verantwortlich für das Abonnieren der Richtlinienbereitstellung sowie für die Zurücknahme der Bereitstellungen, wenn Geschäftsrichtlinien geändert werden.
In einem typischen Unternehmensszenario werden Geschäftsrichtlinien nach dem Aktualisieren, Testen, und Einfügen von Versionsanmerkungen bereitgestellt. Bei der Bereitstellung wird die aktualisierte Richtlinie einem sicheren, persistenten Regelspeicher hinzugefügt. Optional wird Logik auf den Speicher angewendet, um allen interessierten Parteien Informationen zur aktualisierten Richtlinie zur Verfügung zu stellen (hierbei werden Informationen zur Richtlinie veröffentlicht und nicht die Richtlinie selbst).
Der Aktualisierungsdienst für die Regel-Engine wird auf einem Server ausgeführt, der als Host für regelbasierte Anwendungen dient. Der Dienst empfängt die Benachrichtigung für das Richtlinienupdate und legt die Informationen zur weiteren Verwendung im Zwischenspeicher ab. Mit dem Veröffentlichungs- und Abonnementmodell für Richtlinienaktualisierungen können Sie Geschäftsrichtlinien fast in Echtzeit ändern, ohne das System herunterzufahren oder unterbrechen zu müssen.
Entwicklungstools für Richtlinien/Vokabular
Der Business Rule Composer in Microsoft BizTalk Server bietet Richtlinien- und Vokabularerstellungsfunktionen für Endbenutzer und Entwickler.
Regelspeicher
Ein Regelspeicher ist ein Repository für Geschäftsrichtlinien und Vokabulare. Das Repository kann eine einfache Datei oder eine sichere, skalierbare, persistente und zuverlässige Datenbank wie Microsoft SQL Server sein. (SQL Server wird als standardmäßiger Regelspeicher für das Framework verwendet).
Caching
Das Business Rules Engine Framework bietet einen Zwischenspeicherungsmechanismus für RuleEngine-Instanzen . Jede RuleEngine-instance enthält eine Im-Memory-Darstellung einer bestimmten Richtlinienversion.
In den folgenden Schritten wird der Prozess beschrieben, wenn eine neue Richtlinien-instance instanziiert wird (entweder mit einem Aufruf der API oder der Ausführung des Aufrufregeln-Shapes):
Das Policy-Objekt fordert eine RuleEngine-instance aus dem Cache der Regel-Engine an.
Wenn ein RuleEngine-instance für die Richtlinienversion im Cache vorhanden ist, wird die RuleEngine-instance an das Policy-Objekt zurückgegeben. Wenn ein RuleEngine-instance nicht verfügbar ist, erstellt der Cache eine neue instance. Wenn ein RuleEngine-instance instanziiert wird, wird wiederum ein neuer Fakten-Retriever erstellt, instance, wenn einer für die Richtlinienversion konfiguriert ist.
Wenn die Execute-Methode für das Policy-Objekt aufgerufen wird, werden die folgenden Schritte ausgeführt:
Das Policy-Objekt ruft die UpdateFacts-Methodefür den Fakten-Retriever auf, instance, wenn ein Fakten-Retriever vorhanden ist. Die Implementierung der Methode durch den Fact Retriever kann langfristige Fakten im Arbeitsspeicher der RuleEngine geltend machen.
Das Policy-Objekt behauptet die kurzfristigen Fakten, die in dem Array enthalten sind, das im Execute-Aufruf übergeben wurde.
Das Policy-Objekt ruft Execute für ruleEngine auf.
RuleEngine schließt die Ausführung ab und gibt die Steuerung an das Policy-Objektzurück.
DasPolicy-Objektzieht die kurzfristigen Fakten aus ruleEngine zurück. Die vom Faktenabrufer übergebenen kurzfristigen Fakten verbleiben im Arbeitsspeicher der Regel-Engine.
Nachdem die Dispose-Methode für das Policy-Objekt aufgerufen wurde, wird die RuleEngine-instance wieder in den Cache der Regel-Engine freigegeben.
Im Zwischenspeicher der Regel-Engine befinden sich mehrere Regel-Engine-Instanzen für eine bestimmte Richtlinienversion, falls die Last dies erfordert, und jede Regel-Engine-Instanz besitzt eine eigene Faktenabruferinstanz.