Aufrufe
vor 5 Jahren

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

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

Nachrichten und auch die

Nachrichten und auch die Alternativstrategien der Konfliktlösungsstrategie zur Zuteilung von Events funktionieren ohne Kenntnis jeder Semantik), so dass sie in vielen Anwendungsszenarios Verwendung finden können, zum anderen sind die in dieser Arbeit realisierten Interpreter- und Strategiekomponenten flexibel genug implementiert, um ebenso für verschiedene Anwendungszwecke verwendbar zu sein. Die letztendliche operationale Integration muss jedoch hier der Entwickler oder der Benutzer durch die Definition neuer Regeln bzw. durch die Definition neuer Dialogkonstrukte vornehmen. Als letzte Punkte, die in dieser Arbeit nicht behandelt wurden, seien kurz die typischen Anforderungen an grundlegende Middleware-Technologien erwähnt 110 . So ist die Frage der Allokation von Ressourcen (vgl. Coen [45]) oder die Frage der persistenten Ablage von Daten in dieser Arbeit nicht behandelt. Es gäbe die Möglichkeit einen Context-Manager (analog zum EMBASSI-Projekt, vgl. [188]) zu installieren mit der Gefahr dass dieser den Anforderungen der Dynamik von Komponentenensembles widersprechen würde. Der Autor präferiert hier an dieser Stelle Dienste im Internet. Obwohl auch diese im Prinzip zentralen Stellen entsprächen, so liegen sie doch nicht offensichtlich physikalisch vor und sind auch in ” leeren“ Räumen – in denen sich ad-hoc Geräteverbünde bilden sollen – verfügbar. Auch die Frage des Status von Komponenten – eine wesentliche Eigenschaft des PCOM-Systems der Universität Stuttgart (vgl. Kapitel 3.9 und [95]) – bleibt in dieser Arbeit unbeantwortet. Die hier verwendeten Komponenten ” leben“ über ihre Laufzeit hinaus nicht. Vor allem die Frage der Integration verschiedenster heterogener Geräte und heterogener Protokolle (wie z. B. im AMIGO-Projekt) ist nicht Teil dieser Arbeit. Die in dieser Arbeit implementierte Software-Infrastruktur – aufgrund der Implementation in Java – ist aber auf verschiedenen heterogenen Betriebssystemen lauffähig. 110 An dieser Stelle sei Middleware als die Schicht unterhalb einer Software-Infrastruktur definiert. Während eine Software-Infrastruktur über Mechanismen und Strategien zur Aufrechterhaltung der semantischen Kommunikation, zum Auffinden von Diensten und zur Zuteilung von Nachrichten verfügt, ist die Aufgabe einer Middleware näher an der Hardware. Eine Middleware stellt die prinzipielle physikalische Grundlage zur Kommunikation sicher und ist in der Lage heterogene Standards zu einem Kommunikationsstandard zu vereinigen. 259

10 Ausblick und weiterführende Arbeiten Zwei unterschiedliche Arten der Komponentenintegration sind für die Gewährleistung von Selbstorganisation von dynamischen Komponentenensembles laut Encarnação und Kirste [66] notwendig. Die architektonische Integration bezieht sich auf die Integration eines (neuen) Gerätes in das Kommunikationsmuster eines bereits vorhandenen Geräteensembles. Hier sei die Integration eines Spracherkenners in den multimodalen Eingangskanal eines Ensembles, oder die Integration eines CD-Spielers in den Geräte bzw. Funktionskanal eines Ensembles als Beispiele genannt. Die operationale Integration beschreibt dagegen die Möglichkeit neue Funktionen – die entweder durch die eigenen Funktionen eines neuen Gerätes, oder durch die Kombination von Funktionen des neuen Gerätes mit Funktionen bereits vorhandener Geräte – dem Benutzer verfügbar zu machen. Hier lassen die Integration einer neuen Lichtquelle, die vom Gesamtsystem bei der Steuerung der Raumhelligkeit benutzt werden kann, oder die Integration eines CD-Rekorders, der im kooperativen Zusammenspiel mit einem bereits vorhandenen CD-Player die Möglichkeit von direkten Kopien erlaubt als Beispiele anführen. Ein intuitives Beispiel ist für die operationale Integration ist die dynamische Verbindung eines DVD-Spielers mit einem DVD-Rekorder. Neben dem reinen Abspielen und Aufzeichnen von Filmen ist nun auch das Konzept ” DVD kopieren“ (prinzipiell) möglich. Die Aufgabe dieser Arbeit war es nicht diese Art von Integration zu ermöglichen, sondern sich auf den ersten Punkt zu konzentrieren. Die unbedingte Voraussetzung von ad-hoc Kooperation und vom dynamischen Bilden von neuen Funktionen ist die architektonische Integration. Die architektonische Integration – die von der verteilten Implementierung der in dieser Arbeit vorgestellten Software-Infrastruktur bewerkstelligt wird – macht es erst möglich, neue Geräte in den bereits vorhandenen Kommunikationsfluss eines Geräteensembles zu integrieren. Nun kann in späteren Arbeiten die wissenschaftliche Herausforderung der operationalen Integration angegangen werden. Die aus EMBASSI-Publikationen entnommene Abbildung 129 zeigt ein Szenario das durch operationale Integration möglich wird. Ein Benutzer zeigt auf der Bildschirm eines Fernsehgerätes mit den Worten ” heller“. Offensichtlich möchte der Benutzer das Bild heller haben, womöglich um den Kontrast des Fernsehbildes zu erhöhen. Eine mögliche Reaktion der intelligenten Umgebung zeigt Abbildung 129 rechts. Wenn die Helligkeit am Fernsehgerät schon maximal eingestellt ist, kann mittels Kooperation von Raumbeleuchtung und Rollladen eine – relative – Helligkeitserhöhung des Fernsehbildes erreicht werden. Würde keine operationale Integration erfolgen, so würde das Gesamtensemble versuchen die Bildschirmhelligkeit zu erhöhen und letztlich scheitern und den Benutzerwunsch nicht erfüllen können. Ponnekanti [175] – einer der Entwickler des Interactive Workspaces Project – schlägt bezüglich der operationalen Integration eine Lösung vor: Ein Komponentenensemble müsste immer alle möglichen Kombinationen aller möglichen von den einzelnen Geräten zur Verfügung gestellten Funktionen anbieten. Dies kann allein schon aufgrund einer einfachen Plausibilitätsüberlegung nicht sehr wirkungsvoll sein. Drei Geräte mit jeweils drei Funktionen würden schon 27 mögliche Kombinationen (ohne Berücksichtigung von Funktionskombinationen von zweien aus diesen drei Geräten) bedeuten. 260

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