Java-Middleware zur Anbindung dedizierter mobiler Endgeräte an multimediale Informationssysteme

Inhaltsverzeichnis

Kapitel 1: Einführung & Aufgabenstellung
1.1 Einleitung
1.2 Motivation
1.3 Aufgabenstellung
1.4 Gliederung der Arbeit

Kapitel 2: Grundlagen
2.1 Randbedingungen
2.1.1 Bestehende Formate & Dienste
2.1.2 Mobile Endgeräte
2.1.3 Funknetze
2.2 Begriffsklärung
2.2.1 Mobilkommunikation
2.2.2 Middleware
2.2.3 Metadaten
2.2.4 Adaptionsmodell für Dokumente
2.2.5 Adaptionsmodell für Protokolle
2.2.6 Adaptionskriterien
2.3 Mögliche Ansätze
2.3.1 Anpassung auf Server-Seite
2.3.2 Anpassung auf Client-Seite
2.3.3 Erstellung eigener Dokumente
2.3.4 Anpassung durch einen Mittler

Kapitel 3: Stand der Technik
3.1 Anbindungen
3.1.1 EGate
3.1.2 Smart Messaging
3.1.3 HDTP/HDML
3.1.4 Nokia 9000(i)
3.2 Adaptionsstrategien/-ansätze
3.2.1 HTML-Spracherweiterungen
3.2.2 AltaVista’s Sprachadaption
3.2.3 Realaudio/-video
3.2.4 Konverter
3.3 Integration
3.3.1 Narrow-Band Socket
3.3.2 WAP
3.3.3 Personal/Embedded Java
3.4 Forschungsprojekte
3.4.1 Projekt „Mobile Visualisierung“
3.4.2 Projekt „MARVIN“
3.5 Ergebnisse

Kapitel 4: Systementwurf
4.1 Zielsetzung
4.2 Aufteilung der Adaptionspipeline
4.3 Entwurf der Pipelinestufen
4.3.1 Verbindung von Endgerät zum Mittler
4.3.2 Geräteidentifizierer
4.3.3 Anfrageadaptierer
4.3.4 Verbindung zwischen Mittler und Informationsdienst
4.3.5 Fragmentierer
4.3.6 Bewerter
4.3.7 Adaptierer
4.3.8 Komposer
4.3.9 Verbindung vom Mittler zum Endgerät
4.4 Zusammenfassung

Kapitel 5: Realisierung
5.1 Was ist Java?
5.2 Zielsetzung
5.3 Klassen-Hierarchie
5.4 Das Layout
5.5 Das Plugin-Konzept
5.5.1 Funknetz-Gateway
5.5.2 Internet-Gateway
5.5.3 Reduzierer
5.5.4 Transformator
5.5.5 Adaptionsstrategie
5.6 Beispieldurchläufe
5.6.1 Adaption einer einfachen Email für einen PDA
5.6.2 Adaption einer einfachen Email für ein Smartphone
5.6.3 Adaption einer HTML-Seite für einen PDA
5.6.4 Adaption einer HTML-Seite für ein Handy
5.7 Erweiterungsmöglichkeiten
5.7.1 Ausbaumöglichkeiten
5.7.2 Verfügbarkeits- und Geschwindigkeitsoptimierung
5.7.3 Einbettung

Kapitel 6: Zusammenfassung & Ausblick

Anhang A: Programmbeschreibung

A.1 Nötige Programmumgebung

A.2 Benötigte Dateien

A.3 Die Helpers-Klasse

A.4 Die TreeObject-Klasse

A.5 DefaultMutableTreeNode-Klasse

A.6 Hilfsmethoden für Adaptionsstrategien

Anhang B: Spezifikationen

B.1 Email-Grammatik

B.2 MIME-Grammatik

B.3 HTML3.2

Abkürzungen

Abbildungsverzeichnis

Tabellenverzeichnis

Quellen

Zusammenfassung

Sowohl die Mobilkommunikation per Funktelefon als auch Informationssysteme wie das Internet erleben in den letzten Jahren ein enormes Wachstum. Eine befriedigende Lösung, multimediale Informationssysteme auch mobil nutzbar zu machen, existiert aber bisher noch nicht. Dies liegt unter anderem daran, daß teils sehr komplexen Diensten, Dokumenttypen und Protokollen dedizierte Endgeräte gegenüberstehen. Faktoren wie mangelnde Display- oder Speichergröße, schwache Prozessorleistung sowie die in der Regel geringe Bandbreite der Funkverbindung erzwingen eine Adaption bestehender Informationssysteme auf die individuellen Fähigkeiten der unterschiedlichen mobilen Endgeräte.

Aufbauend auf der Untersuchung der Randbedingungen wie bestehende Dienste und Endgeräte und der Betrachtung verschiedener Ansätze zur Adaption wird der Systementwurf für einen Adaptierer spezifiziert. Da eine Adaption weder alleine auf Endgeräte- noch auf Serverseite adäquat verwirklicht werden kann, wird dazu eine Middleware entworfen und implementiert. Die Adaptionseinheit sowie die Schnittstellen zu den unterschiedlichen Diensten und Endgeräten werden modular und objektorientiert gehalten, um eine maximale Erweiterbarkeit und Flexibilität zu gewährleisten. Weitere Endgeräte, Dienste oder komplette Adaptionsstrategien sollen einfach einzubetten sein. Die eigentliche Adaption wird durch eine Kombination von Transformations-, Reduktions-, Substitutions- und Selektionsmodulen verwirklicht. Durch exemplarische Evaluationen der Extrempositionen des Anwendungsraums des Adaptierers wird darauf dessen Adaptionsfähigkeit im Gesamtanwendungsraum untersucht.

Abstract

Despite the tremendous growth in mobile computing systems and information systems like the Internet in the recent years there is still a lack of solutions for enabling multimedia systems via mobile communication systems. One reason for this is the fact that the dedicent mobile terminal equipment doesn't match the needs of the highly complex services, data types an protocols that are usual in current non-mobile systems. Insufficient display size, insufficient memory, low processor clock speed and a small bandwidth for data exchange enforce an adaption of the mobile information systmes to the individual abilities of the different mobile terminal equipment.

Based upon the analysis of the marginal conditions e.g. existing services and terminal equipment and considering other comparable work, a solution for an adaption system for mobile terminal equipment is provided. Due to the fact that an adaption can not adequately be implemented neither solely on terminal equipment nor on server side, a middleware is developped and implemented. The adaption unit and the interfaces for the numerous services and terminal equipment is kept in a modular and objectoriented way in order to achieve the maximum extendability and flexibility. Further terminal equipment, services or complete adaption strategies should be easy to embed. The actual adaption is achieved by a combination of transformational, reductional, substitutional and selectional modules. The functionality of this adaption process is shown by an exemplary evaluation of the occuring extremes for such applications.

Keywords

H.5.1 Multimedia Information Systems

H.3.5 Online Information Systems

H.5.2 User Interfaces

H.2.4 Distributed Systems

Kapitel 1: Einführung & Aufgabenstellung

1.1 Einleitung

Weltweit ist der Trend zur viel zitierten Kommunikationsgesellschaft zu beobachten. So nahmen 1997 die privaten Internet-Anschlüsse in Deutschland um über 500 Prozent zu. Dies zeigt, wie groß das Interesse in der Bevölkerung ist, an die unterschiedlichsten Informationen zu gelangen und weltweit kommunizieren zu können. Eine weitere Branche, die momentan hohe Zuwachsraten erzielt, ist die des Mobilfunks. Sowohl das stetig steigende Bedürfnis, immer und überall mobil kommunizieren zu können, als auch die immer vielfältigeren Möglichkeiten der zugrundeliegenden Technik, treiben auch in diesem Marktsegment die Verkaufszahlen in die Höhe. Eine weitere Folge dieser Entwicklung ist, daß die Anbieter mobiler Endgeräte versuchen, ihre Produktpalette möglichst breit zu fächern, um den individuellen Anforderungen potentieller Kunden möglichst gut entsprechen zu können.

Diese Fakten lassen nur erahnen, wie in den kommenden Jahren die Begriffe Kommunikation und Information die Entwicklung unserer Gesellschaft bestimmen werden. Ein weiterer Schritt zur Vernetzung des täglichen Lebens wäre beispielsweise, multimediale Informationssysteme wie das Internet auch mobil erreichbar zu machen.

1.2 Motivation

Im Bereich der mobilen Endgeräte gibt es eine kaum überschaubare Anzahl von Produkten. Von Notebooks über Handheld PCs, PDAs^[1], Mobilfunktelefonen bis hin zu Two- und Oneway-Pagern unterscheiden sich diese in ihren Leistungsfähigkeiten enorm. Und auch innerhalb einer Produktkategorie gibt es teilweise erhebliche Funktionsunterschiede.

Des weiteren existieren im Internet eine Vielzahl von verschiedenartigen Dokumenten und Übertragungsprotokollen. So werden beispielsweise im WWW schon standardmäßig einige Grafik- und Soundformate unterstützt. Allerdings werden auch dort immer mehr zusätzliche Formate angeboten, die von den gängigen Browsern dargestellt werden können. Dazu kommen noch die verschiedensten Protokolle zum Austausch von Emails, Übertragung von Dateien, dem Fernsteuern von Computern und anderen Diensten.

Sollen Inhalte aus dem Internet mobil zugänglich gemacht werden, muß gewährleistet sein, daß die in Frage kommenden Endgeräte diese Dokumente auch darstellen können. Mobile Endgeräte sind in der Regel in bezug auf Speicherkapazität, Prozessorleistung, Größe des Displays, Übertragungsgeschwindigkeit und der unterstützten Dokumenttypen in ihren Möglichkeiten beschränkt. Dadurch wird es nötig, eine Adaption der im Internet verbreiteten Informationsinhalte auf die Fähigkeiten des jeweiligen Endgerätes vorzunehmen. Nun stellt sich die Frage, wo eine derartige Anpassung vorzunehmen ist.

Eine Möglichkeit wäre, dies direkt auf der Server-Seite zu tun. Dazu müßte das Endgerät, welches die Anfrage gestellt hat, vom Server identifiziert und das gewünschte Dokument vor der Auslieferung an dessen Fähigkeiten angepaßt werden. Das würde jedoch bedeuten, daß jeder Internet-Server jedes Endgerät unterstützen müßte.

Eine weitere Vorgehensweise wäre, die Adaption innerhalb des Endgerätes vorzunehmen. Dazu müssen jedoch alle Dokumente zuerst einmal komplett übertragen werden, unabhängig davon, ob diese im vollen Umfang dargestellt werden können oder nicht. Dies würde die im allgemeinen ohnehin schmalbandige Funkverbindung zum Endgerät unnötigerweise belasten. Außerdem wird dabei dem Endgerät abverlangt, eine Vielzahl von Dokumenten interpretieren und darstellen zu können. Dazu sind ein leistungsstarker Prozessor und einen großer Speicher vonnöten, was eine größere Leistungsaufnahme und mehr Platzverbrauch bedeutet. Dies steht im Widerspruch zur gewollten Mobilität des Endgerätes.

Als dritte Variante bleibt, die Adaption „im Netz“ selbst, das heißt zwischen Server und Endgerät, vorzunehmen. Bei diesem Ansatz bleibt es einer weiteren Instanz überlassen, zwischen den vom Server angebotenen Dokumenten und den Fähigkeiten des Endgeräts einen Konsens zu finden. Da ein derartiger „Mittler“ beide Seiten, das heißt sowohl Endgerät als auch den Server, entlastet, ist diese Möglichkeit den anderen vorzuziehen.

1.3 Aufgabenstellung

Im Rahmen dieser Diplomarbeit soll eine „Middleware“ spezifiziert und implementiert werden, welche die Aufgabe übernimmt, die verschiedensten Dienste den unterschiedlichen Endgeräten anzupassen. Dabei werden verschiedene Adaptionsmechanismen - wie Transformation, Substitution und Reduktion - untersucht und klassifiziert. Ein weiterer Schwerpunkt liegt auf der Untersuchung verschiedener Strategien, durch die Kombination dieser Mechanismen ein optimales Ergebnis zu erreichen. Dabei soll eine möglichst offene Architektur gewählt werden, um auch künftige Endgeräte oder Dienste unterstützen und gegebenenfalls auch andere Adaptionstrategien integrieren zu können.

1.4 Gliederung der Arbeit

Im nachfolgenden Kapitel wird zuerst auf die bestehenden Randbedingungen, das heißt auf die existierenden Endgeräte und Dokumententypen, eingegangen. Außerdem werden die verschiedenen Ansätze, Dokumente den Ausprägungen unterschiedlicher Endgeräten anzupassen, untersucht und bewertet. Dabei werden die grundlegenden Begriffe eingeführt und erklärt. Im dritten Kapitel werden bereits bestehende Adaptionssysteme vorgestellt und auf ihre Fähigkeiten untersucht. Auf den Ergebnissen dieser beiden Kapitel aufbauend wird im vierten Kapitel der Systementwurf für den zu realisierenden Adaptierer vorgestellt und im Detail spezifiziert. Das folgende Kapitel beschäftigt sich dann mit der Realisierung des zuvor theoretisch hergeleiteten Systems. Abschließend folgt im sechsten Kapitel eine Zusammenfassung der Arbeit und ein kurzer Ausblick.

Kapitel 2: Grundlagen

2.1 Randbedingungen

Um geeignete Adaptionsmechanismen zu finden, ist es unumgänglich, die gegebenen Randbedingungen zu analysieren. Da sind auf einer Seite die im Internet verbreiteten Dokumente, die gegebenenfalls einer Anpassung unterzogen werden müssen. Auf der anderen Seite sind die heute zur Verfügung stehenden Endgeräte mit ihren verschiedenen Möglichkeiten und Restriktionen einer genaueren Untersuchung zu unterziehen.

2.1.1 Bestehende Formate & Dienste

Das Internet wird seit seinem Bestehen immer wieder durch neue Formate und Dienste erweitert, um dem aktuellen technischen Stand und der zur Verfügung stehenden Bandbreite Rechnung zu tragen. Einer der ersten verwirklichten Dienste im Internet war die Möglichkeit, Textnachrichten via Email zwischen einzelnen Teilnehmern auszutauschen. Weitere frühe Dienste waren FTP^[2] und Telnet, deren Aufgabe die Fernsteuerung von Computern ist. Mit der Einführung des WWW^[3] -Dienstes begann dann der kommerzielle Siegeszug des Internets außerhalb der Forschung und Lehre. Es bleibt abzuwarten, welche Dienste das Internet in der Zukunft noch zu bieten haben wird.

Doch auch innerhalb eines bestehenden Dienstes werden immer neue Spezifikationen und Formate verabschiedet, um Neuentwicklungen unterstützen und auf geänderte Bedürfnisse der Benutzer und Anbieter reagieren zu können. So konnten innerhalb des WWW-Dienstes ursprünglich lediglich formatierte Textseiten, die untereinander mit sogenannten Hyperlinks verbunden waren, dargestellt werden. Heute können beliebige Medien wie Grafiken, Animationen, Videos, Töne oder Musik in den verschiedensten Formaten in die Seiten eingebettet werden. Im folgenden sollen die beiden erfolgreichsten Dienste des Internets, Email und WWW, genauer betrachtet werden.

2.1.1.1 Der Email-Dienst

Seit 1982 gibt es mit dem RFC^[4] 822 [Crocker82] einen Standard für die Übertragung von textuellen Nachrichten über das Internet. So ist es heute ohne Probleme möglich, elektronische Nachrichten unter den Internet-Benutzern auszutauschen. Allerdings ist dieser Standard derart beschränkt, daß ein Austausch von Nachrichten, die mehr als nur Textinformationen enthalten, fast unmöglich ist. Das wurde mit dem Aufkommen von Multimedia­anwendungen zu einem immer größeren Manko für dieses Verfahren. Für den deutschen Anwender war außerdem störend, daß RFC 822 nur Texte zuläßt, die Zeichen aus einem 7 Bit ASCII^[5] Code und damit keine deutschen Umlaute benutzen.

Mit dem im RFC 1521 [Borenstein93] und im RFC 1522 [Morre93] festgelegten MIME^[6] -Standard wurde eine Erweiterungen des bisherigen Email-Dienstes geschaffen, um nichttextuelle Dokumente wie Grafik, Audio, Video, usw. zu verschicken. Der herkömmliche Internet-Maildienst wurde dadurch multimediafähig, da mit MIME mehrere Objekte unterschiedlichster Modalität in einer Nachricht versendet werden können. Des weiteren können verschiedene Zeichensätze verarbeitet werden.

Eine Email besteht aus zwei Teilen, dem Kopf (Header) und dem Rumpf (Body). Der Header enthält Informationen über die Nachricht und entspricht in etwa dem Briefumschlag bei einem herkömmlichen Brief. Im Body steht der eigentliche Inhalt. Die komplette MIME-Spezifikation ist ab Seite 121 im Anhang B aufgelistet.

Der Email-Header besteht aus verschiedenen Feldern, die jeweils eine besondere Bedeutungen haben. So gibt es zum Beispiel die To -Zeile mit der Adresse des Empfängers, die From -Zeile mit der Absenderadresse oder die Subject -Zeile zur Angabe eines kurzen Betreffs. Da nach dem MIME-Standard die verschiedensten Dokumente übermittelt werden können, müssen bei derartigen Emails im Header weitere Angaben zu den im Body stehenden Daten gemacht werden. Die wichtigsten Felder sind hier der Inhaltstyp (Content-Type), die verwandte Inhaltskodierung (Content-Transfer-Encoding) oder die MIME-Version. Das Inhaltstyp-Feld besteht aus dem Typ und Subtyp des Inhalts der Mail. Es gibt derzeit acht standardisierte Basistypen und für jeden Basistyp eine Reihe von Subtypen. Ein sogenannter Medientyp wird dabei immer durch ein Tupel Basistyp/Subtyp beschrieben. Zu diesem Tupel können noch verschiedene Parameter, wie zum Beispiel der Name der Datei, hinzukommen. Die verschiedenen Basistypen mit den dazugehörigen, wichtigsten Subtypen werden im folgenden vorgestellt:

Text

Bei dem Basistyp „ Text “ werden standardmäßig zwei Subtypen unterstützt: „ plain “ und „ richtext “. Während beim erst genannten Subtyp nur reiner Text im Body erwartet wird, können beim zweiten zusätzlich Formatierungszeichen übermittelt werden. Als Parameter wird üblicherweise der benutzte Zeichensatz angegeben, so zum Beispiel „ charset=us-ascii “. Dadurch wird es möglich, auch länderspezifische Sonderzeichen zu übertragen und diese beim Empfänger wieder korrekt darzustellen.

Multipart

Wie bereits erwähnt, ist es beim MIME-Format möglich, mit einer Email mehrere verschiedene Dokumente zu übermitteln. Sollen beispielsweise Bilder als Anhang zu einer Textdatei hinzugefügt werden, wird der Subtyp „ mixed “ benutzt. Soll jedoch eine grafische und als Alternative eine textuelle Wegbeschreibung dem Leser der Email zur Verfügung gestellt werden, ist der Subtyp „ alternative “ zu benutzten, wie es in Abbildung 1 dargestellt ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Aufbau einer MIME-Email

Ein weiteres Beispiel ist die Möglichkeit, mit diesem Subtyp eine Nachricht als Plaintext und als Richtext oder HTML zu übertragen. Je nachdem, welches Format der Email-Client unterstützt, kann der Text passend dargestellt werden. Sind die verschiedenen Teile der Email gleichzeitig darzustellen, wird „ parallel “ als Subtyp verwendet. Als Parameter muß in jedem Fall eine sogenannte „ Boundary “ angegeben werden, anhand derer festgestellt werden kann, wo im Body die verschiedenen Dokumente beginnen und enden.

Image

Unter diesem Basistyp werden die verschiedenen Grafikformate zusammengefaßt. Als Subtypen wurden ursprünglich nur die beiden Grafikformate „ JPG^[7] “ und „ GIF^[8] “ unterstützt. Später kam noch das Format „ TIFF^[9] “ dazu.

Video

Hier werden alle unterstützten Videoformate zusammengefaßt. „ MPEG “ und „ Quicktime “ sind die von Anfang an unterstützten Formate.

Audio

Beim Audio-Basistyp wurde ursprünglich nur der Subtyp „ basic “ unterstützt, welcher vor allem auf Sun-Workstations benutzt wird. Allerdings haben sich Formate wie „ WAV^[10] “, „ MPEG^[11] “ oder „ MIDI^[12] “ als Quasi-Standards durchgesetzt.

Message

Soll innerhalb einer Email eine weitere Email verschickt werden, wird dieser Typ benutzt. Dies wird oft benutzt, wenn in einer Email Bezug auf eine andere genommen wird, und diese als Anhang mitgeschickt wird. Als Subtyp wird die Kodierung der eingebetteten Email, beispielsweise „ RFC822 “, angegeben.

Model

Dieser Basistyp wurde erst später zur MIME-Spezifikation dazugenommen. Hier können multidimensionale, abstrakte Objekte, wie zum Beispiel „ VRML^[13] “, abgelegt werden.

Application

Unter diesem Basistyp werden Programmdateien und Dateien, die sich in keine der obigen Kategorien einteilen lassen, übertragen.

Zusätzlich zu den Basis- und Subtypen können sogenannte X-Typen angegeben werden. Diese müssen mit „X-“ beginnen und können beliebige neue Typen beinhalten. Allerdings müssen Sender und Empfänger selbst dafür sorgen, daß dieser Typ entsprechend interpretiert werden kann. Vor allen Dingen bei den Subtypen haben sich hier viele Quasi-Standarde etabliert. Bei kommenden MIME-Spezifikationen werden wahrscheinlich einige als Standard übernommen.

Außer dem Inhaltstyp-Feld muß auch das Inhaltskodierungs-Feld angegeben sein, innerhalb dessen angegeben wird, mit welcher Methode die nachfolgenden Daten kodiert sind. Beispiele wären base64, quoted printable, 8bit, 7bit, binary oder selbstdefinierte Kodierungen (x-foo). Die Felder Inhalts-Beschreibung und –ID sind optional und dienen der Beschreibung der Daten im Nachrichtenrumpf.

2.1.1.2 Das World Wide Web

Das WWW [Steinov97] hat als weltweites, multimediales Informationssystem die Etablierung des Internets als zentrale Kommunikationsplattform sehr vorangetrieben, wenn nicht gar erst ermöglicht. Es wurde am europäischen Kernforschungszenturm CERN in Genf entwickelt und wird vom W3-Consortium [W3C98] weiter entwickelt. Die Beliebtheit des WWW liegt vor allem an der Tatsache, daß es die hierarchische Struktur des Internets verschleiert und sinnverwandte Informationen auf verschiedenen Servern über Hyperlinks verbindet. Zum Transport der verschiedenen Dokumente zwischen Servern und Clients wird das HTTP^[14] -Protokoll benutzt. Die Dokumente selbst sind in der Dokumentensprache HTML^[15] verfaßt.

2.1.1.2.1 Das HTTP-Protokoll

HTTP ist das Protokoll, über welches Server und Clients miteinander kommunizieren. Eine Konversation zwischen Client und Server besteht aus Client-Anfragen an den Server („ request “) und Server-Antworten („ response “). Im Regelfall verlangt der Client, ein bestimmtes Objekt zu lesen oder zu schreiben, und der Server antwortet, indem er das Objekt an den Client schickt. Kommt es dabei zu Fehlern, so schickt der Server eine Fehlermeldung anstelle des Objekts. Die momentan aktuelle Version ist HTTP/1.1 [Franks97, Klute95].

Der Request-Block

Beim Request, also der Anfrage des Clients beim Server, unterscheidet man zwischen einem SimpleRequest und einem FullRequest. Der SimpleRequest entspricht der Funktionalität von HTTP/V0.9 und besteht aus der Zeile

GET URL <CR><LF>

Der FullRequest FullRequest hat einen etwas komplizierteren Aufbau:

Method URL ProtocolVersion <CR><LF> [*<HTRQ Header>] [<CR><LF> <DATA>]

Der FullRequest unterscheidet sich durch die Angabe einer Protokollversion vom SimpleRequest, über die das Aussehen der gesamten Anfrage spezifiziert wird. Die Protokollversion HTTP/V1.0 erlaubt eine beliebige Anzahl von HTRQ^[16] -Headern, über die der Client dem Server bestimmte Mitteilungen machen kann (siehe Tabelle 1), und neben GET weitere Methoden (siehe Tabelle 2).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: HTRQ-Headers

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Die verschiedenen Methoden eines FullRequests

Der Respone-Block

Der Response-Block, der als Antwort auf einen Request-Block vom Server zurück an den Client geschickt wird, hat folgenden Syntax:

Abbildung in dieser Leseprobe nicht enthalten

Im HTTP-Versions-Feld wird, wie der Name schon sagt, die Versionsnummer des verwendeten HTTP-Protokolls übergeben. Der Status-Code gibt den Status des Servers wieder. So bedeutet der Status-Code 200, daß die Anfrage ordnungsgemäß, das heißt ohne Fehler, ausgeführt werden konnte. In der Reason-Line wird eine kurze Beschreibung des Status-Codes geliefert, beim Code 200 beispielsweise ein einfaches „OK“.

Im Response-Header werden diverse Informationen über das gesendete Objekt geliefert (siehe Tabelle 3). Im Data-Feld werden schließlich die eigentlichen Daten übertragen, also etwa ein HTML-Dokument oder ein GIF-Bild.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: Die Felder des Response-Headers

Das für diese Arbeit wirklich Interessante an dem HTTP-Protokoll ist die Tatsache, daß im Response-Header weitestgehend die selben Felder zur Spezifikation des Dokuments gesendet werden wie bei einer MIME-Email im Email-Header. Über diese Angaben können die Dokumente unabhängig vom zugrundeliegenden Dienst klassifiziert werden. In anderen Diensten, in denen der MIME-Typ des übermittelten Dokuments nicht durch das benutzte Protokoll explizit zur Verfügung steht, kann beispielsweise die Endung des Dateinamens zur Ermittlung des Typs herangezogen werden.

2.1.1.2.2 Die HTML-Beschreibungssprache

HTML bildet als Sprache das wichtigste Textformat für das WWW. Der darzustellende Text wird mit HTML-Befehlen formatiert, so lassen sich z. B. Überschriften erzeugen, Textpassagen unterstreichen und Tabellen erstellen. Die Stärke von HTML liegt jedoch in der Einbindung von Grafiken und der Verknüpfung von Dokumenten untereinander. Um Informationen im WWW veröffentlichen zu können, ist die Verwendung von HTML erforderlich.

HTML-Dateien bestehen aus ASCII-Texten und können somit mit jedem ASCII-Editor erstellt werden. Zusätzlich zu den Texten enthalten die Dateien HTML-Befehle, die sogenannten Tags. Tags werden durch spitze Klammern (<>) markiert. Die meisten HTML-Befehle bestehen aus einem einleitenden und einem abschließenden Tag. Zwischen den beiden Tags liegt der Gültigkeitsbereich des HTML-Befehls. Verschiedene Tags können beliebig ineinander verschachtelt werden.

Der HTML-Standard wird ständig vom W3-Consortium [W3C98] erweitert und ist momentan bei der Version 4.0 angelangt. Eine gute, kurze Übersicht über die Befehle von HTML 3.0 bietet [Büning97], eine ausführlichere Betrachtung erfolgt in [Klute95]. Eine kurze Übersicht der in HTML 3.2 definierten Tags ist im Anhang B.3 zu sehen. Eine komplette Auflistung des HTML4.0-Syntax würde den Rahmen dieser Arbeit sprengen. Der interessierte Leser sei auf die Spezifikation des W3-Consortiums [Raggett97] verwiesen.

2.1.1.3 Zukünftige Entwicklungen

Wie bei allen Informations- und Kommunikationsdiensten zu beobachten ist, schmelzen auch das WWW und der Email-Service zusammen. So werden im WWW Daten vom Benutzer zum Server per Email geschickt und es existieren WWW-Gates zur Abfrage von Email-Konten. Auf der anderen Seite setzen sich langsam sogenannte Multimedia-Emails durch, bei denen HTML-Seiten samt eventuellen Grafiken, Filmen und ähnlichem nach dem MHTML-Standard [Palme97] verschickt werden. Dazu wurde zum MIME-Basistyp Text der Subtyp HTML hinzugefügt [Berners95].

Der HTML-Standard ist derart umfassend, daß es für ein in seinen Möglichkeiten beschränktes, mobiles Endgerät fast unmöglich ist, diesen komplett zu unterstützen. Daher wird speziell von den Handy-Anbietern ein neuer Standard lanciert: Der HDTP^[17] /HDML^[18] -Standard stellt im großen und ganzen eine Teilmenge des HTTP/HTML-Standards dar – angepaßt an die Fähigkeiten heutiger mobiler Telefone. Dieser Standard wird später im Kapitel „Stand der Technik“ ab Seite 30 näher beschriebem.

2.1.2 Mobile Endgeräte

Auf der Seite der multimedialen Informationssysteme existieren, wie gesehen, viele unterschiedliche Dienste und Formate. Auf der anderen Seite, den mobilen Endgeräten, sind ebenfalls die unterschiedlichsten Typen vorhanden. Da es die Aufgabe des zu entwerfenden Mittlers ist, zwischen den angebotenen Diensten und den Möglichkeiten der Endgeräte einen Konsens zu finden, um deren Nutzung zu ermöglichen, werden im folgenden die Palette mobiler Endgeräte mit ihren Leistungsdaten vorgestellt und klassifiziert.

2.1.2.1 Merkmale

Im Bereich der mobilen Endgeräte existieren viele verschiedene Produktkategorien. Die einzelnen Systeme unterscheiden sich in ihrem Aufbau und ihrer Leistungsfähigkeit auch innerhalb einer Produktkategorie teils erheblich voneinander [Vucak98]. Folgende Merkmale sollen zur Unterscheidung und Klassifizierung der Endgeräte herangezogen werden:

Leistungsfähigkeit

Im Spektrum der unterschiedlichen mobilen Endgeräte schwanken die Rechenleistungen je nach dem Ausstattungsgrad erheblich. Während Notebooks sogar Soundkarten, spezielle Grafikbeschleuniger und CD-Laufwerke besitzen, können bei herkömmlichen Handys lediglich Telefonnummern gespeichert werden.

Display

Die Größe, Farbtiefe und Lesbarkeit des Displays entscheidet maßgeblich darüber, wie brauchbar ein mobiles Endgerät zur Darstellung multimedialer Informationsinhalte ist. Ein großes Farbdisplay benötigt jedoch wiederum sehr viel Energie, wodurch entweder das Gewicht des Endgeräts durch größere Batterien steigt oder die Laufzeit sinkt. Beides widerspricht der gewünschten Mobilität, wodurch ein möglichst optimaler Kompromiß zwischen Displaygüte und Energieverbrauch gefunden werden muß.

Benutzerinterface

Alle traditionellen Desktop-Geräte werden über eine Kombination von Maus und Tastatur bedient. In näherer Zukunft wird sich wohl noch die Spracheingabe als dritte Möglichkeit der Kommunikation mit dem Computer durchsetzten. Aufgrund der beschränkten Ausmaße, die beispielsweise ein brauchbarer PDA haben darf, muß teilweise auf Tastatur beziehungsweise Maus verzichtet werden. Als Alternativen bieten sich bei leistungsfähigeren Geräten die Schrifterkennung und die Spracheingabe an.

Betriebssystem

Im Gegensatz zu stationären Geräten, bei denen sich einige wenige Betriebssysteme durchgesetzt haben, verfügen die meisten Mobilgeräte eigene, spezielle Systeme. Lediglich bei den leistungsfähigeren Endgeräten, wie Handheld PCs, setzt sich wohl langsam ein gemeinsames Betriebsystem, nämlich Windows CE, durch. Die Leistungsfähigkeiten heutiger (Sub-)Notebooks erlauben den Betrieb mit einem Standard-Betriebssystemen wie Windows oder UNIX.

Bei kleineren Endgeräten hat eine solche Konsolidierung bis jetzt noch nicht eingesetzt. Es bleibt auch fraglich, ob ein traditionelles Betriebssystem überhaupt in der Lage sein wird, die gesamte Palette der mobilen Endgeräte abzudecken - zu unterschiedlich sind die Ausprägungen und Leistungsdaten.

Laufzeit

Die Laufzeit eines Endgeräts, das heißt die Zeitspanne, die ohne Wiederaufladung der internen Batterien überbrückt werden kann, bestimmt die mögliche Mobilität des Benutzers. Mache Geräte können ohne externe Stromzufuhr nur eine Stunde betrieben werden, wodurch eigentlich nur Mobilität des Endgeräts, jedoch nicht die des Benutzers verwirklicht wird.

Netzanbindung

Eine eigene, direkte Funknetzanbindung existiert nur bei kleineren Endgeräten, deren Hauptaufgabe die Kommunikation ist, wie bei Pagern und Handys. Bei den Pagern hat jeder Hersteller sein eigenes Funknetz aufgebaut, im Bereich der Handys existieren in Deutschland momentan die Netze D1,D2, E-Plus und bald E2. Die anderen Geräte, bei denen mehr Wert auf Adressverwaltung und ähnlichem gelegt wird, können im allgemeinen über ein Mobilfunktelefon an ein Funknetz angebunden werden.

2.1.2.2 Klassifizierung

Im folgenden soll der Versuch unternommen werden, die einzelnen Geräte in Gruppen aufzuteilen. Leider können sich die Hersteller nicht auf eine einheitliche Bezeichnung der Gerätetypen einigen, wodurch eine Einteilung bei vielen Endgeräten nicht eindeutig vorzunehmen ist. Außerdem gibt es durchaus Endgeräte, die zwischen den Produktkategoriegrenzen angesiedelt sind.

Notebooks

- Stehen in Ausstattung und Leistungsfähigkeit kaum den traditionellen Desktop-Geräten nach. In der Regel sind die technischen Daten aktueller stationärer PCs circa ein halbes Jahr später auch im Notebook-Sektor erhältlich.
- Relativ großes Farbdisplay
- Traditionelle Eingabemöglichkeiten über Maus beziehungsweise Touchpad und Tastatur
- Standard-Betriebssystem wie Windows oder UNIX
- Nur bedingt als mobiles Gerät zu bezeichnen, da Gewicht, Laufzeit und Ausmaße die Einsatzmöglichkeiten stark einschränken
- Keine direkte Netzanbindung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Das Thinkpad-Notebook von IBM

Subnotebooks

- Die Leistungsfähigkeit beträgt ungefähr die Hälfte der Notebooks
- Mittelgroßes Farbdisplay
- Traditionelle Eingabemöglichkeiten
- Standard-Betriebssystem
- Zwar leicht und handlich, jedoch die Stromaufnahme des Farbdisplays begrenzt die Laufzeit und somit die Tauglichkeit als mobiles Gerät
- Keine direkte Netzanbindung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Subnotebook von Toshiba

Handheld-PCs

- Deutlich schwächere Prozessorleistung in Vergleich zu den Subnotebooks
- Mit Farb- oder Schwarzweiß-Display ausgestattet
- Meist Kombination aus Tastatur- und Stifteingabe
- Mit WindowsCE oder speziellem Betriebssystem ausgestattet
- Bei Farbdisplays relativ kurze Laufzeiten (zum Teil weniger als 2 Stunden), bei zweifarbigem Display durchaus befiedigend
- Keine direkte Netzanbindung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: WindowsCE-Rechner

PDAs

- Leistungsfähigkeit mit der der Handheld-PCs vergleichbar, wobei in dieser Produktfamilie starke unterschiede existieren.
- Im allgemeinen mit einem zweifarbigen Display ausgestattet
- Keine Tastatur vorhanden, Bedienung erfolgt mittels Touch-Screen und/oder Stifteingabe
- Bisher existiert kein einheitliches Betriebssystem, jede Firma benutzt Eigenentwicklungen. SUN mit PersonalJava und Mircosoft mit einer abgewandelten Version von Windows CE wollen dies ändern
- Akzeptable Laufzeiten von mehreren Stunden bis hin zu Tagen
- Keine direkte Netzanbindung vorhanden

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Personal Digital Assistent von Philips

Smartphones

- Kombination aus Handy und PDA mit Anbindung an Informationssysteme. Die Leistungsdaten schwanken sehr.
- Monochromes Display
- Teils komplette Tastatur, teils nur Zehnerblock und Funktionstasten
- Bisher kein einheitliches Betriebssystem
- Je nach Funktionsumfang stark unterschiedliche Laufzeiten
- Direkte Netzwerkanbindung. Die Möglichkeiten reichen von der Anzeige spezieller Informationsinhalte des Anbieters bis zu einem nahezu kompletten Internet-Zugang

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Nokia's 9000(i)

Handys

- Relativ geringe Prozessorleistung nötig
- Monochromes Display
- Nur Zehnertastatur mit zusätzlichen Funktionstasten
- Kein einheitliches Betriebssystem
- Laufzeit beträgt bis zu mehreren Tagen
- Direkte Netzwerkanbindung. Jedoch können Informationen nur mit Hilfe von Zusatzgeräten dargestellt werden. Lediglich das Versenden von Kurznachrichten und die Eingangsbenachrichtigung von Emails sind direkt möglich.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Traditionelles Handy

Pager

- Geringe Prozessorleistung
- Zweifarbiges Display, teils alphanumerisch
- Nur Funktionstasten
- Kein einheitliches Betriebssystem
- Laufzeit beträgt mehrere Monate
- Direkte Netzwerkanbindung, kann jedoch nur empfangen. Dienste wie die Weiterleitung von Emails sind möglich, sonst ist der Benutzer auf das Informationsangebot des Herstellers angewiesen. Interaktive Angebote sind aufgrund des fehlenden Rückkanals nicht möglich.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Pager “Skyper” der Telekom

2.1.3 Funknetze

Sollen mobile Endgeräte mit multimedialen Informationssystemen verbunden werden, kann dies nur über ein drahtloses Netz erfolgen. Obwohl dazu viele proprietäre Lösungsungsansätze zu finden sind, existieren jedoch eine Reihe von grundlegenden Unterschieden zwischen Funk- und Festnetzen:

- Höhere Fehlerraten Interferenzen, erzeugt durch Elektromotore und andere elektro-magentische Geräte, stören die Datenübertragung via Funk. Außerdem ist das Übertragungsmedium weit schwerer zu spezifizieren als bei Festnetzen die Kupfer- oder Glasfaserleitungen. Unterschiedliche Geländeformen, wie Berge oder Flachland, beeinflussen die Übertragungsqualität genauso wie Luftfeuchtigkeit und Temperatur.
- Stets geteiltes Medium Die erreichbare Bandbreite muß immer mit allen Teilnehmern in der Funkzelle geteilt werden. Lösungen wie Switches und Bridges, die in Festnetzen benutzt werden, sind nicht möglich.
- Niedrigere Übertragungsraten Durch die beiden zuvor genannten Eigenschaften von Funknetzen ergibt sich zwangsläufig auch eine niedrigere Übertragungsrate für die einzelnen Benutzer. In lokalen Funknetzen können einige Mbit/s erreicht werden, regional stehen beispielsweise nur 9,6 kbit/s per GSM^[19] zur Verfügung [Eberspächer97].
- Höhere Verzögerungen, größere Schwankungen Bei Festnetzen sind die angeschlossenen Systeme stationär und durch ihre Adresse eindeutig anzusprechen. Bei Funknetzen muß dagegen das Endgerät zuerst lokalisiert werden und das Routing zu diesem generiert werden. Bei GSM benötigt der Verbindungsausbau dadurch mehrere Sekunden, sonst sind einige hundert Millisekunden durchaus üblich. Durch Wechseln der Funkzelle und ähnlichem resultieren auch größere Schwankungen der Bandbreite als bei vergleichbaren Festnetzen.
- Restriktivere Regulierung der Frequenzbereiche Die Vergabe der Frequenzen muß koordiniert werden, damit nicht verschiedene Lösungen auf den gleichen Frequenzen kommunizieren und sich somit stören. Die sinnvoll nutzbaren Frequenzen sind nahezu vollständig vergeben.
- Geringere Sicherheit gegenüber Abhören Die Luftschnittstelle ist für jeden einfach zugänglich, es müssen keine physikalischen Verbindungen abgehört werden.

2.2 Begriffsklärung

Im folgenden sollen einige grundlegende Begriffe, die im Rahmen dieser Arbeit benutzt werden, definiert und erläutert werden.

2.2.1 Mobilkommunikation

Unter Mobilkommunikation versteht man die Möglichkeit, ohne Ortsbeschränkungen kommunizieren zu können. Dabei können folgende zwei Ausprägungen unterschieden werden [Krüger98]:

- Benutzermobilität Der Benutzer kann (drahtlos) „zu jeder Zeit, an jedem Ort, mit jedermann“ kommunizieren. Heutige Mobilfunknetze erfüllen diese Spezifikation im Sprachbetrieb, falls sich der Benutzer nicht gerade in einem Senderloch befindet.

- Gerätemobilität Ein Gerät kann zu einer beliebigen Zeit, an einem beliebigen Ort mit dem Netz verbunden werden. Diese Möglichkeit ist bei den heutigen Festnetzen nicht gegeben, vor allen Dingen aus Gründen der Netzwerksicherheit.

Ein weiterer Aspekt der Mobilkommunikation ist die Tatsache, daß „drahtlos“ nicht automatisch „Mobilität“ bedeutet. Ein Funk-LAN^[20] ist beispielsweise im allgemeinen nur innerhalb eines bestimmten Gebäudes zu erreichen, wodurch nicht von Benutzermobilität im eigentlichen Sinne gesprochen werden kann. In der folgenden Tabelle sind verschiedene Szenarien nach „drahtlos“ und „mobil“ klassifiziert:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4: Drahtlose und mobile Kommunikation

Wird im Rahmen dieser Arbeit von „mobil“ gesprochen, ist die oben beschriebene „Benutzermobilität“ gemeint.

2.2.2 Middleware

Der Begriff „ Middleware “ ist momentan in aller Munde und wird als die Technologie gehandelt, um verschiedene, heterogene Dienste einfach und standardisiert ansprechen zu können. Doch was ist eigentlich Middleware?

2.2.2.1 Begriffsdefinition

Die ursprüngliche Definition lautete: „Middleware ist eine Menge von wenig spezialisierten Diensten, die zwischen der Systemplattform und den Anwendungen angesiedelt sind.“ [Bernstein96]. Mit dem Begriff Systemplattform ist hier die Hardware und das darauf zugreifende Betriebssystem gemeint. Unter diese Kategorie fallen alle (Hilfs-)Programme, die die hardwarespezifischen Besonderheiten einzelner Systeme verschleiern und eine standardisierte Schnittstelle zur Kommunikation mit diesen Systemen bieten, wie etwa die Gerätetreiber. Ein Beispiel hierfür ist etwa ein Druckermanager, der es den Anwendungen erlaubt, ohne Wissen über den angeschlossenen Drucker, auf diesen zuzugreifen. Die Anpassung an die Hardware wird innerhalb des Druckermanagers vorgenommen. So gesehen existiert Middleware-Software schon so lange wie die Betriebssysteme. Im Zeitalter des Internets hat sich jedoch die Begriffsdefinition etwas gewandelt. Ist in diesem Zusammenhang von Middleware-Software die Rede, wird stillschweigend davon ausgegangen, daß sie zur plattformübergeifenden Kommunikation benutzt wird. Sie setzt auf bestehende Protokolle, wie beispielsweise TCP^[21] /IP^[22], auf und bietet den Anwendungen, die auf sie zugreifen, eine standardisierte, allgemeinere Schnittstelle.

Außerdem werden auch Mechanismen, die verschiedene Protokolle ineinander umwandeln und diese somit zusammenführen, als Middleware bezeichnet. Nach der obigen Definition handelt es sich hierbei jedoch streng genommen nicht um eine Middleware im ursprünglichen Sinn, da die Adaption nicht in einer Zwischenschicht, sondern im Netz selbst vorgenommen wird. Um etwaigen Begriffsverwirrungen vorzubeugen, werden derartige Adaptoren im folgenden als Mittler bezeichnet.

2.2.2.2 Warum Middleware?

Die Vorteile einer Middleware liegen auf der Hand:

- Vorhandene Systeme lassen sich mit geeigneter Middleware ohne tiefgreifende Reorganisation an andere Systeme ankoppeln. So bleiben gewachsene und erprobte Strukturen erhalten, womit die bewerkstelligte Investitionen geschützt werden.
- Entwickler wünschen sich Unterstützung für die Entwicklung verteilter Anwendungen. Middleware stellt aus diesem Blickwinkel höhere Dienste als reine Betriebssystemplattformen zur Verfügung. Sollen Programmteile auf einem anderen Rechner ausgeführt werden, so ist beispielsweise ein RPC^[23] -Mechanismus leichter zu handhaben als die Verwendung von Send/Receive-Protokollen.
- Entwickler von verteilten Anwendungen wollen ihre Produkte aus ökonomischen und softwaretechnischen Gründen so weit wie möglich von der Systemplattform entkoppeln.
- Da es in mehr und mehr Anwendungsfeldern Bedarf für verteilte Lösungen gibt, zum Beispiel weil Daten nicht mehr im systemeigenen Filesystem, sondern in einer Datenbank abgelegt werden sollen, wird Middleware zunehmend an Bedeutung gewinnen.

2.2.3 Metadaten

Metadaten, also Daten über Daten, sind für den zu verwirklichenden Adpationsvorgang essentiell. Mit deren Hilfe kann beispielsweise abgeschätzt werden, wie wichtig einzelne Dokumententeile für das Verständnis des Gesamtdokuments sind. Nachfolgend wird eine allgemeine Definition des Begriffes Metadaten und eine spezielle Definition für elektronische Dokumente vorgestellt [Ferch97].

2.2.3.1 Allgemeines

Metadaten beziehungsweise Metainformationen sind im weitesten Sinne Daten über Daten. Sie dienen der Beschreibung von Objekten, Dokumenten oder Diensten, indem sie Daten über deren Form und Inhalt enthalten. Metadaten sind Informationen über Daten, die den Zugriff der Daten intelligenter und effizienter machen sollen. Sie sollen keine Einschränkungen bezüglich des Inhalts darstellen und sollten erweiterbar sein. Metadaten können nicht nur zu herkömmlichen Dokumenten, sondern auch zu Personen, Kursen, Abteilungen oder anderen Objekten vorhanden sein. Metainformationen können im zu beschreibenden Dokument oder separat abgelegt sein. Im Gegensatz zu Metadaten, die in herkömmlichen Katalogen aufgelistet sind, können die hier näher betrachteten Metainformationen einen direkten Verweis (z.B. Netzwerkadresse) auf die zu beschreibenden Daten haben. Eine alltägliche Form von Metadaten ist das Dateiformat eines Dokumentes. Es dient dazu, eine entsprechende Repräsentation der Daten durch eine Anwendung zu ermöglichen. William A. Katz unterteilt in [Katz88] Informationsquellen in drei Kategorien: primäre, sekundäre und tertiäre.

Primäre Information ist das Originalmaterial in Form von veröffentlichten Artikeln, Reports, Dissertationen, Programmen, Bildern, Filmen und ähnlichem.

Sekundäre Informationsquellen, oftmals auch Meta-Informationen genannt, werden als Indizes für primäre Informationsquellen benutzt und nach einiger Zeit, die zwischen Monaten und Jahren liegen kann, erstellt. Die Meta-Informationen sind Daten über die primäre Informationsquelle.

Als tertiäre Informationsquelle bezeichnet Katz eine Kombination aus selektierten Informationen von primären und sekundären Quellen.

Die Begriffe Metadaten, Metainformationen, Metabeschreibungen und Metaeigenschaften werden in dieser Arbeit alle gleichbedeutend verwendet. Es handelt sich dabei um zusätzliche Informationen zu Informationen. Die Unterscheidung zwischen Daten und Informationen wird hier nicht vorgenommen. Insbesondere im englischsprachigen Bereich werden die Begriffe oft gleichgesetzt.

2.2.3.2 Definition von Metadaten nach IEEE

Beim Metadata Workshop Meeting des IEEE am 26. August 1993 [IEEE93] einigten sich Vertreter verschiedener Organisationen, Firmen und Institutionen auf einige grundlegende Vereinbarungen. Es gibt zwei verschiedene Ebenen, in denen Metadaten existieren, zum einen allgemeine Metadaten für alle Daten, zum anderen spezielle Metadaten für jedes Dokument. Metadaten sind Informationen über:

1. die gespeicherten Informationen
- Semantik/Informationsinhalt
- Strukturierte Abbildung der Speicherung
- Typ und Codierung der Elemente
- Beziehungen zwischen Informationen
- Format/Struktur/Typ der Informationen
- Folgerung/Ableitung
2. Speichermanagement und Administration
- Lokation/Name
- Zugriffszeit
- Zugriffsmethoden (Zugriff, Speicherung, Migration)
3. Benutzung der Informationen
- Erlaubnis/Zugriffsrechte
- Benutzung/Handhabung
- Interpretation

Durch diese Definition entstanden zwei Arten von Metainformationen:

1. Metadaten, welche die gespeicherten Informationen des Dokumentes/Objektes beschreiben (Inhalt des Objektes)
2. Metadaten, welche die Benutzung und Speicherung des Objektes betreffen (Pfadname, wo das Objekt abgespeichert ist, Datum/Uhrzeit des letzten Zugriffs, Erstellungsdatum, letzte Metadatenänderung, Dateigröße, Zugriffsvoraussetzungen, Zugriffsrechte, Verweise auf gespiegelte Informationsquellen)

2.2.4 Adaptionsmodell für Dokumente

Bei heutigen Informationsdiensten wird meist von einheitlichen Endgeräten ausgegangen. Als Clients werden relativ leistungsfähige Computer mit großen Displays und viel Speicher erwartet. Diese Voraussetzungen erfüllen heutige mobile Endgeräte in der Regel nicht. In Tabelle 5 sind die gröbsten Unterschiede zwischen herkömmlichen, stationären Systemen und mobilen Endgeräten zusammengefaßt [Gessler97].

Abbildung in dieser Leseprobe nicht enthalten^[24]

Tabelle 5: Unterschiede bei der Präsentation von Informationen

Daraus folgt, daß Dokumente, die für herkömmliche Systeme konzipiert wurden, auf die Fähigkeiten der mobilen Endgeräte zugeschnitten werden müssen. Um eine Adaption eines bestehenden Informationsdienstes überhaupt vornehmen zu können, müssen die Dokumente, die dieser liefert, analysiert und aufgeschlüsselt werden. Nur so können beispielsweise Teile des Dokuments, die nicht dargestellt werden können, durch eine alternative Darstellung ersetzt werden.

In folgenden Kapitel wird ein Schichtenmodell vorgestellt, welches deutlich macht, in welchen Bereichen Adaptionen vorgenommen werden können. Daraus wurden drei allgemeine Adaptionsformen entwickelt, die näher spezifiziert werden [Ferch97].

2.2.4.1 Adaptionsebenen

Um die Informationen adäquat mit vielen Endgeräten verarbeiten zu können, sind Adaptionen auf verschiedenen Abstraktionsebenen vorzunehmen. Die Tabelle 6 zeigt zu jeder Abstraktionsstufe mögliche Adaptionsformen und Beispiele.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 6: Die verschiedenen Adaptionsebenen

Alternative Dokumente

Kann ein Dokument nicht vom Endgerät dargestellt werden, kann es die Möglichkeit geben, dieses durch ein anderes, gleichwertiges Dokument zu ersetzten. Dieses Alternativdokument kann durch den Dokumentenanbieter direkt erfolgen^[25], oder mittels automatischer Umwandlung durch den Mittler. Durch eine große Anzahl von Konvertierungsprogramme kann dieser in die Lage gebracht werden, alle möglichen Dokumenttypen ineinander umzuwandeln.

Bewertung der allgemeinen Strukturen

Eine Bewertung einzelner Strukturen stellt die Grundlage dafür dar, um zu entscheiden, welche Informationen auf jeden Fall übertragen werden müssen und welche eventuell gekürzt oder gelöscht werden können. Diese Bewertungen können auf mehrere Arten erzeugt werden:

Zum einen kann durch spezielle Metainformationen über ein Dokument dessen Wertigkeit bestimmt werden, wie beispielsweise durch das „Priority“-Feld bei den Email-Protokollen [Crocker82]. Dies setzt jedoch voraus, daß der Anbieter des Dokuments diese Metainformationen auch übermittelt. Eine weitere Möglichkeit wäre, die Wichtigkeit eines (Teil-)Dokuments anhand von statischen Tabellen zu ermitteln. So ist bei dem Email-Protokoll das Absender- und das Subject-Feld im allgemeinen wichtiger als das Recieved-Feld. Dadurch kann eine Bewertung ohne zusätzliches Randwissen rein anhand der Dokumentenstruktur erfolgen.

Durch die Analyse des Dokumenteninhalts können möglicherweise Metainformationen gewonnen werden, anhand derer eine Einstufung der Wertigkeit des Dokuments erfolgen kann. Allerdings ist die Aufgabe, zum Beispiel den Informationsinhalt eines Textdokuments abzuschätzen, keineswegs trivial. Hierzu muß die höhere Intention des Textes erfaßt und bewertet werden. Eine eher unbefriedigende Methode, den Informationsgehalt zu bewerten, wäre beispielsweise das Zählen der Wörter oder Sätze des Dokuments.

Allgemeine Strukturen

Bei einer Adaption auf der allgemeinen Strukturebene wird meist das Layout, jedoch nicht die Struktur selbst, gewechselt. So wird bei der Struktur Tabelle zum Beispiel von der Darstellung als Säulendiagramm in die Darstellung als Tortendiagramm gewechselt.

Spezielle Strukturen

Bei speziellen Strukturen findet ein Wechsel zwischen Strukturen statt. So kann ein LaTeX-Dokument in ein HTML-Dokument konvertiert werden, falls das Endgerät das LaTeX-Dokument nicht direkt darstellen kann.

Medium

Das Internet wird oftmals mit dem Schlagwort „multimedial“ klassifiziert, was heißen soll, daß die unterschiedlichsten Medien, wie Text, Bild, Video oder Sprache, übertragen werden. Viele Endgeräte können nicht alle Medien ausgeben. Um die angebotenen Informationen jedoch trotzdem dem Benutzer zugänglich machen so können, ist ein Wechsel des Mediums nötig. So könnte ein längeres Text-Dokument auf einem Handy nur schwer dargestellt werden. Der Mittler könnte jedoch den Text dem Benutzer vorlesen und somit dessen Informationsgehalt durch das Medium Sprache übertragen.

Datenformat

In dieser Ebene wird zur Adaption nicht das komplette Medium gewechselt, sondert es findet ein Formatwechsel im gleichen Medium statt. Kann das Endgerät beispielsweise nur GIF-Bilder darstellen, das gewünschte Bild ist jedoch im JPG-Format abgespeichert, kann durch die Konvertierung ins GIF-Format die gewünschte Adaption erreicht werden.

Technische Parameter

In der untersten Ebene werden spezielle Umformungen direkt an den technischen Eigenschaften des Datenformats vorgenommen. So kann bei einem Bild eine Farbreduktion vorgenommen oder der Kompressionsfaktor geändert werden.

2.2.4.2 Adaptionsmechanismen

Bei der Analyse des Adaptionsmodells haben sich drei grundlegende Adaptionsformen herauskristallisiert, mit deren Hilfe Informationsinhalte auf die individuellen Fähigkeiten der unterschiedlichen Endgeräte abgebildet werden können [Gessler97]. Diese sollen im folgenden näher vorgestellt werden. Eine genauere Betrachtung wird später beim Systementwurf erfolgen.

2.2.4.2.1 Transformation

Als Transformation wird die Umwandlung eines Dokuments bezeichnet, bei der sich der Informationsgehalt nicht geändert wird oder dieser vernachlässigbar klein ist. Diese Art der Adaption kann prinzipiell in allen Abstraktionsebenen des Adaptionsmodells vorgenommen werden, hauptsächlich jedoch in der Präsentationsebene und Strukturebene.

Häufige Transformationen werden zwischen verschiedenen Datenformaten vorgenommen, wie zum Beispiel die Umwandlung eines GIF-Bildes in ein JPG-Bild. Auch die Transformation auf Mediumsebene ist durchaus möglich, solange der Informationsgehalt nicht nachhaltig reduziert wird. Ein Beispiel hierzu wäre die Umwandlung von Text in Sprache. Es können auch Transformationen im Bereich Struktur/Layout vorgenommen werden. So stellt eine Umwandlung eines LaTeX-Dokuments in ein Word-Dokument genauso eine gültige Transformation dar, wie die Darstellung eines Kuchendiagramms als Säulendiagramm.

2.2.4.2.2 Substitution

An eine Substitution, also das Ersetzen durch eine Alternative, wird im Gegensatz zur Transformation nicht die Bedingung geknüpft, daß der Informationsgehalt vollständig erhalten bleiben muß. Sie wird hauptsächlich in den höheren Abstraktionsstufen vorgenommen, da dort am ehesten eine alternative gefunden werden kann. Ein Beispiel wäre hier die textuelle Beschreibung eines Bildinhaltes zu nennen, wie bei einem HTML-Dokument durch den ALT-Tag. Hier wird das Alternativdokument vom Informationsanbieter geliefert. Dies bedeutet allerdings auch, daß hier möglicherweise nicht, wie angenommen, eine sinnvolle Alternative zum Bildinhalt gegeben ist. Tatsächlich ist es gerade in diesem Fall so, daß im ALT-Tag im allgemeinen nur der Dateiname der Grafik angegeben ist. Bei MIME-Emails kann der gleiche Informationsgehalt auf mehreren Arten gleichzeitig übertragen werden. Diese Vorgehensweise soll sicherstellen, das der Empfänger die Informationen auswerten kann. Oft wird beispielsweise eine Nachricht als HTML-Dokument und als Plaintext übertragen. Da in diesen Fällen die Substitution schon vom benutzen Dienst geliefert wird, bleibt dem Adaptierer lediglich die Aufgabe der Selektion eines der Alternativdokumente.

Fehlen die Angaben zu alternativen Dokumenten, kann der Mittler versuchen, selbst eine Substitution vorzunehmen. Im Falle eines Bildes wäre eine sehr ausgefeilte Bildverarbeitung nötig, um automatisch eine aussagekräftige textuelle Beschreibung des Bildes zu generieren. Aber beispielsweise die Substitution eines Faxes durch einen ASCII-Text wäre mittels Schrifterkennung durchaus möglich. Zeichnungen und Layout des Faxes gingen dabei verloren.

Ein ähnliches Beispiel ist die Spracherkennung, wobei Sprache in Text umgewandelt wird. Auch wenn dabei alle gesprochenen Wörter erkannt werden können, gehen hierbei Informationen wie Betonung, Stimme oder Lautstärke verloren. Andererseits könnte, eine leistungsfähige Software vorausgesetzt, in diesen Beispielen der Informationsgehalt weitgehend erhalten bleiben. Hier wird erkenntlich, daß sich die Grenzen zwischen Transformation und Substitution durchaus verwischen können.

2.2.4.2.3 Reduktion

Das Kürzen ist eine Adaptionsform, bei der versucht wird, (Teil-)Dokumente zu verkürzen oder ganz zu löschen. Hierbei wird nicht der Dokumenttyp geändert, sondern innerhalb des benutzten Typs eine Reduktionen vorgenommen.

Bei Bildern wären mögliche Kürzungen, das Bild zu verkleinern, die Farbanzahl zu reduzieren oder der Kompressionsfaktor zu erhöhen. Wie stark diese möglichen Reduktionsformen angewandt werden müssen, ergibt sich durch die Fähigkeiten des Endgeräts (Speicher, Auflösung, Farbzahl) und der Wertigkeit des Bildes innerhalb des zu übermittelnden Dokuments. Beim Systementwurf wird auf diese Problematik noch genauer eingegangen. Bei Videos oder Animationen stehen im Rahmen der Einzelbilder dieselben Reduktionsmöglichkeiten wie bei den Bilddaten zur Verfügung, allerdings kann hier noch zusätzlich die Bildfrequenz reduziert werden. Um Texte zu kürzen, kann man, je nach gewünschtem Reduktionsfaktor und der Mächtigkeit der Software, verschiedene Ansätze benutzen:

- Nur die Überschriften übertragen.
- Eine Schlagwortliste aus den am meisten benutzten Substantiven erstellen.
- Standardabkürzungen verwenden ( „zum Beispiel“ ersetzen durch „z.B.“).
- Text absuchen, ob ein Abstract-, Kurzfassungs-, Zusammenfassungs-, oder ein Einführungskapitel vorhanden ist, und dieses übertragen.
- Versuchen, automatisch eine Zusammenfassung des Textes zu generieren.

Bei Audiodaten kann die Samplerate reduziert werden oder beispielsweise eine Stereo-Aufnahme in Mono umgewandelt werden. Auch ist bei einigen Formaten die Möglichkeit gegeben, den Kompressionsgrad zu erhöhen. Oft ist innerhalb eines Audio-Dokuments der Titel oder/und der Autor vermerkt. Also könnte auch etwa auch nur der Titel eines Lieds übertragen werden. Allerdings würden hierdurch Audiodaten in ein anderes Medium, nämlich der textuellen Beschreibung, überführt. Deshalb wird hier eher von einer Substitution gesprochen, obwohl streng genommen das ursprüngliche Dokument nur stark gekürzt wurde. Auch hier zeigt sich, das eine klare Trennung zwischen den einzelnen Adaptionsmechanismen kaum möglich ist.

2.2.4.2.4 Selektion

Als Selektion wird die Aufgabe bezeichnet, ein Dokument aus einer Liste gleichwertiger, alternativer Dokumente auszuwählen. Dabei spielt es keine Rolle, ob diese Alternativen vom Dienst selbst bereitgestellt oder vom Mittler generiert wurden. Im Gegensatz zur Substitution, bei der Alternativdokumente gefunden oder erzeugt werden sollen, liegt das Hauptaugenmerk bei der Selektionsadaption auf eine möglichst optimale Auswahl des schlußendlich auszuliefernden Dokuments.

2.2.5 Adaptionsmodell für Protokolle

Nicht nur die unterstützen Dokumenttypen unterscheiden sich bei mobilen Endgeräten oft von den vom Informationsanbieter gelieferten Typen, sondern auch die Protokolle, die von beiden Seiten benutzt werden [Gessler97b]. In Tabelle 7 sind die grundlegenden Unterschiede zwischen herkömmlichen Protokollen im Festnetz und Protokollen im mobilen Umfeld zusammengefaßt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 7: Unterschiede der Interaktion bei herkömmlichen und mobilen Systemen

Aufgrund dieser Unterschiede muß auch auf Protokollebene eine Adaption stattfinden. Timeouts, Paketgrößen und anderes müssen angepaßt werden. Dazu stehen zwei prinzipielle Adaptionsmechanismen zur Verfügung:

Emulationsadaption

Bei diesem Adaptionsmechanismus werden Interaktionsvorgänge mit dem Gegenüber emuliert. Bei ähnlichen Protokollen kann dabei eine einfache Protokollumsetzung erfolgen. In diesem Fall wird der ein- beziehungsweise ausgehende Datenstrom so umformatiert, daß dieser den Spezifikationen des Zielprotokolls entspricht. In den meisten Fällen genügt dies jedoch nicht.

Werden zum Beispiel verschiedene Paketgrößen benutzt, müssen diese zwischengespeichert, aufgelöst und in der neuen Paketgröße weiter geschickt werden. Auch sind meist unterschiedliche Übertragungsraten vorhanden, was es nötig macht, einen Puffer einzurichten. Da derartige Protokollunterschiede nicht durch eine einfache Umsetzung aufgefangen werden können, wird in diesen Fällen eine Stellvertreterkomponente eingesetzt. Diese kommuniziert mit dem Gegenüber in dessen Protokollspezifikation und verschleiert somit das eigene Protokoll.

Distributionsadaption

Bei der Distributionsadaption erbringt eine dritte Instanz die benötigte Protokollumsetzung. Diese beherrscht beide benutzte Protokolle und kann diese ineinander umwandeln, wie es in Abbildung 9 zu sehen ist. Dieser Mittler nimmt auf beiden Seiten die Rolle des Kommunikationspartners ein. Den beim Kommunikationsprozeß beteiligten Geräten wird somit gar nicht bewußt, daß ihr Gegenüber ihr Protokoll nicht verarbeiten kann.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Protokolladaption mit Hilfe einer dritten Instanz

2.2.6 Adaptionskriterien

Eine Adaption eines Informationsdienstes wird vorgenommen, um diesen einem speziellen Endgerät zur Verfügung stellen zu können. In diesem Zusammenhang haben sich verschiedene Kriterien herauskristallisiert, nach denen Adaptionen klassifiziert werden können. Sind alle diese Kriterien nach der Adaption erfüllt, war diese erfolgreich und die Informationen sind von dem Endgerät darstellbar.

Datentreue

Das Kriterium Datentreue besagt, daß durch die Adaption ein Dokument generiert werden muß, das auf dem benutzten Endgerät darstellbar ist. Für das Adaptionsmodul bedeutet dies, daß es, falls ein geliefertes Dokument nicht vom Endgerät unterstützt wird, dieses in ein Dokument umwandeln muß, welches darstellbar ist.

Bedarfstreue

Das Bedarfstreue-Kriterium schreibt vor, daß die Repräsentationsform der Daten entsprechend der vorhandenen Ressourcen des Endgeräts gewählt werden muß. Eine Grafik zum Beispiel muß dem Display entsprechend aufbereitet werden. Das bedeutet, daß die Dimension und die Farbtiefe der Grafik den Fähigkeiten des Displays angepaßt werden. Außerdem darf der zur Verfügung stehende lokale Speicher nicht überschritten werden.

Informationstreue

Bei der Adaption sollen die ursprünglichen Informationen möglichst erhalten bleiben. Kann ein Endgerät beispielsweise nur ASCII-Text darstellen und es wird ein HTML-Dokument geliefert, muß dieses in ASCII-Text umgewandelt werden. Das Informationstreue-Kriterium besagt, daß die Ursprungsinformation auch in dieser Repräsentationsform wieder erkennbar sein muß.

Rollentreue

Auf der Interaktions-, sprich Protokollebene, muß aufgrund unterschiedlicher Ressourcen und Protokolle auch adaptiert werden. Das Kriterium der Rollentreue verlangt hier, daß derartige Diskrepanzen in den Interaktionsabläufen aufgehoben werden müssen, um eine störungsfreie Kommunikation zwischen dem Dienstanbieter und dem Endgerät zu ermöglichen.

2.3 Mögliche Ansätze

Im folgenden sollen nun die verschiedenen, theoretischen Ansätze zur Adaption der unterschiedlichen Dienste nach den Bedürfnissen und Fähigkeiten der verschiedenen Endgeräte genauer untersucht werden. Ziel dabei ist es, festzustellen, wo innerhalb des Gesamtsystems eine Adaption am besten durchgeführbar ist.

2.3.1 Anpassung auf Server-Seite

Geht man von einer direkten Verbindung zwischen dem Internet-Server und dem Endgerät aus muß entweder der Server oder das Endgerät die Adaption vornehmen. In diesem Abschnitt soll die Möglichkeiten untersucht werden, die auf Server-Seite existieren, um multimediale Dienste zu adaptieren, wie es in Abbildung 10 dargestellt ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Jeder Server muß für jedes mögliche Endgerät passende Dokumente liefern.

Dazu müßte der Server das Endgerät, welches eine Anfrage stellt, identifizieren und die Daten so aufbereiten, daß sie auf diesem darstellbar sind. Nach dem HTTP-Standard ist es für den Server möglich, den vom Client verwendeten Browser und das darunterliegende Betriebssystem zu identifizieren. Allerdings würde dies auch bedeuten, daß der Server für jedes mögliche Endgerät entsprechend angepaßte Dokumente liefern müßte. Dies erzeugt bei der bereits existierenden und vor allem bei der noch zu erwartender Vielfalt der Endgeräte einen großen Verwaltungsaufwand. Schon alleine bei den beiden heute gängigen Browsern für Desktop-Geräte, dem Internet-Explorer von Microsoft und dem Navigator von Netscape, sind trotz großer Standardisierungsbemühungen kleinere Unterschiede vorhanden, so daß manche WWW-Seiten nur von einem bestimmen Browser korrekt wiedergegeben werden können. Daher ist es kaum anzunehmen, daß alle Anbieter von Internet-Inhalten alle Endgeräte unterstützen werden. Des weiteren können bei dieser Variante zwar die Dokumente angepaßt werden, jedoch nicht die verschiedenen Protokolle, wie HTTP beim WWW oder SMTP^[26] beim Email-Verkehr [Postel82]. Das bedeutet, daß die verschiedenen Endgeräte die im Internet üblichen Protokolle beherrschen müssen.

2.3.2 Anpassung auf Client-Seite

Bereits verwirklicht ist die Möglichkeit, Notebooks oder PDAs mit Funktelefonen zu koppeln, und somit auch diese an das Internet anzubinden. Allerdings ist diese Kombination aufgrund deren Dimensionierung nur noch beschränkt für den mobilen Einsatz tauglich. Weiterhin ist gibt es bereits Funktelefone, wie zum Beispiel das Nokia 9000i, bei denen bereits die grundlegenden Kommunikationsprogramme (WWW-Browser, Email-Programme, usw.) eingebaut sind. Dabei gibt es jedoch zwei grundlegende Probleme:

1. Um mit Funktelefonen die komplette Palette der im Internet angeboten Informationen und Kommunikationsmöglichkeiten nutzen zu können, muß eine ganze Palette an Software in das Endgerät integriert werden (siehe Abbildung 11). Mit den heutigen Möglichkeiten der Mikroelektronik ist es kaum möglich, auf so kleinem Raum all diese Software unterzubringen. Abbildung 12 zeigt, wie sich der Umfang der Browser im Laufe der Entwicklung des WWW immer mehr aufgebläht hat. Außerdem ist zur Verarbeitung dieser Software ein leistungsfähiger Prozessor von Nöten. Mit steigender Taktrate steigt jedoch auch der Energieverbrauch und sinkt die Lebensdauer der Akkus.

2. Die Displays heutiger Mobilfunktelefone können aufgrund ihrer Auflösung und Größe nicht alle Inhalte des Internets komplett darstellen. So kann ein großes Bild in Echtfarben beispielsweise nur verkleinert und mit reduzierter Farbtiefe dargestellt werden. Da das Bild jedoch direkt vom WWW-Server geladen wird, benötigt es trotzdem die volle Bandbreite eines großen Bildes. So steigt die Übertragungsdauer für die Webinhalte unnötig an.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: Adaption auf der Client-Seite

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12: Die Entwicklung der Browsergröße (ohne Hilfsdateien)

2.3.3 Erstellung eigener Dokumente

Eine weitere Möglichkeit, mobile Endgeräte mit Informationen zu versorgen, ist die Verwendung spezieller Server für bestimmte Endgeräte - so wie es in Abbildung 13 gezeigt wird. In diesem Szenario stellt der Hersteller eines Endgeräts meist auch den Betreiber des Servers und der Netz-Infrastruktur dar und kann somit beliebige Protokolle und Dokumente zur Kommunikation mit dem Endgerät verwenden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13: Für jedes Endgerät wird ein eigener Server verwendet.

Auf der einen Seite hat dies den Vorteil, daß die Fähigkeiten der mobilen Geräte optimal ausgenutzt und etwaige Defizite der Architektur durch geschickte Wahl der Übertragungsprotokolle verschleiert werden können. Da der entsprechende Server genau weiß, wie er seine Dokumente ausliefern muß, entfällt eine weitere Anpassung.

Andererseits ist der Benutzer des Endgeräts auf die Services beschränkt, die ihm vom Gerätehersteller angeboten werden. Auch wenn beispielsweise ausgelieferte Informationen aus dem WWW extrahiert werden, kann hierbei nicht von einer „echten“ Internet-Anbindung gesprochen werden.

Die Anbieter der zahlreichen Pager-Diensten (Telmi, Cityruf, Quix usw.) stellen ihren Benutzern auf diese Art und Weise diverse Informationen zur Verfügung.

2.3.4 Anpassung durch einen Mittler

Wie bereits gesehen, müßte es das Ziel eines intelligenten Ansatzes sein, möglichst viel Logik aus den mobilen Endgeräten herauszunehmen und nur die Daten zu übertragen, die diese auch tatsächlich darstellen können. Daraus ergibt sich, daß diese Entscheidungen nicht innerhalb des Endgerätes vorgenommen werden können. Auch die Anpassung auf Server-Seite ist nur im begrenzten Umfang möglich. Also muß die gewünschte Adaption dazwischen, das heißt im Netz selbst, vorgenommen werden.

Ein derartiger Mittler hat die Aufgabe, die von den Endgeräten unterstützten und die im Internet üblichen Standards abzugleichen. Dabei müssen sowohl die zugrundeliegenden Protokolle wie auch die Dokumente, die darüber übermittelt werden, angepaßt werden. Dazu müssen geeignete, möglichst allgemeine Adaptionsmechanismen gefunden werden. Es ist auch möglich, spezialisierte Mittler, die nur eine Submenge der Endgeräte unterstützen, zu implementieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 14: Adaption durch die Verwendung von Mittlern

Kapitel 1: Kapitel 3: Stand der Technik

In diesem Kapitel werden vorhandene Ansätze betrachtet, um diverse Informationen von mobilen Endgeräte aus zugänglich zu machen. Zuerst werden dabei bestehende Anbindungen an Informationssysteme untersucht, darauf verschiedene Ansätze, mittels Adaption die Zielgruppen vorhandener Informationssysteme zu erweitern. In einem weiteren Schritt werden dann die technischen Möglichkeiten analysiert, um Funk- mit Festnetzen zu verbinden. Abschließend werden Forschungsprojekte vorgestellt, die sich mit mobilen Informationssystemen befassen. Die einzelnen Ansätze werden nach Flexibilität, Abstraktions- und Integrationsgrad bewertet.

3.1 Anbindungen

Im folgenden sollen verschiedene, bereits vorhandene Strategien betrachtet werden, um mobile Endgeräte an multimediale Informationssysteme anzuschließen.

3.1.1 EGate

Mit dem Produkt [Egate98] der Firma ART+COM GmbH wird das Internet über den SMS^[27] -Service der Funktelefone mobil zugänglich gemacht. Eine SMS-Nachricht darf maximal 160 Zeichen lang sein und wird bei abgeschaltetem oder nicht erreichbarem Handy zwischengespeichert. Dadurch ist eine sichere Datenübertragung gewährleistet. Jedes Handy kann auch selbst SMS-Nachrichten abschicken, viele haben eine „Reply“-Funktion, mit der einfach auf eine eingehende Nachricht geantwortet werden kann. Somit ist beim Datenverkehr mit Hilfe von SMS eine bidirektionale Kommunikation möglich. Ein mit dem Internet verbundener Computer kommuniziert über direkt angeschlossene Handys mit anderen Handys via SMS (siehe Abbildung 15).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 15: Abindung per SMS

3.1.1.1 Bereits implementierte Dienste

Im Rahmen der Entwicklung von EGate wurden zahlreiche Dienste für Handy-Besitzer entworfen:

- Email nach SMS und SMS nach Email.
- Mailinglisten
- Abfrage der aktuellen Nachrichtenschlagzeilen
- Abo-Möglichkeit für Schlagzeilen (PUSH-Technologie)
- Abfrage des aktuellen Wetterberichtes
- Taschenrechner-Funktionen
- WWW-Seiten nach SMS

Leider sind keiner näheren Informationen darüber zu erhalten, wie flexibel die Darstellung von Email-Nachrichten und WWW-Seiten gehalten ist.

3.1.1.2 Fazit

Der Vorteil dieses Ansatzes ist, daß die gesamte nötige Infrastruktur zum Versenden und Empfangen von SMS-Nachrichten schon vorhanden ist. Allerdings lassen sich normale WWW-Seiten kaum in 160 Zeichen zusammenfassen. Das bedeutet, daß Dienste wie Nachrichtenschlagzeilen oder Wetterdienste aufbereitet, das heißt adaptiert, werden müssen. Bei EGate wird keine umfassende, allgemeine Adaption der Internet-Inhalte vorgenommen, der Benutzer ist also größtenteils auf die ihm angebotenen Dienste beschränkt. Nicht zuletzt die relativ hohen Gebühren, die von den Netzbetreibern für den SMS-Versand erhobenen werden, führten dazu, daß der Betrieb von EGate im November 1996 eingestellt wurde.

Ein weiteres Problem bei der Kommunikation mit Hilfe von SMS ist die teilweise lange Zeit, die bis zur Auslieferung der Nachricht an das Zielhandy vergeht und die Tatsache, daß die eine oder andere Nachricht verloren geht. Eine Übersicht ist in Tabelle 8 zu sehen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 8: Auslieferungszeit von SMS-Nachrichten

Außerdem gehört die Email-Weiterleitung mittlerweile zum Standard der Netzwerkbetreiber. Auch die Übertragung von Nachrichten per SMS bei speziellen Handys ist heute Stand der Dinge. So werden an die RAN-Handys, die von der gleichnamigen Sportsendung gesponsort werden, automatisch die aktuellen Fußballergebnisse übertragen. Dadurch wird es für Drittanbieter immer schwieriger, sich in diesem Marktsegment zu behaupten.

3.1.2 Smart Messaging

Die von Nokia propagierte Smart-Messaging-Architektur [Nokia97] soll die Fähigkeiten von Mobilfunktelefonen um weitere, nicht sprachbezogene Dienste erweitern. Dabei werden zahlreiche Dienste standardmäßig unterstützt, weitere können jedoch unproblematisch hinzugefügt werden. Diese kommunizieren über NBS (siehe Seite 37), einer Socket-Schicht speziell für schmalbandige Netze. In Abbildung 16 sind die bereits angebotenen Dienste zusammengefaßt. Außerdem ist zu sehen, wie durch den Netzzugriff über NBS die zu Grunde liegende Netze und Protokolle verschleiert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 16: Die Smart-Messaging-Architektur

3.1.2.1 Dienste

Im folgenden werden die einzelnen, per Standard unterstützten Dienste kurz vorgestellt:

Business Cards

Die „Business Cards“ sollen wohl die bisherigen Visitenkarten ersetzten. Dabei können persönliche Daten wie Namen, Adresse, Email-Adresse, Beruf, Telefon- und Faxnummer im Handy gespeichert werden und bei Bedarf an ein anderes, smart-messaging-fähiges Endgerät übermittelt werden.

Service Cards

Service Cards sollen es erleichtern, mit den speziell in den USA üblichen Servicenummern, bei denen der Benutzer via Tastenfeld verschiedene Aktionen auslösen beziehungsweise Informationen abrufen kann, umzugehen. Bei Fluggesellschaften können zum Beispiel auf diese Art Flüge gebucht werden. Muß nun jemand regelmäßig einen Flug zu einem bestimmten Ziel buchen, können auf diesen Service Cards der Name und die Telefonnummer des Dienstes sowie die Zahlenfolgen für verschiedene Menüpunkte gespeichert und bei Bedarf abgerufen werden.

Internet Acces Configuration

Über diesen Service können die mobilen Endgeräte automatisch entsprechend den Anforderungen des Internet-Einwahlpunktes konfiguriert werden. Wird beispielsweise ein Notebook über ein Handy ans Internet angeschlossen, kann der Provider das benutzte Handy richtig konfigurieren.

Calendar

Dieser Dienst basiert auf der vCalendar-Spezifikation, die zum Austausch von Terminen zwischen verschiedenen Terminplanungsprogrammen entwickelt wurde. So können aktuelle Termine, die mit dem Terminplaner auf dem PC festgehalten wurden, auf das Handy transferiert werden. Dieses erinnert den Benutzer dann an einen wahrzunehmenden Termin.

Ringing Tones

Mit diesem Format können Klingelmelodien zwischen verschiedenen Mobiltelefonen ausgetauscht werden. Die „Lieder“ werden durch eine Folge von Zahlen, die Tonhöhe, -länge und -lautstärke der einzelnen Noten angeben, definiert. Schleifen und ähnliches werden nicht unterstützt. Es gibt zwei verschiedene Arten von Klingelmelodien, die übermittelt werden können: „Basic songs“, die im Zielhandy gespeichert werden und dann als Klingelton für eingehende Anrufe benutzt werden können, und „Temponary Songs“, die nach der Übertragung abgespielt und wieder gelöscht werden.

Dynamic Menu Items

Mit Hilfe dieses Dienstes kann die Menüstruktur des Handys verändert werden. Im „Operator Menü“ können die vom Netzbetreiber angebotenen Dienste wie Mailbox und ähnlichem angesprochen werden. Werden neue Dienste vom Netzbetreiber implementiert oder freigeschaltet, können die nötigen Menüeinträge, um diesen Dienst zu nutzen, von diesem direkt in das „Operator Menü“ kopiert werden.

Im „Local Services Menü“ sind lokale Dienste wie Wettervorhersagen, Stauwarnungen und anderes zusammengefaßt. Dieses Menü kann von lokal verteilten Servern aktualisiert werden. Im „Personal Menü“ kann der Benutzer selbst die für ihn interessante Dienste ablegen.

3.1.2.2 Fazit

Sicherlich bietet die Smart-Messaging-Architektur einen gewissen Mehrwert gegenüber der reinen Sprachübertragung, auch wenn vieles eher als Spielerei abgetan werden kann. Vor allem die Tatsache, daß standardmäßig keinerlei direkte Internet-Anbindung vorgesehen ist, läßt dieses Konzept eher als werbewirksame Bindung an einen Hersteller, nämlich Nokia, erscheinen. Dies wird noch durch die Tatsache unterstrichen, daß die Portnummern für Zusatzdienste ausschließlich von Nokia vergeben werden dürfen. Es bleibt abzuwarten, ob Nokia sich dadurch ein Monopol schaffen kann.

3.1.3 HDTP/HDML

Der HDTP/HDML-Standard wurde von der Firma „Unwired Planet“ entworfen und spezifiziert. Im Januar 1998 gegründeten WAP^[28] -Forum [WAP98], dem Mobilfunk-Firmen wie Ericsson, Motorola, Nokia sowie Unwired Planet zugehören, wird dieser Standard weiter entwickelt. Obwohl er schon im Mai 1997 beim World Wide Web Consortium [W3C98] als Standardisierungsvorschlag eingereicht wurde, ist bisher noch keine Ratifizierung erfolgt.

Trotzdem ist das HDTP-Protokoll bereits in der Version 1.1, HDML gar in der Version 2.0 erhältlich. Angesichts der hochrangigen Mitglieder des Konsortiums ist davon auszugehen, daß eine Absegnung durch das W3C in absehbarer Zeit erfolgen wird.

3.1.3.1 Grundlagen

Bei HDML handelt es sich um ein im Funktionsumfang stark reduziertes Pendant zu HTML. In dieser Dokumentensprache sollen Dokumente auf bestehenden, mit HTTP angebundenen, Servern angeboten werden. Die Endgeräteanbindung übernehmen sogenannte UP.Links, die das HTTP-Protokoll auf das einfachere HDTP-Protokoll abbilden. Des weiteren sollen derartige Links die Fähigkeit erhalten, andere Protokolle, wie zum Beispiel SMTP, umzusetzen. HDTP ist in der verwendeten Notation nahezu mit HTTP identisch. Lediglich der Overhead bei einer Anfrage wurde durch binäre Kodierung und Weglassen nicht unbedingt relevanter Informationen stark reduziert.

Innerhalb eines UP.Links wird also lediglich eine Protokolladaption durchgeführt, die Dokumente werden von den Servern bereits im HDML-Format ausgeliefert. Die mobilen Funktelefone müssen nur HDTP/HDML unterstützen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 17: Protokollumsetzung mit einem UP.Link

3.1.3.2 Unterstütze Endgeräte

Für Endgeräte, die mit Hilfe von HDTP/HDML mit dem Internet kommunizieren wollen, gibt es einige Einschränkungen:

- Das Display muß mindestens 12 Zeichen in einer Zeile darstellen können.
- Es muß ein ASCII-Zeichensatz installiert sein.
- Als Minimalanforderung genügt ein Zeichensatz mit fester Breite. Optional kann auch eine Proportionalschrift, fette oder kursive Zeichensätze benutzt werden.
- Der Bildschirmspeicher muß mehrere Zeilen umfassen, durch die bei Nachrichten, die länger als der physikalische Bildschirm sind, vertikal gescrollt werden kann.
- Der SMS- oder ein vergleichbarer Nachrichtendienst muß unterstützt werden. Eingehende beziehungsweise zum Abruf bereitstehende Nachrichten müssen automatisch angezeigt werden (Message Waiting Indicator).
- Neben der Eingabe von Zahlen muß auch die Eingabe von alphanumerischen Werten unterstützt werden.
- Es muß ein Editierfeld zur Eingabe und Manipulation von Daten vorhanden sein.
- Mit der Hilfe von Cursortasten oder dem Zahlenfeld muß aus einer Liste ein bestimmter Eintrag ausgewählt werden können.
- Es muß eine Zurück- und eine Annahmetaste vorhanden sein.
- Eine oder zwei Tasten, die zur Laufzeit beschriftet werden können (Softkeys). Dabei müssen Beschriftungen von fünf oder mehr Zeichen möglich sein.
- Abspeicherung des momentanen Zustandes bei Abschaltung.

Diese Bedingungen werden von den meisten aktuellen Mobiltelefonen erfüllt. Allerdings lassen diese engen Spezifikationen auch kaum Raum für zukünftige Weiterentwicklungen der Geräte. Ein Beispiel, wie ein Display eines derartiges Funktelefons aussehen könnte, ist in gegeben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 18: Display eines UP.Phones

3.1.3.3 Handheld Device Markup Language

HDML, wie es in [Wireless97] spezifiziert wurde, ist speziell zur Darstellung auf Handy-Displays zugeschnitten. Diese sind in der Regel 12-60 Zeichen breit und 3-8 Zeichen hoch. Um auch auf diesen Geräten Informationen anzeigen und Interaktionen mit dem Benutzer durchführen zu können, ist HTML nicht geeignet, da dort von einem großen Display, vielen Eingabetasten und einer Maus ausgegangen wird. Ein einfaches HDML-Dokument hat beispielsweise folgendes Aussehen:

Abbildung in dieser Leseprobe nicht enthalten

Groß- und Kleinschreibung wird bei den HDML-Tags nicht berücksichtigt, allerdings bei etwaigen Variablen. Die kleinste Einheit, die per HDML an ein Telefon gesendet werden kann, ist ein sogenannter „Deck“ – sinngemäß ein Kartenstapel. Dieser besteht aus einer oder mehreren Karten, von der jede eine einzelne Interaktion mit dem Benutzer bestimmt. In der aktuellen Version 2.0 werden folgende Kartentypen unterstützt:

- Entry card Es wird eine Nachricht angezeigt und der Benutzer aufgefordert, einen String einzugeben.
- Choise card Es wird dem Benutzer eine Liste mit verschiedenen Möglichkeiten angegeben. Dieser kann einer von ihnen auswählen.
- Display card Es wird einfach ein Informationstext ausgegeben.
- No-Display card Dieser Kartentyp wird dazu benutzt, Aktionen im Handy auszulösen, ohne daß es im Display angezeigt wird.

Aus den verschiedenen Karten werden komplexere Benutzerinteraktionen konstruiert.

3.1.3.4 Fazit

HDTP/HDML benötigt spezielle Server, die HDML-Dokumente bereitstellen. Der Erfolg dieses Standards hängt von der Anzahl der Server ab, die derartige Dokumente anbieten werden. Da bei den beschränkten Ausgabemöglichkeiten der Mobiltelefone kaum zusätzliche Werbung in die Dokumente eingebaut werden kann, bleibt die Frage offen, welche Motivation ein möglicher Informationsanbieter haben könnte, ein derartiger Service anzubieten. Denn in der Spezifikation ist es nicht vorgesehen, für verschiedene Dienste direkt eine Gebühr erheben zu können. In erster Linie werden wahrscheinlich die einzelnen Handyhersteller und Kartenanbieter ihren Kunden als Werbemaßnahme diverse Informationen anbieten, deren Nutzungsgrad abzuwarten bleibt. Bisher ist keine Adaption von Email-, HTML- oder anderen Diensten auf HDML implementiert. Eine Adaption findet lediglich auf Protokollebene statt. Wie viele und in welcher Qualität die verschiedenen Dienste adaptiert werden können, wird die Akzeptanz eines solchen Services bestimmen.

Ein prinzipielles Problem ist die starke Selbsteinschränkung der HDML-Beschreibungssprache. Sie ist für reine Textdisplays ausgelegt. Auch die Unterstützung von maximal zwei belegbare Benutzertasten wird sich als Achillesferse dieses Systems herausstellen. Die Möglichkeiten heutiger Mobiltelefone mögen mit diesem Standard durchaus ausreizbar sein, für die nächste Handygeneration muß vielleicht schon ein ganz neuer Standard entwickelt werden.

3.1.4 Nokia 9000(i)

Beim Nokia 9000(i) Communicator handelt es sich im Grunde genommen einen Handheld PC, der mit einem Mobilfunktelefon kombiniert wurde. Die standardmäßig mitgelieferte Software ermöglicht die Nutzung der wichtigsten Internet-Diensten wie WWW und Email. Nicht alle HTML-Befehle werden unterstützt, allerdings können die wichtigsten, wie Bilder, Frames oder Tabellen, interpretiert werden. Emails im MIME-Format können ebenfalls über SMTP, IMAP4 und POP3 geladen und verschickt werden. Des weiteren gehört ein Telnet-Client zum Lieferumfang. Der Internetanschluß erfolgt über einen klassischen Provider.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 19: Der Nokia 9000i Communicator

Das größte Manko bei der Internetanbindung ist jedoch, daß keinerlei Adaption der übertragenen Dokumente vorgenommen wird. So sollten HTML-Seiten für den Communicator optimiert vorliegen, um ein adäquates Ergebnis auf dem Display zu erreichen. Das Graustufen-Display mit einer Auflösung vom 640x200 Pixel kann zwar theoretisch beliebig große HTML-Seiten darstellen, jedoch bilden die 2 MB Speicher, die zur Programmausführung zur Verfügung stehen, die Prozessorleistung sowie die Übertragungsgeschwindigkeit von 9600 Bauds weitere Grenzen. Außerdem benötigt der relativ hoch getaktete Prozessor, die 8 MB Speicher sowie das große Display auch dementsprechend viel Energie. Die Online-Zeit wird dadurch auf rund drei Stunden reduziert.

3.2 Adaptionsstrategien/-ansätze

Im folgenden sollen bereits vorhandene Adaptionsstrategien beziehungsweise bestehende Ansätze bezüglich der Anpassung diverser Dokumente auf die Möglichkeiten dedizierter Endgeräte untersucht werden.

3.2.1 HTML-Spracherweiterungen

HTML wurde dafür entwickelt, um Informationen auf relativ leistungsfähigen Endgeräten, sprich PCs, darzustellen. In diesem Szenario sind Randdaten wie Ressourcenverbrauch des Clients, Bandbreite und Darstellungsgröße zweitrangig, bei mobilen Endgeräten sind diese jedoch essentiell. Einige HTML-Spracherweiterungen nehmen sich der heterogener gewordenen Engerätelandschaft und der durch den steigenden Datenverkehr schwindenden Übetragungsraten an. Diese können teilweise dazu benutzt werden, relativ einfach HTML-Dokumente auf mobile Endgeräte zu adaptieren.

3.2.1.1 Der LOWSCR-Tag

Bei einer per IMG-Tag eingefügten Grafik kann zusätzlich eine Grafik angegeben werden, die das gleiche Bild in niedrigerer Qualität wiedergibt. Dabei kann das alternativ Bild in niedrigerer Auflösung oder kleinerer Farbtiefe abgespeichert sein.

Abbildung in dieser Leseprobe nicht enthalten

Diese Zusatzgrafik hat eigentlich den Sinn, eine Art Vorschaugrafik schnell übertragen zu können, während die eigentliche, hochauflösende Grafik erst später geladen wird. Für mobile Endgeräte kann diese Spracherweiterung genutzt werden, indem nur das Bild in niedrigerer Auflösung angefordert wird. Dies trägt der im allgemeinen schmalen Bandbreite der Funkstrecke, der kleinen Displays, der geringen Farbtiefe und des begrenzten Speichers des Endgeräts Rechnung.

3.2.1.2 Cascading Style Sheets

Um das Layout möglichst vom Inhalt eines Dokuments zu lösen, wurde vom W3C als neuer Standard die sogenannten CSS^[29] [Lie96] eingeführt. Bisher wurde jedoch erst die erste Stufe (CSS1) standardisiert, wodurch die Möglichkeiten, Layout-Informationen aus dem eigentlichen Dokument herauszulösen, stark eingeschränkt sind. Bei HTML-Dokumenten ist es beispielsweise möglich, Schriftart, -größe und –farbe für bestimmte Dokumentenabschnitte wie Überschriften oder ähnlichem zu bestimmen, ohne bei jedem Auftreten diese neu festzulegen. Mit der folgenden Anweisung werden Style Sheets an eine HTML-Seite gekoppelt:

Abbildung in dieser Leseprobe nicht enthalten

In der angegebenen Datei können dann bestehenden Tags spezielle Layoutinformationen zugewiesen werden oder neue Tags definiert werden. Soll beispielsweise das Layout der Hauptüberschriften (H1-Tag) definiert werden, würde ein derartiger Eintrag zu finden sein:

H1 {

font-weight: bold;

font-size: 12pt;

line-height: 14pt;

font-family: helvetica;

font-variant: normal;

font-style: normal;

}

Was Style Sheets für die Adaption von HTML-Dokumenten interessant macht, ist die Tatsache, daß der eigentliche Inhalt und sogar die hierarchische Struktur des Dokuments auch ohne diese Layoutinformationen wiedergegeben werden können. Wird das Prinzip der Style Sheets konsequent genutzt, stehen im eigentlichen HTML-Dokument nur noch die (Struktur-)Informationen, alle Informationen, die lediglich das Aussehen der Seite beschreiben, sind abgelöst. Eine derartige HTML-Seite kann ohne Layout-Spezialitäten mit einem relativ einfachen Browser dargestellt werden.

Das Problem dabei ist, daß die Entwickler von HTML-Seiten nicht gezwungen werden, derartige Informationen in externe Style Sheets zu binden. Ein Minimal-Browser kann also dennoch auf Layout-Informationen innerhalb des Dokuments stoßen.

3.2.2 AltaVista’s Sprachadaption

Die Suchmaschine [AltaVista98] der Firma Digital bietet einen Service, HTML-Seiten online zu übersetzen. Die Seiten, die auf eine Suchanfrage angeboten werden, können wahlweise direkt angezeigt oder über AltaVista geladen werden. Wird der Umweg über AltaVista gewählt, kann die gewünschte Seite in eine andere Sprache übersetzt werden. Digitals Server fungiert dabei quasi als ein Mittler, der die HTML-Seiten entsprechend den Bedürfnissen des Benutzers adaptiert.

In Abbildung 20 ist links die originale (englische) TecO-Startseite und deren Übersetzung zu sehen. Wie unschwer zu erkennen ist, läßt die automatische Übersetzung noch ein wenig zu wünschen übrig. Natürlich können Texte, die als Grafik abgespeichert sind, nicht übersetzt werden. Verändert sich die Länge des Textes durch die Übersetzung, paßt sich das Layout durch die in HTML fehlenden absoluten Positionsangaben automatisch an.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 20: Die originale und die adaptierte TecO-Startseite

3.2.3 Realaudio/-video

Das von der Firma RealNetworks [RealNetworks98] entwickelte Realaudio beziehungsweise -video genießt eine weite Verbreitung im Internet. Es handelt sich dabei um ein komplettes System von Browser-Plugin zur Dekodierung auf der Client-Seite, Realaudio/-video-Kodierer auf Server-Seite und einem Protokoll zur Übertragung der Daten. Dieses Protokoll kann sowohl auf UDP^[30], TCP oder HTTP aufsetzten – es ist somit unabhängig von der darunterliegenden Schicht und dadurch ohne größere Probleme auf andere Transportmedien zu adaptieren.

Die Audio- und Videodaten werden als sogenannter Stream hochkomprimiert übertragen, das heißt die Daten müssen nicht zuerst heruntergeladen und dann abgespielt werden. Vielmehr wird die momentane Bandbreite der Verbindung zwischen Client und Server gemessen und die Qualität der Daten (Auflösung, Bildfrequenz, Samplerate usw.) so eingestellt, daß die Daten „on the fly“ übertragen und dargestellt werden können. Der QoS^[31] wird also der Netzwerkkapazität angepaßt. Dadurch wird es auch möglich, Livemedien wie Radio und Fernsehen über das Internet zu übertragen. Audiodaten können bereits mit einem 28,8-Modem in CD-naher Qualität übertragen werden, Vollbildvideo ist ab einer Übertragungsrate von circa 100 Kilobytes pro Sekunde möglich.

Wenn während der Übertragung der Stream abreißt, was durch eine Überlastung des Netzwerkes oder des Servers geschehen kann, ist eine Nachadaption der Übertragungsparameter möglich. So kann der QoS den momentanen Gegebenheiten angepaßt werden.

Da von Desktop-Geräten als Clients ausgegangen wird, werden Dinge wie maximale Videobildgröße oder ähnliches leider nicht berücksichtigt. Für den Bereich Audio/Video stellt die Real-Produktlinie jedoch ein flexibles, selbstadaptierendes System dar, das durch die Protokollunabhängigkeit durchaus für den mobilen Datentransfer erweitert werden könnte.

3.2.4 Konverter

Die immer größer werdende Anzahl der Anwendungssoftware zieht auch eine große Zahl proprietärer Dokumententypen nach sich. Um anwendungsübergreifend Daten austauschen zu können, müssen diese in ein Format umgewandelt werden, das die Zielsoftware verarbeiten kann. Aus diesem Hintergrund heraus haben sich etliche Konvertierungsprogramme entwickelt. Außerdem unterstützen viele Programme mehrere Formate und können mit Hilfe von In- und Exportfiltern Fremdformate laden beziehungsweise speichern. So können beispielsweise Words-Dokumente in HTML oder JPG- in GIF-Bilder umgewandelt werden.

Diese Umwandlungen entsprechen nach dem im Absatz 2.2.4.2 auf Seite 18 definierten Adaptionsmechanismen einer Transformation. Da viele Konvertierungsprogramme kostenlos zu erhalten sind, können diese dazu benutzt werden, die Transformationsadaption zu verwirklichen. Wie in Abbildung 21 zu sehen ist, können mit deren Hilfe auch ganze Transformationsketten realisiert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 21: Transformationskette von HTML über Richtext hin zu ASCII

3.3 Integration

Im folgenden werden verschiedene, vorhandene Ansätze untersucht, um mobile Endgeräte in bestehende Infrastrukturen wie das Internet zu integrieren.

3.3.1 Narrow-Band Socket

Ein Hauptaugenmerk bei dem von Nokia und Intel entwickelten NBS^[32] wurde darauf gelegt, Anwendungsentwicklern eine flexible Programmierschnittstelle zu bieten, die die Eigentümlichkeiten des benutzten Kommunikationskanals verbirgt. Sie wurde als Ergebnis des „Intel’s Mobile Communication Lab“ vorgestellt, daß zu

m Ziel hatte, Intels AOAC^[33] -Vision zu verwirklichen.

[...]

---

^[1] P ersonal D igital A ssistent

^[2] F ile T ransfer P rotocol

^[3] W ord W ide W eb

^[4] R equest f or C omments

^[5] A merican S tandard C ode for I nformation I nterchange

^[6] M ultipurpose I nternet M ail E xtensions

^[7] J oint P hotographic Experts G roup

^[8] G raphics I nterchange F ormat

^[9] T ag(ged) I mage F ile F ormat

^[10] Wav eform

^[11] M oving P icture E xperts G roup

^[12] M usical I nstrument D igital I nterface

^[13] V irtual R eality M odeling L anguage

^[14] H yper t ext T ransfer P rotokoll

^[15] H yper T ext M arkup L anguage

^[16] H ypertext T ransfer R e q uest

^[17] H andheld D evice T ransport P rotokoll

^[18] H andheld D evice M arkup L anguage

^[19] G lobal S ystem for M obiles

^[20] L ocal A rea N etwork

^[21] T ransmission C ontrol P rotokol

^[22] I nternet P rotokol

^[23] R emote P rocedure C all

^[24] U ser I nterface

^[25] z.B. bei HTML durch das ALT-Attribut eines IMG-Tags

^[26] S imple M ail T ansfer P rotokol

^[27] S hort M essgae S ystem

^[28] W ireless A pplication P rotokol

^[29] C ascading S tyle S heets

^[30] U ser D atagram P rotokol

^[31] Q uality o f S ervice

^[32] N arrow- B and S ocket

^[33] A lways O n, A lways C onnected