|
Dieses Kapitel motiviert ausgehend von den Anforderungen an das Heywow-System ein mögliches Konzept für das Gesamtsystem. In Abschnitt 3.1 werden die nötigen Hardwarevoraussetzungen für das in Abschnitt 3.2 folgende Software-Modell vorgestellt. Hier werden die wesentlichen Entwurfsentscheidungen für die Software-Architektur genauer begründet.
Abschließend geht Abschnitt 3.3 nur kurz auf die Schwierigkeiten bei Sicherheit und Stabilität des Heywow-Systems ein.
Im Heywow-System wird die Struktur der Hardwarekomponenten durch den möglichen Zugriff auf zentrale Dienste und die spontane Integration in ein lokales Funknetzwerk für die Kommunikation mit den lokalen, dezentralen Diensteanbietern, bestimmt. Diese Bedingungen ergeben einige konkrete Anforderungen an das System:
Für den Einsatz von zentral verfügbaren Dienstleistungen muss zwischen dem Handcomputer (WID) und einem zentralen Server (Heywow.com) eine Verbindung über Mobilfunk aufgebaut werden können.
Außerdem kann sich der Handcomputer per Funk in ein bestehendes lokales Festnetz integrieren. Dort stellen die Dienstgeber der lokalen Diensteanbieter ihre Jini-Dienste über strategisch verteilte Sendebaken (Beacons) bereit. Der Dienstgeber registriert bei einer allgemeinen Sendebake von Heywow einen Stellverteter für den Zugriff auf seinen Dienst.
Die Stellvertreter erbringen die Dienstleistung in Kommunikation mit dem eigenen Dienstgeber.
Dieses Konzept stellt an die Hardware in Heywow bestimmte Anforderungen. Der tragbare Handcomputer ist durch seine beschränkten Ressourcen bestimmt, er muss die eingeschränkten Speicher- und Stromressourcen verwalten. Für die Kommunikation mit dem Restsystem muss der WID sein Funkmodul energiesparend betreiben.
Für die im Festnetz integrierten Komponenten gelten diese Einschränkungen nicht. Die lokalen Dienste sind auf Dienstgebern mit Zugriff auf das Fest- und Funknetz implementiert. Sie besitzen eine direkte Verbindung zu den Sendebaken, die für alle Dienste einen Nachschlagedienst realisieren.
Die Teile der Software von Heywow richten sich nach der Struktur der Hardwarekomponenten. In den folgenden Unterkapiteln wird eine Klassenbibliothek für die Implementierung von lokalen Diensten mit unterstützenden Klassen für deren Verwendung entworfen.
Eine Anwendung auf dem mobilen Handcomputer kann nur durch die Kommunikation mit lokalen und zentralen Diensten für den Benutzer eine Leistung erbringen. Der Zugriff für den Benutzer muss transparent und möglichst einfach gestaltet werden. Außerdem muss für die breite Einsetzbarkeit die große Vielfalt von mobilen Handcomputern unterstützt werden:
Teil der weiteren Ausführungen ist jetzt besonders die Implementierung und der Einsatz von Diensten im lokalen Netzwerk. Beim Zugriff auf lokal verfügbare Ressourcen und Dienste muss WID-intern ein Jini-Stellvertreter-Objekt des verfügbaren Dienstes die Kommunikation mit dem Dienstgeber regeln.
Allgemeine Anforderungen ergeben sich wieder aus einem Benutzerszenario. Ein mobiler Handcomputer kann sich über das Funk-LAN in das bestehende Heywow-Netz einbinden. Er muss Zugriff auf alle Dienste in seinem Aktionsradius bekommen und diese kontrolliert einsetzen können:
Der Dienst kann auf einem im Netzwerk integrierten Dienstgeber des Anbieters oder auf einem zentralen Prozessor arbeiten.
Die Leistung des Dienstes erbringt der über einen Nachschlagedienst auf den WID bezogene Stellvertreter, evtl. in Zusammenarbeit mit der Dienstkomponente auf dem Dienstgeber. Durch die Kommunikation zwischen dem Stellvertreter auf dem WID und dem Dienstgeber kann der Benutzer mit dem Diensteanbieter interagieren. So sind komplexe Dienste mit Vertragsverhandlungen und Abstimmung der Beteiligten möglich.
über die Funktionalität des Dienstes selbst hinaus, ist eine Klasse auf dem Dienstgeber auch nötig, für die ordentliche Integration in das Jini-Netzwerk von Heywow. Jeder Dienst muss seinen Benutzern Zeitzusicherungen (vgl. Abschnitt 2.2.4) über die Verfügbarkeit seiner Dienstleistung geben können. Eine solche Funktionsgarantie wird durch Verwendung des Lease-Prinzips aus Jini ermöglicht.
Der Dienstgeber-Teil eines Heywow-Dienstes ist für die Zeitzusicherungen zuständig. Diese Aufgabe wird durch eine zusätzliche Klasse erfüllt, die von allen Diensten instanziiert werden kann und für die Verwaltung eingesetzt wird.
Durch das Auslagern der Verwalter-Funktionalität in eine zusätzliche Klasse kann, wie in Jini üblich, eine beliebige Kombination von Zusicherung und Verwaltung (vgl. Vorschlag Landlord-Leasing in Abschnitt 2.2.4) eingesetzt werden.
Mit dem Auslagern kann für die Verwalter-Aufgaben auch ein spezieller Dienst im Heywow-System eingeführt werden. Jeder registrierte Dienst kann die Anforderungen nach Zeitzusicherungen an einen Verwalter weitergeben und diesem die Kommunikation mit der speziellen Zeitzusicherung übertragen.
Falls der Stellverteter die gesamte Funktionalität des Dienstes beinhaltet, und keine Verbindung zu einem Dienstgeber nötig ist, kann die Vergabe von Zeitzusicherungen und deren Verwaltung auch umgangen werden. Nach einmaligem Bezug des Stellvertreters ist dieser bis auf weiteres gültig und es muss auch nicht für die Zeitzusicherung des Dienstes eine Verbindung zum Dienstgeber aufgebaut werden.
Schwierig bei einem 'immer' gültigen Dienst ist in diesem Fall aber der Austausch einer veralteten Programm-Version. Wenn ein Stellvertreter bereits über einen Nachschlagedienst im Heywow-System bezogen worden ist, wird er WID-intern zwischengespeichert. Der Dienst erfüllt auf dem tragbaren Handgerät seinen Dienst und es besteht keine Notwendigkeit für den Bezug einer aktuelleren Version. Dieses Caching-Problem kann nur durch die Einführung einer Protokollerweiterung von Jini für Heywow behoben werden. Beim Einsatz eines Stellvertreter-Objekts auf dem Handcomputer kann durch einen Kontrollzugriff auf das Versionsattribut des Dienstes über die Aktualität der gespeicherten Version entschieden und evtl. ein neues Stellvertreter-Objekt bezogen werden.
Um die aufwendigen Kontrollen zu umgehen, ist es nützlich, das Prinzip der Zeitzusicherungen aus Jini für die implementierten Dienste zu unterstützen. Ein Dienst sichert für eine festgelegte Zeit die Gültigkeit seines Stellvertreters zu. Erst bei einer späteren Benutzung muss der Klient diese Zusicherung verlängern. Falls dies nicht möglich ist, muss evtl. ein Abgleich mit der aktuellen Version auf dem Dienstgeber vorgenommen werden.
Ein großer Nachteil des bisher vorgestellten Dienstgebers ist, dass er fortwährend einen ganzen Betriebssystemprozess, einschließlich Speicher und sonstigen Ressourcen benötigt. Nach dem Start wird der Prozess für die Verwaltung der Leases und die eigene dauerhafte Registrierung im Jini-Netzwerk benötigt.
Durch Registrierung des Dienstes im Aktivierungssystem (vgl. Abschnitt 2.1.3) können auf diese Weise auch auf dem Dienstgeber Systemressourcen eingespart werden.
Bei der Implementierung konkreter, lokaler Dienste ergibt sich noch eine weitere wesentliche Anforderung:
Mit Verwendung unterstützender Basismethoden kann durch Klassenvererbung die bestehende Struktur für konkrete Dienste einfach angepasst und ergänzt werden.
Um den Einsatz der über Funk in den lokalen Nachschlagediensten erhältlichen Stellvertreter-Objekten durch die Anwendungen auf dem Handcomputer zu erleichtern, kann auf dem mobilen Handgerät ein WID-interner, erkundender Nachschlagedienst als Zwischenspeicher eingerichtet werden. Jeder WID-interne Nachschlagedienst enthält eine Sammlung der für den Benutzer interessanten, lokal erreichbaren Dienste. Durch diese Form des Zwischenspeichers ist es möglich die aus Jini bekannten Programmierkonzepte für Applikationen auf dem Handcomputer einzusetzen.
Auch bei einer nicht dauerhaft mit voller Bandbreite verfügbaren Funkverbindung zu den lokalen Sendebaken können die Anwendungen auf dem WID ohne Beinträchtigung ihre Dienstleistung anbieten. Bei der Kommunikation mit dem Benutzer fallen kleinere Sendestörungen so nicht mehr ins Gewicht.
Die Implementierung von WID-internen Nachschlagediensten auf den mobilen Handcomputer ermöglicht die Verwendung des Jini-Programmierparadigmas (vgl. Abschnitt 2.2). Ein solch mobiles Endgerät stellt einen Kompromiss dar, zwischen einem völlig autonom arbeitenden Handcomputer, mit allen Diensten für den Benutzer, und einem Gerät mit ständiger Kommunikation zu einem zentralen Dienstgeber, mit den dort gespeicherten Informationen über den Benutzer. Ein Nachschlagedienst auf dem WID speichert die Objekte aus den über Funk lokal erreichbaren Nachschlagediensten des Heywow-Systems und bietet den Benutzer-Anwendungen auf dem WID diese Stellvertreter an.
Neben der Kopie des Stellvertreter-Objekts für den lokalen Gebrauch speichert der WID-interne Nachschlagedienst auch Zeitzusicherungen, mit denen die Verfügbarkeit des Dienstes garantiert wird. Bei Auslauf dieser Garantie wird, wenn die Zusicherung nicht erneuert werden kann, der Stellvertreter aus der lokalen Datenbank gelöscht.
Der mobile Handcomputer arbeitet batteriebetrieben, deshalb muss ein Dienst mit seinem Stellvertreter-Objekt auf dem Handcomputer den Energieverbrauch dort gering halten:
Eine Möglichkeit, die Funkleistungsanforderungen auf dem mobilen Endgerät zu verringern, ist die Verwendung von Multicast oder Broadcast Techniken [HS1997]. Wie in Abschnitt 2.3 beschrieben, verbraucht besonders das Funk-Modul des Handcomputers viel Energie. Grundsätzlich ist aber das Empfangen von Daten für das Handgerät stromsparender als der Sendebetrieb.
Ein Simulationsexperiment in [SEa1996] belegt, dass das Empfangen von Datenpaketen nur unwesentlich mehr Energie verbraucht als der Verbrauch des Empfangsgeräts im Leerlauf. Wenn das mobile Gerät Daten in das Netz senden muss, kostet dies mehr Energie. Besonders signifikant wird dieser Unterschied wenn eine größere Datenmenge gesendet wird, was bei jedem Heywow-Dienst möglichst vermieden werden muss.
Zur Erstellung der WID-internen Datenbasis von erreichbaren Diensten kann deshalb auch das energiesparendere Belauschen einer Multicast-Gruppe eingesetzt werden. Die Topologie der Netzzellen in Heywow ermöglicht es, einfache Dienste mit stark lokalem Bezug, durch das in UDP implementierte Abhören einer Multicast-Gruppe an die Klienten zu verteilen.
Bei Multicast-Kommunikation kann keine Garantie für den Empfang aller Datenpakete gegeben werden. Der Verlust wesentlicher Dateninformationen muss anderweitig abgefangen werden. Anders als bei verbindungsorientierten TCP-Unicastverbindungen gibt es bei Multicast über UDP keine Rückmeldung an den Sender. Die zusätzliche Einführung eines Rückkanals würde zwar eine Fehlerkorrektur bei verlorenen Datenpaketen erlauben, dies würde aber einen unvertretbaren Energie-Mehraufwand bedeuten. Günstiger bleibt auch hier der stark redundante Versand der Datenpakete. So kann eine praktisch zuverlässige Kommunikation implementiert werden [Riz1997].
Nach Erhalt aller Datenpakete eines Stellvertreter-Objekts kann auf dem Handcomputer das entsprechende Objekt den WID-internen Anwendungen zur Verfügung gestellt werden. Für die Integration der neue Bezugsstrategie in das Jini-System ist es hier möglich, eine Verbindung mit dem entsprechenden Dienstgeber aufzubauen und eine evtl. notwendige Zeitzusicherung für den Dienst anzufordern.
Für den problemlosen Einsatz eines Jini-Netzwerks beim Zugriff auf lokale Dienste erfordert der tragbare Handcomputer eine andauernde Integration in das lokale Festnetzwerk über Funk:
Um den mobilen Endgeräten im Einzugsbereich den Bezug von Dienst-Stellvertretern über Multicast zu ermöglichen, müssen auf den einzelnen Sendebaken die lokalen Nachschlagedienste durchforstet werden und der Inhalt unter einer Multicast-Gruppe ins Netz gesendet werden. Dieses zusätzliche Multicast-Protokoll erlaubt nicht nur den Versand kompletter Stellvertreter-Objekte1, es ist auch möglich auf der Sendebake nur die Schnittstelle oder eine Beschreibung der vorhandenen Objekte zu versenden. So lässt sich die zweite Bezugsstrategie in den Einsatz des Jini-Systems integrieren. Die Anwendung auf dem Handcomputer erhält die Möglichkeit, nur bei Bedarf das vollständige Stellvertreter-Objekt des Dienstes unter der mitgesendeten Adresse anzufordern.
Beim Einsatz persönlicher, digitaler Assistenten und Handcomputer mit privaten Daten müssen an das System von Heywow besondere Anforderungen von Sicherheit und Vertraulichkeit gestellt werden.
Heywow, als Mittler zwischen lokalen Dienstleistern und Benutzern der Infrastruktur von Heywow, muss seinen Kunden Garantien über die Sicherheit der im System angebotenen Dienste und die Stabilität der Software auf dem privaten Handcomputer garantieren:
Heywow setzt ein Vertrauensverhältniss zwischen dem Dienstevermittler Heywow auf der einen Seite und den Benutzern und den Diensteanbietern auf der anderen Seite voraus. Jeder Klient muss in die Sicherheit und Funktionstüchtigkeit der registrierten Stellvertreter bei Heywow vertrauen und zwischen Heywow und den lokalen oder globalen Diensteanbietern muss ein Vertrauensverhältnis über die angebotenen Dienste bestehen.
Angriffe in das System von Heywow beruhen deshalb meist auf einer Störung oder einem Unterlaufen der bestehenden Vertrauensverhältnisse.
Die Abbildung 3.2 zeigt die direkten Beziehungen der Teilnehmer.Einige Angriffsmöglichkeiten:
1) verpackt in evtl. mehrere UDP-Datenpakete
----------------------------------------------------------------
[home] [TOC] [prev] [next] [guestbook] [contact] (c) SM
