Masterarbeit zum Thema. Complex Event Processing in verteilten, mobilen Umgebungen. Dominique Bellenger Matrikelnummer:

Größe: px
Ab Seite anzeigen:

Download "Masterarbeit zum Thema. Complex Event Processing in verteilten, mobilen Umgebungen. Dominique Bellenger Matrikelnummer: 1116868 2011-09-30"

Transkript

1 Fachhochschule Hannover University of Applied Science and Arts Fakultät IV - Wirtschaft und Informatik Studiengang Angewandte Informatik Masterarbeit zum Thema Complex Event Processing in verteilten, mobilen Umgebungen Dominique Bellenger Matrikelnummer:

2 Selbstständigkeitserklärung Hiermit erkläre ich, dass ich die eingereichte Masterarbeit selbständig und ohne fremde Hilfe verfasst, andere als die von mir angegebenen Quellen und Hilfsmittel nicht benutzt und die den benutzten Werken wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht habe. Hannover, den 30. September 2011 Dominique Bellenger Autor: Erstprüfer: Zweitprüfer: Dominique Bellenger Prof. Dr. Ralf Bruns Oliver Pawlowski, M.Sc. Stammestraÿe 77 Fachhochschule Hannover, Fakultät IV Hannover Ricklinger Stadtweg Hannover Seite I

3 Inhaltsverzeichnis 1 Einleitung Aufgaben und Ziele der Arbeit Eingrenzung der Plattform Aufbau der Arbeit Grundlagen von EDA/CEP und mobilen Plattformen Event-Driven Architecture (EDA) und Complex Event Processing (CEP) Event-Driven Architecture Complex Event Processing Eigenschaften mobiler Plattformen Die Datenverbindung Minimale Ressourcen Interne Kommunikationsmechanismen und Multitasking auf mobilen Plattformen Google Android Apple ios Analyse der Integrationsmöglichkeiten einer mobilen Plattform in eine CEP- Umgebung Varianten der Integration in eine CEP-Umgebung Als Event-Quelle ohne Event-Verarbeitung Als ausgelagerte Event-Verarbeitung Als Event-Consumer ohne Event-Verarbeitung Als Event-Consumer mit Event-Verarbeitung Als Event-Quelle mit Event-Verarbeitung Als Event-Quelle und Event-Consumer mit Event-Verarbeitung Als Event-Quelle und Event-Consumer ohne Event-Verarbeitung Zusammenfassung Anforderungen an die Komponenten der CEP-Lösung Anforderungen an die Event-Quelle Anforderungen an den Channel Anforderungen an den Agenten Anforderungen an den Consumer Anforderungen an das Event-Processing Network Seite II

4 Inhaltsverzeichnis Anforderungen an die Datenübertragung zwischen CEP-Komponenten auf physisch getrennten Systemen Globale Anforderungen Complex Event Processing auf mobilen Geräten Persistierung des Zustands einer CEP-Umgebung Rule Engines für mobile Plattformen Zusammenfassung der Erkenntnisse Konzept einer CEP-Umgebung für ein mobiles Endgerät Das Grundkonzept - wie werden die Elemente einer CEP-Umgebung abgebildet Die Events Quellen, Channels, Agenten und Consumer Details der Einzelkomponenten Agenten Consumer Event-Quellen Channels Verfeinerung des Konzepts Das Event Processing Network Eine Factory für die Channels Ressourcenverbrauch minimieren Die sich ergebenden Klassen im Überblick Technische Umsetzungsmöglichkeiten für die externe Kommunikation Datenformat Datenübertragung zwischen physisch getrennten Systemen Beispiel-Implementierung auf Google Android Rahmenbedingungen Die Entwicklungsumgebung Das mobile Endgerät Die Basis-Applikation Umsetzung der Einzelkomponenten Event Event-Quelle Channel EventSerializer ChannelFactory EventProcessingNetwork Agent Consumer Seite III

5 Inhaltsverzeichnis 6 Fazit Rückblick auf die erarbeiteten Ergebnisse Herausforderungen während der Bearbeitung Ergebnis der Arbeit Bevorzugung einer Plattform Ausblick Seite IV

6 1 Einleitung Nachdem Apple mit dem iphone neue Maÿstäbe im Bezug auf die mobile Telefonie gesetzt hat, ziehen andere Anbieter nach: Der Markt für Smartphones wird immer gröÿer. Ihre Verbreitung nimmt seit einigen Jahren, auch aufgrund von alternativen Betriebssystemen wie Android, stark zu. Smartphones werden nicht mehr nur als notwendiges Arbeitsmittel von Geschäftsleuten, sondern zunehmend auch als mobiles High-Tech-Gadget von Privatpersonen jeglicher Couleur genutzt. Die Anwendungen auf den Geräten sind somit auch nicht mehr ausschlieÿlich auf die Geschäftswelt fokussiert. Es gibt auÿer Adressbüchern und Kalendern schier unendlich viele neue Anwendungsfälle; das Smartphone als PDA wird hierdurch zur Nebensache. Aktuelle Smartphones verfügen dabei über eine Vielzahl an Sensoren, die für unterschiedlichste Zwecke genutzt werden können. So ist in der Mehrheit aktueller Smartphones ein GPS-Empfänger integriert, selbst die Lage im Raum kann durch Beschleunigungs- und Gyrosensoren festgestellt werden. Auch die Rechenkapazität der ständigen Begleiter ist enorm, so ist diese inzwischen vergleichbar mit der von Notebooks von vor wenigen Jahren. Dabei haben aktuellste Smartphones schon die Gigahertz-Marke durchbrochen und arbeiten mit zwei Kernen und bis zu einem Gibibyte Arbeitsspeicher. Die Rechenleistung und vor allem die unterschiedlichen Sensoren werden dabei jedoch hauptsächlich für lokale Anwendungen auf den Telefonen genutzt. Es ist jedoch vorstellbar, insbesondere die Sensordaten auch anderweitig, zum Beispiel in einem Gebäudemanagementsystem, zu nutzen. Dabei könnten z.b. verschiedene Daten des Telefons für die Bestimmung des aktuellen Standorts einer Person im Gebäude herangezogen werden. Diese Daten könnten dann zur intelligenten Gebäudesteuerung, z.b. zur Schaltung von Licht oder zum Önen von Türen, genutzt werden. Die Standort- und Bewegungsdaten von verschiedenen mobilen Geräten können ebenso im Bereich der Verkehrsführung und Stauerkennung genutzt werden, wie es z.b. der ADAC (StauScanner 1 und Google (Maps mit Trac Layer 2 zeigen. Die Möglichkeiten, einen Nutzen aus dem generierten Datenstrom von Smartphones zu ziehen, sind oensichtlich äuÿerst vielfältig. Da es sich bei den meisten Daten um zeitabhängige Gröÿen handelt, sollen diese nach Möglichkeit nahezu in Echtzeit verarbeitet werden. So wird die Position eines Mobiltelefons (und damit seines Besitzers) mit hoher Wahrscheinlichkeit nicht x sein, sondern sich mit fortschreitender Zeit ändern. Im Verlauf der Zeit werden die alten Positionen des Mobiltelefons dann für aktuelle Schlüsse mit hoher Wahrscheinlichkeit irrelevant werden. 1 = abgerufen am abgerufen am Seite 1

7 Kapitel 1. Einleitung 1.1. Aufgaben und Ziele der Arbeit Für diese Art der Verarbeitung von vielen Daten in nahezu Echtzeit wird seit einiger Zeit auf Ereignisgesteuerte Architekturen gesetzt. Hier wird häug Complex Event Processing (CEP) als Verarbeitungsmodell verwendet. 1.1 Aufgaben und Ziele der Arbeit Von einem Smartphone generierte (Sensor-) Daten lassen sich mit wenig Interpretation als Ereignisse einstufen. So ist zum Beispiel das Betreten eines Bereichs, in dem ein bestimmtes WLAN empfangen werden kann oder das Verlassen einer bestimmten Mobilfunkzelle ein solches Ereignis. Diese Ereignisdaten eines Telefons können recht einfach isoliert betrachtet werden, sie sind dann aber meist wenig aussagekräftig. Diese Ereignisse treten bei der Betrachtung von mehreren Sensoren am Telefon sowie unter Umständen bei der Verwendung mehrerer Geräte als Ereignisstrom auf. Zur Verarbeitung solcher Ereignisströme hat sich Complex Event Processing bewährt. Dabei werden die Ereignisse in der Reihenfolge ihres Auftretens betrachtet und der Ereignisstrom auf bestimmte Ereignismuster untersucht. Auch neue, komplexe Ereignisse können während der Verarbeitung erzeugt und in den Strom eingespeist werden. Können bestimmte Muster identiziert werden, erlaubt dies das Ziehen von Rückschlüssen und damit schlieÿlich auch das Ausführen von Aktionen. Im Rahmen dieser Arbeit soll eine Evaluation über ereignisbasierte Echtzeitverarbeitung in mobilen, verteilten Systemen erfolgen. Dabei soll vor allem festgestellt werden, wie sich mobile Endgeräte mit ihren speziellen Eigenschaften in eine Architektur mit Complex Event Processing einfügen lassen. Auch soll untersucht werden, in wie weit die Verarbeitung von Ereignissen direkt auf dem Gerät erfolgen kann Eingrenzung der Plattform Der Fokus im Bereich der mobilen Endgeräte wird dabei auf Mobiltelefonen bzw. Smartphones liegen. Ihre zunehmende Verbreitung in allen Lebensbereichen, ob es beruicher oder privater Natur ist, bietet ein stetig wachsendes Einsatzpotential auch über den ursprünglichen Zweck eines Telefons hinaus. Als Basis dient dabei Googles oene Plattform Android, auf welcher die Ergebnisse am Ende der Arbeit schlieÿlich auch vorgestellt werden. Da sich die Plattform einer hohen Beliebtheit erfreut, bietet sich Android für die nähere Evaluierung sowie die Konzeption und Implementierung der Software an. So zeigen Umfragen und Prognosen, dass Android sowohl im zweiten Quartal 2011 nicht nur die meist genutzte Plattform für Smartphones ist, 34 sondern auch, dass Android in Zukunft weiter Marktanteile gewinnen wird 5. Aufgrund der oenen Plattform, einer wachsenden Fangemeinde und der damit verbundenen Kostenersparnis, existieren heute viele Hersteller aus unterschiedlichsten Branchen, für die es somit interessant wird Android in ihren Produkten einzusetzen. Dabei handelt es sich 3 - abgerufen am abgerufen am abgerufen am Seite 2

8 Kapitel 1. Einleitung 1.2. Aufbau der Arbeit allerdings nicht ausschlieÿlich um Mobiltelefone oder Tablet-PCs, sondern z.b. um Autos 67 und sogar Waschmachinen und Mikrowellen 8. Selbstverständlich wird versucht, die Erkenntnisse und damit verbundenen Empfehlungen und Entscheidungen nicht nur auf Android zu beziehen. Aus diesem Grund wird an ausgesuchten Stellen ebenfalls das mögliche Vorgehen bei Verwendung des zweiten groÿen Smartphone- Betriebssystems, Apple ios, grob geschildert. Eine nähere Betrachtung ndet in diesem Fall jedoch nicht statt, da ios im Gegensatz zu Android an spezielle, proprietäre Hardware gebunden ist. Damit sind die Einsatzbereiche beschränkter und diese Plattform für eine explizite Umsetzung der gewonnenen Erkenntnisse als solches weniger interessant. Andere Betriebssysteme bzw. Plattformen, wie zum Beispiel Microsoft Windows Mobile oder RIM Blackberry, werden nicht näher betrachtet. Die Erkenntnisse, welche sich auf das Einbinden einer mobilen Plattform in eine Complex-Event-Processing-Architektur beziehen, lassen sich aber ebenfalls auf diese Systeme anwenden. 1.2 Aufbau der Arbeit Die Arbeit gliedert sich in sechs Kapitel. Das Einführungskapitel beschäftigt sich mit der Problemstellung, den Aufgaben und Zielen der Arbeit, sowie deren Strukturierung. In Kapitel 2 werden Event-Driven Architecture und Complex Event Processing erläutert. Zudem wird in diesem Kapitel auf die besonderen Eigenschaften von mobilen Endgeräten eingegangen. Dieses Kapitel bildet die Grundlage, auf deren Basis die folgenden konzeptuellen und sonstigen Entscheidungen getroen werden. Im darauf folgenden Kapitel 3 wird eine Analyse der Problematik angefertigt. Hierzu wird auf die in Kapitel 2 vermittelten Grundlagen zurückgegrien. Ebenso wird auf bestehende CEP- Lösungen eingegangen und insbesondere betrachtet, inwiefern CEP auf mobilen Endgeräten schon eingesetzt wird oder eingesetzt werden kann. Aus den Ergebnissen werden dann die Anforderungen an die zu entwickelnde Software und Architektur deniert. Anschlieÿend werden für verschiedene Problemstellungen, die während der Erarbeitung der Anforderungen auftauchen unterschiedliche Lösungsansätze evaluiert. In Kapitel 4 wird ein Konzept erarbeitet, welches den Anforderungen Rechnung trägt. Das Gesamtkonzept ist dabei mehrteilig aufgebaut. So werden für die unterschiedlichen Komponenten der angestrebten Complex Event Processing Architektur einzelne Konzepte zur Umsetzung beschrieben. Kapitel 5 widmet sich der prototypischen Implementierung des vorher erarbeiteten Konzepts. Schlieÿlich werden in Kapitel 6 die erreichten Ergebnisse kritisch beleuchtet und ein Blick in die Zukunft geworfen. An dieser Stelle werden auch Verbesserungsmöglichkeiten und weitere, mögliche Änderungen am Konzept betrachtet abgerufen am abgerufen am abgerufen am Seite 3

9 2 Grundlagen von EDA/CEP und mobilen Plattformen Im folgenden Kapitel werden die grundlegenden Techniken, die diese Arbeit betreen, erläutert. Auf der Basis dieser Techniken werden in einem späteren Teil die Anforderungen an die Software abgeleitet. Zunächst wird der Software-Architekturstil Event-Driven Architecture vorgestellt. Hier wird insbesondere das Konzept des Complex Event Processings (CEP) beleuchtet. Diese Themenbereiche beschreiben den prinzipiellen Aufbau und die Arbeitsweise der Umgebung, in die im Rahmen dieser Arbeit mobile Systeme integriert werden sollen. Der letzte Teil dieses Kapitels handelt von besonderen Eigenschaften mobiler Plattformen bzw. mobiler Endgeräte. Zwischen diesen und stationären Rechnern gibt es eklatante Unterschiede, welche bei der Konzeption der Integrationslösung berücksichtigt werden müssen. Auch wird hier auf einige Details der verwendeten mobilen Plattform Android eingegangen. 2.1 Event-Driven Architecture (EDA) und Complex Event Processing (CEP) Dieser Abschnitt gibt eine Einführung in die Softwarearchitektur Event-Driven Architecture und der Softwaretechnologie Complex Event Processing Event-Driven Architecture In der Datenverarbeitung und bei der Umsetzung von Geschäftsprozessen wird immer versucht, möglichst exible und performante Softwarelösungen zu entwickeln. Diese Eigenschaften sind Kernvoraussetzungen für eine, auch in Zukunft gegebene, Wirtschaftlichkeit und Wettbewerbsfähigkeit einer Software. Die Vergangenheit hat gezeigt, dass einmal eingeführte Softwaresysteme unter Umständen Jahrzehnte ihren Dienst versehen müssen. Monolithische Produkte, die schon in der Planung keinen Wert auf Erweiterbarkeit oder auch nur Änderung von Abläufen erlauben, sind dabei Hemmschuhe. Bestrebungen, mit dieser Vorgehensweise der monolithischen Softwareprodukte zu brechen und die Systeme auf eine modulare Basis zu bringen existieren seit vielen Jahren. Die Entkopplung einzelner Softwareelemente wurde so schon mit Einführung von Service Oriented Architectures (SOA) vorangetrieben. Die Abbildung der realen Welt aber ist auch durch diesen Architekturstil nicht so einfach möglich. Die Begründung ist sehr einfach zu nden: Während sich die SOA auf Seite 4

10 Kapitel 2. Grundlagen EDA/CEP & mobile Plattformen 2.1. EDA & CEP die Bereitstellung und Verknüpfung von verschiedenen Diensten spezialisiert, trit sie damit nicht den zentralen Punkt, der das Gesamtgefüge anregt und steuert. Dieser Punkt sind Ereignisse, die in schier unendlichen Ausprägungen und einer sehr groÿen Anzahl immer und überall auf der Welt auftreten und einen sehr groÿen Einuss auf Prozesse und Abläufe haben. Die Prozesse müssen auf unterschiedlichste Ereignisse geeignet reagieren können bzw. müssen sie sich sogar dynamisch anpassen. Dies ist der Punkt, der die ereignisgesteuerte Architektur abgrenzt: Die Ereignisse und deren Verarbeitung stehen im Vordergrund. Die Verwendung von bestimmten Diensten als Reaktion auf bestimmte Ereignisse tritt dabei in den Hintergrund. Somit stellt die EDA nicht den Anspruch, bisheriger Architekturstile obsolet werden zu lassen, doch bietet sie die Möglichkeit, an der richtigen Stelle den Fokus auf die relevanten Informationen zu legen. Die Ereignisse entstammen dabei den unterschiedlichsten Quellen und haben unterschiedlich starke Bedeutung für die Steuerung von Abläufen. Die Reaktion auf die Ereignisse muss dabei optimalerweise in Echtzeit erfolgen, um schnell Rückschlüsse ziehen und entsprechende Prozesse anstoÿen oder ändern zu können. Als Beispiel kann man sich ein System zur Verkehrssteuerung vorstellen. Aus verschiedenen Quellen werden aktuelle Verkehrsinformationen in das System eingespeist, welches basierend auf diesen Informationen die Verkehrssituation darstellen kann. Die gewonnenen Informationen können dann zur Steuerung des Verkehrs eingesetzt werden. Die Umsetzung der Steuerung könnte dabei durch Verkehrsregelung mit dynamischen Schildern oder auch durch Manipulation von Navigationsgeräten in den Autos der Verkehrsteilnehmern statt- nden. Anhand dieses Beispiels kann gut nachvollzogen werden, warum eine Echtzeitverarbeitung so wichtig ist. Um den Verkehr zu beeinussen, wäre eine nachträgliche Auswertung der gesammelten Daten nicht sinnvoll. Dies muss in dem Moment geschehen, in dem die Ereignisse auftreten. Die Event-Driven Architecture setzt genau an diesem Punkt an. Die Ereignisse werden in den Mittelpunkt der Softwarearchitektur gerückt und in Echtzeit vom System verarbeitet. Am Ende der Verarbeitung steht dann eine Aktion, die ausgeführt wird. Welche das sein wird, steht beim Entstehen des Ereignisses noch nicht fest und kann auch von äuÿeren Umständen, wie der Zeit des Auftretens o.ä., abhängig sein. Die hervorstechenden Eigenschaften, die diese Art der Verarbeitung erlauben, lassen sich wie folgt zusammenfassen [10]: Echtzeitverarbeitung Die auftretenden Ereignisse werden zu dem Zeitpunkt verarbeitet, zu dem sie auftreten. Im Gegensatz dazu würde eine Sammlung stehen, in der auftretende Ereignisse gespeichert und dann stoÿweise (z.b. immer nachts) verarbeitet werden. Asynchronität Die Komponenten, welche Ereignisse in das System einspeisen, warten weder in Bezug auf den Empfang der Ereignisse noch im Bezug auf die abschlieÿende Verarbeitung der Ereignisse durch die empfangenden Komponenten. Broadcast Kommunikation Alle Komponenten, die Ereignisse erzeugen oder weiterleiten, versenden die Ereignisse zu Seite 5

11 Kapitel 2. Grundlagen EDA/CEP & mobile Plattformen 2.1. EDA & CEP Abbildung 2.1: EDA: Die verschiedenen Schichten im Überblick jeder an den Ereignissen interessierten Komponente. Ereignisse können so von mehreren Komponenten gleichzeitig empfangen und dann zur Verarbeitung genutzt werden. Ontologie Um Ereignisse unterschiedlichen Typs dierenzieren zu können, deniert die EDA eine Nomenklatur für die Ereignistypen, anhand welcher sie sich unterscheiden lassen. Typischerweise werden die unterschiedlichen Typen von Ereignissen in einer Form Hierarchie dargestellt. Die verschiedenen Komponenten können sich so für einzelne Ereignistypen oder auch Gruppen von Ereignissen interessieren. Die Event-Driven Architecture gliedert sich prinzipiell in vier verschiedenen Ebenen, welche die Ereignisse erzeugen, weiterleiten, verarbeiten und schlieÿlich für eine Reaktion sorgen. [14] Zur groben Einordnung dient dabei Abbildung 2.1. Auf dieser Abbildung sind die Schichten und auf der linken Seite die Bewegungsrichtung eines Ereignisses gezeigt. Auf der untersten Schicht be- nden sich die Ereignis-Quellen, die die erzeugten Ereignisse mit Hilfe vom Ereignis-Träger in die nächste Schicht befördern. In dieser Schicht, der Ereignis-Verarbeitung, ndet die eigentliche Beund Verarbeitung der Ereignisse statt. Schlieÿlich werden in der Verarbeitungs-Schicht erzeugte oder weitergeleitete Ereignisse wieder mit Hilfe vom Ereignis-Träger in die letzte Schicht geleitet. In dieser Aktivitäts-Schicht werden dann unterschiedliche Aktionen ausgeführt wie z.b. das Triggern von externen Services oder ähnliches. Im Folgenden wird zunächst der Begri Ereignis klar deniert, danach wird dann näher auf die einzelnen Schichten der Architektur eingegangen. Ereignisse in der Architektur Wenn von der EDA gesprochen wird, dann ist auch immer die Rede von Ereignissen. Dabei muss zwischen zwei prinzipiell Ereignisarten unterschieden werden. Das eine sind die tatsächlich auftretenden Ereignisse wie z.b. Ein Auto überfährt die Magnetschleife, welche direkt aus der Umgebung stammen. Diese Ereignisse müssen in architekturspezische Ereignisobjekte umgewandelt werden. Ein solches Ereignisobjekt hat einen bestimmten Typ, wie z.b. DriveByEvent und führt einen Zeitstempel mit sich, der den Zeitpunkt kennzeichnet, wann es auftrat. Als zusätzliches Attribut für ein solches Ereignis wird typischerweise auch die Quelle, an der das Ereignis aufgetreten ist, für eine spätere Auswertung vermerkt. Seite 6

12 Kapitel 2. Grundlagen EDA/CEP & mobile Plattformen 2.1. EDA & CEP Um den Unterschied sprachlich hervorzuheben, wird im Folgenden von einem Ereignis gesprochen, wenn es sich um das externe, also aus der Umwelt kommende Ereignis handelt. Soll deutlich gemacht werden, dass es sich um ein Ereignis handelt, welches so in der Architektur zur Verarbeitung genutzt wird, so wird von einem Event gesprochen. Event-Quelle Jedes Event hat eine Quelle, die auftretende Ereignisse wahr nimmt und entsprechende Events erzeugt. Diese Quellen können unterschiedlicher Natur sein. Typische Event-Quellen sind Sensoren, die ihre Umgebung beobachten und Änderungen bemerken. Für das oben verwendete Beispiel der Verkehrssteuerung sei ein Sensor zur Erfassung von Fahrzeugen im Straÿenverkehr eine solche Event-Quelle. Durch eine induktive Schleife, die in der Fahrbahn eingebettet ist, werden Fahrzeuge erkannt wenn sie diese Schleife überfahren. Überfährt ein Fahrzeug nun diese Schleife, so handelt es sich dabei um ein Ereignis, welches mit den Worten Ein Auto hat soeben die Schleife XY passiert umschrieben werden kann. Dieses Ereignis wird von der Quelle in ein Event überführt, welches von den Komponenten der Architektur verarbeitet werden kann. Im Beispiel würde so ein DriveByEvent erzeugt. Dieses Event wird dann mit mehreren Attributen belegt. Sinnvolle Attribute, die dem Event zugeschrieben werden, wären beispielsweise die gemessene Geschwindigkeit des Fahrzeugs und die eindeutige Kennzeichnung der Event-Quelle (z.b. ihre systemweit eindeutige ID). In einer Event-Driven Architecture ist eine Event-Quelle somit die Schnittstelle zwischen externen Systemen im Sinne von Drittsoftware oder auch Hardware, von welcher Ereignisse stammen, und der Event-Verarbeitung innerhalb der EDA. Diese Quellen kennzeichnen sich dadurch, dass sie beliebige Daten in das Ereignis-Format übertragen können, welches für die weitere Behandlung benötigt wird. Dieses Format sind die Events. Ereignis-Träger Alle Events müssen zwischen den unterschiedlichen Ebenen bzw. Einzelkomponenten der Gesamtarchitektur ausgetauscht werden können. Das Medium, über das dieser Austausch statt- ndet, wird Ereignis-Träger genannt. Diesen Träger kann man sich als einen virtuellen Kanal vorstellen, an den Events übergeben werden. Diese Events werden dann wiederum an die an dem Kanal angeschlossenen Komponenten weiter gereicht. Der Ereignis-Träger ist ausschlieÿlich für die Übermittlung von Events zuständig. Es ist dabei irrelevant, um was für Events es sich handelt und wer der Sender oder Empfänger eines Events ist. Der Ereignis-Träger sorgt, je nach Implementierung, auch für die zugesicherte Zustellung und für die korrekte Reihenfolge der Auslieferung von Events. Zugesicherte Zustellung bedeutet, dass bei der Verwendung eines entsprechenden Trägers auch bei Nicht-Erreichbarkeit des Empfängers das Event dann zu einem späteren Zeitpunkt an diesen ausgeliefert wird. Die Zustellung in korrekter Reihenfolge bedeutet, dass der einzelne Kanal nach dem FIFO (First In First Out)-Prinzip funktioniert. Zumindest diese Eigenschaft sollte jeder Träger besitzen. Zudem sollte eine Implementierung der Event-Verarbeitung (siehe folgender Abschnitt), auch bei einer minimal abweichenden Reihen- Seite 7

13 Kapitel 2. Grundlagen EDA/CEP & mobile Plattformen 2.1. EDA & CEP folge der eingehenden Events, korrekte Ergebnisse liefert. Eine solche Implementierung könnte z.b. die Zeitstempel der Ereignisse und nicht die Eingangsreihenfolge betrachten. Damit wäre eine Zustellung in der korrekten Reihenfolge des Empfangs im Ereignis-Träger nicht unbedingt notwendig. Da es sich, wie erwähnt um einen virtuellen Kanal handelt, wird zumeist von einem Event- Channel oder nur Channel gesprochen, wenn die Rede von einem Ereignis-Träger ist. Event-Verarbeitung Die Events werden nur in einer der vier Ebenen verarbeitet. Diese Ebene wird dementsprechend Event-Verarbeitung genannt. In der Event-Verarbeitung werden die Events, basierend auf verschiedenen Kriterien, betrachtet und dann typischerweise durch ein Regelwerk verarbeitet. Das Regelwerk kann dabei aus klassischem Programmcode bestehen, aber auch in Form von Systemen vorliegen, die Regeln aus Klartext-Dateien lesen. Diese Regeln sind in speziellen Sprachen geschrieben und werden typischerweise zur Laufzeit in Programmcode umgewandelt, welcher dann ausgeführt wird. Die Events werden im Regelwerk nach verschiedenen Kriterien betrachtet und dann verarbeitet. Dabei kann es auch passieren, dass ein Event keinem Kriterium gerecht und somit nicht weiter berücksichtigt wird. Die gesamte Verarbeitung der Events ist typischerweise nicht monolithisch in einer Software- Komponenten zusammengefasst. Stattdessen sorgen nach dem Prinzip der starken Kohärenz bei gleichzeitig loser Kopplung verschiedene Verarbeitungskomponenten für die Bearbeitung der auftretenden Events. Diese einzelnen Komponenten werden auch als Agenten bezeichnet, welche sich gegenseitig mit der Hilfe von Channels Events zukommen lassen können. Dabei ist einem Agenten allerdings nicht bekannt, wie er einen bestimmten anderen Agenten adressiert, um ihm ein Event zukommen zu lassen. Jeder Agent gibt seine Ergebnisse stattdessen nur in ihm bekannte Channels. Welche weiteren Komponenten an diese Channels gebunden sind und entsprechend die Events erhalten, ist ihm nicht bekannt. Jeder Agent bearbeitet dabei nur die für seine Aufgabe wichtigen Events. Die Events werden dabei aus dem Strom von Events, der den Agenten erreicht, heraus gesucht. Diese Auswahl ndet dabei anhand eines Pattern Matching statt. Dabei werden Pattern (im einfachsten Fall Es handelt sich um ein Event vom Typ X) festgelegt, die dann auf die eingehenden Events angewendet werden. Wird ein Pattern erkannt, dann wird eine denierte Handlung ausgeführt. Bei dieser Handlung kann es sich um eine Berechnung, um das Erstellen eines neuen Events oder andere Aktionen handeln. Das Ergebnis wird dann in Form eines Events (dabei kann es sich auch um ein Event aus dem Strom handeln) in einen Channel und damit an weitere Agenten oder Consumer gegeben. Wie oben angesprochen kann es dabei auch passieren, dass ein Event, welches einem Agenten zugestellt wird, von diesem einfach nur verworfen wird. Die Aufgaben, welche die Agenten erfüllen sollen, können sowohl aufeinander aufbauender Natur oder auch komplett unabhängig voneinander sein. Das einfachste Beispiel für aufeinander folgende Aufgaben ist das Filtern von Events. In diesem Fall können weitere Aufgaben erst nach abgeschlossener Filterung stattnden. Seite 8

14 Kapitel 2. Grundlagen EDA/CEP & mobile Plattformen 2.1. EDA & CEP Durch die Aufteilung der Aufgaben auf einzelne Software-Komponenten, die Agenten, ist es aus Architektursicht einfach möglich, das Gesamtsystem skalierbar zu gestalten. Dies ist dem Umstand geschuldet, dass die einzelnen Agenten soweit voneinander entkoppelt sind, dass sie auch auf unterschiedlichen Rechnersystemen laufen können. Ebenso ist es möglich, eine Parallelisierung zu realisieren, wenn die Aufgaben der betreenden Agenten voneinander unabhängig sind. Die Art, wie die Agenten die eingehenden Events verarbeiten, kann dabei in verschiedene Arbeitsweisen unterteilt werden, welche jedoch in einer Gesamtarchitektur im Allgemeinen alle Verwendung nden: Simple Event-Verarbeitung Die einfache, oder simple, Event-Verarbeitung betrachtet nur einzelne Events. Sofern die Events einen sofortigen Rückschluss erlauben und somit direkt eine korrespondierende Aktion ausgeführt werden kann, ist diese Arbeitsweise vollkommen ausreichend. Um beim Beispiel der Verkehrssteuerung zu bleiben: Ein solches Event würde beim Registrieren eines Fahrzeugs auf einem gesperrten Streckenabschnitt erzeugt werden. In der Event- Verarbeitung wird anhand dieses einzelnen Events sofort erkannt, dass an dieser Stelle eine Abweichung vorliegt und ein Alarm wird ausgelöst. Da bei dieser Betrachtung die Events nur einzeln ausgewertet werden, ist die Umsetzung einer solchen simplen Event-Verarbeitung im Allgemeinen sowohl schnell als auch einfach. Event-Strom-Verarbeitung Werden Events als Strom betrachtet und nicht jedes für sich, spricht man von der Event- Strom-Verarbeitung. Diese Form der Betrachtung ergibt Sinn, wenn aus einzelnen Events nicht der gewünschte Schluss gezogen werden kann, jedoch aus mehreren Events ein Rückschluss möglich ist. Um ebenfalls bei dem Beispiel zu bleiben, nehmen wir an, dass die Messschleife mehrere Fahrzeuge innerhalb einer bestimmten Zeitspanne registriert. Ob sich an der Stelle momentan ein Verkehrshindernis bendet, ist aus diesen Einzel-Events nicht ersichtlich. Nimmt die Geschwindigkeit der registrierten Fahrzeuge jedoch abrupt ab, kann davon ausgegangen werden, dass ein Verkehrshindernis aufgetaucht ist. Mindestens kann jedoch eine Aussage darüber getroen werden, dass sich die Geschwindigkeit der erfassten Fahrzeuge reduziert. Für diese Betrachtung ist in diesem Fall auch der zeitliche Zusammenhang zwischen den Events relevant. So ist sinkt die Geschwindigkeit z.b. nicht, wenn das erste Event eine niedrigere Geschwindigkeit als das folgende aufweist. Komplexe Event(strom)-Verarbeitung Die komplexe Event-Verarbeitung (oder auch Complex Event Processing) betrachtet eingehende Events eingehender als die bisher vorgestellten Methoden. Im Fokus der komplexen Event-Verwaltung steht dabei die Auswertung von Informationen, die durch das Auftreten von verschiedenen Events zu unterschiedlichen Zeiten gewonnen werden können. Die genaue Arbeitsweise wird im Unterabschnitt beschrieben. Seite 9

15 Kapitel 2. Grundlagen EDA/CEP & mobile Plattformen 2.1. EDA & CEP Abbildung 2.2: Beispiel eines Event Processing Networks Ereignis-Aktivität Die letzte logische Schicht in der Event-Driven Architecture ist die Ereignis-Aktivitäts-Schicht. In dieser werden konkrete Aktionen ausgeführt. Diese Aktionen können die unterschiedlichsten Formen annehmen, so kann zum Beispiel eine versendet oder ein bestimmter Webservice aufgerufen werden. Welche Aktivität genau angesprochen wird, entscheidet sich in der Event- Verarbeitung. Die Ereignis-Aktivität entspricht der Konsequenz, welche dem Auftreten des ursprünglichen Ereignisses schlieÿlich folgt. Da die Ereignis-Aktivität keine Events oder sonstige Daten an die anderen Komponenten der Architektur zurück gibt, handelt es sich um einen reinen Konsumenten von Events. Folglich wird eine Ereignis-Aktivität auch als Event-Consumer bzw. Consumer bezeichnet. Das Event Processing Network Werden die einzelnen Komponenten aus den oben erläuterten Schichten zusammengefasst und miteinander verknüpft, so spricht man von einem Event Processing Network. Die Verknüpfung wird dabei mit Hilfe der Channels realisiert. Ein Beispiel für den Aufbau eines Event Processing Networks ist auf Abbildung 2.2 zu sehen Complex Event Processing Die komplexe Event-Verarbeitung, oder auch Complex Event Processing (CEP) dient der Verarbeitung von Events. Im Gegensatz zu den in Abschnitt genannten, einfachen Verarbeitungsmechanismen ist das Complex Event Processing jedoch wesentlich mächtiger. Die Verwendung von CEP zur Verarbeitung von Events ermöglicht es dem System, nicht nur auf einzelne Events zu reagieren, sondern Eventmuster zu erkennen und auf sie zu reagieren. Diese Eventmuster wer- Seite 10

16 Kapitel 2. Grundlagen EDA/CEP & mobile Plattformen 2.1. EDA & CEP den in einem Strom von Events erkannt. Die Erkennung ndet dabei in den bereits im vorherigen Abschnitt vorgestellten Agenten statt. Um ein solches Muster zu erkennen, werden die einzelnen Events auf zeitliche, räumliche oder auch kontextabhängige Zusammenhänge hin überprüft [13]. Für die Überprüfung wird dabei typischerweise auf eine Rule Engine zurückgegrien. Eine solche Rule Engine arbeitet dabei auf einer Faktenbasis, gegen die die Regeln der Rule Engine angewandt werden. Die Faktenbasis besteht im Falle des Complex Event Processing aus den Events, die den Agenten erreichen. Die Events verbleiben dabei so lange in der Faktenbasis, bis sie aus einer Regel heraus explizit wieder entfernt werden oder, je nach Rule Engine, die Events abgelaufen sind. Diese Ablaufzeit wird erreicht, wenn ein Event nicht mehr in bestimmte Fenster passen. Diese Fenster können auf der Basis von Zeit oder eingehenden Events von den Regeln deniert werden. So können z.b. die letzten zehn Events betrachtet werden, oder auch die letzten Events eines nahezu beliebig wählbaren Zeitraums. Ob solche Fenster deniert werden können oder man diese manuell mit einfachen Regeln nachbauen muss, um die Faktenbasis entsprechend wieder zu verkleinern, hängt dabei von der genutzten Implementierung der Rule Engine ab. Eine Regel besteht aus einer linken und rechten Seite, wobei die linke das Auswahlkriterium darstellt, die rechte die auszuführende Aktion. Man kann sich eine Regel also als WENN linke Seite DANN rechte Seite vorstellen. Im Rahmen der Verarbeitung mit CEP werden aus einfachen Events mit wenig Aussagekraft durch Aggregation neue Events mit einer höheren Aussagekraft erzeugt. Die Aussagekraft eines einzelnen Events hängt dabei mit dessen Granularität zusammen. Je feingranularer ein Typ von Event ist, desto weniger Aussagekraft besitzt das Event. Ein Beispiel: Jeder Request an einen Webserver wird als Event im System registriert. Folgen viele Requests von unterschiedlichen IP Adressen schnell aufeinander und weisen diese Requests ein ähnliches Schema auf (z.b. wird dieselbe URL angefordert), so handelt es sich bei den einzelnen Events immer noch nur um die Darstellung eines Requests. Die Tatsache, dass sich die die Requests ähneln, schnell hintereinander eingehen und von unterschiedlichen IP Adressen stammen, lässt jedoch den weitergehenden Schluss zu, dass der Webserver Opfer einer Distributed Denial of Service Attacke ist. Dieser Schluss lässt sich wiederum als Ereignis auassen, welches als Event in den Strom von Events gegeben werden kann. Am Beispiel kann man sehen, dass aus feingranularen Events neue, gröber gefasste Events abgeleitet werden können. Eine weitere Verarbeitungsart im CEP ist die Reduktion der Events im Eventstrom. Reduktion bedeutet, dass bestimmte Events konsumiert werden und nicht mehr länger zur Verarbeitung zur Verfügung stehen. Typischerweise wird eine solche Reduktion durch Filterung realisiert. Dazu erneut ein Beispiel: Ein Lesegerät für RFID-Etiketten erzeugt bei jeder erfolgreichen Lesung ein Ereignis. Da das Lesegerät die Lesungen in schneller, zeitlicher Abfolge wiederholt, werden für dasselbe Etikett mehrfache Leseereignisse erzeugt. Diese tragen zum Fakt, dass das spezielle Etikett sich gerade in Reichweite des Lesegerätes bendet, nichts bedeutendes bei. Der Eventstrom kann mit Hilfe eines Agenten reduziert werden. Dieser Agent ltert doppelte Leseereignisse desselben Etiketts in einer vorgegebenen Zeitspanne aus dem Strom heraus. So könnte die Frequenz des Auftretens eines bestimmten Events im Strom z.b. von mehreren Events pro Sekunde auf ein Event pro 10 Sekunden verringert werden. Seite 11

17 Kapitel 2. Grundlagen EDA/CEP & mobile Plattformen 2.2. Eigenschaften mobiler Plattformen Die dritte Verfahrensweise des CEP, welche an dieser Stelle beschrieben werden soll, betrit das Anreichern eines Events mit weiteren Daten. Diese Anreicherung dient dazu, einem Event mehr Informationen anzuhängen und es somit für eine weitere Verarbeitung vorzubereiten. Um beim Beispiel der RFID-Etikette zu bleiben: Das vom Lesegerät erzeugte Event besitzt nur die ID des Lesegerätes, die ID der Etikette und den Zeitstempel, wann die Lesung durchgeführt wurde. Ein Agent, der das Event anreichern soll, könnte z.b. anhand der Etiketten-ID Informationen zu dem etikettierten Artikel aus einer Datenbank abfragen. Diese Informationen würde er dem Event als weitere Daten anhängen. Die Daten stehen dann späteren Agenten bei der Verarbeitung zur Verfügung, ohne, dass diese selbst sie von der Datenbank abfragen müssen. Die drei genannten Verfahren zum Erzeugen, Eliminieren und Anreichern von Events sind nur die wichtigsten, es gibt weitere, die an dieser Stelle nicht näher betrachtet werden. Mehr zu dem Thema lässt sich in der einschlägigen Literatur wie z.b. [13] oder [4] nachlesen. 2.2 Eigenschaften mobiler Plattformen Bei mobilen Endgeräten muss schon während der Entwicklungsphase auf bestimmte Gegebenheiten Rücksicht genommen werden, die bei normalen Desktoprechnern oder Servern nicht oder nur wenig Beachtung bedürfen. Alle mobilen Endgeräte verfügen über Eigenschaften, die sich aus der mobilen Einsetzbarkeit und physikalischen Grenzen zusammensetzen. Diese speziellen Eigenschaften gelten typischerweise für alle mobilen Endgeräte. In diesem Abschnitt werden diese Eigenschaften aufgelistet und näher erläutert. Auf dieser Basis werden dann konzeptuelle Entscheidungen für die Umsetzung der Software getroen Die Datenverbindung Datenverbindungen bei mobilen Endgeräten können grundsätzlich durch zwei verschiedene Techniken aufgebaut werden. Die ursprüngliche Variante nutzt dabei die Verbindung des Gerätes mit dem Mobilfunknetz, aktuelle Geräte sind aber auch in der Lage, umgebende Wireless LANs zu nutzen. Bei modernen Endgeräten wird dabei ein für den Benutzer des Gerätes transparenter Wechsel zwischen den verschiedenen Verbindungsarten vorgenommen. So wird unter anderem bei einer etablierten Verbindung zu einem WLAN automatisch diese gegenüber einer Datenverbindung über das Mobilfunknetz bevorzugt. Die Transparenz für den Benutzer gilt dabei allerdings nicht in allen Maÿen für die auf dem Endgerät laufende Software, da sich bei einem Wechsel zwischen den verschiedenen Verbindungsarten zum Beispiel auch die Netzwerkadresse des Gerätes ändert. Ebenso wird eine, unter Umständen bereits bestehende, Verbindung zur Gegenseite kurzzeitig unterbrochen und muss zur weiteren Nutzung erneut aufgebaut werden. Dies ist gerade bei verbindungsorientierten Diensten unumgänglich und führt damit zu erhöhtem Planungsaufwand für das Gesamtkonzept der Software. Seite 12

18 Kapitel 2. Grundlagen EDA/CEP & mobile Plattformen 2.2. Eigenschaften mobiler Plattformen Mobilfunknetz Schon seit Jahren ermöglichen es die Mobilfunkbetreiber, auf unterschiedliche Art die Funkzellen auch für paketbasierte Datenübertragung zu nutzen. Inzwischen gibt es mehrere Verbindungsarten, mit denen das mobile Endgerät Datenpakete mit dem Mobilfunknetz und somit der kabelgebundenen Infrastruktur des Providers austauschen kann. Diese eingesetzten Techniken unterscheiden sich hauptsächlich in der Verbindungsgeschwindigkeit. Einen Teil der zur Verfügung stehenden Verbindungsarten liefert Tabelle 2.1. Sie beinhaltet die meist verwendeten, bei weitem aber nicht alle möglichen Datenübermittlungsarten. Welche der Optionen dem mobilen Endgerät zur Verfügung stehen, ist von verschiedenen Faktoren abhängig. Natürlich muss die entsprechende Verbindungsart vor allem von dem Gerät hard- und softwareseitig unterstützt werden. Ebenso muss der Mobilfunkbetreiber die Verbindungsart dem Anwender anbieten bzw. erlauben. Eine solche Erlaubnis kann zum Beispiel bei exzessiver Nutzung der Verbindung auch temporär entzogen werden, sodass im Folgenden nur noch schlechtere Verbindungsarten zur Verfügung stehen. Schlieÿlich ist die momentane Netzqualität und -stärke ein Einussfaktor für die zur Verfügung stehenden Verbindungsarten. So gibt es zum Beispiel gerade im ländlichen Raum Gebiete, in denen keine UMTS-Funkzellen zur Verfügung stehen und somit nur langsame GPRS-Verbindungen anstatt des deutlich schnelleren HSPA genutzt werden können. Ein weiterer Punkt, der bei der Nutzung dieser Datenverbindungen zu berücksichtigen ist, ist der Kostenfaktor. Dieser kann stark variieren und ist erst seit der Einführung so genannter Datenatrates für den Privatverbraucher zu vernachlässigen. Angemerkt sei dabei allerdings, dass diese Datenatrates zumeist nur ein bestimmtes Volumen an Datenverkehr erlauben und die Provider nach der Ausschöpfung dieses Volumens die Übertragungsgeschwindigkeit deutlich verringern. Insofern ist die Bezeichnung einer Flatrate zum Teil irreführend, da nach der Drosselung nur noch marginale Datenmengen übertragen werden können. Insbesondere für den Aufenthalt im Ausland gilt bei den Tarifen zusätzlich, dass die Datenverbindungen einen sehr hohen Preis haben und somit nur von wenigen Personen genutzt werden (können). Des Weiteren ist zu beachten, dass bei der Verwendung der Mobilfunkverbindung zur Datenübertragung dem Endgerät eine IP-Adresse aus dem öentlichen Raum zugewiesen, oder das Endgerät hinter einer Maskierung, wie beispielsweise NAT, verborgen wird. Damit kann es unter anderem durch Portbeschränkungen oder ähnliche Maÿnahmen der Provider problematisch sein, das Endgerät in eine bestehende nicht öentliche Infrastruktur einzubinden. Auf jeden Fall wird ohne einen weiteren, externen Service das Ansprechen des Endgerätes unmöglich gemacht, da einem Dritten die dynamisch zugeteilte IP-Adresse nicht bekannt ist. Verbindung über WLAN Neben der Möglichkeit die mobilfunkbasierte Datenverbindung zu nutzen, verfügen moderne Endgeräte ebenfalls über die Fähigkeit eine Verbindung zu Wireless LAN Netzwerken aufzubauen. Wesentlich geringer ist die Verbreitung einer Verbindung via USB oder anderen Schnittstellen, die das Endgerät bietet. Daher wird im Folgenden von einer Verbindung über WLAN ausgegangen, da dieses die zu erwartende Verbindung darstellt. Seite 13

19 Kapitel 2. Grundlagen EDA/CEP & mobile Plattformen 2.2. Eigenschaften mobiler Plattformen Bezeichnung GPRS General Packet Radio Service EDGE Enhanced Data Rates for GSM Evolution HSDPA / HSUPA High Speed (Downlink/Uplink) Packet Access Übliche max. Übertragungrate 114 kbit/s 400 kbit/s 7,2 Mbit/s down, 5,7 Mbit/s up Tabelle 2.1: Mobilfunk-Datenverbindungsarten Diese Verbindung bringt gegenüber der Datenverbindung über das Mobilfunknetz einige Vorteile. Die Übertragungsgeschwindigkeit ist im Normalfall wesentlich höher als die maximal erreichbare über HSDPA (siehe 2.1), da zumeist ein breitbandiger Internetanschluss zur Verfügung steht. Teilweise ist das Nadelöhr in einer solchen Konstellation sogar die WLAN-Verbindung und nicht der eigentliche Internetanschluss. Zusammenfassung und Schlussfolgerung - Datenverbindung Wie beschrieben sind Datenverbindungen von mobilen Endgeräten weder in der Übertragungsgeschwindigkeit noch in der bloÿen Existenz verlässlich. Bei einem mobilen Endgerät kann somit nicht davon ausgegangen werden, dass es durchgehend eine Datenverbindung hat und wenn, dass diese Verbindung immer eine ausreichend hohe Übertragungsgeschwindigkeit zur Verfügung stellen kann. Dieser Umstand muss in der Konzeption von Softwareprojekten, die mobile Endgeräte einbeziehen, immer berücksichtigt werden (sofern die Software nicht alleinig auf dem Endgerät laufen wird und keine Kommunikation mit der Auÿenwelt benötigt). Insbesondere für den Einsatz als Signalgeber oder als mobile Sensorstation jedoch gilt, dass eine Datenverbindung benötigt wird, um die anfallenden Daten an den verarbeitenden Dienst zu übermitteln. Ebenso ist in umgekehrter Richtung davon auszugehen, dass das mobile Endgerät unter Umständen zu dem Zeitpunkt, wenn die Daten gesendet werden über keine Datenverbindung verfügt. In diesem Fall muss berücksichtigt werden, ob die Daten zu einem späteren Zeitpunkt nachträglich übermittelt werden oder ob diese einfach verfallen sollen. Diese Punkte haben einen groÿen Einuss auf die Konzeption von Software, die das mobile Endgerät als Teil des Gesamtkonzepts einbindet Minimale Ressourcen Mobile Endgeräte verfügen, verglichen mit stationären Rechnern, über sehr eingeschränkte Ressourcen. Diese Einschränkungen rühren von der mobilen Eigenschaft eines solchen Gerätes. Die Mobilität wird durch möglichst kleine Abmessungen und geringes Gewicht erreicht. Dazu ist es vor allem notwendig, auf Komponenten mit hohem Energiebedarf zu Gunsten von leistungsärmeren, sparsameren Komponenten, zu verzichten. Die begrenzende Gröÿe ist bei mobilen Geräten meist durch den Energievorrat, also üblicherweise die Kapazität des Akkus, gegeben. Die auf Strom angewiesenen Komponenten der Geräte werden mit einer höheren Geschwindigkeit zu Seite 14

20 Kapitel 2. Grundlagen EDA/CEP & mobile Plattformen 2.2. Eigenschaften mobiler Plattformen immer neuen Entwicklungsstufen getrieben als die Strom zur Verfügung stellenden Komponenten, insbesondere der Akkus. Das Problem liegt hierbei daran, dass die immer leistungsfähigeren Komponenten ihre höhere Leistungsfähigkeit zum groÿen Teil mit einen erhöhten Energiebedarf erkaufen. Die CPU Moderne mobile Geräte verfügen über eine RISC CPU (Reduced Instruction Set Computer). Da diese durch ihren relativ geringen Energiebedarf gleich zwei Vorteile bieten, wird diese Art Prozessoren groÿteils im eingebetteten Bereich, also auch in mobilen Geräten eingesetzt: Einerseits wird die Energieversorgung eines mobilen Endgeräts nicht übermäÿig belastet, was zu einer höheren Laufzeit führt, andererseits wird durch ebenso weniger Abwärme produziert. Eine übermäÿige Abwärme wäre gerade unter dem Gesichtspunkt der möglichst kleinen Abmessungen eines solchen Geräts nur schwierig abzuführen. Allerdings gilt auch bei der energieezientesten Art von Prozessoren die Faustregel: Benutzung der CPU sowie erhöhte Leistungsfähigkeit derselben bedeuten immer einen höheren Energiebedarf gegenüber Nicht-Benutzung oder einer schwächeren CPU. Dies bedeutet, dass bei Nutzung der CPU mehr Strom verbraucht wird, als wenn keine Berechnungen durchgeführt werden. Ebenso sagt es aus, dass leistungsfähigere CPUs typischerweise auch eine höhere Stromaufnahme haben. Inzwischen werden auch in mobilen Geräten Mehrkernprozessoren verbaut, welche mehr Leistung als Einzelkernprozessoren bieten, jedoch erneut eine erhöhte Stromaufnahme bedeuten. Hauptspeicher Auch im Bereich des Hauptspeichers schreitet die Entwicklung schnell voran. So verfügen aktuelle Smartphones über 512 MiB oder gar 1 GiB RAM. Im Vergleich zu stationären Rechnern ist diese Menge an Hauptspeicher dennoch gering. Dies wird teilweise durch die Hauptspeicherverwaltung der entsprechenden Betriebssysteme kompensiert. Für die Software bedeutet diese Verwaltung jedoch, dass die Lebenszyklen einzelner Komponenten der Software unter Umständen sehr kurz sein können. Werden Ressourcen, insbesondere Speicher, benötigt, so gehen Betriebssysteme mobiler Endgeräte um diese Ressourcen liefern zu können zumeist rigoros vor. Da die Möglichkeit des Swapping auf mobilen Geräten nicht ezient eingesetzt werden kann, denn Zugrie auf die sonstigen Speichermedien sind langsam und energieinezient, kommt diese Möglichkeit nicht in Frage. Daher werden zum Beispiel bei Android Anwendungen komplett beendet, wenn diese bestimmte Bedingungen erfüllen und eine andere Anwendung Speicher benötigt. Der Status der Anwendung wird dabei zwar gespeichert, jedoch wird sie in diesem Augenblick nicht mehr ausgeführt. Andere Betriebssysteme für mobile Geräte verwalten ihren Speicher mit ähnlichen Methoden oder bieten noch nicht einmal die Möglichkeit, mehrere Anwendungen gleichzeitig auszuführen. Damit wird dieses Problem ebenfalls gelöst, da immer nur eine (Benutzer)-Anwendung Speicher benötigt. Eben dieser unvorhersehbare Lebenszyklus einer Anwendung auf mobilen Geräten ist bei der Seite 15

21 Kapitel 2. Grundlagen EDA/CEP & mobile Plattformen 2.2. Eigenschaften mobiler Plattformen Konzeption der Softwarelösung ebenfalls zu bedenken. Sicherlich gilt der Grundsatz, dass eine Anwendung so wenig RAM wie möglich benötigen soll auch hier, jedoch ist es gerade auf mobilen Plattformen um so wichtiger, ihn zu auch zu befolgen. Energiespeicher Jedes mobile Endgerät verfügt in jedem Fall über eine Gemeinsamkeit: eine autonome Stromversorgung. Typischerweise wird diese mit Hilfe eines in das Gerät integrierten Akkus erreicht. Da der Trend immer weiter in die Richtung kleinerer und leichterer Geräte geht, ist die Kapazität der verbauten Akkus begrenzt. In heutigen Smartphones nden sich Akkus mit Kapazitäten um die 1200 mah 1 bis 1600 mah 2. Als Vergleich: 2002 gab es bereits Geräte mit über 1000 mah zu kaufen 3, deren Rechen- und Speicherkapazitäten jedoch deutlich unter derer heutiger Smartphones liegen. Dieser Akku war allerdings wesentlich gröÿer als heutige Akkus mit gleicher Kapazität. Die Entwicklung der Energiespeicher schreitet zwar voran, kann jedoch mit der Entwicklung der anderen Komponenten von mobilen Geräten derzeit nicht Schritt halten. Damit wird die zur Verfügung stehende Energie auf einem mobilen Endgerät zu einer wichtigen und knappen Ressouce, welche sich ausschlieÿlich dadurch schonen lässt, dass besonders energiehungrige Aktionen nach Möglichkeit vermieden werden. Besonders energiehungrig sind vor allem Datenverbindungen und natürlich abgeforderte Rechenleistung [5]. Dies ist jedoch nicht so einfach zu pauschalisieren. Der Unterschied des Energiebedarfs zwischen einer Datenverbindung mit WLAN und einer Verbindung über das Mobilfunknetz (vgl. auch 2.2.1) ist zwar gegeben, aber stets abhängig von den zu übermittelnden Daten. So ist das Senden von mehreren kleinen Datenhäppchen besonders bei einer Verbindung über das Mobilfunknetz sehr teuer [3]. Zusammenfassung und Schlussfolgerung - Hardwareressourcen auf mobilen Geräten Im direkten Vergleich zwischen aktuellen stationären und mobilen Geräten stehen letzteren weniger Ressourcen zur Verfügung. Da die Entwicklung aber auch im mobilen Bereich immer weiter fortschreitet, stehen absolut ausgedrückt jedoch für viele Anwendungsfälle ausreichende Ressourcen zur Verfügung. Dies liegt auch am Umgang der Betriebssysteme mit den zur Verfügung stehenden Ressourcen. Der begrenzende Faktor ist bei den mobilen Geräten inzwischen weniger die reine, zur Verfügung stehende Rechenkapazität oder Hauptspeicher, sondern eher die Energiereserven. Diese werden bei jeder Berechnung und vor allem auch bei der Benutzung von Datenverbindungen in Anspruch genommen. Es ist daher nicht nur wichtig, die Software auf die faktisch zur Verfügung stehenden Ressourcen zu optimieren, sondern vor allem eine Balance zu nden, um so energieezient wie möglich zu arbeiten abgerufen am abgerufen am abgerufen am Seite 16

22 Kapitel 2. Grundlagen EDA/CEP 2.3. Interne & mobile Kommunikationsmechanismen Plattformen und Multitasking auf mobilen Plattformen 2.3 Interne Kommunikationsmechanismen und Multitasking auf mobilen Plattformen In diesem Abschnitt werden der Aufbau und die groben Funktionsweisen von zwei ausgesuchten, mobilen Plattformen beschrieben, mit denen innerhalb der jeweiligen Plattform kommuniziert wird. Diese Kommunikation kann als Möglichkeit gesehen werden wie Ereignisse erzeugt werden können, die von der CEP-Umgebung, welche auf der Plattform läuft, registriert werden können. Die Kommunikationsmöglichkeiten unterscheiden sich dabei teilweise stark, welches mit der internen Strukturierung und grundlegenden Auslegung der Systeme zusammen hängt. Begonnen wird jedoch jeweils mit der Umsetzung von Multitasking auf den mobilen Plattformen Google Android Google Android wurde von Beginn an darauf ausgelegt, einzelne Teile des Systems als Komponenten austauschbar zu realisieren [9]. So ist es z.b. möglich, selbst System-Applikationen wie die Anwendung zur Verwaltung von SMS oder Anrufen durch eine eigene zu ersetzen. Um diese Flexibilität zu erreichen, wurde von Beginn an auf ein ausgeklügeltes System zur Interprozesskommunikation gesetzt. Dieses System basiert auf sogenannten Intent. Ein Intent stell eine Nachricht dar, welche mit unterschiedlichen Daten angereichert werden kann. Diese Nachrichten werden sowohl vom Betriebssystem genutzt, um Statusänderungen wie z.b. einen eingehenden Anruf zu propagieren und können ebenfalls von Dritt-Anbieter-Anwendungen benutzt werden. Die Nachrichten werden vom Betriebssystem an alle Anwendungen zugestellt, welche sich für diese registriert haben. Bei der Registrierung kann genau angegeben werden, welche Art von Nachrichten für die registrierende Anwendung interessant sind. Multitasking Google Android unsterstützt echtes Multitasking, also mehrere, parallel laufende Prozesse sowie Anwendungen (auch von Drittanbietern). Das Speichermanagement von Google Android sorgt dafür, dass eine Anwendung so lange läuft, bis das Betriebssystem für eine neu gestartete Anwendung nicht mehr ausreichende Ressourcen zur Verfügung hat. An diesem Punkt wird dann eine der noch im Hintergrund laufenden Anwendungen beendet. Dabei wird der zu beendenden Anwendung die Möglichkeit gegeben, ihren aktuellen Zustand zu sichern. Wird die beendete Applikation vom Benutzer durch Start derselben wieder angefordert, wird der vormals gesicherte Zustand der Applikation wieder zur Verfügung gestellt. So kann die Applikation die notwendigen Daten und den Ausgangszustand wiederherstellen. Ob eine Applikation vom System als Kandidat zur Beendigung vorgesehen wird, hängt von der momentanen Priorität der Applikation ab. Eine Applikation, die sich gerade im Vordergrund bendet, besitzt z.b. eine höhere Priorität, als eine Applikation, die als Service nur im Hintergrund läuft. Wie genau die Priorisierung vom System vorgenommen wird, ist dabei teilweise sehr Seite 17

23 Kapitel 2. Grundlagen EDA/CEP & mobile Plattformen 2.3. Interne Kommunikation & Multitasking komplex und kann in der Dokumentation von Google Android nachgelesen werden[9] 4. Bedeutung für eine Applikation Eine Applikation kann so implementiert und auf dem Gerät gestartet werden, dass sie im Hintergrund durchgehend läuft. Eine solche Anwendung wird dann Service genannt. Eine auf diese Art implementierte Anwendung kann so permanent eine Verbindung zu einem externen Server halten, um das mobile Gerät für diesen durchgehend erreichbar zu machen. Auch, wenn es sich um eine klassische Anwendung mit Benutzeroberäche handelt, kann diese durchgehend weiter laufen, selbst dann, wenn eine andere Anwendung kurzzeitig in den Vordergrund geholt wird. Ob und wann aber die Anwendung zur Freisetzung von Ressourcen beendet wird, ist nicht festgelegt. Es kann zwar Einuss darauf ausgeübt werden, welche Priorität einer Applikation vom System zugemessen wird (indem man z.b. einen sogenannten Foreground Service 5 implementiert), aber dennoch kann die Applikation jederzeit vom System beendet und wieder gestartet werden. Dementsprechend muss eine Anwendung darauf ausgelegt werden, dass sie die benötigten Daten bei Beendigung als Zustand speichert, welcher dann im Nachhinein wieder hergestellt werden kann. Interprozesskommunikation Die Interprozesskommunikation basiert auf den oben beschriebenen Intents. Unter Android läuft jede Anwendung in einem separaten Prozess. Von daher kann in diesem Fall auch von einer Kommunikation zwischen Anwendungen gesprochen werden, denn innerhalb einer Anwendung ist es unüblich, mehrere Prozesse zu haben, zwischen denen kommuniziert werden muss. Sie können aus einer Applikation genutzt werden, um andere Applikationen zu starten oder auch um Daten an eine bereits gestartete Applikation zu übermitteln. Auch ist es möglich, dass eine Anwendung sich mit Hilfe eines Intents an einen Service (ein im Hintergrund laufender Prozess) einer anderen Anwendung bindet und diesen benutzt. Auf diese Art und Weise wird es ermöglicht, Remote Procedure Calls auszuführen. Da die Intents sowohl als Broadcast, aber auch adressiert nur an bestimmte Anwendungen verschickt werden können, ist das System sehr exibel und kann auch zur Intra- Prozesskommunikation eingesetzt werden. Die Adressierung besteht dabei aus der Angabe des Paket- und Komponentennamens der Anwendung, an die der Intent zugestellt werden soll. Wird der Intent als Broadcast versendet, so wird er jeder Anwendung zugestellt, die sich für die Art Intents im Vorfeld registriert hat. 4 Im Blog auf der Entwicklerseite bendet sich ein interessanter Artikel über Multitasking in Android sowie die Prioritäten der Prozesse und Applikationen: multitasking-android-way.html 5 - abgerufen am Seite 18

24 Kapitel 2. Grundlagen EDA/CEP & mobile Plattformen 2.3. Interne Kommunikation & Multitasking System-Ereignisse Systemereignisse, wie z.b. das Ein- oder Ausschalten des Bildschirms, werden vom Betriebssystem selbst als Broadcast-Intent versendet. Es stehen eine Vielzahl von unterschiedlichen Systemereignissen zur Verfügung, für die sich eine Applikation registrieren kann. Einige der Ereignisse bedürfen einer bestimmten Berechtigung oder Permission, die die Applikation bei der Installation vom Benutzer anfordern muss, damit die Ereignisse zugestellt werden. Eine dieser Permissions ist z.b. android.permission.read_phone_state, welche es der Applikation erlaubt, über eingehende oder beendete Telefonanrufe benachrichtigt zu werden. Ein Beispiel zum Registrieren für einen Intent wird in Listing 2.1 gezeigt. Es handelt sich um den Intent, der vom Betriebssystem generiert wird, wenn ein Anruf eingeht oder das Gespräch angenommen bzw. beendet wird. Um diesen Intent nutzen zu können bedarf es der oben genannten Permission. Die Registrierung ndet hier zur Laufzeit der Anwendung statt. Es ist allerdings ebenfalls möglich, dass eine Applikation sich schon beim Installationszeitpunkt für bestimmte Intents registriert. Die Anwendung wird in dem Fall gestartet, wenn der Intent vom System generiert wird. Dieses Vorgehen ist allerdings nicht bei allen Intents möglich, da es sich bei einigen um so häug vorkommende handelt, dass sich eine Applikation nur zur eigenen Laufzeit für sie registrieren kann. 1 public class MyClass extends Activity 2 { 3 public void oncreate () 4 { 5 BroadcastReceiver receiver = new BroadcastReceiver () 6 { 8 public void onreceive ( Context context, Intent intent ) 9 { 10 dostuff ( intent ); 11 } 12 }; 13 this. registerreceiver ( receiver, " android. intent. action. PHONE_ STATE " 14 } 15 } ); Listing 2.1: Runtime-Registrierung für den Intent beim Wechsel des Telefonstatus (eingehender Anruf, beendeter Anruf,...) Seite 19

25 Kapitel 2. Grundlagen EDA/CEP & mobile Plattformen 2.3. Interne Kommunikation & Multitasking Apple ios Apple ios ist das zweite Betriebssystem für mobile Endgeräte, welches an dieser Stelle näher vorgestellt wird. Da es von Grund auf anders aufgebaut ist, als Google Android, bietet es sich als Vergleich an, um so zum späteren Zeitpunkt die gegensätzliche Grundvoraussetzungen berücksichtigen zu können. Multitasking Apple ios ist darauf ausgelegt, dass immer nur die Anwendung läuft, welche gerade im Vordergrund angezeigt wird, also mit welcher der Benutzer gerade arbeitet. Das System unterstützt kein Multitasking im Sinn von echt parallel laufenden Prozessen oder Anwendungen für Applikationen von Drittanbietern. Dabei bestehen drei Ausnahmen, die es erlauben, dass die Anwendung eines Drittanbieters im Hintergrund weiter läuft, während eine andere Anwendung den Fokus hat. Diese Ausnahmen betreen Anwendungen zur Audiowiedergabe, zur Navigation mit Hilfe von GPS und Anwendungen zum Führen von Voice-Over-IP-Gesprächen. Weitere Anwendungen, die permanent im Hintergrund laufen, sind ausschlieÿlich Systemanwendungen, die von Apple geliefert werden. Hintergrund dieser Vorgehensweise ist, dass so sichergestellt werden kann, dass Hintergrundprozesse von Drittanbietern nicht die knappen Ressourcen, insbesondere den Akku, belasten. Für den Nutzer wird jedoch der Eindruck geschaen, dass mehrere Anwendungen parallel auf dem Gerät ausgeführt werden. Dies wird durch eine spezielle Technik umgesetzt: Wird eine Anwendung gestartet, so wird der Zustand der laufenden Anwendung gespeichert. Wechselt der Nutzer nun zur vorigen Anwendung, so wird der Zustand wieder hergestellt und es macht den Eindruck, als wäre die Anwendung durchgehend geönet gewesen und ausgeführt worden. Bedeutung für eine Applikation Eine Applikation muss, wenn sie dauerhaft laufen soll, darauf ausgelegt werden, ständig im Fokus des Benutzers zu sein. Das bedeutet, dass die Oberäche der Applikation dem Nutzer durchgehend angezeigt wird. Ansonsten ist ihr Lebenszyklus exakt so lang, wie sie sich im Vordergrund bendet. Dabei wird jedoch ihr Zustand bei der Pausierung bzw. Beendigung gespeichert um für den Benutzer das Bild von Multitasking zu erzeugen. Aufgrund der Einschränkungen für den Betrieb von mehreren Anwendungen zum gleichen Zeitpunkt unterscheiden sich die Kommunikationsmöglichkeiten ebenfalls von denen, welche z.b. auf Android zur Verfügung stehen. Interprozesskommunikation Die Kommunikation zwischen mehreren Anwendungen ist aufgrund der Architektur des Betriebssystems darauf ausgelegt, dass die angesprochene Anwendung zum Zeitpunkt der Kommunikation nicht läuft. Deshalb kann im engeren Sinne nicht von einer Interprozesskommunikation gesprochen werden. Seite 20

26 Kapitel 2. Grundlagen EDA/CEP & mobile Plattformen 2.3. Interne Kommunikation & Multitasking Stattdessen können sich Anwendungen aber für ein spezisches URL-Schemata registrieren. Wird eine URL mit dem entsprechenden Schema aus einer anderen Anwendung heraus aufgerufen, so önet sich die Applikation, welche für das Schema registriert ist. Dabei ist allerdings nicht festgelegt, welche Applikation gestartet wird, wenn für dasselbe Schema mehrere Applikationen registriert sind. Zu übermittelnde Daten werden, in der entsprechenden URL kodiert, an die aufgerufene Anwendung übertragen.[1] System-Ereignisse Änderungen am Zustand der Plattform können in Apple ios auf unterschiedliche Arten registriert werden. Die erste Methode konzentriert sich dabei auf sogenannte Delegates, welche für unterschiedliche Komponenten einer Applikation zur Verfügung stehen. Die Delegates implementieren verschiedene Methoden, die dann bei Zustandsänderungen (z.b. Änderung der Bildschirmausrichtung) vom Betriebssystem aufgerufen werden 6. Um von Ereignissen unterrichtet zu werden, bei denen kein Callback auf einem Delegate aufgerufen wird, kann in der SystemConfiguration eine Registrierung vorgenommen werden. Wie dies funktioniert, zeigt ein Beispielprogramm, welches den Status der Datenverbindung beobachtet 7 6 Reference/Reference.html - abgerufen am uid/dts abgerufen am Seite 21

27 3 Analyse der Integrationsmöglichkeiten einer mobilen Plattform in eine CEP-Umgebung Basierend auf den Informationen aus Abschnitt und werden in diesem Kapitel mögliche Konstellationen zur Verteilung der einzelnen Komponenten aus einer CEP-Umgebung vorgestellt. Sie repräsentieren die verschiedenen Möglichkeiten, wie ein mobiles Endgerät in eine bestehende CEP-Umgebung integriert werden kann. Nachdem die verschiedenen Konstellationen der Komponenten betrachtet worden sind, werden die Anforderungen an die einzelnen Komponenten deniert. Diese Anforderungen dienen als Basis für das Konzept der Komponenten, welches schlieÿlich im nächsten Kapitel erstellt wird. Abschlieÿend werden die Möglichkeiten zur Event-Verarbeitung auf einer mobilen Plattform betrachtet. Hierbei wird insbesondere darauf eingegangen, wie der Zustand einer laufenden CEP- Umgebung festgehalten werden kann. Dies ist wichtig für den Betrieb auf einem mobilen System, da die Applikation, in welche die CEP-Umgebung integriert ist, jederzeit beendet und wieder gestartet werden kann. Aktuelle Ansätze zur komplexen Eventverarbeitung mit Einbindung von mobilen Plattformen werden ebenfalls im letzten Abschnitt angesprochen. Dabei wird auch ein Augenmerk auf Rule Engines gelegt, welche typischerweise für die Verarbeitung von Events innerhalb der Agenten eingesetzt werden. 3.1 Varianten der Integration in eine CEP-Umgebung Wie in Abschnitt beschrieben, gibt es in einer Event-Driven Architecture vier Hauptkomponenten: Event-Quellen Event-Träger oder Channel s Event-Verarbeitung oder Agenten Ereignis-Aktivität oder Consumer Diese Komponenten lassen sich entweder auf dem mobilen Gerät, oder auf einem externen Rechner betreiben. Dabei muss davon ausgegangen werden, dass die Ereignis-Träger immer auf beiden Seite 22

28 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.1. Integrationsvarianten Seiten vorhanden sein müssen, da es sich um das koppelnde Element zwischen den anderen Komponenten handelt. Daraus lassen sich sieben grundlegende Konstellationen ableiten, welche sich durch die Verteilung der Komponenten auf dem mobilen Endgerät und / oder dem externen Rechner voneinander abgrenzen. Weitere Ausprägungen sind selbstverständlich durch Kombinationen denkbar. Da diese Kombinationen aber keine weiteren expliziten Vor- oder Nachteile mit sich bringen, werden nur die Basisvarianten näher betrachtet. Die angesprochenen, sieben grundlegenden Konstellationen werden im Folgenden anhand von Abbildungen und erklärendem Text vorgestellt. Dabei ist auf jeder Abbildung das mobile Endgerät und eine Backend-Komponente zu sehen. Die Backend-Komponente steht dabei für eine existierende CEP-Umgebung. Diese Umgebung könnte sich sowohl auf einem stationären Rechner benden, als auch weiteren Systemen verteilt vorliegen. Genauso gut könnte es sich um andere, mobile Geräte handeln. In diesem Fall müsste korrekterweise jedoch von einer CEP-Umgebung gesprochen werden, die ausschlieÿlich auf mobilen Geräten läuft. Da in diesem Fall eine Unterscheidung zwischen den einzelnen Teilnehmern nicht sinnvoll erscheint, wird ausdrücklich von einem stationären System ausgegangen. Die schwarzen Pfeile zwischen den einzelnen Komponenten kennzeichnen Channels, mit deren Hilfe die Events zwischen den Komponenten ausgetauscht werden. Dabei ist die Pfeilrichtung ausschlaggebend für die Kommunikationsrichtung, in der die Events ieÿen sollen. Die Richtung der Kommunikation kann in den Konstellationen eindeutig gekennzeichnet werden, da die auf den Abbildungen verwendeten Event Processing Networks so aufgebaut sind, dass keine bidirektionale Kommunikation über einen Channel realisiert werden muss. Diese Entscheidung für die Darstellung ist getroen worden, um ein leichteres Verständnis für die Netzwerke zu ermöglichen Als Event-Quelle ohne Event-Verarbeitung Auf Abbildung 3.1 ist der Einsatz des mobilen Endgeräts als reine Event-Quelle skizziert. Dies ist die einfachste Möglichkeit, das Gerät in eine CEP-Umgebung zu integrieren. Die gesamte Verarbeitung der Events ndet bei dieser Art der Integration im Backend statt. Auch die Aktionen, die im schlieÿlich auslösen, werden im Backend, oder durch dieses, angestoÿen. Die Aktionen könnten z.b. Datenbankoperationen, Tracking und Tracing des mobilen Gerätes oder das Aufrufen von bestimmten Services sein. Auf diesem Weg könnte z.b. eine Verkehrsüberwachung im Straÿenverkehr implementiert werden. Durch gesendete Positions- und Geschwindigkeitsdaten von mobilen Endgeräten könnte auf der Backend-Komponente eine Verkehrslage errechnet werden. Die skizzierte Lösung könnte jedoch auch ohne den Einsatz von dedizierten CEP-Komponenten auf dem Endgerät gelöst werden. Es gäbe in diesem Fall als solches keine Event-Quelle und die Kommunikation zur Backend-Komponente würde nicht über einen Channel gelöst werden müssen. Stattdessen würde, wenn ein Ereignis auf dem Gerät auftritt, auf einem auÿerhalb des EPN liegenden Weg die Backend-Komponente angesprochen werden können. Die Backend-Komponente würde über eine entsprechende Event-Quelle verfügen (zum Beispiel einen Webservice-Endpunkt), in welcher dann das entsprechende Event erzeugt wird. Das erzeugte Seite 23

29 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.1. Integrationsvarianten Abbildung 3.1: Das mobile Endgerät als Event-Quelle ohne Event-Verarbeitung Event würde dann für die Verarbeitung genutzt werden. Dieser Ansatz würde das Endgerät jedoch explizit aus dem EPN ausschlieÿen und einen wesentlichen Vorteil des ansonsten verwendeten Channels nicht nutzen können. Der Vorteil besteht darin, dass die dem Sender (also dem mobilen Gerät) unbekannte Empfängerseite für Events erweitert und umstrukturiert werden kann. Dieser Vorgang würde für den Sender transparent geschehen, da er immer nur Events in den gleichen Channel geben muss. Vorteile Die Events müssen in dieser Konstellation nur in eine Richtung, zum Backend, übermittelt werden. Dafür kann ein unidirektionaler Channel benutzt werden. Damit kann die Problematik des Rückkanals zum mobilen Endgerät umgangen werden (vgl ). Da keine Verarbeitung der Events stattndet, wird keine groÿe Rechenleistung verwendet, die sich negativ auf den Energieverbrauch auswirken würde. Nachteile Nachteile erwachsen bei dieser Form der Integration nur, wenn von den generierten Events viele schon auf dem mobilen Endgerät ausgeltert werden könnten. Werden diese nicht ge- ltert (was in dieser Konstellation ja nicht möglich ist), dann kann dies zu einer überhöhten Nutzung der Datenverbindung führen. Durch diese vermeidbare Nutzung der Datenverbindung können Kosten entstehen und die Energiereserven des mobilen Gerätes werden übermäÿig strapaziert. Bewertung Die gezeigte Konstellation hat ihre Daseinsberechtigung und ist somit theoretisch in der Realität einsetzbar. Dabei ist allerdings auf jeden Fall darauf zu achten, ob die Menge der anfallenden Daten nicht durch eine auf dem Gerät stattndende Filterung eklatant verringert werden könnten. In diesem Fall ist dann auf eine Lösung wie in Konstellation zu sehen zurück zu greifen. Seite 24

30 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.1. Integrationsvarianten Als ausgelagerte Event-Verarbeitung Auf Abbildung 3.2 ist eine weiter Möglichkeit dargestellt, wie ein mobiles Endgerät in eine CEP-Umgebung eingebunden werden könnte. Stattdessen wird das Gerät ausschlieÿlich zur Verarbeitung von Events genutzt. Auch hier kann selbstverständlich ein Einsatzzweck gefunden werden. Prinzipiell kann eine Situation eintreten, in der die Verarbeitung von Events vom Backend auf externe Systeme ausgelagert werden muss, damit das Gesamtsystem skalieren kann. Hier ist das Problem, dass eine solche Auslagerung der Verarbeitung nicht auf ein potentiell weniger leistungsstarkes Gerät erfolgen sollte. Vor allem vor dem Hintergrund, dass kein Nutzen aus den sensorischen Fähigkeiten des Geräts gezogen wird und das Gerät auch nicht durch etwaige Aktionen gesteuert wird, wäre eine Auslagerung auf ein stationäres System in diesem Fall wesentlich sinnvoller. Der sowieso schon begrenzte Energievorrat auf dem mobilen Endgerät sollte nur genutzt werden, wenn keine andere Möglichkeit besteht. Inwieweit diese Möglichkeit der Einbindung somit von Nutzen ist, wäre zu diskutieren. Die Möglichkeit wurde jedoch der Vollständigkeit halber in die Übersicht mit aufgenommen. Abbildung 3.2: Das mobile Endgerät als ausgelagerte Event-Verarbeitung Vorteile Der einzige Vorteil, der sich in dieser Lösung nden lässt, ist die Nutzung von externen Ressourcen zur Verarbeitung von Events. Damit werden im genutzten Backend Ressourcen frei, welche anderweitig eingesetzt werden können. Nachteile Es werden keinerlei speziellen Möglichkeiten der mobilen Endgeräte genutzt. Es werden lediglich die Rechnenleistung und die Datenverbindung genutzt. Das bedeutet, dass die Energiereserven der mobilen Geräte extrem beansprucht werden, die Arbeit aber auch von stationären Rechnern übernommen werden könnte. Seite 25

31 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.1. Integrationsvarianten Ein weiterer Nachteil dieser Konstellation ist, dass das auf dem mobilen Gerät betriebene Event Processing Network um seinen Zustand halten zu können permanent auf dem Endgerät laufen müsste. Dieser Zustand ist unter Umständen für die Verarbeitung eingehender Events notwendig. Das Endgerät müsste zudem über eine überaus stabile Datenverbindung verfügen, da es als wichtiger Teil des gesamten EPN betrachtet werden müsste, wenn explizit Arbeit auf das Gerät ausgelagert wird. Bewertung Die gezeigte Konstellation entspringt, wie erwähnt, dem Gedanken, alle möglichen Kombinationen abzubilden und zu beschreiben. Sie ist von daher eher von einem wissenschaftlichen als von einem realen Einsatzwert. Die aufgeführten Nachteile mit dem Hinweis, dass sich eine solche Auslagerung auch auf einem herkömmlichen, stationären Gerät durchführen lassen würde reichen hier als Begründung Als Event-Consumer ohne Event-Verarbeitung In der auf Abbildung 3.3 dargestellten Verteilung der Komponenten werden, wie in der vorangegangenen Konstellation, keine Sensoren des mobilen Endgeräts ausgewertet. Allerdings werden vom Gerät empfangene Events in Aktionen umgesetzt. Eine solche Aktion könnte z.b. die Benachrichtigung des Benutzer sein oder auch das Starten einer Anwendung. Ein möglicher Einsatzzweck wäre z.b. eine Applikation, die neue Informationen per PUSH- Kommunikation auf das Endgerät übertragen möchte. Ein schönes Beispiel ist die Smartphoneapplikation für die Software DigitalFoosball 1, in der Live die Ergebnisse eines Tischfuÿballspiels auf ein Smartphone transferiert werden. Es handelt sich bei dem Beispiel allerdings um eine Webapplikation, die dieses pushen von aktuellen Spielständen per Web-Sockets erreicht. Wie auch bei der Konstellation 3.1 könnte die Funktionalität auch unter Ausschluss des mobilen Geräts aus dem EPN realisiert werden. Dazu müsste im Backend ein entsprechender Consumer eine Verbindung zu dem mobilen Endgerät aufbauen und das Event, bzw. dann schon aufbereitete Daten, transferieren. Auch hier gilt allerdings, dass der Vorteil eines Channels dann nicht genutzt würde. So wäre das Verteilen eines Events auf mehrere mobile Geräte über einen Channel einfach und transparent möglich, indem sich alle interessierten Geräte auf dem Channel registrieren. Vorteile Es handelt sich hierbei um ein Beispiel für die Implementierung einer klassischen Datenübertragung per PUSH. Damit verbunden ist, dass die durchgehend auf dem mobilen Gerät laufende Applikation sich darauf beschränken kann, die Verbindung zum EPN aufrecht zu erhalten und somit wenig Ressourcen verbraucht. Auf diese Weise ist es einfach möglich, von auÿen gesteuert Aktionen auf dem Gerät auszuführen. Anmerkung In dieser Variante ist es, ebenso wie in der in Abschnitt vorgestellten, möglich, 1 - abgerufen am Seite 26

32 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.1. Integrationsvarianten Abbildung 3.3: Das mobile Endgerät als Event-Consumer ohne Event-Verarbeitung einen unidirektionalen Channel zu nutzen. Der Vorteil kann hier jedoch nicht ausgespielt werden, da die kritische Verbindungsrichtung, nämlich die zu dem mobilen Gerät gerichtete, die benötigte Kommunikationsrichtung ist. Nachteile Es muss sichergestellt werden, dass die Verbindung zwischen dem mobilen Endgerät und dem im Backend beheimateten EPN nach Möglichkeit nicht abreiÿt. Würde dies geschehen, dann könnten die entsprechenden Aktionen auf dem Endgerät nicht mehr ausgeführt werden. Dies kann, wenn z.b. sicherheitsrelevante Aktionen angestoÿen werden sollten, kritisch sein. Da eine weitere Verarbeitung nicht stattndet, müssen alle eingehenden Daten fertig aufbereitet auf dem mobilen Gerät eintreen. Wenn von einer äuÿerst konsequenten Umsetzung der Zuständigkeitstrennung in der EDA ausgegangen wird, dann können eintreende Daten nicht einmal veriziert werden, da dies bereits eine Art Verarbeitung darstellen würde. Diese Verarbeitung hingegen würde, wenn die strikte Trennung der Zuständigkeiten eingehalten werden soll, von einem Agenten übernommen werden müssen. Bewertung Für unkritische Anwendungen ist diese Konstellation der Verteilung von Komponenten durchaus denkbar. Handelt es sich zum Beispiel um Statusupdates, die auf einem Smartphone angezeigt werden sollen, so kann dies mit der gezeigten Verteilung realisiert werden. Zu bedenken ist jedoch, dass eine reine PUSH-Funktionalität zumeist mit Boardmitteln der unterschiedlichen Plattformen implementiert werden kann, da die groÿen Anbieter Google 2, Apple 3 und Microsoft 4 eine solche Funktionalität bereits anbieten abgerufen am abgerufen am abgerufen am Seite 27

33 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.1. Integrationsvarianten Als Event-Consumer mit Event-Verarbeitung Abbildung 3.4 zeigt eine Konstellation, die im Prinzip der vorigen (Abbildung 3.3) gleicht. Hinzugekommen ist allerdings die Event-Verarbeitung. Damit kann erreicht werden, dass eingehende Events erst noch weiter verarbeitet werden, bevor diese zu Aktionen führen. Diese Verarbeitung könnte z.b. aus einer Filterung bestehen, die nur Events zulässt, die für genau das betreende, mobile Endgerät von Belang sind. Abbildung 3.4: Das mobile Endgerät als Event-Consumer mit Event-Verarbeitung Vorteile Im Gegensatz zum vorhergehenden Ansatz ist es bei dieser Konstellation möglich, nach dem Eingang eines Events auf dem mobilen Gerät dieses noch zu verarbeiten, bevor es zu einer Aktion führt. Dies ermöglicht z.b. eine Verizierung der eingehenden Daten. Anmerkung In dieser Variante ist es, ebenso wie in der in Abschnitt vorgestellten möglich, einen unidirektionalen Channel zu nutzen. Der Vorteil kann hier jedoch nicht ausgespielt werden, da die kritische Verbindungsrichtung, nämlich die zu dem mobilen Gerät gerichtete, die benötigte Kommunikationsrichtung ist. Nachteile Der Ressourcenverbrauch ist höher, als bei der vorhergehenden Lösung ohne einer Event- Verarbeitung auf dem mobilen Gerät. Bewertung Insgesamt bietet diese Konstellation im Vergleich zur in Abschnitt vorgestellten Variante wesentlich mehr Flexibilität. Dabei werden, je nach Menge der auf dem mobilen Gerät installierten Agenten, jedoch nur unwesentlich mehr Ressourcen benötigt. Seite 28

34 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.1. Integrationsvarianten Als Event-Quelle mit Event-Verarbeitung Eine weitere, denkbare Verteilung der einzelnen Komponenten der CEP-Umgebung zeigt Abbildung 3.5. Hier wird, ähnlich wie in der ersten, vorgestellen Variante, hauptsächlich Nutzen aus den sensorischen Fähigkeiten des mobilen Endgeräts gezogen. Die gewonnenen Daten können in diesem Fall jedoch nicht nur als Rohdaten, sondern auch geltert an das Backend weitergegeben werden. Die Vorverarbeitung der gesammelten Daten aus den Event-Quellen ermöglicht es, den Netzwerkverkehr zu minimieren, der durch die Übertragung entsteht. Während im ersten Fall (Abbildung 3.1) alle auftretenden Ereignisse eins zu eins als Events an das Backend weitergegeben werden, können sie mit einer Event-Verarbeitung erst entsprechend geltert werden. Natürlich wäre es auch denkbar, dass die Events schon auf dem mobilen Endgerät so weit verarbeitet werden, dass schlieÿlich nur noch die Ergebnisse (in Form von Events) an das Backend übermittelt werden müssen. So würde man von einer intelligenten Event-Quelle sprechen können. Die Filterung von Events wäre zum Beispiel in einem Umfeld sinnvoll, in dem viele mehrfach auftretende Ereignisse keinen Mehrwert für eine Aussage erzeugen. In den meisten dieser Fälle können alle Duplikate ausgeltert werden, ohne die endgültigen Ergebnisse zu verfälschen. Ein mögliches Anwendungsszenario lässt sich aus dem laufenden Projekt Leglo 5 ableiten. In diesem Projekt werden von einem mobilen Endgerät RFID-Etiketten gelesen und die Lesungen an ein Backend übermittelt. Bei dem Verfahren kommt es, aufgrund der verwendeten Technik, zu vielen doppelten Lesungen der gleichen Etiketten in einem kurzen Zeitraum. Da diese Dubletten allerdings für die Logik im Backend nicht benötigt werden, sie jedoch viel Bandbreite bei der Übermittlung der Daten beanspruchen, ist hier eine Vorverarbeitung im Sinne eines Filters auf dem mobilen Gerät sinnvoll. Abbildung 3.5: Das mobile Endgerät als Event-Quelle mit Event-Verarbeitung 5 - abgerufen am Seite 29

35 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.1. Integrationsvarianten Vorteile Diese Variante der Verteilung der unterschiedlichen Komponenten hat starke Ähnlichkeit mit der in Abschnitt vorgestellten Konstellation. Die Vorteile lassen sich daher weitestgehend übertragen. Diese Vorverarbeitung ist sinnvoll, wenn sie zu einer eklatanten Verringerung des Datenaufkommens sorgen kann, die schlieÿlich an das Backend übermittelt werden müssen. Anmerkung Wie auch in Abschnitt kann in diesem Modell ein unidirektionaler Channel eingesetzt werden. Dieser muss lediglich die Verbindung zum Backend halten, um die Daten zu übertragen. Solch ein unidirektionaler Channel kann jedoch nur dann eingesetzt werden, wenn die Agenten ausschlieÿlich für die Vorverarbeitung der Events genutzt werden, die von den Quellen auf der mobilen Plattform generiert werden. Nachteile Die benötigten Ressourcen auf dem mobilen Endgerät sind im Vergleich zur Variante in auf einem höheren Niveau. Bewertung Soll das mobile Endgerät ausschlieÿlich als Quelle für Events dienen, die in nachgelagerten Systemen weiter verarbeitet werden, dann bietet sich diese Variante an. Sie erlaubt auch, die Events exibel vorab zu verarbeiten, was insbesondere dem Aufkommen an Daten zuträglich sein kann, welches im Anschluss übertragen werden muss. Des Weiteren ergibt sich im Vergleich zu der anderen Variante, in der das Gerät ausschlieÿlich als Event-Quelle dient (vgl ), auch über den zuletzt genannten Punkt hinaus eine wesentlich höhere Flexibilität Als Event-Quelle und Event-Consumer mit Event-Verarbeitung Auf Abbildung 3.6 sind alle benötigten Komponenten einer CEP-Umgebung auf dem mobilen Endgerät im Einsatz. Dadurch ist hier im Prinzip kein Backend notwendig, allerdings handelt es sich dann streng genommen nicht um eine Integration des mobilen Gerätes in eine CEP- Umgebung. Das gezeigte EPN kann allerdings ebenso ein Ausschnitt aus einem Teilnetzwerk einer gröÿeren Umgebung sein, wie auf Abbildung 3.7 zu sehen ist. Die Benutzung aller Komponenten auf dem mobilen Endgerät bedeutet, dass die möglichen Einsatzzwecke fast beliebig sein können. So könnte auf einem Smartphone eine solche CEP- Umgebung dafür eingesetzt werden, bestimmte Vorgänge auf dem Telefon zu automatisieren, wie es heute schon durch Software wie z.b. Tasker 6 oder Locale 7 geschieht. Durch die Verwendung von CEP könnten die zur Verfügung stehenden Regeln, welche in den Produkten eingesetzt werden können, noch mächtiger werden, da besonders die zeitliche Korrelation von Ereignissen möglich wäre abgerufen am ) 7 - abgerufen am Seite 30

36 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.1. Integrationsvarianten Abbildung 3.6: Das mobile Endgerät als Event-Quelle und Event-Consumer mit Event- Verarbeitung Vorteile Bei der Einbindung in eine CEP-Umgebung, also keiner Stand-Alone-Lösung wie auf Abbildung 3.6 zu sehen ist, können die Vorteile der bis dato vorgestellten Varianten zusammengefasst werden. Auf dem Gerät generierte Events können direkt auf dem Gerät verarbeitet werden und führen dann ohne Verzögerung zu Aktionen oder werden vorgeltert an das Backend übertragen. In der anderen Richtung ist es möglich, Events aus dem Backend zu empfangen und diese, wenn sie Aktionen auslösen sollen, vorher noch zu validieren oder anderweitig zu verarbeiten. Zudem ist bei dieser Variante ebenfalls die Möglichkeit gegeben, dass vom Backend eingebrachte Events Einuss auf die weitergehende Verarbeitung auf dem mobilen Gerät haben, ohne, dass diese Events explizit Aktionen auf dem Gerät auslösen sollten. Anmerkung Je nach Einsatzzweck können auch bei diesem Modell unidirektionale Implementierungen eines Channels zur Kommunikation zwischen dem Backend und dem mobilen Endgerät eingesetzt werden. Allerdings ist dies nur sinnvoll, wenn ausschlieÿlich Daten vom mobilen Endgerät zum Backend übermittelt und keine Daten empfangen werden müssen. Wenn keine Daten vom Backend empfangen werden, bedeutet dies gleichzeitig, dass die Aktionen, welche auf dem mobilen Gerät ausgeführt werden können, ausschlieÿlich auf der Verarbeitung von Events basieren, die auf dem Gerät selbst entstanden sind. Nachteile Die Nachteile dieser Lösung liegen in der erhöhten Komplexität des insgesamt entstehenden Event Processing Networks und dem erhöhten Ressourcenbedarf auf dem mobilen Gerät. Bewertung Die hier vorgestellte Variante ist die exibelste unter allen vorgestellten Varianten zur Einbindung eines mobilen Endgeräts in eine CEP-Umgebung. Durch den Einsatz aller Kom- Seite 31

37 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.1. Integrationsvarianten Abbildung 3.7: Das mobile Endgerät als Event-Quelle und Event-Consumer mit Event- Verarbeitung als Teil eines gröÿeren EPN ponenten einer CEP-Umgebung können alle denkbaren Szenarien gelöst werden. Da es sich gleichzeitig aber auch um die komplexeste Konstellation handelt, ist vor einem Einsatz dieser Möglichkeit auf jeden Fall zu eruieren, ob das entsprechende Szenario nicht auch mit einer anderen der vorgestellten Varianten gelöst werden könnte Als Event-Quelle und Event-Consumer ohne Event-Verarbeitung Die letzte denkbare Möglichkeit ist die Verwendung des mobilen Endgeräts als Event-Quelle wie in 3.1, jedoch zusätzlich als Event-Consumer. Diese Variante schlieÿt nur die Event-Verarbeitung auf dem Gerät aus. Dadurch ist es möglich, dass auftretende Ereignisse direkt zu Aktionen auf dem Endgerät führen, allerdings ohne eine etwaige Verarbeitung oder Überprüfung. Ebenso ist es möglich, dass auf dem Gerät erzeugte Events extern (im Backend) verarbeitet werden und die daraus resultierenden Schlüsse auf dem Endgerät zu Aktionen führen. Ein mögliches Einsatzszenario wäre die Umsetzung eines Navigationssystems, bei dem die Daten ungeltert an das Backend übertragen werden. Alle mobilen Endgeräte übermitteln ihre Standortdaten an das Backend, welches daraus die Verkehrsdichte etc. berechnen kann. Die resultierenden Ergebnisse, zum Beispiel das Auftreten eines Staus, können dann an die mobilen Endgeräte übermittelt und dort dargestellt werden. Zu bedenken ist jedoch, dass weder ausgehende noch eingehende Events geltert werden können. Dieser Umstand kann für erhöhte Belastung der Datenverbindung der mobilen Endgeräte sorgen. Ebenso können Daten vom Backend an die Endgeräte übermittelt werden, welche für diese nicht relevant sind. Da die Geräte an dieser Stelle aber wiederum keine Validierung oder Filterung vornehmen können, müssen sie sich darauf verlassen, dass die Daten entsprechend vom Backend aufbereitet sind. Vorteile Durch die Abwesenheit einer Event-Verarbeitung werden auf dem Endgerät die komplexesten Komponenten, die Agenten, nicht benötigt. Das bedeutet eine groÿe Entlastung der Seite 32

38 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.1. Integrationsvarianten Ressourcen des Geräts, da die Quellen und Consumer keine groÿen Ansprüche an diese stellen. Nachteile Ausgehende und eingehende Events können weder geltert noch validiert oder anderweitig verarbeitet werden. Das bedeutet, dass die Flexibilität der Lösung, bezogen auf die Abläufe auf dem mobilen Endgerät, stark eingeschränkt ist. Bewertung Sollen innerhalb einer Anwendung Daten dargestellt werden, die sich aus Events von vielen Endgeräten zusammensetzen, dann bietet sich eine solche Lösung an. Die Events können dabei allerdings nicht verarbeitet werden. Das betrit sowohl die ausgehenden, als auch eingehenden Events. Eine Lösung mit integrierter Verarbeitung, wie in wäre in den meisten Fällen entsprechend besser geeignet, da sie zu erhöhter Flexibilität führt. Abbildung 3.8: Das mobile Endgerät als Event-Quelle und Event-Consumer ohne Event- Verarbeitung Zusammenfassung Wie sich bei der Betrachtung der einzelnen, denkbaren Varianten schon deutlich deutlich gezeigt hat, eignen sich nicht alle Konzepte zur Realisierung. Zumeist kann eine Eignung aufgrund mangelnder Flexibilität oder wegen Verschwendung von Ressourcen auf dem mobilen Endgerät abgesprochen werden. Entscheidend ist hierbei, dass zwar die Ressourcen verwendet werden, aber keine der besonderen Fähigkeiten des mobilen Endgeräts in Anspruch genommen wird. Soll ein mobiles Endgerät als Quelle für Events eingesetzt werden, so ist vor allem danach zu unterscheiden, wie viele Events von dem mobilen Gerät erwartet werden. Je nachdem ist es sinnvoll, eine Event-Vorverarbeitung auf dem Gerät zu etablieren, um z.b. Events auszultern. Somit können unter Umständen groÿe Mengen an Daten gespart werden, die sonst an das Backend übermittelt werden würden, ohne zu einen Erkenntniszuwachs zu führen. Interessant an dem Seite 33

39 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.2. Anforderungen an die Komponenten der CEP-Lösung Einsatzzweck als reine Quelle von Events, ob mit oder ohne Event-Verarbeitung, ist, dass es nur eines unidirektionalen Channels bedarf, um das mobile Endgerät mit dem Backend zu verbinden. Auf diese Art ist das Problem der Erreichbarkeit des Gerätes unter verschiedenen IP Adressen irrelevant. Wenn ein Endgerät als Consumer in das EPN integriert werden soll, bietet sich eine Verabeitung der eingehenden Events zumeist an. Findet keine Verarbeitung der eingehenden Events statt, so muss sicher gestellt sein, dass das Backend ausschlieÿlich fertig aufbereitete Events versendet, die von dem jeweiligen Empfänger auch von Interesse sind. Technisch ist es möglich, dass in einem Consumer auch ein wenig Logik implementiert wird, dies stände jedoch im Widerspruch zu den Aufgaben der einzelnen Komponenten in einer CEP-Umgebung. Der Einsatz von Agenten, also Event-verarbeitenden Komponenten, auf einem mobilen Endgerät beschränkt sich bei den meisten Varianten darauf, dass diese Agenten zur Filterung von Events oder für andere, einfache Aufgaben eingesetzt werden. Natürlich können auch komplexere Aufgaben von den Agenten übernommen werden, dies ist aber immer vom entsprechenden Einsatzszenario abhängig. Eine Filterung von Events oder das Anreichern der Events mit Daten aus dem mobilen Endgerät hingegen ist, bezogen auf die möglichen Einsatzszenarien, relativ unspezisch und kann somit als pauschaler Einsatzzweck gewertet werden. Insgesamt kann festgehalten werden, dass mit Ausnahme einer Variante (vgl. Abschnitt 3.1.2) alle vorgestellten Konstellationen auch für eine reale Umgebung denkbar wären. Hier sollte jedoch stets im Auge behalten werden, dass jegliche weitere Komponente auf dem mobilen Endgerät dessen Energiereserven belasten kann. Andererseits ist ebenfalls zu bedenken, dass beim Senden von Events eine zusätzliche Komponente im Form eines Agenten zur Filterung durchaus Sinn machen und den entstehenden Datenstrom verkleinern kann. Dies würde die Energiereserven im Endeekt gegebenenfalls schonen. 3.2 Anforderungen an die Komponenten der CEP-Lösung Im vorangegangenen Abschnitt wurden verschiedene Konstellationen vorgestellt, die durch Verteilung der unterschiedlichen Komponenten einer CEP-Umgebung vorstellbar sind. Dabei ist gezeigt worden, dass im Endeekt alle diese Komponenten auch auf dem mobilen Endgerät zum Einsatz kommen können. In diesem Abschnitt geht es darum, die Anforderungen an die einzelnen Komponenten einer CEP-Umgebung für den Einsatz auf einer mobilen Plattform zu denieren. Anhand dieser Anforderungen wird im Kapitel 4 das Konzept für die auf dem mobilen Endgerät eingesetzte CEP-Umgebung entworfen. Die Anforderungen setzen sich dabei aus hauptsächlich zwei Bereichen zusammen. Auf der einen Seite stehen die funktionalen Anforderungen, die eine Event-Driven Architecture mit sich bringt (vgl. Abschnitt 2.1.1). Auf der anderen Seite stehen die, zumeist nicht-funktionalen, Anforderungen, die durch die Verwendung einer mobilen Plattform als Rahmenbedingung vorgegeben werden. Seite 34

40 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.2. Anforderungen an die Komponenten Anforderungen an die Event-Quelle Die Event-Quelle auf dem mobilen Endgerät stellt die Schnittstelle zu den Ereignissen dar, die auf dem mobilen Gerät auftreten oder die vom Gerät in dessen Umgebung wahrgenommen werden. Als ursprüngliche Quelle der Ereignisse kommen dabei drei verschiedene Erzeuger in Frage: Das Betriebssystem Die Ereignisse, die durch Sensoren auf der Plattform erkannt werden, werden typischerweise vom System selbst innerhalb der Plattform propagiert bzw. können von einer Applikation vom System abgefragt werden. Dabei kommen plattformspezische Verbreitungsmechanismen zum Einsatz (vgl. Abschnitt 2.3). Um diese Art von Ereignissen vom System zugespielt zu bekommen, ist im Regelfall eine Registrierung für die Ereignisse im Betriebssystem notwendig. Diese Ereignisse erreichen die Event-Quelle naturgemäÿ in einem plattformspezischen Format und müssen in Events transformiert werden können. Applikationen von Drittanbietern Durch Interprozesskommunikation können, je nach verwendeter Plattform, auch Anwendungen von Drittanbietern Ereignisse produzieren. Diese können dann durch plattformspezische Mechanismen zur Interprozesskommunikation an die CEP-Umgebung (in Form der Event-Quellen) weitergegeben werden (vgl. Abschnitt 2.3) Auch in diesem Fall erreichen die Ereignisse die Event-Quelle in einem plattformabhängigen Format und müssen entsprechend aus diesem umgewandelt werden. Ebenso wie bei den Systemereignissen ist auch in diesem Fall in der Regel eine Registrierung der Event-Quelle als Empfänger dieser Art Ereignisse notwendig. Die die CEP-Umgebung umgebende Applikation Wird die CEP-Umgebung nicht als einzelne Anwendung auf der Plattform betrieben, sondern als Teil einer Applikation, dann kann diese umgebende Applikation Ereignisse produzieren. Diese Ereignisse müssen von einer Event-Quelle dann in das EPN eingespeist werden. An dieser Stelle ist es jedoch nicht zwingend notwendig, die Kommunikation zur Event-Quelle mit plattformspezischen Lösungen umzusetzen, da nur innerhalb der einen Applikation kommuniziert werden muss. Stattdessen kann eine solche Event-Quelle sich beispielsweise in einer Java-Umgebung als Observer verdingen und auf diese Weise auf applikationsinterne Ereignisse reagieren. Für eine Event-Quelle ergeben sich somit die folgenden Anforderungen: Funktionale Anforderungen Die Event-Quelle muss in der Lage sein, plattformspezische Ereignisse zu registrieren, um systemseitig generierte und durch Interprozesskommunikation entstandene Ereignisse empfangen zu können. Die Registrierung für die plattformspezischen Ereignisse ist dabei naturgemäÿ abhängig von der verwendeten Plattform. Die empfangenen Ereignisse müssen anschlieÿend von der Quelle in Eventobjekte transformiert werden. Diese Transformation ist ebenfalls plattformspezisch, da die eingehenden Ereignisse kein einheitliches Format besitzen. Abschlieÿend werden die erzeugten Events in einen Channel gegeben, der der Quelle bekannt sein muss. Seite 35

41 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.2. Anforderungen an die Komponenten Nicht-funktionale Anforderungen Um eine maximale Modularität zu gewährleisten, sollte eine Event-Quelle ausschlieÿlich für eine Art eingehender Ereignisse bestimmt sein. So sollen sich einfach weitere Event- Quellen für bisher nicht verwendete Ereignistypen registrieren lassen. Die Event-Quellen sollen vom Rest der Software durch die Verwendung von Channels zur Übertragung der erzeugten Events entkoppelt werden Anforderungen an den Channel Der Channel soll zur Kommunikation zwischen den einzelnen Komponenten der CEP-Umgebung genutzt werden. Dabei muss zwischen zwei grundlegend unterschiedlichen Kommunikationsarten unterschieden werden. Auf der einen Seite wird ein Channel benötigt, der ausschlieÿlich Events aus dem internen Umfeld, also dem auf dem mobilen Gerät laufenden EPN, empfängt und diese an lokale Komponenten weiter gibt. Auf der anderen Seite wird ein Channel benötigt, der zusätzlich Events von auÿen empfangen kann und diese dann an die lokalen Komponenten verteilt, sowie lokale Events nach auÿen verfügbar macht. Intern genutzter Channel Um Events intern auf dem mobilen Endgerät zwischen den Komponenten auszutauschen, wird ein Channel benötigt, der keine komplexen Aufgaben erfüllen können muss. Durch die ausschlieÿliche Verwendung für die interne Kommunikation ist die Funktionalität übersichtlich und kann auf jeder Plattform umgesetzt werden. Funktionale Anforderungen Auf dem Channel sollen sich andere Komponenten (Consumer und Agenten) als Event- Empfänger registrieren können. Wird ein Event in den Channel gegeben, so soll es an alle registrierten Empfänger weiter gegeben werden. Jeder Channel soll über einen eindeutigen Namen referenziert werden können. Wird ein Event in den Channel A gegeben, so müssen alle Komponenten, die sich auf Channel A registriert haben, das Event zugestellt bekommen. Der Channel soll nicht an bestimmte Event-Typen gebunden werden. Das bedeutet, dass jeder Channel jede Art Event an alle Empfänger übermitteln können muss. Nicht-Funktionale Anforderungen An den intern genutzten Channel werden keine speziellen, nicht-funktionalen Anforderungen gestellt. Extern genutzter Channel Im Prinzip handelt es sich bei einem extern nutzbaren Channel um eine Erweiterung des intern genutzten, welcher in seiner Funktionalität um zwei Punkte ergänzt wird. Der erste dieser Punkte betrit die Weitergabe von auf dem mobilen Gerät erzeugten Events. Diese müssen nicht nur an die internen Komponenten, sondern auch an externe Kommunikationspartner weiter gegeben Seite 36

42 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.2. Anforderungen an die Komponenten werden. Der zweite Punkt betrit die Möglichkeit, Events von den externen Kommunikationspartnern zu empfangen. Diese Events müssen dann an die internen Komponenten weitergegeben werden. Detaillierte Anforderungen für die Art der Serialisierung von Daten und der Übermittlung an externe Kommunikationspartner werden in Abschnitt genauer betrachtet. Zusammengefasst können die folgenden Anforderungen an einen Channel deniert werden, der auch nach auÿen kommunizieren kann. Funktionale Anforderungen Eingehende Events werden von dem Channel sowohl an die internen Komponenten, als auch über eine Netzwerkverbindung an Kommunikationspartner aus der Auÿenwelt weiter gegeben. Um die Kommunikation mit der Auÿenwelt zu realisieren, muss der extern genutzte Channel eine Verbindung zu einem spezizierten Service aufbauen können. Über diese Verbindung werden die Events in beide Richtungen, also bidirektional, ausgetauscht. Es gilt auch bei den extern nutzbaren Channels das Prinzip, dass ein Channel aufgrund seines Namens referenziert wird. Somit müssen alle Channels, die sich unter Benutzung desselben, externen Services mit gleich lautendem Namen an diesem Service registrieren, einen logischen Kanal darstellen. Das bedeutet, wenn sich 5 Channels mit dem Namen A an einem Service anmelden und in einen von ihnen ein Event gegeben wird, alle dieses Event erhalten (und damit alle Empfänger, die an den jeweiligen Channels registriert sind). Da die Kommunikation über das Netzwerk statt ndet, muss der extern nutzbare Channel Events serialisieren und deserialisieren können. Dies ist dem Umstand zu schulden, dass lediglich serialisierte Daten, jedoch keine Objektinstanzen über das Netzwerk verschickt werden können. Die Serialisierung der Events muss dabei in ein plattformunabhängiges Format erfolgen. Ebenso darf die Art der Übermittlung der serialisierten Daten nicht vom verwendeten, mobilen Gerät abhängig sein. Nicht-Funktionale Anforderungen Die Methode zum Serialisieren und Deserialisieren soll austauschbar sein, um eine hohe Flexibilität in der externen Kommunikation zu erreichen. Bei der Kommunikation mit dem externen Service muss auf Asynchronität geachtet werden, damit etwaige Netzwerklatenzen oder ein nicht erreichbarer Service nicht zu Blockaden führen Anforderungen an den Agenten Der Agent stellt die Komponente zur eigentlichen Verarbeitung der Events dar. Er empfängt Events von anderen Komponenten der CEP-Umgebung und gibt die Ergebnisse seiner Verarbeitung ebenfalls in Form von Ereignissen wieder zurück in das EPN. Funktionale Anforderungen Der Agent verarbeitet eingehende Events und gibt die Ergebnisse in Form von Events weiter. Die Events bekommt der Agent dabei aus den Channels zugestellt, in denen er als Event- Empfänger registriert ist. Die Verarbeitung wird soweit abstrahiert dargestellt, dass keine Seite 37

43 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.2. Anforderungen an die Komponenten bestimmte Technik (zum Beispiel eine bestimmte Software zur Regelverarbeitung) genutzt werden muss. Nicht-Funktionale Anforderungen Es muss auf einfache Weise möglich sein, neue Agenten mit einer abweichenden Event- Behandlung zu erstellen und diese in das EPN zu integrieren Anforderungen an den Consumer Der Consumer stellt, wie der Agent, ein Empfänger von Events aus Channels dar. Im Gegensatz zu einem Agenten gibt der Consumer jedoch keine Events zurück in das EPN. Funktionale Anforderungen Der Consumer empfängt Events aus einem oder mehreren Channeln, in denen er als Empfänger registriert ist. Die so empfangenen Events führen zu Aktionen auf dem mobilen Endgerät. Nicht-Funktionale Anforderungen Es muss auf einfache Weise möglich sein, neue Consumer zu erstellen und diese in das EPN zu integrieren Anforderungen an das Event-Processing Network An das EPN, also die Kombination aus mehreren der oben aufgeführten Komponenten, werden ebenfalls Anforderungen gestellt. Diese werden im Folgenden näher speziziert. Funktionale Anforderungen Das EPN muss frei zusammengestellt werden können. Das bedeutet, dass die Anzahl und Art der verwendeten Komponenten des EPN sowie deren Verknüpfung frei denierbar sind. Eine weitere Anforderung erwächst aus dem Einsatz auf einer mobilen Plattform: Da der Lebenszyklus des EPN begrenzt sein kann, muss der Zustand eines etablierten Netzwerks speicher- und wiederherstellbar sein. Dieser Zustand, bezogen auf das EPN, betrit die Art und Anzahl der verwendeten Komponenten und deren Verknüpfung miteinander. Nicht-Funktionale Anforderungen Das EPN darf während der Verarbeitung eines Events nicht blockieren. Somit müssen die einzelnen Komponenten, die in der Verarbeitung und Weiterleitung beteiligt sind, nichtblockierend arbeiten. Dies betrit die Channels und Agenten sowie Consumer Anforderungen an die Datenübertragung zwischen CEP-Komponenten auf physisch getrennten Systemen Der folgende Abschnitt beschreibt detailliert, wie die externe Kommunikation des Channels beschaen sein muss, welcher ebenfalls Events von auÿerhalb der Plattform empfangen und Events an externe Komponenten senden kann. Es muss berücksichtigt werden, dass das mobile Endgerät über eine unzuverlässige Datenverbindung verfügen kann. Diese Unzuverlässigkeit wird Seite 38

44 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.2. Anforderungen an die Komponenten sich durch schwankende Verbindungsqualität und unter Umständen auch durch Verbindungsabbrüche bemerkbar machen. Es muss zudem davon ausgegangen werden, dass das Gerät nach einem Verbindungsabbruch oder nach einem Verbindungswechsel eine neue IP Adresse zugeteilt bekommt. Anforderungen an das Datenformat Die Events, welche die zu übertragenden Daten darstellen, sind einfache Objekte mit einer Menge an Attributen. Diese Objekte können somit auch als Art Attributcontainer oder Bean beschrieben werden (vgl. Abschnitt 2.1.1). Wie bereits bei den Anforderungen an den Channel erwähnt, müssen diese Events vor dem Versenden serialisiert werden. Erst in diesem serialisierten Zustand können die Daten über eine Netzwerkverbindung an den Kommunikationspartner übermittelt werden. Dabei ist beim Serialisieren zu beachten, dass das verwendete Format keine Bindung an eine bestimmte Plattform erzwingt, da sonst die globale Anforderung an eine systemunabhängige Lösung nicht erfüllt werden kann. Ebenso ist eine Methode zu wählen, die keinen groÿen Overhead erzeugt. Dies betrit sowohl die Berechnungszeit, die zur Serialisierung und Deserialisierung aufgewendet werden muss, aber auch die entstehenden Datenmengen. Gerade im mobilen Umfeld sind diese beiden Punkte kritischer Natur, da sie sich erheblich auf den Energiebedarf auswirken. Bei der Annahme, dass in der CEP-Umgebung sehr viele Events erzeugt und unter Umständen auch übertragen werden müssen, ist jede Ersparnis von Rechenzeit und Übertragungsvolumen bedeutsam. Für die Darstellung dieser serialisierten Daten bieten sich im im Kontext dieser Arbeit Formate an, die als Klartext übertragen werden können. Klartext kann von allen gängigen Programmiersprachen einfach und schnell erzeugt und verarbeitet werden. Im Gegensatz zu einem binären Format bietet es zudem den Vorteil, für den Menschen lesbar zu sein und somit die Entwicklung der Software zu vereinfachen. Des Weiteren erfolgt bei einem binären Format typischerweise zumindest eine Bindung an eine ganz bestimmte Interpretation der Daten. Im Extremfall wird so sogar eine Abhängigkeit zur verwendeten Programmiersprache oder, im Falle der Java-Serialisierung, sogar an eine bestimmte Version der Umgebung erschaen. Schlieÿlich ist die Übertragung von Klartext-Nachrichten sehr einfach möglich, da sie prinzipiell mit jeder Technologie zur Datenübertragung versendet werden können. Ebenfalls wichtig ist die Verizierung der Daten. Es sollte anhand eines Schemas möglich sein, die empfangenen Daten zu verizieren, bevor versucht wird, sie wieder in Objekte umzuwandeln. Das Format, welches gewählt wird, sollte ebenfalls von allen gängigen Programmiersprachen unterstützt werden. Ob diese Unterstützung dabei nativ oder durch qualitativ hochwertige Bibliotheken erfolgt, spielt eine untergeordnete Rolle. Anforderungen an die Übermittlungstechnik Ebenso wie das oben angesprochene Format der zu übertragenden Daten muss auch die Übertragung der Daten unabhängig von den genutzten Plattformen gelöst sein. Für die Verwendung in einer CEP-Umgebung sind dabei weitere Anforderungen zu erfüllen. Seite 39

45 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.2. Anforderungen an die Komponenten Übertragung von Klartext Aus den Anforderungen für das Format der Daten geht hervor, dass es sich um Klartext- Dokumente handeln wird. Unter diesem Gesichtspunkt muss die gewählte Übermittlungsform in der Lage sein, solche Klartext-Dokumente zu übermitteln. Geschwindigkeit Einer der ausschlaggebenden Punkte für die Datenübertragung ist die Geschwindigkeit, mit welcher Events über die gewählte Art der Datenübertragung von einem Kommunikationspartner zum anderen versendet werden können. Die maximale Laufzeit für ein Event kann an dieser Stelle nicht festgelegt werden, da sie vom Einsatzszenario abhängig ist. Die Zeit für die Übermittlung eines Events sollte aber generell so gering wie möglich sein, damit die Erwartung an eine CEP-Umgebung als Echtzeitverarbeitungs-Architektur erfüllt werden kann. Plattformunabhängigkeit Die Form der Datenübertragung darf nicht an eine bestimmte Plattform gebunden sein. Es muss sich demzufolge um eine Technik handeln, die sich auf den gängigen Plattformen mit den systemeigenen Mitteln verwirklichen lässt. Selbstverständlich kann auch auf Bibliotheken zurück gegrien werden, die die Funktionalität für die gewählte Technik bereit stellen, diese sollten aber entsprechend für alle gängigen Plattformen existieren. Leichtgewichtigkeit Die Datenübertragung sollte zumindest auf dem mobilen Endgerät so wenig Ressourcen wie möglich beanspruchen. Das bedeutet, dass auf dem Endgerät keine speziellen Services installiert und betrieben werden sollen, um die Datenübertragung zu gewährleisten. Abbildung des Kommunikationsmodells Das Kommunikationsmodell für die Übertragung von Daten zwischen verschiedenen Systemen im EPN muss durch die verwendete Technik realisiert werden können. Die Kommunikation soll asynchron ablaufen und in beide Richtungen, also bidirektional, funktionieren. Dabei ist zu beachten, dass mobile Endgeräte über dynamische IP Adressen verfügen, die sich jederzeit ändern können Globale Anforderungen Für alle Bereiche der zu entwickelnden Lösung gilt, dass so wenig wie möglich plattformspezische Konstrukte und Lösungswege verwendet werden sollen. Nur so ist es möglich, ein für viele verschiedene Plattformen gültiges Konzept zu erarbeiten. Das Konzept für eine CEP-Lösung auf einem mobilen Endgerät soll ebenfalls darauf ausgelegt sein, so wenig Ressourcen wie möglich zu benötigen. Inwieweit dies möglich ist, muss evaluiert werden. Insbesondere die Verteilung zwischen Verarbeitung von Events (CPU-intensiv) und der Anzahl der an das Backend zu übertragenden Ereignisse kann dabei eine entscheidende Rolle einnehmen. An dieser Stelle ist es wichtig, einen möglichst optimalen Kompromiss zu nden, um die Energiereserven des mobilen Endgeräts so weit wie möglich zu schonen. Seite 40

46 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.3. Complex Event Processing auf mobilen Geräten 3.3 Complex Event Processing auf mobilen Geräten Wie in Abschnitt 3.1 gezeigt wurde, kann die Integration eines mobilen Endgeräts in eine CEP- Umgebung auf verschiedene Weisen realisiert werden. Eine besondere Beachtung benötigen dabei die Möglichkeiten, die eine Event-Verarbeitung auf der mobilen Plattform beinhalten. Diese Event-Verarbeitung dieriert besonders in zwei Bereichen von der auf einem System mit einem herkömmlichen Betriebssystem. Der erste Unterschied betrit den Lebenszyklus von Anwendungen auf einer mobilen Plattform, der stark von dem darunter operierendem Betriebssystem reglementiert wird (vgl. 2.3). Dieser unvorhersagbare Lebenszyklus bedeutet für die CEP-Umgebung, dass diese zu jedem Zeitpunkt beendet werden kann, um später wieder fortgesetzt zu werden. Inwieweit der Zustand der CEP- Umgebung gespeichert und wiederhergestellt werden kann, wird in diesem Abschnitt der Arbeit betrachtet. Der zweite Unterschied betrit die Art, wie die Agenten die eingehenden Events verarbeiten. Diese Verarbeitung wird typischerweise mit Hilfe einer Regelmaschine oder Rule Engine durchgeführt. Für normale Betriebssysteme stehen verschiedene Implementierungen solcher Rule Engines zur Verfügung. Es bleibt also zu klären, ob auch für mobile Plattformen solche Rule Engines existieren bzw. inwieweit existierende Lösungen für stationäre Systeme auch auf mobilen Plattformen eingesetzt werden können. Auf diesen Sachverhalt wird ebenfalls in diesem Abschnitt eingegangen. In diesem Rahmen werden abschlieÿend exemplarisch zwei verschiedene Implementierungen einer Rule Engine näher auf eine mögliche Tauglichkeit beleuchtet Persistierung des Zustands einer CEP-Umgebung Normalerweise wird davon ausgegangen, dass eine CEP-Umgebung und damit das aufgebaute Event Processing Network dauerhaft in Betrieb ist. Das Netzwerk kann zwar zur Laufzeit modiziert werden, indem Komponenten hinzugefügt, entfernt oder neu vernetzt werden, insgesamt bleibt das Netzwerk als Ganzes aber im Regelfall online. Während des Betriebs des Netzwerks ist dessen Zustand sehr dynamisch. Durchgehend werden neue Events erzeugt, durch das Netzwerk verarbeitet und weiter gegeben. Zu unterschiedlichen Zeitpunkten benden Events an verschiedenen Punkten des Netzwerks und die einzelnen Komponenten sind mit der Bearbeitung ihrer jeweiligen Aufgaben beschäftigt. Soll dieses dynamische Gebilde temporär eingefroren werden, dann ergeben sich daraus Herausforderungen, die bei der typischen Nutzung eines EPN nicht auftreten. Zuerst muss das Netzwerk in einen Zustand überführt werden, der speicher- und wiederherstellbar ist. Anschlieÿend muss der Zustand der einzelnen Komponenten abgefragt und gespeichert werden. Schlieÿlich muss die Topologie des Netzwerks, also die eingebundenen Komponenten und die Vernetzung zwischen ihnen, erfasst und ebenfalls gespeichert werden. Sind diese Schritte erfolgreich verlaufen, kann das Netzwerk wiederhergestellt werden. Dies passiert in umgekehrter Reihenfolge: Zuerst werden die beteiligten Komponenten initialisiert und wieder zu einem Netzwerk verknüpft. Danach werden die vormals gespeicherten Daten, die den Zustand der einzelnen Komponenten ausmachen, diesen wieder zur Verfügung gestellt. Seite 41

47 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.3. CEP auf mobilen Geräten Nachdem der Zustand wiederhergestellt worden ist, kann das Netzwerk wieder seine normale Arbeit aufnehmen. Beispiel eines EPN auf einer mobilen Plattform Die einzelnen Schritte zum Speichern eines laufenden EPN sollen anhand des Beispiels auf Abbildung 3.9 beschrieben werden. Auf der Abbildung sind zwei Event-Quellen, drei Agenten und ein Consumer zu sehen, der eine Aktivität auf dem Gerät ausführen soll. Die Channels, die die einzelnen Komponenten verbinden, sind der Einfachheit halber lediglich durch schwarze Pfeile symbolisiert. Abbildung 3.9: Beispiel eines Event Processing Networks auf einem mobilen Endgerät Quelle 1 generiert Events vom Typ 1 und leitet diese an Agent 1 weiter. Dieser Agent reichert die eingehenden Event mit weiteren Daten an und übermittelt die Events weiter an Agent 3. Quelle 2 und Agent 2 arbeiten nach demselben Schema, nur werden hier Events vom Typ 2 generiert und angereichert. Agent 3 verfügt über eine simple Regel zur Event-Verarbeitung. Er sucht in dem ihm zur Verfügung gestellten Eventstrom nach Events vom Typ 2, die innerhalb von 10 Sekunden nach einem Event vom Typ 1 auftreten. Wird dieses Pattern erkannt, generiert der Agent 3 ein Event vom Typ 3 und schickt dieses an den Consumer am Ende der Kette. Speichern des Zustands Um den Zustand des Event Processing Networks zu speichern, muss dieser Zustand erst einmal erfassbar sein. Um sich ein besseres Bild machen zu können, zeigt Abbildung 3.10 einen Schnappschuss des Beispiel-EPNs zur Laufzeit. Auf dem Schnappschuss sind verschiedene Events der Typen 1 und 2 zu sehen, die sich an unterschiedlichen Stellen des EPN benden. Ein Event bendet sich gerade im Channel zwischen Quelle 1 und Agent 1 und soll gerade zugestellt werden. Ein weiteres Event wurde soeben in Quelle 2 erzeugt und soll in den angeschlossenen Channel gegeben werden. Zwei weitere Events benden sich in Agent 3 und werden dort gerade durch die im Agenten operierende Rule Engine verarbeitet. Seite 42

48 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.3. CEP auf mobilen Geräten Abbildung 3.10: Beispiel eines Event Processing Networks auf einem mobilen Endgerät (Schnappschuss 1) Die einzelnen Komponenten benden sich gerade dabei, ihre Aufgaben zu erfüllen. Das bedeutet, dass sie sich im schlimmsten Fall gerade in komplexen Routinen benden, was besonders Agent 3 betreen kann. Dieser Zustand könnte so nicht wiederhergestellt werden. Die einfachste Möglichkeit, um einen wiederherstellbaren Zustand zu erreichen, ist, den Event- uss zu unterbinden. Um dies zu erreichen, soll folgende Lösung betrachtet werden, bei der alle noch laufenden Berechnungen und Aktionen ausgeführt, aber keine Events mehr an verarbeitende Komponenten übermittelt werden: Im ersten Schritt erhalten alle Channels und Event-Quellen ein Stoppsignal. Quelle 2 würde in diesem Fall das Event, welches sie schon erzeugt hat, noch in den Channel geben, aber keine weiteren Events erzeugen. Empfängt ein Channel das Signal, so liefert er alle noch vorhandenen Events aus und hängt alle neu eingehenden Events in eine Queue, statt sie weiter zu geben. Haben alle Channels ihre noch auszuliefernden Events an die Empfänger verteilt, wird an die verbliebenden Komponenten (Agenten und Consumer) das Stoppsignal gesendet. Dieses Signal bedeutet ihnen, die restlichen Events, welche ihnen zur Verfügung stehen, abzuarbeiten und anschlieÿend zurück zu melden. Diese Rückmeldung ist notwendig, weil von auÿen nicht bewertet werden kann, wann eine Bearbeitung beendet ist. Haben alle Komponenten ihre aktuellen Aufgaben erledigt und die dabei unter Umständen anfallenden Events in die Channels gegeben, ist nach endlicher Zeit ein Zustand erreicht, in dem nur noch die Channels Events in ihrer Queue vorhalten. Somit muss der Zustand der einzelnen Channels in dem Sinne persistiert werden, als dass die Events gespeichert werden, welche sie noch zustellen sollen. Die einzigen Komponenten, deren Zustände auÿerdem gesichert werden müssen, sind die Agenten. Diese stützen sich bei der Verarbeitung von Events typischerweise auf eine Rule Engine, welche eine Faktenbasis hält. Diese Faktenbasis besteht aus Events, welche in der Vergangenheit von dem Agenten empfangen wurden. Abhängig von den Regeln, welche von der Rule Engine genutzt werden, werden alte Events vorgehalten, da sie für die Bewertung aktueller Events benötigt werden. Für dieses Szenario soll angenommen werden, dass der Zustand der Rule Engine und damit die Faktenbasis gespeichert werden können. Seite 43

49 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.3. CEP auf mobilen Geräten Ist der beschriebene Zustand erreicht, können die Daten der einzelnen Channels und Agenten gesichert werden. Abschlieÿend wird der Aufbau des Netzwerks persistiert. Dazu werden die beteiligten Komponenten und die Verknüpfungen zwischen ihnen gespeichert. Wiederherstellung des Zustands Die Wiederherstellung des Zustands, der zum Zeitpunkt der Beendigung des EPNs vorhanden war, verläuft recht einfach. Zuerst wird das Netzwerk so initialisiert, wie es gespeichert wurde. Dazu werden alle Komponenten gestartet, die zuvor aktiv waren. Diese Komponenten werden dann durch die Channels erneut so vernetzt, dass die ursprüngliche Topologie wieder vorhanden ist. Anschlieÿend werden die Komponenten, die beim Beenden Daten zum Speichern bereit gestellt haben (der eigentliche Zustand der Komponenten in Form von Events) wieder mit den Daten versorgt. Hiernach ist das Netzwerk wieder in dem Zustand, wie es beendet wurde. Probleme bei der Wiederherstellung Auch wenn der Zustand nach der Wiederherstellung augenscheinlich derselbe ist, wie beim Speichern des EPN, tun sich dennoch Probleme auf. Das erste Problem, welches benannt werden muss, tritt schon in der Phase auf, in der die Channels die Events nicht mehr an die Empfänger weiter geben, sondern sie in einer Queue speichern. Die Abstände, in denen die Events normalerweise an die Empfänger weitergeleitet werden, können stark variieren. Werden die eingehenden Events jedoch in eine Queue geschrieben, so werden diese natürlichen Abstände zwischen den Events normalisiert. Wenn beim Wiederherstellen die Events gebündelt an die Empfänger weiter gegeben werden, kann dies insofern zu Problemen führen, dass unter Umständen einige Regeln nicht mehr zutreen. Auch stimmen die Zeitstempel der Events nicht mehr mit dem eigentlichen Eventuss überein. Dies bedeutet, dass ein Event statt wenige Millisekunden nach seiner Erstellung z.b. erst Sekunden danach zugestellt werden kann. Für die empfangene Komponente kann jedoch nicht nachvollzogen werden, woher diese Verzögerung stammt. Je nach Implementierung der Empfänger kann es so zu anderen Ergebnissen oder Aktionen führen, als wenn die Events gleich weitergegeben worden wären. Ein ähnliches Problem wird auf Abbildung 3.11 deutlich. Wird das Netzwerk in diesem Zustand nach dem oben beschriebenen Muster gespeichert, dann wird das Event vom Typ 1 in Agent 3 als Faktenbasis gespeichert. Hier besteht der Zusammenhang darin, dass der Agent das Event speichert, um sehen zu können, ob innerhalb von 10 Sekunden ein Event vom Typ 2 folgt. Das zweite Event, vom Typ 2, bendet sich gerade in der Bearbeitung durch Agent 2, der es mit weiteren Informationen anreichert. Der Agent gibt das Event danach in den Channel, der die beiden Agenten verbindet. Hier wird es jedoch nicht mehr zugestellt, an dieser Stellen hat das Netzwerk seinen stabilen Zustand erreicht und wird gespeichert. Wenn das Netzwerk neu aufgebaut wird, wird das Event vom Typ 2 an Agent 3 übermittelt. Hier ergibt sich folgendes Problem: Wurde das Event vom Typ 2 innerhalb von 10 Sekunden empfangen, nachdem das Event vom Typ 1 empfangen wurde? Wird innerhalb der Regel nach den Zeitstempeln der Events geurteilt, dann wird das Ergebnis weiterhin das erwartete sein. Wird allerdings die Zeit als Referenz genommen, Seite 44

50 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.3. CEP auf mobilen Geräten Abbildung 3.11: Beispiel eines Event Processing Networks auf einem mobilen Endgerät (Schnappschuss 2) zu der die Events in die Faktenbasis eingepegt werden, so wird die Regel unter Umständen nicht mehr greifen. Das Verhalten ist dabei alleine abhängig von der Implementierung der Rule Engine bzw. der Ausgestaltung der Regel. Die dritte Problematik, die sich zeigt, ist die der Wiederherstellung des Zustands der Agenten. Vereinfachend wurde angenommen, dass auch der Zustand der im Agenten betriebenen Rule Engine gespeichert werden kann, indem die Faktenbasis gesichert wird. Diese Faktenbasis, bestehend aus Events, wird nun nach der erneuten Initialisierung des Agenten zurück in die Rule Engine gegeben. Abgesehen von den genannten Problemen, welche unter Umständen durch vorzugebende Richtlinien, Sorgfalt und Fehlertoleranz bei der Erstellung der Regeln umgangen werden können, bleibt noch folgende Frage zu klären: Complex Event Processing wird für die Verarbeitung von Ereignissen in Echtzeit eingesetzt. Wenn ein EPN in einem bestimmten Zustand, also inklusive aller momentan vorhandenen Events, gespeichert und zu einem späteren Zeitpunkt wieder aktiviert wird, handelt es sich dann noch um Echtzeitverarbeitung? Zusammenfassung und Bewertung Die Erkenntnisse, welche in den letzten Abschnitten gewonnen werden konnten, haben deutlich werden lassen, dass eine Speicherung des EPNs und somit der CEP-Umgebung auf dem mobilen Endgerät weder realisierbar noch sinnvoll ist. Die Realisierbarkeit wird durch den Umstand der komplexen Auslegung der Agenten eingeschränkt. Da diese die eigentliche Logik des Systems beinhalten, können sie beliebig komplex implementiert werden. Hier ein allgemein gültiges Verfahren zu nden, wie der Zustand der Agenten gespeichert und wiederhergestellt werden kann, stellt sich als Herausforderung dar. Besonders schwerwiegend ist dabei, dass in einem Agenten typischerweise Software von Drittanbietern zur Regelauswertung genutzt wird. Somit muss also auch diese Software in einen Zustand gebracht werden, der es erlaubt, gespeichert und wiederhergestellt zu werden. Selbst wenn die technischen Probleme lösbar sind, so bleiben immer noch die Bedenken hin- Seite 45

51 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.3. CEP auf mobilen Geräten sichtlich des Anspruchs auf Echtzeitverarbeitung und der Problematik der verschobenen Zeitstempel der Events, welche zu Fehlern in der Verarbeitung führen können. Dem ist nur abzuhelfen, indem wiederum in der Implementierung der einzelnen Agenten, speziell in den aufgestellten Regeln zur Verarbeitung, auf diesen Umstand Rücksicht genommen wird und auf den Anspruch einer wirklichen Echtzeitverarbeitung verzichtet wird. Wird auf den Anspruch verzichtet, stellt sich jedoch die Frage, inwieweit laut Denition noch von einer CEP-Umgebung gesprochen werden darf, da Echtzeitverarbeitung eines der essentiellen Merkmale einer solchen Umgebung ist. Der einzige Punkt, der sowohl umsetzbar als auch sinnvoll ist, ist die Speicherung der beteiligten Komponenten und deren Topologie des EPN. So kann beim Wiederherstellen das Netzwerk in der Ausprägung erstellt werden, die es vor dem Beenden hatte Rule Engines für mobile Plattformen Ein Agent nutzt typischerweise eine Regelmaschine oder Rule Engine zur Verarbeitung der eingehenden Events. Diese Rule Engine ermöglicht es, dass für die Verarbeitung der Events Regeln aufgestellt werden, die dann auf den eingehenden Eventstrom angewendet werden. Eine Regel besteht dabei typischerweise aus einer linken und einer rechten Seite, die auch als Condition und Action bezeichnet werden können. Trit eine bestimmte Bedingung zu (Condition), so führe eine denierte Aktion aus (Action). Die linke Seite wird beim Einsatz in einem Agenten genutzt, um bestimmte Muster im eingehenden Eventstrom zu nden. Werden diese Muster erkannt, dann wird die entsprechende rechte Seite der Regel ausgeführt. Abhängig von der gewählten Implementierung einer Rule Engine unterscheiden sich die Sprachen, in denen die Regeln ausgedrückt werden. Ebenso unterscheiden sich die Möglichkeiten, insbesondere im Bereich der Conditions, welche einem Entwickler für die Regelerstellung zur Verfügung gestellt werden. So ist es zum Beispiel nicht jeder Rule Engine möglich, explizit bestimmte Zeitfenster für die Betrachtung von Events zu benutzen. Es existieren eine Vielzahl Implementierung von Rule Engines, sowohl quelloen als auch proprietär. Für eine Vielzahl von Programmiersprachen stehen solche Lösungen zur Verfügung, wie z.b. für Java 8 9, C 10, Objective-C 11, Ruby und auch.net Leider lassen sich zur Zeit aber noch keine Implementierungen nden, die explizit für mobile Plattformen entwickelt wurden. Für die Verwendung auf einer mobilen Plattform können somit lediglich die Implementierungen für Standardumgebungen in Betracht gezogen werden. Dabei muss im ersten Schritt darauf geachtet werden, dass nur die Umsetzungen in Frage kommen, die in der jeweiligen Programmiersprache entwickelt wurde, in welcher auch die Applikationen für die mobile Plattform geschrieben werden müssen. Andere Implementierungen lassen sich schwer bis gar nicht in eine Applikation 8 - abgerufen am abgerufen am abgerufen am abgerufen am abgerufen am https://github.com/codeaspects/ruleby - abgerufen am abgerufen am abgerufen am Seite 46

52 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.3. CEP auf mobilen Geräten einbinden, die auf der Plattform betrieben werden soll. Ist eine Lösung in der korrekten Programmiersprache gefunden, so ist allerdings noch nicht sichergestellt, dass diese Lösung auch auf der mobilen Plattform einsetzbar ist. Die Software Development Kits und Bibliotheken, die zur Programmierung einer Applikation für eine mobile Plattform zur Verfügung stehen, beinhalten nicht zwingend alle benötigten Bibliotheken und Funktionen, die von den Rule Engine Implementierungen genutzt werden. Auf diesen Umstand wird zum Beispiel im Dev Guide für Android Entwickler[9] hingewiesen: Android includes a set of core libraries that provides most of the functionality available in the core libraries of the Java programming language. Auch andere Einschränkungen, wie zum Beispiel das Fehlen der Möglichkeit, zur Laufzeit ausführbaren Code zu generieren, sind denkbar. Daher muss eine in Betracht gezogene Rule Engine vor dem Einsatz darauf getestet werden, ob sie auf der einzusetzenden Plattform überhaupt funktioniert. In den folgenden Abschnitten werden exemplarisch zwei verschiedene Rule Engines für den Einsatz auf Google Android betrachtet. Es handelt sich dabei um JBoss Drools und Esper, welche jeweils in Java implementiert sind (s.o.). JBoss Drools Bei Drools handelt es sich um eine quelloene Implementierung einer Rule Engine, die seit 2001 entwickelt wird. Seit Version 5.0 verfügt Drools über zusätzliche Funktionalität, welche speziell für die Belange einer Regelverarbeitung in CEP-Umgebungen ausgelegt ist und im Paket Fusion zur Verfügung steht 16. Drools übersetzt die in Klartextdateien zur Verfügung gestellten Regeln zur Laufzeit in ausführbaren Java-Code[15]. In einer Diskussion um eine Portierung von Drools auf die Android- Plattform auf der Entwickler-Mailingliste wurde dieses Verhalten als Hauptproblem für die Portierung gesehen. Das System Android setzt auf eine selbst entwickelte, virtuelle Maschine, die Dalvik VM. Diese führt keinen Java-Bytecode auf dem Gerät aus, sondern Dateien im Dalvik Executable Format (.dex). Die dex-dateien werden mit Hilfe des dx-tool s bei der Kompilierung einer Anwendung aus den Java-.class-Dateien generiert. Eine Generierung von.dex-dateien zur Laufzeit einer Anwendung auf dem mobilen Endgerät ist von den Entwicklern bisher nicht umgesetzt worden. Es besteht jedoch Möglichkeiten, über Umwege den benötigten, ausführbaren Code zu erhalten. Die Möglichkeiten werden im Folgenden kurz vorgestellt abgerufen am Seite 47

53 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.3. CEP auf mobilen Geräten Erzeugen des Codes auÿerhalb der Dalvik VM Die erste Möglichkeit ist zwar die performantere, aber es handelt sich auch um die weniger dynamische. Hierbei wird das Programm, welches zur Laufzeit den Code erzeugen möchte, zunächst in einer Standardumgebung, also unter Nutzung einer herkömmlichen Java VM, ausgeführt. Die dann zur Laufzeit generierten.class-dateien werden gesichert und mit dem dx-tool in.dex-dateien umgewandelt. Diese können nun mit der Software gemeinsam ausgeliefert und auf dem mobilen Endgerät ausgeführt werden. Dazu muss die Software natürlich entsprechend erst nach den vorhandenen Klassen suchen, bevor sie sie generiert. In diesem Fall würde sie die fertig vorkompilierten Klassen nden und sie so nicht mehr auf der mobilen Plattform generieren wollen. Dieser Ansatz lässt sich zum Beispiel auch durch die Verwendung des Hammurapi Event Bus 17 verfolgen. Dabei werden durch Annotationen zur Kompilierzeit Klassen erzeugt, die dann im fertigen Paket genutzt werden. Regeln können allerdings ausschlieÿlich über Annotationen, und nicht in separaten Dateien, deniert werden. Erzeugen des Codes zur Laufzeit in der Dalvik VM Die zweite Möglichkeit ist weniger aufwändig, dafür aber bei weitem nicht so performant wie die erste. Der Ansatz beruht auf der normalen Generierung von Java-.class-Dateien zur Laufzeit auf der mobilen Plattform. Die entstehenden Dateien werden dann durch den Aufruf des dx-tool s aus der Anwendung selbst heraus in das Dalvik Executable Format umgewandelt. Die fehlende Performanz durch den Aufruf des Tools aus der Applikation heraus fällt jedoch kaum ins Gewicht, wenn nicht mit hoher Frequenz Code generiert werden muss. Die entstehenden.dex-dateien können zur Laufzeit mit Hilfe der Klasse DexClassLoader geladen werden. Mit diesen Ansätzen wäre es möglich, das angesprochene Problem auf der Mailingliste der Entwickler zu lösen. Wie sich durch den Versuch eines Mitgliedes der User-Mailingliste jedoch zeigt, muss die Generierung von ausführbarem Code nicht zwingend das gröÿte Problem sein. In der Diskussion 18 auf der Mailingliste ist zu verfolgen, dass der Versuch des Users an einer anderen Hürde scheiterte. Zunächst wird beschrieben, dass einige Stellen im Quellcode von Drools geändert werden mussten, um fehlerhafte Aufrufe in der Android- Umgebung zu vermeiden. Zudem musste das Java-Package java.beans, welches in der Android- Umgebung nicht zur Verfügung steht, mit einem Paket vom Apache Harmony Projekt 19 zur Verfügung gestellt werden. Abschlieÿend wurde noch ein weiterer Fehler gefunden, der in der Methode zur Kompilierung der Regeln auftauchte. Schlieÿlich kann aber nicht gesagt werden, ob die Kompilierung nach der Fehlerbehebung fehlerfrei funktioniert, da im weiteren Verlauf der Entwicklung ein weiterer Fehler auftauchte. Dieser Fehler, der nicht mehr gefunden und behoben werden konnte, ist ein Speicherleck, welches die Applikation mit Regelmäÿigkeit abstürzen lässt, abgerufen am abgerufen am abgerufen am Seite 48

54 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.3. CEP auf mobilen Geräten wenn Drools initialisiert wird. Er tritt zu dem Zeitpunkt auf, an dem die Regeln generiert werden, lieÿ sich aber von dem Entwickler nicht weiter eingrenzen. Insgesamt kann festgestellt werden, dass zur Zeit keine Version von Drools auf einem auf Android basierendem, mobilen Endgerät eingesetzt werden kann. Durch aufwändige Änderungen am Quellcode von Drools ist es möglich, nach und nach die auftretenden Fehler zu beheben, ob jedoch alle Fehler gefunden und beseitig werden können, wäre zu prüfen. Esper Esper ist eine quelloene Software, welche seit 2006 für die Verarbeitung von Events im Rahmen einer Complex Event Processing Lösung entwickelt wird. Seit 2007 wird Esper auÿer für Java auch für.net-umgebungen unter dem Namen NEsper zum Download angeboten. Auch Esper generiert zur Laufzeit Bytecode, mit dessen Hilfe schneller auf Attribute von Objekten zugegrien werden kann[7]. Ebenso wie bei Drools sind die Bestrebungen, Esper auch auf einer Android-basierten Plattform betreiben zu können, nicht neu. So ist auf der Esper Mailingliste der Entwickler Ende 2010 zu lesen 20, dass sich ein Entwickler mit der Portierung auf Android auseinander setzt. Dieses Vorhaben scheitert zunächst an einem Fehler in der Laufzeitumgebung, welcher von den Android-Entwicklern inzwischen behoben wurde. Abschlieÿend gelingt die Portierung, indem bestimmte Quellcodeabschnitte aus Esper entfernt werden, die für Unverträglichkeiten mit der Android-Laufzeitumgebung sorgen. Im Speziellen wurde Code entfernt, der auf die Bytecodegenerierung angewiesen ist. Durch diesen Schritt entstand eine auf Android lauähige Portierung von Esper 3.2, die unter heruntergeladen werden kann. Es ist allerdings anzumerken, dass die portierte Version im Vergleich zu der originalen Version 3.2 von Esper einige Einschränkungen mit sich bringt. Welche Einschränkungen dies im Details sind, lässt sich auf der Projektseite nachlesen. Zusammenfassend kann festgestellt werden, dass es zumindest eine Version von Esper gibt, die auf Android einsetzbar ist. Version 3.2, auf der die Portierung beruht, ist nicht mehr die aktuellste Version von Esper, welches inzwischen dev Versionsstand 4.3 erreicht hat. Soll demnach eine neuere Version genutzt werden, so müsste diese erneut portiert werden. Regelbasierte Anwendungen Neben den in Abschnitt angesprochenen Applikationen gibt es eine groÿe Anzahl weiterer Anwendungen, die Regeln in ihrer Logik beinhalten. Ein Beispiel für eine solche Anwendung, die nicht nur regelbasierte Abläufe beinhaltet, sondern sogar für den Einsatz von CEP zur Verarbeitung prädestiniert scheint, ist die Jigsaw Continuous Sensing Engine, welche in [12] vorgestellt wird. Auch in anderen Projekten, die, wie die Jigsaw Continuous Sensing Engine verschiedene Sensoren von mobilen Geräten abfragen, um aus den Werten Aussagen über den Zustand des Geräts treen zu können, wäre ein Einsatz von CEP oder zumindest Rule Engines denkbar. Ein Beispiel für solch ein Projekt wird in [8] vorgestellt, weitere Beispiele lassen sich in [11] nden abgerufen am Seite 49

55 Kapitel 3. Analyse der Integrationsmöglichkeiten 3.3. CEP auf mobilen Geräten Zusammenfassung der Erkenntnisse Wie eingangs beschrieben, wurden in diesem Abschnitt die zwei Einussfaktoren auf eine Event- Verarbeitung auf mobilen Plattformen näher beleuchtet. Generell kann dabei festgehalten werden, dass eine derartige Verarbeitung auf einer mobilen Plattform möglich ist. Im Detail können folgende Aussagen getroen werden: Lebenszyklus der Applikation Die Anwendung, welche das EPN beherbergt, kann nicht so geplant werden, als dass sie vom Starten durch den Benutzer bis zum Beenden durch den Benutzer durchgehend aktiv ist. Das heiÿt, es muss damit gerechnet werden, dass die Applikation und damit das EPN zwischenzeitlich vom System beendet und wieder gestartet wird. Dieser Umstand bedeutet aber keinesfalls das Aus für eine Event-Verarbeitung auf dem mobilen System. Die Lebensdauer einer Applikation lässt sich auf den gängigen Geräten durchaus dahingehend beeinussen, dass eine Anwendung nur mit einer geringen Wahrscheinlichkeit beendet wird. So ist es z.b. sehr unwahrscheinlich, dass eine Anwendung, die im Vordergrund auf dem Gerät läuft, vom Betriebssystem zur Freigabe von Ressourcen gestoppt wird. Selbstverständlich muss diese Möglichkeit der vorzeitigen Beendigung und des erneuten Startens der Applikation dennoch bei der Planung und Umsetzung der Anwendung berücksichtigt werden. Dabei muss jedoch im Detail betrachtet werden, welche Daten eine Anwendung nach einem erneuten Start tatsächlich benötigt, und welche obsolet sind und dementsprechend verworfen werden können. Wie auch die Beispiele gezeigt haben, ist zum Beispiel eine Sicherung der aktuell im System bendlichen Events nicht unbedingt sinnvoll und zielführend. Um die Beeinträchtigung durch die Beeinussung des Lebenszyklusses zu minimieren, bietet es sich auf jeden Fall an, nach Möglichkeit nur kurzlebige Regeln auf dem mobilen Endgerät zu verwenden. Lange laufende Regeln, die z.b. über Zeitfenster von mehreren Tagen eingehende Events betrachten, sollten besser auf ein stationäres System ausgelagert werden. Bei einer vorzeitigen Beendigung der Anwendung auf dem mobilen Endgerät bietet es sich unter Umständen an, das Backend über dieses Ereignis zu informieren. Ist die Anwendung auf dem mobilen Gerät z.b. Teil einer Sicherheitslösung, so könnten durch eine Beendigung der Anwendung auf dem mobilen Gerät unter Umständen sicherheitskritische Maÿnahmen notwendig werden. Diese Maÿnahmen könnten möglicherweise der Ausschluss des mobilen Endgeräts aus einem Firmeninternen Netzwerk bedeuten. Verfügbarkeit von Rule Engines Durch die Aufzählung wurde deutlich, dass es eine Vielzahl an Implementierungen von Rule Engines gibt. Bedauerlicherweise gibt es derzeit keine Lösung, die explizit für mobile Plattformen bestimmt ist. Daher müssen Kandidaten, die zumindest schon einmal in der richtigen Programmiersprache geschrieben sind, auf ihre Tauglichkeit geprüft werden. Teilweise können bestehende Implementierungen mit relativ wenig Aufwand so manipuliert werden, dass sie auf mobilen Systemen einsetzbar sind. Seite 50

56 4 Konzept einer CEP-Umgebung für ein mobiles Endgerät In diesem Kapitel wird das Konzept zur Erstellung einer CEP-Umgebung erarbeitet, welche auf einem mobilen Endgerät eingesetzt werden kann. Dabei wird von einer späteren Umsetzung in einer objektorientierten Programmiersprache ausgegangen. Davon abgesehen werden keine Ansprüche an die Umgebung gestellt, in der das Konzept später umgesetzt werden können soll. Dieser Umstand ist damit zu begründen, dass ein Konzept entworfen werden soll, welches auf unterschiedlichen, mobilen Plattformen eingesetzt werden kann. Es wird bei der Erstellung des Konzepts darauf geachtet, dass so viele Anforderungen aus 3.2 umgesetzt werden, wie durch konzeptuelle Entscheidungen umgesetzt werden können. Sollten Anforderungen erst durch die konkrete Implementierung umgesetzt werden können, so wird an passender Stelle auf diesen Umstand hingewiesen. Zur Gliederung dieses Kapitels: Anfangs wird das Grundkonzept zur Umsetzung einer CEP- Lösung geschildert. Anschlieÿend wird auf die einzelnen Komponenten näher eingegangen. Schlieÿlich werden technische Umsetzungsmöglichkeiten hinsichtlich der Kommunikation zwischen dem mobilen Endgerät und anderen Systemen eingehend betrachtet. Dabei wird sowohl auf das mögliche Datenformat als auch auf die technische Umsetzung der Übertragung der Daten eingegangen. 4.1 Das Grundkonzept - wie werden die Elemente einer CEP-Umgebung abgebildet Zunächst muss festgelegt werden, wie die einzelnen Elemente der CEP-Umgebung dargestellt werden können. Mit den Elementen sind die bisher viel diskutierten Komponenten, also Quellen, Channels, Agenten und Consumer aber auch die Events an sich gemeint Die Events Ein wesentlicher Bestandteil einer Complex Event Processing Umgebung sind die Events, die erzeugt und verarbeitet werden. Wie in Abschnitt erläutert, gibt es dabei unterschiedliche Arten von Events, die über unterschiedliche Bedeutungen verfügen und unterschiedliche Daten mit sich führen. Allen gemeinsam ist lediglich ihr Dasein als Event. Vor allem beim Austausch der Events zwischen den Komponenten soll eine einheitliche Behandlung aller unterschiedlichen Seite 51

57 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.2. Details der Einzelkomponenten Event-Typen möglich sein. Dazu benötigen alle Events ein Erscheinungsbild, welches von auÿen den eigentlichen Typ des Events verbirgt und es einfach nur als generelles Event erscheinen lässt. Da alle Events zumindest eine eindeutige ID und einen Zeitstempel tragen, bietet es sich an, eine abstrakte Klasse Event zu entwerfen. Diese Klasse stellt die beiden auf jeden Fall benötigten Felder zur Verfügung. Alle weiteren, benötigten Event-Typen erben von der Klasse Event und können somit beim Austausch zwischen verschiedenen Komponenten als Instanz vom Typ Event durchgehen gleich behandelt werden. Jeder Event-Typ dient als Container für die jeweiligen Daten, die ein Event des entsprechenden Typs mit sich führen muss. Dieses einfache Konzept für die Darstellung der unterschiedlichen Event-Typen wird auf Abbildung 4.1 in einem vereinfachten UML-Diagramm dargestellt. Abbildung 4.1: UML-Darstellung: Die Klasse Event mit Unterklassen Quellen, Channels, Agenten und Consumer Jede der Komponenten Quelle, Channel, Agent und Consumer wird im ersten Schritt durch eine jeweilige Klasse dargestellt. Somit kann eine klare Abbildung einer CEP-Umgebung erreicht werden. Die Aufgaben der einzelnen Komponenten sind auf diese Art und Weise klar einfach trennbar. Auÿerdem lässt sich durch diese Wahl der Darstellung ein Event-Processing Netzwerk einfach vorstellen und gestalten. Somit folgen der Klasse Event, welche oben eingeführt wurde, noch die Klassen Source, Channel, Agent und Consumer. Auch diese werden als abstrakte Klassen deniert, um die einzelnen Ausprägungen bei der Implementierung einheitlich benutzen zu können. 4.2 Details der Einzelkomponenten Nach einer groben Vorstellung, welche Klassen prinzipiell für die Umsetzung der CEP-Umgebung benötigt werden und wie das EPN von auÿen erstellt und gewartet werden kann, folgen nun Details für das Konzept. Die einzelnen Komponenten werden im Folgenden genau betrachtet, sodass am Ende auch das Zusammenspiel der einzelnen Komponenten deutlich wird. An dieser Stelle wird auch auf die Anforderungen an die einzelnen Komponenten eingegangen, die in Abschnitt 3.2 deniert worden sind. Seite 52

58 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.2. Details der Einzelkomponenten Agenten Die Agenten werden durch die abstrakte Klasse Agent dargestellt. Seine Aufgabe ist der Empfang von Events, deren Verarbeitung und anschlieÿendes Senden von Events zurück in das Event Processing Network. Zur Erfüllung dieser Aufgaben benötigt der Agent Verbindungen mit dem Netzwerk, über die er Events empfangen und versenden kann. Um eine möglichst lose Kopplung zwischen Agenten und Channels zu erreichen, ist dem Agenten nur ein einziger Channel bekannt. Dabei handelt es sich um den Channel, mit dessen Hilfe er die Ergebnisse seiner Verarbeitung in Form von Events verschickt. Die Entscheidung eines einzelnen Ausgangskanals ist damit zu begründen, dass nur so die Kontrolle über den Fluss von Events innerhalb des Netzwerks in der Hand des Netzwerkdesigners verbleibt. Würden dem Agenten mehrere Ausgangskanäle zur Verfügung stehen, dann könnten die Ergebnisse der Verarbeitung in einen beliebigen dieser Kanäle gegeben werden. Damit würde die Kompetenz des Agenten überschritten werden, da er so in der Lage wäre, den Eventuss innerhalb des Netzwerks zu ändern und den Aufbau des gesamten Netzwerks damit in Frage zu stellen. Zudem ergäbe sich die Problematik, dass der Entwurf des Netzwerks mit seinen Beteiligten Komponenten abhängig von Regeln in den einzelnen Agenten wäre. Um hier eine klare Trennung zu erzwingen, wird dem Agenten also nur ein Channel zur Ausgabe zur Verfügung gestellt. Um Events erhalten zu können, stellt der Agent eine Methode zur Verfügung, über die die Events an den Agenten übergeben werden können. Diese Methode wird von den Channels genutzt, die dem Agenten Events ausliefern wollen. Die Kommunikation mit Hilfe der Channels wird in Abschnitt noch eingehender betrachtet. Die eigentliche Verarbeitung der eingehenden Events wird typischerweise mit Hilfe einer Rule Engine vorgenommen. Da sich nicht festlegen lässt, welche Implementierung einer Rule Engine zum Einsatz kommen und ob es sich überhaupt um eine Rule Engine handeln wird, kann der Verarbeitungsschritt nicht generalisiert in das Konzept aufgenommen werden. Fest steht lediglich, dass die Events innerhalb des Agenten verarbeitet werden. Wie genau dies passiert, muss in der Implementierung festgelegt werden. Die Erstellung neuer Agenten mit jeweils abweichender Verarbeitung von Events ist durch die Verwendung von Vererbung einfach realisierbar. Das Netzwerk an sich kennt als Komponente dabei lediglich die Klasse Agent, die sich von auÿen gesehen immer gleich verhält. Abbildung 4.2: UML-Darstellung: Die Klasse Agent Die Oberklasse aller unterschiedlichen Agenten ist auf Abbildung 4.2 zu sehen. Auÿer der Methode zum Empfang von Events und dem Ausgangs-Channel ist die Methode teardown() erkennbar. Diese Hook-Methode wird zur Verfügung gestellt, um den Implementierungen die Möglichkeit zu geben, für eine ordentliche Freigabe von Ressourcen zu sorgen, bevor eine Instanz Seite 53

59 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.2. Details der Einzelkomponenten beendet wird. Die Methode muss nicht implementiert werden, die Standard-Implementierung innerhalb der Klasse Agent ist jedoch leer Consumer Auch bei den Consumern handelt es sich um Komponenten, die aus Sicht des EPN alle das gleiche Verhalten zeigen. Sie werden durch die Klasse Consumer realisiert dargestellt. Ebenso wie die Agenten, werden einem Consumer über Channels Events zugesandt. Diese Events führen dann zu Aktionen, die die Consumer ausführen. Der eigentliche Unterschied zu einem Agenten besteht lediglich darin, dass ein Consumer keine neuen Events als Ergebnis einer Bearbeitung in das EPN einspeist. Damit verbleibt die Methode, welche zum Zustellen von Events genutzt wird. Weitere, generelle Verhaltensweisen sind einem Consumer nicht zuzuschreiben. Damit ist das Konzept an dieser Stelle schnell erschöpft: Ein Consumer benötigt lediglich eine Methode, über die die Events zugestellt werden können. Diese Events kommen dabei aus einem oder mehreren Channeln, welche dem Consumer aber (ebenso wie dem Agenten) nicht bekannt sein müssen. Wenn man die Klassen Agent und Consumer vergleicht, dann stellt man fest, dass das Merkmal kann Events von einem Channel zugestellt bekommen identisch ist. Somit können Agenten als spezielle Art Consumer verstanden werden. Durch diesen Schluss kann das Konzept abgeändert werden: Ein Consumer wird lediglich durch ein Interface dargestellt, welches die Methode zum Übermitteln von Events zur Verfügung stellt. In einem UML-Diagramm lässt sich die geänderte Situation wie auf Abbildung 4.3 gezeigt darstellen. Abbildung 4.3: UML-Darstellung: Das Consumer Interface Die Anforderungen, welche im Abschnitt 3.2 für einen Consumer deniert wurden, lassen sich mit dem gezeigtem Konzept erfüllen. Durch die Implementierung des Interfaces lassen sich einfach neue Consumer programmieren. Deren Verhalten ist abhängig von deren Aufgabe und der mobilen Plattform, auf der sie eingesetzt werden sollen und damit implementierungsabhängig Event-Quellen Die Event-Quellen sind mit den Consumern die einzigen Komponenten, deren Aufgabe teilweise nur durch die Verwendung plattformspezischer Bibliotheken oder Funktionen erfüllt werden kann. Damit fällt eine Generalisierung schwer. Alle Event-Quellen haben jedoch gemeinsam, dass sie Events generieren und diese dann in einen Ausgabe-Channel geben. Wie genau die Events generiert werden, ist wie erwähnt, abhängig von der Plattform, auf der sie zum Einsatz kommen Seite 54

60 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.2. Details der Einzelkomponenten sollen und auf welche Art die umzusetzenden Ereignisse die Quellen erreichen. So kann es sein, dass eine Quelle erst beim Betriebssystem registriert werden muss, aber das ist nicht immer der Fall. Soll sie zum Beispiel intern in einer Anwendung verwendet werden und lauscht auf somit auf anwendungsinterne Ereignisse, oder liest z.b. dauerhaft eine Logdatei mit, dann ist eine solche Registrierung nicht unbedingt notwendig. Eine Event-Quelle zeichnet sich somit lediglich durch einen Ausgabe-Channel aus. Die entsprechende Klasse macht entsprechend einen eher unspektakulären Eindruck, wie Abbildung 4.4 zu entnehmen ist. Die Methode emitevent(event e) dient lediglich der Kapselung des Vorgangs, der zum Übermitteln eines Events an den Ausgabe-Channel dient. Abbildung 4.4: UML-Darstellung: Die Klasse Source Channels Das verbindende Element zwischen den einzelnen Komponenten des Event Processing Networks ist der Channel. Wie die anderen Komponenten auch, wird der Channel durch eine eigene Klasse dargestellt. Diese trägt, wie anfangs erwähnt, den Namen Channel. Die Aufgabe eines Channels besteht alleinig aus der Übermittlung von Events. Die zu übermittelnden Events werden in den Channel gegeben und dieser sorgt dafür, dass alle Komponenten, die an den Channel angeschlossen sind, die Events zugestellt bekommen. Für die Erfüllung dieser Aufgabe stellt die Klasse Channelsource eine Methode nach auÿen zur Verfügung, über die Events in den Channel gegeben werden können. Alle Komponenten, die an Events aus dem speziellen Channel interessiert sind, müssen auf diesem als Empfänger registriert werden. Bei diesen Komponenten handelt es sich Instanzen der Klasse Agent sowie um andere Klassen, die das Consumer-Interface implementieren. Andere Komponenten bekommen keine Events aus einem Channel heraus zugestellt. Für den Channel bedeutet das, dass er ausschlieÿlich auf dem Interface Consumer operieren kann. Den Ablauf beim Eintreen eines Ereignisses ist auf Abbildung 4.5 mit Hilfe eines Sequenzdiagramms dargestellt. Das eingehende Event wird an alle registrierten Empfänger weitergegeben, indem deren Callback-Methode onevent(event e) aufgerufen wird. Auf dem Diagramm 4.5 ist zu erkennen, dass die Event-Source so lange blockiert, bis der Channel das Ereignis an alle seine Empfänger zugestellt hat. Es handelt sich bei den Aufrufen der Methode onevent(event e) jedoch prinzipiell um blockierende Aufrufe. Das bedeutet, dass der Channel und damit auch die Komponente, die das Event in den Channel gegeben hat, so lange blockiert, bis das Event komplett verarbeitet worden ist. Lösungsansätze für dieses Problems werden in Abschnitt diskutiert. Die Registrierung eines Consumer wird über die entsprechende Methode registerconsumer(consumer c) angestoÿen. Damit die einzelnen Komponenten des EPN so wenig wie möglich voneinander wissen, wird diese Registrierung von auÿen vorgenommen. Das bedeutet, dass z.b. einem Agent Seite 55

61 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.2. Details der Einzelkomponenten Abbildung 4.5: Ablauf beim Eintreen eines Events in einem Channel nicht seine Eingangskanäle bekannt gemacht werden und er sich darauf registriert. Stattdessen wird an der Stelle, an der ein Agent instanziiert wird, dieser auch gleich in den entsprechenden Channels bekannt gemacht, aus denen er Events erhalten soll. Ähnlich der Registrierung von einem Consumer funktioniert auch das Entfernen eines bereits registrierten Consumers aus dem Channel. Soll eine Komponente aus dem Netzwerk entfernt werden, so muss sie zunächst aus allen Channeln entfernt werden, welche ihr Events zuspielen. Zu diesem Zweck verfügt der Channel über die Methode unregisterconsumer(consumer c), die den Consumer als Argument entgegen nimmt, welcher entfernt werden soll. Wie aus den Inhalten von Kapitel 3 entnommen werden kann, werden zumindest zwei unterschiedliche Channel benötigt. Der eine dient ausschlieÿlich der internen Kommunikation, d.h. während der andere Events auch nach auÿerhalb der mobilen Plattform propagiert. Alleine bei der internen Kommunikation kann aber auch wieder unterschieden werden zwischen applikationsinterner Kommunikation und z.b. Interprozesskommunikation, wenn diese von der Plattform unterstützt wird. Abbildung 4.6: UML-Darstellung: Die Klasse Channel Alle diese Ausprägungen haben lediglich gemeinsam, dass sie über Methoden zum Empfangen von Events und zum Registrieren und Entfernen von Consumern verfügen. Die erforderlichen Felder und Methoden können in der abstrakten Klasse Channel zur Verfügung gestellt und implementiert werden. Die somit entstehende Klasse ist auf Abbildung 4.6 in UML-Notation zu sehen. Seite 56

62 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.2. Details der Einzelkomponenten Die Anforderungen an den Channel (vgl ) werden durch diesen Ansatz gut abgedeckt. Was jedoch noch fehlt ist die Möglichkeit, die einzelnen Instanzen der Channel-Klassen anhand eines eindeutigen Namens zu identizieren. Hierfür wird ein Mapping zwischen Namen und Instanzen benötigt. Das Konzept zur Lösung dieses Problems wird in Abschnitt vorgestellt. Die weiteren Anforderungen betreen den extern nutzbaren Channel. Dieser soll die eingehenden Events zusätzlich zu den registrierten Empfängern auch an die externen Endpunkte, mit denen er verbunden ist, übermitteln. Die Übermittlung an die externen Partner soll dabei asynchron ablaufen. Um die Anforderung der asynchronen Übermittlung von Daten nach auÿen erfüllen zu können, sollten diese Übermittlungen in einem nebenläugen Thread abgearbeitet werden. Für ein generelles Konzept ist es allerdings schwierig, bei den verschiedenen Wegen zur Lösung dieses Problem eine Lösungsrichtung vorzugeben. Das bedeutet, dass diese Anforderung durch die jeweilige Implementierung erfüllt werden muss und nicht durch diesen generellen Teil des Konzepts abgedeckt werden kann. Auÿerdem sollen die Channel, welche mit externen Systemen kommunizieren, über eine austauschbare Teilkomponente verfügen, die für die Serialisierung und Deserialisierung von Events verwendet wird. Diese Anforderung kann im Konzept mit aufgenommen werden, indem eine Unterklasse des Channel eingeführt wird. Diese verfügt über einen EventSerializer, welcher das entsprechende Interface implementiert. Ebenso wird in dieser Klasse ein Feld vorgehalten, welches den Endpunkt der Verbindung beinhalten soll. Über einen solchen Verbindungsendpunkt müssen alle RemoteChannels verfügen, da sie ein Ziel für die zu übermittelnden Events benötigen. Schlieÿlich verfügt jeder RemoteChannel über eine Methode teardown(), die es ermöglicht, dass Verbindungen geordnet beendet werden, wenn der Channel beendet werden soll. Diese Methode wird nicht als abstrakt deklariert, kann jedoch überschrieben werden, wenn sie von der jeweiligen Implementierung benötigt wird. Der Übersichtlichkeit halber zeigt Abbildung 4.7 das entstehende UML-Diagramm. Auf dieser Abbildung ist zudem sichtbar, dass ein RemoteChannel seinen eigenen Namen kennt. Dies ist notwendig, damit die Anforderung aus Abschnitt erfüllt werden kann, in der es heiÿt, dass der Name des Channels global als Identizierungsmerkmal genutzt werden soll. Um dieses Identizierungsmerkmal für die Kommunikation mit den externen Systemen nutzen zu können, benötigt der RemoteChannel folglich dieses Wissen. Das EventSerializer Interface Bei diesem Interface handelt es sich um die Abstraktion einer Klasse, mit deren Hilfe Events in Strings übersetzt werden können. Ebenso ist es möglich, aus einem gegebenen String wieder ein entsprechendes Event zu erhalten. Dabei muss bei der Implementierung darauf geachtet werden, dass bei der Deserialisierung die korrekte Unterklasse des Events erzeugt wird. Durch diese Abstraktion ist es möglich, unterschiedliche Implementierungen zu nutzen. Auf diese Weise kann immer die Implementierung gewählt werden, die für die Serialisierung und Deserialisierung der Events am besten geeignet ist. Die Eignung muss dabei an den Anforderungen aus dem speziellen Szenario und den dadurch entstehenden, möglicherweise komplexen Event-Objekten Seite 57

63 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.3. Verfeinerung des Konzepts gemessen werden. Abbildung 4.7: UML-Darstellung: Die Klasse RemoteChannel 4.3 Verfeinerung des Konzepts Das bisher vorgestellte Konzept zur Realisierung der einzelnen Komponenten ermöglicht es, schon viele der gestellten Anforderungen zu erfüllen. Es gibt allerdings noch Bereiche, die nicht abgedeckt sind. Diese betreen nicht einzelne Komponenten, sondern das System in seiner Gesamtheit. Nachfolgend wird das Konzept verfeinert und somit versucht, die noch oenen Anforderungen zu erfüllen Das Event Processing Network Das EPN wird durch eine Kombination der verschiedenen Komponenten realisiert. Es müssen dabei Instanzen der benötigten Komponenten erzeugt und dann mit Hilfe von Channels untereinander verbunden werden. Da es sich bei dem EPN um ein dynamisches, modulares System handelt, sollte es auch zur Laufzeit geändert werden können. Zur Vereinfachung und Vereinheitlichung der Erstellung und Wartung des EPN wird eine einzelne Klasse verwendet. Diese Klasse stellt die Methoden zum Hinzufügen und Entfernen von Komponenten aus dem Netzwerk bereit. So stellt die Klasse eine Fassade für die Interaktion mit dem eigentlichen EPN dar. Mit Hilfe dieser Klasse ist das Netzwerk einfach konstruier- und änderbar. Zur Laufzeit werden alle Komponenten ausschlieÿlich zentral in dieser Klasse vorgehalten. Die verwendete Klasse trägt den Namen EventProcessingNetwork. Um eine bessere Vorstellung zu bekommen, ist die Klasse auf Abbildung 4.8 in UML-Notation dargestellt. Um ein möglichst einfaches Interface nach auÿen zur Verfügung zu stellen, werden bei den Methoden zum Hinzufügen von Komponenten diese nur mit Strings bezeichnet. Die Fassade bekommt von auÿen lediglich Befehle in der Form Füge eine Quelle vom Typ X zum Netzwerk hinzu, welche ihre Events in den Channel 'ABC' gibt. Dieser Channel soll vom Typ Y sein.. In der Darstellung der Klasse ist zu sehen, dass die Methoden zum Hinzufügen einer Komponente einen String zurück geben. Hierbei handelt es sich um eine eindeutige ID, welche jede neu erzeugte Instanz einer Komponente zugeordnet bekommt. Über diese ID kann zu einem späteren Zeitpunkt auf die Instanz referenziert werden, ohne die Instanz selbst nach auÿen geben zu Seite 58

64 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.3. Verfeinerung des Konzepts Abbildung 4.8: UML-Darstellung: Die Klasse EventProcessingNetwork müssen. Die ID wird so z.b. in den Methoden genutzt, über die einzelne Komponenten wieder aus dem Netzwerk entfernt werden können. Zwei weitere Anforderungen, die vom EPN erfüllt werden sollen, betreen die Persistierbarkeit des Netzwerks und den Ablauf der Verarbeitung, welcher nicht blockieren darf (vgl ). Zunächst wird die Möglichkeit der Speicherung des Netzwerks betrachtet. Die Persistierung des gesamten Netzwerks ist, wie in Abschnitt gezeigt wurde, technisch nicht sinnvoll. Allerdings kann sehr wohl der Aufbau des Netzwerks, also die vorhandenen Komponenten und deren Verknüpfungen, gespeichert werden. Für diese Speicherung wird die Methode persist() genutzt. Sie gibt das EPN, repräsentiert in einer Datenstruktur, zurück. Diese Datenstruktur enthält die Typen der verschiedenen Komponenten und wie diese Komponenten miteinander verknüpft sind. Dafür wird bei den genutzten Channeln auch deren Name gespeichert. Die Wiederherstellung wird durch einen speziellen Konstruktor gelöst. Wird dieser genutzt und ein EPN in Form der Datenstruktur übergeben, so wird dieses EPN wieder wiederhergestellt und somit reaktiviert. Als nächstes wird sich der Anforderung gewidmet, die aussagt, dass das EPN nicht-blockierend arbeiten muss. Um diesen Zustand zu erreichen, müssen Operationen in nebenläuge Threads ausgelagert werden, die eine längere Zeit benötigen oder benötigen können, um beendet zu werden. Prinzipiell sind diese Operationen, die das Netzwerk im jetzigen Zustand blockieren können, die verarbeitenden Operationen. Entsprechend betroen sind die Methoden onevent(event e) der Agenten und Consumer und auch die Methode put(event e) der Channel, in der das eingehende Event an alle Consumer weitergegeben wird. Letztere Methode, also die im Channel implementierte, bietet an dieser Stelle einen Punkt, der alle drei Schwachstellen abdeckt. In dieser Methode werden die onevent(event e)-methoden der registrierten Empfänger aufgerufen. Zudem soll bei einem Channel, der Events auch an externe Kommunikationspartner sendet, dieser Sendevorgang sowieso asynchron ablaufen. Da die Auslagerung von Funktionalität in nebenläuge Threads auf jeder Plattform anders implementiert wer- Seite 59

65 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.3. Verfeinerung des Konzepts den kann, kann an dieser Stelle das Konzept lediglich um den Hinweis erweitert werden, dass an dieser Stelle eine nebenläuge Verarbeitung implementiert werden sollte. Es sollte jedoch möglich sein, die Nebenläugkeit direkt in der abstrakten Klasse Channel zu implementieren und damit den Aufwand nur einmal betreiben zu müssen. Zu beachten ist, dass durch die Möglichkeit mehrerer Eingangskanäle in den Agenten und Consumern deren jeweilige Methode onevent(event e) auf jeden Fall threadsicher implementiert werden muss. Dies ist aber auf jeden Fall einfacher, als bei jeder Implementierung eines Agenten/Consumer auf eine nicht-blockierende Abarbeitung der Events achten zu müssen Eine Factory für die Channels Eine weitere Anforderung an das System ist, dass die Channels mit einem Namen eindeutig im System referenzierbar sein sollen. Für diesen Zweck bedarf es der Zuordnung der Namen zu der jeweiligen Instanz des dazugehörigen Channels. Diese Zuordnung lässt sich mit einer einfachen Map realisieren. Wird nun ein Channel mit einem bestimmten Namen angefordert, so wird erst in der Map geschaut, ob der Channel schon existiert und wenn ja, eine Referenz auf ihn zurück gegeben. Existiert noch kein Channel mit dem angegebenen Namen, dann wird er erstellt und in der Map unter dem Namen hinterlegt. Diese Vorgehensweise ist auf den ersten Blick recht simpel, wird aber bei genauerer Ansicht schnell kompliziert. Da es Channels verschiedenen Typs gibt (beispielsweise nur applikationsintern nutzbare), kann es sein, dass der angeforderte Name bereits vergeben, aber der dazugehörige Channel vom falschen Typ ist. Die Verwaltung der Channels auszulagern, bietet sich daher an, um die entstehende Komplexität zu verbergen. In diesem Zuge kann dann auch die Erstellung von Channels unterschiedlichen Typs ausgelagert werden. Sie stellt eine weitere Komplexität dar, die beim Erstellen des Netzwerks verborgen bleiben sollte. So soll nach Möglichkeit nur noch der Typ und Name des gewünschten Channels angegeben werden müssen und es wird ein entsprechender Channel zur Verfügung gestellt. Wie genau diese Factory realisiert wird, ist wiederum Sache der Implementierung. Eine solche mit zu implementieren, wäre jedoch in jedem Fall sinnvoll Ressourcenverbrauch minimieren Das vorgestellte Konzept berücksichtigt bisher nicht explizit die auf einem mobilen Endgerät nur eingeschränkt zur Verfügung stehenden Ressourcen. Zwei Ansätze zum Einsparen von Ressourcen sind jedoch denkbar, die aus unterschiedlichen Gründen aber nicht ihren Weg in das Konzept nden. Abschalten eines Teils des Netzwerks Der erste Ansatz betrit das EPN als Ganzes. Besonders bei komplexen Netzwerken kann es vorkommen, dass Teile des Netzwerks weniger intensiv genutzt werden, als andere. In diesen Teilen könnten vorübergehend Ressourcen freigesetzt werden, wenn die Teile des Netzwerks gerade nicht genutzt werden. Insbesondere wäre es denkbar, dass in den Channels statt den Referenzen Seite 60

66 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.3. Verfeinerung des Konzepts auf die Agenten und Consumer nur deren IDs vorgehalten werden (vgl ). Sollen nun eingehende Events zugestellt werden, werden zu den IDs die entsprechenden Komponenten angefragt und die Events abgeliefert. Die Komponenten werden dabei an einer zentralen Stelle vorgehalten, können aber auch beendet bzw. pausiert werden. Wird eine Komponente angefordert, die momentan nicht aktiv ist, so wird diese initialisiert. Der Zeitpunkt der Pausierung bzw. Beendigung von einzelnen Komponenten muss dabei von diesen selbst festgelegt werden, indem sie sich entsprechend als idle melden. Auf diese Art und Weise könnten viele Ressourcen gespart werden, indem sie nur aquiriert werden, wenn sie auch benötigt werden. Der Ansatz bringt allerdings auch Probleme mit sich. Zunächst sind die Nachteile im Bereich der Performanz zu nennen. Wenn ein Channel eingehende Events nicht direkt weitergeben kann, sondern bei jedem Event erst ein Lookup erfolgen muss, dann bedeutet dies einen Geschwindigkeitsverlust. Ebenso könnte es im schlimmsten Fall zu der Situation kommen, dass bei jedem eingehenden Event nicht nur der Lookup erfolgen muss, sondern die empfangende Komponente auch erst noch instanziiert werden muss. Um diesen Fall zu verhindern, wäre es notwendig, genau zu wissen, in welchem Abstand die Events in den Channel gegeben werden, was nicht so einfach, wenn überhaupt, möglich ist. Das zweite Problem tauchte schon bei der Frage auf, ob und wie das EPN persistiert werden kann (vgl ). Auch in dem jetzt betrachteten Fall müssten die Agenten und deren Zustand sowohl gespeichert als auch wiederhergestellt werden, was, wie schon festgestellt worden ist, nicht trivial ist. Zumindest das Problem mit zu spät zugestellten Events würde jedoch nicht auftreten. Die Begründung ist, dass nur Teile des Netzwerks für eine Abschaltung in Frage kommen, in denen aktuell keine Events mehr aktiv weitergegeben oder verarbeitet werden. Externe Kommunikation nur, wenn es sein muss Das Sparen von Ressourcen ist an einer bestimmten Stelle im EPN auf jeden Fall möglich. Diese Stelle sind die Channels, die die Ergebnisse auch an externe Kommunikationspartner weitergeben und von diesen empfangen können. Die Möglichkeiten der Einsparung hängen dabei von der Implementierung ab und tauchen deswegen nicht im vorgestellten Konzept auf. Unter der Voraussetzung, dass für den Hin- und Rückkanal eigenständige Netzwerkverbindungen zur anderen Seite aufgebaut werden müssen, könnte folgendes umgesetzt werden: Eine Verbindung zum Server für den Empfang von Events muss lediglich aufgebaut werden, wenn auf dem Channel auf dem mobilen Endgerät auch Empfänger für die Events registriert sind. Des Weiteren ist zu überlegen, ob für die Senderichtung dauerhaft eine Verbindung gehalten werden muss, oder ob diese on demand bei eingehenden Events aufgebaut werden soll. Wird diese nach dem Önen für eine bestimmte Zeit oen gehalten und dann wieder beendet, können Ressourcen gespart werden. Es tritt dabei allerdings eine ähnliche Problematik wie beim Abschalten einzelner Teile des Netzwerks auf: Im schlimmsten Fall würde für jedes Event eine Verbindung neu aufgebaut werden. Dies kann zu einem stark erhöhten Energieverbrauch führen, da der Auf- und Abbau einer Datenverbindung über das Mobilfunknetz viel Energie benötigt[3]. Ebenfalls denkbar wäre ein Caching von Events über einen bestimmten Zeitraum, sodass die Seite 61

67 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.4. Die sich ergebenden Klassen im Überblick Events dann gesammelt übertragen werden können. Diese Möglichkeit muss vom Szenario abhängig gemacht werden. Müssen die Events zeitnah übermittelt werden, dann bietet sich eine solche Lösung nicht an. Weitergehende Strategien zur Optimierung des Datenverkehrs lassen sich z.b. mit Hilfe von [2] und [16] recherchieren. Ob und wie die gefundenen Schlüsse sich sowohl im Channel implementieren lassen und ob sie im gegebenen Szenario anwendbar sind, muss jeweils evaluiert werden. 4.4 Die sich ergebenden Klassen im Überblick Abbildung 4.9 zeigt alle Klassen, die aus dem generellen Konzept abgeleitet werden. Aus dem Diagramm gehen auch die Beziehungen zwischen den Komponenten hervor. Es wurde dabei bewusst auf die Klasse Event und die Factory für Channels verzichtet, um die Übersichtlichkeit zu wahren. Alle Klassen sind dabei ohne jede Spezialisierung auf eine bestimmte Programmiersprache entworfen. Somit lässt sich das gezeigte Diagramm für jede Plattform umsetzen, für die objektorientierte Anwendungen geschrieben werden können. Abbildung 4.9: UML-Darstellung: Alle Klassen des generellen Konzepts und deren Beziehungen Seite 62

68 Kapitel 4. Konzept einer CEP-Umgebung 4.5. auf Technische mobilen Geräten Umsetzungsmöglichkeiten für die externe Kommunikation 4.5 Technische Umsetzungsmöglichkeiten für die externe Kommunikation Dieser Abschnitt behandelt die Kommunikation zwischen dem mobilen Endgerät und externen Kommunikationpartnern. Diese Kommunikationspartner sind autark betriebenen Plattformen, die in die Gesamtarchitektur eingebunden sind. Dabei kann es sich um weitere, mobile Endgeräte oder auch um stationäre Systeme wie zum Beispiel eine auf einen Server ausgelagerte Ereignisverarbeitung handeln Datenformat Im Folgenden werden zwei unterschiedliche Ansätze vorgestellt, um die zu sendenden Ereignisse in ein anforderungsgerechtes Format zu überführen. Die beiden Möglichkeiten werden insbesondere darauf hin betrachtet, wie groÿ die entstehende Datenmenge ist und wie schnell die Serialisierung bzw. Deserialisierung erfolgt. Beide stellen die Ergebnisse im Klartext dar und bieten somit ein einfaches und plattformunabhängiges Format für die Übertragung an. Im Vergleich sollen vor allem fünf Punkte näher betrachtet werden: 1. Werden Klartext-Dokumente erzeugt? In der Anforderung an die Datenübertragung in Abschnitt wurde festgelegt, dass die Daten in Form von Klartext-Dokumenten aufbereitet werden sollen. 2. Wie gut ist die Unterstützung des Formats für unterschiedliche Programmiersprachen? Das Format soll unabhängig von der verwendeten Plattform und damit auch von der verwendeten Programmiersprache sein. 3. Sind die Daten validierbar? Die Validierbarkeit der entstehenden Daten ist wichtig, da sie zwischen autonomen Systemen übertragen werden. Beim Empfänger müssen aus den Daten wieder Objekte erzeugt werden. Um diesen Vorgang nur mit korrekten Daten durchzuführen, sollten die Daten einfach validiert werden können. 4. Wie sieht die Struktur der Daten aus? Die Struktur der Daten sollte so beschaen sein, dass so wenig Overhead wie möglich erzeugt wird, um die entstehende Datenmenge gering zu halten. Es ist dabei ausreichend, wenn einfache Objekte mit Attributen dargestellt werden können. 5. Ist eine Umwandlung der Daten performant? Die Geschwindigkeit der Umwandlung der Daten spielt ebenfalls eine Rolle. Diesbezüglich wird mit den beiden Verfahren nach deren Vergleich hinsichtlich der oben genannten Punkte ein experimenteller Vergleich durchgeführt. Dieser Punkt taucht entsprechend nicht direkt bei der Einzelbetrachtung auf, sondern wird erst im darauf folgenden Abschnitt beleuchtet. Seite 63

69 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.5. Techniken für die externe Kommunikation Extensible Markup Language (XML) Ein weit verbreitetes Format für die plattformunabhängige Datenübertragung ist seit Jahren die Extensible Markup Language (XML). Es handelt sich hierbei um eine Beschreibungssprache, mit deren Hilfe strukturierte, hierarchische Daten dargestellt werden können. Die Sprache besitzt verschiedene Eigenschaften, die Vor- und auch Nachteile mit sich bringen. In Bezug auf die Anforderungen im vorliegenden Anwendungsfall sind nur einige dieser Eigenschaften relevant: 1. Klartext-Dokumente XML ist rein textbasiert. Das bedeutet, dass XML aus allen gängigen Programmiersprachen heraus einfach generiert werden kann, da es sich im Prinzip nur um einen Text-String handelt. Die entstehenden Daten können sehr einfach über jedes beliebiges Medium ausgetauscht werden. Es ist überdies möglich, einfache und somit schnelle Komprimierungsverfahren anzuwenden, um die entstehenden Textdokumente ezient zu verkleinern. So ist es möglich, die entstehenden Daten für die Übertragung zu minimieren. 2. Sprachunterstützung Die Unterstützung von XML ist in vielen Programmiersprachen gegeben. Für die meisten der gängigen Sprachen gibt es eziente Bibliotheken zum Generieren und Parsen von XML Daten. Bei einigen Sprachen gibt es überdies direkt in die Sprache integrierte Mechanismen, um mit XML Dokumenten arbeiten oder um komplette Objekte direkt als XML zu exportieren. Die Performanz der Verarbeitung kann dabei je nach benutzter Bibliothek stark schwanken. 3. Validierbarkeit Jedes XML Dokument kann gegen ein Schema validiert werden. Dazu ist es notwendig, dass ein entsprechendes Schema erstellt wird und die benutzte Schnittstelle der Programmiersprache eine Schema-Validierung unterstützt. Mit Hilfe dieser Validierung ist es möglich, fehlerhafte Dokumente zu verwerfen und / oder neu anzufordern. 4. Struktur Die Struktur von XML wird relativ schnell kompliziert und somit für einen Menschen unübersichtlich. Die einzelnen Daten werden in XML-Elementen gespeichert. Die einzelnen Elemente besitzen mindestens einen Namen und bestehen im Normalfall aus einem önendem und einem schlieÿendem Tag. Daten, die dem Element zugeordnet werden stehen typischerweise zwischen den beiden Tags. Diese Schreibweise führt zu viel Overhead, welcher die Gesamtzahl der Zeichen in einem XML Dokument negativ beeinusst. Seite 64

70 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.5. Techniken für die externe Kommunikation 1 <? xml version =" 1.0 " encoding =" UTF -8 " standalone =" yes "? > 2 < event > 3 < type > DriveByEvent </ type > 4 < uuid > 5 < String > df8-0 f9e a2f9-9 af309fb5889 </ String > 6 </ uuid > 7 < timestamp > 8 <int > </ int > 9 </ timestamp > 10 < speed > 11 < float > </ float > 12 </ speed > 13 </ event > Listing 4.1: Ereignis als XML Dokument JavaScript Object Notation (JSON) Ein weiteres Format für die plattformunabhängige Datenübertragung ist die JavaScript Object Notation (JSON). Die Darstellung von strukturierten Daten in diesem Format erfreut sich seit einiger Zeit steigender Beliebtheit. Dies begründet sich vor allem dadurch, dass es sich um ein noch leichtgewichtigeres Format handelt als XML. Wie jenes handelt es sich ebenfalls um ein textbasiertes Format. Vor allem Webanwendungen verwenden das JSON-Format zum Datenaustausch zwischen Server und Client, da es sich sehr gut mit dem in diesen Anwendungen genutzten JavaScript integriert. 1. Klartext-Dokumente Ebenso wie bei XML handelt es sich bei JSON um ein textbasiertes Format. Die entstehenden Dokumente können also gleichfalls über ein beliebiges Medium übertragen, als auch recht einfach und ezient komprimiert werden. 2. Sprachunterstützung Die Unterstützung von JSON ist inzwischen in vielen Programmiersprachen durch Bibliotheken gegeben. Diese bieten eziente und einfach zu bedienende Funktionen zum Generieren und Parsen von Daten im JSON Format. 3. Validierbarkeit Ähnlich zu dem Ansatz XML Schema ist es auch für JSON möglich, die einzelnen Dokumente anhand eines Schemas zu validieren. Der entsprechende Standard bendet sich allerdings noch im Zustand eines Drafts, die Vorgaben aus dem Draft sind aber schon in verschiedenen Bibliotheken umgesetzt. Seite 65

71 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.5. Techniken für die externe Kommunikation 1 { 4. Struktur Die Struktur eines JSON Dokuments ist, wie in Listing 4.2 zu sehen, ein wenig einfacher als die von XML. Es wird nicht so viel Overhead erzeugt, da die Elemente nicht mit einem önenden und einem schlieÿenden Tag gekennzeichnet werden müssen. Dafür ist zu sehen, dass keine expliziten Typen für die einzelnen Elemente angegeben sind und keine Hierarchie abgebildet wird. Implizit kann jedoch zwischen String, Integer und Float unterschieden werden. Alle weiteren Typen müssten ebenfalls mit einer expliziten Kennzeichnung versehen werden. Muss eine Hierarchie abgebildet werden, kann dies durch Schachtelung ebenfalls erfolgen, ist jedoch nicht vorgeschrieben. 2 " type ": " DriveByEvent ", 3 " uuid ": "54968 df8-0 f9e a2f9-9 af309fb5889 ", 4 " timestamp ": , 5 " speed ": } Listing 4.2: Ereignis als JSON Dokument Performanzvergleich Die beiden vorgestellten Ansätze zur Übertragung von serialisierten Ereignissen haben, wie leicht zu sehen ist, viele Gemeinsamkeiten. Trotzdem ist ein Test unabdingbar, welcher die beiden Techniken gegenüberstellt. Bei diesem Test wird als Referenzwert ebenfalls die Geschwindigkeit betrachtet, die bei der Verwendung des Java-Interfaces Serializable und den Java-internen Methoden erreicht werden kann. Diese Methode wird später jedoch nicht als Kandidat zur Übertragung berücksichtigt werden können, da in dem Fall eine Bindung an Java (in einer bestimmten Version) erfolgen würde, um die Daten wieder zu deserialisieren. Der durchgeführte Vergleich wird im Folgenden beschrieben: Der Vergleichstest wird mit Java SE durchgeführt. Dabei wird für die Serialisierung mit Hilfe von XML auf die im Sprachumfang enthaltenen Klassen XMLEncoder und XMLDecoder zurückgegrien. Für die Serialisierung mit Hilfe von JSON wird die Bibliothek Gson benutzt, welche von Google unter der Apache License 2.0 veröentlicht wurde. Diese dritte Möglichkeit der Serialisierung wird aber nicht weiter in Betracht gezogen, da sonst eine Festlegung auf Java auf beiden Kommunikationsseiten geschehen würde. Auch erschwertes Debugging während der Entwicklungsphase spricht gegen die Verwendung des eingebauten Java-Mechanismus. Zuerst werden verschiedene Mengen an Ereignisobjekten erzeugt. Diese Objekte werden dann mit jeder der verschiedenen Methoden (XML, JSON) serialisiert und wieder deserialisiert. Dabei werden sie nicht als Strom von Objekten, sondern als Einzelobjekte behandelt. Dies kommt der Realität am nächsten, in welcher ebenfalls einzelne Objekte serialisiert und deserialisiert werden, auch, wenn es sich bei der abstrakten Betrachtung des Szenarios um einen Ereignisstrom handelt. Sie werden entsprechend nicht erst zwischengespeichert und dann gesammelt verschickt, sondern jedes für sich. Zu beachten ist dabei, dass unter Umständen in den Implementierungen vorgesehene Caching-Funktionen auÿer Kraft gesetzt werden. Dies ist wie beschrieben aber auch explizit Seite 66

72 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.5. Techniken für die externe Kommunikation Abbildung 4.10: Laufzeitvergleich XML/JSON/Native Serialisierung gewollt, da es sich in der Realität sowieso immer nur um einzelne, unterschiedliche Objekte handeln wird. Zu beachten ist, dass die Eingabe in die Funktionen zum Serialisieren immer aus exakt denselben Objekte besteht. Nur so kann ein möglichst repräsentatives Ergebnis der Laufzeit der Funktionen ermittelt werden. Der Vergleich wird mehrfach wiederholt und schlieÿlich werden die durchschnittlichen Werte zur Auswertung herangezogen. Das Ergebnis des Performanzvergleichs lässt sich am Diagramm auf Abbildung 4.10 gut ablesen. Dabei ist zu beachten, dass die Einteilung der X-Achse nicht symmetrisch ist. Auf Anhieb fällt auf, dass die Laufzeit bei der Serialisierung / Deserialisierung mit Hilfe von XML rasant mit der Menge der zu bearbeitenden Objekte ansteigt. Dieser Anstieg ist deutlich gröÿer als bei der Nutzung der externen Bibliothek für die Serialisierung / Deserialisierung per JSON. Diese ist ihrerseits sichtbar langsamer als die Serialisierung / Deserialisierung in Bytearrays über das Java-Interface Serializable. Datenvolumenvergleich Wird ein Objekt serialisiert, entstehen die Daten, die an den jeweiligen Kommunikationspartner übertragen werden. Je geringer das Datenvolumen ist, desto besser ist dies im Bezug auf Übertragungsdauer. Im besonderen Fall von mobilen Endgeräten sind weniger zu übertragende Daten auch gut im Hinblick auf die Lebensdauer des Energievorrats und die unter Umständen entstehenden Kosten für die Übertragung. Die drei im Performanztest durchgeführten Methoden zur Serialisierung führen zu Datenmengen in verschiedenen Gröÿen. Die ermittelten Werte sind in Tabelle 4.1 aufgeführt. Die Gröÿe gilt jeweils für ein einzelnes, serialisiertes Objekt. Seite 67

73 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.5. Techniken für die externe Kommunikation Es wurden dieselben Objekte genutzt, die auch im Performanztest verwendet wurden. Da einzelne Attributwerte der unterschiedlichen Objekten voneinander abweichen, wurde der entsprechende Mittelwert ausgewertet. Bei den Werten handelt es sich um die ID und den Zeitstempel der Erstellung. Methode Format Gröÿe in Byte XML (built-in) Text 287 Gson (Bibliothek) Text 147 Serializable (built-in) Binär 62 Tabelle 4.1: Gröÿenvergleich der serialisierten Ereignisse Zusammenfassung der Ergebnisse Sowohl XML als auch JSON bieten ähnliche Eigenschaften, die jeweils die Anforderungen an das benötigte Übertragungsformat erfüllen. Beide liefern Klartext als Ausgabe, der unkompliziert von den meisten Systemen verarbeitet werden kann. Für beide besteht ebenfalls eine weite Verbreitung von verschiedenen Bibliotheken, mit deren Hilfe die Daten serialisiert und deserialisiert werden können. Damit erfüllen beide Formate die Anforderungen an das Datenformat, in welchem die Ereignisse zwischen dem mobilen Endgerät und weiteren Stellen ausgetauscht werden. Da JSON sowohl im Geschwindigkeitsvergleich als auch bei der entstehenden Datenmenge XML im gegebenen Anwendungsfall überlegen ist, kann die Verwendung des JSON-Formats für diesen Einsatzzweck empfohlen werden. Als Bibliothek kann zum Beispiel das von Google angebotene Gson-Paket benutzt werden. Es bietet eine einfache und doch mächtige Schnittstelle, welche es ermöglicht, auch ohne jede Art der Annotationen in den jeweiligen Klassen diese zu serialisieren Datenübertragung zwischen physisch getrennten Systemen Für die Übertragung der Daten zwischen den autonomen Systemen muss eine Technik gefunden werden, die die Anforderungen aus Abschnitt erfüllen kann. Für eine solche Übermittlungstechnik kommen verschiedene Ansätze in Frage, welche alle in der Lage sind, Klartext-Nachrichten zu übertragen. So bieten sich die Übermittlung mit Hilfe einer Nachrichtenorientierten Middleware (MOM) oder per HTTP an. Auch eine, auf reiner Socketprogrammierung beruhende, Lösung kann in diesem Zusammenhang näher betrachtet werden. Die Kriterien, auf die die Übermittlungsformen hin betrachtet werden, stellen sich aus den Anforderungen und zusätzlichen Betrachtungspunkten zusammen. Die zusätzlichen Punkte sind: Protokoll Ein Protokoll zur Übertragung der Daten kann entweder selbst entwickelt werden, oder es wird ein vorhandenes Protokoll genutzt. Ein schon erprobtes und verbreitetes Protokoll zu nutzen spart dabei Entwicklungsarbeit für ein eigenes Protokoll. Auch ist die Interoperabi- Seite 68

74 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.5. Techniken für die externe Kommunikation lität bei der Verwendung eines existierenden Protokolls eher gegeben, als bei einer Eigenentwicklung. Sicherheit Bei der Übermittlung der Daten muss auch die Sicherheit der Übertragung betrachtet werden. Die Schutzziele, welche dabei eine Rolle spielen, hängen jedoch vom jeweiligen Anwendungsfall bzw. Einsatzzweck ab. Für die CEP-Umgebung und ihre Funktion ist der Schutz der versendeten Daten zu vernachlässigen. Der Punkt soll bei Betrachtung der unterschiedlichen Möglichkeiten zur Datenübertragung dennoch berücksichtigt werden, um eine detailliertere Sichtweise zu liefern. Jede der drei angesprochenen Ansätze bietet sowohl Vor- als auch Nachteile, auf die im Folgenden näher eingegangen wird. Nach der Betrachtung der einzelnen Möglichkeiten werden diese im Bezug auf die tatsächliche Übertragungsgeschwindigkeit einzelner Ereignisse hin verglichen. Dazu wurden sie getrennt voneinander bei gleichem Versuchsaufbau zur Übertragung von Ereignissen von einem mobilen Endgerät auf einen stationären Rechner getestet. Mehr zu diesem Geschwindigkeitsvergleich folgt auf Seite 73. Übertragung per Socket Der erste Ansatz ist die Übertragung der Daten über eine manuell erstellte Socketverbindung. Dieser Ansatz bietet verschiedene Vorteile: Geschwindigkeit Dieser Ansatz realisiert die schnellste Übertragung der Daten. Dies lässt sich auch leicht erklären: Es wird kein Overhead erzeugt, der die Übertragungszeit unnötig verlängert. Auf diese Art ist es möglich, ausschlieÿlich die Nutzdaten zu übertragen. Die Übertragung geschieht folglich mit einer sehr hohen Geschwindigkeit. Plattformunabhängigkeit Ebenso ist es von Vorteil, das mit allen gängigen Plattformen einfache Sockets erstellt und genutzt werden können. Dieser Umstand sorgt für ein hohes Maÿ an Interoperabilität. Leichtgewichtigkeit Auf der Empfängerseite muss lediglich ein Listening-Socket geönet werden. Diese Unabhängigkeit von einem zu startenden Service, wie er in den anderen Ansätzen gebraucht wird, macht das Kommunizieren über reine Sockets extrem leichtgewichtig. Protokoll Bei der Wahl dieses Ansatzes muss ein eigenes Protokoll entworfen werden. Ohne ein vereinbartes Protokoll ist es der Empfängerseite nicht möglich, die empfangenen Daten korrekt wieder zu Objekten zusammen zu setzen. Des Weiteren gibt es zusätzliche Gründe, warum ein Protokoll benötigt wird. So muss beispielsweise festgelegt werden können, für welchen Seite 69

75 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.5. Techniken für die externe Kommunikation Channel die Daten bestimmt sind. Diese Festlegung soll anhand eines Namens, dem Channelnamen, getroen werden können. Eine Einbindung des Namens in die Adressierung des Endpunktes, wie es bei der Verwendung von HTTP möglich wäre, nicht realisierbar. Sicherheit Sockets lassen sich ohne groÿen Aufwand mit Hilfe von Transport Layer Security (TLS) verschlüsseln. Die Kommunikation zwischen den beiden Endpunkten ist dann, entsprechende Konguration vorausgesetzt, sowohl in Punkto Authentizität, als auch Integrität und Vertraulichkeit sicher. Hervorzuheben ist jedoch, dass eine Autorisierung durch diesen Sicherheitsmechanismus nur mit Hilfe von Client-Zertikaten durchgeführt werden kann, welche ausschlieÿlich an autorisierte Clients ausgegeben werden. Da dies einen erheblichen Aufwand bedeutet, sollte zur Erfüllung dieses Schutzziels ebenfalls das zu entwickelnde Protokoll verwendet werden. Übertragung per HTTP Der zweite Ansatz, die Übertragung der Daten über das Hypertext Transfer Protocol (HTTP) bietet sich insbesondere bei der Verwendung von Smartphones an. Begründet werden kann dies, da HTTP in vielen Anwendungen, die für mobile Endgeräte und insbesondere Smartphones entwickelt werden, eingesetzt wird. Es handelt sich um ein simples und weit verbreitetes Protokoll, was die Beliebtheit bei der Entwicklung von Applikationen für mobile Endgeräte erklärt. Als Entwickler ist die Verwendung von HTTP extrem einfach, da es in den verbreiteten Frameworks zur Programmierung von Applikationen für Smartphones gut dokumentierte und performante Schnittstellen gibt. Die Bibliothek, welche auf Google Android genutzt wird, ist so z.b. die Apache HTTP-Bibliothek[9]. Daher dient an dieser Stelle das von Android-basierten Geräten eingesetzte Package org.apache.http als Beispiel. In der Übersicht lassen sich die wesentlichen Merkmale einer HTTP-basierten Datenübertragung wie folgt zusammenfassen: Geschwindigkeit Die Geschwindigkeit der Übertragung von Daten über HTTP ist schnell. Das Protokoll addiert zu den Nutzdaten minimalen Overhead, welcher allerdings nicht zu eklatanten Geschwindigkeitseinbuÿen führt. Durch die vom Protokoll vorgesehene Sitzungsunabhängigkeit entfällt ebenso etwaiger Overhead beim Erstellen einer Verbindung. Plattformunabhängigkeit Durch die Übertragung der Daten über das HTTP wird keine Plattformabhängigkeit generiert, da es sich um ein universelles Protokoll handelt. Leichtgewichtigkeit Die Verwendung von HTTP als Transportprotokoll setzt bei beiden Kommunikationspartnern voraus, dass diese HTTP sprechen können. Das bedeutet, dass auf der Clientseite ein entsprechender HTTP-Client, auf der Serverseite ein HTTP-Server eingesetzt werden Seite 70

76 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.5. Techniken für die externe Kommunikation müssen. Diese sind abhängig von der gewählten Implementierung eher leicht- oder schwergewichtig. Protokoll Da es sich bei HTTP bereits um ein Protokoll handelt, muss kein eigenes entwickelt werden. Damit entfällt auf dieser Seite der Aufwand, der mit so einer Aufgabe einher geht. Auf der anderen Seite ist man bei der Benutzung von HTTP darauf angewiesen, dass das Protokoll alle Anwendungsanforderungen erfüllen kann. Dabei ist insbesondere das Kommunikationsmodell von HTTP unter Umständen ein Problempunkt, da es sich um ein unidirektionales Modell handelt. Ob somit ein Anwendungsgeeignetes Modell mit Hilfe von HTTP nachgebildet werden kann ist noch zu prüfen, da es sich bei der Verbindung zwischen dem mobilen Endgerät und der Umgebung um eine bidirektionale Verbindung handeln soll. Sicherheit Bei der Verwendung von HTTP gibt es im ersten Schritt keine Sicherheit in Bezug auf Integrität, Vertraulichkeit oder Authentizität der Daten. Lediglich eine Autorisierung ist durch HTTP bereits abgedeckt. Hier bietet das Protokoll bereits die Möglichkeit einer Anforderung und Übermittlung von Benutzernamen und Passwörtern. Da jedoch unverschlüsselte Daten übertragen werden, ist dieser Sicherheitsmechanismus nicht ausreichend. Die oben angesprochenen, fehlenden Sicherheitskriterien können jedoch durch die Verwendung von HTTPS erfüllt werden. Da es sich hierbei um eine simple Erweiterung des Protokolls handelt, können die meisten zur Verfügung stehenden HTTP-Clients und -Server durch einfache Konguration auch HTTPS sprechen. Übertragung mit Hilfe einer Message Oriented Middleware Der dritte Ansatz zur Übertragung von Daten beruht auf dem Einsatz einer speziellen Software zur Übertragung von Nachrichten. Es handelt sich dabei um einen Dienst zwischen dem Nachrichtenproduzenten (im obigen Ansatz Client) und dem Nachrichtenempfänger (im obigen Beispiel Server). Diese Art von Diensten wird auch Message Oriented Middleware (MOM) genannt. Es gibt viele verschiedene Implementierungen von solchen MOM-Diensten. Besonders im Javaumfeld wird dabei gerne auf die Implementierungen zurück gegrien, welche als Dienste zur Nutzung der Java Messaging Service JMS-Schnittstelle 1 fungieren. Diese Schnittstelle deniert einheitliche Methoden zum Kreieren, Versenden, Empfangen und Auslesen von Nachrichten, welche mit Hilfe einer MOM versendet werden. Welche MOM-Software dabei eingesetzt wird, ist unabhängig von der Implementierung dieser Methoden. Da die Schnittstelle dabei fest vorgegeben ist, kann somit gegen sie entwickelt werden, wobei der Code von der später eingesetzten MOM-Software unabhängig ist. Dieser Ansatz funktioniert, bietet jedoch keine Unabhängigkeit von der eingesetzten Plattform, wie es im Rahmen dieser Arbeit aber angedacht ist, da abgerufen am Seite 71

77 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.5. Techniken für die externe Kommunikation Um diese Plattformunabhängigkeit zu erreichen, wird an dieser Stelle der Fokus auf ein alternatives Protokoll für nachrichtenorientierte Zwischenanwendungen gelegt. Dabei handelt es sich um das Advanced Message Queuing Protocol (AMQP). Es deniert ein binäres Protokoll, welches zur Kommunikation zwischen verschiedenen Clients und der MOM-Software zum tragen kommt. Aus der Denition eines Protokolls und nicht einer Schnittstelle (wie JMS) entsteht der Vorteil, dass unterschiedlichste Systeme zusammen arbeiten können. Weil das (binär) Format zum Beispiel bei OpenJMS proprietär ist, wird bei den beteiligten Kommunikationspartnern voraus gesetzt, dass sie dieses spezische OpenJMS-Format unterstützen. Im Gegensatz dazu steht das standardisierte Protokoll AMQP, mit welchem für unterschiedliche Plattformen Schnittstellen entwickelt werden können, die dann alle mit dem selben Protokoll kommunizieren.. Das Protokoll bendet sich in der Version 1.0, jedoch basieren die meisten verfügbaren Bibliotheken (siehe unten) noch auf Version So gibt es zum Beispiel Bibliotheken für Java 2, Erlang 3, C 4, C# 5, Python 6, Ruby 7 oder auch PHP 8. Als Implementierung der MOM wird RabbitMQ 9 genutzt. Hierbei handelt sich um ein Projekt, welches sowohl einen AMQP Server als auch einige der oben genannten Client-Bibliotheken zur Verfügung stellt. Der AMQP-Server von RabbitMQ basiert dabei auf der Protokollspezikation und noch nicht auf der Version 1.0, da diese Umsetzung noch nicht erfolgt ist. Diese Version wird auch von den verfügbaren Clients unterstützt. Für die Version 1.0 gibt es hingegen noch keine breite Unterstützung durch Bibliotheken. Um einen Vergleich zu den bisher vorgestellten Übertragungsmöglichkeiten zu erhalten, werden im Folgenden die entsprechenden Eigenschaften betrachtet: Geschwindigkeit Die Geschwindigkeit der Übertragung hängt stark von den gewählten Features ab, die beim Übermitteln genutzt werden sollen. So ist es z.b. möglich, dass der Absender der Nachricht benachrichtigt wird, wenn die Nachricht empfangen worden ist. Ebenso kann vorgegeben werden, dass eine Nachricht auf jeden Fall zum Empfänger weitergeleitet wird - auch, wenn dieser in dem Moment gerade nicht verbunden ist. All diese Einstellungsmöglichkeiten haben einen Einuss auf die Geschwindigkeit der Übertragung. Im folgenden Performancetest werden daher möglichst günstige Optionen gewählt, um so auch die Fähigkeiten der anderen Ansätze so gut wie möglich abzubilden. Das bedeutet zum Beispiel, dass es keine Empfangsquittungen geben und auch eine zugesicherte Zustellung nicht benutzt wird. Dieser Umstand ist jedoch verschmerzbar, da der Absender eines Events in einer CEP-Umgebung nicht weiter an dem Verbleib des Events oder den Reaktionen auf das Event interessiert ist. Plattformunabhängigkeit 2 - abgerufen am abgerufen am https://launchpad.net/librabbitmq - abgerufen am abgerufen am https://github.com/pika/pika/ - abgerufen am https://github.com/ruby-amqp/amqp/ - abgerufen am https://github.com/tnc/php-amqplib - abgerufen am abgerufen am Seite 72

78 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.5. Techniken für die externe Kommunikation Da es sich um ein binäres Protokoll handelt, welches für jede Plattform gleich ist, gibt es keine Abhängigkeiten von von einer bestimmten Plattform oder eingesetzten Bibliothek. Es muss lediglich eine beliebige Bibliothek für die jeweils verwendete Plattform genutzt werden, die das AMQP umsetzt. Leichtgewichtigkeit Die Verwendung von AMQP als Transportprotokoll setzt bei beiden Kommunikationspartnern voraus, dass diese die Daten in das AMQP-Format übersetzen können. Ebenso wird ein externer Service, also der AMQP-Server, benötigt. Die eingesetzten clientseitigen Bibliotheken sind dabei leicht einzubinden und insgesamt eher als leichtgewichtig zu bezeichnen 10. Protokoll Wie bei HTTP handelt es sich bei AMQP ebenfalls um ein vorgegebenes Protokoll. Durch die Verwendung eines passenden, nachrichtenbasierten Kommunikationsmodells kann jedoch, im Gegensatz zu HTTP, einfach eine bidirektionale Verbindung zwischen zwei Kommunikationspartnern hergestellt werden. Sicherheit AMQP sieht in der Spezikation keine Art von Verschlüsselung oder Signierung der Nachrichten vor. Die Mitglieder der Working Group sind sich der Singnikanz eines Sicherheitsmechanismusses bewusst, allerdings haben sie entschieden, dass dies Aufgabe der Applikation ist. Daher wird die Verantwortlichkeit auf den Anwendungsentwickler übertragen. RabbitMQ hingegen sieht wenigstens eine Benutzername / Passwort-Authentizierung vor, mit deren Hilfe zumindest der Nutzerkreis eingeschränkt werden kann, der Nachrichten in das System einspeist bzw. Nachrichten daraus empfangen kann. Geschwindigkeitsvergleich der drei Ansätze Ein wesentlicher Punkt bei der Wahl des richtigen Ansatzes zur Übertragung der Daten von dem Endgerät an andere Kommunikationspartner ist die Übertragungsgeschwindigkeit. Die Einbindung des Gerätes in eine Complex-Event-Processing-Architektur stellt den Anspruch, dass die Datenübertragung so schnell wie möglich erfolgt. Nur so kann eine Berechnung der Fakten in Echtzeit erfolgen. Die drei oben vorgestellten Ansätze werden bezüglich ihrer Übertragungsgeschwindigkeit von Ereignissen getestet. Dabei werden bei der Übertragung per reinem Socket und per HTTP jeweils unterschiedliche, mögliche Implementierungen betrachtet. Bei der Übertragung über Sockets werden zwei verschiedene Serverkonzepte eingesetzt: Klassischer Threading-Server Beim klassischen Socketserver wird jeder Request von einem eigenen Thread bearbeitet. Dies ist notwendig, da der bei der Verbindung neu geönete Socket blockiert und somit auch keine neuen Verbindungen angenommen werden können, bis der Request nicht verarbeitet wurde. 10 Die benötigten Java-Bibliotheken haben eine Gröÿe von ca. 400kb Seite 73

79 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.5. Techniken für die externe Kommunikation Die Verarbeitung wird also durch einen eigenen Thread abgewickelt, damit parallel weitere Verbindungen angenommen werden können. Es wird dabei mit einem Threadpool gearbeitet, um nicht für jeden eingehenden Request einen neuen Thread, und damit vermeidbaren Overhead, zu erzeugen. Die Konsequenz daraus ist, dass eine bestimmte Anzahl an Threads zur Verfügung stehen, die die anfallenden Aufgaben (das Annehmen und Bearbeiten eines Requests) konkurrierend abarbeiten. Non-Blocking-IO-Server Bei diesem Konzept gibt es nur einen einzigen Thread, in dem alle Requests bearbeitet werden. Statt auf blockierenden Sockets zu arbeiten, werden dabei nicht-blockierende Sockets verwendet, die beim Empfang von Daten einen Interrupt erzeugen. Wird ein solcher Interrupt registriert, werden die auf dem Socket eingegangenen Daten in einem Callback vom Mainthread verarbeitet. Dabei ist es nebensächlich, ob es sich um einen Verbindungsaufbau eines neuen Client handelt oder einen Socket, der nach dem Verbindungsaufbau für die Übertragung der Nutzdaten genutzt wird. Zur Realisierung wird die Serversoftware nodejs 11 eingesetzt. Bei der Verwendung von HTTP wurden ebenfalls zwei verschiedene Implementierungen getestet, jedoch hier auf der Clientseite. Auf der Android-Plattform stehen zwei verschiedene Möglichkeiten zur Verfügung, um HTTP-Requests zu stellen: Die komfortable Bibliothek von Apache, welche die Klasse org.apache.http.client und ihre Unterklassen zur Verfügung stellt und die Low-Level Klasse java.net.urlconnection. Beide Varianten werden im Folgenden genutzt, um per HTTP Requests an einen lighttpd 12 -Server zu stellen. Der Versuchsaufbau besteht im Wesentlichen aus einer Android-Applikation, welche unter Verwendung von drei verschiedenen Implementierungen (eine pro oben genannten Ansatz) eine bestimmte Anzahl Ereignisse übermittelt. Der Empfänger ist dabei ein stationärer Rechner, auf welchem eine entsprechende Empfangssoftware (TCP Server, HTTP Server, RabbitMQ Server und zusätzlicher RabbitMQ Client) installiert ist. Die Anwendung wird sowohl im Android-Emulator als auch auf einem authentischen Smartphone mit Android-Betriebssystem ausgeführt. Der Emulator wird mit dem Android SDK mitgeliefert. Es ist zu beachten, dass die Netzwerklatenz bei dem Smartphone leicht erhöht sein kann, da die Verbindung nicht über LAN, sondern WLAN hergestellt wird. In der Anwendung werden 500 Ereignisse generiert und diese dann serialisiert. Anschlieÿend werden die serialisierten Ereignisse einzeln übertragen, wobei lediglich die Zeit der Übertragung zum anderen Ende gemessen wird. Das bedeutet im Einzelnen, dass sowohl bei der Übertragung über den Socket, als auch beim Senden an den RabbitMQ-Server nach dem Absenden des Ereignisses dieses als gesendet gezählt wird. Ebenso wird bei der Verwendung der java.net.urlconnection lediglich der Request zum Server gesendet. Beim org.apache.http.client hingegen muss jeweils noch die Antwort des Servers auf den Request abgerufen am abgerufen am Seite 74

80 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.5. Techniken für die externe Kommunikation Emulator Nexus One Anzahl Threads HTTP URLConnection 37164, , , ,8 7134,4 6564,4 HTTPClient 39834, , , , ,6 6529,8 Socket NIO Server 15850, ,0 8606,8 4270,6 3113,6 2902,6 Threading Server 15735, ,6 8786,0 4305,2 3112,8 2812,6 AMQP RabbitMQ 16129, , ,8 4557,4 4102,0 3955,6 Tabelle 4.2: Übertragungszeit für 500 Ereignisse in Millisekunden abgewartet werden, da der org.apache.http.client diese erwartet und ohne das Auslesen der Antwort nicht weiter arbeitet. Um den maximalen Durchsatz an Ereignissen zu erreichen, wird der Versuch auch mit mehreren parallel laufenden Threads durchgeführt, welche jeweils eine Verbindung zum Server aufbauen und gemeinsam die zu verschickenden Ereignisse versenden. Dabei hält jeder Thread eine Verbindung zum jeweiligen Endpunkt, um den Overhead beim Erzeugen der Verbindung zu minimieren. Diese Verbindung ist je nach Implementierung unterschiedlich, es handelt sich also um einen geöneten Socket, eine geönete HTTP Connection bzw. um eine geönete Verbindung zum RabbitMQ-Server. Jede Kombination der Anzahl an Threads (Läufe mit einem, drei und fünf Threads) und der verschiedenen Übermittlungsansätze wird fünf mal wiederholt und am Ende die mittlere Zeit berechnet, die der Versendevorgang gedauert hat. Diese mittleren Übertragungszeiten können aus Tabelle 4.2 abgelesen werden. Anmerkung Auf dem Nexus One ist unter der Verwendung von nur einem Thread bei der Methode HTTPClient eine ungewöhnliche Abweichung zu sehen. Die Zeit, die benötigt wird, ist wesentlich höher, als im Vergleich zu den anderen Methoden erwartet werden kann. Die einzige Erklärung, welche plausibel erscheint, ist, dass es bei der Verwendung von nur einem Thread und gleichzeitiger Nutzung des ThreadSafeClientConnManager zu Komplikationen kommt. Die Verwendung eines anderen, nicht threadsicheren Connection Managers führt zu anderen Ergebnissen. Da aber alle Versuche mit den gleichen Bedingungen und unter Verwendung derselben Implementierung durchgeführt werden, ist dieser Ausreiÿer hinzunehmen und mit in die Tabelle eingepegt worden. Abbildung 4.11 zeigt die visualisierten Ergebnisse der Testläufe auf dem Android-Emulator. Wegen dem marginalen Unterschied bei der Verwendung der unterschiedlichen Servervarianten für die reine Socket-Lösung, zeigt die Abbildung nur den Verlauf für die Variante mit nichtblockierenden Sockets. Wie deutlich zu sehen ist, ist bei keiner der eingesetzten Implementierungen durch Hinzufügen weiterer, parallel arbeitender Threads eine signikante Verbesserung der Ergebnisse zu erwarten. Eine kleine Ausnahme bildet hier nur die Verwendung des HTTPClient, welcher nach dem Deuten des Diagramms unter Umständen noch unter die 15-Sekunden-Marke fallen könnte. Da der Ver- Seite 75

81 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.5. Techniken für die externe Kommunikation Abbildung 4.11: Laufzeitvergleich der Datenübertragung von 500 Ereignissen mit verschiedenen Methoden suchsaufbau mit maximal fünf konkurrierenden Threads jedoch schon die Grenze für tatsächlich nebenläugen Fäden auf einem mobilen Endgerät bricht, ist fraglich, ob eine weitere Erhöhung der Anzahl überhaupt sinnvoll wäre. In diesem Anwendungsfall könnte dies tatsächlich sinnvoll sein, da durch die Verwendung der Threads hauptsächlich die Netzwerklatenz kaschiert wird. Es sei aber an dieser Stelle bemerkt, dass eine merkliche Steigerung der Geschwindigkeit zur Übertragung auch mit mehr Threads nicht erreicht werden konnte. Dies ist wahrscheinlich auf den zusätzlichen Overhead zurückzuführen, den die Verwaltung von mehr Threads intern bedeutet. Da sich insgesamt alle gezeigten Lösungen bei dem Versuch, mit Hilfe von Threading bessere Ergebnisse zu erzielen ähnlich verhalten, ist die Entscheidung für eine der Lösungen unabhängig vom Threading-Verhalten zu treen. Somit bleibt beim Vergleich nach der Performance nur der absolute Wert als Bewertungskriterium bestehen. Umsetzung des Kommunikationsmodells unter Verwendung der verschiedenen Ansätze Neben der Geschwindigkeit der Übertragung ist es ebenso unumgänglich, dass mit dem gewählten Ansatz das erforderliche Kommunikationsmodell realisiert werden kann. Um die kommenden Überlegungen leichter nachvollziehbar zu machen, folgen noch einmal die Anforderungen an die externe Kommunikation: Die Kommunikation soll asynchron erfolgen, damit der Sender eines Events nicht blockiert Die Kommunikation soll bidirektional erfolgen können, da von allen Kommunikationspartnern Events in den Channel gegeben werden können, die an alle anderen zugestellt werden sollen. Seite 76

82 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.5. Techniken für die externe Kommunikation Etwaige Verbindungsabbrüche müssen behandelt werden, damit die Kommunikation aufrecht erhalten bzw. automatisch wiederhergestellt wird. Dabei müssen die Ereignisse nicht noch nachträglich zugestellt werden, jedoch ist die Möglichkeit des Abbruchs der Verbindung zu beachten. Wichtig hierbei ist, dass das mobile Endgerät nach erneutem Verbinden unter Umständen unter einer anderen Adresse zu erreichen ist als vor dem Verbindungsabbruch. Die Eigenschaft der Asynchronität ist für die Verwendung in einer EDA-Umgebung so zu verstehen, dass auf das Senden eines Ereignisses keine direkte Reaktion erwartet wird. Die Ereignisse werden einfach nur an eine andere Stelle übermittelt, welche Auswirkungen das Ereignis hat, wird dem Sender nicht bekannt gegeben. Auf der Empfängerseite darf das Empfangen eines Ereignisses dabei nicht dazu führen, dass bis zum Abschluss der Verarbeitung dieses Ereignisses keine weiteren empfangen werden können. Zusammengefasst müssen also durchgehend Ereignisse sowohl gesendet als auch empfangen werden können. Die Auswirkungen, die das Eintreen eines neuen Ereignisses beim Empfänger haben, werden dem Absender nicht bekannt gemacht. Durch diese Denition ist einfach zu sehen, dass mit allen drei Ansätzen diese Art der Asynchronität erreicht werden kann. Bei der Verbindung über reine Sockets ist der Sendevorgang nach dem Abschicken der Daten komplett. Der Sender kann nun sofort ein weiteres Ereignis senden, welches im Zweifelsfall erst später vom Empfänger aus dem Socket ausgelesen wird. Auf der Empfängerseite hingegen muss die Verarbeitung des Ereignisses so schnell wie möglich geschehen, damit das nächste Ereignis aus dem Socket gelesen werden kann. Da die Ereignis-Träger-Schicht keine wirkliche Verarbeitung der Ereignisse vornimmt, beschränkt sich die Arbeit des Empfängers auf das Verteilen der eintreenden Ereignisse auf die verbundenen Komponenten der Ereignis-Verarbeitungs-Schicht. Diese Verteilung sollte in einen eigenen Thread oder Prozess ausgelagert werden, um direkt das nächste, eintreende Event verteilen zu können. So kann verhindert werden, dass sich zu empfangende Ereignisse aufstauen, wenn diese nicht schnell genug verteilt werden. Die Asynchronität ist aber auf jeden Fall gewährleistet, da der Sender nicht auf das Verteilen seines Ereignisses auf der Empfängerseite warten muss, bis er das nächste schicken kann. Im Gegensatz dazu steht der Ansatz über HTTP. Wie im Versuchsaufbau in beschrieben, wird hier vom Sender die Antwort auf den HTTP-Request erwartet. Bis diese nicht empfangen wurde, blockiert der Sender und kann keine neuen Ereignisse versenden. Das bedeutet, dass der Empfänger sofort eine (leere) Antwort auf den HTTP-Request verschicken muss, bevor er mit der Verteilung des Ereignisses beginnt. Da ein HTTP-Server darauf ausgelegt ist, viele konkurrierende Anfragen zu beantworten, werden folgende eintreende Ereignisse automatisch von neuen HTTP-Request-Handlern bearbeitet. Ist dies gegeben, dann kann auch bei dieser Lösung die Asynchronität gewährleistet werden. Beim letzten Ansatz, dem Versenden der Ereignisse mit Hilfe von AMQP, ist die Asynchronität durch die Verwendung einer MOM und der damit gegebenen, starken Entkopplung zwischen Sender und Empfänger gegeben. Der Sender kann ohne Pause Ereignisse verschicken, der oder die Empfänger werden vom MOM-Server asynchron bedient. Seite 77

83 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.5. Techniken für die externe Kommunikation Die zweite zu erfüllende Anforderung betrit die Bidirektionalität der Kommunikation. Da alle Kommunikationsendpunkte gleichberechtigt sind, also Events sowohl senden als auch empfangen können sollen, müssen die Events in beiden sich so ergebenden Richtungen zugestellt werden können (vgl ). Die Etablierung einer bidirektionalen Kommunikation ist mit dem Ansatz der reinen Sockets bei der Verwendung von TCP über eine einzelne Socketverbindung realisierbar. Bei TCP handelt es sich um ein Full-Duplex-Protokoll 13, darum kann über eine einzelne Verbindung gleichzeitig empfangen als auch gesendet werden. Wird das Lesen aus einem Socket in einem nebenläugen Thread realisiert, kann ohne zu blockieren eine bidirektionale Verbindung betrieben werden. Bei der Initialisierung der Endpunkte muss dabei lediglich speziziert werden, ob der jeweilige Endpunkt initial als Client oder Server agiert, also eine Verbindung zu einem entfernten Rechner aufbauen soll oder einen Listening-Socket önen muss. Auf dem dann entweder durch die Methode connect() oder accept() erzeugten Socket kann anschlieÿend gelesen und geschrieben werden. Diese Methoden stehen so oder so ähnlich in jeder Programmierumgebung zur Verfügung, mit welcher Socketkommunikation betrieben werden kann. Alternativ könnten auch zwei eigenständige Verbindungen aufgebaut werden. Durch das (zu entwickelnde) Protokoll müsste dann beim Verbindungsaufbau kommuniziert werden, welchem Nutzen (Lesen oder Schreiben) eine neu erönete Socketverbindung dienen soll. Dazu ein Beispiel: Zunächst werden ein Client und ein Server festgelegt. So wird festgelegt, welche Seite den Aufbau der Kommunikationsverbindung initiieren muss. Der Client önet die erste Verbindung zum Server und gibt an, dass er diese Socketverbindung gerne zum Schreiben verwenden würde. Der Server erzeugt beim Annehmen der Verbindung mittels accept() einen neuen Socket, auf dem diese Verbindung zum Client fortan gehalten wird. Aus diesem Socket kann der Server nun eingehende Daten des Clients empfangen. Anschlieÿend önet der Client eine weitere Verbindung zum Server. Für die entstehende Verbindung gibt er jedoch diesmal an, sie zum Empfang von Daten nutzen zu wollen. Der Server erhält diese Information und nutzt die so etablierte Socketverbindung, um Daten an den Client zu senden. Bei der Verwendung von HTTP ist es schwieriger, einen bidirektionalen Kommunikationsweg zu nden. HTTP ist nicht auf dauerhafte Verbindungen ausgelegt, über die Daten in beide Richtungen versendet werden. Es handelt sich um ein Protokoll, welches für ein REQUEST- RESPONSE Modell entworfen wurde. Bei diesem Modell wird von einem Client und einem Server ausgegangen, von denen jeder seine spezische Rolle spielt und diese Rollen nicht getauscht werden. Der Client sendet einen Request an den Server, welcher dann auf diesen antwortet. Der Server sendet entsprechend keine Daten, ohne einen vorhergehenden Request eines Clients. Genau genommen ist dem Server der Client vor dem Request gar nicht bekannt. Nach dem erfolgreichen Abarbeiten des Requests verliert der Server die Kenntnis über den Client. Man kann von einem PULL-Verfahren sprechen. Im Gegensatz dazu steht die PUSH -Methode, die es dem Server erlauben würde, unangefordert Daten zum Client zu senden. Im Rahmen des Web 2.0 und Technologien wie Asynchronous JavaScript and XML (AJAX) ist bereits eine Methode ent abgerufen am Seite 78

84 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.5. Techniken für die externe Kommunikation wickelt worden, um dieses pushen von Daten trotz des eigentlichen PULL-Prinzips des Modells zu ermöglichen. Möchte ein Client auch unangefordert Daten vom Server erhalten, so sendet er zunächst einen Request, welcher aber nicht sofort vom Server beantwortet wird. Stattdessen wartet der Server mit seiner Antwort, bis er Daten zum Client übermitteln möchte. Um einem Timeout der Anfrage vorzubeugen, antwortet der Server vor Ablauf der Frist auch, wenn er keine Daten für den Client bereit hält. Dieser erkennt dann an der Antwort (diese ist dann leer oder beinhaltet eine Fehlermeldung), dass es keine Daten für ihn gab und stellt den nächsten Request, der dann so lange nicht beantwortet wird, bis Daten vorliegen. Dieses Spiel setzt sich fort, bis der Client kein Interesse mehr an neuen Daten hat. Der beschriebene Ansatz wird auch als Long Polling bezeichnet und stellt über den beschriebenen Weg eine PUSH-Funktionalität zur Verfügung. Allerdings gibt es bei dem Ansatz auch einige Probleme: Ein Request, welcher nicht sofort beantwortet wird, bedeutet unter Umständen eine Benutzung von Systemressourcen, welche für andere Requests nicht mehr zur Verfügung stehen. Diese werden erst wieder freigegeben, wenn der Request schlieÿlich beantwortet wird. Besonders deutlich wird dies beim populären 14 Webserver Apache, der für jeden neuen Request einen eigenen Kindprozess startet. Eine Alternative Möglichkeit, die Kommunikation unter der Verwendung von HTTP bidirektional zu gestalten, wäre, auf jedem der Kommunikationspartner einen eigenen Webserver zu betreiben. So würden jeweils der Hin- und Rückkanal über gegenseitige Requests an den Server des jeweiligen Kommunikationspartner laufen. Dieser Ansatz führt jedoch spätestens auf mobilen Endgeräten zu Problemen, besonders weil die benötigten Resourcen in keinem Verhältnis zum Nutzen stehen. Ebenso ist das Betreiben eines Dienstes auf einem mobilen Endgerät schwierig, da die Datenverbindung nicht als stabil einzustufen ist. In jedem Fall muss jedoch gesagt werden, dass die ursprüngliche angedachte Verwendung des Protokolls, Daten auf Anfrage bereitzustellen, dem Einsatzzweck in diesem speziellen Anwendungsfall nicht gerecht wird. Hier geht es schlieÿlich darum, Daten zu senden, ohne vorher dazu aufgefordert zu werden. Um mit AMQP eine bidirektionale Kommunikation zu etablieren, bietet sich die Verwendung des Publisher-Subscriber-Modells an. Insbesondere für die Übermittlung von Daten mit Beteiligung von mobilen Kommunikationspartnern erweist sich dieses Modell als günstig[6]. Bei der Verwendung diesen Modells werden Nachrichten an den AMQP-Server gesendet, welcher die Nachrichten an alle registrierten Subscriber weiter vermittelt. Dies funktioniert, indem sich Subscriber auf dem Server für Nachrichten mit einem bestimmten Merkmal registrieren. Die Ausprägung dieses Merkmals ist je nach eingesetzter MOM-Software unterschiedlich. So können beispielsweise in den Nachrichten bestimmte Flags gesetzt oder andere Metainformationen an die Nachricht gekoppelt werden. Ebenso eignet sich die Verwendung von unterschiedlichen Kontexten zur Unterscheidung von Nachrichten, wenn die Software unterschiedliche Kontexte unterstützt. Das Merkmal ist dann der verwendete Kontext. Registriert sich ein Client für Nachrichten mit einem Merkmal X und sendet ausgehende Nachrichten ebenfalls mit dem Merkmal X, so kann er in beide Richtungen kommunizieren abgerufen am Seite 79

85 Kapitel 4. Konzept einer CEP-Umgebung auf mobilen Geräten 4.5. Techniken für die externe Kommunikation Der letzte Gesichtspunkt, unter dem die drei Möglichkeiten betrachtet werden müssen, betrit die möglichen Abbrüche der Datenverbindung von mobilen Geräten. In diesem Zuge ist das Augenmerk auch auf die variablen Adressen zu richten, unter denen die Geräte erreichbar sind. Da die Kommunikation auch zwischen einzelnen, mobilen Endgeräten möglich sein soll, ist die Verwendung eines Vermittlungsservers unumgänglich. Auf eine andere Weise können die Geräte nicht in direkten Kontakt treten, da ihre Adressen untereinander nicht bekannt sind und sich durchgehend ändern können. Somit muss auf einen konstanten, durchgehend unter der gleichen Adresse erreichbaren Vermittlungsservice zurückgegrien werden. Mit Hilfe dieses zentralen Dienstes kann dann eine Kommunikation zwischen den Geräten aufgenommen werden, da alle Geräte die Adresse dieses Services kennen. Entweder läuft die Kommunikation dann über diesen zentralen Service, oder der Service stellt zumindest die Verbindungsdaten der jeweiligen Gegenstelle zur Verfügung, damit dann direkt zwischen den Partnern kommuniziert werden kann. Bei den Ansätzen, die HTTP bzw. AMQP benutzen ist dieser Aufbau leicht umzusetzen, da sie unter allen Umständen eine Server-Komponente benötigen. Seite 80

86 5 Beispiel-Implementierung auf Google Android Im letzten Kapitel ist ein generelles Kozept für die Umsetzung einer Complex Event Processing Lösung auf einem mobilen System erarbeitet worden. Jenes Konzept wird in einer Beispiel- Implementierung für die Plattform Google Android umgesetzt. Dieses Kapitel behandelt die Realisierung des Konzepts für die angesprochene Plattform. Dabei wird insbesondere auf Details der Implementierung eingegangen, die die konzeptuelle Vorarbeit erweitern. Ebenso werden explizit die Umsetzungen näher betrachtet, welche im Konzept schon als implementierungsabhängig gekennzeichnet wurden. Es wird jedoch nicht jedes einzelne Detail der Implementierung besprochen, da die Entwicklung einer Applikation nicht dem Kern der Arbeit zuzuordnen ist. Die Dokumentation aller androidspezischer Klassen sowie Ausdrücke benden sich im Google Android Developer Guide[9]. Werden nicht-androidspezische Klassen oder Bibliotheken angesprochen, so wird dies ausdrücklich gekennzeichnet. 5.1 Rahmenbedingungen Vorab werden die Rahmenbedingungen für die Entwicklung beschrieben. Dabei werden sowohl die eingesetzte Software, als auch die verwendete Hardware kurz vorgestellt Die Entwicklungsumgebung Die Entwicklungsumgebung kann so, wie sie genutzt wird, auf allen gängigen Betriebssystemen eingerichtet werden. Als IDE kommt Eclipse 1 zum Einsatz. Diese freie, in Java implementierte IDE ist ursprünglich für die Entwicklung von Javaanwendungen entwickelt worden. Für die Entwicklung von Android-Applikationen stellt Google ein entsprechendes SDK 2 und eine Erweiterung für Eclipse 3 zur Verfügung. Das SDK steht für Windows, Linus und MacOS Betriebssysteme zur Verfügung. Unter anderem stellt das SDK auch einen Emulator zur Verfügung, mit welchem Geräte nachgebildet werden können, auf denen die entwickelte Software schlieÿlich getestet werden kann abgerufen am abgerufen am abgerufen am Seite 81

87 Kapitel 5. Beispiel-Implementierung auf Google Android 5.2. Die Basis-Applikation Nach der Installation von Eclipse und der Integration des SDK sowie der Erweiterung für Eclipse kann die Entwicklung einer Applikation für Google Android beginnen Das mobile Endgerät Auch ein mobiles Endgerät mit Google Android wird bei der Entwicklung verwendet. Somit kann die entwickelte Software auch auf einem echten Gerät getestet werden. Bei der verwendeten Hardware handelt es sich um ein Google Nexus One 4. Das Gerät verfügt über 512 MB RAM, einen Qualcomm Prozessor mit 1 GHz Taktrate und diverse, nutzbare Extras wie zum Beispiel GPS zur Positionsbestimmung oder auch einem Lagesensor. Abbildung 5.1: Das Google Nexus One 5.2 Die Basis-Applikation Basis der Applikation bildet eine Activity, also eine Anwendung mit einem Benutzerinterface, welche im Vordergrund betrieben wird. Die Anwendung verfügt lediglich über einen einzigen Screen, auf dem die notwendigen Einstellungen getätigt werden und das Absenden der Events getriggert werden kann. Abbildung 5.2 zeigt die gestartete Anwendung. Innerhalb der Anwendung wird ein Event Processing Network aufgebaut und zum Senden von Events an ein Backend genutzt. Dabei kann der zum Senden zu nutzende Channel, in Gestalt seines Typs, frei gewählt werden. Dieser Typ wird im Event vermerkt und später im Netzwerk als Routinginformation genutzt. Zum besseren Verständnis zeig Abbildung 5.3 das genutzte EPN. Die Verwendung einer Activity bietet im Wesentlichen drei Vorteile. Der erste Vorteil ist, dass eine dynamischen Konguration von bestimmten Einstellungen möglich ist. Der zweite Vorteil entsteht durch die Möglichkeit eines visuellen Feedbacks für den Nutzer der Software. So sind zum Beispiel sichtbare Statusupdates bei gesendeten Events oder auch die Ausgabe von Fehlern möglich. Der letzte Vorteil wird durch den Lebenszyklus einer Vordergrundapplikation deutlich abgerufen am Seite 82

88 Kapitel 5. Beispiel-Implementierung auf Google Android 5.3. Umsetzung der Einzelkomponenten Abbildung 5.2: Die Beispiel-Applikation Abbildung 5.3: Das EPN der Beispiel-Applikation Diese wird mit hoher Wahrscheinlichkeit nicht unerwartet vom System beendet, sondern es wird versucht, ihr alle notwendigen Ressourcen zur Verfügung zu stellen[9]. 5.3 Umsetzung der Einzelkomponenten Die Komponenten, welche im Konzept vorgestellt worden sind, können eins zu eins mit der Programmiersprache Java umgesetzt werden. Entsprechend ergeben sich die auch auf Abbildung 4.9 abgebildeten Klassen und Interfaces als Grundgerüst für die CEP-Umgebung der Softwarelösung. Um das Netzwerk jedoch nutzen zu können, werden Implementierungen der abstrakten Klassen und Interfaces benötigt. Die Umsetzung dieser Implementierungen werden im Folgenden näher betrachtet. Seite 83

89 Kapitel 5. Beispiel-Implementierung auf Google Android 5.3. Umsetzung der Einzelkomponenten Event Die Events werden umgesetzt, wie es im Konzept vorgesehen ist (vgl ). Die eindeutige ID wird durch die Verwendung der Klasse java.util.uuid realisiert, die ID selbst jedoch als java.lang.string abgespeichert. Dieses Verfahren wird angewendet, um die Serialisierung später zu vereinfachen. Der Zeitstempel des Events wird durch Verwendung der Klasse java.util.date realisiert. Zusätzlich erhalten Events noch das Attribut classname. Dieses Attribut wird mit dem Namen der Eventklasse befüllt. Es handelt sich hierbei um einen Workaround für die Serialisierung und Deserialisierung der Events, dazu später mehr Event-Quelle Die Event-Quelle soll Ereignisse empfangen und diese dann in Events umwandeln können, welche schlieÿlich in den angeschlossenen Channel gegeben werden. Um Ereignisse zu empfangen, bietet sich in der Google Android Umgebung die Benutzung eines BroadcastReceivers an. Erweitert eine selbst geschriebene Klasse BroadcastReceiver, so kann die Klasse als Empfänger für Ereignisse im System registriert werden. Alternativ kann auch eine Variable in der Klasse als anonymer BroadcastReceiver initialisiert werden, welcher dann im System registriert werden kann. Die Ereignisse, welche empfangen werden können, werden als sogenannte Intents vom Betriebssystem an registrierte BroadcastReceiver weitergegeben. Diese Intents werden sowohl systemseitig generiert, können aber auch aus einer Applikation eines Drittanbieters gefeuert werden. Um einen BroadcastReceiver für bestimmte Intents zu registrieren, müssen zunächst die Intents speziziert werden, die empfangen werden sollen. Diese Spezikation wird durch einen String ausgedrückt. Die Registrierung kann jedoch ausschlieÿlich auf einem Service oder einer Activity durchgeführt werden, was bedeutet, dass die Event-Quelle eine Registrierung nicht ohne Wissen über die umgebende Applikation realisieren kann. Um dieses Problem mit einer möglichst generellen Lösung zu beheben, wird die abstrakte Klasse BroadcastReceiverSource entworfen. Abbildung 5.4: UML-Darstellung: Die Klasse BroadcastReceiverSource Seite 84

90 Kapitel 5. Beispiel-Implementierung auf Google Android 5.3. Umsetzung der Einzelkomponenten Diese Klasse erweitert die aus dem Konzept bekannte Klasse Source und fügt Eigenschaften hinzu, die es ermöglichen, aus per Broadcast verschickten Intents Events zu erzeugen. Abbildung 5.4 zeigt die Klasse in UML-Notation. Soll eine neue Event-Quelle erstellt werden, die auf eine bestimmte Art von Intents lauscht, so ist diese Klasse zu erweitern und die beiden abstrakten Methoden zu implementieren. Die Methode getintentfilterstring() muss dann den String zurückgeben, der zur Identikation der Intants dient, die empfangen werden sollen. Die Methode geteventforbundle(bundle bundle) bekommt ein Bundle übergeben. Solch ein Bundle wird vom Intent mitgeführt und beinhaltet Daten, die zum Intent gehören. Aus diesen Informationen werden nun Events gewonnen, dabei kann es sich um ein einzelnes Event pro empfangenen Intent (und damit Bundle) handeln, oder auch um mehrere. Der BroadcastReceiver innerhalb der BroadcastReceiverSource ist für alle Unterklassen gleich implementiert. Diese Implementierung kann Listing 5.1 entnommen werden. 1 mreceiver = new BroadcastReceiver () 2 { 4 public void onreceive ( final Context context, final Intent intent ) 5 { 6 final Bundle extras = intent. getextras () ; 7 if ( extras!= null ) 8 { 9 final List < Event > events = geteventforbundle ( extras ); 10 for ( final Event event : events ) 11 { 12 emitevent ( event ); 13 } 14 } 15 } 16 }; Listing 5.1: BroadcastReceiver-Implementierung in der Source-Oberklasse Die Registrierung der Quelle als BroadcastReceiver wird bei der Erstellung der Instanz vorgenommen. Die laufende Instanz des EventProcessingNetwork erstellt eine Instanz der Event- Quellen-Klasse und kommt über die Methode getintentfilter() an den IntentFilter, welcher zur Registrierung im System benötigt wird. Anschlieÿend kann das EventProcessingNetwork sich von der Quelle den BroadcastReceiver besorgen und diesen im System registrieren. Für die Registrierung muss das EventProcessingNetwork jedoch über eine Referenz auf die umgebende Activity verfügen, da auf dieser die Registrierung durchgeführt werden muss. Der Vorgang wird in Listing 5.2 gezeigt. Seite 85

91 Kapitel 5. Beispiel-Implementierung auf Google Android 5.3. Umsetzung der Einzelkomponenten 1 private void addreceiver ( final BroadcastReceiverSource source ) 2 { 3 sources. add ( source ); 4 final BroadcastReceiver receiver = source. getreceiver () ; 5 activity. registerreceiver ( receiver, source. getintentfilter () ); 6 receivers. add ( receiver ); 7 } Listing 5.2: Registrierung einer BroadcastReceiverSource als BroadcastReceiver In Zeile 6 des Listings kann man sehen, dass der BroadcastReceiver einer internen Liste hinzugefügt wird. Dies ist notwendig, um beim Beenden der Applikation sämtliche BroadcastReceiver wieder beim System abzumelden. Senden eines Intents per Broadcast Nachdem eine Quelle als BroadcastReceiver registriert ist, sollen ihr auch Ereignisse (in Form von Intents) zugespielt werden können. Um einen Intent per Broadcast zu verschicken, ist nicht viel Aufwand notwendig. Ein Beispiel zeigt Listing 5.3. Die Action, die dem Intent gegeben wird, sollte so angepasst werden, dass der entsprechende IntentFilter der Event-Quelle greift. 1 Intent i = new Intent () ; 2 i. setaction (" insert. some. action. name "); 3 i. putextra (" key ", " value "); 4 activity. getcontext (). sendbroadcast (i); Listing 5.3: Versenden eines Intent als Broadcast Channel Die Implementierung der Klasse Channel geht über das hinaus, was durch das Konzept für die Klasse vorgesehen ist. Im Abschnitt wurde bereits darauf hingewiesen, dass das Event Processing Network nicht blockierend arbeiten soll. Um dies zu erreichen, wird der Channel in der Implementierung mit einem ThreadPoolExecutor ausgestattet. In diesen werden beim Erhalt eines Events Runnables gegeben, die aus der Zustellung des Events an einen Empfänger bestehen. Der ThreadPoolExecutor wird dabei mit einer variablen Anzahl an Threads gestartet. Auf Abbildung 5.2 kann bei genauerem Hinsehen erkannt werden, dass die Anzahl an Threads über die Oberäche einstellbar ist. Bei den Implementierungen, die die Events auch an externe Systeme übermitteln, wird der ThreadPoolExecutor ebenfalls genutzt, um die Netzwerkkommunikation nebenläug auszugestalten. Somit werden durch die Verwendung des Konzeptes eines Thread-Pools im Channel, der anfallende Aufgaben dieses Channels jeder Art annimmt, mehrere Anforderungen auf einmal erfüllt. Seite 86

92 Kapitel 5. Beispiel-Implementierung auf Google Android 5.3. Umsetzung der Einzelkomponenten Abbildung 5.5: Das Auswahlmenu für den zu nutzenden Channel Für die Beispiel-Applikation werden verschiedene Arten von Channels benötigt. Diese sind, bis auf den zwischen Quelle und Agenten, allesamt in der Lage, Events an ein externes System zu übermitteln. Entsprechend erben alle verwendeten Implementierungen ausschlieÿlich von der Klasse RemoteChannel. Die Klasse RemoteChannel wird im Vergleich zur im Konzept vorgestellten Klasse erweitert. Diese Erweiterung zielt darauf ab, den im Channel denierten ThreadPoolExecutor für das Senden von Events zu nutzen. Die UML-Notation der erweiterten Klasse ist auf Abbildung 5.6 zu sehen. Abbildung 5.6: Das Auswahlmenu für den zu nutzenden Channel Seite 87

93 Kapitel 5. Beispiel-Implementierung auf Google Android 5.3. Umsetzung der Einzelkomponenten Die abstrakte Methode put(event e) wird in der Klasse RemoteChannel wie in Listing 5.4 implementiert. Dabei werden zunächst für alle lokalen Empfänger Runnable-Objekte erzeugt, die dann ausgeführt werden. Die Objekte sind dabei Instanzen einer inneren Klasse. Anschlieÿend wird das Event an den externen Kommunikationspartner übermittelt. Wie genau dies geschieht, muss in den erbenden Klassen durch Implementierung der Methode getsendeventtask festgelegt werden. 2 public void put ( Event event ) 3 { 4 for ( Consumer c : consumers ) 5 { 6 executor. execute ( new SendEventToConsumerTask (c, event )); 7 } 8 executor. execute ( getsendtask ( event )); 9 } Listing 5.4: Verteilung der Events an Empfänger (RemoteChannel) In der Applikation kann ausgesucht werden, welcher Channel-Typ zur Übermittlung genutzt werden soll. Das Menu zur Auswahl ist auf Abbildung 5.5 zu sehen. Es enthält die Channel, die die jeweilige Implementierung der, bereits in Abschnitt vorgestellten, Methoden zur Datenübertragung darstellen. Alle implementierten Channel werden im Folgenden näher beleuchtet. ListenerChannel Der ListenerChannel ist der einfachste, zu implementierende Channel. Er wird lediglich intern verwendet und dient zur Übermittlung der Events von der Quelle zu den Agenten. Die Implementierung der Methode put(event event) beschränkt sich auf Zeile 4 bis 7 der Implementierung für einen RemoteChannel, welche in Listing 5.4 zu sehen ist. HTTPClientChannel und HTTPURLConnectionChannel Die beiden Channel, welche die Kommunikation über HTTP abwickeln, werden für die Beispiel- Anwendung lediglich unidirektional implementiert. Dieser Umstand wird damit begründet, dass vom Remotesystem keine Events empfangen werden müssen. Die beiden Channel verfügen über einen org.apache.http.impl.client.defaulthttpclient bzw. eine java.net.url. Über diese beiden Objekte werden aus den Runnables, mit denen schlieÿlich die Events gesendet werden, Verbindungen aquiriert. Dabei kommt es nicht zu Problemen durch das Multithreading, da die entsprechenden Methoden threadsafe implementiert sind. Im Gegensatz zu den noch folgenden Channels wird auch nicht in jedem Thread eine Verbindung vorgehalten, die dann durchgehend benutzt wird. Diese Vereinfachung der Implementierung ist dem internen Connection-Pooling zu danken. Sowohl beim Erstellen eines neuen HttpRequest als auch bei der Anforderung einer neuen HTTP-Verbindung mittels java.net.url.openconnection() werden vorhandene Verbindungen genutzt und nicht zwangsläug immer wieder neue erstellt. Dazu muss allerdings beim Seite 88

94 Kapitel 5. Beispiel-Implementierung auf Google Android 5.3. Umsetzung der Einzelkomponenten HTTPClientChannel die Klasse ThreadSafeClientConnManager als Connection Manager benutzt werden. Bei der Implementierung mit dem Paket java.net.urlconnection hingegen brauchen keine besonderen Vorkehrungen getroen werden. Das Senden der Events wird per einfachem Request an den HTTP-Server durchgeführt. Die Events werden dabei als POST-Daten des Requests versandt. Bei beiden Implementierungen wird der Name des jeweiligen Channels nicht als identizierendes Merkmal eingesetzt. Dies lieÿe sich jedoch einfach realisieren, indem entweder eine bestimmte URL des Servers für den Request genutzt wird (wie z.b. NAME) oder indem der Name als weiteres Datum an den Request gehängt wird. Die Empfangsrichtung wurde nicht implementiert, der Name des Channels könnte jedoch ebenfalls mit dem URL-Schema abgedeckt werden (Beispiel: SocketConnectionChannel Der SocketConnectionChannel wird, wie die beiden HTTP-Channel ebenfalls nur unidirektional implementiert. Da für die Verbindung auf reine Sockets gesetzt wird, ndet ein automatisches Pooling der Verbindungen hier nicht statt. Um trotzdem nicht für jedes zu sendende Event eine Verbindung zu önen, wird eine optimierte Implementierung benötigt. Jeder Thread, der die anfallenden Aufgaben im ThreadPool abarbeitet, bekommt einen eigenen OutputStreamWriter zugeordnet, welcher auf einem eigenen Socket arbeitet. In Verbindung mit einer xen, maximalen Gröÿe des Pools, werden so nur eine bestimmte Anzahl Sockets geönet. Für die Umsetzung dieses Konzepts muss dem ThreadPoolExecutor eine alternative ThreadFactory zugewiesen werden, die die speziellen Threads bereit stellt. Der ThreadFactory werden bei ihrer Instanziierung eine Liste von OutputStreamWriter übergeben. Aus dieser Liste wird jedem erzeugten Thread ein OutputStreamWriter zugeteilt. Im Runnable, wird auf den OutputStreamWriter des aktuellen Threads zugegrien und dieser Writer zum Senden von Daten genutzt. Veranschaulicht ist dies in Listing 5.5. Auch beim SocketConnectionChannel wird der Name des Channels nicht bei der Kommunikation beachtet. Dies hängt vor allem mit dem fehlenden Protokoll zusammen, welches für den Einsatz des SocketConnectionChannel in der Beispiel-Applikation nicht entwickelt worden ist. Seite 89

95 Kapitel 5. Beispiel-Implementierung auf Google Android 5.3. Umsetzung der Einzelkomponenten 2 public void run () 3 { 4 SocketThread st = ( SocketThread ) Thread. currentthread () ; 5 OutputStreamWriter writer = st. getwriter () ; 6 try 7 { 8 writer. write ( new String ( serializer. serialize ( mevent )) + "\n"); 9 writer. flush () ; 10 } catch ( Exception e) 11 { 12 e. printstacktrace () ; 13 } 14 } Listing 5.5: Versenden eines Events per Socket RabbitMQChannel Die gleiche Problematik wie bei der Verwendung von Sockets kommt auch beim RabbitMQChannel zum Tragen. Auch hier ist vorerst kein Pooling der Verbindungen möglich, da es keine einfach zu nutzende Funktionalität für ein solches gibt. Stattdessen wird, analog zur Lösung im SocketConnectionChannel, jedem Thread eine autonome Verbindung zum Server zur Verfügung gestellt. Anstelle eines OutputStreamWriters erhält jeder Thread in diesem Fall jedoch einen com.rabbitmq.client.channel, über den kommuniziert werden kann. Im Gegensatz zu den bisher vorgestellten Implementierungen, wird beim RabbitMQChannel der Name des Channels verwendet. Er dient zur Bestimmung des Topics, in welchem der Channel als Publisher bzw. Subscriber von Events auftritt. Ebenfalls im Unterschied zu den vorher beschriebenen Implementierungen eines Channel kann der RabbitMQChannel Events auch von extern empfangen. Die Umsetzung ist denkbar einfach: Mit Hilfe eines weiteren Threads registriert sich der RabbitMQChannel als Subscriber auf dem Topic, welches seinen Namen trägt. Dies wird allerdings nur durchgeführt, wenn mindestens ein lokaler Empfänger im RabbitMQChannel registriert ist, um Ressourcen zu schonen. Beim Senden von Events an das Topic lässt sich nicht verhindern, dass sie dem selben RabbitMQChannel wieder zugestellt werden. Aus der Sicht des RabbitMQ-Servers sind Publisher und Subscriber auf dem Topic zwei unterschiedliche Identitäten, auch, wenn beide Rollen von einer Instanz eines RabbitMQChannel gespielt werden. Um diese reektierten Events nicht an die lokal angeschlossenen Empfänger weiterzuleiten, erhalten die abgesendeten Events eine eindeutige ID, die die Instanz des sendenden RabbitMQChannels kennzeichnet. Beim Empfang eines Events von auÿerhalb wird geprüft, ob das Event die ID des empfangenen RabbitMQChannels trägt. Ist dies der Fall, so wird das Event verworfen, weil es von genau diesem Channel selbst versandt worden ist. Seite 90

96 Kapitel 5. Beispiel-Implementierung auf Google Android 5.3. Umsetzung der Einzelkomponenten EventSerializer Die Komponente zur Serialisierung erzeugt und verarbeitet Zeichenketten im JSON-Format. Hierfür wird die Bibliothek Gson eingesetzt (vgl ). Um bei der Deserialisierung den richtigen Event-Typen wiederherzustellen zu können, wird der Name der Klasse benötigt. Da dieser im vormals erzeugten String normalerweise nicht auftreten würde, trägt jedes Event seinen Namen als Attribut mit sich. Der Wert des entsprechenden Attributs wird extrahiert und mittels Reection die zu erzeugende Klasse ermittelt. Mit dem Wissen um die Klasse, welche entstehen soll, kann dann die Gson-API benutzt werden, um das Event mit dem korrekten Typ wiederherzustellen ChannelFactory Wie in Abschnitt vorgeschlagen, kommt eine ChannelFactory zum Einsatz. In dieser Klasse werden die Instanzen derchannel erzeugt und verwaltet. Für die Erzeugung werden dabei die Möglichkeiten der Reection genutzt, welche in Google Android zur Verfügung steht. Die Instanzen der Channel werden mit ihrem Namen als Schlüsselwert in einer Map<String, Channel> hinterlegt. Ein Channel kann von der Factory angefordert werden, indem die Methode getchannel(string channelname, String channelclassname) aufgerufen wird. Diese Methode überprüft zunächst, ob schon ein Channel mit dem gewünschten Namen existiert. Existiert kein solcher Channel, so wird eine Instanz des angeforderten Typs erzeugt, in der Map hinterlegt und zurück gegeben. Ist jedoch bereits ein Channel mit dem Namen in der Map hinterlegt und ist dieser auch noch vom angeforderten Typ, dann wird der Channel zurückgegeben. Konikte werden durch das Werfen von einer entsprechenden Exception angezeigt. Es kann beispielsweise passieren, dass ein Channel mit dem angegebenen Namen schon existiert, sein Typ jedoch vom angeforderten Typ abweicht. In diesem Fall kann keine Fehlerbehebung stattnden, da der Channel nicht einfach gelöscht werden kann. Tritt dieser Fehler also auf, muss der Aufrufer der Methode wissen, wie er weiter verfahren möchte. Die Klasse ChannelFactory ist auf Abbildung 5.7 in UML-Notation zu sehen. Abbildung 5.7: UML-Darstellung: Die Klasse ChannelFactory EventProcessingNetwork Auch die Klasse EventProcessingNetwork wird so implementiert, wie sie im Konzept vorgegeben ist. Innerhalb der Klasse existiert jedoch keine Liste von Channels, da eine solche Liste von der ChannelFactory erhalten werden kann. Die Speicherung des Aufbaus des EPN wird in der Implementierung schon während des Betriebs, und nicht erst beim Aufruf der persist()- Methode durchgeführt. Sobald dem Netzwerk eine neue Komponente hinzugefügt wird, speichert Seite 91

Complex Event Processing für intelligente mobile M2M- Kommunikation

Complex Event Processing für intelligente mobile M2M- Kommunikation Complex Event Processing für intelligente mobile 2- Kommunikation Hochschule Hannover arcel etzdorf, Prof. Dr. Ralf Bruns, Prof. Dr. Jürgen Dunkel, Henrik asbruch Inside 2 Ilja Hellwich, Sven Kasten 2

Mehr

ANDROID. Analyse der Android Plattform. Andre Rein, Johannes Florian Tietje. 28. Oktober 2010. FH-Gieÿen-Friedberg Android Praktikum

ANDROID. Analyse der Android Plattform. Andre Rein, Johannes Florian Tietje. 28. Oktober 2010. FH-Gieÿen-Friedberg Android Praktikum Analyse der Android Plattform Andre Rein, Johannes Florian Tietje FH-Gieÿen-Friedberg Android Praktikum 28. Oktober 2010 Topics 1 Übersicht Android Plattform Application Framework Activities und Services

Mehr

Lastenheft. Zielbestimmungen. Produkteinsatz. swp11-4. 3. Mai 2011. Franz Teichmann, Robert Röÿling swp11-4 3. Mai 2011

Lastenheft. Zielbestimmungen. Produkteinsatz. swp11-4. 3. Mai 2011. Franz Teichmann, Robert Röÿling swp11-4 3. Mai 2011 Lastenheft swp11-4 3. Mai 2011 Zielbestimmungen In der heutigen Geschäftswelt stehen mittelständische Unternehmen vor dem Dilemma, einerseits interne und externe Kommunikation in angemessener Weise gewährleisten

Mehr

SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen

SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen WEITER BLICKEN. MEHR ERKENNEN. BESSER ENTSCHEIDEN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN VERSION 1.0 OPTIMIERUNG VON ABFRAGEN IN MS SQL

Mehr

Geschäftsbereich Mobile Services Was ist Android?

Geschäftsbereich Mobile Services Was ist Android? Geschäftsbereich Mobile Services Was ist Android? Hinter Hoben 149 53129 Bonn www.visionera.de Ansprechpartner: Arno Becker arno.becker@visionera.de +49 228 555 1111 +49 160 98965856 Einleitung Android

Mehr

Complex Event Processing im Überblick

Complex Event Processing im Überblick Complex Event Processing im Überblick 2 Complex Event Processing ist eine von David Luckham entwickelte Softwaretechnologie, um kontinuierliche Ereignisströme zu verarbeiten [17]. Dieses Kapitel stellt

Mehr

Erfolgreiches mobiles Arbeiten. Markus Meys

Erfolgreiches mobiles Arbeiten. Markus Meys Erfolgreiches mobiles Arbeiten Markus Meys Die Themen im Überblick Faktoren für erfolgreiches mobiles Arbeiten Cloud App und andere tolle Begriffe Welche Geräte kann ich nutzen? Planung Was möchte ich

Mehr

Event Stream Processing & Complex Event Processing. Dirk Bade

Event Stream Processing & Complex Event Processing. Dirk Bade Event Stream Processing & Complex Event Processing Dirk Bade Die Folien sind angelehnt an eine Präsentation der Orientation in Objects GmbH, 2009 Motivation Business Activity Monitoring Sammlung, Analyse

Mehr

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

Mehr

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH Complex Hosting Autor.: Monika Olschewski Whitepaper Version: 1.0 Erstellt am: 14.07.2010 ADACOR Hosting GmbH Kaiserleistrasse 51 63067 Offenbach am Main info@adacor.com www.adacor.com Complex Hosting

Mehr

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1)

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) 1 FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) In dieser Kurseinheit geht es um verteilte Anwendungen, bei denen wir sowohl ein Client- als auch ein

Mehr

SMARTPHONES. Möglichkeiten, Gefahren, Sicherheit Best Practice Peter Teufl

SMARTPHONES. Möglichkeiten, Gefahren, Sicherheit Best Practice Peter Teufl SMARTPHONES Möglichkeiten, Gefahren, Sicherheit Best Practice Peter Teufl A-SIT/Smartphones iphone security analysis (Q1 2010) Blackberry security analysis (Q1 2010) Qualifizierte Signaturen und Smartphones

Mehr

Antwortzeitverhalten von Online Storage Services im Vergleich

Antwortzeitverhalten von Online Storage Services im Vergleich EPOD Encrypted Private Online Disc Antwortzeitverhalten von Online Storage Services im Vergleich Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee

Mehr

Der Auftritt von WWAN: Welche Bedeutung hat WWAN für den mobilen Berufstätigen?

Der Auftritt von WWAN: Welche Bedeutung hat WWAN für den mobilen Berufstätigen? Hauptartikel Der Auftritt von Breitband-WWAN Der Auftritt von WWAN: Welche Bedeutung hat WWAN für den mobilen Berufstätigen? Eine nahtlose High-Speed-Verbindung wird immer wichtiger sowohl für den Erfolg

Mehr

Hardware- und Software-Anforderungen IBeeS.ERP

Hardware- und Software-Anforderungen IBeeS.ERP Hardware- und Software-Anforderungen IBeeS.ERP IBeeS GmbH Stand 08.2015 www.ibees.de Seite 1 von 8 Inhalt 1 Hardware-Anforderungen für eine IBeeS.ERP - Applikation... 3 1.1 Server... 3 1.1.1 Allgemeines

Mehr

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

Philosophie & Tätigkeiten. Geschäftsfelder. Software Engineering. Business Applikationen. Mobile Applikationen. Web Applikationen.

Philosophie & Tätigkeiten. Geschäftsfelder. Software Engineering. Business Applikationen. Mobile Applikationen. Web Applikationen. Philosophie & Tätigkeiten Wir sind ein Unternehmen, welches sich mit der Umsetzung kundenspezifischer Softwareprodukte und IT-Lösungen beschäftigt. Wir unterstützen unsere Kunde während des gesamten Projektprozesses,

Mehr

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND

NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND NOCTUA by init.at DAS FLEXIBLE MONITORING WEBFRONTEND init.at informationstechnologie GmbH - Tannhäuserplatz 2 - A-1150 Wien - www.init.at Dieses Dokument und alle Teile von ihm bilden ein geistiges Eigentum

Mehr

Von der UML nach C++

Von der UML nach C++ 22 Von der UML nach C++ Dieses Kapitel behandelt die folgenden Themen: Vererbung Interfaces Assoziationen Multiplizität Aggregation Komposition Die Unified Modeling Language (UML) ist eine weit verbreitete

Mehr

Für den Zugriff vom PC aus die TCP/IP Netzwerkeinstellung des PC auf DHCP bzw. automatisch stellen,

Für den Zugriff vom PC aus die TCP/IP Netzwerkeinstellung des PC auf DHCP bzw. automatisch stellen, DIGITRONIC GmbH - Seite: 1 Ausgabe: 11.05.2012 Einstellanleitung GSM XSBOXR6VE Diese Anleitung gilt für die Firmware Version 1.1 Zunächst die SIM Karte mit der richtigen Nummer einsetzten (siehe Lieferschein).

Mehr

Tablet-PCs. Preise, Tarifarten und Kostenfallen

Tablet-PCs. Preise, Tarifarten und Kostenfallen Tablet-PCs Preise, Tarifarten und Kostenfallen Stand: 09. Dezember 2011 Agenda 1. Zusammenfassung 2. Preisvergleich 3. Hilfe bei der Wahl des passenden Tarifs 4. Kostenfallen 2 Agenda 1. Zusammenfassung

Mehr

Prozesse und Scheduling

Prozesse und Scheduling Betriebssysteme für Wirtschaftsinformatiker SS04 KLAUSUR Vorbereitung mit Lösungen / Blatt 1 Prozesse und Scheduling Aufgabe 1 : Scheduling Gegeben seien die folgenden Prozesse und die Längen des jeweiligen

Mehr

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests Masterarbeit zur Erlangung des akademischen Grades Master of Science (M.Sc.) im Masterstudiengang Wirtschaftswissenschaft

Mehr

VDLUFA-Schriftenreihe 1

VDLUFA-Schriftenreihe 1 VDLUFA-Schriftenreihe 1 Wie viele Apps sind ein LIMS? J. Flekna Pragmatis GmbH, Neufahrn 1. Einleitung Seitdem mobile Endgeräte massentauglich sind, ist die Bezeichnung App fester Bestandteil unseres zeitgeistigen

Mehr

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges Komponentenbasierte Client-Architektur Hamburg, 16.11.2007 Bernd Olleck IT-Beratung Olleck Agenda Clients aus drei verschiedenen Perspektiven: Technische Infrastruktur Fachliche Sicht Aufgaben eines Clients

Mehr

Online Help StruxureWare Data Center Expert

Online Help StruxureWare Data Center Expert Online Help StruxureWare Data Center Expert Version 7.2.7 Virtuelle StruxureWare Data Center Expert-Appliance Der StruxureWare Data Center Expert-7.2-Server ist als virtuelle Appliance verfügbar, die auf

Mehr

Was ist VoIP. Ist-Zustand

Was ist VoIP. Ist-Zustand Was ist VoIP Unter Internet-Telefonie bzw. IP-Telefonie (Internet Protokoll-Telefonie; auch Voice over IP (VoIP)) versteht man das Telefonieren über e, die nach Internet-Standards aufgebaut sind. Dabei

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

App-Entwicklung für Android

App-Entwicklung für Android App-Entwicklung für Android Einleitung - Systemarchitektur Hochschule Darmstadt WS15/16 1 Inhalt Historie Systemarchitektur Sandbox 2 Motivation Kontra Pro Limitierte Größe Begrenzte Ressourcen Kein Standardgerät

Mehr

UMTS Verbindungen mit dem EuroPC_mobile Laptop

UMTS Verbindungen mit dem EuroPC_mobile Laptop UMTS Verbindungen mit dem EuroPC_mobile Laptop UGS2P2 Version 1.4 - Stand 20.01.2010 Inhaltsverzeichnis 1. Einleitung...2 2. Freigegebene Datenkarten...3 3. Inbetriebnahme der Karte...4 3.1 Installation

Mehr

Caching Handbuch. Auftraggeber: Version: 01. INM Inter Network Marketing AG Usterstrasse 202 CH-8620 Wetzikon

Caching Handbuch. Auftraggeber: Version: 01. INM Inter Network Marketing AG Usterstrasse 202 CH-8620 Wetzikon Caching Handbuch Auftraggeber: Version: 01 Projekttyp: Erstellt durch: Internet David Bürge INM Inter Network Marketing AG Usterstrasse 202 CH-8620 Wetzikon Email david.buerge@inm.ch URL http://www.inm.ch

Mehr

Einführung in die OPC-Technik

Einführung in die OPC-Technik Einführung in die OPC-Technik Was ist OPC? OPC, als Standartschnittstelle der Zukunft, steht für OLE for Process Control,und basiert auf dem Komponentenmodel der Firma Microsoft,dem Hersteller des Betriebssystems

Mehr

Systemvoraussetzungen und Installation

Systemvoraussetzungen und Installation Systemvoraussetzungen und Installation Inhaltsverzeichnis Inhaltsverzeichnis... 2 1. Einleitung... 2 2. Einzelarbeitsplatzinstallation... 3 3. Referenz: Client/Server-Installation... 5 3.1. Variante A:

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 5 26.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: Erläutern

Mehr

GMM WLAN-Transmitter

GMM WLAN-Transmitter Inhaltsverzeichnis 1. Produktbeschreibung... 2 2. Konfiguration... 2 Verbindung... 2 Konfiguration der Baudrate... 2 Access Point... 3 3. Datenübertragung... 3 4. Technische Daten... 4 Kontakt... 5 1 1.

Mehr

Vodafone Cloud. Einfach A1. A1.net/cloud

Vodafone Cloud. Einfach A1. A1.net/cloud Einfach A1. A1.net/cloud Ihr sicherer Online-Speicher für Ihre wichtigsten Daten auf Handy und PC Die Vodafone Cloud ist Ihr sicherer Online-Speicher für Ihre Bilder, Videos, Musik und andere Daten. Der

Mehr

CEPaaS. Complex Event Processing as a Service. Bernhard Seeger Philipps-Universität Marburg RTM Realtime Monitoring GmbH

CEPaaS. Complex Event Processing as a Service. Bernhard Seeger Philipps-Universität Marburg RTM Realtime Monitoring GmbH CEPaaS Complex Event Processing as a Service Bernhard Seeger Philipps-Universität Marburg RTM Realtime Monitoring GmbH Daniar Achakeyev, Daniel Schäfer, Philip Schmiegelt CEP-Forschung in Marburg: aus

Mehr

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem 1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem Management, Access Management a. Event Management b. Service Desk c. Facilities Management d. Change Management e. Request Fulfilment

Mehr

Grundlagen der Verwendung von make

Grundlagen der Verwendung von make Kurzskript zum Thema: Grundlagen der Verwendung von make Stefan Junghans Gregor Gilka 16. November 2012 1 Einleitung In diesem Teilskript sollen die Grundlagen der Verwendung des Programmes make und der

Mehr

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit 1 Hochverfügbarkeit Lernziele: Network Load Balancing (NLB) Failover-Servercluster Verwalten der Failover Cluster Rolle Arbeiten mit virtuellen Maschinen Prüfungsanforderungen von Microsoft: Configure

Mehr

Mobile Security Smartphones

Mobile Security Smartphones Mobile Security Smartphones Schmelztiegel privater und geschäftlicher Aktivitäten eberhard@keyon.ch V1.1 2011 by keyon (www.keyon.ch) Über Keyon Warum Smartphones Welcher Nutzen wird vom Unternehmen erwartet?

Mehr

bintec elmeg Filialisten Lösungen mit WLAN Controllern IP Access WLAN ITK VoIP / VoVPN IT Security UC Unified Teldat Group Company

bintec elmeg Filialisten Lösungen mit WLAN Controllern IP Access WLAN ITK VoIP / VoVPN IT Security UC Unified Teldat Group Company Filialisten Lösungen mit WLAN Controllern Autor: Hans-Dieter Wahl, Produktmanager bei Teldat GmbH IP Access WLAN ITK VoIP / Vo IT Security UC Unified Communications WLAN Netzwerke findet man inzwischen

Mehr

WebRTU. Schritt-für-Schritt. Anleitungen

WebRTU. Schritt-für-Schritt. Anleitungen Schritt-für-Schritt WebRTU Anleitungen 1. Lokale Ein- und Ausgänge einlesen 2. Daten externer Geräte einlesen 3. Daten an externe Geräte senden 4. Modem einstellen 5. SMS-Alarmierung bei Grenzwertüberschreitung

Mehr

Internetzugänge - Technik, Tarife und Fallen

Internetzugänge - Technik, Tarife und Fallen zugang Was ist das? Dienste im zugänge - Technik, Tarife und Fallen anschluss anbieter David Mika Verein zur Förderung der privaten Nutzung e.v. Donnerstag, den 26. April 2012 1 / 34 Themenüberblick zugang

Mehr

KOMPETENZ IN SOFTWARE

KOMPETENZ IN SOFTWARE KOMPETENZ IN SOFTWARE Software- und App-Entwicklung Automotive-Software Elektromobilität Collaboration und Business Intelligence BATTERY STATUS BATTERY STATUS c4c engineering GmbH kompetenz in Software,

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

1 Verarbeitung personenbezogener Daten

1 Verarbeitung personenbezogener Daten .WIEN WHOIS-Politik Inhalt 1 Verarbeitung personenbezogener Daten... 1 2 Zur Verwendung gesammelte Informationen... 1 3 WHOIS-Suchfunktion... 2 3.1 Einleitung... 2 3.2 Zweck... 3 3.3 Identifizieren von

Mehr

OMICRON App zur Steuerung eines Messgeräts

OMICRON App zur Steuerung eines Messgeräts Mobile Lösungen im industriellen Umfeld jetzt die Chancen nutzen! Die Benutzerführung auf Tablets und Smartphones hat die Gestaltung von Bedienoberflächen revolutioniert. Interaktionskonzepte wie Multitouch

Mehr

PDF FormServer Quickstart

PDF FormServer Quickstart PDF FormServer Quickstart 1. Voraussetzungen Der PDF FormServer benötigt als Basis einen Computer mit den Betriebssystemen Windows 98SE, Windows NT, Windows 2000, Windows XP Pro, Windows 2000 Server oder

Mehr

Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim

Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim Sven Hartlieb Cloud-Computing Seminar Hochschule Mannheim WS0910 1/23 Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim Sven Hartlieb Fakultät für Informatik Hochschule

Mehr

Wirtschaftlichkeitsanalyse von Cloud Computing aus der Sicht internationaler Unternehmen. Masterarbeit

Wirtschaftlichkeitsanalyse von Cloud Computing aus der Sicht internationaler Unternehmen. Masterarbeit Wirtschaftlichkeitsanalyse von Cloud Computing aus der Sicht internationaler Unternehmen Masterarbeit zur Erlangung des akademischen Grades Master of Science (M.Sc.) im Masterstudiengang Wirtschaftswissenschaft

Mehr

GeoPilot (Android) die App

GeoPilot (Android) die App GeoPilot (Android) die App Mit der neuen Rademacher GeoPilot App machen Sie Ihr Android Smartphone zum Sensor und steuern beliebige Szenen über den HomePilot. Die App beinhaltet zwei Funktionen, zum einen

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Mobile Data Monitor Erfassung, Überwachung und Analyse von übertragenen Datenmengen

Mobile Data Monitor Erfassung, Überwachung und Analyse von übertragenen Datenmengen Mobile Data Monitor Erfassung, Überwachung und Analyse von übertragenen Datenmengen Testdokumente Semesterarbeit von: Juli 2005 Mobile Data Monitor Seite 71 / 106 5.3 Testing Folgende Tests wurden durchgeführt.

Mehr

whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN

whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN CLOUD-ENTWICKLUNG: BESTE METHODEN 1 Cloud-basierte Lösungen sind auf dem IT-Markt immer weiter verbreitet und werden von immer mehr

Mehr

Hard- und Software Aastra 415/430/470, IntelliGate 150/300/2025/2045/2065

Hard- und Software Aastra 415/430/470, IntelliGate 150/300/2025/2045/2065 Hard- und Software Aastra 415/430/470, IntelliGate 150/300/2025/2045/2065 Treiber und Applikationen Autor Open Interface Plattform und OIP Applikationen Michael Egl, Ascotel System Engineer 1.1 Kommunikation

Mehr

Die Zukunft der Telekommunikation. Rückblick und Ausblick

Die Zukunft der Telekommunikation. Rückblick und Ausblick Die Zukunft der Telekommunikation Rückblick und Ausblick Die Zukunft voraussagen? Prognosen sind schwierig, besonders wenn sie die Zukunft betreffen > Mark Twain Die beste Art die Zukunft vorauszusagen,

Mehr

Mobile Plattform für effiziente Verkehrs-Informationsdienste. mobile info

Mobile Plattform für effiziente Verkehrs-Informationsdienste. mobile info Mobile Plattform für effiziente Verkehrs-Informationsdienste mobile info Das Projekt mobile.info erweitert die Potentiale von Verkehrsinformationen Das Problem Die Verkehrsbelastung auf europäischen Straßen

Mehr

Information Lifecycle Management (ILM) - neue Speicherkonzepte für die digitale Archivierung. Dr. Bernhard Wentz

Information Lifecycle Management (ILM) - neue Speicherkonzepte für die digitale Archivierung. Dr. Bernhard Wentz Information Lifecycle Management (ILM) - neue Speicherkonzepte für die digitale Archivierung Einleitung und Motivation Medizinische IT-Anwendungssysteme komplexe hoch funktionale Systeme Basisfunktionen

Mehr

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik - Arbeitsheft

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik - Arbeitsheft Lösungen zu ---- Informations- und Telekommunikationstechnik - Arbeitsheft Handlungsschritt Aufgabe a) Die TCP/IP-Protokollfamilie verwendet logischen Adressen für die Rechner (IP- Adressen), die eine

Mehr

Einblick in die VMware Infrastruktur

Einblick in die VMware Infrastruktur Einblick in die VMware Infrastruktur Rainer Sennwitz Lehrstuhl für Informatik IV Friedrich-Alexander-Universität Erlangen-Nürnberg 4. Juli 2007 Rainer

Mehr

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Name: Matrikel-Nr: Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Bitte schreiben Sie leserlich und antworten Sie kurz und präzise. 1. Zeichnen Sie das Schichten-Modell eines Computersystems und markieren

Mehr

Richtlinie zur.tirol WHOIS-Politik

Richtlinie zur.tirol WHOIS-Politik Richtlinie zur.tirol WHOIS-Politik Die vorliegende Policy soll nach österreichischem Rechtsverständnis ausgelegt werden. Im Streitfall ist die deutsche Version der Policy einer Übersetzung vorrangig. Inhalt

Mehr

Systeme 1. Kapitel 10. Virtualisierung

Systeme 1. Kapitel 10. Virtualisierung Systeme 1 Kapitel 10 Virtualisierung Virtualisierung Virtualisierung: Definition: Der Begriff Virtualisierung beschreibt eine Abstraktion von Computerhardware hin zu einer virtuellen Maschine. Tatsächlich

Mehr

Visualisierungssystem comvismc BuildSec

Visualisierungssystem comvismc BuildSec Visualisierungssystem comvismc BuildSec Mai 2014 Inhalt 1 Allgemeines...3 2 Kurzanleitung...4 3 comvismc BuildSec Applikationen...5 3.1 comvismc BuildSec (iphone)...5 3.2 comvismc BuildSec (Android)...5

Mehr

APPS ALS MARKETINGINSTRUMENT NUTZEN

APPS ALS MARKETINGINSTRUMENT NUTZEN APPS ALS MARKETINGINSTRUMENT NUTZEN Die Tendenz, mobile Endgeräte als Marketing- Plattform zu nutzen ist steigend. Laut einer Umfrage des Bundesverbandes Digitale Wirtschaft e.v. (BVDW) erwarten Beschäftigte

Mehr

Lastenheft. Auftraggeber IBR Abteilung ALG

Lastenheft. Auftraggeber IBR Abteilung ALG Lastenheft Auftraggeber IBR Abteilung ALG Versionsübersicht Version Datum Autor Status Kommentar 1.0 9. 2. 2011 Auftraggeber 1.1 1. 4. 2011 Auftraggeber Ergänzung Miniflur, Personenerkennung 1.1.1 6. 4.

Mehr

IT-Security on Cloud Computing

IT-Security on Cloud Computing Abbildung 1: IT-Sicherheit des Cloud Computing Name, Vorname: Ebert, Philipp Geb.: 23.06.1993 Studiengang: Angewandte Informatik, 3. FS Beruf: IT-Systemelektroniker Abgabedatum: 08.12.2014 Kurzfassung

Mehr

Smartphone Entwicklung mit Android und Java

Smartphone Entwicklung mit Android und Java Smartphone Entwicklung mit Android und Java predic8 GmbH Moltkestr. 40 53173 Bonn Tel: (0228)5552576-0 www.predic8.de info@predic8.de Was ist Android Offene Plattform für mobile Geräte Software Kompletter

Mehr

Diplomarbeit von Lars Gohlke. University of Applied Sciences Brandenburg

Diplomarbeit von Lars Gohlke. University of Applied Sciences Brandenburg Diplomarbeit von Lars Gohlke University of Applied Sciences Brandenburg Inhalt Motivation Skype SOA in 5 Schritten Anwendung + Demo Seite 2 Motivation Kommunikation einfach - schnell preiswert - verläßlich

Mehr

Universität Passau. Prof. Dr. Carola Jungwirth. Bachelorarbeit

Universität Passau. Prof. Dr. Carola Jungwirth. Bachelorarbeit Universität Passau Lehrstuhl für Betriebswirtschaftslehre mit Schwerpunkt Internationales Management Prof. Dr. Carola Jungwirth Bachelorarbeit Der Einsatz moderner Medien und Kommunikationsmöglichkeiten

Mehr

Sichere Nutzung und schnelle Anpassung von Sensornetzen

Sichere Nutzung und schnelle Anpassung von Sensornetzen Sichere Nutzung und schnelle Anpassung von Sensornetzen Dienstorientierte Sensornetze bieten Flexibilität für Benutzer und Entwickler Einleitung Der Einsatz von Sensornetzen ermöglicht die Überwachung

Mehr

SDD System Design Document

SDD System Design Document SDD Software Konstruktion WS01/02 Gruppe 4 1. Einleitung Das vorliegende Dokument richtet sich vor allem an die Entwickler, aber auch an den Kunden, der das enstehende System verwenden wird. Es soll einen

Mehr

Gateway für netzwerkfähige Komponenten ewon kann als Gateway für alle netzwerkfähigen Komponenten dienen

Gateway für netzwerkfähige Komponenten ewon kann als Gateway für alle netzwerkfähigen Komponenten dienen ewon - Technical Note Nr. 005 Version 1.3 Gateway für netzwerkfähige Komponenten ewon kann als Gateway für alle netzwerkfähigen Komponenten dienen 08.08.2006/SI Übersicht: 1. Thema 2. Benötigte Komponenten

Mehr

Bedienungsanleitung für PolterPhones (Smartphones ohne Touchscreen) Inhaltsverzeichnis

Bedienungsanleitung für PolterPhones (Smartphones ohne Touchscreen) Inhaltsverzeichnis Bedienungsanleitung für PolterPhones (Smartphones ohne Touchscreen) Inhaltsverzeichnis 1. Allgemeines... 2 1.1 Einschalten... 2 1.2 Polter Programm starten... 2 1.3 Info Anzeige... 2 1.4 Haupt Fenster...

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

PIWIN II. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II. Vorlesung 2 SWS SS 08

PIWIN II. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II. Vorlesung 2 SWS SS 08 PIWIN II Kap. 3: Verteilte Systeme & Rechnernetze 1 PIWIN II Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II Vorlesung 2 SWS SS 08 Fakultät für Informatik Technische

Mehr

RAID. Name: Artur Neumann

RAID. Name: Artur Neumann Name: Inhaltsverzeichnis 1 Was ist RAID 3 1.1 RAID-Level... 3 2 Wozu RAID 3 3 Wie werden RAID Gruppen verwaltet 3 3.1 Software RAID... 3 3.2 Hardware RAID... 4 4 Die Verschiedenen RAID-Level 4 4.1 RAID

Mehr

iphone App. www.woistwer24.de Bedienungsanleitung für die iphone App. Wichtiger Hinweis:

iphone App. www.woistwer24.de Bedienungsanleitung für die iphone App. Wichtiger Hinweis: iphone App. www.woistwer24.de Bedienungsanleitung für die iphone App. Wichtiger Hinweis: Wir haben bei der Entwicklung der iphone App. darauf geachtet, eine einfache Bedienung und eine stabile Anwendung

Mehr

Benutzeranleitung emailarchiv.ch

Benutzeranleitung emailarchiv.ch Benutzeranleitung emailarchiv.ch Luzern, 14.03.2014 Inhalt 1 Zugriff... 3 2 Anmelden... 3 2.1 Anmeldung über den Browser... 3 2.2 Anmeldung über das Outlook Plug-In... 4 3 Das Mailarchiv... 5 3.1 Überblick...

Mehr

pimoto - Ein System zum verteilten passiven Monitoring von Sensornetzen

pimoto - Ein System zum verteilten passiven Monitoring von Sensornetzen pimoto - Ein System zum verteilten passiven Monitoring von Sensornetzen Rodrigo Nebel Institut für Informatik Lehrstuhl für Rechnernetze und Kommunikationssysteme (Informatik 7) Friedrich-Alexander-Universität

Mehr

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik Arbeitsheft, 3. Auflage

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik Arbeitsheft, 3. Auflage 1. HANDLUNGSSCHRITT Wireless Local Area Network kabelloses lokales Netzwerk Aufgabe 14 Vorteile: einfache Installation, bequeme Nutzung durch mobile Geräte (z. B. Notebooks oder Tablet-PCs), geringe Kosten,

Mehr

Kurzanleitung für die Arbeit mit dem comosoft Helpdesk

Kurzanleitung für die Arbeit mit dem comosoft Helpdesk Kurzanleitung für die Arbeit mit dem comosoft Helpdesk 1. Der Start 2. Ticket-Erstellung 3. Prioritäten 4. Der Umgang mit Tickets 5. Der Umgang mit E-Mails 6. Der Downloadbereich 1 Der Start 1.1 URL Um

Mehr

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz Hochverfügbar und Skalierung mit und ohne RAC Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC Alexander Scholz Copyright its-people Alexander Scholz 1 Einleitung Hochverfügbarkeit

Mehr

Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden

Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden 27.05.13 Autor / Redakteur: Nach Unterlagen von National Instruments / Hendrik Härter Messdaten

Mehr

Mobile Device Management bei der SBB AG in Zusammenarbeit mit Ergon Informatik AG

Mobile Device Management bei der SBB AG in Zusammenarbeit mit Ergon Informatik AG Erhard Buchs SBB Peter K. Brandt Ergon Informatik Mobile Device Management bei der SBB AG in Zusammenarbeit mit Ergon Informatik AG Übersicht Erhard Buchs, SBB Ausgangslage Motivation Strategie SBB für

Mehr

VMware. Rainer Sennwitz.

VMware. Rainer Sennwitz. <Rainer.Sennwitz@andariel.informatik.uni-erlangen.de> VMware Rainer Sennwitz Lehrstuhl für Informatik IV Friedrich-Alexander-Universität Erlangen-Nürnberg 4. Juli 2007 Rainer Sennwitz VMware Inhalt Inhalt

Mehr

>Mobile Device Management Möglichkeiten und Grenzen unter Compliance Anforderungen

>Mobile Device Management Möglichkeiten und Grenzen unter Compliance Anforderungen >Mobile Device Management Möglichkeiten und Grenzen unter Compliance Anforderungen >Agenda Eigenschaften und Besonderheiten Sicherheitsrisiken und Bedrohungen Lösungsvarianten Grenzen des Mobile Device

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Yellowbill Adapter Spezifikationen Voraussetzungen Datum : 22.08.2013 Version : 1.0.0.2 22.08.2013 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung...3 2 Architektur...3 2.1 Grundsätze

Mehr

A-Plan 12.0. Zeiterfassung 2.0. Ausgabe 1.1. Copyright. Warenzeichenhinweise

A-Plan 12.0. Zeiterfassung 2.0. Ausgabe 1.1. Copyright. Warenzeichenhinweise A-Plan 12.0 Zeiterfassung 2.0 Ausgabe 1.1 Copyright Copyright 1996-2014 braintool software gmbh Kein Teil dieses Handbuches darf ohne ausdrückliche Genehmigung von braintool software gmbh auf mechanischem

Mehr

SiteAudit Knowledge Base. Move Add Change Tracking. Vorteile Übersicht. In diesem Artikel: Vorteile Übersicht Funktionsübersicht Berichte anpassen

SiteAudit Knowledge Base. Move Add Change Tracking. Vorteile Übersicht. In diesem Artikel: Vorteile Übersicht Funktionsübersicht Berichte anpassen SiteAudit Knowledge Base Move Add Change Tracking Dezember 2010 In diesem Artikel: Vorteile Übersicht Funktionsübersicht Berichte anpassen MAC Benachrichtigungen Vorteile Übersicht Heutzutage ändern sich

Mehr

Zeiterfassungsanlage Handbuch

Zeiterfassungsanlage Handbuch Zeiterfassungsanlage Handbuch Inhalt In diesem Handbuch werden Sie die Zeiterfassungsanlage kennen sowie verstehen lernen. Es wird beschrieben wie Sie die Anlage einstellen können und wie das Überwachungsprogramm

Mehr

Parallels Plesk Panel. Firewall-Modul für Parallels Plesk Panel 10 für Linux/Unix. Administratorhandbuch

Parallels Plesk Panel. Firewall-Modul für Parallels Plesk Panel 10 für Linux/Unix. Administratorhandbuch Parallels Plesk Panel Firewall-Modul für Parallels Plesk Panel 10 für Linux/Unix Administratorhandbuch Copyright-Vermerk Parallels Holdings, Ltd. c/o Parallels International GmbH Vordergasse 59 CH-Schaffhausen

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

TM1 mobile intelligence

TM1 mobile intelligence TM1 mobile intelligence TM1mobile ist eine hochportable, mobile Plattform State of the Art, realisiert als Mobile BI-Plug-In für IBM Cognos TM1 und konzipiert als Framework für die Realisierung anspruchsvoller

Mehr

GEO-DIENSTE AUF BASIS DER ANDROID-PLATTFORM. Seminar: Datenbankunterstützung für mobile GIS Michael Goj

GEO-DIENSTE AUF BASIS DER ANDROID-PLATTFORM. Seminar: Datenbankunterstützung für mobile GIS Michael Goj GEO-DIENSTE AUF BASIS DER ANDROID-PLATTFORM Seminar: Datenbankunterstützung für mobile GIS Michael Goj AGENDA Einleitung Standortbezogene Dienste und Anwendungen Geo-Dienste Die Android-Plattform Google

Mehr

Musterlösung Klausur SS 2004

Musterlösung Klausur SS 2004 Musterlösung Klausur SS 2004 Fachrichtung: Informatik Lehrveranstaltung: Verteilte Systeme Dozent: Prof. G. Bengel Tag: 15.6.04 Bearbeitungszeit: 90 Minuten Name:... Matr.Nr.:... Punkte:... Note:... Hilfsmittel:

Mehr

Business Process Execution Language. Christian Vollmer Oliver Garbe

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

Mehr

Installationsanleitung

Installationsanleitung Installationsanleitung POP3 und Bridge-Modus Inhaltsverzeichnis 1 POP3 und Bridge-Modus 2 1.1 Funktionsweise von POP3 mit REDDOXX 2 1.2 Betriebsarten 3 1.2.1 Standard-Modus 3 1.2.2 Bridge-Modus 6 1.2.3

Mehr

Performance Zertifizierung

Performance Zertifizierung Performance Zertifizierung Alois Schmid alois.schmid@itf-edv.de www.itf-edv.de Copyright 2012 ITF-EDV Fröschl GmbH Inhalt Firma.... Kapitel 1 Gründe für die Zertifizierung der Massendatentauglichkeit.....

Mehr