Auswahl einer Rule-Engine

Wie im vorigen Post beschrieben kann man Rule-Engines nutzen, um Business-Logik in Regeln zu kapseln. Vorteile sind:

• Der Code ist leichter verständlicher. Die Regeln sind in einem extra Dokument, von wo aus man zentral alle Regeln bearbeiten/betrachten kann.
• Auch bei großen Datenmengen können die Business-Rules noch schnell ausgeführt bzw. die Daten noch schnell ausgewertet werden.
• Die Regeln können an aktuelle Anforderungen angepasst werden, ohne das System bis ins Detail kennen zu müssen ... und (!) man kann die Regeln von Außen zur Laufzeit gut manipulieren.

Wie funktionieren Rule-Engines nun?

Prozesse oder Daten müssen auf bestimmte Eigenschaften ausgewertet werden. Wird eine bestimmte Bedingung erfüllt, muss eine dafür geplante Aktion ausgeführt werden.

Diese Sachverhalte kann man in Regeln formulieren. Unsere Regeln bestehen also aus:

1. einer Bedingung, auf die ein Eingabedatum geprüft werden muss
2. und ein Folgeaktion, die nur dann ausgeführt wird, wenn die Bedingung erfüllt worden ist.

Regeln werden auf eine Menge von Fakten angewandt. Fakten sind unsere Geschäfts- oder Prozessdaten. Das Anwenden bzw. Ausführen der Regeln übernimmt die Rule-Engine.

Implementierung von Rule-Engines für Java gibt es einige (Vgl. http://java-source.net/open-source/rule-engines). Das Problem bei der Auswahl ist die Sprache, mit der die Regeln verwendet werden. Aktuell gibt es noch nicht wirklich einen Standard für solche Sprachen. Es gibt Sprachen, mit XML-Syntax, mit Lisp-ähnlicher Syntax, und diverse andere DSLs (Mehr Interessantes zu DSLs auf: http://raik-bieniek.blogspot.com/).

Bei der Suche nach einer geeigneten Rule-Engine für das Monitoring ist also die Regel-Sprache wichtig. als Regelsprache werde ich eine XML-Sprache verwenden. Die Manipulation von XML ist sehr einfach, da es für XML genügend Werkzeuge dafür gibt. In wie weit es genügend gute Werkzeuge für proprietäre Sprachen gibt, ist mir nicht bekannt. Das Suchen danach liegt momentan nicht in meinem Fokus. Daher soll es XML sein.
Weiterhin ist es von Vorteil, wenn die Rule-Engine für OSGi geeignet ist, sprich es sollte eine OSGi-Version davon geben. Dies ist jedoch kein "Muss", mehr ein "Nice-To-Have".

Über mich

Als erstes möchte ich für den frischen Blog ein paar Worte zu mir sagen.

Ich studiere seit 2008 Informatik und schreibe bereits meine Bachelorarbeit. Das Thema der Bachelorarbeit ist die "Entwicklung einer Monitoring-Komponente für den HTS" (http://www.humantaskservice.blogspot.com/). Um nur mal ein paar Buzzwords für die (Java-) Technologien zu nennen, mit denen ich mich gerade beschäftige, sei folgendes genannt:

• OSGi: Der HTS besteht aus den Teilen HTP, TPC und der Human Task Infrastructure (HTI). Diese wurde basierend auf dem OSGi-Standard entwickelt. Kurz gesagt bietet dieses Framework die folgenden Vorteile, die Grund für den Einsatz dessen waren: Modularisierung, Erweiterbarkeit, austauschbarkeit, Hot-Deployment
• Drools (Rule-Engine): Mit Hilfe von Rule-Engines kann man Business-Code einer Anwendung der aus etlichen If-Then-Else-Statements besteht in Form von Regeln implementieren. Diese Regeln, oft in einem extra Dokument formuliert, können dann von einer sog. Rule-Engine auf einen Satz von Daten ausgeführt werden. Damit errreicht man selbst bei einer riesigen Datenmenge eine immernoch performante Abarbeitung. Ein weiterer Grund Business-Logik in solchen Regeln zu formulieren ist, dass die einzelnen Regeln (je nach verwendeter  Regel-Sprache) einfacher lesbar, damit schneller verständlich und besser wartbar sind. Gerade in der heutigen Welt ändern sich die Anforderungen an ein Software-System sehr schnell.
• JMX: Die Java Management Extension erlaubt es Java-Anwendungen zu monitoren. Mehr dazu auf http://de.wikipedia.org/wiki/Java_Management_Extensions
• JAX-WS: Da die Dienste des HT-Service über das Netz angeboten werden, liegt es nahe Java-Webservices zu nutzen.

Dies sind die wichtigsten Technologien, mit denen die Monitoring-Komponente umgesetzt wird.