Universität Stuttgart Fakultät Informatik

Transkript

1 Universität Stuttgart Fakultät Informatik Prüfer: Prof. Dr. rer. nat. Dr. h.c. Kurt Rothermel Betreuer: Dr. phil. nat. Christian Becker Dipl. inf. Gregor Schiele Beginn am: Beendet am: CR-Nummer: C.2.4, D.2.11, D.2.12, D.4.1, D.4.4, D.4.7 Diplomarbeit Nr Basisdienste für Anwendungen in ubiquitären Rechnersystemen Holger Gubbels Institut für Parallele und Verteilte Systeme (IPVS) Abteilung Verteilte Systeme Breitwiesenstr Stuttgart

2

3 Zusammenfassung In der sich rasch entwickelnden Welt der Kleinrechnersysteme werden allgegenwärtig verfügbare Anwendungssysteme von immer größerer Bedeutung. Durch die Heterogenität der Zielsysteme, unterschiedlicher Ressourcenbeschränkungen und die Mobilität der Benutzer müssen sich Anwendungsentwickler neuen Herausforderungen stellen. Diese Arbeit beschreibt Anforderungen an eine Infrastruktur zur Unterstützung von Anwendungssystemen in ubiquitären Rechnersystemen. Es wird eine auf einem Mikrokern basierende Architektur vorgeschlagen. Auf diese Weise werden die Ziele bezüglich Erweiterbarkeit, minimaler Konfiguration, flexibler Protokollauswahl und einer einheitlichen Programmierschnittstelle erreicht. Schließlich wird die vorgeschlagene Architektur in ein reales System umgesetzt und evaluiert.

4

5 Diese Arbeit möchte ich meinen Eltern widmen, ohne die dieses Studium und damit auch diese Arbeit nicht möglich gewesen wäre 12. November 2002

6

7 Inhaltsverzeichnis 1 Einleitung Allgemein Motivation Struktur dieser Arbeit Grundlagen Komponenten RPC Remote Procedure Call JAVA Middleware Parameterübergabe-Semantiken TupleSpaces Analyse Anforderungen Einheitliches Programmiermodell Flexibilität des Transports Konfigurierbarkeit Verwandte Arbeiten und Technologien RMI JINI CORBA Gaia AURA one.world Puppeteer Konzepte Applikationen im UbiComp Interaktion und Basiskommunikation

8 vi INHALTSVERZEICHNIS Stellvertreter-Objekte Systemkommunikation Konfigurierbarkeit des Systems Discovery und Lookup Semantiken eines Dienstaufrufs Entwurf Architektur von BASE Komponentensystem SystemCore Installation von Komponenten Registrierung und Lookup Basiskommunikation Plugins Implementierung Package Struktur ClassLoader in BASE Nutzung der IBM J9 als Java-VM Evaluation Übersicht Leistungsmessung Beschreibung Ergebnisse Speicherbedarf Zusammenfassung und Ausblick Zusammenfassung Ausblick Übertragung von Klasseninformationen zur Laufzeit Systemdienste Erweiterung um Migration Aufrufoptimierung Literaturverzeichnis 86 A Package framework 87 A.1 Classes A.1.1 Class Main A.1.2 Class NotYetImplementedError

9 INHALTSVERZEICHNIS vii B Package framework.service 91 B.1 Interfaces B.1.1 Interface IService B.1.2 Interface IServiceContext B.1.3 Interface IServiceMoniker B.2 Classes B.2.1 Class InvocationException B.2.2 Class ServiceImplementation C Package framework.plugin 103 C.1 Interfaces C.1.1 Interface IPlugin C.1.2 Interface IPluginManager D Package framework.plugin.wellknowninterfaces 107 D.1 Interfaces D.1.1 Interface IDiscovery D.1.2 Interface IRemoting E Package framework.logging 111 E.1 Classes E.1.1 Class Logging

10

11 Abbildungsverzeichnis 2.1 Schematische Darstellung der RPC-Semantiken Die drei Hauptelemente von Java Java Plattformen Middleware-Architektur TupleSpace Operationen JINI Architektur Gaia Architektur Architektur von Puppeteer Proxy-Skeleton Konzept Entfernte Nachrichtenzustellung Architektur von BASE Lokale Kommunikation in BASE (synchroner Aufruf) Entfernte Kommunikation in BASE (synchroner Aufruf) Vergleich entfernter Aufruf RMI vs. BASE Vergleich lokaler Aufruf RMI vs. BASE Unterschied Aufruf zwischen Base und RMI

12

13 Tabellenverzeichnis 7.1 Metriken der Implementierung Ergebnisse der entfernten Aufruf-Messungen Ergebnisse der lokalen Aufruf-Messungen

14

15 Kapitel 1 Einleitung In diesem Kapitel wird zunächst einleitend die Entwicklung der Informationssysteme, insbesondere die der Kleinrechner, angesprochen. Die resultierende Allgegenwärtigkeit von Rechnersystemen wird herausgestellt. Durch ein Szenario wird dies weiter verdeutlicht und das Thema der Arbeit motiviert. 1.1 Allgemein Die drastische Entwicklung der Informationssysteme und dadurch auch der Kleinrechnersysteme hat in den letzten zehn Jahren ein immer größer werdendes Bedürfnis nach Unterstützung von Mobilität geschaffen. Der Mobiltelefonmarkt explodierte. Schon heute existieren mehr mobile Telefon-Verträge als sogenannte Festnetzanschlüsse. Mobiltelefone übernehmen heute schon mehr als nur Kommunikationsfunktionen. Auch hier ist die Softwareentwicklung nicht stehen geblieben. Spiele, kleinere Notizblöcke oder Kalender gehören heute zu der Standardausstattung. Auch der Markt der mobilen Computer, sogenannte PDAs (für Personal Digital Assistant), hat sich in den letzten Jahren immer mehr etabliert. Einfache Applikationen wie Kalendersysteme und andere kleine Verwaltungsanwendungen gehören in diesem Bereich zu den gebräuchlichsten Anwendungen. Dies führt zu einer zunehmenden Integration der Funktionalität von PDAs und Mobiltelefonen. Die ersten PDAs mit integriertem Mobiltelefon sind bereits erhältlich. Kleine Rechnersysteme werden oder sind bereits in viele Alltagsgeräten integriert. Fernsehgeräte mit Internetzugang, Kaffeemaschinen mit PC-Schnitt-

16 2 Einleitung stelle oder Autoradios mit WindowsCE sind schon lange keine Vision mehr. Neue Verbindungstechnologien wie z.b. IRDA (Infrarot), WLan (Funknetz) oder Bluetooth erobern den Markt. Alltagsgegenstände können technisch gesehen untereinander autonom Daten austauschen, z.b. könnte die Kalenderapplikation auf dem PDA eines Benutzers einem Wecker mitteilen, um welche Uhrzeit dieser zu klingeln hat. Mark Weiser hat im vergangenen Jahrzehnt den Begriff des Ubiquitous Computing geprägt [47]. Computing everywhere an jedem Ort verfügbare Rechnersysteme, die sich transparent in Alltagsgegenstände integrieren und sich selbst verwaltende Softwaresysteme, die sich der Umgebung anpassen oder dem Benutzer folgen: The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it Mark Weiser. Die Entwicklung des Ubiquitous Computing steht noch am Anfang. Wie in den meisten Bereichen der Informationstechnik ist die Entwicklung der Hardware und deren Integration in andere Geräte schneller als die dafür notwendige Software. Im Bereich mobiler Systeme ist die wachsende Komplexität durch neue Anforderungen an Softwaresysteme ein wichtiger Grund für diese Entwicklung. Die Unterstützung der Entwicklung solcher Systeme soll Schwerpunkt dieser Arbeit sein. 1.2 Motivation Ubiquitous Computing (kurz UbiComp) stellt einen Paradigmenwechsel dar, in dem Systeme und Technologien im täglichen Leben integriert werden aber unsichtbar bleiben. Ziel ist es, den Computer als reine Erweiterung der physischen Welt zu betrachten, ihn aber möglichst vollständig unsichtbar zu halten ( virtuelle Erweiterung von Alltagsgegenständen). Dieses Paradigma ist also weit entfernt von der sogenannten virtuellen Realität. Während dort der Mensch in eine computergenerierte Welt geführt wird, beschreibt das UbiComp-Paradigma die Eingliederung des Computers in das tägliche Leben. Daraus folgt also, dass nicht der Computer Gegenstand der Betrachtung ist, sondern ausschließlich Werkzeug für eine Virtualisierung von Alltagsgegenständen. Im Zentrum stehen Benutzer und die von ihnen benötigten Dienste. Um die Motivation klarer herauszustellen und um später die Anforderungen an Basisdienste definieren zu können, muss die Aufgabenstellung klarer

17 1.3 Struktur dieser Arbeit 3 gefasst werden. Dazu wird zunächst eine Art Szenario entwickelt, in dem beispielhaft Zielgeräte zum Einsatz kommen, die grob die Klassen der Zielplattformen darstellen. Dabei handelt es sich um Geräte wie Sensoren. Solche Sensoren sammeln in ihrer Umgebung Daten wie Helligkeit, Temperatur, Luftfeuchtigkeit oder Lautstärke und teilen das benachbarten Geräten z.b. via Infrarot mit. Aus solchen Daten kann dann geschlossen werden, ob sich Personen in einem Raum befinden oder ob Licht im Zimmer notwendig ist. Solche Daten können dann über ein einfaches ereignisbasiertes Protokoll propagiert werden. Dieses Protokoll könnte z.b. einfach die ID des Sensors und die gesammelten Daten periodisch an einen Ereignisdienst senden, an dem sich beliebige Geräte registrieren können. Mobile Geräte, wie PDAs, haben mehr Rechenleistung und können evtl. auch noch weitere Dienste anbieten, wie beispielsweise Standortabfragen über einen integrierten GPS-Sensor. Diese Art mobiler Geräte bieten üblicherweise neben Infrarot weitere Kommunikationsschnittstellen an, z.b. Bluetooth oder IEEE Neben diesen Kleingeräten sind auch weiterhin einfache Desktop PCs Teil einer solchen Umgebung. Diese Geräte können ebenfalls Dienste anbieten, beispielsweise einen Zugang ins Internet, oder einfach nur Rechenleistung, die genutzt werden kann. Dazu kommen auch speziellere Geräte zum Einsatz wie Videoprojektoren, SmartBoards oder herkömmliche Telekommunikationseinrichtungen. Zukünftig wird die Produktvielfalt immer größer werden und es wird immer mehr Rechenleistung und Intelligenz in solche Alltagsgeräte eingebaut werden. Ausgelöst durch die Heterogenität der Zielsysteme, den Leistungseinschränkungen und vor allem die durch Mobilität ausgelöste spontane Vernetzung, stehen Applikationsentwickler vor neuen Anforderungen. Ziel dieser Arbeit ist es, diese Anforderungen zu beschreiben und Konzepte zu entwickeln, mit denen man ihnen begegnen kann. 1.3 Struktur dieser Arbeit Die weitere Arbeit ist wie folgt strukturiert: Nachdem in diesem Kapitel die Arbeit kurz motiviert wurde, erläutert Kapitel 2 kurz die Grundlagen für das Verständnis der weiteren Arbeit. Ka-

18 4 Einleitung pitel 3 definiert die Anforderungen an ein System, das in diesem Kapitel motiviert wurde, und stellt kurz verwandte Arbeiten vor. Im Kapitel 4 werden Konzepte erarbeitet, um die Anforderungen aus Kapitel 3 umsetzen zu können. Diese Konzepte werden in Kapitel 5 in einen Entwurf eines realen Systems umgesetzt, das prototypisch implementiert wird. Die Implementierungsaspekte werden in Kapitel 6 erläutert. In Kapitel 7 werden die Konzepte durch Messungen evaluiert. Kapitel 8 fasst den Inhalt kurz zusammen und gibt Vorschläge für zukünftige Weiterentwicklungsmöglichkeiten. Im darauffolgenden Appendix befinden sich dann Informationen bzgl. der Nutzung der Infrastruktur.

19 Kapitel 2 Grundlagen In diesem Kapitel werden Grundlagen eingeführt, die für das Verständnis weiterführender Kapitel notwendig sind. Auf die einzelnen Unterkapitel wird bei Verwendung jeweils verwiesen. 2.1 Komponenten Ähnlich den sogenannten IC s (Integrated Circuit) im Elektrotechnikbereich gibt es bei Softwaresystemen die Bestrebung der Wiederverwendbarkeit. Szyperski definiert eine Komponente folgendermaßen: Software components are binary units of independent production, acquisition, and deployment that interact to form a functioning system. [41]. Eigenschaften sind also: Binary Komponenten werden nicht im Quellcode verteilt, sondern in einer ausführbaren Form Independent Komponenten sind unabhängig, d.h. sie sind eigenständig lauffähig Deployment Komponenten können auf eine definierte Weise eigenständig verteilt werden Interaction Komponenten können untereinander interagieren

20 6 Grundlagen Diese Definition wird als Grundlage für vorliegende Arbeit verwendet. Problematisch an dieser Definition ist die Aussage der Unabhängigkeit. Unter der Annahme dass mehrere Komponenten zusammen einen Dienst bilden und daher ihre Nutzbarkeit gewissen Abhängigkeiten unterworfen ist, muss die Unabhängigkeit einer Komponente keine Voraussetzung sein. 2.2 RPC Remote Procedure Call Ein Remote Procedure Call ist eine Technik, mit der entfernte Methodenaufrufe ermöglicht werden. Mittels eines RPCs kann ein Programmierer entfernte Methoden aufrufen als wären sie lokal, also durch einen synchronen Prozeduraufruf. Üblicherweise wird dies bewerkstelligt, indem auf der Seite des Aufrufers ein sogenanntes Stellvertreter-Objekt verfügbar ist das dafür sorgt, dass der Aufrufer bis zur Antwort blockiert und der Aufruf über ein entsprechendes Protokoll zum Anbieter gesendet wird. Auf der Seite des Anbieters befindet sich ein weiteres Stellvertreter-Objekt das die Nachricht entgegen nimmt, dekodiert, den entsprechenden Aufruf tätigt und danach die Antwort wieder zum Aufrufer zurücksendet (siehe Proxy oder Surrogat [15]). Die Funktion des Kodierens bzw. des Dekodierens eines Aufrufs nennt man in diesem Zusammenhang marshalling bzw. unmarshalling. Bei entfernten Aufrufen sind mehr Fehlertypen denkbar als bei lokalen. Folgende Semantiken sind definiert worden (schematisch siehe Abbildung 2.1): Maybe Ein Aufruf ist entweder einmal oder gar nicht ausgeführt worden. Im Fehlerfall weiss der Aufrufer nicht, ob der Aufruf ausgeführt wurde oder nicht. At-least-once Der Aufruf wurde mindestens einmal ausgeführt. Mit anderen Worten: der Aufruf kann auch mehrmals ausgeführt worden sein. Einzige Ausnahme ist ein Knotenfehler dann ist die Ausführung nicht garantiert. At most-once Der Aufruf wird genau einmal ausgeführt. Das gilt allerdings nur solange kein Knotenfehler besteht. Im Falle eines Knotenfehlers ist nicht garantiert, dass der Aufruf ausgeführt wurde. Es ist aber garantiert, dass der Aufruf nicht mehrmals ausgeführt wurde. Exactly-once Die stärkste Semantik: der Aufruf wird ohne Einschränkungen genau einmal ausgeführt.

21 2.3 JAVA 7 Types of errors Failure Semantics No Errors Message lost Additionally: Server Failure Additionally: Client Failure MAYBE Execution: 1 Result: 1 Execution: 0/1 Result: 0/1 Execution: 0/1 Result: 0/1 Execution: 0/1 Result: =/1 AT-LEAST- ONCE Execution: 1 Result: 1 Execution: >=1 Result: >=1 Execution: >=0 Result: >=0 Execution: >=0 Result: 0 AT-MOST- ONCE Execution: 1 Result: 1 Execution: 1 Result: 1 Execution: 0/1 Result: 0/1 Execution: 0/1 Result: 0 EXACTLY- ONCE Execution: 1 Result: 1 Execution: 1 Result: 1 Execution: 1 Result: 1 Execution: 1 Result: 1 Abbildung 2.1: Schematische Darstellung der RPC-Semantiken 2.3 JAVA JAVA ist eine Technologie, die Anfang 1990 von SUN Microsystems entwickelt worden ist. Ziel dieser Technologie ist, eine plattformunabhängige Entwicklung von Applikationen mittels einer eigenen Programmiersprache zu ermöglichen [40]. Die Plattformunabhängigkeit wurde dadurch erreicht, dass SUN zusätzlich zur Definition der Programmiersprache die Spezifikation einer sogenannten Virtual Machine (VM) entwickelte, die als virtuelles Betriebssystem für JAVA Applikationen dient. Die VM kapselt Betriebssystemdienste und macht sie durch eine entsprechende API der Programmiersprache verfügbar. Dadurch wird die Applikation durch Einführung eines Laufzeitsystems vom Betriebssystem entkoppelt (siehe Abbildung 2.2). Applikationen sind damit auf allen Zielsystemen lauffähig, auf denen eine solche VM zur Verfügung gestellt wird. JAVA ist eine interpretierte Programmiersprache. Programmdateien werden in einen sogennanten JAVA-Bytecode übersetzt, der für den Interpreter lesbar ist. JAVA galt bisher im Allgemeinen als langsames System. Die größten Ein-

22 8 Grundlagen Java Application APIs Java Virtual Machine Operating System Hardware Abbildung 2.2: Die drei Hauptelemente von Java bußen hat das System sicherlich dadurch, dass es interpretiert wird. Es gibt allerdings heute bereits Bestrebungen, JAVA als eigenes Betriebssystem anzubieten, wodurch die Ausführungsgeschwindigkeit beschleunigt wird [36]. Außerdem wird bereits Hardware entwickelt, die JAVA Bytecode direkt ausführen kann [2]. Langfristig wird also die Ausführungsgeschwindigkeit keinen Mangel mehr darstellen. Neben der Standard Edition (J2SE Java 2 Standard Edition) hat SUN für den E-Business Markt eine erweiterte Technologie entwickelt, die J2EE Java 2 Enterprise Edition mit der skalierbare verteilte Anwendungen möglich werden. Mit der starken Verbreitung von Kleinrechnern und intelligenten Mobiltelefonen, hat SUN weitere Spezifikationen von Virtual Machines entwickelt. Dabei entstanden kleinere Versionen wie Embedded Java, Personal Java und später J2ME sowie JavaCard. Alle kleineren Versionen verfügen über weniger Funktionalität, sind aber kompatibel zur Standard Edition (siehe Abbildung 2.3, Seite 9). Java Personal Edition und Java Embedded Edition sind Vorläufer der Java 2 Micro Edition [43]. Diese werden zukünftig vollständig von der J2ME ersetzt. JavaCard ist eine eigenständige Plattform, die parallel zur J2ME existiert. Ziel von JavaCard ist es Applikationen für SmartCards zu entwickeln wie Geldkarten, andere Chipkarten und ähnliche Kleinstgeräte. Die Verwendung ist aufgrund der zu eingeschränkten API in dieser Arbeit nicht vorgesehen und wird daher nicht weiter betrachtet. SUN führt mit J2ME sogenannte Konfigurationen und Profile ein. Es gibt zur Zeit zwei Spezifikationen für Konfigurationen: die Connected Limited Device Configuration (CLDC) und die Connected Device Configuration (CDC).

23 2.3 JAVA 9 J2SE EJAE PJAE J2ME JavaCard Java 2 Standard Edition Klassenbibliothek konfigurierte Klassenbibliothek Personal Java Klassenbibliothek Personal Profile Personal Basis Profile R MI Profile Foundation Profile CDC API Game Profile MIDP PDA Profile MIDP V2 CLDC API Java Card API JVM EmbeddedJAV A VM Personal JAVA VM CVM KVM JavaCard VM Betriebssystem Hardware Abbildung 2.3: Java Plattformen Die CDC wurde zum einen für stationäre Geräte wie Router, Set-Top-Boxen und Geräte aus der Unterhaltungselektronik entwickelt und zum anderen für mobile Geräte wie Auto-Navigationssysteme, Smartphones, Pocket PCs und PDAs der nächsten Generation, für die die CLDC zu eingeschränkt ist. Zielplattformen für die CLDC sind kleine, ressourcenbeschränkte Geräte, die über eine Netzanbindung verfügen (Mobiltelefone, etc). Bestimmte Einschränkungen, die die CDC als auch die CLDC aufweisen, können durch weitere Profile aufgehoben werden. Diese bauen teilweise aufeinander auf und bringen Funktionalität mit, die eher einen optionalen Charakter haben. Mit den zusätzlichen VM-Spezifikationen wird somit auf die verschiedenen Speicherplatzbedarfe eingegangen.

24 10 Grundlagen 2.4 Middleware Durch verschiedene Betriebssysteme, plattformabhängige Anwendungssysteme und inkompatible Netzwerke gibt es in vielen Bereichen Heterogenitätsund Verteilungsprobleme. Betriebssysteme bieten Funktionen an, die ein Anwendungsentwickler direkt nutzen kann. Dadurch verliert das Anwendungssystem seine Plattformunabhängigkeit. Dies kann man durch eine Entkopplung von Anwendung und Betriebssystem erreichen. Dazu erweitert man die Architektur um eine Schicht, die Middleware (Abbildung 2.4). A middleware service is a general purpose service that sits between applications and platforms, where a platform is a set of low level services and processing elements defined by a processor architecture and an OS s API [7]. Ein Middleware-System stellt höhere Dienste zur Verfügung als das darunterliegende Betriebssystem. Die Ziele sind einheitliche, plattformunabhängige Modelle und Abstraktionen zu finden, die ein vereinheitlichtes Programmierinterface bieten. Um eine höhere Austauschbarkeit zu gewährleisten, müssen low level Dienste so weit wie möglich gekapselt werden. Ziel eines Middleware- Systems ist es eine homogene Anwendungsentwicklungsebene über heterogene und verteilte Systemebenen hinweg zu schaffen. Application... Application APIs Middleware (distributed system services) Platform interface Platform - OS - Hardware... Platform interface Platform - OS - Hardware Abbildung 2.4: Middleware-Architektur Beispiele bekannter Middleware-Systeme sind unter anderem CORBA (siehe

25 2.5 Parameterübergabe-Semantiken 11 Abschnitt 3.2.3, Seite 19), COM/DCOM [9, 13] und Enterprise JAVA Beans [23]. 2.5 Parameterübergabe-Semantiken Bei einem Methoden-, Funktions oder Prozeduraufruf können üblicherweise Parameter übergeben werden. Parameter können dabei einfache Datentypen wie Integer oder Byte sein, Zeiger oder Referenzen auf Objekte oder gar Zeiger auf Funktionen. Die Übergabeparameter können in der aufgerufenen Methode verschieden behandelt werden. Dazu müssen entsprechende Semantiken definiert werden. Gängige Semantiken sind: Call By Value Call By Reference Call By Copy/Restore Call By Name Bei Call By Value arbeitet die aufgerufene Prozedur mit lokalen Kopien der Übergabeparameter, womit bei der Verarbeitung der Ursprungswert des Aufrufers nicht verändert werden kann. Im Fall Call By Reference wird statt des Wertes nur ein Zeiger auf den Speicherplatz übergeben. Da Aufrufer und aufgerufene Prozedur damit auf dem selben Speicherplatz arbeiten, wird der Wert des Aufrufers damit ebenfalls implizit verändert (entspricht CallByValue bei expliziter Zeigerübergabe). Call By Copy/Restore ist quasi eine Mischung aus Call By Value und Call By Reference. Die aufgerufene Prozedur arbeitet auf einer lokalen Kopie, die nach Beendigung wieder an den Speicherplatz der Aufrufervariablen kopiert wird. Dieses Verfahren ist für entfernte Aufrufe sinnvoll, wenn ein Call By Reference nachgebildet werden soll. Der wichtige Unterschied dabei ist, dass der entfernt veränderte Wert auf den Ursprungsspeicherplatz zurück kopiert wird und damit evtl. gleichzeitige Änderungen des lokalen Wertes überschrieben werden. In einem System mit nebenläufigen Prozessen (Multithreading) muss der Entwickler selbst auf die Verhinderung von Update-Anomalien (z.b. durch Synchronisation) bei Schreibvorgängen achten. Call By Name wurde mit Algol60 eingeführt und ersetzt alle formalen Parameter wie bei einer formalen Grammatik textuell (anhand des Namens).

26 12 Grundlagen 2.6 TupleSpaces Für einen verteilte Zugriff auf Daten, sozusagen einem verteilten Datenspeicher, wurden sogenannte TupleSpaces eingeführt. TupleSpaces zeichnen sich nicht durch eine bestimmte Implementierung aus sondern sind eher symptomatisch durch die Art des verteilten, transparenten Zugriffs definiert. Tuples definieren ein gemeinsames Datenmodell das Typsystem eingeschlossen für jegliche Applikationen und macht dadurch den Datenaustausch und die Datenspeicherung einfach. Tuples sind selbstbeschreibend, haben üblicherweise eine eindeutige ID als eine Art Primärschlüssel (z.b. GUID Global Unique Identifier), benannte Felder sowie optional getypte Felder und können geschachtelt werden. Die Operationen auf Tuple sind sehr einfach gehalten, um damit für zukünftige Anwendungen möglichst offen zu bleiben (siehe Abbildung 2.5). Operation Argument Erklärung put Tuple Schreibt einen Tuple read Query Liest ein Tupel listen Query Liest mehrere Tupel in der Reihenfolge, wie sie geschrieben worden sind. query Query Liest bestimmte Tupel aus dem Speicher delete ID Löscht ein Tupel vom Speicher Abbildung 2.5: TupleSpace Operationen Dadurch, dass TupleSpaces typischerweise auf Datenbanksystemen basieren, kann die transparente Verteilung z.b. durch Replikation angeboten werden.

27 Kapitel 3 Analyse Im Kapitel Analyse werden zunächst die Anforderungen an mögliche Basisdienste herausgearbeitet, wie sie aus der Motivation im Einleitungskapitel abgeleitet werden können. Danach wird auf verwandte Arbeiten eingegangen, die sich teilweise mit ähnlichen Aufgabenstellungen beschäftigen. 3.1 Anforderungen Aus der Motivation (siehe Abschnitt 1.2, Seite 2) können Anforderungen an notwendige Basisdienste abgeleitet werden. Anwendungen in spontan vernetzten Umgebungen werden üblicherweise hinsichtlich folgender Eigenschaften entwickelt: einmal hinsichtlich dynamischer Rekonfiguration, die durch spontan mögliche Kommunikation notwendig wird, dann bezüglich der Mobilität eines Benutzers und nicht zuletzt hinsichtlich der heterogenen Voraussetzungen und Eigenschaften der Zielgeräte bzw. der entfernt verfügbaren Dienste. Abstrakt gesehen handelt es sich um ein Netzwerk aus stationären sowie mobilen Knoten, die spontan interagieren und über äußerst heterogene Kommunikationsschnittstellen verfügen. Diese reichen von der einfachen verbundenen bis hin zur Funknetz Variante. Da sich spontane Interoperation nicht allein auf Netzwerkebene realisieren lässt sondern vielmehr von dieser entkoppelt sein sollte, wird in dieser Arbeit eher von spontaner Vernetzung als von AdHoc-Netzen gesprochen [22, 14]. Ziel dieser Arbeit ist es mit einer geeigneten Infrastruktur ein einheitliches Programmiermodell zu entwickeln und durch Entkopplung der notwendigen Kommunikation vom Netzwerk bzw. Protokoll flexible Unterstützung von

28 14 Analyse Transportprotokollen zu bieten. Neben diesen Eigenschaften soll die Infrastruktur möglichst klein und für zukünftige Erweiterungen offen gehalten werden, um damit für verschiedene Zielsysteme anpassbar zu sein Einheitliches Programmiermodell Ein einheitliches Programmiermodell bedeutet im Bereich des Ubiquitous Computing ein Programmiermodell für einheitlichen Zugriff auf dynamisch verfügbare Dienste und Geräteeigenschaften anzubieten. Aus der Sicht einer Anwendung sind Dienste nur temporär verfügbar. Wie bei entfernt verfügbaren Diensten können auch lokale Geräteeigenschaften dynamisch unverfügbar werden, wie z.b ein GPS-Sensor bei Betreten eines Gebäudes. Durch eine einheitliche Modellierung von Geräteeigenschaften als Dienst kann die Applikation Verfügbarkeit auf dieselbe Weise behandeln. Das Modell soll des weiteren eine Orts- wie auch Zugriffstransparenz bieten. Das bedeutet, dass dem Entwickler zunächst die Lokalität des Dienstes verborgen bleiben soll und er dadurch im entfernten wie im lokalen Fall auf dieselbe Art mit einem verfügbaren Dienst interagieren können muss. Ein einheitliches Programmiermodell senkt außerdem die Komplexität einer Software, die für Anwendungen im Ubiquitous Computing stark ansteigt und erhöht damit unter anderem die Qualität durch bessere Wartbarkeit. Weit wichtiger ist allerdings die daraus resultierende Portabilität von Anwendungen. Wird der Zugriff auf Dienste oder Ressourcen auf allen Systemen auf die selbe Weise angeboten, sind Applikationen unabhängig vom Gerät lauffähig Flexibilität des Transports Durch die Nutzung verschiedener, flexibel einsetzbarer Protokolle erhält man die Möglichkeit der Kommunikation mit verschiedenen Zielgeräten. Besonders sinnvoll ist eine Entkopplung von Dienstinteraktion und verwendetem Protokoll. Dadurch erhält man zusätzlich die Möglichkeit unterschiedlicher Protokolle und netzbasierter Kommunikationswege für ein- bzw. ausgehende Nachrichten. Bei Ausfall einer Kommunikationsschnittstelle, z.b. des Infrarots durch zu großen Abstand oder bei Blockierung durch Gegenstände und gleichzeitigem Vorhandensein einer anderen Kommunikationsmöglichkeit z.b. eine Funkverbindung während der Interaktion zweier entfernter Dienste, kann diese über den zweiten Weg trotzdem weitergeführt werden.

29 3.2 Verwandte Arbeiten und Technologien Konfigurierbarkeit Das Szenario (siehe Abschnitt 1.2, Seite 2) zeigt die Vielfältigkeit der Zielsysteme. Bei der Entwicklung einer Infrastruktur muss beachtet werden, dass diese neben einfachen Desktop PCs auch auf kleineren Geräten wie PDAs und mittelfristig auch auf Kleingeräten wie Sensoren lauffähig sein soll. Zielsysteme, wie einfache Sensoren, haben nur begrenzte Kapazitäten. Damit ein solches Zielgerät beispielsweise kein umfangreiches Interoperationsprotokoll anbieten muss wenn ein einfaches ereignisbasiertes Protokoll für Anwendungsbedürfnisse ausreichend wäre, müssen Konfigurationen möglich sein. Dazu muss das Laufzeitsystem betrachtet und geeignete Schnittstellen angeboten werden. 3.2 Verwandte Arbeiten und Technologien Eigenschaften wie Heterogenität oder dynamisch wechselnde Umgebungen sind Eigenschaften, die nicht erst im Umfeld des UbiComp in Erscheinung getreten sind. In Anlehnung an [6] lassen sich bestehende Middleware-Systeme wie folgt gliedern: Konventionelle Middleware-Systeme Mehrere Systeme wie CORBA [18], Java RMI [25] oder DCOM [13] wurden entwickelt, um wie in Abschnitt 2.4 beschrieben eine homogene Anwendungsentwicklungsebene über heterogene und verteilte Systemebenen hinweg zu schaffen. Diese Architekturen bieten dem Entwickler typischerweise viel Funktionalität an, was sie aufgrund ihrer Größe nicht für kleine Geräte nutzbar macht. Es kommt hinzu, dass herkömmliche Middleware-Systeme hauptsächlich hinsichtlich eines stabilen Netzwerkes entwickelt wurden. Daher wird bei diesen Systemen ein Verbindungsabbruch als unerwarteter Fehler gehandelt. Dynamisch rekonfigurierbare Middleware-Systeme Erweitert man herkömmliche Middleware-Systeme um die Möglichkeit dynamischer Rekonfiguration, können sich diese Systeme zur Laufzeit an verschiedene Umgebungen oder dynamisch wechselnde Anwendungseigenschaften anpassen [5, 8, 31, 32]. Diese Systeme unterstützen weiterhin keine unterschiedlichen Kommunikationsmodelle oder dynamisch wechselnde Protokolle für ein- bzw. ausgehende Nachrichten.

30 16 Analyse Eine Ausnahme bildet das Rover Toolkit [21], das diese Möglichkeit für sein Konzept des QRPC Queued RPC unterstützt. Rover verwendet allerdings ausschließlich QRPC als Kommunikationsmodell und wurde eher hinsichtlich eines Zugriffs auf nicht verbundene Infrastrukturen entwickelt als bezüglich spontaner Vernetzung. Ein weiterer Nachteil im Hinblick auf die Anforderungen ist, dass rekonfigurierbare Middleware-Systeme typischerweise über mächtige Rekonfigurationsschnittstellen verfügen und damit weniger auf kleine, leistungsschwache Geräte ausgerichtet sind. Eine erwähnenswerte Ausnahme hierzu stellt UIC [32] dar, auf das im nächsten Abschnitt eingegangen wird. Middleware-Systeme für Kleingeräte Durch die begrenzten Ressourcen eines mobilen Kleingeräts ist die Nutzung voll ausgestatteter Middleware- Systeme nicht möglich. Eine Lösung dafür wäre eine verringerte Anzahl an Funktionalität anzubieten, was zu veränderten Programmiermodellen oder einer geringeren Zahl angebotener Interoperabilitätsprotokolle führt [27, 34, 37]. Ein anderer Lösungsansatz wäre die Modularisierung der Systeme, so dass nicht benötigte Funktionalität durch das System zur Laufzeit entfernt werden kann. Ein Beispiel hierfür ist das UIC Universally Interoperable Core System. UIC basiert auf einem Mikrokern-Ansatz, der dynamisch erweitert werden kann, um mit anderen Middleware-Systemen interagieren zu können. Bei UIC muss man sich bereits zu Beginn einer Interaktion für ein Kommunikationsprotokoll entscheiden, das nicht zwischen Anfrage und Antwort gewechselt werden kann. Middleware-Systeme für Ubiquitous Computing Die meisten Middleware-Systeme für UbiComp sind entwickelt worden, um Informationssysteme in physische Alltagsumgebungen zu integrieren. Solche Umgebungen sind z.b. Räume oder Gebäude (IE Intelligent Environment) [1, 11, 26, 39, 35]. Benutzer erhalten durch ihre mobilen Geräte beim Betreten spontan Zugriff auf die Informationssysteme. Spontane Interaktion zweier Geräte wie im Szenario in Abschnitt 1.2 angesprochen, ist bei diesen Systemen nicht vorgesehen. Im Hinblick auf das Ziel dieser Arbeit eine Infrastruktur für spontan vernetzte Anwendungen zu bieten wie es aus den Anforderungen hervorgeht (siehe Abschnitt 3.1, Seite 13), werden als grundlegende Konzepte die Architekturen

31 3.2 Verwandte Arbeiten und Technologien 17 RMI für die Möglichkeit entfernter Methodenaufrufe, JINI als Beispiel für dynamische Diensterkennung (Discovery) und CORBA für verteilte, transparente Dienstnutzung exemplarisch vorgestellt. Als Beispiel für IE-Systeme werden GAIA und AURA erläutert. Aufgrund seines rein ereignisbasierten Interaktionskonzepts wird zudem das System one.world dargestellt. Abschließend wird Puppeteer als ein interessantes Adaptions-Konzept vorgestellt, das zukünftig in der geforderten Infrastruktur ähnlich zum Einsatz kommen könnte RMI RMI ist eine Technologie, die im Zusammenhang mit Java von SUN Microsystems entwickelt worden ist [25]. Ähnlich einem RPC (siehe Abschnitt 2.2, Seite 6) bietet RMI die Möglichkeit Methoden von entfernten Objekten lokal verfügbar zu machen. RMI verwendet dafür Stellvertreter-Objekte oder Stubs, die vom Aufrufer genutzt werden können. Dazu muss der Aufrufer einen Registrier-Dienst auf dem Zielgerät nach dem gewünschten Dienst befragen. Als Rückgabe erhält der Aufrufer ein Stub-Objekt, das die gewünschten Methoden implementiert und an den Zieldienst gebunden ist. Bei Aufruf wird eine Nachricht mit Meta-Informationen generiert und via TCP-Sockets an den Empfänger gesendet wobei der Aufrufer blockiert wird. Das Zielgerät sorgt für die korrekte Zustellung des Aufrufs und sendet nach Abarbeitung der Methode die Rückgabewerte zurück an den lokalen Stub. Dieser dekodiert die Daten und macht sie dem Aufrufer verfügbar. Eine Besonderheit an RMI ist die Möglichkeit des dynamischen Transfers von Klasseninformationen, der durch Fernzugriff auf einen Webserver bzw. durch Zugriff auf ein lokales Dateisystem möglich gemacht wird (RMI codebase). Die Stub-Objekte von RMI sind durch TCP-Verbindungen mit dem Zieldienst verbunden. Dadurch ist es nicht möglich das Netzwerk zwischenzeitlich zu trennen. Um einen Dienst nutzen zu können muss die Netzadresse der genutzten Registry bekannt sein. Weder kontinuierliche Verbindungen noch zentralisierte Dienste sollen laut Anforderungen in UbiComp-Umgebungen verwendet werden. Reines RMI ist daher nicht für Anwendungen in diesem Bereich ausreichend. Es kann allerdings als zu Grunde liegendes Kommunikationssystem für eine geeignete UbiComp-Middleware dienen. Ein solcher Ansatz wird in der entwickelten Infrastruktur aus Kapitel 5 als Evaluation verwendet (siehe Abschnitt 7, Seite 65).

32 18 Analyse JINI JINI [44] ist eine von SUN entwickelte Technologie für verteilte Dienste, die auf JAVA basiert. Ziel war es eine Möglichkeit zu schaffen Geräte oder Dienste verschiedenster Art in einem Netzwerk verfügbar zu machen. Man wollte erreichen, dass z.b. ein Drucker, wie ein Telefon nachdem es angeschlossen wurde, sofort nutzbar wird. Dazu bietet jedes Gerät, das in einem Netzwerk einen Dienst zur Verfügung stellen möchte, einen Dienststellvertreter (Proxy) an und meldet diesen bei einem Lookup-Service an. Dieser Lookup-Service wird von einem entsprechenden Client verwendet, um an die Dienstinformation zu gelangen z.b. über die angebotene Suche über Diensttypen (Yellow-Pages). Anders als bei RMI (siehe Abschnitt 3.2.1, Seite 17) muss die Netzadresse des Lookup-Service nicht a priori bekannt sein. Dazu bietet Jini ein Discovery- Protokoll. Über eine Multicast-Anfrage wird der Lookup-Service gesucht (Multicast Request Protocol). Damit können transparent mehrere Lookup-Service redundant angeboten werden. Kann kein Multicast verwendet werden, bietet Jini wie RMI die Möglichkeit eines Unicasts auf eine bekannte Adresse an (Unicast Request Protocol). Außerdem definiert Jini ein drittes Protokoll, das Multicast Announcement Protocol, mit dem ein Lookup-Service nach einem Neustart (z.b. durch Serverausfall) potentiellen Clients seine (erneute) Erreichbarkeit mitteilen kann. Dies ist sinnvoll damit Serviceanbieter nicht andauernd ein neues und dadurch ineffizientes Discovery starten müssen, um die Aktualität zu bewahren. Service Service Service Service Lookup Discovery / Join RMI JAVA JAVA JAVA OS 1 OS 2 OS 3 Abbildung 3.1: JINI Architektur JINI ist keine wirklich neue Technologie sondern eher eine Standardisie-

33 3.2 Verwandte Arbeiten und Technologien 19 rung vorhandener Technologien und Implementierung zusätzlicher Dienste (Abbildung 3.1). Im Prinzip wird RMI als Technologie verwendet und über entsprechende Definitionen werden wiederkehrende Aufgabenstellungen (wie Lookup und Discovery) gelöst. JINI zielt besonders auf den PlugAndPlay Gedanken ab, wobei externe Geräte die primäre Zielgruppe sind. Geräte sind in einem Netzwerkverbund verfügbar, das zwar ad hoc zusammengeführt wird, die Dauer des Verbundes fluktuiert aber deutlich weniger als im Ubiquitous Computing. Proxies bringen üblicherweise einen kompletten Protokollstapel mit was den Dienstnutzer nach dem Lookup an ein Protokoll bindet. Laut den Anforderungen in Abschnitt 3.1 sind dagegen mehrere Kommunikationsschnittstellen pro Gerät denkbar, die bei Ausfall dynamisch reselektiert werden sollen. Der Lookup-Service stellt einen Single Point of Failure dar. Sicherlich kann man Abhilfe schaffen indem man entsprechend viel Redundanzen einbaut. Dabei müssen einige Konsistenz-Probleme gelöst werden. Dies bietet JINI selbst nicht an und muss im Einzelfall selber entwickelt werden CORBA 1989 spezifizierte die Object Management Group [18] eine Verteilungsinfrastruktur oder Middleware (siehe Abschnitt 2.4, Seite 10) und gab ihr den Namen CORBA. CORBA steht für Common Object Request Broker Architecture. Bei CORBA handelt es sich nicht um ein Produkt oder eine Implementierung sondern tatsächlich nur um eine Spezifikation. CORBA ermöglicht ein verteiltes Dienstmodell für heterogene Zielsysteme. Kernstück der Architektur ist der ORB Object Request Broker, der als Vermittler zwischen den Diensten fungiert. Durch diese Entkopplung vom Betriebssystem und durch eine weitere Entkopplung zwischen ORB und Dienst durch sogenannte Objektadapter können die Objekte in verschiedenen Sprachen implementiert sein, auf verschiedenen Betriebssystemen laufen und auf unterschiedlicher Hardware angeboten werden. Mittels CORBA können nun eine Menge von interagierenden Objekten, die in beliebigen Sprachen implementiert sein können, ohne Kenntnis des Ortes benutzt werden. Der ORB ist dafür zuständig die Implementierung zu finden und die Kommunikation entsprechend durchzuführen. Der Aufrufer kennt dabei nur eine symbolische Objekt-Referenz, die in einem ORB eindeutig ist.

34 20 Analyse Durch den offenen Standard ist CORBA herstellerunabhängig und in heterogenen Umgebungen lauffähig. Die angebotenen Dienste innerhalb des Systems sind jeweils in einer IDL Interface Definition Language festgelegt. Zu allen gängigen Programmiersprachen gibt es entsprechende Abbildungen (Java, C, C++, Smalltalk, Ada, etc.). Großer Vorteil der Architektur ist, dass man sprachunabhängig Objekte aufrufen kann. Durch die Definition eines Interoperabilitätsprotokolls, dem IIOP Internet Inter ORB Protokoll, wird die Kommunikation zwischen verschiedensten Systemen ermöglicht. CORBA ist nicht protokollunabhängig sondern verwendet IIOP oder wahlweise auch GIOP General InterOrb Protocol, eine andere Protokolldefinition. CORBA behandelt einen Ausfall des Netzwerks als unerwarteten Fehler. Aus diesen Gründen ist die Architektur für protokollunabhängige, spontane Vernetzung, wie im UbiComp gefordert, nicht geeignet Gaia Gaia wurde an der University of Illinois at Urbana-Champaign am Institute of Computer Science entwickelt. Gaia ermöglicht eine transparente Integration rechnergestützter Infrastrukturen in gewohnte Alltagsumgebungen z.b. in größere Plätze oder Räume. Diese werden ActiveSpaces[35, 33, 30] genannt. ActiveSpaces bieten Dienste, die ein Benutzer direkt über stationäre oder indirekt über mitgeführte Geräte, die sich mit dem ActiveSpace verbinden, nutzen kann. Active Spaces Execution Environment Gaia Application Model Gaia Services GaiaOS Gaia Kernel Unified Object Bus Abbildung 3.2: Gaia Architektur Gaia basiert auf GaiaOS, einem Middleware-System, das auf bestehenden Plattformen lauffähig ist (z.b. Windows2000, WindowsCE, Solaris). Gaia besteht aus einem Kommunikationsträger, einem Kern, zusätzlichen Diensten

35 3.2 Verwandte Arbeiten und Technologien 21 und einem Applikationsmodell. Die Teile unter dem Applikationsmodell (siehe Abbildung 3.2, Seite 20) werden GaiaOS genannt. Der Unified Object Bus ist für eine Homogenisierung heterogener Komponenten zu Unified Components verantwortlich. Das wird durch sogenannte Component Manager ermöglicht, die für den Export der von der Komponente angebotenen Schnittstelle zuständig sind. D.h. es muss für jedes Komponentenmodell einen spezifischen Component Manager geben. Der Gaia-Kern bietet als Mittelpunkt von Gaia Dienste wie Naming, Discovery, Security etc. an. Externe Dienste werden über den Discovery-Service bekannt gemacht. Jede Komponente, die einen Dienst bietet, sendet eigenständig periodisch Signale über seine Existenz (Heartbeats). Gespeichert werden diese Informationen im Space Repository. Dazu hört das Space Repository auf den Discovery-Service, um an die Informationen zu gelangen. Gaia ist ein Projekt für ActiveSpaces also für intelligente Plätze mit wechselnden Benutzern. Ziel ist es eher eine Rechner-Infrastruktur in vorhandene Umgebungen einzugliedern und für Benutzer im Umfeld verfügbar zu machen als beide Seiten (Anbieter und Nutzer) direkt untereinander interagieren zu lassen. Die gegenseitige Nutzung von Diensten zweier Kleingeräte funktioniert nur innerhalb eines ActiveSpace also bei Verfügbarkeit der zusätzlichen Infrastruktur. Davon kann laut den Anforderungen aus Abschnitt 3.1 nicht ausgegangen werden AURA AURA ist ein Forschungsprojekt der Carnegie Mellon University in Pittsburgh [39]. Ausgangspunkt der Forschung ist die Annahme, dass die wichtigste Ressource eines Computersystems nicht mehr ein Prozessor, Hauptspeicher oder Netzwerk ist, sondern die Aufmerksamkeit eines Benutzers. Ziel des Projekts ist es jeden Benutzer mit einer unsichtbaren Umgebung aus Rechenund Informationsdiensten zu versehen, die unabhängig des Standortes gleich bleiben. Folgendes Zielszenario soll dies verdeutlichen: Ein Benutzer arbeitet zu Hause an Daten bezüglich einer Präsentation. Dazu hat er sich zusätzliche Informationen aus dem Internet geladen, die nun lokal verfügbar sind. Nachdem er das Haus verlässt, werden diese Daten inklusive des aktuellen Status an einen zentralen globalen Datenspeicher gesendet. Beim Betreten seines Büros wird der Benutzer von einem Umgebungsdienst erkannt und seine Daten werden von dem globalen Datenspeicher angefordert.

36 22 Analyse Danach wird der letzte Status wiederhergestellt und an die neuen Gegebenheiten angepasst. Eine solche neue Gegebenheit ist z.b. eine größere Leinwand, über die der Benutzer jetzt die Video-Informationen ansehen kann und evtl. Multimediaanlagen, mit deren Hilfe Audio-Informationen hörbar gemacht werden. AURA arbeitet nicht mit Applikationen sondern definiert aus der Sicht des Benutzers User Tasks [45]. Solche Tasks sind z.b. das Schreiben einer wissenschaftlichen Ausarbeitung. Ein solcher Task würde neben einem vorhandenen Texteditor gleich die richtige Vorlage und etwaige Informationen über das Thema bereitstellen oder zumindest Zugriff auf übliche Nachschlagewerke zur Verfügung stellen. Ausgangspunkt von Aura ist eine Sicht in der alle einzelnen Infrastrukturen global vernetzt sind. Das ist notwendige Voraussetzung, um Benutzerinformationen global migrieren zu können. Spontane Vernetzung, wie bei den Anforderungen in 3.1 beschrieben, stellt hier keine Aufgabenstellung dar one.world one.world ist eine Infrastruktur, die an der University Of Washington am Department of Computer Science Engineering entwickelt worden ist (siehe [16, 17, 46]). Motivation von one.world ist es eine Infrastruktur zu schaffen, in der Dienste in einem spontanen Netzwerk verteilt nutzbar gemacht werden können. Mobile Systeme zeichnen sich durch plötzliche, unvorhergesehene Änderungen aus, die durch Bewegung des Benutzers ausgelöst werden. Daher ist eine grundlegende Annahme in one.world, dass Ereignisse eine Kommunikationsform darstellen, die sich am besten in ein UbiComp Umfeld eingliedern lässt. Daher sind in one.world Ereignisse, neben der reinen Benachrichtigungsfunktion, Grundlage jeder Kommunikation. Synchrone Methodenaufrufe müssen damit über Request/Response-Events nachgebildet werden. Diese Ereignisnachrichten müssen von einem Entwickler selbst erstellt werden. Dienste können dadurch nicht wie eine einfache Methode synchron gerufen werden. Dadurch wird das Aufruf-Paradigma bei Dienstnutzung von einem synchronen Methodenaufruf zu einem nachrichtenbasierten Aufruf geändert. Das System bietet keine Zugriffstransparenz für die Dienstnutzung an. Entfernte Ereignis-Nachrichten haben einen anderen Typ als lokale. Für die Antwortreferenz kann nicht mehr eine direkte Referenz auf den Absender angegeben werden, sondern ein spezielles Stellvertreter-Objekt. Dies liegt alles in

37 3.2 Verwandte Arbeiten und Technologien 23 der Verantwortung des Entwicklers. Das wird unter anderem damit begründet, dass Zugriffstransparenz üblicherweise mit Hilfe programmiersprachlicher Interfaces erreicht wird, die mit dem Dienst eng verbunden sind, wodurch Erweiterbarkeit erschwert wird. Auch die Behandlung dynamischer Unverfügbarkeit von Diensten liegt in der Verantwortung des Entwicklers (Programming for Change). Anders als in herkömmlichen Systemen werden in one.world Daten und Funktionalitäten voneinander getrennt. Dies wird damit begründet, dass die Handhabung der Daten dadurch vereinfacht wird. Zukünftige Anwendungssysteme können dadurch Suchen oder Filterungen vornehmen, die bei einer vergleichbaren Datenkapselung durch Objekte nur durch Erweiterung der Objekt- Schnittstellen realisiert werden könnten. Die Idee dafür stammt aus dem Bereich der Datenbanksysteme, die durch ihre allgemeine Schnittstelle (SQL) zukünftigen Anwendungssystemen Zugriff auf Sichten der Daten anbieten, die heute noch nicht bekannt sein können. Für die Verwaltung der Daten verwendet one.world TupleSpaces (siehe Abschnitt 2.6, Seite 12). Die Dienstsuche (Discovery) wird über einen zentralen Dienst angeboten. Spontane Vernetzung und Interaktion zwischen zwei Geräten ohne Zugriff auf diesen Dienst wird damit unmöglich. one.world erfüllt viele Anforderungen, die im Ubiquitous Computing von Nutzen sind. Dennoch verliert die Art der Implementierung trotz Nutzung von Java ihre Plattformunabhängigkeit dadurch, dass für die Generierung der verwendeten GUIDs Global Unique Identifiers eine native Bibliothek verwendet wird und nicht zuletzt deswegen, da das verwendete Datenbanksystem selber nicht plattformunabhängig ist. Die Service-Discovery stellt einen Single Point Of Failure dar, was in einer Umgebung stark fluktuierender Netz- und Dienstverfügbarkeiten nicht von Vorteil ist. Dem Programmierer werden viel Arbeiten aufgebürdet. Neben der Verfügbarkeitsfrage eines Dienstes muss der Programmierer jeden Aufruf (Event) selber generieren, was zusätzlichen Aufwand bedeutet und das übliche Programmierparadigma (Methodenaufruf) verletzt. Ein einheitliches Programmiermodell, wie in den Anforderungen gewünscht, wird nicht angeboten.

38 24 Analyse Puppeteer Ziel von Puppeteer ist es, Adaption in mobilen Umgebungen für (vorhandene) komponentenbasierte Applikationen anbieten zu können [12]. Dabei verwendet das System die exportierten Schnittstellen der Applikationen, um die Adaption ohne Veränderung der Applikation durchführen zu können. In [12] wird erläutert, wie als Beispiel Microsofts PowerPoint, eine Software für Bildschirmpräsentationen, mit Hilfe von Puppeteer einer Adaption unterworfen wird. Dazu wird ausgenutzt, dass PowerPoint selber komponentenbasiert aufgebaut ist. PowerPoint basiert auf COM [9], einem Komponentenmodell von Microsoft. Client Proxy Server Proxy Export Driver Tracking Driver Policies KERNEL Decoder Import Driver KERNEL Coder Abbildung 3.3: Architektur von Puppeteer Abbildung 3.3 zeigt schematisch die Architektur von Puppeteer. Das System besteht aus vier Moduln: Kernel, Driver (Export und Import Driver), Transcoder (Coder und Decoder) und Policy. Prinzipiell wird nun beim Start einer Applikation der Server über den Kernel nach Daten befragt. Dazu werden entsprechende Stub-Klassen übermittelt, die über applikationsspezifische Policies Daten vom Server nachladen. Bei der PowerPoint-Adaption wird z.b. initial die erste Folie komplett und zusätzlich die Anzahl der Folien geladen. Je nach Benutzerinteraktion und Policy können dann weitere Daten vom Server nachgeladen werden. In welcher Form Daten komprimiert und übertragen werden liegt im Verantwortungsbereich des Trancoders. Die Daten werden über entsprechende Importtreiber verfügbar gemacht. Damit der Benutzer in der Lage ist Dokumente zu bearbeiten, werden auch entsprechende Exporttreiber angeboten. Diese Treiber sind notwendig, um die applikationseigenen Datenformate unterstützen zu können. PowerPoint basiert auf Object Linking and Embedding und legt dementspre-