Aufrufe
vor 5 Jahren

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

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

teilt implementiert ist.

teilt implementiert ist. Die Einführung der Kanäle behebt somit gleich zwei Nachteile der Software-Infrastrukturen, die auf zentralen Komponenten basieren. Kanäle sind definiert als verteilt existierende Instanzen. Somit besitzt eine Infrastruktur, die auf dem SODAPOP-Modell basiert keine zentrale Instanz. Die Tatsache, dass es mehrere Kanäle geben kann – sinnvollerweise ist die Definition von Kanälen von den darauf zu sendenden und empfangenden Nachrichten abhängig –, erlaubt die Parallelverarbeitung von Nachrichten. Nachrichten müssen somit nicht durch einen singulären umfangreichen Kanal bearbeitet werden. Gewissermaßen erweiterte das SODAPOP-Modell somit das Blackboard- Prinzip. Nachrichten gelangen in einen Kanal hinein und aus diesem wieder hinaus. Im Gegensatz zum Blackboard-Prinzip werden die Kanäle aber über alle Komponenten verteilt und können vielfach vorhanden sein. Zur Behandlung von Nachrichten verfügen Kanäle über Konfliktlösungsstrategien um den Fall von konkurrierenden Komponenten zu meistern. Sendet eine Komponente eine Nachricht in einen Kanal, so evaluiert dieser Kanal mittels dieser Nachricht die UtilityValue-Funktionen aller an diesem Kanal registrierten Komponenten. Die kanal-eigene Konfliktlösungsstrategie teilt den Komponenten dann auf Basis der initialen Nachricht und den evaluierten UtilityValue-Funktionen die ursprüngliche oder abgeänderte Nachricht zu. Wird folglich eine Software-Infrastruktur auf Basis des SODAPOP-Modells den Entwicklern von verteilten Komponentensystemen zur Verfügung gestellt, so sind diese in der Lage nur auf Basis der auszutauschenden Nachrichten die jeweils eigenen Komponenten zu erstellen. Verfügt die Software-Infrastruktur über ” eingebaute“ kanal-eigene Konfliktlösungsstrategien, so sind Komponentenentwickler von der Implementierung eigener Service-Discovery- und Service-Binding-Methoden entlastet. In Kapitel 5 dieser Arbeit wird die Implementierung einer Software-Infrastruktur auf Basis des SODAPOP-Modell im Detail besprochen und spezifiziert. Hierbei wird in der verteilten Implementierung der Ansatz gewählt, auf jedem physikalischen Gerät einen sogenannten SODAPOPD(AEMON) als Hintergrunddienst für die auf diesem Gerät laufenden Komponenten zu realisieren. Dieser SODAPOPD(AEMON) übernimmt für ” seine“ Komponenten die Verwaltung der Kanäle, die Ausführung der kanal-eigenen Konfliktlösungsstrategien und die Kommunikation mit den SODAPOPD(AEMON)s der anderen physikalischen Geräte (und damit mit deren Kanälen und Komponenten). Die SODA- POPD(AEMON)s sind, um diese Aufgaben ausführen zu können, als Multithread-Applikationen (vgl. eine wesentliche Forderung von Brumitt [33]) implementiert. Auf den ersten Blick scheint ein zentraler Hintergrunddienst wie die Realisierung der SODA- POPD(AEMON)s pro Gerät im Widerspruch zu dem in den Anforderungen und auch eben in diesem Kapitel Besprochenen zu stehen. Es ist aber realistischer zu fordern, dass jedes physikalische Gerät autonom sein soll. Auch aus Anwendersicht ist dies vernünftig. Schließlich bestehen reale Umgebungen aus den unterschiedlichsten physikalischen Geräten und aus Anwendersicht nicht aus Software-Komponenten. Letztlich werden immer physikalische Geräte ad-hoc miteinander zusammengebracht. Fällt ein SODAPOPD(AEMON) aus, so bedeutet dies folglich, dass das zu diesem SO- DAPOPD(AEMON) gehörende Gerät ein bestehendes Geräteensemble verlassen hat. Tritt ein SODAPOPD(AEMON) einer Gruppe bereits vorhandener SODAPOPD(AEMON)s bei, 247

so hat sich ein bereits bestehendes Geräteensemble um ein weiteres Gerät erweitert. Die Definition eines SODAPOPD(AEMON)s pro physikalischen Gerät entspricht somit exakt den in Kapitel 2.3 und in diesem Kapitel besprochenen Anforderungen an eine verteilte Software-Infrastruktur für dynamische Geräteensembles 95 . Zwei weitere mögliche Implementierungen sollen an dieser Stelle nicht unbesprochen bleiben. Unter Verzicht auf einen SODAPOPD(AEMON) pro physikalischen Gerät könnte auch jede einzelne Software-Komponente – sprich Transducer – die Kanäle, an denen sie konnektiert ist, und die Realisierung der von diesen Kanälen auszuführenden Konfliktlösungsstrategien selbst implementieren. Im Prinzip würde dies der Realisierung eines peer-to-peer- Komponentensystems entsprechen. Der einzige Vorteil wäre, dass nun die Komponenten nicht mehr von der Präsenz und der Funktionsfähigkeit eines (für diese Komponenten zentralen) SODAPOPD(AEMON)s angewiesen wären. Somit wäre eine erhöhte Autonomie bis hin auf Komponentenebene und eine noch höhere Dezentralisierung gegeben 96 . Die Nachteile einer solchen Lösung liegen jedoch klar auf der Hand: Sollte jede Komponente die Kanäle, an denen sie konnektiert ist, selbst verwalten müssen, so muss sie auch die Kommunikation mit allen anderen Komponenten (auf den anderen Geräten) gewährleisten, die an diesen Kanälen konnektiert sind. Die Komponenten haben somit einen massiven Kommunikations- und auch Verwaltungsaufwand, der dann natürlich auch den Aufwand für den Entwickler einer solchen Komponente erhöht. Darüber hinaus müsste jede einzelne Komponente in der Lage sein, die zu diesen Kanälen gehörenden Konfliktlösungsstrategien auszuführen 97 . Tatsächlich bedeutet diese Notwendigkeit wiederum nicht nur einen erhöhten Aufwand für einen Komponentenentwickler, auch das Gerät an sich wäre bei mehreren Komponenten über Gebühr hinaus belastet, da nun jede Komponente die Konfliktlösung implementieren und auch ausführen muss 98 . Die zweite andere mögliche Implementierung (neben der Realisierung von SODAPOP als reines peer-topeer-System bzw. der in dieser Arbeit spezifizierten SODAPOPD(AEMON)s) besteht in der Realisierung der Kanäle nicht nur als virtuelle Entitäten, sondern als eigenständige lauffähige Komponenten. Diese ” Kanalkomponenten“ müssten die Kommunikation zu den zum Gerät gehörenden Komponenten zum einen und zu den anderen Kanalkompo- 95 Tatsächlich ist die in Kapitel 5.1 spezifizierte Lösung für das SODAPOP-Modell eine Software- Infrastruktur für verteilte Komponentenensembles und die in Kapitel 5.2 spezifizierte verteilte Software- Infrastruktur eine Lösung für verteilte Geräteensembles. 96 In wie weit die Funktionalität einer Komponente auf einem physikalischen Gerät gewährleistet werden kann, wenn auf demselben Gerät ein wesentlicher Hintergrunddienst nicht lauffähig ist, stellt einen anderen Gesichtspunkt dar und soll an dieser Stelle nicht weiter vertieft werden. 97 Im Grunde würde diese Lösung nichts weiter bedeuten, als dass jede Komponente wieder für die bereits diskutierten Kommunikationsmechanismen Service Discovery, Service Binding und Service Decomposition verantwortlich wäre. 98 Der Autor dieser Arbeit ist hier auch der Meinung, dass genau in diesem Punkt der wesentliche Nachteil der in dieser Arbeit im Detail beschriebenen (vgl. Kapitel 3) anderen Software-Infrastrukturen und Kommunikationstechnologien besteht. Die Negierung der physikalischen Geräte (mit Ausnahme von PCOM, vgl. Kapitel 3.9) und der damit verbundenen Konzentration auf die reinen Softwarekomponenten und dem damit wiederum verbundenen ” Overhead“ an Vergeudung von Rechen- aber auch Implementationsressourcen bringen wesentliche Nachteile in Bezug auf Benutzbarkeit, aber auch auf Erweiterbarkeit und Autonomie der einzelnen Geräte mit sich. 248

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