Experimentelle Evaluierung eines Ansatzes zur semantisch entkoppelten Kommunikation in dynamischen, heterogenen Netzwerken mittels Publish/Subscribe

Transkript

1 Experimentelle Evaluierung eines Ansatzes zur semantisch entkoppelten Kommunikation in dynamischen, heterogenen Netzwerken mittels Publish/Subscribe Diplomarbeit Universita t Rostock Fakulta t fu r Informatik und Elektrotechnik Institut fu r Informatik Lehrstuhl fu r Informations- und Kommunikationsdienste vorgelegt von: Erstgutachter: Zweitgutachter: Betreuer: Abgabedatum: Roland Seuchter Prof. Dr. Clemens H. Cap Prof. Dr. Peter Forbrig Henry Ristau

2 Kurzfassung In dieser Arbeit wird ASP (Announcement/Subscription/Publication), ein Routingverfahren für die Kommunikation in heterogenen Netzwerken, untersucht. Erstmals wird das auf Publish/Subscribe basierende Verfahren in einem realen System umgesetzt. Das Ziel der Arbeit ist es, zu prüfen, ob ASP in der Praxis als Middleware für die Kommunikation in heterogenen Netzen, wie sie zum Beispiel in intelligenten Umgebungen vorkommen, geeignet ist. Bislang wurde ASP ausschließlich in Simulationen evaluiert. In einem ausgewählten, realistischen Szenario sind die Experimente angesiedelt, mit denen die Leistungsfähigkeit von ASP geprüft wird. Abstract This thesis analyses ASP (Announcement/Subscription/Publication). ASP is a routing algorithm that is based on Publish/Subscribe. It has been designed to enable flexible communication in heterogeneous networks. These networks can be found in smart environments and other systems. Earlier research used simulation to evaluate the concept of ASP. This thesis marks the first time that ASP is implemented in a real system. The objective of this thesis is to evaluate the approach and measure the performance of the new system. A series of experiments in a realistic setting provide the data for assessing ASP. i

3 Inhaltsverzeichnis Inhaltsverzeichnis 1. Einleitung Motivation Zielstellung Überblick Grundlagen und Stand der Technik Überblick Publish/Subscribe Publish/Subscribe in heterogenen Netzen Inhaltsbasiertes Routing Datenmodelle Adressierungsschemata Sprachen Weitere Problemstellungen Publish/Process/Subscribe Announcement/Subscription/Publication Interaktion Routing Anwendungsschnittstelle Netzwerkabstraktionsschicht Übertragungskategorien Andere Publish-Subscribe-Middleware Routingmetriken Hop Count ETX ETT WCETT MIC Netzwerktechnologien IP UDP Wireless LAN Bluetooth Konzept Anwendungsszenarien für PPS ii

4 Inhaltsverzeichnis 3.2. Szenario Ziele von ASP Überblick Variationsmöglichkeiten Abbildung auf ASP Anwendungstypen und Übertragungskategorien Plattformen und Netzwerktechnologien Anwendungsschnittstelle Interaktion Caching Metrik Datentransport Datenverarbeitung Metrik für ASP Implementierung Einleitung Anwendungen Rekorder Speicherung Konverter Download Weitere Anwendungen Broker Multithreading Priorisierung Fragmentierung Protokollierung NAL Priorisierung Ethernet und WLAN via UDP Bluetooth via OBEX Nachrichtenformat Metrik Experimenteller Ansatz Experimente Versuchsaufbau Hardwareumfeld Softwareumfeld Beispielaufbau und -ablauf Auswertung Heterogenität iii

5 Inhaltsverzeichnis 6.2. Räumliche Entkopplung Nachbarschaftsbeziehungen Verwaltungsaufwand Zeitliche Entkopplung Alternative Übertragungswege Gestörte Übertragungswege Alternative Übertragungstechniken Alternative Prozessoren Schlussbetrachtungen Zusammenfassung Ausblick A. Nachrichtenformat 76 B. Versuche 77 B.1. Namensschema B.2. Übersicht der Experimente B.3. Versuchsaufbau B.4. Hard- und Softwarespezifikationen B.5. Ausgewählte Diagramme Literaturverzeichnis 88 iv

6 Abbildungsverzeichnis Abbildungsverzeichnis 2.1. Komponenten eines PPS-Knotens Prozessor versendet Abonnements Verbindungsgewichtung durch ETX Beispiel Inter-Flow-Interferenz Szenarioskizze Variationsmöglichkeiten im Szenario Schnittstellen zwischen Anwendungen und Broker Nachrichtenverlust nach Routenänderungen Definition von t proc Logische Trennung eines IP-Netzwerks in Subnetze Verwaltungsaufwand in Experiment 2, Reihe Vergleich der Downloadzeiten Beispiel zeitlicher Ablauf der Ausbreitung von Ankündigungen Störungen durch Bluetooth Inquiry Scans B.1. Legende der Versuchsskizzen B.2. Versuchsaufbau Experiment B.3. Versuchsaufbau Experiment B.4. Versuchsaufbau Experiment B.5. Versuchsaufbau Experiment B.6. Kosten der Ankündigungen in X1v1R1@1M B.7. Kosten der Ankündigungen in X1v1R1@11M B.8. Kosten der Ankündigungen in X1v1R1@54M B.9. Kosten der Ankündigungen in X1v1R1@auto B.10.Kosten der Ankündigungen in X1v1R2@dc80a B.11.Kosten der Ankündigungen in X1v1R2@dc v

7 Tabellenverzeichnis Tabellenverzeichnis 2.1. Publish-Subscribe-Beispielnachricht ASP-Nachrichtentypen Übertragungskategorien Vergleich der Metriken Rollenverteilung in den Beispielszenarien Variationsmöglichkeiten der Vernetzung Variationsmöglichkeiten der Rollen und Plattformen Kurzübersicht Versuchsrechner Rollenverteilung in Experiment 1, Variante 1, Reihe Zuordnung der Versuche zu den Untersuchungsaspekten Anzahl der Ankündigungen in Experiment 1, Variante 2, Reihe Kosten und Hops in Experiment 1, Variante 1, Reihe A.1. Nachrichtenformat B.1. Durchgeführte Experimente B.2. Softwareausstattung B.3. Hardwareausstattung B.4. Netzwerkperipherie vi

8 1. Einleitung 1. Einleitung 1.1. Motivation Intelligente Umgebungen sollen Menschen in ihren Arbeits- oder Wohnumgebungen bei ihren Tätigkeiten unterstützen und sich an die Bedürfnisse ihrer Nutzer anpassen. Dazu werden Räume mit Sensoren ausgestattet, die der Umgebung helfen, die Nutzer und ihren Kontext wahrzunehmen. Aktoren versetzen die Umgebung in die Lage, sich aktiv und selbstständig an die Situation anzupassen. Ein Beispiel sind ferngesteuerte Rollläden oder Zimmerlampen, die von einem Beleuchtungssensor gesteuert werden, um eine gleichmäßige Beleuchtung zu gewährleisten. Die Flexibilität und Anpassungsfähigkeit intelligenter Umgebungen wächst sprunghaft, wenn neben einfachen Sensoren und Aktoren weitere Geräte eingebunden werden. Angenommen, eine Person befindet sich in einem Wohnzimmer, das mit einem digitalen Videorecorder (DVR) ausgestattet ist. Erkennt der Recorder, dass der Benutzer auf die Aufzeichnung eines Spielfilms vom Vortag zugreift, wird die Zimmerbeleuchtung automatisch heruntergeregelt. Um dies zu erreichen, ist es notwendig, dass alle genannten Geräte miteinander kommunizieren und kooperieren. Bei Sensoren, Aktoren und weiteren Geräten handelt es sich aber um völlig unterschiedliche Geräte. Sie unterscheiden sich in ihrer Anzahl, in der Rechen- und Speicherkapazität, in der Art und Leistungsfähigkeit der verfügbaren Kommunikationsschnittstellen und in der Qualität der Stromversorgung. Ein Beleuchtungssensor mit ZigBee-Schnittstelle [Lüd07] und Solarbetrieb auf der einen Seite und ein DVR mit n WLAN [Rec06] und Gigabit-Ethernet [Rec08] auf der anderen Seite sind zwei Beispiele an gegenüberliegenden Enden eines breiten Spektrums. Diese heterogene Vielfalt ist charakteristisch für intelligente Umgebungen. Ein weiterer interessanter Aspekt intelligenter Umgebungen ist Mobilität. Betrachtet man das eingangs genannte Beispiel erneut, so kann man sich leicht vorstellen, dass der Benutzer, der den DVR steuert, ein Handy oder Smartphone besitzt. Intelligente Umgebungen umfassen nicht nur Geräte, die fest installiert sind, sondern auch Geräte, die mobil sind und die vom Nutzer in immer andere Umgebungen eingebracht werden. Im Beispiel ist es wünschenswert, wenn sich das Telefon für die Dauer des Films selbstständig in einen leisen Modus versetzt. Verlässt der Benutzer den Raum oder beendet er die Aufzeichnung, kehrt das Telefon wieder in seinen ursprünglichen Betriebsmodus zurück. Dazu muss es mit den anderen Geräten in der Umgebung kommunizieren. Kabellose Verbindungstechniken eignen sich dafür besonders. Die folgende Liste enthält zusätzliche charakteristische Eigenschaften für das Umfeld der heterogenen Netze in intelligenten Umgebungen: 1

9 1. Einleitung paralleler Einsatz von Funkschnittstellen und Kabelverbindungen mit stark unterschiedlicher Reichweite, Bandbreite und Verfügbarkeit hohe Anzahl der Geräte unterschiedliche Hardware- und Programmierarchitekturen und damit verbunden unterschiedliche Leistungsfähigkeit der Geräte Das hat eine Reihe von Konsequenzen für das Netzwerk. Wegen der Vielzahl der Geräte herrscht ein tendentiell hoher Kommunikationsbedarf. Arbeitet die Infrastruktur in dieser Situation nicht effizient, kann der Bedarf nicht gedeckt werden. Dass es mobile Geräte und Geräte mit begrenzter Energieversorgung gibt, führt dazu, dass sich die Topologie des Netzes häufig ändert. Einzelne tragbare Geräte werden bewegt und die Betriebszustände anderer Geräte ändern sich kurzfristig: An der einen Stelle kommt ein mobiles Gerät hinzu, während am anderen Ende des Raumes ein batteriebetriebener Sensor den Dienst einstellen muss. Vorhandene Funkschnittstellen verwenden ein geteiltes Medium und stellen eine Kommunikationsinfrastruktur vor weitere Probleme. Das Medium kann beträchtlichen Störungen ausgesetzt sein und die Verbindungsqualität kann schwanken. Auch dies hat Änderungen in der Topologie zur Folge. Weiter kann eine festinstallierte, kabelgebundene Infrastruktur vorhanden sein, die im Allgemeinen eine höhere Bandbreite aufweist und zuverlässiger ist als kabellose Netze, weshalb sie in die Kommunikationsvorgänge einzubeziehen ist. Nicht zuletzt führt die Vielfalt der Netzwerkschnittstellen der Geräte dazu, dass nur wenige Geräte unmittelbar miteinander kommunizieren können. Ein einheitlicher Adressraum existiert nicht. Die Kommunikation muss also koordiniert werden und kooperativ sein. Einzelne Geräte müssen zwischen unterschiedlichen Techniken vermitteln. Die genannten Eigenschaften heterogener Netze, wie sie in intelligenten Umgebungen zu finden sind, und das Beispiel, veranschaulichen, dass es eine komplexe Aufgabe ist, ein leistungsfähiges und flexibles Kommunikationskonzept zu entwerfen, dass die Geräte miteinander verbindet Zielstellung Mit Announcement/Subscription/Publication (ASP) existiert ein neuartiges Konzept, das die Kommunikation in heterogenen Netzwerken ermöglichen kann. In einer Middleware kombiniert der Ansatz die Kommunikation mittels Publish/Subscribe mit einer flexiblen und aus Anwendungssicht transparenten Nachrichtenverarbeitung. Bislang wurde der Ansatz von ASP in Simulationen evaluiert. Die Ergebnisse waren erfolgversprechend. Erst eine reale Umsetzung kann zeigen, wie praxistauglich und ausgereift das in der Literatur beschriebene Konzept ist. In dieser Arbeit wird ASP daher erstmals in ein konkretes System überführt. Das entwickelte System ist die Grundlage für die experimentelle 2

10 1. Einleitung Evaluierung des Ansatzes in einem praktischen Szenario. Aus dem Szenario werden in dieser Arbeit vier unterschiedliche Experimente abgeleitet. Mit Hilfe dieser Experimente werden Hypothesen geprüft, die sich wie folgt zusammenfassen lassen: 1. Das System funktioniert in einem heterogenen Umfeld. 2. Die Kommunikation ist räumlich entkoppelt und 3. erfolgt auf Grundlage von Nachbarschaftsbeziehungen. 4. Das System arbeitet mit einem niedrigen Verwaltungsaufwand. 5. Die zeitliche Entkopplung der Kommunikation ist gewährleistet. 6. Unter den alternativen Übertragungswegen wird ein effizienter gewählt. 7. Gestörte Übertragungswege werden vermieden und 8. unterschiedliche Übertragungstechnologien können genutzt werden. 9. Für die Datenverarbeitung werden die leistungsfähigsten der verfügbaren Geräte eingebunden. Ob ASP die gesteckten Erwartungen erfüllen kann, ergibt die Auswertung der praktischen Versuche. Es wird geklärt, wie effizient das implementierte System diese Ziele erreicht und an welchen Stellen das Konzept gegebenenfalls verbessert oder konkretisiert werden muss Überblick Die vorliegende Arbeit ist neben der Einleitung in diesem Kapitel in sechs weitere Kapitel untergliedert. Kapitel 2 schildert die Grundlagen von Publish/Subscribe, dem darauf aufbauenden Ansatz Publish/Process/Subscribe und dem weiterführenden System Announcement/Subscription/Publication (ASP). ASP ist der Untersuchungsgegenstand dieser Arbeit. Kapitel 3 erläutert das Szenario, in dem das implementierte System zum Einsatz kommt. Fragestellungen, die einer erfolgreichen Implementierung vorausgehen, werden diskutiert. Insbesondere wird die Metrik als ein Kernbereich der künftigen Middleware beschrieben. Die Besonderheiten der Implementierung beschreibt Kapitel 4. Die Merkmale der Implementierung, die für das Verständnis des Ablaufs der Experimente und die spätere Auswertung der Versuche von entscheidender Bedeutung sind, stehen dabei im Mittelpunkt. Die Anforderungen an die Experimente und das Vorgehen bei den Versuchen enthält Kapitel 5. Kapitel 6 diskutiert die durchgeführten Versuche und wertet sie aus. Die in Abschnitt 1.2 genannten Hypothesen bilden den Leitfaden der Auswertung. Eine Zusammenfassung der Ergebnisse und einen Ausblick auf zukünftige Forschungsthemen gibt Kapitel 7. 3

11 2. Grundlagen und Stand der Technik 2. Grundlagen und Stand der Technik In Abschnitt 1.1 wurden die Merkmale intelligenter Umgebungen dargestellt. Damit die Kommunikation in einem solchen Umfeld gewährleistet werden kann, wird eine geeignete Infrastruktur benötigt. Publish/Subscribe eignet sich als Grundlage einer solchen Infrastruktur, denn die Kommunikation mittels Publish/Subscribe ist lose gekoppelt. Client-Server-Architekturen sind zeitlich und räumlich eng gekoppelt. Client und Server müssen zum Zeitpunkt der Kommunikation beide aktiv (und erreichbar) sein und der Kommunikationspartner muss genau bekannt sein [TS08]. In einem heterogenen, dynamischen Netzwerk, in dem kein gemeinsamer Adressraum existiert und Verbindungen instabil sind, werden diese Voraussetzungen nicht erfüllt. Warteschlangensysteme entkoppeln die Kommunikation räumlich und zeitlich und sind mit Publish/Subscribe sehr eng verbunden [EFGK03]. Publish/Subscribe ist jedoch noch weiter entkoppelt, wie im folgenden Abschnitt beschrieben wird. Zudem ist die persistente Kommunikation, wie sie von Warteschlangensystemen angeboten wird, in intelligenten Umgebungen im Allgemeinen nicht erforderlich. Die Infrastruktur ist somit zu komplex. Im weiteren liegt der Schwerpunkt daher auf Publish/Subscribe. In diesem Kapitel werden zunächst die Grundlagen von Publish/Subscribe erläutert. Anschließend werden schrittweise die Konzepte von Publish/Process/Subscribe (PPS) und Announcement/ Subscription/Publication (ASP) eingeführt. PPS ergänzt Publish/Subscribe um Mechanismen zur flexiblen Datenverarbeitung und unterstützt auf diese Weise die Kooperation von Geräten in intelligenten Umgebungen. Auf PSP aufbauend, ist ASP ein Routingalgorithmus für die Kommunikation in heterogenen Netzwerken. Metriken sind eine wesentliche Komponente von Routingalgorithmen. Auf Grundlage einer Metrik wird die Auswahl der Verbindungen oder Pfade getroffen, auf denen Daten transportiert werden. Für ASP wurde bislang keine Metrik festgelegt. Für die praktische Umsetzung wird sie jedoch benötigt. Abschnitt 2.7 behandelt existierende Metriken. Sie dienen später als Grundlage der Metrik für ASP. Die praktische Umsetzung des entwickelten Systems greift auf eine Reihe verbreiteter Netzwerktechnologien zurück. Das Kapitel schließt aus diesem Grund mit den wichtigsten Eckpunkten der eingesetzten Netzwerktechnologien. 4

12 2. Grundlagen und Stand der Technik 2.1. Überblick Publish/Subscribe Publish/Subscribe ist ein Kommunikationsparadigma [EFGK03], das unter anderem der Interaktion von Komponenten in komplexen verteilten Systemen besser gerecht werden möchte als andere Ansätze, zu denen das Client-Server-Modell, Remote Procedure Calls 1 (RPC) und Warteschlangensysteme (bzw. nachrichten-orientierte Middleware, MOM) gehören. Einen Überblick dieser Techniken bietet [TS08], sodass ihre Hintergründe hier nicht weiter Gegenstand sind. Stattdessen veranschaulicht eine detaillierte Betrachtung der Komponenten und der Funktionsweise von Publish/Subscribe dessen Potenzial und unterstreicht die Vorzüge der zentralen Eigenschaften von Publish/Subscribe. An der Kommunikation mittels Publish/Subscribe sind stets drei Parteien beteiligt: Subscriber, Broker und Publisher 2. Der Subscriber ist an den Nachrichten, die der Publisher erzeugt, interessiert. Der Broker koordiniert die Kommunikation und leitet Nachrichten ausschließlich weiter. Er hat selbst kein Interesse am Inhalt der Nachrichten und erzeugt auch keine Botschaften, ist also weder Quelle noch Senke. Möchte der Subscriber Nachrichten empfangen, teilt er dem Broker sein Interesse mit, d.h. er abonniert bestimmte Nachrichten. Erzeugt der Publisher eine Botschaft, sendet er diese an den Broker. Der überprüft, ob es (einen oder mehrere) Subscriber gibt, die an der Nachricht interessiert sind und leitet sie an alle interessierten Subscriber weiter. Bereits in seiner einfachsten Form, weist das Modell zwei interessante Eigenschaften auf: 1. Die Kommunikation ist räumlich entkoppelt (anonym). 2. Je ein Publisher kann mit nur einer Operation Nachrichten an beliebig viele Subscriber übertragen (Multicast). Versendet der Publisher eine Nachricht, adressiert er die Empfänger nicht direkt. Die Verbreitung der Information wird dem Broker überlassen. In der Folge müssen sich die Kommunikationspartner nicht kennen. Die Kommunikation gilt als räumlich entkoppelt [EFGK03]. Der zweite Punkt besagt, dass der Broker jede eintreffende Nachricht an mehrere Empfänger weiterleiten kann, falls sie Interesse daran haben. Unabhängig davon können in einem Publish-Subscribe-System mehrere Publisher existieren und aktiv Nachrichten versenden. Neben der räumlichen Entkopplung ist die Kommunikation per Publish/Subscribe auch zeitlich entkoppelt und erfordert keine Synchronisation von Publisher und Subscriber [EFGK03]. Die Bedeutung der zeitlichen Entkopplung ist, dass Sender und Empfänger einer Nachricht nicht zum gleichen Zeitpunkt aktiv sein müssen. So kann ein Publisher eine Nachricht versenden, während der Empfänger dieser Nachricht inaktiv ist, oder falls die Verbindung auf Sende- oder Empfangsseite unterbrochen ist. Die Entkopplung 1 Vereinfachend soll dies auch Remote Method Invocation (RMI) umfassen. 2 Die Bezeichnung ist uneinheitlich. In einigen Veröffentlichungen heißt es Produzent und Konsument statt Publisher bzw. Subscriber; anstelle von Nachrichten wird häufiger von Ereignissen gesprochen [CRW00, EFGK03, MC02] u.a. 5

13 2. Grundlagen und Stand der Technik der Synchronisation bezieht sich auf das Blockieren der Kommunikationsvorgänge. Bei Publish/Subscribe müssen sich weder Publisher noch Subscriber beim Versand bzw. Empfang mit anderen Teilnehmern synchronisieren. Aldred et al. formalisieren die Entkopplung von Middleware entlang der drei Dimensionen Ort (Adresse), Zeit und Synchronisation [AADH05]. Sie argumentieren ferner, dass alle drei Dimensionen orthogonal sind Publish/Subscribe in heterogenen Netzen Stellt man den Ansatz von Publish/Subscribe den Charakteristika heterogener Netze (siehe Abschnitt 1.1) gegenüber, stellt man fest, dass das Publish-Subscribe-Verfahren gut für den Einsatz in intelligenten Umgebungen geeignet ist. Die räumliche Entkopplung und die Multicast-Semantik helfen, viele Geräte zu verbinden. So müssen die Kommunikationspartner nicht aufwändig im Vorfeld einer Kommunikation ermittelt werden und während des eigentlichen Kommunikationsvorgangs einzeln angesprochen werden. Die veränderliche Topologie, hervorgerufen durch Geräte in unterschiedlichen Betriebszuständen, kann durch die zeitliche Entkopplung kompensiert werden, denn sie erlaubt die Kommunikation auch dann, wenn einer der beteiligten Endpunkte inaktiv ist. Ähnliches gilt für die Entkopplung der Synchronisation. Insbesondere erlaubt sie Applikationen auf leistungsschwachen Geräten mit begrenzter Stromversorgung Nachrichten zu verschicken oder zu empfangen, ohne unter hohem Zeitaufwand auf andere Geräte warten zu müssen Inhaltsbasiertes Routing In Publish-Subscribe-Systemen spielt es eine entscheidende Rolle auf welcher Grundlage Nachrichten vom Broker weitergeleitet werden. Man spricht von inhaltsbasiertem Routing, wenn der Broker auf Grundlage des Inhalts einer Nachricht entscheidet, wohin diese übertragen werden soll. Daneben sind vordefinierte Multicastgruppen oder Flooding weitere Möglichkeiten zur Verbreitung der Nachrichten [CS04, MUHW04]. Das Datenmodell, die Adressierungsschemata und die Sprachen mit denen das Interesse (oder das Angebot) an Inhalten beschrieben werden, sind grundlegend für inhaltsbasiertes Routing, denn die Ausdrucksfähigkeit des Mechanismus, mit dem Interesse beschrieben werden kann, beeinflusst unmittelbar die Flexibilität des gesamten Systems [CJ02]. Die folgenden Abschnitte geben einen Überblick zu den drei genannten Bereichen. Abschließend werden in Abschnitt weitere Problemstellungen vorgestellt und einige konkrete Systeme genannt. 6

14 2. Grundlagen und Stand der Technik Datenmodelle Es existieren unterschiedliche Datenmodelle um den Inhalt von Nachrichten zu beschreiben. Sie sind die Grundlage, um das Interesse an Nachrichten formulieren zu können. Ein weit verbreitetes Modell ist das bei SIENA [CRW00] verwendete, das eine Nachricht als eine typenlose Menge typisierter Attribute definiert 3. In einer leichten Abwandlung sprechen die Autoren von Mercury von Listen typisierter Attribut-Wert-Paare [BRS02]. In jedem Fall sind dies die Modelle, die die wissenschaftlichen Veröffentlichungen dominieren. Sivaharan et al. nennen zusätzlich Zeichenketten, Tupel, XML-Dokumente und Objekte als Datenmodell [SBC05] Adressierungsschemata Die Adressierung von Empfängern in Publish-Subscribe-Systemen kann auf unterschiedliche Art und Weise erfolgen. Die drei geläufigsten Ansätze arbeiten entweder kanalbasiert, themenbasiert oder inhaltsbasiert. Kanalbasierte Ansätze berücksichtigen den Inhalt von Nachrichten nicht. Stattdessen werden Kommunikationskanäle über Namen identifiziert [CRW00]. Ein Subscriber abonniert den Kanal und empfängt somit sämtliche Nachrichten, die über den gewählten Kanal veröffentlicht werden. In der Implementierung lässt sich dieser Ansatz unmittelbar auf existierende Architekturen wie IP-Multicast abbilden. In Tabelle 2.1 ist ein Beispiel für eine Nachricht gegeben. In einem kanalbasierten Publish-Subscribe-System könnte sie z.b. in dem Kanal Börsennachrichten veröffentlicht werden. Es steht dem Publisher frei, welche Nachrichten er in welchem Kanal veröffentlicht. Der Mechanismus themenbasierter Adressierung ist ausdrucksstärker als kanalbasierte Adressierung [HGM04,BCM + 99,EFGK03]. Ein Publisher kennzeichnet jede Nachricht mit einem sogenannten Thema. Subscriber abonnieren Nachrichten mit einem bestimmten Thema. Stimmt das gewünschte Thema mit dem einer Nachricht überein, wird die Nachricht an den interessierten Subscriber ausgeliefert. So könnte das Beispiel (Tab. 2.1) das Thema Kursänderung haben. Am flexibelsten ist die inhaltsbasierte Adressierung [BCM + 99,HGM04]. Anstatt lediglich ein einzelnes Attribut oder Thema mit einem vorgegebenen Wert zu vergleichen, erlauben inhaltsbasierte Verfahren die Auswertung der kompletten Nachricht (z.b. aller Attribute). Erst wenn alle untersuchten Eigenschaften einer Nachricht erfüllt sind, d.h. mit dem Interesse des Subscribers übereinstimmen, wird sie an diesen weitergeleitet. Eine 3 untyped set of typed attributes [CRW00] 7

15 2. Grundlagen und Stand der Technik Ausnahme bildet das System A-ToPSS [CJ02], welches auch teilweise Übereinstimmungen (n aus m ; n < m) zulässt. Zusammenfassend lässt sich sagen, dass die kanalbasierte und insbesondere die themenbasierte Adressierung Spezialfälle der inhaltsbasierten Verfahren sind [HGM04,CRW00]. Das Beispiel aus Tabelle 2.1 würde die folgende komplexe Bedingung erfüllen: Unternehmen = Friendface UND Preis > 21,60 UND (Handelsplatz = Hannover ODER Handelsplatz = Stuttgart ) Neben den genannten Ansätzen schlagen Eugster et al. ein typbasiertes Verfahren vor, welches eine engere Integration von Middleware und Sprache (siehe Abschnitt 2.3.3) sowie Typsicherheit ermöglichen soll [EFGK03]. Attribut Wert Unternehmen Friendface Wertpapier AKTIEFF Datum Uhrzeit 14:06 CEST Preis 21,64 e Handelsplatz Hannover Tabelle 2.1.: Eine Beispielnachricht in einem Publish-Subscribe-System Sprachen Die Ausdrucksfähigkeit eines inhaltsbasierten Publish-Subscribe-Systems hängt von der Sprache ab, die genutzt wird, um Interesse d.h. Abonnements zu beschreiben. Gängig ist die Formulierung als Zeichenkette wobei neben proprietären Sprachen auch SQL oder XPath zur Anwendung kommen können [HBS + 02, TRP + 04, EFGK03]. Letzteres ist die naheliegende Wahl, wenn Nachrichten in XML kodiert werden. Allgemein sind boolesche Ausdrücke vorherrschend. Sie verknüpfen Vergleiche von Attributwerten und Konstanten miteinander. Unterschiedliche Vergleichsoperatoren wie =,,<,> usw. kommen dabei zum Einsatz, soweit sie auf den Datentypen der Attribute definiert sind [CRW00, SA97, EFGK03] Weitere Problemstellungen In der Literatur werden spezielle Problemfragen von inhaltsbasiertem Routing diskutiert. Häufig finden die Ergebnisse Eingang in Routingalgorithmen oder Prototypen. Eines der Probleme ist die effiziente Auswertung von Prädikaten, d.h. der Vergleich von Nachrichten mit den Interessen der Kommunikationspartner. So wurden Überdeckungsrelationen vorgeschlagen, um die Anzahl und Komplexität von Prädikaten zu reduzieren [CRW04]. 8

16 2. Grundlagen und Stand der Technik Suchbäume sollen die Zahl der Vergleiche auf das für das Weiterleiten von Nachrichten nötige Minimum reduzieren [BCM + 99]. Über das Wann und Wo der Auswertung von Prädikaten gibt es unterschiedliche Meinungen. Das System Kyra [CS04] unterteilt den Raum möglicher Nachrichten und strukturiert zusätzlich das Netzwerk der Broker in Cliquen, die in Bäumen organisiert sind, um die Vergleiche auf nahegelegenen und (pro Nachricht) weniger Knoten durchführen zu müssen. Vor dem Hintergrund der Multicast-Eigenschaft von Publish/Subscribe muss man das Argument aus [CRW00] sehen, wonach Prädikate möglichst früh, d.h. wenige Stationen vom Publisher entfernt auszuwerten sind, Verzweigungen, d.h. Kopien von Nachrichten, möglichst spät, also nahe an den Subscribern durchgeführt werden sollen. Beides soll die Belastung des Netzwerks minimieren. Konsequenterweise sollten Nachrichten für die momentan kein Interesse besteht, überhaupt nicht versendet werden. Diese Optimierung ist unter dem Begriff source quenching bereits seit längerem bekannt [SA97]. Die Anonymität der Kommunikationspartner und das Multicasting in inhaltsbasierten Publish-Subscribe-Systemen erschweren die verlustfreie Ende-zu-Ende-Übermittlung von Nachrichten, was in vielen Anwendungen eine wichtige Anforderung an die Dienstgüte ist. Mit Gryphon wurde eine komplexe Lösung vorgestellt, die auf Zeitschlitzen basiert [BSB + 02] und die Nachrichtenübermittlung absichert. Mobile Geräte und insbesondere MANETs 4 stellen besondere Anforderungen. Huang und Garcia-Molina beschreiben in [HGM04] Szenarien wie inhaltsbasiertes Publish-Subscribe für mobile und Ad-Hoc-Umgebungen erweitert werden kann. Sie untersuchen den Einsatz von zentralen, verteilten und replizierten Brokern. Zusätzlich untersuchen sie weitere allgemeine Fragen des mobilen Publish/Subscribe. Mit zwei unterschiedlichen Vorstellungen von Mobilität beschäftigt sich [FGKZ03]. Fiege et al. unterscheiden die transparente Mobilität von Anwendungen, aber auch Mobilität und Ortsbezug als Anwendungskontext. In ihrem Ansatz setzen sie auf Stellvertreter von Subscribern, die Nachrichten empfangen, während der echte Subscriber keine Verbindung zum Netz hat. GREEN und STEAM befassen sich ebenfalls mit dem mobilen Umfeld [SBC05,MC02]. Sie sehen Anwendungen insbesondere im Verkehrsbereich und VANETs 5 und erweitern Publish/Subscribe für ihre Beispielanwendungen um räumliche Nähe als weitere Filterdimension Publish/Process/Subscribe Um die volle Leistungsfähigkeit einer intelligenten Umgebung auszuschöpfen, müssen alle vorhandenen Geräte miteinander kommunizieren. Wie bereits erläutert wurde (siehe S. 1), sind intelligente Umgebungen sehr heterogen. Ziel des in [Ris08] vorgestellten 4 Mobile ad hoc networks; siehe [Per01]. 5 Vehicular ad hoc networks; siehe [MSJ09]. 9

17 2. Grundlagen und Stand der Technik Publish/Process/Subscribe (PPS) ist es, den Geräten zu ermöglichen, unabhängig von ihrer Kommunikationstechnologie Daten auszutauschen. Existierende Ansätze sind ungenügend und müssen von zentralen Komponenten und dem Bedarf manueller Konfiguration befreit werden [Ris08]. Um maximale Flexibilität zu erreichen, setzt das Konzept von PPS auf Publish/Subscribe auf (siehe Abschnitte 2.1 und 2.2). Dabei macht es sich dessen Vorzüge der räumlichen und zeitlichen Entkoppelung zunutze. Ergänzt wird die Architektur aus Publisher, Subscriber und Broker um Prozesse, die Daten verarbeiten können (Prozessoren). Diese Prozesse können (Sensor-)Daten auswerten und Geräte steuern oder sie unterstützen andere Geräte beim Datenaustausch durch die transparente Wandlung von Daten in unterschiedlichen Formaten [Ris09a]. Ohne derartige Prozessoren werden Daten mit klassischem Publish/Subscribe lediglich verteilt. Das Konzept von PPS, welches explizit auf die Anwendung in intelligenten Umgebungen zugeschnitten ist, sieht für jeden Knoten eine bestimmte Struktur aus unterschiedlichen Komponenten vor (siehe Grafik 2.1). Im heterogenen Netz verfügt jeder (physische) Knoten über einen eigenen Broker (lokaler Broker), der die Kommunikation mit benachbarten Knoten bzw. deren Brokern übernimmt. Anwendungen, die auf dem Knoten aktiv sind, werden in die drei Kategorien Quelle, Senke und Prozessor unterteilt. Jede Anwendung ist mit dem lokalen Broker ihres Knotens über eine definierte Schittstelle verbunden. Die Existenz von Brokern auf jedem Knoten wird damit begründet, dass auf diesem Wege lokales Wissen über den Knoten und seine unmittelbaren Nachbarn für den Betrieb genügt. Eine globale Sicht und damit die Kenntnis aller Knoten im Netzwerk ist nicht erforderlich. Wegen der Heterogenität der Umgebung wäre sie unzweckmäßig. Für ein Smartphone, welches per Bluetooth mit dem Netzwerk verbunden ist, ist die Information, dass es in einem anderen Bereich des Netzes zwei per Ethernet verbundene Knoten gibt, nutzlos. Das Smartphone kann nicht direkt mit den Knoten kommunizieren. Häufige Topologieänderungen wie sie im Einsatzumfeld von PPS zu erwarten sind, treiben zudem die Kosten für das Vorhalten einer konsistenten und aktuellen Sicht auf das gesamte Netz in die Höhe. Informationen über die Topologie müssten nach jeder Änderung an jeden Knoten im Netz verteilt werden, was das Netzwerk belasten würde. Eine weitere Komponente ist der sog. Network Abstraction Layer (NAL), die Netzwerkabstraktionsschicht. Sie verbirgt die Eigenheiten einer konkreten Kommunikationstechnik vor den darüberliegenden Schichten, also insbesondere vor dem Broker. Die Interaktion der Broker und Anwendungen untereinander ist ein Routingproblem [Ris08]. Nachrichten müssen von den Quellen, durch das Netzwerk aus Brokern hindurch, zu den Senken transportiert werden. Auf dem Weg kann es erforderlich sein, dass ein oder mehrere Prozessoren die Daten verarbeiten. Es können mehrere Wege von der Quelle zur Senke existieren. Die Komplexität wird dabei durch die Einbeziehung der Prozessoren erhöht. Um ein Datum d nach d abzubilden, können unterschiedliche Verknüpfungen von Funktionen existieren, die sich in der Reihenfolge und Anzahl der Einzeloperationen und damit den beteiligten Prozessoren unterscheiden. Es müssen also Wege durch ein Netzwerk gefunden werden, die möglichst kostengünstig sind. In [Ris08] werden drei Strategien für das Routing vorgestellt, von denen ein auf Flooding basierender Ansatz 10

18 2. Grundlagen und Stand der Technik Quelle Quelle Prozessor Prozessor Senke Senke Nachbarn Anwendungss. Broker NAL Abbildung 2.1.: Die Komponenten von PPS auf einem Knoten: Anwendungen (Quelle, Prozessor, Senke), die Anwendungsschnittstelle, der Broker und die Netzwerkabstraktionsschicht (NAL). NAL und Broker sammeln Informationen über Nachbarknoten. Abbildung nach [Ris08]. weiter verfolgt wird und in das Konzept Announcement/Subscription/Publication (ASP) mündet. Einer der beiden weiteren Vorschläge basiert auf der Abbildung von Prozessoren auf je eine Quelle und Senke, dem anderen liegt die netzweite Verbreitung des Interesses an Publikationen zu Grunde Announcement/Subscription/Publication Mit Announcement/Subscription/Publication (ASP) existiert ein Konzept, dass das zuvor beschriebene PPS umsetzen möchte. Die grundlegende Architektur von ASP ist daher gleich der von PPS: In einem Netzwerk aus Knoten kommunizieren Anwendungen (Quelle, Senke oder Prozessor) untereinander per Publish/Subscribe. Auf jedem Knoten existiert dazu ein Broker mit Applikationsschnittstelle und Netzwerkabstraktionsschicht. ASP konkretisiert einige dieser Konzepte und ergänzt einen Routingalgorithmus [Ris09a] Interaktion Die Interaktion zwischen den Brokern und den restlichen Komponenten des ASP-Systems läuft in drei Phasen ab: Ankündigung, Abonnement und Veröffentlichung. Jede dieser Phasen wird auf einen separaten Nachrichtentyp abgebildet. Sämtliche Nachrichten tragen Identifikationsnummern. Sie werden fortan als ASP ID oder verkürzend als ID bezeichnet. Trägt eine Ankündigung zum Beispiel die ID 7e44a5e4, so tragen alle nachfolgenden Abonnements und Veröffentlichungen, die auf die Ankündigung bezug nehmen dieselbe ID. Dies entspricht der themenbasierten Adressierung (siehe Seite 7). Mit Ankündigungen (Announcement) signalisieren Quellen, dass sie Daten im Netz zur Verfügung stellen. Ankündigungen werden grundsätzlich an alle Broker im Netzwerk 11

19 2. Grundlagen und Stand der Technik verteilt. Broker erhalten auf diese Weise eine Übersicht über die verfügbaren Datenquellen und lernen den Nachbarn kennen, über den die Nachrichten bezogen werden können. Eine Ankündigung kann eine Beschreibung der Daten enthalten, die die Quelle in Zukunft unter der gegebenen ID veröffentlichen wird. Handelt es sich bei einer Quelle beispielsweise um eine Webcam, die regelmäßig Aufnahmen macht, kann eine Ankündigung Informationen wie den Standort der Kamera, Bildmaße usw. enthalten. ASP legt weder die Form noch den Inhalt von Ankündigungen fest. Die Erzeugung und Interpretation einer Ankündigung ist den Anwendungen (Quelle, Prozessor, Senke) überlassen. Erzeugt eine Quelle Nachrichten von geringem Umfang oder werden sie nur selten versendet, kann eine Ankündigung statt einer Beschreibung das komplette Datum enthalten. Ein Temperatursensor kann auf diese Weise den jüngsten Messwert mit einer Ankündigung verbreiten. Neben Quellen können auch Prozessoren den Versand von Ankündigungen auslösen. Dies geschieht als Reaktion auf Ankündigungen von anderen Quellen oder Prozessoren, wenn ein Prozessor aus den bisher empfangenen Ankündigungen A 1, A 2 usw. beziehungsweise den entsprechenden Veröffentlichungen P 1, P 2 usw. eine neue Ankündigung A (bzw. P ) erzeugen kann. Ein Abonnement (Subscription) wird als Reaktion auf eine Ankündigung verschickt. Bevor eine Senke ein Abonnement auslösen kann, muss sie eine Ankündigung empfangen haben. Wird eine Ankündigung eines Prozessors abonniert, abonniert dieser alle Ankündigungen, die nötig sind, um die gewünschten Veröffentlichungen erzeugen zu können (siehe Grafik 2.2). S Proz. Broker S 1 S 2 S 3 Abbildung 2.2.: Ein Prozessor erhält ein Abonnement S und versendet daraufhin Abonnements für S 1, S 2, S 3. Neben Abonnements existieren Kündigungen. Sind ein Prozessor oder eine Senke nicht länger an den Daten einer Quelle interessiert, versendet der zuständige Broker eine Kündigung, die dieselbe ID wie die Ankündigung trägt. Spätere Veröffentlichungen mit dieser ID werden dem Prozessor oder der Senke nicht zugestellt. Die von Quellen angebotenen Daten werden in Form von Veröffentlichungen (Publication) verbreitet. Jede Veröffentlichung trägt die zur jeweiligen Ankündigung und dem Abonnement gehörende ID. Liegt einem Broker kein Abonnement zu einer ID vor, versendet der Broker die von den lokalen Anwendungen erzeugten Veröffentlichungen nicht. 12

20 2. Grundlagen und Stand der Technik Routing ASP sieht einen Routingalgorithmus vor, der lediglich voraussetzt, dass Knoten ihre unmittelbaren Nachbarn kennen, mit denen sie direkt kommunizieren können. Ankündigungen werden wie bereits erwähnt, an alle Broker im Netz verteilt. Um dies zu erreichen, werden Ankündigungen im Netzwerk geflutet. Eine neue Nachricht (Ankündigung) wird an alle benachbarten Broker und lokalen Prozessoren und Senken verteilt. Empfängt ein Broker b i eine Ankündigung von einem Nachbarn, speichert er, von welchem Nachbarbroker b j die Ankündigung versendet wurde. Außerdem merkt der Broker b i sich die Kosten der Nachricht. Eine Metrik akkumuliert die Kosten der Weiterleitung der Ankündigung vom erzeugenden Broker b 0 bis zum empfangenden Broker b i. Anschließend reicht der Broker die Ankündigung an lokale Anwendungen und leitet die Nachricht an alle ihm bekannten Nachbarn mit Ausnahme des Absenders b j weiter. Dabei werden die Kosten der Nachricht entsprechend den Kosten der Verbindung, über die die Ankündigung weitergeleitet wird, angepasst. Broker speichern die IDs von Ankündigungen, die sie bereits weitergeleitet haben. Eine Ankündigung wird von jedem Broker nur einmal an seine Nachbarn weitergeleitet. Dadurch ist sichergestellt, dass die Weiterleitung der Nachrichten terminiert. Erhält eine Senke von ihrem Broker eine Ankündigung und ist sie an zukünftigen Veröffentlichungen, wie sie in der Ankündigung beschrieben werden, interessiert, signalisiert die Senke dies ihrem Broker. Dieser erzeugt ein Abonnement mit der ID der Ankündigung. Kann das Abonnement nicht von einer lokalen Quelle oder Prozessor bedient werden, verschickt der Broker die Nachricht an einen seiner Nachbarn. Der Broker wählt den Nachbarn, dessen Kosten laut Metrik für die gegebene ID minimal sind. Abonnements gelangen schrittweise zum Broker, der die ursprüngliche Ankündigung versandt hat. Empfängt ein Broker ein Abonnement, nimmt er den sendenden Nachbarn mit der ID und den Kosten in eine Tabelle sogenannter aktiver Pfade auf. Das Abonnement wird wie zuvor an den Nachbarn mit der günstigsten Ankündigung weitergeleitet. Stammt die günstigste Ankündigung A von einem lokalen Prozessor, wird die Nachricht an diesen weitergegeben. Für alle Ankündigungen A 1 bis A n (n 1), die der Prozessor verarbeiten muss, um A erzeugen zu können, werden Abonnements verschickt. Erreicht ein Abonnement die Quelle der Ankündigung, wird die Nachricht nicht weitergeleitet. Der Broker merkt sich von welchem Nachbarn das Abonnement gesendet wurde. Kündigungen werden auf dieselbe Weise weitergeleitet wie Abonnements. Veröffentlicht eine Quelle Daten, erzeugt der Broker eine Veröffentlichung und sendet sie an alle Nachbarn, die Teil eines aktiven Pfades für die gegebene ID sind. Beim Empfang einer Veröffentlichung reicht ein Broker die Daten an lokale Anwendungen (Prozessor oder Senke), falls diese die ID der Veröffentlichung abonniert haben. Danach wird die Veröffentlichung an alle Nachbarn weitergeleitet, von denen Abonnements der ID vorliegen. Damit die Zahl der von einem Broker gespeicherten aktiven Pfade und weitergeleiteten Ankündigungen nicht beliebig zunimmt, wird jede Ankündigung bei ihrer Erzeugung mit einer Gültigkeitsdauer versehen. Ist die Gültigkeit einer Ankündigung abgelaufen, 13