Ein adaptives Brokernetz für Publish/Subscribe Systeme

Diplomarbeit Ein adaptives Brokernetz für Publish/Subscribe Systeme vorgelegt von Helge Parzyjegla Berlin, den 26. Oktober 2005 Gutachter Prof. Dr. Hans-Ulrich Heiß Fachgebiet Kommunikations- und Betriebssysteme Fakultät IV Elektrotechnik und Informatik Technische Universität Berlin Dr.-Ing. Gero Mühl Fachgebiet Kommunikations- und Betriebssysteme Fakultät IV Elektrotechnik und Informatik Technische Universität Berlin Betreuer Dipl. Inf. Michael A. Jaeger Fachgebiet Kommunikations- und Betriebssysteme Fakultät IV Elektrotechnik und Informatik Technische Universität Berlin

ii

Inhaltsverzeichnis 1 Einleitung 1 1.1 Motivation.................................... 1 1.2 Ziele........................................ 2 1.3 Wissenschaftlicher Beitrag............................ 3 1.4 Aufbau der Arbeit................................ 3 2 Publish/Subscribe 5 2.1 Konzepte..................................... 5 2.1.1 Ereignisse, Notifikationen und Nachrichten.............. 5 2.1.2 Publisher, Subscriber und Broker.................... 6 2.1.3 Filter, Subskriptionen und Ankündigungen.............. 6 2.1.4 Filtermodelle............................... 7 2.1.5 Entkopplung............................... 8 2.1.6 Architekturen............................... 9 2.1.7 Routing-Algorithmen........................... 10 2.1.8 Multicast und Peer-to-Peer....................... 12 2.2 Systeme...................................... 14 2.2.1 Siena................................... 14 2.2.2 Gryphon................................. 14 2.2.3 Jedi.................................... 15 2.2.4 Rebeca.................................. 16 2.2.5 Hermes.................................. 17 2.3 Verwandte Arbeiten............................... 17 2.3.1 Selbstorganisation............................ 18 2.3.2 Selbststabilisierung............................ 18 2.3.3 Adaptivität und Selbstoptimierung................... 19 2.3.4 Rekonfiguration.............................. 21 3 Design eines adaptiven Brokernetzes 23 3.1 Kostenmodell................................... 23 3.1.1 Modell eines Publish/Subscribe Systems................ 23 3.1.2 Kostenfaktoren.............................. 25 3.1.3 Minimale und maximale Spannbäume................. 25 3.1.4 Optimale Publish/Subscribe Bäume.................. 27 3.1.5 NP-Vollständigkeit............................ 28 3.1.6 Konsequenzen............................... 30 3.2 Bestimmung gemeinsamer Brokerinteressen.................. 31 3.2.1 Assoziativität............................... 31 3.2.2 Caches................................... 33 3.2.3 Bloom-Filter............................... 34 iii

iv INHALTSVERZEICHNIS 3.2.4 Integration der Caches.......................... 35 3.3 Strategie des Algorithmus............................ 37 3.3.1 Grundlagen der Heuristik........................ 37 3.3.2 Bewertungsphase............................. 39 3.3.3 Abstimmungsphase............................ 40 3.3.4 Integration der Heuristik........................ 41 3.4 Rekonfiguration.................................. 46 3.4.1 Strawman Approach........................... 46 3.4.2 Grundlagen der Rekonfiguration.................... 49 3.4.3 Invarianten................................ 50 3.4.4 Integration des Rekonfigurationsalgorithmus.............. 53 3.4.5 Algorithmusdetails............................ 55 4 Implementierung 69 4.1 Übersicht..................................... 69 4.2 Broker....................................... 70 4.2.1 Warteschlangen.............................. 72 4.2.2 Routing-Tabelle............................. 72 4.2.3 Cache................................... 72 4.2.4 Lokale Umgebung............................ 73 4.3 Simulationsumgebung.............................. 73 4.3.1 Ereignisse................................. 75 4.3.2 Brokertopologien............................. 75 4.3.3 Applikationen............................... 77 4.3.4 Szenarien................................. 77 5 Simulation und Auswertung 79 5.1 Simulationsaufbau................................ 79 5.1.1 Netzwerktopologie............................ 79 5.1.2 Parameter................................. 80 5.1.3 Beispiel.................................. 81 5.2 Adaptionsgüte.................................. 81 5.2.1 Lastverteilung.............................. 83 5.2.2 Lokalität................................. 84 5.2.3 Kostenverhältnis............................. 86 5.3 Aufwand...................................... 88 5.3.1 Heuristik................................. 88 5.3.2 Rekonfiguration.............................. 90 5.3.3 Nachrichtenordnungen.......................... 91 6 Zusammenfassung 95 6.1 Bewertung..................................... 96 6.2 Ausblick...................................... 97 Literaturverzeichnis 99 A CD-ROM 111

Abbildungsverzeichnis 2.1 Ereignisbasierte Interaktion............................ 6 2.2 Illustration der Schnittstelle eines Publish/Subscribe Systems......... 7 2.3 Overlay-Netzwerk basierend auf einem physischen Netz............ 10 2.4 Verschiedene Brokertopologien.......................... 11 3.1 Modell eines Brokers................................ 24 3.2 Brokernetz basierend auf einem minimalen Spannbaum............ 26 3.3 Brokernetz basierend auf einem maximalen Spannbaum............ 27 3.4 Assoziativität und Ereignisverteilung...................... 32 3.5 Caches und Notifikationen............................ 34 3.6 Bloom-Filter mit drei Hashfunktionen...................... 35 3.7 Modell eines Brokers mit Cache......................... 36 3.8 Kosten verschiedener Verbindungsvarianten................... 38 3.9 Abstimmung über einen Rekonfigurationswunsch................ 41 3.10 Routing einer Broadcast-Nachricht........................ 42 3.11 Routing einer Request-Nachricht......................... 45 3.12 Illustration des Strawman Approachs...................... 47 3.13 Grundlagen des Rekonfigurationsalgorithmus.................. 49 3.14 Vermeiden von Notifikationsduplikaten..................... 51 3.15 Verzögern von Subskriptionen und Kündigungen................ 52 3.16 Garantie einer FIFO- und einer kausalen Ordnung der Notifikationen.... 53 3.17 Modell eines Brokers mit Cache und zusätzlichen Warteschlangen...... 54 3.18 Sperren des Rekonfigurationspfades....................... 55 3.19 Beginn des eigentlichen Rekonfigurationsprozesses............... 59 3.20 Routing der Separator-Nachrichten........................ 60 3.21 Durch Separator-Nachricht initiierte Aktionen................. 63 3.22 Freigabe des gesperrten Rekonfigurationspfades................. 64 3.23 Garantie der Nachrichtenvollständigkeit und -ordnung............. 66 4.1 UML-Klassendiagramm eines Brokers...................... 71 4.2 UML-Klassendiagramm der Simulationsumgebung............... 74 4.3 Beispiel einer Topologiedatei........................... 76 4.4 Beispiel einer Konfigurationsdatei........................ 77 5.1 Parameter der Simulationsexperimente..................... 80 5.2 Beispiel eines Simulationslaufs.......................... 82 5.3 Relative Verbesserung bei ungleichmäßiger Lastverteilung........... 84 5.4 Relative Verbesserung bei steigender Lokalität................. 86 5.5 Relative Verbesserung bei variierten Kostenverhältnissen........... 88 5.6 Relative Performanz und Kostenanteile..................... 89 5.7 Rekonfigurationskosten bei steigender Pfadlänge................ 91 5.8 Mittlere Verzögerungszeit bei steigender Pfadlänge............... 92 v

vi ABBILDUNGSVERZEICHNIS

Kapitel 1 Einleitung In den letzten Jahrzehnten haben sich Computer deutlich verändert aus riesigen Maschinen wurden kleine, tragbare Geräte, die trotzdem ein Vielfaches der Rechenleistung ihrer einstigen Vorfahren besitzen. Gleichzeitig nahm ihre Komplexität beständig zu, wobei auch heutzutage ein Ende dieser Entwicklung nicht abzusehen ist. Die Komplexität entsteht durch Abhängigkeiten einzelner Komponenten voneinander, die es erschweren das Verhalten des Gesamtsystems zu erfassen. In der Folge ist es schwierig zu bedienen und aufwändig zu warten. Daher ist die Beherrschung der Komplexität eine aktuelle Herausforderung und zugleich auch Voraussetzung für die weitere Entwicklung. In diesem Zusammenhang ist es eine faszinierende und vielversprechende Idee, Computersystemen die Fähigkeit zu geben, sich und ihre Komponenten selbständig verwalten zu können. Hierbei betrachtet IBMs Autonomic Computing Initiative [IBM01a] sogar den menschlichen Körper als inspirierendes Vorbild. Dessen autonomes Nervensystem reguliert automatisch Körperfunktionen wie Atmung und Herzschlag, ohne dass dem Menschen die inhärente Komplexität dieser Vorgänge bewusst ist. Analog sollen zukünftige Computersysteme sich autonom kontrollieren, so dass manuelle Eingriffe nur in Ausnahmefällen erforderlich sind. Natürlich besteht noch ein weiter Weg bis zum angestrebten Ziel des Autonomic Computings [GC03]. Mit der vorliegenden Arbeit unternehmen wir einen Schritt in diese Richtung. Im Bereich der Publish/Subscribe Systeme beschreiben wir die Entwicklung eines adaptiven Brokernetzes, dass sich selbständig rekonfiguriert und an die Topologie des Kommunikationsnetzes anpasst, jedoch gleichzeitig auch die Interessen der Anwendungen beachtet. 1.1 Motivation Mit abnehmender physischer Größe gelingt es Computern immer mehr Bereiche des täglichen Lebens zu durchdringen. Bereits heutzutage ist der Mensch von unzähligen Mikroprozessoren umgeben. Sie befinden sich beispielsweise in Fahrzeugen, Haushaltsgeräten oder Spielwaren. Einige Geräte, wie Persönliche Digitale Assistenten (PDAs) oder Mobiltelefone, vereinen Beweglichkeit, Rechenleistung und die Möglichkeit zur Kommunikation. Damit entstehen hochgradig vernetzte, mobile und intelligente Systeme, die zunehmend Mark Weisers Vision des Ubiquitous Computing[Wei91] entsprechen, in der eine mit computerisierten Artefakten angereicherte Umgebung den Menschen bei seinen Tätigkeiten in 1

2 1. EINLEITUNG unaufdringlicher Weise assistiert. Ein ähnliches Bild zeichnet auch der von IBM geprägte Begriff des Pervasive Computings[HMNS03] allerdings mit der Intention der breiten Anwendung bereits verfügbarer Technologien in Mobile- und Electronic-Commerce Szenarien. Ubiquitous und Pervasive Computing implizieren beide eine dynamische Welt mit einer gewaltigen Anzahl an kommunizierenden Geräten und Anwendungen, die Kommunikationsnetze und -infrastrukturen vor neue Herausforderungen stellt. Dabei ist absehbar, dass klassische Kommunikationsformen, insbesondere Client/Server Modelle, an ihre Grenzen stoßen. Sie sind zu unflexibel und scheitern bereits an der klassischen Rollenaufteilung in Client oder Server. Publish/Subscribe Systeme können hier ihr volles Potential ausschöpfen. Als ereignisbasierte Systeme ermöglichen sie eine Konzentration auf Kommunikationsinhalte, ohne Nachrichten direkt adressieren zu müssen. Inhaltsbasierte Filter erlauben den Anwendungen zudem die exakte Beschreibung und Auswahl der Ereignisse, für die sie sich interessieren. Beides zusammen gestattet eine lose und flexible Kopplung einzelner Komponenten, wie sie zukünftige dynamische Umgebungen benötigen. Doch auch schon heute helfen Publish/Subscribe Systeme die stetig wachsende Informations- und Datenflut einzudämmen, da eine Kommmunikation nur erfolgt, wenn einerseits eine neue Nachricht vorliegt und andererseits an ihr tatsächlich ein Interesse besteht. Derzeit gibt es eine Vielzahl von Implementierungen verteilter Publish/Subscribe Systeme, die auf einem Brokernetz basieren und einen Notifikationsdienst bilden. Allerdings besitzt ihr Brokernetz meist statische Strukturen, wodurch es sich als starr und unflexibel erweist. Sowohl die wachsende Größe des Netzes, beispielsweise in einem globalen Internet- Szenario, als auch die hohe Dynamik ubiquitärer Umgebungen werden jedoch letztlich eine Anpassung erfordern. Hierzu bieten gegenwärtige Systeme keine oder nur begrenzte manuelle Rekonfigurationsmöglichkeiten, die in beiden Fällen vom Aufwand nicht mehr zu vertreten sind. Folglich benötigen wir autonome, eigenständige Publish/Subscribe Systeme, die in der Lage sind sich selbst und insbesondere ihr Brokernetz, an die Topologie des Kommunikationsnetzes sowie den Anwendungsinteressen in dynamischen Umgebungen anzupassen. 1.2 Ziele Die Autonomic Computing Initiative definiert vier fundamentale Eigenschaften autonomer Computersysteme [GC03]. Zunächst besitzen sie die Fähigkeit sich selbst zu konfigurieren (engl. self-configuring). Für Einsatzzweck und -umgebung finden sie jeweils passende und sinnvolle Einstellungen. Dann sind sie in der Lage sich selbst zu heilen (engl. self-healing), indem sie auftretende Fehler eigenständig erkennen, diagnostizieren und schließlich beheben. Ferner sind autonome Systeme ständig bestrebt sich selbst zu optimieren (engl. self-optimising). Sie passen die Aufteilung ihrer Ressourcen kontinuierlich an, um stets eine optimale Funktionalität zu gewährleisten. Zuletzt wissen sie auch ihre Daten und Dienste zu schützen (engl. self-protecting). Unberechtigte Zugriffe oder Angriffe werden automatisch erkannt und verhindert. Die Betrachtung aller vier Eigenschaften würde im Kontext von Publish/Subscribe Systemen den Rahmen dieser Arbeit sprengen. Wir beschränken uns daher auf den Aspekt der Selbstoptimierung mit dem Ziel, die Performance eines Publish/Subscribe Systems durch Adaption seines Brokernetzes zu steigern. Dies umfasst folgende Punkte:

1.3. WISSENSCHAFTLICHER BEITRAG 3 Primäres Vorhaben ist die Entwicklung eines adaptiven, verteilten Algorithmus, der sich an die Topologie des Kommunikationsnetzes anpasst, dabei jedoch auch die Nachrichteninteressen der Anwendungen berücksichtigt. Im Ergebnis soll sowohl die Leistung des Routing-Verfahrens erhöht, als auch die Netzlast reduziert werden. Der Algorithmus soll möglichst universell einsetzbar sein. Hierfür müssen weitreichende und einschränkende Annahmen, beispielsweise über Nachrichtenhäufigkeiten und -verteilungen, vermieden werden. Die Rekonfiguration des Brokernetzes soll für Anwendungen kaum wahrzunehmen sein. Daher darf sie nur minimale Auswirkungen auf die Dienstgüte des Publish/ Subscribe Systems haben. 1.3 Wissenschaftlicher Beitrag Schwerpunkt dieser Arbeit ist die Entwicklung eines adaptiven Brokernetzes für Publish/ Subscribe Systeme. Die folgenden Punkte markieren wichtige Schritte im Entwicklungsprozess und bilden essentielle Bestandteile der Arbeit: Das Kostenmodell ist die Grundlage, auf der Rekonfigurationsentscheidungen getroffen werden. Mit seiner Hilfe führen wir den Nachweis, dass die Optimierung des Brokernetzes NP vollständig ist. Wir stellen ein Verfahren zur Bestimmung des gemeinsamen Nachrichteninteresses verschiedener Broker vor. Da das Verfahren auf Caches und Bloom-Filtern beruht, werden keine Annahmen über Nachrichten- bzw. Ereignisverteilungen benötigt. Kernstück des entwickelten Algorithmus ist eine Heuristik, die Broker mit gleichen Interessen möglichst direkt miteinander verbindet, sofern der Aufwand für das genutzte Kommunikationsnetz ein akzeptables Maß nicht übersteigt. Für die notwendige Rekonfiguration des Brokernetzes präsentieren wir eine Möglichkeit, die ohne Nachrichtenverlust auskommt und zudem Aufwand und Auswirkungen lokal begrenzt. Durch Queueing kann zusätzlich eine FIFO- bzw. kausale Ordung der Nachrichten gewährleistet werden. Durch Implementierung des Algorithmus und Simulation verschiedener Szenarien analysieren wir seine Charakteristika. Ebenfalls erfolgt ein Vergleich mit anderen Ansätzen und Verfahren. 1.4 Aufbau der Arbeit Im folgenden Kapitel 2 erläutern wir die Grundlagen des Publish/Subscribe Modells, wobei sowohl dessen Konzepte erörtert, als auch aktuelle Systeme vorgestellt werden. Ferner geben wir einen Überblick über verwandte Arbeiten, die vor allem Aspekte autonomer Systeme beinhalten. Kapitel 3 beschreibt den Entwurf eines adaptiven Brokernetzes für Publish/Subscribe Systeme. Zunächst stellen wir ein Kostenmodell und ein Verfahren zum Bestimmen gemeinsamer Brokerinteressen vor. Darauf aufbauend entwickeln wir eine Adaptionsheuristik sowie einen Rekonfigurationsalgorithmus.

4 1. EINLEITUNG Anschließend diskutiert Kapitel 4 sowohl die Implementierung der entwickelten Algorithmen und Verfahren, als auch den Aufbau einer flexiblen Simulationsumgebung zu ihrer Auswertung. Wir besprechen die Details der wichtigsten Klassen und erläutern die unter ihnen bestehenden Beziehungen und Abhängigkeiten. Kapitel 5 beschäftigt sich mit der Simulation und Evaluierung der Heuristik und des Rekonfigurationsalgorithmus. In verschiedenen Szenarien untersuchen wir sowohl die erreichte Adaptionsgüte, als auch den verursachten Aufwand und vergleichen die Ergebnisse mit denen anderer Verfahren und Ansätze. Abschließend fasst Kapitel 6 die geleistete Arbeit zusammen und bewertet die gewonnenen Ergebnisse. Ferner wird ein Ausblick auf weiterführende Thematiken und Aspekte gegeben.

Kapitel 2 Publish/Subscribe Dieses Kapitel widmen wir dem Publish/Subscribe Paradigma. Wir erläutern seine Grundlagen, die das Fundament dieser Arbeit bilden und auf denen nachfolgende Kapitel aufbauen. Zunächst werden maßgebliche Konzepte vorgestellt und dann deren Umsetzung in aktuellen Publish/Subscribe Systemen betrachtet. Abschließend geben wir eine kurze Zusammenfassung aktueller Forschung auf diesem Gebiet. Insbesondere interessieren uns Veröffentlichungen, die bewusst Aspekte autonomer Systeme thematisieren. 2.1 Konzepte Publish/Subscribe Systeme ermöglichen eine flexible ereignisbasierte Kommunikation. Ihre Flexibilität liegt in den genutzten Konzepten begründet, die wir im Folgenden erläutern. Wir beginnen unsere Betrachtung aus Sicht der Anwendungen und untersuchen, warum das Publish/Subscribe Modell insbesondere für zukünftige, dynamische Szenarien wie das Ubiquitous- oder Pervasive Computing geeignet ist. Anschließend interessieren wir uns mehr für technische Details der Systeme und diskutieren Varianten der Implementierung. 2.1.1 Ereignisse, Notifikationen und Nachrichten In ereignisbasierten Systemen interagieren Komponenten, indem sie Notifikationen austauschen und sich gegenseitig über aufgetretene Ereignisse informieren [CNRW98]. Ein Ereignis ist eine beobachtbare Zustandsänderung, die sowohl in der realen, physischen Welt, als auch im Inneren des Computers liegen kann. Beispielsweise kann ein physisches Ereignis durch einen Sensor registriert werden, was zu einer Änderung seines Messwertes führt. Aber auch das Ergebnis interner Rechenoperationen ist ein Ereignis, das den Abschluß der Berechnung markiert. Ereignisse können ebenfalls in Größe und Umfang variieren. Sowohl ein einfacher Hardwareinterrupt, als auch die komplexe Auftragsannahme in einer Electronic-Commerce Anwendung stellen in diesem Sinne Ereignisse dar. Möchte eine Komponente eine andere über ein Ereignis informieren, so erstellt sie hierzu eine Notifikation. Eine Notifikation enthält die notwendigen Daten, um das Ereignis und eventuell die Umstände seines Auftretens zu beschreiben [Zei04]. Gleichzeitig repräsentiert sie das Ereignis in der Form, in der es von anderen Komponenten verarbeitet werden kann. Gebräuchliche Datenmodelle sind Name/Wert Paare [CRW01], Objekte [EGD01] oder semi-strukturierte Daten im XML-Format [MF01]. 5

6 2. PUBLISH/SUBSCRIBE Ereignis Publisher Ereignisbasierte Interaktion Subscriber Notifikation Notifikation Broker Broker Nachricht Kommunikationsnetz Abbildung 2.1: Ereignisbasierte Interaktion. Die Zustellung der Notifikationen an interessierte Empfänger übernimmt ein Notifikationsdienst. Ist hierfür der Transport über ein Netzwerk erforderlich, so sprechen wir auf Netzebene von Nachrichten. Eine Nachricht ist schlicht der Transportcontainer einer Notifikation und praktisch meist die serialisierte Notifikation selbst. 2.1.2 Publisher, Subscriber und Broker In der Publish/Subscribe Welt wird ein Produzent von Notifikationen als Publisher 1 bezeichnet. Wir sagen, ein Publisher veröffentlicht oder publiziert Notifikationen, wann immer ein Ereignis auftritt. Ein Subscriber ist hingegen der Konsument von Notifikationen. Wir sagen, ein Subscriber abonniert oder subskribiert Notifikationen, für die er sich interessiert. Für eine Komponente gibt es keine feste Aufteilung der Rollen. Sie kann Publisher und zugleich Subscriber sein. Die Aufgabe des Notifikationsdienstes übernimmt das Publish/Subscribe System. Ein verteiltes Publish/Subscribe System besteht aus einer Menge untereinander vernetzter Broker. Für Publisher wie Subscriber bilden die Broker Schnittstelle und Zugangspunkte zum System. Abbildung 2.1 illustriert die ereignisbasierte Kommunikation in einem verteilten Publish/Subscribe System. Ein Publisher registriert ein Ereignis, worauf er eine Notifikation veröffentlicht und sie seinem lokalen Broker übergibt. Dieser sendet sie, verpackt in einer Nachricht, an den Broker des Subscribers, der die Notifikation dann ausliefert. 2.1.3 Filter, Subskriptionen und Ankündigungen Nicht jedes Ereignis ist bedeutend und daher nur ein Teil der Notifikationen relevant. Broker nutzen Filter, um die wichtigen Notifikationen von den uninteressanten zu trennen. 1 Sofern keine treffenden deutschen Übersetzungen existieren, werden englische Bezeichnungen verwendet.

2.1. KONZEPTE 7 advertise() unadvertise() publish() Broker subscribe() unsubscribe() notify() Publisher Subscriber Abbildung 2.2: Illustration der Schnittstelle eines Publish/Subscribe Systems. Ein Filter ist eine boolsche Funktion, mit der ein Broker eine erhaltene Notifikation auf ihre Relevanz testet. Entweder besteht an ihr Interesse oder nicht. Durch eine Subskription können Konsumenten ihr Interesse an bestimmten Notifikationen äußern. Eine Subskription enthält einen Filter, der genau die Notifikationen beschreibt, an denen der Subscriber interessiert ist. Er übergibt die Subskription dann seinem lokalen Broker, der das Filtern übernimmt. Während Filter sich nur auf den Inhalt einer Notifikation beziehen, können Subskriptionen noch Metadaten mit einschließen [Zei04]. Beispiele sind Sichtbarkeitsbereiche [FMG02a], Sicherheits- [BEP + 03] und Zeitinformationen [CFH + 03] sowie maximale Auslieferungsraten [MUHW04]. Auf der anderen Seite können Produzenten ihrem lokalen Broker durch eine Ankündigung mitteilen, welche Notifikationen sie veröffentlichen werden. Analog zu Subskriptionen enthalten Ankündigungen einen Filter, der den Inhalt zukünftiger Notifikationen festlegt. Diese Information kann vom Publish/Subscribe System zu Optimierungszwecken ausgenutzt werden. Allerdings kann auf Ankündigungen auch vollständig verzichtet werden, wenn implizit angenommen wird, dass jeder Publisher fähig ist, beliebige Notifikationen zu erzeugen. Abbildung 2.2 veranschaulicht Schnittstellen und zugehörige Operationen eines Publish/- Subscribe Systems. Durch subscribe()- und unsubscribe()- Aufrufe äußert ein Subscriber sein Interesse an Notifikationen bzw. widerruft es. Ein Publisher kann mit advertise() und unadvertise() die Erzeugung von Notifikationen an- bzw. aufkündigen. publish() und notify() dienen dem Veröffentlichen von Notifikationen bzw. deren Zustellung. 2.1.4 Filtermodelle Broker vertreten die Interessen ihrer Klienten. Sie filtern gewünschte Notifikationen heraus und benachrichtigen ihre Subscriber. Dem Wunsch der Subscriber nach einer möglichst präzisen Beschreibung der Interessen steht ein erhöhter Filteraufwand seitens der Broker gegenüber. Zwischen Ausdrucksstärke und Skalierbarkeit muss abgewogen werden [CRW99]. Nach ihrer Ausdrucksstärke unterscheiden wir im Wesentlichen fünf Filtermodelle [Zei04]: Kanalbasierte Filterung. Notifikationen werden in benannten Nachrichten-Kanälen veröffentlicht. Ein Subscriber kann einen oder mehrere Kanäle abonnieren und erhält dann alle dort publizierten Notifikationen. Eine differenziertere Auswahl findet nicht statt. Ein Beispiel ist der Corba Event Service [OMG04].

8 2. PUBLISH/SUBSCRIBE Themenbasierte Filterung. Jede Notifikation gehört zu einem Thema. Beispielsweise könnte IBMs aktueller Aktienkurs unter market.nyse.stock.stockquote.ibm veröffentlicht werden. Themen sind hierarchisch geordnet, wobei untergeordnete Kategorien den Notifikationsinhalt weiter eingrenzen. Jede Subskription bezieht sich auf ein bestimmtes Thema und kann auch untergeordnete Themen mit einschließen. Typbasierte Filterung. Notifikationen werden als Objekte betrachtet. Die Auswahl erfolgt anhand der Typhierarchie ihrer zugehörigen Klassen [EGD01]. Typbasierte Filterung ähnelt stark der themenbasierten, erweitert deren Ausdruckskraft jedoch um die Möglichkeit der Mehrfachvererbung (falls implementiert). Durch Kombination mit inhaltsbasierten Filtern kann die Selektion weiter verfeinert werden. Inhaltsbasierte Filterung. Inhaltsbasierte Filter erlauben die Selektion anhand beliebiger inhaltlicher Aspekte, was die Auswertung der gesamten Notifikation zulässt [Müh02]. Die Subscriber sind somit unabhängig von jeglicher Klassifizierung durch die Publisher. Die Ausdruckskraft wird nur durch die genutzten Filterprädikate und das Datenmodell der Notifikationen begrenzt [Zei04]. Vorgeschlagen werden u.a. Templates [CNF01], Filter für Name/Wert Paare [Müh01], XPath für XML [AF00] sowie der Einsatz von mobilem Programmcode [DMDP03]. Konzeptbasierte Filterung. Ereignisse lassen sich unterschiedlich beschreiben abhängig vom jeweiligen Kontext. Beispielsweise könnte ein New Yorker Aktienkurs das Attribut price=50$ tragen, wohingegen ein Frankfurter Kurs mit preis=50e gekennzeichnet wird. Konzeptbasierte Filterung [Cil02] berücksichtigt inhaltliche Transformationen und erlaubt die Auswahl von Notifikationen auf einem semantischen Niveau. Konzeptbasierte Filterung erweitert so die inhaltsbasierte, setzt jedoch wohl definierte Ontologien voraus [Zei04]. 2.1.5 Entkopplung Gegenüber dem weit verbreiteten Request/Reply Paradigma bietet Publish/Subscribe ein flexibleres Kommunikationsmodell. Die Flexibilität liegt vor allem in der Entkopplung der Kommunikationspartner begründet. Das Publish/Subscribe System agiert als neutraler Mediator zwischen Ereignisproduzenten und -konsumenten. Publisher und Subscriber werden in drei Dimensionen entkoppelt [EFGK03]: Entkopplung im Raum. Publisher und Subscriber müssen sich nicht gegenseitig kennen. Publisher veröffentlichen ihre Notifikationen und die Broker übernehmen deren Auslieferung an alle interessierten Subscriber. Dabei werden die Empfänger einzig aus dem Inhalt der Notifikation und den Filtern der abgegebenen Subskriptionen bestimmt. Die resultierende Gruppenkommunikation ist daten- bzw. inhaltszentriert und damit anonym sowie indirekt. Entkopplung in der Zeit. Durch den Einsatz von Caches [CFH + 03] können Broker Notifikationen temporär zwischenspeichern. Subscriber brauchen dann zum Veröffentlichungszeitpunkt einer Notifikation nicht mehr mit dem System verbunden zu sein. Die Notifikation kann auch später noch zugestellt werden, selbst wenn der Publisher nun seinerseits nicht mehr erreichbar ist.

2.1. KONZEPTE 9 Entkopplung in der Synchronisation. Publisher werden beim Veröffentlichen einer Notifikation nicht blockiert und deren Auslieferung an die Subscriber erfolgt asynchron durch Callbacks. Die Kontrollflüsse von Publishern und Subscribern sind daher nicht so stark miteinander verwoben und voneinander abhängig, wie dies bei entfernten Prozeduraufrufen im Request/Reply Modell üblich ist. Eine lose Kopplung einzelner Komponenten ist Voraussetzung für dynamische Szenarien wie das Ubiquitous- oder Pervasive Computing, in denen eine Vielzahl von Sensoren, Aktuatoren und mobilen Geräten miteinander kommunizieren. Publish/Subscribe erlaubt die asynchrone Benachrichtigung der Subscriber, wenn sich beispielsweise ein Sensormesswert ändert. Mit Request/Reply bliebe hingegen nur das ineffiziente periodische Abfragen des Sensors, um eine Änderung zu detektieren [FZ98]. Durch die indirekte, inhaltsbasierte Kommunikation brauchen Komponenten sich nicht mehr gegenseitig zu kennen. Der Sensor muss nicht wissen, welche und wieviele Anwendungen sich für seine Daten interessieren. Ein mobiles Gerät ist hauptsächlich daran interessiert, dass ein Dienst erbracht wird und weniger von wem. Publisher wie Subscriber müssen sich nicht um die Verwaltung von Adressinformationen kümmern, die sich in mobilen Welten zudem ständig ändern können. Das temporäre Zwischenspeichern von Notifikationen trägt hier ebenfalls den fragilen Verbindungen drahtloser Netze Rechnung [Zei04]. Das abrupte Abbrechen einer Verbindung muss in mobilen Szenarien Berücksichtigung finden. Publish/Subscribe Systeme können dies durch Caches auf Middleware-Ebene unterstützen und so einen Notifikations- und Datenverlust für die Anwendungen vermeiden. 2.1.6 Architekturen Einfache Publish/Subscribe Systeme bestehen nur aus einem Server, der für das Filtern und Ausliefern veröffentlichter Notifikationen verantwortlich ist. Erste Implementierungen folgten diesem zentralistischen, jedoch nicht skalierbaren Ansatz. Hingegen bestehen aktuelle Publish/Subscribe Systeme aus einer Anzahl untereinander vernetzter und kooperierender Broker. Die Broker bilden dabei ein logisches Overlay-Netzwerk [PB03a]. Zwei Broker müssen hierzu nicht notwendiger Weise direkt miteinander verbunden sein. Nachrichten können erst über mehrere physische Knoten des genutzten Kommunikationsnetzes laufen, ehe sie den jeweils anderen Broker erreichen. Abbildung 2.3 zeigt ein Overlay-Netzwerk basierend auf einem bespielhaften physischen Netz. Viele verteilte Publish/Subscribe Systeme unterscheiden sich in den Topologien ihrer Overlay-Netze. Im Folgenden differenzieren wir vier verschiedene Formen [Car98]: Hierarchische Topologie. Eine hierarchische Topologie entsteht durch Erweiterung des zentralistischen Ansatzes (mit einem Server). Jeder Broker hat eine Anzahl von Klienten, was Publisher und Subscriber, aber auch andere Broker sein können [Car98]. Ein Broker vertritt seine Klienten, indem er erhaltene Subskriptionen und Notifikationen an den jeweils übergeordneten Broker weiterleitet. Aus Sicht des übergeordneten Brokers erscheint dieser dann wie ein einfacher Publisher oder Subscriber und muss daher nicht gesondert behandelt werden. Abbildung 2.4(a) zeigt eine hierarchische Topologie. Broker sind als Kreise, Publisher und Subscriber als Rechtecke dargestellt.

10 2. PUBLISH/SUBSCRIBE Overlay- Netzwerk Physisches Netzwerk Abbildung 2.3: Overlay-Netzwerk basierend auf einem physischen Netz. Azyklische Topologie. Azyklische Topologien basieren wie hierarchische auf Baumstrukturen, benötigen jedoch keinen ausgezeichneten Wurzelknoten. Die Broker sind einander gleichgestellt und tauschen bidirektional Subskriptionen, Ankündigungen und Notifikationen aus. Abbildung 2.4(b) gibt ein Beispiel. Generische Topologie. In generischen Topologien, wie in Abbildung 2.4(c) dargestellt, werden zusätzliche Zyklen zugelassen, wodurch sich die Fehlertoleranz erhöht. Sind zwei Broker über mehr als einen Weg miteinander verbunden, kann eine Verbindung unterbrochen werden. Ebenfalls ist es möglich, die Last auf mehrere Wege zu verteilen. Allerdings konstruieren viele Routing-Algorithmen zunächst wieder azyklische Baumstrukturen, beispielsweise minimale Spannbäume für Publisher, auf denen sie dann effizient arbeiten [CW03, CRW04]. Die tatsächlich genutzten Verbindungen ergeben sich aus einer Überlagerung der konstruierten Bäume. Hybride Topologie. Hybride Topologien entstehen durch Kombination der obigen. Abbildung 2.4(d) illustriert eine generische Topologie mit zwei hierarchischen Subnetzen (Cluster). 2.1.7 Routing-Algorithmen Die Art und Weise, wie Broker untereinander Subskriptionen, Ankündigungen und Notifikationen austauschen, wird durch die genutzten Routing-Algorithmen bestimmt. Prinzipiell beeinflussen Subskriptionen, wohin passende Notifikationen geschickt werden. Wir unterscheiden folgende Routing-Algorithmen [Müh02]: Flooding. Flooding bezeichnet das kontrollierte Fluten des Brokernetzes. Die Notifikationen werden grundsätzlich an alle Broker gesendet. Deshalb brauchen Subskriptionen nicht weitergeleitet zu werden. Dieser triviale Ansatz ist nicht skalierbar [MFB02]. Da Broker grundsätzlich alle veröffentlichten Notifikationen erhalten, muss jeder von ihnen auch solche verarbeiten, für die sich kein Subscriber interessiert. Somit werden wertvolle Ressourcen verschwendet. Simple Routing. Simple Routing ist der einfachste inhaltsbasierte Routing-Algorithmus. Das Brokernetz wird mit Subskriptionen geflutet, so dass jeder Broker globales Wissen über alle Interessen besitzt. Ein Broker muss Notifikationen dann nur noch in die Richtungen weiterleiten, in denen sich weitere interessierte Broker befinden.

2.1. KONZEPTE 11 (a) (b) (c) (d) Abbildung 2.4: Verschiedene Brokertopologien: (a) hierarchische Topologie; (b) azyklische Topologie; (c) generische Topologie; (d) hybride Topologie (generisch/hierarchisch). Hierzu speichert er in einer Routing-Tabelle jeweils den Filter einer Subskription zusammen mit dem Nachbarbroker, von dem er sie erhalten hat. Empfangene Notifikationen werden gegen die Filter der Tabelle getestet und nur an die Nachbarn weitergeleitet, die einen passenden Routing-Eintrag haben. Identity-based Routing. Identity-based Routing nutzt Gemeinsamkeiten zwischen den Filtern zweier Subskriptionen aus, um die Größe der Routing-Tabellen und somit den Aufwand in jedem Routing-Schritt zu reduzieren [MFB02]. Das Weiterleiten einer Subskription an einen Nachbarn wird unterbunden, wenn an diesen bereits eine identische Subskription 2 gesendet wurde. Dies verringert die Anzahl seiner Routing- Einträge. Covering-based Routing. Covering-based Routing [CRW01] ist eine Erweiterung des Identity-based Routings. Subskriptionen, die nur eine Teilmenge an Notifikationen einer bereits übermittelten Subskription erfassen, werden ebenfalls nicht mehr weitergeleitet. Erst beim Kündigen der überdeckenden Subskription müssen sie übermittelt werden. Merging-based Routing. Merging-based Routing erlaubt Brokern ihre Routing-Einträge zu neuen, überdeckenden Subskriptionen zu verschmelzen, die sie anstatt der 2 Eine Subskription, die eine identische Menge an Notifikationen beschreibt.

12 2. PUBLISH/SUBSCRIBE Originale weiterleiten [MFB02]. So kann die Größe der Routing-Tabellen nochmals reduziert werden. Ankündigungen schränken ebenfalls die Weiterleitung von Subskriptionen ein. Subskriptionen müssen nur noch in die Teile des Overlay-Netzes propagiert werden, aus denen Ankündigungen stammen, die sich mit ihnen überschneiden. Für das Routing der Ankündigungen können alle oben vorgestellten Algorithmen, bis auf das Flooding, genutzt werden. Ebenfalls können unterschiedliche Algorithmen für das Weiterleiten von Subskriptionen und von Ankündigungen miteinander kombiniert werden. 2.1.8 Multicast und Peer-to-Peer Die im vorigen Abschnitt vorgestellten Algorithmen beschreiben das Routing im Overlay- Netz der Broker, wobei Gemeinsamkeiten der Filter von Subskriptionen sowie von Ankündigungen zur Optimierung genutzt werden. Doch können auch Mechanismen des zu Grunde liegenden Kommunikationsnetzes zur Leistungssteigerung eingesetzt werden. Beispielsweise bietet sich IP-Multicast [Dee89] für eine effiziente Gruppenkommunikation der Broker an. Aktuelle Arbeiten [PB02, Pie04] nutzen allerdings auch Peer-to-Peer Routing- Verfahren und daraus entstehende Overlay-Netze, um auf deren Grundlage Publish/Subscribe Systeme zu realisieren. Multicast. Multicast bezeichnet das Senden von Informationen an eine Gruppe von Empfängern. IP-Multicast-Nachrichten laufen hierbei nur einmal über jede Kante des Netzes und werden erst an den Knoten kopiert, an denen sich die Wege zu unterschiedlichen Empfängern trennen. Alle Beteiligten gehören einer gemeinsamen Multicast-Gruppe an. In themenbasierten Publish/Subscribe Systemen kann für jedes Thema eine Multicast- Gruppe eingerichtet werden, der die Broker bei Interesse ihrer Subscriber beitreten. Bei einer nur begrenzten Anzahl verfügbarer Multicast-Adressen und -Gruppen gegenüber einer großen Menge an Themen führt dieser Ansatz zum sogenannten Channelization Problem [AGK + 01]. Das Finden einer optimalen Zuordnung bezogen auf genutzte Ressourcen von Themen zu einzelnen Gruppen ist NP-vollständig [AGK + 01]. In inhaltsbasierten Systemen bestimmt erst der Inhalt einer Notifikation, an welche Broker sie gesendet wird. Die Menge der Empfänger kann sich so von Notifikation zu Notifikation ändern, wobei insgesamt 2 N mögliche Kombinationen bei N beteiligten Brokern existieren [OAA + 00]. Prinzipiell müsste daher eine exponentielle Anzahl von Multicast-Gruppen bereitgehalten werden, was nicht skalierbar ist und ebenfalls zu einem Channelization Problem führt 3. Die Anzahl genutzter Multicast-Gruppen wird nicht nur durch die Verfügbarkeit freier Adressen begrenzt, sondern vor allem durch den Aufwand die Gruppen zu verwalten. Broker treten den Gruppen bei und verlassen sie wieder. Routing-Informationen für das Kommunikationsnetz müssen berechnet, gespeichert und stets aktuell gehalten werden. Opyrchal et al. erörtern daher in [OAA + 00] mehrere Heuristiken, um die Anzahl der benötigten Gruppen zu reduzieren. Dabei geben sie einen Überblick über generelle Ansätze und Möglichkeiten: 3 Die Analogie ist ersichtlich, wenn wir uns für jede der 2 N Kombinationen ein eigenes Thema vorstellen.

2.1. KONZEPTE 13 Reduzieren der Gruppenpräzision. In einer Gruppe werden auch Notifikationen veröffentlicht, für die sich nur ein Teil der beigetretenen Broker interessiert. Mehrfaches Senden von Multicasts. Eine Notifikation wird in mehreren Multicast- Gruppen veröffentlicht. Senden über mehrere Knoten. Ein Broker sendet die Notifikation in einer Multicast- Nachricht an einen Teil seiner Nachbarn, die sie dann mittels Multicast analog weiterleiten. Peer-to-Peer. In Peer-to-Peer Netzen [Ora01] interagieren Knoten als Gleichgestellte und bieten sich gegenseitig Dienste an bzw. nehmen diese in Anspruch. Der Begriff Peerto-Peer wurde im Zusammenhang mit Internettauschbörsen bekannt, in denen Nutzer sich gegenseitig Zugriff auf Dateien gewähren. Peer-to-Peer Systeme der ersten Generation waren unstrukturiert und fluteten Anfragen direkt in ihr Netz, was zu Performance- und Skalierbarkeitsproblemen führte [CP02]. Aktuelle Systeme wie Pastry [RD01] oder Tapestry [ZKJ01], die auf verteilten Hashtabellen basieren, sind in der Lage Nachrichten in durchschnittlich O(log N) Schritten zu einem der N Netzknoten zu leiten. Ihr Routing-Algorithmus konstruiert ein sogenanntes Small-World Overlay-Netz [Ora01], das stark geclustert ist und einen geringen Durchmesser aufweist. Derartige Peer-to-Peer Systeme sind in hohem Maße fehlertolerant sowie skalierbar. Eine verteilte Hashtabelle [Dev93] ist eine dezentrale Datenstruktur, die einen Schlüssel auf einen Netzknoten abbildet, der ein zugehöriges Datum speichert. Der Aufwand zum Speichern wird gleichmäßig auf alle Knoten verteilt. Anfragen leitet das Peer-to-Peer System effizient an den durch den Hashwert des Schlüssels bestimmten Knoten, der diese dann bedient. Auf dieser Basis lässt sich ein Multicast auf Applikationsebene [CRZ00] entwerfen, der äquivalent zu themenbasierten Publish/Subscribe ist. Subskriptionen sowie Notifikationen werden durch das Peer-to-Peer Netz geroutet, wobei ihr Thema als Schlüssel dient. Ihr Zielknoten, der sich durch den Hashwert des Schlüssels bzw. Themas ergibt, ist der Rendezvous-Punkt [CDKR02], an dem sie sich treffen. Auf ihrer Reise zum Rendezvous-Punkt hinterlassen Subskriptionen in jedem Knoten Routing-Informationen, die den letzten Vorgänger auf ihrem bisherigen Weg beinhalten. Damit initialisieren sie die Pfade, die in umgekehrter Richtung der Auslieferung der Notifikationen dienen. Es entsteht ein kernbasierter Multicast-Baum [BFC93] für ein bestimmtes Thema mit dem zugehörigen Rendezvous-Knoten als Wurzel. Ist die Adresse bekannt, so können Notifikationen auch direkt an den Wurzelknoten geschickt werden, von dem ausgehend die eigentliche Verteilung an die Subscriber beginnt. Scribe [CDKR02] implementiert einen derartigen Multicast basierend auf Pastry. Eine weitere, ähnliche Implementierung ist Bayeux [ZZJ + 01], die hingegen Tapestry als Peerto-Peer Routing-Schicht nutzt. In Bayeux verwalten die Rendezvous-Knoten zusätzlich die Mitgliedschaft in ihren Gruppen. Ferner wird der Multicast-Baum erst von Nachrichten des Rendezvous-Knotens an die Subscriber erzeugt, die ihre Subskriptionen bestätigen. Hermes [PB02] (siehe auch Kapitel 2.2.5) erweitert den vorgestellten Multicast-Mechanismus um inhaltsbasierte Filterung zu einem flexiblen und vollwertigen Publish/Subscribe System.

14 2. PUBLISH/SUBSCRIBE 2.2 Systeme Es gibt eine Vielzahl verschiedener Publish/Subscribe Systeme. Wang et al. verweisen allein in [WQA + 02] auf elf Projekte. Dies sind bei weitem nicht alle und aufgrund der Attraktivität des Publish/Subscribe Modells werden es kontinuierlich mehr. Wir haben fünf Repräsentanten Siena [Car98], Gryphon [IBM01b], Jedi [CNF98], Rebeca [FMB01] und Hermes [PB02] ausgewählt, die wir im Folgenden vorstellen. Vor allem interessiert uns, welche der im vorigen Abschnitt betrachteten Konzepte jeweils umgesetzt wurden. 2.2.1 SIENA Das Siena Projekt [Car98, CRW01] ist am Software Engineering Research Laboratory der Universität von Colorado in Boulder beheimatet [SER04]. Die Scalable Internet Event Notification Architecture (Siena) ist eine der ersten Implementierungen eines verteilten inhaltsbasierten Publish/Subscribe Systems. Siena Server bilden die Zugangspunkte zum System und bieten ihren Klienten eine Schnittstelle zum Publizieren, Subskribieren und Ankündigen von Notifikationen. Notifikationen bestehen aus typisierten Attributen, die in Form von (Name, T yp, W ert) Tripeln angegeben werden. Die Auswahl möglicher Typen ist jedoch auf eine feste, vordefinierte Menge beschränkt. Subskriptionen bzw. Filter erlauben die Angabe einfacher Prädikate über den Attributwerten. Siena nutzt Covering-Based Routing als inhaltsbasierten Routing-Algorithmus [CRW00], wobei statische, azyklische Netzwerktopologien unterstützt werden. Eine Rekonfiguration des Brokernetzes, bestehend aus den Siena Servern, ist nicht vorgesehen. Allerdings werden in [CIP02] und [CCW03] Erweiterungen für mobile Klienten vorgestellt, die auf dem Zwischenspeichern der Notifikationen basieren, solange Subscriber nicht mit Brokern verbunden sind. Die vorgeschlagenen Lösungen können den Verlust von Notifikationen drastisch reduzieren, aber aufgrund auftretender Race-Conditions nicht vollständig ausschließen [Zei04]. 2.2.2 GRYPHON Ziel des seit Frühjar 1997 am IBM Watson Research Center bestehenden Gryphon Projekts [IBM01b] ist die Entwicklung eines hoch skalierbaren, zuverlässigen sowie sicheren inhaltsbasierten Publish/Subscribe Systems. Gryphon ist heute als IBM WebSphere MQ Event Broker Bestandteil von IBMs kommerzieller WebSphere Produktreihe [IBM05] und wurde bereits erfolgreich bei globalen Sportveranstaltungen wie den australischen Olympischen Spielen 2000 oder Wimbledon 2001 eingesetzt. Gryphons Zuverlässigkeit und Skalierbarkeit beruhen auf Redundanz. Virtuelle Broker werden eingeführt, die aus Zellen (Clustern) untereinander vernetzter physischer Broker bestehen. Eine Kante im Netz der virtuellen Broker wird auf ein Bündel von Verbindungen zwischen physischen Brokern der verschiedenen Zellen abgebildet. So kann einerseits die Last aufgeteilt und andererseits der Ausfall einzelner physischer Broker oder Verbindungen toleriert werden. Gryphon unterscheidet zwischen Brokern, die entweder nur für Publisher oder nur für Subscriber zuständig sind, sowie zwischen intermediären Brokern, die keine Klienten besitzen. Das Routing der Notifikationen wird von einem Informationsfluss-Graphen (IFG)