Schon seit ein paar Tagen habe ich mich mit Drools beschäftigt. Jetzt endlich kann ich sagen, die Engine, die ich fürs Monitoring benutzen kann. Was habe ich also die letzten Tage gemacht?
Zuerst einmal findet man im Netz relativ viel Material zu Drools. Die Beispiele für Regeldefinitionen haben mich natürlich am meisten interessiert. Schnell hatte ich einige gefunden, die ganz gut aussahen. Daher begann ich mich näher mit Drools zu beschäftigen um ein kleines Hello-World-Projekt aufzusetzen. Damit fingen die Probleme an.
Nachdem ich alle Ressourcen heruntergeladen und eingebunden hatte, habe ich ein Rule-File nach den Beispielen im Netz geschrieben. Leider lief nichts. Bei der Fehlersuche verwirrte mich Anfangs, dass es noch so viele andere Sprachen für Drools gab. Das genau ist der Punkt!
Drools hat erstens sein eigenes Regelformat namens "drl" (kein XML) und zweitens unterstützt es außerdem noch Regeldefinition via XML. Das Tückische daran ist, dass Drools, aktuell in der Version 5.2.0 vorliegend, eine sehr starke Entwicklung durchlaufen hat. So gibt es einige verschiedene XML-Formate, die alle nicht mehr aktuell sind. Die Materialien, die man im Netz dazu findet, sind oft für die alten Formate gewesen. Wenn man das weiß, stellt es kein Problem dar :-)
Mein Hello-World-Beispiel habe ich zum laufen bekommen. Es ist das Ergebnis dieses Wochenendes. Eine komische Fehlermeldung wird jedoch nach wie vor angezeigt. Trage ich die Schemaversionen analog zum Versionsstand (5) von Drools ein, findet er das Schema nicht. Trage ich die Version 4 ein, wie es in der aktuellen Dokumentation von der Drools-Seite zu lesen ist, bekomme ich die Meldung, dass ich doch bitte mal Version 5 eintragen soll. Seltsam!
Mein Hello-World-Beispiel kommt später.
Montag, 11. Juli 2011
Auswahl einer Rule-Engine
Um Business-Logik, also z.B. die Implementierung der SLAs, zu kapseln, kann man Rule-Engines verwenden. Dafür wird die Logik in Regeln (in einer speziellen Sprache) definiert. Vorteile sind:
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:
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".
- Der Code ist leichter verständlicher. Die Regeln sind in einem extra Dokument, von wo aus man zentral alle Regeln bearbeiten/betrachten kann.
- Es erfolgt eine bessere Trennung von Daten und Logik.
- 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.
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:
- einer Bedingung, auf die ein Eingabedatum geprüft werden muss
- und ein Folgeaktion, die nur dann ausgeführt wird, wenn die Bedingung erfüllt worden ist.
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".
Abonnieren
Posts (Atom)