In verschiedenen Bereichen der Applikationsentwicklung kommt es vor, dass aufgrund einer Wissensbasis Entscheidungen getroffen werden müssen. Dies kann in Web-Applikationen oder Datenbankanwendungen vorkommen, wo man zum Beispiel Benutzereingaben validieren muss:
- Ist der eingegebene Wert eine Zahl?
- Ist das angegebene Geburtsdatum über 1950 und kleiner als?
- Hat die Kreditkartennummer ein bestimmtes Format?
Es können aber durchaus auch komplexere Zusammenhänge sein, die es zu beurteilen gilt – wie «Hat ein Kunde Anspruch auf Rabatt»? Für diese Entscheidung könnte eine Kombination von Regeln notwendig sein, die beispielsweise bewerten, wie lange er bereits Kunde ist oder ob er regelmässig eingekauft hat. Derartige Problemstellungen findet man in einer grossen Zahl von Anwendungsfeldern. Diese reichen von geradezu «historischen» Einsatzbereichen wie Expertensystemen, die anhand von Regelsystemen versuchen, entscheidungsunterstützend zu wirken, über genannte Formularvalidierungen und Geschäftsanwendungen bis hin zu Spielen, in denen Spielregeln je nach Spielsituation auszuwerten sind.
Die architektonische Frage, die sich dann aufdrängt, ist, wie man derartige Systeme am besten implementiert. Natürlich kann man in einer Programmiersprache wie Java die Regeln in Bedingungen (if/then) «hart» codieren. Dies kann in vielen einfachen Fällen durchaus sinnvoll sein. Daneben existieren für Spezialfälle auch Frameworks, die gewisse Überprüfungen deklarativ erlauben. So gibt es beispielsweise im Bereich der Web-Formular-Frameworks meist die Möglichkeit, zu beschreiben, welche Werte in Formularfeldern erlaubt sind, beziehungsweise die Möglichkeit, entsprechende Prüfroutinen zu definieren.
Auch in Geschäftsanwendungen kommt es häufig vor, dass ganze Regelsysteme zu implementieren sind. Erschwerend kommt hier meist dazu, dass diese Regeln von Fachkräften, Managern, Sachbearbeitern und nicht von Technikern definiert werden (Kasten «Beispiel für Regelsatz» gibt ein Beispiel für einen Regelsatz, wie er im geschäftlichen Umfeld vorkommen könnte). Regeln im Geschäftsumfeld werden meist in drei Kategorien eingeteilt:
- Konsistenzregeln: Diese dienen dazu, Eingabewerte oder Datensätze zu validieren und auf Konsistenz zu prüfen.
Ist die Anwendung beziehungsweise die Wissensbasis hinreichend komplex, so kann die Strategie, diese Regeln «hart» zu kodieren, aus verschiedenen Gründen zu Problemen führen:
- Im Geschäftsumfeld beispielsweise sind diejenigen, die Regeln definieren, Sachbearbeiter oder Manager und keine Techniker/Informatiker. Es ist eine Trennung der Rollen wünschenswert.
- Komplexe Regelsysteme werden in hart codierten If-Blöcken oft äusserst unübersichtlich, schwer verständlich und entsprechend schwer wartbar.
- Abhängig von der Lebensdauer der Anwendung sowie der Wahrscheinlichkeit, dass sich die Regelbasis ändert, muss in den Quellcode der Anwendung eingegriffen werden, wenn Adaptionen erforderlich sind.
- Regeln sind je nach Anwendungsfall nicht immer leicht auf If/Then-Codierung abzubilden. Statt dessen sind andere Formen gewünscht (Regeln in natürlicher oder Domain-spezifischer Sprache, Entscheidungstabellen usw.).
Aus diesen und anderen Gründen ist es oftmals wünschenswert, die Regeln von der Anwendungslogik zu trennen. Hier kommen zeitgemässe Rule Engines wie Jboss Rules (Drools) oder Jess ins Spiel.
Eine Regel besteht bei einer Rule Engine aus einer Bedingung und einer Aktion, die beim Eintreffen der Bedingung zu folgen hat. Die obenstehende Abbildung zeigt die grundlegende Funktionsweise einer Rule Engine:
- Regeln und Datenbasis (Fakten) werden getrennt.
- Die Regeln können je nach Rule Engine in verschiedenen Formaten vorgelegt werden.
- Fakten sind Daten, die zur Laufzeit «auf die Regeln losgelassen werden».
- Ein Pattern-Matching-Algorithmus (oft Rete) prüft, welche Regeln ansprechen.
- Dabei wird zunächst eine Konfliktmenge gebildet (es können mehrere Regeln gültig sein).
- Welche Regeln tatsächlich in welcher Reihenfolge ausgeführt werden, wird im Konfliktlösungsschritt geklärt, und das Ergebnis ist dann eine Agenda.
Man kann sich eine Rule Engine also als leistungsfähige If/Then-Maschine vorstellen, wobei die If/Then-Statements aus den Regeln abgeleitet und auf die Fakten angewendet werden.
Zu den leistungsfähigsten Rule Engines im Java-Bereich zählen Jboss Drools und Jess, wobei Jess auch den Java Rules Standard JSR 94 unterstützt.
Algorithmus zur Regel-Bearbeitung
Wie schon erwähnt, können die Regeln je nach Rule Engine in ganz unterschiedlichen Formen vorliegen. Manche Rule Engine wie Drools erlauben auch die Verwendung von Regeltabellen. Dabei kann der Domänen-Experte die Regeln in Form einer Tabelle in der Tabellenkalkulation erstellen. Die Zeilen entsprechen dabei Regeln, die Spalten Bedingungen respektive Konsequenzen. Folgt die Tabelle bestimmten Konventionen, kann sie direkt von der Rule Engine geladen werden.
Oft ist es nicht ganz einfach, zu entscheiden, ob für ein bestimmtes Problem eher ein Workflow/Geschäftsprozess-Framework wie Jboss jBPM oder verschiedene BPEL Engines (Active BPEL, Ode) oder eine Rule Engine eingesetzt werden soll.
Grundsätzlich kann man sagen, dass Rule Engines eher darauf abgestimmt sind, «lokal» in einer bestimmten Anwendung zu laufen, um dort komplexe Regeln auszuwerten, während Prozess-Engines darauf spezialisiert sind, auch verteilte Prozesse (wie BPEL über Webservices) zu verwalten und zu kontrollieren. Workflows sind typischerweise auch lang laufende Vorgänge – sogar über Tage und Wochen –, während die Abarbeitung einer Regel meist ein schneller Vorgang ist.
Es kann allerdings zu Überschneidungen kommen. So kann es in Prozessabläufen notwendig werden, an bestimmten Stellen Entscheidungen zu treffen. Hier bieten Prozesssprachen wie BPEL entsprechende (einfache) Mechanismen an. Eventuell kann an solchen Stellen dann auch eine Rule Engine komplexere Regeln abbilden. Das führt dazu, dass in der letzten Zeit in den Communities auch diskutiert wird, ob man Rule Engines und Prozess-Engines nicht zusammenführen sollte. Allerdings gibt es hier noch kaum konkrete Ergebnisse.
Rule Flow
Die Auswertung komplexer Regeln kann auch in verschiedenen Enterprise-Architekturen und Integrations-Szenarien sinnvoll sein. Im letzten Artikel haben wir das Konzept des Enterprise Service Bus (ESB) und konkrete Implementierungen und Standards wie Java Business Integration (JBI) vorgestellt. Rule Engines wie Jboss Drools können nun auch als JBI-Komponente in einer JBI-fähigen ESB-Implementierung wie Apache Service Mix eingeführt und verwendet werden.
Drools könnte dann einerseits als Routing-Komponente eingesetzt werden – also anhand definierter Regeln entscheiden, wie Nachrichten weitergeleitet werden. Andererseits könnten Aktionen definiert werden, die einsetzen, wenn bestimmte Zustände eintreten: Aktionen für ein Szenario vergleichbar zur nebenstehenden Abbildung könnten beispielsweise ausgeführt werden, wenn eine neue Bestellnachricht eingeht.
Rule Engines sind zwar durchaus keine triviale Technologie, bieten sich aber in Stand-alone-Applikationen sowie in Enterprise-Architekturen an, wenn Entscheidungen oder Aktionen anhand von (komplexen) Wissenszusammenhängen zu fällen sind. Diese lassen sich oftmals leichter in Regeln ausdrücken als in konkretem Programmcode. Diese Regeln sind typischerweise auch leichter verständlich als entsprechender Programmcode.
Der Ansatz erlaubt weiter die saubere Trennung von Regeln und Anwendungslogik und kann daher die Wartbarkeit der Systeme erleichtern. Auch das Anpassen und Verändern der Wissensbasis (Regeln) ist zur Laufzeit leichter möglich, weil keine Eingriffe in die Applikation erforderlich sind.
Im Open-Source-Umfeld gibt es mittlerweile eine Anzahl von sehr leistungsfähigen Rule Engines wie Jess oder Jboss Drools, die sich auch in Enterprise-Architekturen gut integrieren lassen.
Kommerzielle Rule Engines bieten oft umfangreichen Tool-Support an, aber auch die Open-Source-Varianten verfügen in den neuesten Versionen schon über Plug-ins und Design-Komponenten für IDEs.
Rules
· JBoss Rules (Drools)
· Jess
Orchestration
· Active BPEL
· Apache Ode (BPEL Engine)
· JBoss jBPM
ESB Integration
· z.B. mit Apache Service Mix & Drools
Neue Bestellung:
· Wenn Bestellsumme grösser als 1000 Franken ist, muss Kreditrahmen geprüft werden
· Wenn Kunde «Premium»-Status hat, muss Kreditrahmen nie geprüft werden
· Wenn Bezahlmethode «Kreditkarte», Karteninfos (Nummer, Ablaufdatum ...) prüfen
· Wenn Bezahlmethode «Abbuchung», Kontoinfos prüfen
· Wenn Kunde im letzten Monat mehr als 5 Mal eingekauft hat, Rabatt von 3 % gewähren
· Wenn Kunde im letzten Monat für mehr als 5000 Franken eingekauft hat, gibt’s Rabatt von 5 %
· Wenn Kunde «Premium»-Status hat, schnelle Lieferung kostenfrei
· Wenn Lieferung «schnell», zusätzliche Kosten aufschlagen
Alexander Schatten (alexander@schatten.info) ist Assistent am Institut für Softwaretechnik und interaktive Systeme der Technischen Universität Wien.
