WAP - noch aktuell? Alternativen?

Werbung
Thema: WAP - noch aktuell? Alternativen?
Vertiefungsarbeit
von
Patrick Schachner
aus Bad Säckingen
BERUFSAKADEMIE LÖRRACH
– STAATLICHE STUDIENAKADEMIE –
UNIVERSITY OF COOPERATIVE EDUCATION
Ausbildungsbereich Wirtschaft
Betreuende(r) Dozent(-in):
Abgabetermin:
Kurs:
Fachrichtung
Unternehmen
Prof. Gerhard Staib
(Datum)
WWI 01 B
(Fach)
Sedus Stoll AG
Ehrenwörtliche Erklärung
Ich versichere hiermit, dass ich meine Vertiefungsarbeit mit dem Thema
WAP - noch aktuell? Alternativen?
selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt
habe.
(Ort, Datum)
(Unterschrift)
WAP - noch aktuell? Alternativen? 2
Kurzfassung
Ziel der Kurzfassung ist es, einen (eiligen) Leser zu informieren, so dass dieser entscheiden
kann, ob die Arbeit für ihn hilfreich ist oder nicht (neudeutsch: Management Summary). Die
Kurzfassung gibt daher eine kurze Darstellung

des in der Arbeit angegangenen Problems

der verwendeten Methode(n)

des in der Arbeit erzielten Fortschritts.
Dabei sollte nicht auf die Struktur der Arbeit eingegangen werden, also Kapitel 2 etc. denn die
Kurzfassung soll ja gerade das Wichtigste der Arbeit vermitteln, ohne dass diese gelesen werden
muss. Eine Kapitelbezogene Darstellung sollte sich in Kapitel 1 unter Vorgehen befinden.
Länge: Maximal 1 Seite.
WAP - noch aktuell? Alternativen? 3
Inhaltsverzeichnis
Seite
Ehrenwörtliche Erklärung ...................................................................................2
Kurzfassung.........................................................................................................3
Abkürzungsverzeichnis ......................................................................................6
Abbildungsverzeichnis .......................................................................................7
Tabellenverzeichnis.............................................................................................8
Anlagenverzeichnis .............................................................................................9
1
Einleitung...................................................................................................10
1.1
1.2
1.3
1.4
Boom in der Informationstechnologie.............................................................. 10
Entwicklung der Mobiltelefonbranche ............................................................. 10
Entwicklung der Mobilkommunikation .............................................................. 11
Wozu existiert WAP? ......................................................................................... 12
2
Grundlagen ................................................................................................13
3
Problemanalyse ........................................................................................14
3.1
Wie kann Mobilkommunikation sinnvoll erfolgen? ......................................... 14
4
mögliche Lösungsansätze .......................................................................16
4.1
WAP ................................................................................................................. 16
4.1.1 grundlegende Architektur.......................................................................... 16
4.1.2 Schichtenmodell im Detail ........................................................................ 19
4.1.2.1
4.1.2.2
4.1.2.3
4.1.2.4
4.1.2.5
WDP - Wireless Datagram Protocol ........................................................................ 19
WTLS Wireless Transport Layer Security ............................................................... 20
WTP - Wireless Transaction Protocol ..................................................................... 21
WSP - Wireless Session Protocol ........................................................................... 25
WAE - Wireless Application Environment ............................................................... 32
4.1.3 WAP 2.0 ................................................................................................... 34
4.1.3.1
4.1.3.2
4.1.3.3
4.1.3.4
neuer Protocol - Stack ............................................................................................. 34
WML 2 34
Push - Architektur .................................................................................................... 34
Fazit zu WAP 2.0 ..................................................................................................... 36
4.1.4 WAP kritisch betrachtet ............................... Error! Bookmark not defined.
WAP - noch aktuell? Alternativen? 4
4.2
Alternative I - Mode............................................................................................ 36
5
Fazit und Ausblick ....................................................................................38
5.1
5.2
Fazit ................................................................................................................. 38
Ausblick ............................................................................................................. 38
Quellenverzeichnis ............................................................................................40
Stichwortverzeichnis.........................................................................................42
Anhang ...............................................................................................................44
WAP - noch aktuell? Alternativen? 5
Abkürzungsverzeichnis
Abkz.
Erläuterung der Abkürzung
WAP - noch aktuell? Alternativen? 6
Abbildungsverzeichnis
Seite
Abbildung 1: grundlegende WAP Architektur und Komponenten ................................. 17
Abbildung 2: WAP - Schichtenmodell .......................................................................... 18
Abbildung 3: WDP - Dienstprimitiv .............................................................................. 19
Abbildung 4: Aufbau einer sicheren Sitzung mit WTLS ............................................... 20
Abbildung 5: WTLS - Datagrammübertragung ............................................................ 21
Abbildung 6: Einfache Transaktion in der WTP - Klasse 0........................................... 22
Abbildung 7: Transaktion in der WTP - Klasse 1 ohne Nutzerbestätigung ................... 23
Abbildung 8: Transaktion in der WTP - Klasse 1 mit einer Bestätigung durch einen
Nutzer ................................................................................................... 23
Abbildung 9: Transaktion in der WTP - Klasse 2 ohne Nutzerbestätigung ................... 24
Abbildung 10: WTP - Klasse - 2 Transaktion mit einer Bestätigung durch einen
Nutzer ................................................................................................... 24
Abbildung 11: Transaktion in der WTP - Klasse 2 mit Halten des Initiators .................. 25
Abbildung 12: WSP/B Sitzungsaufbau ........................................................................ 27
Abbildung 13: Parken und Wiederaufnehmen einer Sitzung ....................................... 28
Abbildung 14: Beenden einer WSP/B - Sitzung........................................................... 28
Abbildung 15: unbestätigter Push - Dienst in WSP/B .................................................. 29
Abbildung 16: bestätigter Push - Dienst in WSP/B ...................................................... 29
Abbildung 17: Methodenaufruf als Beispiel für eine vollständige WTP - Klasse - 2 Transaktion ........................................................................................... 30
Abbildung 18: Nutzung von WTP als unterliegende Schicht durch WSP ..................... 30
Abbildung 19: asynchrone, ungeordnete WSP/B - Anfragen ....................................... 31
Abbildung 20: WSP/B als unbestätigter Sitzungsdienst mit WDP als Grundlage ......... 32
Abbildung 21: WAP - Push - Architektur mit Gateway ................................................. 35
WAP - noch aktuell? Alternativen? 7
Tabellenverzeichnis
Seite
Tabelle 1: Formen des Zusammenwirkens von PersonenError! Bookmark not defined.
WAP - noch aktuell? Alternativen? 8
Anlagenverzeichnis
Seite
Anlage 1: Konstruktive und kritisch-analytische ProblemstellungenError! Bookmark not defined.
Anlage 2: Zeichnungen und Grafiken ............................ Error! Bookmark not defined.
Anlage 3: Literaturzitate ............................................................................................. 45
Anlage 4: Ändern der Fußzeile ...................................... Error! Bookmark not defined.
WAP - noch aktuell? Alternativen? 9
1 Einleitung
Um ein besseres Verständnis für heutige Entwicklungen und Mobilkommunikationslösungen zu
erreichen. möchte ich in den folgenden Abschnitten zunächst einmal einen kurzen Überblick
über die Entwicklung der Informationstechnologie und der Mobilkommunikation geben.
Bei meinem Überblick möchte ich mich auf die Entwicklungen des letzten halben Jahrhunderts
beschränken. Ich werde nicht bis an die ersten Anfänge der Kommunikation mittels erster
Telegrafen und Telefone zurückgehen.
1.1
Boom in der Informationstechnologie
Seit der Begründung des Internets in den 60er Jahren fand ein regelrechter Boom in der
Informationstechnologie statt. In den letzten 10 Jahren haben sich etwa alle 1,5 Jahre die Anzahl
der Hosts im Internet verdoppelt. In der heutigen Zeit kann es sich kaum ein Unternehmen
leisten keinen Internetauftritt zu haben. Darüber hinaus gehört eine E-Mail-Adresse heutzutage
bereits zu den Standards in einer Anschrift. Das Internet ermöglicht dem einzelnen Benutzer eine
Vielzahl an Möglichkeiten und Funktionen, wie beispielsweise das Kommunizieren mit anderen
Benutzern, Daten untereinander auszutauschen, einzukaufen, oder sich einfach nur zu
informieren.
1.2
Entwicklung der Mobiltelefonbranche
Wohl mit unter den ersten Entwicklungen im Bereich der Mobilkommunikation war das Handy.
Bereits im Jahr 1958 wurde in Deutschland das A - Netz aktiviert, das auf einer Frequenz von
160 MHz arbeitete. 1971 hatte es eine Flächenabdeckung von etwa 80 Prozent und ungefähr
11.000 Mobilfunkkunden. Das A - Netz war bis ins Jahr 1977 aktiv. Im Jahr 1972 folgte dann die
erste Weiterentwicklung mit dem B - Netz. Dieses arbeitete ebenfalls auf 160 MHz wobei jetzt
schon eine Weiterleitung eines Festnetzgesprächs auf ein Handy möglich war, wenn der Standort
des Mobilfunkgerätes bekannt war. 1979 hatte das B - Netz etwa 13.000 Kunden, 1985 bereits
25.000. Hier muss aber noch erwähnt werden, dass die meisten dieser Mobilfunkgeräte in Autos
montiert waren, da die Sender und Empfänger noch sehr schwer und groß waren. Abgeschaltet
wurde das B - Netz im Jahr 1994. Ungefähr gleichzeitig mit der Entwicklung des B - Netzes in
Deutschland einigten sich die skandinavischen Länder Dänemark, Norwegen, Schweden und
Finnland auf das einheitliche Nordic-Mobile-Telephone - (NMT -) System. Dieses nutzte zu
Beginn einen Träger von 450 MHz, ein NMT - Netz auf 900 MHz folgte 1986.
WAP - noch aktuell? Alternativen? 10
Im Hinblick auf die EU wollten die europäischen Länder ab 1982 einen paneuropäischen
Mobilfunkstandard entwickeln. Dieser sollte bei einer Frequenz von 900 MHz arbeiten und
Roaming über verschiedene Funkzellen ermöglichen. Außerdem sollte es sich bei dem neuen
Standard um eine vollkommen digitale Lösung handeln, die sowohl Sprach- als auch
Datendienste zur Verfügung stellen sollte. Zu diesem Zweck wurde die GSM (Groupe Spéciale
Mobile) gegründet.
Zwischenzeitlich wurde in Deutschland im Jahr 1984 das neue C - Netz entwickelt, das bis zum
31.12.2000 noch im Betrieb war. Es hatte eine Flächenabdeckung von nahezu 100 Prozent und
eine Gesprächsübergabe zwischen verschieden Funkzellen war bereits möglich. 1991 wurde
dann der GSM - Standard verabschiedet, der über 5000 Seiten umfasste. Er nutzt eine Frequenz
von 900 MHz und stellt 124 Vollduplexkanäle zur Verfügung. Der Standard bietet internationales
Roaming, automatische Teilnehmerlokalisierung, Teilnehmer- und Geräteauthentifizierung,
Datenverschlüsselung, SMS - und FAX - Dienste, sowie weitere Dienste. Der Standard war noch
nicht für eine übermäßig hohe Teilnehmerdichte ausgelegt, weshalb dann später zusätzlich ein
GSM - Standard im Frequenzbereich von 1800 MHz verabschiedet wurde, und noch später ein
weiterer im Bereich von 1900 MHz für die USA. Heute steht die Abkürzung GSM für Global
System for Mobile Communications.
Im Bezug auf die USA kann an dieser Stelle noch folgender Satz hinzugefügt werden: Der
Vorteil in der Mobilfunkbranche, den Europa noch heute vor den USA besitzt, beruht darauf,
dass die Europäer in der Entwicklung des Mobilfunks auf Standards gesetzt haben, während die
USA sich auf die Marktkräfte verlassen haben, was zur Folge hat, dass die USA noch heute mit
uneinheitlichen Mobilfunklösungen leben und arbeiten muss.
1.3
Entwicklung der Mobilkommunikation
Auch im Bereich der Mobilkommunikation fand eine rasante Entwicklung statt. So sind die
ersten Prototypen aus allen Bereichen der Mobilkommunikation kaum noch mit den heutigen
Mobilgeräten vergleichbar. Der Fortschritt ist ganz besonders deutlich an Größe, Gewicht und
Funktionsumfang der mobilen Endgeräte zu bemerken.
Die Informationsbereitstellung und -beschaffung, sowie die Kommunikation bekam einen immer
höheren Stellenwert nicht nur im kommerziellen Bereich. Man sollte zu jeder Tages- und
Nachtzeit und an jedem Standort erreichbar sein. Diese Anforderungen wurden zuerst von den
Mobiltelefonen abgedeckt.
Mobiltelefone bedeuteten von Beginn an direkte Erreichbarkeit und schnellere, flexiblere
Kommunikation. Auch wenn die physikalischen Distanzen zwischen zwei Gesprächsteilnehmern
nahezu beliebig groß werden, schaffen Handys eine virtuelle Nähe zum Gesprächspartner. Mit
der Voicebox, deren Idee vom Internet und E-Mail Verkehr übernommen wurde, kam eine
Möglichkeit der asynchronen Kommunikation hinzu. Eine weitere Neuerung war dann der SMS
- (Short Message Service) Dienst. Hierdurch wurde ebenfalls eine Möglichkeit zur asynchronen
Kommunikation geschaffen, bei der aber die Nachrichten im Gegensatz zur Voicebox
emotionslos übertragen werden, da keine Übertragung der Stimme mit ihren Emotionen
stattfindet. Darüber hinaus besteht die Möglichkeit, die Nachrichten zu kontrollieren und
abzuändern, bevor sie übermittelt werden. Mit einem integrierten Adressbuch, also der
Möglichkeit Telefonnummer abzuspeichern kamen dann erste Organizerfunktionen hinzu. In
neuester Zeit geht der Trend bei Handys zur Personalisierung und Individualisierung der Geräte.
WAP - noch aktuell? Alternativen? 11
Man stattet die Geräte mit neuen Klingeltönen, Logos, Bildschirmschonern, etc aus, um im
Besitz eines einzigartigen Handys zu sein.
Parallel zu den Mobiltelefonen entwickelten sich tragbare Computer, die auch als Laptops oder
Notebooks bezeichnet werden. Das erste Gerät dieser Art kam mit dem Osborne - 1 von Osborne
Computer Corporation im Jahr 1981 auf den Markt. Es war auch gleichzeitig der erste Computer,
der ein Softwarepaket im Kaufpreis inbegriffen hatte. Allerdings ist er mit heutigen Laptops
absolut nicht mehr zu vergleichen: Der Osborne - 1 hatte beispielsweise ein 5´´ großes Display,
war etwa so groß wie ein Koffer und wog über 10 Kilogramm.
Anfang der 90er Jahre begann sich mit dem PDA (Personal Digital Assistent) oder Handheld
noch ein weiteres mobiles Gerät zu entwickeln und auf dem Markt zu verbreiten. Das erste Gerät
war 1992 mit dem Newton von Apple auf dem Markt. Zu den Grundfunktionen dieser Geräte
zählen hauptsächlich die Organizerfunktionen, wie beispielsweise Adressbuch, Terminkalender,
Notizen, Merkzettel, etc. Später kamen dann Internet-Browser, E-Mail - Reader und
Dokumenten - Reader zu den Standardfunktionen hinzu. Diese mobilen Geräte, die von der
Größe zwischen einem Laptop und einem Handy liegen, haben einige wesentliche Vorteile:
Durch ihren reduzierten Umfang sind sie genau auf die Bedürfnisse der mobilen Benutzer
zugeschnitten. Sie können schneller booten und haben eine höhere Laufzeit, da Sie sich nach
einer bestimmten Zeit der Inaktivität selbst abschalten. Im Vergleich zu Laptops sind PDAs
kleiner und können so bequem in der Hosentasche mitgeführt werden. Auch ein großer Vorteil ist
die einfache Bedienung, die meist mit einem Stift direkt über das Display erfolgt.
1.4
Wozu existiert WAP?
Die parallel laufenden rasanten Entwicklungen in der Informations- und der
Mobilkommunikationstechnologien hat auch sehr schnell das Verlangen nach einer Verknüpfung
der beiden Technologien geweckt. Dadurch ausgelöst wurde ein Bedarf an mobilen Endgeräten,
mit denen es möglich ist die zur Verfügung stehenden Daten und Informationen auch mobil und
ohne Kabel abzurufen und zu verwenden.
Zunächst einmal ist völlig klar, dass das einzige relevante Datennetz sowohl für wireline - als
auch für wireless - Benutzer das Internet darstellt. Das heißt, es wird selbstverständlich kein
neues, eigenständiges Datennetz speziell für den drahtlosen mobilen Zugriff aufgebaut werden.
Das bedeutet wiederum, dass einige Anpassungen beispielsweise an den Inhalten oder den
Übertragungsprotokollen vorgenommen werden müssen.
WAP - noch aktuell? Alternativen? 12
2 Grundlagen
An dieser Stelle möchte ich die nötigen Grundlagen erläutern, die wir benötigen um die
Technologien zu verstehen, die in den späteren Kapiteln beschrieben werden. Zu diesen
Grundlagen zähle ich vor allem sämtliche mögliche Trägerdienst, auf denen WAP operieren
kann, wie beispielsweise GSM, GPRS oder HSCSD.
WAP - noch aktuell? Alternativen? 13
3 Problemanalyse
In der heutigen Zeit, in der Informationen und Kommunikationen für Unternehmen immer
wichtiger werden und Begriffe wie E-Commerce oder M-Commerce in aller Munde sind, stellt
sich sehr schnell die Frage: Wie kann eine mobile Kommunikation / Information sinnvoll
erfolgen?
3.1
Wie kann Mobilkommunikation sinnvoll erfolgen?
Die größten Probleme im Bereich der mobilen Kommunikation stellen die Datenübertragung, die
Darstellung der Inhalte und der eingeschränkte Funktionsumfang der mobilen Endgeräte dar.
Das wohl größte Hindernis auf dem Weg der mobilen Geräte ins Internet ist die Übertragung der
Daten aus dem Festnetz in das drahtlose Netz. Die Internetstandards wie beispielsweise HTTP,
HTML oder SSL sind hierfür nicht geeignet: Diese Standards wurden ausschließlich für
Festnetzanbindungen geschaffen, die Datenübertragung erfolgt in Textform und außerdem sind
die Bandbreiten im wireless - Umfeld zu gering und werden auch in naher Zukunft nicht
ausreichend wachsen.
Aber auch wenn die Datenübertragung realisiert werden könnte, gibt es immer noch das Problem
mit der Darstellung der Inhalte auf den mobilen Geräten. Noch lange nicht haben alle Geräte ein
Farbdisplay mit einer ausreichenden Farbtiefe, und außerdem sind die Displays mit ihren
wenigen Quadratzentimetern viel zu klein, um beispielsweise eine Homepage sinnvoll darstellen
zu können. So kann von einer Homepage mit 800 x 600 Pixel etwa 1 - 2 Prozent dargestellt
werden. Aber eine wesentliche Vergrößerung der Displays ist ausgeschlossen, da die mobilen
Endgeräte ja weiterhin handlich klein bleiben sollen. Darüber hinaus ist eine einfache
Benutzerführung im Internet auf einem Handy ohne Maus oder großzügige Tastatur nur schwer
vorstellbar.
Ebenfalls einen Nachteil stellt der eingeschränkte Funktionsumfang dar, der zuvor aber auch als
Vorteil dargestellt wurde. Bei einer um etwa 90 Prozent beschränkten Hardware gegenüber
einem Standrechner ist es völlig undenkbar, eine Software zu entwickeln, die einen ähnlichen
Browserumfang wie ein PC bietet.
WAP - noch aktuell? Alternativen? 14
Um diese Probleme der Mobilkommunikation zu überwinden, können heutzutage Techniken wie
I-Mode oder WAP eingesetzt werden.
WAP - noch aktuell? Alternativen? 15
4 mögliche Lösungsansätze
Aufgrund der enormen Expansion des Internet und des raschen Wachstums an Anwendungen im
Internet und im Bereich der Mobilkommunikation, wuchs auch die Vielzahl an proprietären
Lösungen für einen mobilen, drahtlosen Internetzugang sehr schnell an. Um das Wachstum
dieser untereinander inkompatiblen Insellösungen einzudämmen, gründeten Ericsson, Motorola,
Nokia und Unwired Planet (das heutige Phone.com) im Juni 1997 das Wireless Application
Protocol Forum (WAP Forum). Das zweite Lösungskonzept auf das ich im Folgenden noch kurz
eingehen will ist I - Mode. I - Mode ist ein noch relativ neuer Standard, der 1999 von der
japanischen Firma NTT DoCoMo entwickelt wurde. In Deutschland gibt es I- Mode seit Anfang
2002 und wird bisher nur von vier verschiedenen Unternehmen, untern anderem von E-Plus
vertrieben.
4.1
WAP
Die grundlegenden Dienste von WAP umfassen die Bereitstellung von Internetinhalten und
anderen Datendiensten, beispielsweise das Abrufen von Verkehrsmeldungen oder Börsenkursen,
auf mobile Endgeräte wie Handys, PDAs oder Laptops.
Das WAP-Forum versuchte mit WAP ein Protokoll zu verabschieden, das auf sämtlichen
Netztechniken wie GSM, GPRS oder UMTS operieren kann.
4.1.1
grundlegende Architektur
In der WAP - Architektur gibt es eine Vielzahl an Spezifikationen und Standards, die
ursprünglich auf Internetstandards basierten. Durch die Anpassungen und Abänderungen der
Spezifikationen unterscheiden sich diese aber sehr von den heutigen Internetstandards wie
beispielsweise HTML oder HTTP.
Im Internet gibt es die Client - Server - Architektur mit dem recht einfachen Prinzip der Requests
und Responses. Die Inhalte liegen in Form von HTML - Dokumenten auf einem Webserver. Um
Internetinhalte auf einem Client anzuzeigen schickt dieser eine Anfrage (Request) an den Server.
Dieser behandelt die Anfrage und sendet eine Antwort (Response) mit den anzuzeigenden
Inhalten an den Client zurück. Ob es sich bei den Inhalten um statische oder dynamisch erstellte
Informationen handelt, spielt für den anfragenden Client keine Rolle. Nachdem dieser seinen
Request gesendet hat wartet er nur noch auf die Response de Servers.
WAP - noch aktuell? Alternativen? 16
In Abbildung 1 können wir die grundlegende Architektur von WAP erkennen, die derjenigen
vom Internet grundsätzlich nicht unähnlich ist. In der WAP - Architektur liegen die Inhalte zwar
ebenfalls auf Webservern, jedoch ist zwischen diesen und den mobilen WAP - Clients noch ein
Gateway zwischengeschaltet. Der WAP - Client sendet seinen Request an den Gateway, der
diesen dann in HTTP übersetzt, damit der Webserver etwas damit anfangen kann. Der Webserver
behandelt die Anfrage dann wie gewohnt.
Um die auf HTML basierenden Inhalte auch auf den WAP - Browsern der mobilen Endgeräte
darstellen zu können, wurde in WAP mit WML (wireless markup language) eine eigene
Beschreibungssprache entwickelt. Die Inhalte können nun entweder im HTML - oder im WML Format auf den Servern zur Verfügung stehen. Liegen die Inhalte bereits in WML vor, so kann
der Server diese direkt an das Gateway senden, der die Daten dann in binäre WML Daten
umsetzt, damit sie effizienter über die drahtlose Strecke übertragen werden können. Stehen die
angefragten Daten auf dem Webserver nicht im WML - Format zur Verfügung, so müssen die auf
HTML basierenden Inhalte zuerst von speziellen Programmen im Festnetz (Filter) in das WML Format übersetzt werden. Diese Filterprogramme können entweder eigenständig im Festnetz
oder direkt in den Gateways integriert sein.
Abbildung 1: grundlegende WAP Architektur und Komponenten
WAP arbeitet wie auch andere Netzwerkprotokolle schichtenförmig. Dieses ist in Abbildung 2
dargestellt. Jede der fünf Schichten von WAP stellt der darüber liegenden Schicht an einer
Schnittstelle, einem so genannten Dienstzugangspunkt, bestimmte Dienste und Funktionen zur
Verfügung. An dieser Stelle soll zur Architekturbeschreibung nur ein kurzer Überblick über die
einzelnen Schichten gegeben werden. Im Detail wird das Schichtenmodell im Kapitel 4.1.2
behandelt.
WAP - noch aktuell? Alternativen? 17
Abbildung 2: WAP - Schichtenmodell
Als Grundlage für die mobile Datenübertragung dienen verschiedene Trägerdienste, so genannte
Bearers. WAP ist nicht speziell auf einen Trägerdienst zugeschnitten, sondern will vielmehr die
bereits vorhandenen Dienste nutzen und zukünftige Entwicklungen integrieren. Unterstützt
werden nachrichtenvermittelte Dienste wie SMS in GSM, leitungsvermittelte Dienste wie
HSCSD in GSM oder paketvermittelte Dienste wie beispielsweise GPRS in GSM.
Die unterste Schicht, die Transportschicht, arbeitet mit WDP (wireless datagram protocol) und
dient als Verbindung zwischen den Bearers und den darüber liegenden Schichten. Man könnte
diese Schicht also als Schnittstelle zwischen dem Protokoll und den physikalischen Schichten
betrachten. Sie stellt Ihre Dienste den darüber liegenden Diensten am Dienstzugangspunkt T SAP (Transport Layer Service Access Point) zur Verfügung.
Über der Transportschicht liegt die Sicherheitsschicht, die für die sichere Übertragung der Daten
zuständig ist. Sie arbeitet mit WTLS (wireless transport layer security), das auf TLS, dem
Nachfolger von SSL, basiert. WTLS ist für Datenintegrität, Authentifizierung, Abwehr von
Denial-of-Service - Attacken und ähnlichem zuständig. Die Schnittstelle zu den höheren
Schichten ist der SEC - SAP (Security Service Access Point).
Die nächst höhere Schicht ist die Transaktionsschicht, die mittels WTP (wireless transaction
protocol) drei Transaktionsdienste zur Verfügung stellt: unzuverlässige Einweg - Requests,
zuverlässige Einweg - Requests und zuverlässige Zweiwege - Requests. Der Dienstzugangspunkt
auf dieser Schicht ist der TR - SAP (Transaction Service Access Point) und verbindet die
Transaktionsschicht mit der darüber liegenden Sitzungsschicht.
Diese Sitzungsschicht stellt über WSP (wireless session protocol) der nächst höheren Schicht
verbindungslose und verbindungsorientierte Dienste an der Schnittstelle S - SAP (Session
Service Access Point) zur Verfügung.
Die oberste Schicht ist die Anwendungsschicht, mit ihren wichtigsten Komponenten WML und
WML - Script. Die WAE (wireless applicatin environment)hat die Bereitstellung einer
plattformunabhängigen Umgebung zur Aufgabe, auf der verschieden mobile Geräte miteinander
kommunizieren können. Der Dienstzugangspunkt auf dieser Schicht ist der A - SAP (Application
Service Access Point).
WAP - noch aktuell? Alternativen? 18
4.1.2
Schichtenmodell im Detail
Die grundsätzlichen Funktionen der verschiedenen Schichten wurden weiter oben bereits kurz
angesprochen. In den folgenden Abschnitten sollen die jeweiligen Protokolle der fünf oben
bereits genannten Schichten beschrieben werden.
4.1.2.1
WDP - Wireless Datagram Protocol
WDP arbeitet wie bereits erwähnt mit mehreren verschiedenen Trägerdiensten und stellt den
höheren Schichten mit dem T-SAP (Transport Layer Service Access Point) trotzdem einen
einheitlichen Dienstzugangspunkt zur Verfügung. Der Aufwand für die Anpassungen in dieser
Schicht hängt stark vom genutzten Dienst ab. Je ähnlicher dieser IP (Internet Protocol) ist, desto
geringer ist der zu betreibende Aufwand um die nötigen Anpassungen vorzunehmen. Bietet der
Trägerdienst bereits selbst IP - Dienste an wie beispielsweise GPRS, so kann direkt UDP (User
Datagram Protocol) als WDP genutzt werden. hieraus ist bereits deutlich zu erkennen, dass WDP
prinzipiell die gleichen Dienste anbietet, wie es UDP in der Transportschicht des OSI Schichtenmodells tut.
Abbildung 3: WDP - Dienstprimitiv
Wie in obiger Abbildung 3 sichtbar, werden die Nutzdaten (UD - User Data) in WDP mittels
eines Dienstprimitivs mit der Bezeichnung „T-DUnitdata.req“ übermittelt. Verpflichtende
Parameter in diesem Request sind die Nutzdaten UD, Zieladresse DA (Destination Address) und
Zielport DP (Destinantion Port), sowie Quelladresse SA (Source Address) und Quellport SP
(Source Port). Die Adressen müssen eindeutig identifizierbar sein und können beispielsweise als
MSISDNs (Mobile Suscriber ISDN Number) oder als IP - Adressen vorliegen. Das
entsprechende Dienstprimitiv „TDUnitdata.ind“ meldet den Empfang der Daten, wobei die
beiden Parameter Zieladresse und -port optional sind.
Konnte der Dienst nicht erfüllt werden, d.h. das Primitiv konnte nicht übermittelt werden, steht
in WDP mit „TDError.ind“ noch ein Dienstprimitiv zur Verfügung, mit dem den höheren
Schichten mitgeteilt werden kann, dass ein angeforderter Dienst nicht erfüllt werden konnte. Im
einzigen Parameter EC (Error Code) wird die Ursache für den Fehler übermittelt. Dieses Primitiv
kann aber nicht dazu verwendet werden, um auf Probleme mit dem verwendeten Trägerdienst
hinzuweisen. Hierfür steht in der Transportschicht mit WCMP (Wireless Control Message
Protocol) noch ein weiteres Protokoll zur Verfügung. Typische Fehlermeldungen dieser Art sind
beispielsweise „Empfänger nicht erreichbar“ oder „Parameterproblem“, also zuwenig oder zuviel
Parameter im Paketkopf. WCMP basiert auf ICMP (Internet Control Message Protocol), wobei
WAP - noch aktuell? Alternativen? 19
auch hier direkt ICMP als WCMP verwendet werden kann, falls der genutzte Trägerdienst bereits
IP - Dienste unterstützt.
4.1.2.2
WTLS Wireless Transport Layer Security
In der Sicherungsschicht kann mit Hilfe von WTLS ein Sicherheitsdienst angeboten werden,
sofern dies von einem Programm angefordert wird. Das bedeutet im Umkehrschluss natürlich,
dass dieser Dienst optional ist. Es kann also auch sein, dass die Sicherungsschicht übersprungen
wird und Anwendungen von höheren Schichten direkt auf die Transportschicht zugreifen.
WTLS basiert grundsätzlich auf den Funktionen von TLS (Transport Layer Security), dem
Nachfolger von SSL (Secure Sockets Layer), der Protokollablauf zwischen den Instanzen wurde
jedoch für die Mobilübertragung optimiert. Bei der Entwicklung von WTLS wurde besonders
auf die niedrigen Datenraten und höheren Verzögerungszeiten bei der Übertragung geachtet.
Ebenfalls beachtet wurde, dass die Endgeräte eventuell nur schwache Prozessoren und begrenzte
Speicherkapazitäten besitzen, die für die kryptographischen Algorithmen benötigt werden.
Bevor über WTLS Nutzdaten ausgetauscht werden können, muss zunächst eine gesicherte
Verbindung zwischen dem Initiator und seinem Kommunikationspartner aufgebaut werden, was
über mehrere Schritte geschieht. Diese werden in Abbildung 4 dargestellt.
Abbildung 4: Aufbau einer sicheren Sitzung mit WTLS
Als erstes wird durch das Dienstprimitiv „SEC-Create.req“ eine Sitzung vom Initiator erstellt.
Dieses Primitiv enthält die Parameter Quelladresse und -port, Zieladresse und -port, sowie drei
weitere Parameter für die Sicherheitsprotokolle. Diese sind im Einzelnen das
Schlüsselaustauschverfahren KES (Keys Exchange Suite) wie beispielsweise RSA, das
Chiffrierverfahren CS (Cipher Suite) wie z.B. DES (Digital Encrypton Standard), sowie ein
Kompressionsverfahren CM (Compression Method). Auf diesen Request antwortet der
Kommunikationspartner mit dem Primitiv „SEC-Create.res“, das die Parameter Sequence
Number Mode SNM, den Schlüsselerneuerungszyklus KR (Key Refresh), die Sitzungskennung
SID (Session Identifier) und die ausgewählten Schlüsselaustauschverfahren KES,
Chiffrierverfahren CS und Kompressionsmethode CM enthält. Zusätzlich zu dieser Response
sendet der Kommunikationspartner das Dienstprimitiv „SEC-Exchange.req“, mit dem er dem
Initiator mitteilt, dass er eine Authentifizierung mit öffentlichem Schlüssel durchführen möchte
WAP - noch aktuell? Alternativen? 20
und gleichzeitig ein Zertifikat CC (Client Certificate) anfordert. Im letzten Schritt sendet der
Initiator das angeforderte Zertifikat mittels des Primitivs „SEC-Exchange.res“ als Parameter und
sendet gleichzeitig noch das Dienstprimitiv „SEC-Commit.req“ mit dem er dem
Kommunikationspartner anzeigt, dass der Austausch von Parametern nun beendet ist und er in
die eben ausgehandelte Verbindung überwechseln möchte. Somit ist der Aufbau der
abgesicherten Verbindung abgeschlossen.
Nachdem die gesicherte Verbindung zwischen dem Initiator und seinem Kommunikationspartner
aufgebaut wurde, lassen sich Nutzdaten sehr einfach mit Hilfe des Dienstprimitivs „SECUnitdata.req“ ausgetauscht werden. Diese Funktion ist identisch mit dem Primitiv „TDUnitdata.req“ in WDP und ist ebenfalls noch eine unzuverlässige Datenübertragung, da keine
Rückmeldung über den Erhalt der Daten erfolgt. Lediglich ein Mitlesen von Außen wird jetzt
durch die gesicherte Verbindung verhindert. Der sichere Datenaustausch wird in Abbildung 5
dargestellt.
Abbildung 5: WTLS - Datagrammübertragung
An dieser Stelle sollte noch erwähnt werden, das die Sicherheit, die durch die abgesicherte
Verbindung von WTLS hergestellt wird lediglich ein gewisses Grundmaß bieten kann jedoch auf
keinen Fall eine absolute Sicherheit. Denn es ist natürlich klar, dass bei der relativ geringen
Leistungsfähigkeit der mobilen Endgeräte eine Verschlüsselung nicht besonders stark sein kann.
4.1.2.3
WTP - Wireless Transaction Protocol
WTP setzt entweder direkt auf WDP auf, oder falls eine sichere Verbindung gewünscht wird auf
WTLS. Das transaktionsorientierte Protokoll wurde speziell dafür entwickelt, auch auf weniger
leistungsstarken Geräten wie beispielsweise Handys zu laufen. WTP ist in der Lage mehrere
Dienste für die höherne Schichten anzubieten: Datenübertragung mit erhöhter Zuverlässigkeit,
effiziente,
verbindungsorientierte
Datenübertragungen
sowie
transaktionsorientierte
Datenübertragungen. Der zuletzt genannte Punkt ist besonders für den Web - Datenverkehr von
großer Bedeutung ist. Durch einige Funktionen wie das Entfernen von Duplikaten,
Übertragungswiederholungen, Bestätigungsmeldungen sowie eindeutige Transaktionskennungen
ist es WTP möglich eine sehr hohe Zuverlässigkeit zu bieten. Darüber hinaus beinhaltet WTP
noch weitere wichtige Funktionen wie asynchrone Transaktionen, Abbruch von Transaktionen,
Verknüpfung von Nachrichten oder das Signalisieren von Erfolg oder Misserfolg einer
Transaktion.
Die Basis für alle von WTP angebotenen Dienst bilden drei grundlegende Klassem von
Transaktionsdiensten. Die WTP - Klasse 0 bietet einen unzuverlässige Transfer von Daten ohne
Rückmeldung. Die WTP - Klassen 1 und 2 bieten jeweils zuverlässige Datenübertragungen
wobei die Klasse 1 keine und die Klasse 2 genau eine Rückantwort zulässt. Ein expliziter
Verbindungsauf- oder -abbau wird von keiner der drei Klassen benötigt. Durch den Verzicht auf
WAP - noch aktuell? Alternativen? 21
diese Mechanismen wie sie bei TCP eingesetzt werden, wird eine unnötige Verschwendung der
ohnehin schon geringen Bandbreiten in der mobilen Datenübertragung verhindert.
WTP - Klasse 0
Die WTP - Klasse 0 bietet einen unzuverlässigen Transaktionsdienst ohne Übermittlung einer
Ergebnisnachricht. Die Transaktionen dieser Klasse sind zustandslos und können zu jedem
Zeitpunkt abgebrochen werden.
Abbildung 6: Einfache Transaktion in der WTP - Klasse 0
Wie in Abbildung 6 sichtbar wird dieser Dienst durch das Dienstprimitiv „TR-Invoke.req“ mit
den bereits bekannten Parametern Quelladresse SA und -port SP, Zieladresse DA und -port DP
angefordert. Darüber hinaus hat dieses Primitiv einen Parameter A, mit Hilfe dessen festgelegt
werden kann, ob eine Bestätigungsnachricht durch den Nutzer eines Dienstes oder durch die
WTP - Instanz auf der Seite des Beantworters erzeugt wird. Dieser Parameter ist jedoch in der
WTP - Klasse 0 ohne Bedeutung, da ohnehin keine Bestätigung erzeugt wird. Die letzten drei
Parameters des oben genannten Dienstprimitivs sind die Benutzerdaten DU, der Klassentyp C,
der in der Klasse 0 statisch auf 0 gesetzt wird und die Transaktionskennung H, über die eine
Transaktion eindeutig identifiziert werden kann.
Durch den Aufruf dieses Dienstprimitivs wird die WTP - Instanz auf Initiatorseite dazu gebracht,
eine Invoke PDU (Protocol Data Unit) an die WTP - Instanz des Beantworters zu übermitteln,
die daraufhin dem Nutzer auf Beantworterseite durch das Senden des Primitivs „TR-Invoke.ind“
mit denselben Parametern wie bei „TR-Invoke.req“ den Erhalt der Invoke PDU signalisiert.
WTP - Klasse 1
In der WTP - Klasse 1 wird ein zuverlässiger Transaktionsdienst ohne Ergebnisnachricht zur
Verfügung gestellt. Die Anforderung des Dienstes erfolgt ebenso wie in der Klasse 0 über das
Dienstprimitiv „TR-Invoke.req“, wobei der Parameter Klassentyp C auf 1 gesetzt wird.
Entscheidet der Initiator über den Parameter A, dass die Bestätigungsnachricht automatisch
durch die WTP - Instanz des Beantworters versendet werden soll, so geschieht dies automatisch
nach der Empfangssignalisierung der Instanz an den Nutzer über das Primitiv „TR-Invoke.ind“.
Automatisch wird eine ACK - PDU (Acknowledgement PDU) an die WTP - Instanz des
Initiators übermittelt durch die WTP - Schicht des Beantworters gesendet. Dieser Fall ist in
Abbildung 7 dargestellt.
WAP - noch aktuell? Alternativen? 22
Abbildung 7: Transaktion in der WTP - Klasse 1 ohne Nutzerbestätigung
Im anderen Fall, wie in Abbildung 8, muss der Nutzer durch das Aufrufen des Primitivs „TRInvoke.res“ die WTP - Schicht aktiv zum Versenden der ACK - PDU auffordern. In beiden
Fällen wird nach Erhalt der ACK - PDU dem Nutzer auf Initiatorseite der Erhalt der
Bestätigungsnachricht durch das Primitiv „TR-Invoke.cnf“ signalisiert. Hat er dieses Signal nach
einer gewissen Zeit noch nicht erhalten, so wird der Initiator vom Verlust der Invoke - PDU
ausgehen und eine Übertragungswiederholung durchführen.
Abbildung 8: Transaktion in der WTP - Klasse 1 mit einer Bestätigung durch einen Nutzer
Mögliche sinnvolle Anwendungsgebiete für die WTP - Klasse 1 können beispielsweise
zuverlässige Push - Dienste sein. Eine genauere Beschreibung der Push - Dienste folgt in Kapitel
4.1.3 -- Push - Architektur.
WTP - Klasse 2
Die WTP - Klasse 2 bietet zuverlässige Transaktionsdienste mit genau einer Antwort, wie sie von
klassischen, zuverlässigen Transaktionen wie beispielsweise in der Client - Server - Architektur
her bekannt sind. Je nach dem, was vom Benutzer angefordert wird, ist eine Vielzahl an
Szenarien denkbar. Im Folgenden möchte ich kurz auf drei verschiedene Anwendungsfälle
eingehen und diese etwas näher betrachten:
In allen drei Fällen wird genau wie in den WTP - Klassen 0 und 1 der Transaktionsdienst über
das Primitiv „TR-Invoke.req“ angefordert und daraufhin die Invoke - PDU an die WTP - Schicht
des Beantworters gesendet. Diese signalisiert dann dem Nutzer den Erhalt der Invoke - PDU
über das Primitiv „TR-Invoke.ind“. Im ersten Fall handelt es sich um eine Transaktion in der
WTP - Klasse 2 ohne Bestätigung durch einen Nutzer auf Beantworterseite. Nach Erhalt der
Invoke - PDU sendet der Beantworter die Result - PDU mittels des Dienstprimitivs „TRResult.req“ an den Initiator zurück. Dieses Primitiv enthält als Parameter das Ergebnis der
WAP - noch aktuell? Alternativen? 23
Transaktion in den Benutzerdaten UD* und die Transaktionskennung H. Der Erhalt der Result PDU auf Initiatorseite signalisiert auch gleichzeitig den Erhalt der Invoke - PDU. Abschließend
sendet der Initiator eine ACK - PDU mit Hilfe des „TR-Result.res“ - Primitivs an den
Beantworter zurück, um den Erhalt des Ergebnisses anzuzeigen. Dieses eben dargestellte
Zusammenspiel der beiden Dienste TR-Invoke und TR-Result bildet die Grundlage für den zur
Verfügung gestellten zuverlässigen, effizienten Datentransfer mit Bestätigung. Dieser
Sachverhalt ist in Abbildung 9 dargestellt.
Abbildung 9: Transaktion in der WTP - Klasse 2 ohne Nutzerbestätigung
Beim zweiten Fall wie in Abbildung 10 gezeigt, handelt es sich um eine einfache Transaktion der
WTP - Klasse 2 mit einer expliziten Bestätigung des Nutzers auf Beantworterseite. Prinzipiell
läuft die Transaktion gleich ab wie im gerade beschriebenen ersten Fall, bis auf die Tatsache,
dass der Nutzer auf Beantworterseite nach Erhalt der Invoke -PDU den Erhalt durch das Senden
einer ACK - PDU bestätigt. Anschließend läuft die Transaktion genauso weiter, wie im oben
beschriebenen Fall. Dieser Fall ist normalerweise der Standardfall in verteilten Anwendungen,
die auf Anfrage- und Antwort - Schemata beruhen.
Abbildung 10: WTP - Klasse - 2 Transaktion mit einer Bestätigung durch einen Nutzer
Der dritte Fall, der hier beschrieben werden soll, ist eine WTP - Klasse 2 - Transaktion mit
Halten und ohne Bestätigung des Beantworters. Dieser Fall ist vom Ablauf her wieder genau wie
der erste beschriebene Fall, das der Nutzer auf Beantworterseite ebenfalls keine explizite
WAP - noch aktuell? Alternativen? 24
Bestätigung über den Erhalt der Invoke - PDU an den Initiator zurücksendet. Hier wird aber im
Fall einer längeren Berechnungszeit des Ergebnisses der Initiator in eine Wartestellung (hold on) gebracht. Dies geschieht über ein automatisches Senden einer Bestätigungsnachricht (ACK PDU) durch die WTP - Instanz des Beantworters. Hierdurch wird die WTP - Instanz des
Initiators darüber informiert, dass die Invoke - PDU beim Beantworter angekommen ist und
keine Übertragungswiederholung nötig ist. Das Zeitablaufschema für dieses Szenario kann
Abbildung 11 entnommen werden.
Abbildung 11: Transaktion in der WTP - Klasse 2 mit Halten des Initiators
Weitere Eigenschaften von WTP sind beispielsweise die Verkettung und Separierung von
Nachrichten oder asynchrone Transaktionen mit bis zu 215 ausstehenden Transaktionen, d.h. dass
die Transaktionen bereits initiiert wurden jedoch noch kein Ergebnis vorliegt.
4.1.2.4
WSP - Wireless Session Protocol
WSP kann entweder auf dem einfachen Datagramm - Dienst WDP oder auf dem
Transaktionsdienst WTP aufsetzen. Bei beiden Varianten ist natürlich eine sichere Variante
möglich, indem einfach die Sicherungsschicht mit dem Protokoll WTLS dazwischen
eingeschoben wird. Die grundlegende Funktion des wireless session protocol ist die Errichtung
eines gemeinsamen Zustands zwischen dem anfragenden Client und dem Server. Hierdurch soll
eine Optimierung der Inhaltsübertragung erreicht werden. Im Gegensatz dazu ist HTTP ein
zustandloses Protokoll, d.h. es ist keine Zwischenspeicherung von Inhalten möglich. Aus diesem
Grund wurde im Web - Umfeld auch die Notlösung Cookies erfunden, damit wenigstens ein
gewisser Zustand auf der Client Maschine gespeichert werden kann. Eben dieses Protokoll soll
im wireless - Umfeld durch WSP ersetzt werden, das gegenüber HTTP einige Vorteile im
wireless - Bereich zu bieten hat. Zum einen hat man durch die Zwischenspeicherung der
Zustände auf der lokalen Maschine immer eine gewohnte Umgebung im Web, egal von wo aus
man sich einwählt. Außerdem müssen nicht jedes Mal die Benutzerprofile durch den Anbieter
neu übertragen werden, und nicht zuletzt kann die Arbeit im Web an gleicher Stelle fortgesetzt
werden wo sie beendet wurde, als das Web verlassen oder die Verbindung abgebrochen wurde.
WSP bietet folgende grundlegende Fähigkeiten im Bereich der Client - Server - Datentransfers:

Sitzungsverwaltung
Die Sitzungen werden vom Client aus zu einem Server eingerichtet und sind von
langlebiger Natur, d.h. sie müssen genauso geordnet abgebaut werden, wie sie aufgebaut
WAP - noch aktuell? Alternativen? 25
werden. Ein ganz wichtiges Merkmal der Sitzungsverwaltung ist die Möglichkeit
Sitzungen parken und wiederaufnehmen zu können. Hierdurch kann die Arbeit im Web
an der gleichen Stelle vorgesetzt werden wo sie beendet wurde, ohne dass die Daten
nochmals komplett von Beginn an übermittelt werden müssen. Dies ist natürlich
besonders im Bereich der mobilen Kommunikation mit seinen niedrigen Bandbreiten ein
sehr wichtiges und wertvolles Merkmal.

Aushandlung von Fähigkeiten
Während die Sitzung aufgebaut wird, können Client und Server untereinander einen
Parametersatz austauschen, über den das genutzte Protokoll sowie die Protokollparameter
festgelegt bzw. ausgehandelt werden. Beispiele für diese Protokollparameter sind die
maximale SDU - (Service Data Unit) Größe, die maximale Anzahl an ausstehenden
Anfragen oder die Protokolloptionen.

Inhaltecodierung
In WSP ebenfalls definiert ist eine Binärcodierung für die zu übertragenden Inhalte, um
diese effizienter über die drahtlosen Übertragungswege versenden zu können.
bei dem bisher beschriebenen WSP handelt es sich um ein allgemein einsetzbares
Sitzungsschichtprotokoll. Speziell für den Einsatz im WAP wurde das Protokoll WSP/B (WSP /
Browsing) entwickelt. Dieses umfasst Protokolle und Dienste, die im Wesentlichen für Web Nutzung gedacht sind und enthält zusätzlich zu den Fähigkeiten und Merkmalen von WSP noch
folgende weitergehende Eigenschaften:

HHTP / 1.1 - Funktionalität
WSP / B unterstützt auch die von HTTP / 1.1 angebotenen Funktionen wie beispielsweise
erweiterte Anfrage- und Antwortmethoden, zusammengesetzte Objekte oder Verhandlung
von Inhaltstypen. Bei WSP 7 B handelt es sich im Prinzip um eine Binärversion von
HTTP / 1.1. Denn zur Festlegung der Inhaltstypen, der Codierung des Zeichensatzes oder
der Sprachen wird ein HTTP / 1.1 - Kopf verwendet. Viele Standardköpfe, die häufig
vorkommen sind hierbei jedoch mit einer festen binären Codierung versehen, um den
Übertragungsaufwand zu minimieren.

Austausch von Sitzungsinformationen
Client und Server können diejenigen Köpfe für die Anfragen und Antworten austauschen
und speichern, die für die komplette Sitzung konstant bleiben. Das vermindert wiederum
denn Übertragungsaufwand, da diese konstanten, gespeicherten Köpfe nicht ständig neu
übertragen werden müssen. Hierbei kann es sich beispielsweise um Inhaltstypen,
Zeichensätze, Sprache, Gerätefähigkeit oder andere statische Parameter handeln.

Push- und Pull - Datentransfer
Im Web dominieren traditionellerweise die Pull - Dienste, d.h. die Daten auf dem Server
werden von einem Client angefordert, bevor diese gesendet werden. Diese Funktion wird
von WSP / B durch die Verwendung der Anfrage - Antwort - Mechanismen von HTTP /
1.1 unterstützt. Zusätzlich zu diesen Pull - Diensten werden von WSP / B noch drei Push
WAP - noch aktuell? Alternativen? 26
- Dienst unterstützt. Push - Dienste sind direkt vom Server angestoßene Datentransfers,
ohne das der Client eine Anfrage an diesen gestellt hat. Denkbare Beispiele für so einen
Dienst sind Verkehrsmeldungen, Wettervorhersagen, Ergebnisdienst, etc. Eine
ausführlichere Erklärung der Push - Dienste folgt in Kapitel 4.1.3. Die drei gerade
erwähnten Dienste sind jeweils ein bestätigter und ein unbestätigter Push - Dienst im
Kontext einer bestehenden Sitzung sowie ein unbestätigter Push - Dienst außerhalb des
Kontexts einer bestehenden Sitzung.

asynchrone Anfragen
Dieses Merkmal wird von WSP / B optional angeboten. Hierbei werden Clients
unterstützt, die mehrere Anfragen simultan an einen Server senden möchten. Diese
Funktion erhöht ebenfalls die Übertragungseffizienz, da mehrere Anfragen und
Antworten innerhalb von wenigen Nachrichten zusammengefasst werden können.
Einsatz von WSP / B über WTP
Alle drei WTP - Klassen werden von WSP / B verwendet, jedoch für unterschiedliche
Funktionen: Die Klasse 0 - Transaktionen werden für unbestätigte Push - Dienste sowie für das
Parken oder Beenden einer Sitzung und für die Sitzungsverwaltung verwendet. Transaktionen
der WTP - Klasse 1 werden nur für bestätigte Push - Dienste verwendet und die WTP - Klasse 2 Transaktionen werden hauptsächlich für Methodenaufrufe, manchmal auch für die
Sitzungsverwaltung verwendet. Einige dieser Beispiele möchte ich im Folgenden kurz näher
beschreiben:
Abbildung 12: WSP/B Sitzungsaufbau
Wie in obiger Graphik (Abbildung 12) sichtbar, erfolgt das Einrichten einer Sitzung mittels einer
WTP - Klasse -2 -Transaktion über den Aufruf des Dienstprimitivs „S-Connect.req“ mit den
Parametern Server Adresse SA, Client Adresse CA, Client - Kopf CH(Client Header) und den
angeforderten Fähigkeiten RC (Requested Capabilities). Der Client - Kopf bedient sich der
Adressierung der unterliegenden Schicht, d.h. die beiden Schnittstellen TR - SAP und S - SAP
können direkt aufeinander abgebildet werden. Im Client - Kopf können vielfältige Nutzer - zu Nutzer - Informationen enthalten sein, die auch, wie schon beschrieben, zwischengespeichert
werden können, falls sie über die komplette Sitzung unverändert bleiben. Der Parameter RC ist
nötig, damit Client und Server ihre jeweiligen Fähigkeiten aushandeln können. Im Anschluss an
die Initialisierung der Sitzung sendet die WTP - Instanz des Initiators eine Connect - PDU an des
S -SAP des Servers, der dann mittels des Primitivs „S - Connect.ind“ dem Benutzer die neue
WAP - noch aktuell? Alternativen? 27
Sitzung anzeigt. Dieses Primitiv hat die gleichen Parameter wie der Request nur mit der
Abweichung, dass die angeforderten Fähigkeiten RC jetzt verpflichtend sind. Wenn die Sitzung
vom Server akzeptiert wird, so sendet dieser eine ConnReply - PDU mittels des Primitivs „SConnect.res“ mit den Parametern Server Kopf SH und den ausgehandelten Fähigkeiten NC
(Negotiated Capabilities). Ist die ConnReply - PDU beim Initiator angekommen, bestätigt die
WTP - Instanz dem Nutzer mit Hilfe des Dienstprimitivs „S-Connect.cnf“ den Aufbau der
Sitzung.
Abbildung 13: Parken und Wiederaufnehmen einer Sitzung
Abbildung 13 zeigt das Parken und Wiederaufnehmen einer Sitzung, das wir als zweites Beispiel
betrachten wollen: Falls der Client bemerkt, dass er bald nicht mehr erreichbar sein wird, sei es
weil das Gerät ausgeschaltet wird, wegen einem Netzwerkwechsel oder eines Abbruchs der
Funkverbindung, so wird er alle Datenübertragungen abbrechen und den gegenwärtigen Zustand
auf Client- und Serverseite einfrieren, um ihn später wieder aufnehmen zu können. Der Aufruf
des Primitivs „S-Suspend.req“ löst das Senden der Suspend - PDU aus, die auf Empfängerseite
das Primitiv „S-Suspend.ind“ aufruft, um den Server vom Abbruch der Sitzung zu informieren.
Parameter sind hier lediglich der Grund R (Reason). Hierbei handelt es sich um Transaktion der
WTP - Klasse 0. Das Wiederaufnehmen einer Sitzung geschieht mit hilfe des Dienstprimitivs „SResume.req“ mit den Parametern Server Adresse SA und Client Adresse CA. nach dem Erhalt
der gesendeten Resume - PDU auf Server - Seite sendet dies eine Reply - PDU mit „SResume.res“ ab, um dem Client mitzuteilen, dass Die Sitzung wieder aufgenommen wurde. Bei
diesem Vorgang handelt es sich um einen bestätigten Dienst, also um eine Transaktion in der
WTP - Klasse 2.
Abbildung 14: Beenden einer WSP/B - Sitzung
WAP - noch aktuell? Alternativen? 28
Das Beenden einer Sitzung erfolgt analog wie beim Parken einer Sitzung mit dem Primitiv „SDisconnect.req“ und der Disconnect - PDU.
Zwei weitere kleine Beispiele sind ein unbestätigter Push - Dienst in der WTP - Klasse 0 mittels
des Primitivs „S-Push.req“ mit den Parametern Push - Kopf PH und Push - Body PB und der
bestätigte Push - Dienst in der WTP - Klasse 1 mittels „S-ConfirmedPush.req“ mit dem
zusätzlichen Parameter Client Push Identifier CPID bzw. Server Push Identifier SPID. In diesen
beiden Fällen wird eine Push - PDU bzw. eine ConfPush - PDU vom Server an die WTP Instanz des Clients gesendet. Im Fall des bestätigten Push - Dienstes sendet der Client nach
Erhalt der ConfPush - PDU noch eine Bestätigung über den Erhalt der PDU an den Server
zurück. Diese beiden Beispiele sind in untenstehenden Abbildungen 15 und 16 dargestellt.
Abbildung 15: unbestätigter Push - Dienst in WSP/B
Abbildung 16: bestätigter Push - Dienst in WSP/B
Beim Fall eines Methodenaufrufs wie in Abbildung 17 dargestellt,handelt es sich um eine
vollständige WTP - Klasse -2- Transaktion. Initiiert wird diese über den Aufruf des Primitivs „SMethodInvoke.req“ was das Senden der Method - PDU nach sich zieht. Parameter sind hierbei
der Client Transaction Identifier CTID, die Methode M und die Request URI (Uniform Response
Identifier, z.B. eine URL) RU. Auf Server - Seite wird diese Anfrage zuerst mit der
entsprechenden Antwort bestätigt und dann das Ergebnis mit Hilfe von „S-MethodResult.req“
mit den Parametern Server Transaction Identifier STID, Status S, Response Header RH und
Response Body RB. Der Erhalt des Ergebnisses wird dann noch vom Client mit dem
entsprechenden Dienstprimitiv bestätigt.
WAP - noch aktuell? Alternativen? 29
Abbildung 17: Methodenaufruf als Beispiel für eine vollständige WTP - Klasse - 2 - Transaktion
In unten stehender Graphik (Abbildung 18) wird gezeigt, wie beispielsweise das Primitiv „SMethodInvoke.req“ ein „TR-Invoke.req“ - Primitiv auf der Transaktionsschicht auslöst. In
diesem Beispiel trägt die Invoke - PDU der Transaktionsschicht die Method - PDU der WSP Schicht in sich. Für die Bestätigungen der eigenen Dienstprimitive gibt es keine eigenen PDUs in
der Sitzungsschicht. Stattdessen werden um redundante Datenübertragungen zu vermeiden die
ACK - PDUs der Transaktionsschicht verwendet, wie ebenfalls aus unten stehender Graphik
sichtbar wird.
Abbildung 18: Nutzung von WTP als unterliegende Schicht durch WSP
WSP bietet auch keine Möglichkeit, die Reihenfolge von Anfragen einzuhalten oder
wiederherzustellen. So kann es zu einer Verschiebung der Reihenfolge der Antworten im
Vergleich der Anfragenkommen. Dieser Zustand kann beispielsweise entstehen, wenn für die
Antwort der ersten Anfrage ein Datenbankzugriff nötig ist aber die Antwort auf die nächste
Anfrage bereits in gespeichertem zustand vorhanden ist. dann werden die Antworten in
umgekehrter Reihenfolge beim Client ankommen, wie die Abfragen abgesendet wurden. Dieser
Sachverhalt ist in Abbildung 19 graphisch dargestellt.
WAP - noch aktuell? Alternativen? 30
Abbildung 19: asynchrone, ungeordnete WSP/B - Anfragen
Einsatz von WSP / B über WDP (als verbindungsloser Datendienst)
Bei manchen Anwendungen ist es durchaus denkbar, dass der Aufwand für diverse Aktionen wie
Sitzungseinrichtung, bestätigte Methodenaufrufe, Speicherung der zustände oder
Sitzungsabbruch nicht gerechtfertig ist, oder ein zuverlässiger Dienst einfach nicht erforderlich
ist. Ein Beispiel hierfür könnte die Übermittlung von periodischen Wetterdaten auf einmobiles
Endgerät sein. In so einem Fall würde sich dann die direkte Arbeit mit dem einfachen
Datagrammdienst der WDP - Schicht besser eignen, als das komplexe WTP als Grundlage für die
Sitzungsschicht. Im Falle dieser verbindungslosen Datendienste stehen dann drei Dienstprimitive
(vgl. Abbildung 20) „S-Unit-MethodInvoke.req“, „S-UnitMethodResult.req“ und „S-UnitPush.req“ zur Verfügung. Die Übertragung der zugehörigen PDUs (Method, Reply, Push) erfolgt
dann mit Hilfe des unzuverlässigen Datagrammdienstes von WDP. Das Primitiv „S-UnitMethodInvoke“ hat zusätzlich zu den bereits bekannten Parametern Server - Adresse SA, Client Adresse CA, Methode M und Request - URI RU den Parameter Transaktionskennung TID
(Transaction Identifier). Bei „S-Unit -Method-Result“ kommen zu SA, CA und TID noch Status
S, Response - Header RH und Response - Body RB als Parameter hinzu. Das Dienstprimitiv „SUnit-Push“ hat als Parameter außer SA und CA noch den Push - Identifier PID, den Push Header PH und den Push - Body PB.
WAP - noch aktuell? Alternativen? 31
Abbildung 20: WSP/B als unbestätigter Sitzungsdienst mit WDP als Grundlage
Trotz der bereits vielfältigen in WSP angebotenen Dienste gibt es immer noch einige ungeklärte
Probleme wie etwa die Unterstützung von Gruppenkommunikationen, die Unterstützung von
isochronen Diensten, also Dienste mit garantierter Zeitschranke bei Sitzungsaufbau und
Datenübertragung, oder der allgemeinen Verwaltung aller Dienste.
4.1.2.5
WAE - Wireless Application Environment
Die Wireless Application Environment hat als Grundziel die Schaffung einer allgemeingültigen
Anwendungsumgebung die vorwiegend auf bestehenden Techniken und Entwurfsphilosophien
aus der WWW - Umgebung basiert. Dies soll einerseits ermöglichen, dass möglichst viele
Dienstanbieter und Hersteller von Hard- und Software ihre Produkte integrieren können, aber
andererseits auch dass eine möglichst große Bandbreite an verschiedenen mobilen Endgeräten
erreicht werden kann. Genau aus diesem Grund wurde in WAE keine einheitliche Schnittstelle zu
den Nutzern festgelegt, um unterschiedliche Geräte von verschieden Herstellern mit ihren
spezifischen Fähigkeiten, Stärken und Schwächen unterstützen zu können.
Zu den generellen Zielen von WAE zählt die Minimierung des Datenverkehrs über Funkstrecken
und die Minimierung des Ressourcenverbrauchs auf den mobilen Endgeräten. Deswegen
unterstützt WAE schwerpunktmäßig auch Geräte mit relativ schwachen Fähigkeiten und oft
schmalbandigen Funkanbindungen. Um diese Ziele zu erreichen wurden Techniken erfunden, die
speziell auf den mobilen Datentransfer mit all seinen Problemen zugeschnitten sind. WML und
WMLScript, die beiden Beschreibungssprachen von WAE, basieren hauptsächlich auf bekannten
Techniken wie HTML, HDML (Handheld Device markup language) oder JavaScript.
WAE übernimmt zwar hauptsächlich die generelle WWW - Architektur der Requests-andResponses, integriert jedoch noch einen Gateway, der quasi als Vermittler zwischen Servern und
mobilen Clients dient. Die Anfragen vom Client gelangen in einem binären WML - Format zum
Gateway, der diese dann in HTTP übersetzt. Anschließend werden sie zum angefragten Server
gesendet und dort wie eine gewöhnliche Anfrage aus dem Festnetz behandelt. Die Antwort des
Servers gelangt ebenso wie die Anfrage wieder über den Gateway zurück zum Client.
WAP - noch aktuell? Alternativen? 32
WML
Die Wireless Markup Language WML wurde als ein XML - Dokumententyp spezifiziert, wobei
einige bereits mehrfach erwähnte Einschränkungen der drahtlosen, tragbaren Endgeräte, wie
etwa geringe Bandbreiten oder schwache Leistungsfähigkeit, berücksichtigt werden mussten.
WML wurde nach einer karten - und Stapel - Architektur entworfen. Ein WML - Dokument
besteht aus mehreren Karten (cards), die wiederum zu Stapeln zusammengefasst werden können.
Ein Stapel ist mit einer HTML - Seite vergleichbar, das er ebenfalls über eine URL angesteuert
werden kann und eine Übertragungseinheit darstellt. WML - Stapel liegen auf dem Server und
werden vom Nutzer über den WML - Browser angefragt. Diese Stapel können als statische
Inhalte auf den Servern liegen oder dynamisch auf eine bestimmte Anfrage hin berechnet
werden.
Im Folgenden werden noch kurz einige grundlegende Eigenschaften von WML dargestellt: Mit
zu den Hauptaufgaben gehört auf jeden Fall das darstellen von Texten, einfachen Bildern oder
Graphiken und einfachen Textformatierungen. Ein weiteres wichtiges Merkmal on WML ist die
Interaktion mit dem Benutzer. Dieser kann beispielsweise durch Eingabe von Text oder
Passwörtern oder Auswahl von Options- oder Steuerknöpfen mit dem System interagieren.
Gleich wie in einem HTML - Browser gibt es in WML Mechanismen, mit denen im Bereich der
Navigation zum Beispiel bereits besuchte Seiten abgespeichert werden können.
Auf die Syntax von WML - Dokumenten soll in dieser Arbeit nicht genauer eingegangen werden.
WMLScript
WMLScript stellt eine Ergänzung zu WML dar und ermöglicht zusätzlich zu den statischen
WML - Inhalte die dynamischen Möglichkeiten einer Scriptsprache in der WAP - Architektur.
Beispiele für sinnvolle Anwendungen solcher Art sind zum Beispiel die Gültigkeitsprüfung von
Benutzereingaben, Zugriff auf die Gerätefunktionen oder die Erweiterung von Geräte - Software.
Im ersten genannten Beispiel ist sehr gut vorstellbar, dass es durchaus Sinn macht,
Benutzereingaben vor der Übermittlung an den Server zu prüfen, da im Falle einer
Falscheingabe eventuell viel Zeit und Übertragungskosten gespart werden können. Beim letzten
Beispiel wäre es denkbar, dass die Software eines Mobilgerätes nach Auslieferung an den
Kunden neu konfiguriert oder aufgestockt werden kann. Dies könnte beispielsweise durch den
Download neuer Software oder Updates vom Hersteller geschehen.
WMLScript basiert zwar grundsätzlich auf JavaScript, wurde jedoch an das drahtlose
Einsatzgebiet angepasst. Diese Anpassungen umfassen im Wesentlichen den geringeren
Speicherbedarf für den WMLScript - Bytecode - Interpreter, der sehr viel kleiner ist als sein
Pendant in JavaScript, und den effizienten Datenaustausch über die Funkübertragungsstrecken
dank eines kompakteren Bytecodes. Dieser Bytecode kann entweder bereits auf einem Server
bereitliegen oder durch einen WMLScript - Compiler, der beispielsweise im Gateway platziert
werden kann, erzeugt werden. WMLScript ist es möglich in vollem Umfang auf WML - Kontext
zuzugreifen, also beispielsweise sämtliche Variablen zu lesen oder zu setzen.
Ebenso wie auch bei WML wird auf eine genauere Beschreibung der Syntax von WMLScript in
dieser Arbeit verzichtet.
WAP - noch aktuell? Alternativen? 33
4.1.3
WAP 2.0
Der WAP 2.0 - Standard wurde Anfang 2002 vom WAP Forum verabschiedet und enthielt eine
Vielzahl an teils sehr guten Neuerungen. Dieser neue Standard bringt das Wireless Application
Protocol näher an die bestehenden Internet - Technologien heran.
Einige Beispiele aus der imposanten Liste der Neuerungen sind die Unterstützung bestehender
Internetprotokolle wie TCP oder IP, die Unterstützung von High - Speed Übertragungstechniken wie GPRS, oder die aktive Verteilung von Inhalten, so genannte Push Dienste.
4.1.3.1
neuer Protocol - Stack
Die im Kapitel 4.1.2 dargestellten WAP 1.x - Schichten werden auch durch WAP 2.0 weiterhin
unterstützt. Jedoch gibt es drei neue Standards, die näher an den bekannten Internettechnologien
liegen:
Wireless Profiled HTTP (WP - HTTP)
Hierbei handelt es sich um eine auf die speziellen Bedürfnisse von WAP zugeschnittene Variante
von HTTP. WP - HTTP ist kompatibel zu HTTP/1.1 und unterstützt neben Kompression auch das
Tunneling. Die Interaktionen zwischen den WAP - Endgeräten und den WAP - Gateways
basieren auf HTTP - Request/Response - Transaktionen.
Wireless Profiled TLS (WP - TLS)
Bei WP - TLS handelt es sich um einen Ableger von TLS, der speziell auf WAP zugeschnitten
wurde. Es unterstützt neben Zertifikaten auch verschiedene Verschlüsselungstechniken und TLS
- basierte Tunnel für gesicherte Punkt - zu - Punkt - Verbindungen.
Wireless Profiled TCP (WP - TCP)
Hierbei handelt es sich um eine Form von TCP, die speziell für den drahtlosen Einsatz angepasst
wurde. WP - TCP ist kompatibel zu Standard - TCP - Implementierungen und bringt somit einen
nicht unwesentlichen Performancegewinn mit sich.
4.1.3.2
WML 2
Auch auf der Ebene der Inhalte hat sich mit der Entwicklung von WML 2 einiges getan. WML 2
bietet zur Formatierung der anzuzeigenden Inhalte einen XHTML - basierten Auszeichnungssatz
mit CSS - Subset. WML 2 ist zwar abwärtskompatibel zu WML 1, wird dieses in naher Zukunft
aber doch ablösen. Für diesen Zeitpunkt steht dann in WAP 2.0 ein Transformationsmechanismus
zur Verfügung, der die Umwandlung von WML 1 - Dokumenten nach WML 2 ermöglicht.
4.1.3.3
Push - Architektur
Anstelle des typischen Pull eines Clients, der Daten auf einem Server anfragt tritt hier das Push
eines Servers, der Daten ohne spezifische Anfrage an Clients sendet. Der Server tritt hier als so
genannter Push Initiator PI auf und übermittelt Daten über den Push Proxy Gateway PPG an
bestimmte Clients. Für die Kommunikation der Geräte kommt zwischen PI und PPG das Push
Access Protocol (PAP), und zwischen PPG und Client das Push OTA (Over The Air) Protocol
zum Einsatz. Die allgemeine Push - Architektur ist in Abbildung 21 dargestellt.
WAP - noch aktuell? Alternativen? 34
Abbildung 21: WAP - Push - Architektur mit Gateway
Push Proxy Gateway
Der PPG ist mit dem WAP - Gateway vergleichbar, da es ebenfalls eine Vermittlungsfunktion
bezüglich der Protokolle und Funktionen zwischen Server und Client einnimmt. Nachdem der
PPG eine Push - Anfrage eines Servers erhalten hat besteht seine erste Aufgabe darin,
festzustellen ob dieser Push - Dienst an einen Client übermittle werden kann. Er muss also zuerst
überprüfen, ob beispielsweise die Client - Adresse ein gültiges Format hat oder ob der Client im
Mobilnetz gefunden werden kann. Sind diese ersten Anforderungen erfüllt, muss der zu
übermittelnde Inhalt eventuell erst noch umcodiert werden, um eine effizienter Datenübertragung
im drahtlosen Netz des Clients mittels des Push OTA Protokolls zu erreichen. Das PPG ist auch
in der Lage Erfolgs- / bzw. Misserfolgsnachrichten über den Versand der Nachricht an den PI
übermitteln. Ebenfalls ist es dem PPG möglich, Push - Inhalt an mehrere Empfänger gleichzeitig
zu versenden (Multicast).
Push Access Protocol
PAP wurde zwar unabhängig vom unterliegenden Transportsystem entwickelt, aber die ersten
Implementierungen liefen dann über HTTP. Im Folgenden eine kurze Übersicht über einige der
Operationen, die von PAP angeboten werden:

Push - Submission bezeichnet das Übermitteln einer Push - Nachricht vom PI an das
PPG, welches die Nachricht dann an einen Client weiterreichen soll.

Result - Notification ist die Benachrichtigung des PI darüber, ob seine an den PPG
gesendete Push - Nachricht auch wirklich beim Client angekommen ist.

Push - Cancellation bezeichnet den Vorgang, dass der PI versucht eine bereits an den PPG
gesendete Push - Nachricht noch vor der Weiterleitung wieder zu löschen.

Status - Query ist die Abfrage des aktuellen Status einer Push - Nachricht. Diese Abfrage
gibt dem PI Auskunft darüber, ob die Nachricht bereits ausgeliefert wurde, oder ob
aktuell noch versucht wird diese zu übermitteln.

Client Capabilities Query bezeichnet eine Abfrage, mit der ein PI feststellen kann, welche
Fähigkeiten ein Client besitzt. Ein PPG kann durch diese Abfrage erfahren, welche
Transformationen er am Inhalt vorzunehmen hat, damit die Push - Nachricht vom Client
auch fehlerfrei verarbeitet werden kann. Denkbar wäre hier beispielsweise die
WAP - noch aktuell? Alternativen? 35
Umsetzung eine Bildes im JPG - Format nach BMP, da ein Client nur Bitmaps als
Bildformate unterstützt.
Push OTA Protocol
Das Push OTA Protokoll ist ein sehr einfaches Protokoll, welches direkt über WSP eingesetzt
wird und so die Dienste sehr einfach darauf abbilden kann. Durch dieses Protokoll werden unter
anderem die Auslieferung von Push -. Nachrichten, Auswahl verschiedener
Transportmöglichkeiten für Push - Dienste oder Authentifizierung eines Pis angeboten. Der Push
- Dienst an sich kann verbindungslos und verbindungsorientiert arbeiten und dabei sowohl auf
unidirektionalen als auch auf bidirektionalen Trägerdiensten aufsetzen. Im Folgenden werden
noch kurz einige im Push OTA Protokoll spezifizierten Dienstprimitive vorgestellt:

Beim Po - Push handelt es sich um einen unbestätigten Push über einen
verbindungsorientierten Dienst innerhalb einer Sitzung.

Der Po - Confirmed - Push gleicht dem Po - Push bis auf die Abweichung, dass es sich
hierbei um einen bestätigten Push handelt.

Mit Po - Push - Abort wird die Abweisung einer Push - Nachricht eines Clients
bezeichnet.

Po - Unit - Push ist ein unbestätigter Push von Inhalten über verbindungslose
Sitzungsdienst
4.1.3.4
Fazit zu WAP 2.0
Die oben genannten Punkte stellen lediglich einen kurzen Auszug aus der beeindruckenden Liste
der Neuerungen von WAP 2.0 dar. Mit der Verabschiedung dieses neuen Standards ist dem WAp
Forum ein sehr großer Schritt nach vorne gelungen. besonders die Unterstützung der
Internetprotokolle und der Highspeed - Übertragungstechniken waren Punkte, die WAP vor dem
zwischenzeitlichen Verschwinden im Untergrund bewart haben, wie wir im abschließenden Fazit
noch sehen werden.
Auch mit der neuen Beschreibungssprache WML 2, die auf dem sehr mächtigen HHTML basiert
ist ein wahnsinnig wichtiger Schritt für die weitere Entwicklung von WAP. Hierbei ist momentan
jedoch noch das größte Problem, dass es an Implementierungen von Inhalten mit WML 2
mangelt. Ein weiters Problem des neuen Standards ist dessen hohe Komplexität, so dass es bis
jetzt nur wenige Mobiltelefone mit einem WAP 2.0 - Browser gibt. Eines der wenigen Beispiele
ist das Panasonic GD 87, das über einen kompletten WAP 2.0 Browser verfügt.
4.2
Alternative I - Mode
An dieser Stelle möchte ich nur einen kurzen Überblick über die Alternative zu WAP geben und
keine detaillierte Beschreibung liefern.
I - Mode steht für “Information Mode“ und wurde erstmals 1999 in Japan von der Firma NTT
DoCoMo eingeführt. In Japan wurde I - Mode ein Riesenerfolg und hat bereits über 30 Millionen
Nutzer, was etwa 25 % der Gesamtbevölkerung Japans entspricht. In Deutschland wurde I -.
Mode 2002 von E-Plus eingeführt, die immer noch der einzige I - Mode - Anbieter in
WAP - noch aktuell? Alternativen? 36
Deutschland sind. Hierzulande wartet man jedoch immer noch auf ähnliche Erfolge wie in Japan.
Derzeit gibt es in Deutschland lediglich etwa 120.000 I - Mode - Nutzer.
I - Mode arbeitet mit iHTML, was eine I - Mode spezifische Anpassung von cHTML ist. iHTML
bietet zusätzlich zu texten als Gestaltungsmitteln auch farbige Bilder, jedoch nur im GIF Format.
Bei I - Mode wird zwischen offiziellen und inoffiziellen Content - Providern unterschieden.
Derzeit gibt es etwa 7.000 offizielle und 20.000 inoffizielle Webseiten, wobei die offiziellen
Seiten durch NTT DoCoMo überprüft werden und dann per Standleitung mit dem I - Mode Server von NTT DoCoMo verbunden sind. Die nicht offiziellen Content Provider sind im
Gegensatz zu den offiziellen nicht am Umsatz beteiligt und sind auch nicht über eine Mietleitung
mit NTT DoCoMo´s I - Mode - Server verbunden. Auch übernimmt NTT DoCoMo keine
Gewährleistung für den reibungslosen betrieb Dieser Seiten.
I - Mode setzt voll auf GPRS, also auf eine paketvermittelte Übertragungstechnik. Hierdurch ist
es möglich, dass die Handy - Nutzer ständig online sind, und nur die übertragenen Daten bezahlt
werden müssen.
WAP - noch aktuell? Alternativen? 37
5 Fazit und Ausblick
5.1
Fazit
Wenn man WAP im praktischen Einsatz einmal kritisch betrachtet ist man dazu verleitet, schnell
über WAP zu urteilen: WAP ist zu teuer, zu umständlich, zu langsam und zu wenig ergiebig.
Was die Kosten betrifft, kann man bei den älteren Versionen WAP 1.x mit der zeitabhängigen
Abrechnung ganz klar sagen: WAP ist zu teuer! Hier muss man die komplette Onlinezeit
bezahlen, unabhängig davon, ob gerade übertragen, gelesen oder geschrieben wird. Und das zu
Minutenpreisen zwischen 19 und 20 Cent pro Minute bei allen deutschen Netzbetreibern. Von
der Kostenseite her gesehen ist WAP erst ab WAP 2.0 mit der Unterstützung von Highspeed Übertragungstechniken wie GPRS konkurrenzfähig. hierbei muss dann nur noch das tatsächlich
übertragene Datenvolumen bezahlt werden, wie es auch bei I - Mode der Fall ist.
Auch wenn es heute bereits mehrere zehntausend WAP - Seiten gibt, auf die mobil zugegriffen
werden kann, gibt es doch noch Milliarden anderer Seiten, für die der Anpassungsaufwand nicht
betrieben wurde. Nicht zuletzt des hohen Aufwandes wegen haben viele Unternehmen den
letzten Schritt der mobilen Bereitstellung der Internetinhalte nicht gewagt, da dieser im Vergleich
zum Ertrag einfach viel zu groß gewesen wäre.
Im Bereich der Geschwindigkeit ist WAP auch erstmals mit dem neuen WAP 2.0 als sinnvoll
anzusehen, da die Übertragung der Inhalte über GSM alleine einfach viel zu langsam ist. Mit
GPRS ist auch hier wieder eine akzeptable, jedoch noch lange keine ideale Lösung gefunden
worden.
Abschließend muss noch hinzugefügt werden, dass das sichtbare Ergebnis für den Benutzer auf
den mobilen Endgeräten mit Textanzeigen und sehr einfachen Graphiken natürlich den heutigen
Anforderungen an Informationen, wie wir sie aus dem Internet gewohnt sind, absolut nicht
gewachsen ist. Dieses Problem wird jetzt mit größer werdenden Displays und immer mehr
Geräten mit höheren Auflösungen und größeren Farbtiefen zwar etwas gemildert, aber noch
lange nicht zufrieden stellend gelöst. Selbst wenn in WAP 2.0 mit xHTML basierten Inhalten
auch farbige Inhalte möglich sind, sind die wenige cm2 großen Displays der mobilen Endgeräte
selbstverständlich trotzdem viel zu klein, um auch nur schlanke Homepages aus dem Internet
sinnvoll darstellen zu können. Hier wird sich jedoch auch keine wesentliche Verbesserung
ergeben können, da die Displays ja relativ klein bleiben müssen, um die Geräte auch weiterhin in
einem ansprechenden Format anbieten zu können.
WAP - noch aktuell? Alternativen? 38
5.2
Ausblick
Als Ausblick gilt es nur noch abschließend festzuhalten, dass die Zukunft sowohl von WAP als
auch von I - Mode noch ungewiss ist.
Wahrscheinlich ist jedoch, dass beide in einer Synergie aufgehen werden, sobald der WAP 2.0 Standard sich vollkommen durchgesetzt und etabliert hat. Dies liegt nicht zuletzt an xHTML, das
wesentlich effektiver als WML und selbst als iHTML ist. Gerade deshalb zählt NTT DoCoMo
auch zu den wesentlichen Antreibern im WAP Forum.
WAP - noch aktuell? Alternativen? 39
Quellenverzeichnis
Das Quellenverzeichnis soll das Auffinden der verwendeten Quellen ermöglichen. Aus dem
Internet gewonnene Informationen müssen auf CD gebrannt und mit der Arbeit abgegeben
werden.
Für die Gestaltung des Quellenverzeichnisses siehe [Rech02], wobei Marken bestehend aus 4
Buchstaben und der Jahreszahl verwendet werden. Die Marken werden aus den
Anfangsbuchstaben des Autors oder der Autoren gebildet, wie [SABK98] zeigt. Die Marken sind
die Grundlage für die alphabetische Sortierung des Quellenverzeichnisses.
Die wichtigsten Fälle sind im Folgenden dargestellt, eine umfangreichere Liste befindet sich in
[Rech02]. (Wichtiger Hinweis: Die Überschriften „Zeitschriftenartikel“ etc. sind als
Bezeichnung für Beispiel gedacht, und nicht als Unterteilung des Quellenverzeichnisses!
Zeitschriftenartikel (Beispiel)
[Bern98]
P. A. Bernstein; Repositories and Object-Oriented Databases, SIGMOD Record
98, März 1998, S. 34-46.
Workshop-Bericht: (Beispiel)
[AsSc97]
U. Aßmann, R. Schmidt: Towards a Model For Composed Extensible Components. In Proceedings Workshop Foundations of Component-Based Systems, Zürich, Schweiz, 26. September 1997, S. 23 - 30.
Diplom- / Studienarbeit (Beispiel)
[Hörb02]
M. Hörbe: Entwicklung einer Direct-To-Consumer Web-Site. Diplomarbeit an der
Berufsakademie Lörrach, Fachrichtung Wirtschaftsinformatik, Lörrach 2002.
Buch (Beispiel)
[Rech02]
P. Rechenberg: Technisches Schreiben (nicht nur) für Informatiker. Hanser Verlag.
München 2002.
[WöDö02]
G. Wöhe, U. Döring: Einführung in die Allgemeine Betriebswirtschaftslehre.
Vahlen Verlag. München 2002.
WAP - noch aktuell? Alternativen? 40
[AhFK91]
D. Ahlert, K.-P. Franz, W. Kaefer: Grundlagen und Grundbegriffe der
Betriebswirtschaftslehre. VDI Verlag. Berlin 1991.
Sammelband (Beispiel)
[BHJS96]
C. Bußler, P. Heinl, S. Jablonski, H. Schuster, K. Stein: Das WWW als
Benutzerschnittstelle und Basisdienst zur Applikationsintegration für WorkflowManagement-Systeme. In: Jeusfeld, M. (Hrsg.): Informationsserver für das
Internet. Anforderungen, Konzepte, Methoden. In Proceedings EMISAFachgruppentreffen, Aachen, Oktober 1996.
Internet (Beispiel)
[SABK98]
R. Schmidt, U. Assmann, P. Biegler, R. Kramer, P. C. Lockemann, C. Rolker: The
Interrelatedness of Component-oriented Systems And Work-flow-Management:
What they can do for each other. Workshop on Com-positional Software Architectures. Monterey, USA 1998,
http://www.objs.com/workshops/ws9801/papers/paper043.pdf. Abgerufen am
20.11.2002.
[WORD03]
http://www.microsoft.com/office/word/support/default.asp. Abgerufen am
8.5.2003
WAP - noch aktuell? Alternativen? 41
Stichwortverzeichnis
Das Stichwortverzeichnis enthält wesentliche Begriffe und ihr erstmaliges bzw. wichtiges
Vorkommen im Text. Das Stichwortverzeichnis besitzt zwei Ebenen, um beispielsweise Begriffe
wie funktionale Programmiersprachen und objektorientierte Programmiersprachen einheitlich
unter dem Stichwort Programmiersprachen darstellen zu können.
A
P
Ausblick 22
Problemanalyse 18
E
Programmiersprachen
funktionale 25
objektorientierte 25
Einleitung 13
G
Grundlagen 16
L
Lösungskonzept 19
T
Tabelle 16
U
Umsetzung 21
Z
Zusammenfassung 22
STICHWORTVERZEICHNIS
WAP - noch aktuell? Alternativen? 43
Anhang
Die Seiten des Anhangs werden durchnummeriert und schließen an die Nummerierung des
Hauptteils an.
Die einzelnen Bestandteile des Anhangs werden als Anlagen bezeichnet und durchnummeriert.
Sie erscheinen im Anlagenverzeichnis.
Grundsätzlich darf pro Anlage nur eine Quelle zitiert werden.
Anlage 1: Quellenangaben
In der wissenschaftlichen Literatur haben sich unterschiedliche Formen der Quellenangabe
eingebürgert. Sie werden entweder direkt im Text wie beispielsweise [Rech02] oder aber als
Fußnote1 in unterschiedlichsten Varianten ausgeführt.
Für diese Vorlage soll die Kombination aus Fußnote, Quellenkürzel und Seitenzahl empfohlen
werden. Auf diese Weise kann einerseits der genaue Fundort durch die Seitenzahl angegeben
werden, andererseits kann auf die Wiedergabe der kompletten Quellenbeschreibung verzichtet
werden. Bei mehreren unterschiedlichen Zitaten aus einem Buch reicht es dann, das Kürzel des
Buches anzugeben, ergänzt um die jeweilige Seitenzahl.
1
[Rech02], S. 117
WAP - noch aktuell? Alternativen? 45
Herunterladen