Aufgabenstellung

Fangen wir mit einer Aufgabenstellung an. Ziel ist es, Menschen, die bei Regenwetter an einem Regenschirmgeschäft vorbeilaufen, einen Hinweis auf’s Mobiltelefon zu schicken: “Wie wäre es mit einem Regenschirm?” (Wer reine Regenschirmgeschäfte nicht kennt. Ich auch nicht. Aber: es wird bestimmt solche spezialisierten Geschäfte geben, verdammt, ich bin letztens in einem Senfladen gewesen – man glaubt gar nicht, mit welchen Dingen man seine Zunge töten und Magenrevolutionen starten kann – uhm, nur mal am Rande)

Die Handys schicken ihre Geokoordinaten, Sensoren die Niederschlagsmenge. Es sollen nun aber die registrierten Nutzer des Dienstes nur dann informiert werden, wenn sie im Umkreis von 50m um das Geschäft sind und innerhalb von 5 Minuten stärkere Regenfälle gemeldet werden.

Lösungsmöglichkeiten

SQL ist der Hammer

…den man immer einsetzen kann. Man schreibe eine kleine Applikation, die beständig die Geokoordinaten der Nutzer in einer Tabelle speichert, die Wetterdaten in einer anderen. Sobald ein Regenevent eintrifft, prüfen wir die Daten der letzten 5 Minuten und falls auch diese Regen der nötigen Stärke aufweisen, durchsuchen wir die Geodaten nach passenden Regenschirmkandidaten.

Das Problem ist damit lösbar. Klar ist aber auch: je mehr Nutzer beobachtet werden müssen, je mehr Datenquellen auch hinzukommen und in Summe je komplizierter die Aufgabe ist, desto höher ist hier die Belastung der Datenbank, die Speicherauslastung und damit auch die Kosten.

Alternative: Event Stream Processing

Ein ESP dreht die Welt um. Man definiert Muster/Regeln durch die Events hindurchströmen. Bleibt ein Event in einem Muster hängen, wird eine Aktion ausgelöst. Auf den ersten Blick ist ein ESP also sehr ähnlich einer RETE-Engine, einer Ruleengine wie z.B. drools. Doch üblicherweise kommen bei einem ESP noch zeitliche und räumliche Abfrageoptionen hinzu – die drools derzeit noch fehlen.

Was ist zu tun, um das oben genannte Problem mit einem ESP zu lösen? Zunächst werden Eventtypen deklariert – in diesem Fall gibt es zwei: Nutzer- und Regensensordaten.

public class UserEvent {
  String firstName;
  String lastName;
  String mobileNumber;
  double locationX;
  double locationY;
}

public class SensorEvent {
  double rainIntensity;
  long sensorId;
}

Diese Eventtypen werden nun regelmäßig in die ESP-Engine “gepumpt”. Fein. Nur was macht das dumme Ding damit? So natürlich sich nur peinlich berührt räuspern. Was fehlt ist die Musterdefinition. Auch wenn sich ESPs voneinander unterscheiden und eine jeweils andere Syntax verwenden, so ähneln sie doch im Grunde sehr stark einer SQL-Abfrage:

every sensor1=SensorEvent(intensity>2.0) ->
  (sensor2=SensorEvent() and
     sensorId != sensor1.sensorId and intensity>2.0 ) ->
   sensor3=SensorEvent() and
     sensorId not in (sensor1.sensorId, sensor2.userId) and
     intensity>2.0))
  ) where timer:within(5 min)

Diese Regel schlägt an, wenn über einen Zeitraum von 5 Minuten (timer:within) drei Events mit einer Regenintensität größer drei eingetrudelt sind. Sobald dieses Ereignis eingetreten ist, kann eine weitere Regel aktiviert werden, die nun die Geodaten der Nutzer im Umkreis auswertet:

every other=UserEvent (locationX in [5 : 55],
                                    locationY in [5: 55])

Das Einspielen erfolgt über eine einfache Java-Klasse:

public class RainMonitor {
...

public void registerUserEvent {
 locateUsers = epService.getEPAdministrator().createPattern("
             every other=UserEvent (locationX in [5 : 55],
                                                locationY in [5: 55])");

 locateUsers.addListener(new UpdateListener() {
            public void update(EventBean[] newEvents, EventBean[] oldEvents)
            {
                UserEvent other = (UserEvent) newEvents[0].get("other");
                MatchAlertBean alert = new MatchAlertBean(other.getUserMobileNumber(), other.getFirstName(), other.getLastName());
                epService.getEPRuntime().emit(alert);
            }
        });

Was ist nun geschehen? Wir haben Regeln definiert und in der Engine registriert. Sobald ein Muster erkannt wurde, wird ein Listener aktiviert, der daraufhin auf die Eventdaten zugreifen kann, um eine Aktion auszulösen (in diesem Fall: das Senden einer SMS)
Schön hierbei: es ist sparsam. Und flexibel. Neue Regeln können schnell definiert und zur Laufzeit eingespielt werden.

Schließlich muss man bedenken, dass es um Massenverarbeitung geht. Denn zumeist werden weit mehr als zwei Datenströme ausgewertet. Korrelationen zwischen Hunderten an Events sind möglich. Zigtausende Auswertungen können mit dieser Technologie durchgeführt werden. Zwar kann man es mit SQL genauso lösen oder bei geschickter Entwicklung auch in memory, jedoch: warum?

Weitere Informationen:

• http://esper.codehaus.org (Esper: GPL-ESP-Engine)
• http://www.progress.com/apama/index.ssp (Apama ESP)
• ESP vs. ESB

Dies lösen wir – oh, Gott, Hypeattacke – über eine SOA-Architektur mit einem Enterprise Service Bus (ESB) im Zentrum. Dieser spielt den großen Mediator zwischen Automaten, eigenen Services und externen Schnittstellen.

Ändert man jedoch nur einen Buchstaben, wechselt man vom ESB zu ESP, ergibt sich eine weit aus größere Veränderung: ESP steht für Event Stream Processor. ESP-Applikationen sind darauf ausgelegt, Unmengen an Nachrichten verarbeiten zu können. Allerdings zumeist nicht auf per message Basis. ESP schauen sich den Nachrichtenstrom an und erkennen im Fluß Muster. Die einzelne Nachricht ist egal, wichtig ist, die Masse an Informationen zu betrachen und Korrelationen zu erkennen. Gibt es eine Übereinstimmung, kann ein Service (oder ein ESB) angestoßen werden, der eine entsprechende Aktion auflöst.

Übertragen auf unseren Anwendungsfall (was hier ein wenig an den Haaren herbeigezogen ist, aber ich bin heute nur bedingt kreativ) könnte ein Beispiel lauten:

“Musterdefinition: wenn ein Automat nicht innerhalb von einer halben Stunde eine Nachricht schickt, dann triggere MachineOfflineStrategy”

Natürlich gibt es für diesen Fall bessere Lösungen, es zeigt aber einen sehr interessanten Aspekt an einem ESP auf: die Definition von “Zeit-basierenden Sichtfenstern”: man lege eine Schablone über den Nachrichtenfluss und prüfe für diesen Ausschnitt nach Musterübereinstimmungen.

Feine Sache. Und, uhm, ja, das “ESP vs. ESB” habe ich nur sprachklanglichen Gründen eingefügt. Genau genommen sind ESP und ESB ein hervorragendes Tandem.

Dazu später mehr.