Aufrufe
vor 5 Jahren

8 Werkzeuge f¨ur Rapid Prototyping mit verteilten Soft - tuprints

8 Werkzeuge f¨ur Rapid Prototyping mit verteilten Soft - tuprints

für dynamische

für dynamische Szenarios geeignet erscheinen hier die Systeme auf Basis des publishsubscribe-Paradigmas. Dabei publizieren Komponenten ihre Dienste an einer zentralen Stelle (vgl. z. B. Universal Plug and Play, Kapitel 3.12.2) und diejenigen Komponenten, die sich für einen solchen Dienst registriert haben, werden automatisch benachrichtigt. Andere Lösungen verfolgen hier den reinen peer-to-peer-Ansatz (vgl. AMIGO, Kapitel 3.1), in dem Komponenten ihre Fähigkeiten an die anderen Komponenten publizieren 91 Solche Ansätze haben generell die Eigenschaft der viel geringeren Kopplung der einzelnen Komponenten untereinander. Das andere Extrem stellen fest implementierte Kommunikationswege dar, die auf dem Aufruf von Methoden entfernter Objekte basieren. Prominente Vertreter dieser Technologien sind Corba [46] und RMI [127]. Auch die Technologie Metaglue (vgl. Kapitel 3.4) gehört in diese Kategorie der unterlagerten Kommunikationsinfrastrukturen. Komponenten können somit intern die Fähigkeiten anderer im Netzwerk vorhandenen Komponenten für die spätere Verwendung speichern oder per Nachfragen ins Netzwerk nach den vorhandenen Fähigkeiten und angebotenen Diensten fragen. Solche auf der peer-to-peer-Technologie aufbauenden publish-subscribe-Systeme scheinen für dynamische Umgebungen geeigneter zu sein als die auf dem Blackboard- Prinzip aufbauenden Systeme. Die Autonomie, die hier jedoch den einzelnen Komponenten zugestanden wird (hinsichlich service publishing, service discovery und service binding bzw. service composition 92 ) ist teuer erkauft. Die Entwickler jeder einzelnen Komponente müssen nicht nur die Funktionalitäten der eingebrachten Komponente implementieren, sondern sind zudem für alle unterlagerten Funktionen wie das Anbieten von Diensten, das Auffinden von Diensten und das Zuteilen von Aufträgen zuständig. Alle diese Aufgaben werden in den Systemen nach dem Blackboard-Prinzip von zentralen Stellen wahrgenommen. Dies unterbindet jedoch die Flexibilität und Dynamik der darauf basierenden Komponentenensembles. In dieser Arbeit werden, basierend auf der Analyse der Szenarios eigener Projekte (vgl. EMBASSI in Kapitel 2.1.1 und DYNAMITE in Kapitel 2.1.13) und Projekte anderer Forschungsinstitutionen und Firmen (vgl. Kapitel 2) die Anforderungen an eine Software- Infrastruktur für die Realisierung heterogener intelligenter Umgebungen identifiziert und erläutert. Zu diesen Eigenschaften der Selbstorganisation (siehe Kapitel 2.3) gehören die Unterstützung der dynamischen Erweiterbarkeit bereits vorhandener Geräteensembles, die Austauschbarkeit von Komponenten zur Laufzeit eines Geräteensembles und die Autonomie jedes einzelnen Gerätes. Systeme, die auf zentralen Komponenten basieren, können offensichtlich einige und manche sogar alle diese Punkte nicht vollständig erfüllen. In Systemen mit festen Routingregeln (vgl. Galaxy Communicator in Kapitel 3.8) können Komponenten nicht ausgetauscht werden. Ebenso ist das Hinzufügen von Komponenten, 91 Die AMIGO-Architektur definiert sich selbst als eine service-oriented middleware, da der Schwerpunkt auf dem standardisierten Zugriff auf Dienste heterogener Geräte gelegt wurde. Der peer-to-peer-Ansatz wird begründet mit der Gewährleistung maximaler Autonomie der einzelnen Komponenten. 92 Generell wird ” service binding“ als die Identifizierung eines gesuchten Dienstes mit einem ganz speziellen Diensteanbieter verstanden. Wird also mittels ” service discovery“ eine Liste an möglichen Diensteerbringern angefordert und dann ein Diensteanbieter aus dieser Liste ausgesucht, so spricht man von ” service binding“. ” Service decomposition“ bezeichnet die Aufteilung einer Dienstanfrage in mehrere Teilaufträge, die dann wiederum einzeln an unterschiedliche Diensteanbieter vergeben werden. 245

wenn nicht unmöglich, dann aber nutzlos, da sie in den festen Routingalgorithmen nicht berücksichtigt werden. Auch ist die Autonomie von Geräten in Systemen mit zentralen Stellen und Komponenten nicht gewährleistet. Fällt diese zentrale Stelle aus, dann sind die übrigen Teilnehmer des dann noch vorhandenen Komponentenensembles nicht mehr im vollen Funktionsumfang lauffähig93 . Die wichtige Forderung nach Dezentralität wird von den peer-to-peer-Systemen wie AMIGO in hervorragender Weise erfüllt. Im Prinzip zählen hier auch die auf dem Kommunikationsstandard FIPA (vgl. Kapitel 3.10) zählenden Lösungen hinzu, falls sie – wie es die FIPA-Spezifikation erlauben würde – ohne (zentrale) Facilitatoren realisiert worden sind. Gemeinhin erfüllen die dezentralen Realisierungen von Komponentenensembles jedoch die weiteren geforderten Eigenschaften Konfliktlösung und Benutzbarkeit nur bedingt. Konflikte in dynamischen Ensembles treten vor allem dann auf, wenn es mehr als nur einen Anbieter eines gesuchten Dienstes (bzw. Verbraucher einer Nachricht oder eines Ereignisses) gibt. Solche Konflikte zu lösen ist die Aufgabe von Algorithmen zum service discovery“ bzw. des service bindings“ und der ” ” ” service decomposition“. Solche Algorithmen zu entwickeln und zu implementieren ist in den bekannten peer-to-peer-Systemen Aufgabe des Entwicklers bzw. Programmierers der einzelnen Komponenten. Dies schränkt folglich die Benutzbarkeit solcher Software- Infrastrukturen für den Entwickler stark ein. Es werden ihm zwar Möglichkeiten geboten, Nachrichten mit anderen Komponenten auszutauschen; er wird jedoch zusätzlich belastet – neben der eigentlichen Aufgabe eine Applikation zu entwickeln – mit der Notwendigkeit geeignete Algorithmen zum Dienstefinden und Diensteverwalten zu implementieren94 . Die Forderung nach Echtzeit, das heißt, dass Nachrichten ohne große Verzögerung die Empfängerkomponente erreichen, wird zufriedenstellend von allen in dieser Arbeit erwähnten Infrastrukturen erfüllt. Wünschenswert – im Sinne der Benutzbarkeit einer Software-Infrastruktur – wäre das Folgende: Eine Komponente (sprich: der Entwickler einer Komponente) sollte Nachrichten erzeugen und diese in die Software-Infrastruktur hinein verschicken können. Das sich daran anschließende Service Discovery, das Service Binding und Service Decomposition sollte dann unabhängig von der Leistungsfähigkeit der Implementierung der versendenden Komponente erfolgen. Gelangt eine Nachricht zu einer Komponente, so soll sie diese sofort verarbeiten können, ohne spezielle Routinen und Nachrichtenfilter vorsehen zu müssen, um an den unterschiedlichen Service-Discovery-Nachrichten der Software- Infrastruktur und der anderen Komponenten teilzunehmen. Im SODAPOP-Modell (siehe Kapitel 4) werden die Aufgaben des Service Discovery, des Service Binding und der Service Decomposition von den Kanälen übernommen. Wichtig ist hierbei, dass ein Kanal nicht eine zentrale Instanz darstellt, sondern ver- 93 Es mag hier sein, dass jede Komponente noch ihre singulären Funktionen ausführen kann. Jedoch ist bei Ausfall zentraler Stellen (Routingserver, Blackboards, publish-subscribe-Server) keine Kooperation und Kommunikation der einzelnen Komponenten mehr möglich. 94 An dieser Stelle sei von den Erfahrungen aus dem EMBASSI-Projekt berichtet: Gefordert aus der Menge gleichartiger Geräte – wie Fernsehgeräte, Videorekorder bzw. Festplattenspeicher – auszuwählen, fanden die Entwickler (unter denen sich Programmierer von drei konkurrierenden Herstellern von Unterhaltungsgeräten befanden) eine ” naheliegende“ Lösung: Sie schickten Nachrichten und Aufträge generell nur an Geräte der eigenen Firma. Dies schränkte die Verwendbarkeit und die Szenarios stark ein. 246

eine infrastruktur f ¨ur das management von verteilten ... - DVS