Was vor Jahren noch undenkbar war, ist heute längst Realität: Das Internet ist ein Massenmedium, gleiches gilt auch für den Bereich mobiles Telefonieren. In keinem anderen Land in Europa werden derzeit mehr Handys an den Mann gebracht, als in Deutschland. Es liegt auf der Hand, dass Software- und Hardwareentwickler, Netzbetreiber und Hersteller von mobilen Kommunikationsgeräten nach Lösungen suchen, wie man die Vorzüge der Internettechnologie auch für Handys nutzbar machen kann.
Die Probleme sind offensichtlich: Handys mit ihren winzigen Displays sind nicht in der Lage, traditionellen Webseiten darzustellen. Auch die beschränkten Übertragungskapazitäten machen es unmöglich, dass auch nur annähernd webähnliche Inhalte auf mobile Geräte übertragen werden. Eine vorläufige Lösung dieser Probleme leistet WAP. Die zu Grunde liegende Technologie ist in vielen Bereichen der traditionellen Internet-, insbesondere aber auch Webtechnologie, sehr ähnlich.
Das WAP-Modell
Um den Begriff WAP herum ist ein ganzes Paket an Spezifikationen entstanden, in denen Erweiterungen der Internet- und Netzwerktechnologien definiert sind. Diese unterscheiden sich stark von den bestehenden Webstandards wie zum Beispiel HTML und HTTP . Am deutlichsten werden die Erweiterungen, wenn man beide Technologie vergleicht.
Im Web herrscht ein einfaches Prinzip, die Client-Server-Architektur: Dokumente und deren unterschiedlichsten Komponenten werden auf einem traditionellen Webserver abgelegt. Der Client ruft diese Inhalte ab und stellt sie lokal dar. Ob es sich um statische oder dynamisch generierte Inhalte handelt, spielt für den Client keine Rolle. Nachdem er seine Anfrage (Request) an den Server übermittelt hat, wartet er nur auf die Antwort (Response) des Servers. Inhalte werden von Seiten des Browsers über den URL angesprochen.
WAP schreibt eine andere Architektur vor. Zwischen WAP-Client und -Server ist ein Gateway geschaltet. Wie bei herkömmlichen Webinhalten wird auch der WAP-Content auf einem Webserver abgelegt. Der Client greift über Standard-URLs auf diese Inhalte zu. Die auf dem Webserver abgelegten Inhalten basieren nicht auf HTML, sondern auf der Wireless Markup Languange (WML). Die Seiten können einfache Markierungen, Tabellen und kleine Grafiken enthalten. Aber auch elektronische Visitenkarten, Kalenderinformationen und Skriptfunktionen sind möglich.
Die Kommunikation zwischen Client und Server wird über WAP-eigene Protokolle abgewickelt. Der zentrale Unterschied zur Webtechnologie liegt in der Verwendung eines Gateways, über das Requests und Responses laufen. Dieses Gateway konvertiert WAP-basierte Requests nach dem HTTP-Protokoll, damit der Webserver etwas mit der Datenanforderung anfangen kann.
Der Client, auch als Micro Browser bezeichnet, sendet zunächst seinen WAP-Request an das Gateway. Dort wird er dekodiert und als HTTP-Request an den Webserver übermittelt. Der Webserver bearbeitet die Anforderung wie gewohnt, greift eventuell auf CGI-Schnittstellen oder Datenbanken zurück, generiert die Inhalte und übermittelt sie an das zwischengeschaltete Gateway. Der WAP-Content wird vom Gateway seinerseits kodiert und schließlich in einem WAP-eigenen Binärformat an den Client übermittelt. Auf Seiten des Clients erfolgt dann die Verarbeitung. Werden von Webserver WML-Skripts an den Client übermittelt, so werden diese vom Gateway mit Hilfe eines WML-Script-Compilers kompiliert.
Der WAP-Protokollstack
Wie andere Netzwerkprotokollfamilien ist auch WAP schichtenförmig aufgebaut. Dabei stellt jede tiefer liegende Schicht der darüber liegenden Schicht bestimmte Funktionen zur Verfügung. WAP wird durch fünf Schichten beschrieben: Anwendungs-, Session-, Transaktions-, Sicherungs- und Transportschicht. Inhaltsentwickler müssen sich insbesondere mit der Anwendungsschicht beschäftigen. Dort liegen die Auszeichnungssprache Wireless Markup Language (WML) und die Skriptsprache WMLScript.
Die Schichten im Detail:
Anwendungsschicht: Das Wireless Application Environment (WAE) ist eine multifunktionale Anwendungsumgebung, die auf der Kombination von Web- und mobilen Telefonietechnologien basiert. Ihre wichtigste Aufgabe ist die Bereitstellung einer plattformunabhängigen Umgebung, in der die unterschiedlichsten Geräte miteinander kommunizieren können. Die wichtigsten Komponenten sind Wireless Markup Language und WML-Script.
Sessionsschicht: In dieser Schicht stellt das Wireless Session Protocol (WSP) der Anwendungsschicht zwei Dienste bereit: Einen verbindungsorientierten und einen verbindungslosen Service. Sie dienen dazu, dass der Client sich zuverlässig in WAP-Anwendungen bewegen kann.
Transaktionsschicht: Das Wireless Transaction Protocol (WTP) ist ein transaktionsorientiertes Protokoll, das insbesondere drei Transaktionsdienste erlaubt: unzuverlässige Einwege-Requests, zuverlässige Einwege-Requests und zuverlässige Zweiwege-Request-Reply-Transaktionen.
Sicherungsschicht: Für die gesicherte Übertragung von Daten ist das Wireless-Transport-Layer-Security-Protokoll (WTLS) zuständig. Dieses Protokoll basiert auf TLS, dem Nachfolger von SSL . WTLS sorgt für die Datenintegrität, Privatsphäre, Authentifizierung und bietet Schutz vor Denial-of-Service-Attacken.
Transportschicht: Der Transportmechanismus Wireless Datagram Protocol (WDP) dient als Schnittstelle zwischen den darüber liegenden WAP-Protokollen und den so genannten Bearers. Unter dem Begriff Bearers werden die unterschiedlichsten Trägernetze zusammengefasst, über die WAP kommunizieren kann. Man kann sie auch als Schnittstellen zwischen WAP und den physikalischen Netzen auffassen.
Die WAP-Architektur ist so ausgelegt, dass sie über definierte Schnittstellen auch von anderen Diensten oder Anwendungen angesprochen werden kann. Über solche Schnittstellen könnten theoretisch auch E-Mail-Clients oder E-Commerce-Anwendungen auf WAP-Anwendungen zugreifen.
Binäres WAP-Format
WAP verwendet ein Gateway, über das WAP-Client und Webserver, auf dem die Inhalte abgelegt sind, kommunizieren. Das WAP-Gateway übernimmt dabei eine zentrale Aufgabe: Es wandelt binäre Informationen wie beispielsweise einen Request, der vom WAP-Handy kommt, in webbasierte Kommandos um. Diese werden dann vom Gateway an den Webserver übermittelt. Der Webserver beantwortet die Requests wie gewohnt mit einer Response, leitet seine Antwort an das Gateway, wo sie wieder in das Binärformat konvertiert und an den Client übermittelt wird. Webserver und Gateway tauschen WML-Dokumente aus.
Der Kodiermechanismus filtert dabei aus WML-Dokumenten nicht benötigte Informationen wie Meta-Daten inklusive DTD und konditionalen Abschnitte heraus. Der Kodiermechanismus verwendet eine Kodiertabelle, die WML-Tags eine hexadezimale Zeichenfolge zuweist. So wird beispielsweise das BR-Tag durch den Code 05 ersetzt.
Anhand eines Beispiels wird deutlich, wie Quelle und kodiertes Dokument sich unterscheiden. Das folgende WML-Deck enthält typische Elemente:
<?xml version="1.0"?>
<!DOCTYPE XYZ [
<!ELEMENT XYZ (CARD)+>
<!ELEMENT CARD (#PCDATA | BR)*>
<!ELEMENT BR EMPTY>
<!ENTITY nbsp " ">
]>
<XYZ>
<CARD>
X & Y<BR/>
X = 1
</CARD>
</XYZ>
Nach der Konvertierung durch den Encoder ergibt sich folgendes Format in Hexadezimaldarstellung:
02 01 03 00 47 46 03 ' ' 'X' ' ' '&' ' ' 'Y' 00 05 03 ' '
'X'00 02 81 20 03 '='00 02 81 20 03 '1' ' ' 00 01 01
Probleme tauchen auf in der Praxis - wenn auch relativ selten - durch unterschiedliche Implementierungen der Kodiermechanismen. Im schlimmsten Fall sind Inhalte für den End-User unbrauchbar.
Zukünftige Entwicklungen
Noch steckt WAP in den Kinderschuhen. Erste WAP-Anwendungen sind gerade im Entstehen, entsprechende Handys immer noch nicht in Stückzahlen erhältlich. Und dennoch: Die Mütter und Väter von WAP haben konkrete Vorstellungen, was in Zukunft per WAP möglich sein soll. Die Wunschliste an technischen Erweiterungen ist lang. In Planung sind unter anderem eine automatische Kompression der übertragenen Seiten, Sicherheitsmechanismen für die Anwendungsschicht, Multicast-Support und APIs für die einzelnen Schichten. (mhe)