Aufrufe
vor 5 Jahren

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

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

nenten (auf den anderen

nenten (auf den anderen physikalischen) Geräten realisieren. Kanäle würden somit Peers im Sinne eines peer-to-peer-Systems darstellen. Im Vergleich zu der in Kapitel 5.2 spezifizierten Lösung auf der Basis von SODAPOPD(AEMON)s würden die Kanalkomponenten in der Summe (ihrer Funktionalitäten) einen gemeinsamen SODAPOPD(AEMON) realisieren. Die Realisierung des SODAPOP-Modells auf der Basis verteilter Kanalkomponenten würde somit im Vergleich zu der in dieser Arbeit realisierten Implementierung einen erhöhten Verwaltungsaufwand pro physikalischem Gerät bedeuten. Der Kommunikationsaufwand bliebe gleich 99 . Die Nachteile der reinen peer-to-peer-Lösung, bei der jede Komponente für sich für die Ausführung der kanal-eigenen Konfliktlösungsstrategien verantwortlich wäre und die Nachteile der möglichen Realisierung des SODAPOP-Modells auf der Basis von Kanalkomponenten, die den Verwaltungsaufwand pro Gerät erhöhen würden 100 überwiegen somit bei weitem die damit einhergehenden eventuellen Vorteile. Diese Überlegungen haben letztlich zur Entscheidung für die in dieser Arbeit vorgestellte Software-Infrastruktur auf der Basis von geräte-eigenen SODAPOPD(AEMON)s geführt. Die folgenden Überlegungen sollen es ermöglichen einen Leistungsvergleich mittels einer Plausibilitätsüberlegungen zu ermöglichen. Blackboard-Systeme (wie die Open- Agent-Architecture, vgl. Kapitel 3.7 oder der Galaxy Communicator, vgl. Kapitel 3.8) ermöglichen es, in zwei Kommunikationsschritten eine Nachricht vom Sender zum Empfänger zu senden. Hierbei sendet der Absender eine Nachricht zu einer zentralen Stelle, von der aus sie zum Empfänger weitergeleitet wird. Dazwischen findet das Nachsehen in einem Look-up-Service oder das Inferieren eines regelgesteuerten Routingsystems statt 101 . Der Aufwand in solchen Systemen eine Nachricht vom Absender zum Adressaten zu versenden beträgt somit 3 Arbeitsschritte (reine peer-to-peer-Systeme, bei denen jede Komponente über einen eigenen Look-up-Service verfügt benötigen im Sinne der hier gemachten Definitionen zwei Arbeitsschritte). Peer-to-peer-Systeme, in denen das Service-Discovery und Service-Binding von den Komponenten übernommen werden muss, müssen die folgenden Schritte bewältigen: Die Komponente, die einen Auftrag versenden will, befragt mittels einer Nachricht eine zentrale Stelle nach den möglichen Adressaten (hier: Versenden einer Nachricht an eine zentrale Registry, Look-Up inner- 99 Es würde sich noch die Frage der automatischen Erzeugung von Kanalkomponenten stellen, sobald eine Komponente einen solchen Kanal erzeugt. Ein Gerät müsste somit bereits laufende Kanalkomponenten vorhalten können, bzw. Komponenten müssten in der Lage sein, auf Geräten autonome Kanalkomponenten definieren und starten zu können. 100 Folgende Überlegungen können hier gemacht werden: Drei Kanalkomponenten pro physikalischen Gerät (vgl. die drei Kanäle in der erweiterten Basistopologie in Abbildung 73) würden drei unterschiedliche IP-Adressen oder eine einheitliche IP-Adresse mit der Definition unterschiedlicher Portnummern bedeuten. Kanäle die dynamisch erzeugt werden, müssten somit in der Lage sein, dynamische IP-Adressen bzw. dynamische Portnummern zu erzeugen und diese den jeweils anderen Geräten mitzuteilen. Allein diese Notwendigkeiten würde einen erhöhten Verwaltungsaufwand, neben der Kommunikation der Kanalkomponenten miteinander, bedeuten oder die Definition einer zentralen Verwaltungskomponente, die wiederum die unterschiedlichen Kanalkomponenten eineindeutig verwalten kann. Die letztere Lösung führt automatisch zur Definition der SODAPOPD(AEMON)s. 101 Da hier von System zu System unterschiedliche Mechanismen angewendet werden soll für diesen Plausibilitätsansatz jeweils ein Aufwand der Ordnung 1 angenommen werden (z. B. Nachsehen in einer Tabelle, Ausführen einer Regel). 249

halb der Registry und Antworten an den Auftraggeber), muss nach Erhalt einer solchen Liste einen internen Service-Binding-Prozeß durchführen und kann dann die Nachricht an den eigentlichen Adressaten versenden. Für die Plausibilität genügt hier die Feststellung, dass es 5 unterschiedlicher Arbeitsschritte bedarf in peer-to-peer-Systemen auf der Basis von Service-Discovery-Mechanismen eine Nachricht vom Absender zum eigentlichen Empfänger zu versenden 102 . In der Realisierung von SODAPOP auf der Basis des in Kapitel 5.1 realisierten SODAPOPD(AEMON)s müssen für dynamische Komponentenensembles die folgenden Arbeitsschritte erfolgen: Komponente sendet mittels seines Kanalobjektes (vgl. Abbildung 51) eine Nachricht an den geräte-eigenen SODAPOPD(AEMON). Dieser sendet an die am entsprechenden Kanal konnektierten Komponenten eine Nachricht, um die entsprechenden UtilityValue-Funktionen zu evaluieren. Nach Erhalt aller dieser Funktionen führt der SODAPOPD(AEMON) die Konfliktlösungsstrategie aus und sendet gemäß den Ergebnissen dieser Strategie Nachrichten an die ” gewinnenden“ Komponenten. Für diesen Prozess finden somit vier Nachrichtenprozesse, eine Evaluierung einer UtilityValue-Funktion und die Ausführung einer Konfliktlösungsstrategie statt. Für die Plausibilitätsbetrachtung, die hier vorgenommen werden soll, bedeutet dies in der Summe 6 Arbeitsschritte. Betrachtet man die Realisierung des SODAPOP-Modells auf der Basis der verteilten Implementierung nach Kapitel 5.2 so kommt zusätzlich zu den eben aufgezählten Arbeitsschritten noch die Kommunikation der SODAPOPD(AEMON)s untereinander hinzu. Dies sind (vgl. Abbildung 62) vier zusätzliche Kommunikationsschritte. Somit sind hier in der verteilten Realisierung 10 Arbeitsschritte zur Zuteilung einer Nachricht notwendig. Dies ist der komplett fehlenden ” Festverdrahtung“ der Kommunikationswege und der damit realisierten Dynamik innerhalb eines Komponenten- bzw. Geräteensembles geschuldet. Man kann hier vom Preis der Dynamik sprechen. Aus der Analyse der Szenarios und den in den eigenen Projekten EMBASSI und DYNAMITE, die sich mit der Realisierung von intelligenten Umgebungen beschäftigt haben, kann davon ausgegangen werden, dass schon mit einer Anzahl an Geräten unterhalb der Einhundertgrenze die meisten der erwähnten Szenarios realisiert werden kann. Dies dürfte keine Einschränkungen im Sinne der hier gemachten Plausibilitätsuntersuchungen darstellen. Eine Verminderung der Anzahl der Kommunikationen zwischen den geräte-eigenen SO- DAPOPD(AEMON)s und den eigenen Transducern kann erfolgen, in dem zwischen statischen und nicht-statischen UtilityValue-Funktionen unterschieden werden würde. Bei Konnektion eines Transducers an einen SODAPOPD(AEMON) könnte dieser seine statischen UtilityValue-Funktionen übergeben. Der Aufwand von zwei Kommunikationswegen und einer transducer-seitigen Evaluierung der UtilityValue-Funktion reduziert sich somit auf den Aufwand des Nachsehens in einer Look-up-Tabelle auf Seiten der SO- DAPOPD(AEMON)s. Die 6 Arbeitsschritte (bzw. die 10 Arbeitsschritte in der verteilten Implementierung) reduzieren sich dabei im optimalen Fall auf 4 Arbeitsschritte (bzw. 8 Arbeitsschritte). Der optimale Fall würde bedeuten, dass alle UtilityValue-Funktionen in den Look-up-Tabellen der SODAPOPD(AEMON)s auffindbar sind. 102 Sollte dieser Mechanismus über einen Broadcast an alle möglichen Empfänger einer Nachricht erfolgt sein, so bleibt die Anzahl der 5 Arbeitsschritte konstant, da die internen Verarbeitungsschritte der antwortenden Komponenten und deren Antwort zeitgleich parallel erfolgen. 250

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