Ausarbeitung

Inhaltsverzeichnis
1 Einleitung ..................................................................................................... 1
2 Verwendete Technologien ................................................................................ 2
2.1 WAP (Wireless Application Protocol) ............................................................ 3
2.1.1 Entstehungsgeschichte ........................................................................ 3
2.1.2 WAP Architektur ................................................................................. 4
2.1.2.1 WAP-Client .................................................................................. 4
2.1.2.1.1 Komponenten ......................................................................... 4
2.1.2.1.2 Einschränkungen mobiler Endgeräte ........................................... 5
2.1.2.2 Mobilfunknetz ............................................................................... 8
2.1.2.2.1 Netze (GSM, HSCD, GRPS, EDGE-GMS, UMTS) ............................... 8
2.1.2.2.2 Netzwerkbetreiber .................................................................... 9
2.1.2.3 WAP-Gateway .............................................................................. 10
2.1.2.4 Contentprovider ........................................................................... 10
2.1.2.5 Beispiel ...................................................................................... 11
2.1.3 WAP-Protokolle ................................................................................. 11
2.1.4 WML (Wireless Markup Language) ......................................................... 13
2.2 JSP (Java Server Pages) ........................................................................... 14
3 Entwicklungstools in der Implementierungs- und Testphase ................................... 15
3.1 Nokia Toolkit 1.2 ...................................................................................... 15
3.2 JBuilder 4 .............................................................................................. 15
4 Zusammenfassung ........................................................................................ 16
Literaturverzeichnis ......................................................................................... 17
1
1 Einleitung
Das Unternehmen FCS Fair Computer Systems GmbH, das April 1999 gegründet
wurde, ist ein Systemhaus mit Schwerpunkt auf Realisierung von Internet Backend
Systemen und Web Services. Es entwickelt im Bereich E-Commerce Lösungen für
den Automobilhandel.
Das Projektteam realisiert ihre Projektarbeit in der Geschäftseinheit Internet
Technology & Security unter der Leitung von Herrn Dr. Jürgen Falk und Herrn Thomas
Ilgenfritz im Aufgabenbereich Mobile Internet (WAPFair). Als persönlicher Betreuer
stand uns Herr Rainer Friedensohn während des ganzen Projekts zur Seite.
WAPFair ist ein modularer WAP-Service für das Mobile Business, in denen WAP
Systeme, wie beispielsweise WAP-Fahrzeugbörsen, implementiert werden.
Aufgabenstellung der Projektarbeit ist es, eine WAP-Schnäppchenbörse zu
implementieren, die den mobilen Verkauf von Gebrauchtwagen unterstützt. Dadurch
sollen die bestehenden Fahrzeugbörsen um WAP-Funktionalitäten erweitert, sowie
den Kunden eine direkte Kontaktaufnahme über das Handy mit den anbietenden
Autohäusern ermöglicht werden.
In den folgenden Abschnitten wird auf die Technologien eingegangen, die zur
Zielerreichung der Aufgabenstellung notwendig sind. Am Ende der Ausarbeitung
werden die verwendeten Entwicklungstools kurz vorgestellt.
2
2 Verwendete Technologien
Das Projektteam hat sich mit FCS Fair Computer Systems, zur Erstellung der WAPSchnäppchenbörse, auf folgende Basis-Technologien geeinigt:
1.
2.
3.
4.
JAVA Servlets
JSP
WML
SQL
Auf Konzeption, Anwendungslogik und Datenbankdesign wird näher in den
schriftlichen Ausarbeitungen der anderen Projektteammitglieder eingegangen.
An der Konzeption waren alle Projektteammitglieder beteiligt. In der
Implementierungsphase hingegen wurde das Projekt in zwei Gruppen geteilt, um die
Anwendung aus den drei Sichten: Design (engl. View), Logik und Daten, besser
herausarbeiten zu können.
Michael Stumpf und Hans Cristoph Luther übernahmen den Teil der Implementierung
der Java Servlets und des Datenbankdesigns, René J. Soria Wolf und Denise
Biermann den der Java Server Pages und der WML-Seiten.
In dieser schriftlichen Ausarbeitung wird die WAP-Technologie (vgl. Abschnitt 2.1)
erklärt, um die Seitenbeschreibungssprache WML (vgl. Abschnitt 2.1.4), die in der
Projektimplementierung verwendet wird, besser darlegen zu können. Zusammen mit
den Java Server Pages (vgl. Abschnitt 2.2) haben sie primär die Aufgabe der
Anwendungsdarstellung (Design). Durch die Kommunikation mit den Java Servlets
(Logik) wird die Darstellungsschicht mit den Daten aus der Datenbank (Daten)
versorgt.
3
2.1 WAP (Wireless Application Protocol)
WAP ist ein Oberbegriff für eine Protokollfamilie (vgl. Abschnitt 2.1.3), wird aber auch
für die Seitenbeschreibungssprache WML und ihre Ergänzung WMLScript (vgl.
Abschnitt 2.1.4) verwendet. [WeHa01, S. 3]
Die mittlerweile realisierte Vision der WAP–Technologie, den Transfer von
Internetinhalten auf das Mobilfunknetz zu ermöglichen, so dass auf Web-Inhalte mit
portablen Endgeräten, z.B. Handys oder PDAs (Personal Digital Assistant),
zugegriffen werden kann, hat einen neuen, großen Marktplatz gefunden, der nach
konkreten Anwendungen sucht, die für mobile Benutzer einen Sinn machen und einen
Nutzen bringen. „Die Idee dahinter ist keine geringere, als die beiden größten Märkte,
die Welt der Handys und des WWW, miteinander zu verheiraten“. [WeHa01, S. 3]
2.1.1 Entstehungsgeschichte
„Viele Berufe bedürfen heute einer ständigen Erreichbarkeit, die durch die wachsende
Mobilität bedingt ist“ [Rich00].
Die ersten Versuche einen Standard in der mobilen Kommunikation zu setzen, wurden
seit 1996 von einigen Firmen, wie z.B. von Unwired Planet, unternommen.
Auszeichnungssprachen, wie beispielsweise HDML (Handheld Device Markup
Language), konnten sich allerdings als Standard nie richtig durchsetzen, was andere
Firmen dazu bewog, nach eigenen Standards zu suchen.
1997 wurde das WAP Forum1 von den Verantwortlichen von Unwired Planet (heute
Phone.com), Motorola, Nokia und Ericsson gegründet. Ziel war es, in gemeinsamer
Zusammenarbeit, einen standardisierten Internetzugang für mobile Endgeräte zu
entwickeln, d.h. einen Industriestandard für mobile Anwendungen, der sowohl die
Übertragung der Daten (Protokolle), als auch die Programmierung der Seiten regelt.
Mittlerweile besteht das Forum aus über 500 Mitgliedern2. Bei der Aufnahme weiterer
Firmen in das Forum, wurde darauf geachtet, dass die Unternehmen aus dem
weiteren Umfeld der Telekommunikation, darunter die Hersteller mobiler
Empfangsgeräte,
Netzbetreiber
und
andere
Infrastrukturanbieter,
sowie
Softwareentwickler, in einem ausgewogenen Verhältnis vertreten sind, damit keine
Branche in Zukunft die Oberhand gewinnen kann [Bros00, S. 11].
1
Homepage: http://www.wapforum.org.
2
Stand: November 2000.
4
Mit WAP wollte das Forum einen Standard entwickeln, der von möglichst allen mobilen
Endgeräten verstanden wird und der auch mit den verschiedenen Netzen umgehen
kann.
2.1.2 WAP Architektur
Die drei Säulen der mobilen Welt sind die der Endgeräte, der Netzbetreiber und der
Inhalteanbieter (engl. Contentprovider), die durch ihr Zusammenspiel, die WAPArchitektur (Abbildung 2.1.2/1) konstituieren. In genannter Reihenfolge, werden ihre
einzelnen Elemente erklärt und anschließend ihre Funktionsweise, an einem
beispielhaften Ablauf eines WAP-Seitenaufrufs durch ein mobiles Endgerät,
veranschaulicht.
WAP-Client
Proxy Server
Mobile
Network
WTA
User
Agent
Request (Encoded)
WAE
User
Agent
WAP
Stack
(WAP-Gateway)
Request
Handling
Internet
HTTP Request
Coder /
Decoder
Response (Encoded)
Protocol
Gateway
WWW
Server
Content
HTTP Response
Abbildung 2.1.2/1 Die WAP Architektur, angelehnt an [Nisk99, S. 7].
2.1.2.1 WAP-Client
Unter WAP-Clients sind die mobilen Endgeräte zu verstehen. Dazu zählen
beispielsweise Handys, PDAs, etc. Damit diese für Wap-Dienste nutzbar sind, müssen
sie einige Komponenten aufweisen, die im folgenden erklärt werden. Anschließend
wird speziell auf die Einschränkungen der Handys eingegangen, da unsere
Anwendung für diesen Typ von Endgerät ausgelegt ist.
2.1.2.1.1 Komponenten
In jedem mobilen Endgerät (oder auch WAP-Client) muss ein WAE (Wireless
Application Environment) User Agent, ein WTA (Wireless Telephony Application) User
Agent und ein WAP-Stack enthalten sein.
5

Der WAP-Stack erlaubt den Versand und den Empfang der Daten mit den WAPProtokollen und kommuniziert mit dem WAP-Stack auf dem WAP-Gateway
(Protocol Gateway).

Der WAE User Agent ist nichts anderes als der WAP-Browser (Micro Browser). Er
erhält die Daten vom WAP-Gateway, muss diese dekodieren und für den Display
rendern [WeHa01, S. 11]. Der jetzige WAP-Standard unterstützt WML- und
WMLScript-Code oder WBMP-Grafiken (Wireless Bitmap).

Der WTA User Agent verwaltet Funktionen, die mit dem Endgerät selbst oder mit
dem Netzwerk zu tun haben. Erst mit der Einführung von GPRS können
Netzwerkfunktionen, wie beispielsweise Location Based Services, welche Dienste
sind, die auf der aktuellen Position des Benutzers basieren, eingesetzt werden.
Allerdings unterstützen die meisten Endgeräte diese noch nicht.
2.1.2.1.2 Einschränkungen mobiler Endgeräte
Unsere Zielsetzung war es, die WAP-Schnäppchenbörse für tragbare Mobiltelefone zu
konzipieren. Dabei waren Probleme zu bewältigen, die durch einige technische
Einschränkungen der Endgeräte bedingt waren und im folgenden erläutert werden.

Display
Eine Hürde bei der Implementierung von WML-Seiten, ist die Begrenzung der
Darstellbarkeit von Inhalten auf den sehr kleinen Displays der Endgeräte3. Die
begrenzte Ausgabefläche der Displays hat vor allem Auswirkungen auf die
Formulierung der Inhalte, da Sätze, die sich über viele Zeilen erstrecken, nicht
geeignet dargestellt werden können. Die Kunst ist es, präzise und kurze Begriffe
für die Inhalte, sowie für die Navigation zu finden, denn oft passen in eine Zeile
nicht mehr als 17 bis 30 Zeichen und die Displayhöhe fasst häufig nicht mehr als
drei bis dreieinhalb Zeilen. Da die verschiedenen Handy-Modelle unterschiedliche
Displays besitzen (bei einigen Modellen sind diese lediglich 110 x 45 Pixel groß4),
muss versucht werden, den kleinsten gemeinsamen Nenner, bei der Visualisierung
von Inhalten zu finden, um in allen Handys die gewünschte Darstellung zu
gewährleisten.
3
„Nach wie vor sind die kleinen Displays der Komplexität professioneller Anwendungen noch nicht
gewachsen.“ [Ross01, S. 47]
4
Das Nokia 7110 hat beispielsweise nur eine Displaygröße von 95x68 Pixel, das Ericcson R320 nur
101x52 Pixel [Imml01].
6

Sprache
Das Problem kann mit folgender Situation in der Projektarbeit veranschaulicht
werden: Wir wollten dem Kunden die Möglichkeit bieten, über sein Handy, sich
eine detaillierte Information über ein Fahrzeug seiner Wahl per Email zukommen
zu lassen. Wie sollte aber ein möglichst kurzer Menüpunkt lauten? Wie haben
„Email“ gewählt, allerdings könnte das auch als „eine Email an den Autohändler
schicken“ verstanden werden. „Infomail“ verwarfen wir, weil wir nicht Englisch und
Deutsch mischen durften. Die Texte müssen kurz und trotzdem aussagekräftig
sein. Dies ist vor allem in der deutschen Sprache sehr schwierig, da viele Wörter i.
d. R. um 50 – 120% länger sind als in der englischen Sprache.

Tastatur
Die Handytastatur ist eigentlich, aus der der technischen Perspektive betrachtet,
für das Telefonieren ausgelegt.5 Nur durch mehrmaliges Drücken auf ein Taste,
können die verschiedenen Buchstaben des Alphabets ausgewählt werden. Das ist
ein Grund, wieso dem Nutzer nur eine minimale Eingabe zugemutet werden sollte,
da es eine äußerst mühsame Aufgabe ist, längeren Text eingeben zu müssen.
Als Beispiel soll hier die Eingabe von Passwörtern kritisch betrachtet werden. Um
in den personalisierten Bereich der Schnäppchenbörse zu gelangen, muss sich
der Benutzer authentifizieren. WML bietet die Möglichkeit Textfelder eines
Formulars mit einem „*“-Symbol zu maskieren. Dies ist nicht sehr sinnvoll, da der
Benutzer nicht sehen kann was er eintippt. Das Ganze wird noch zusätzlich durch
den Zwang des mehrmaligen Drückens einer Taste, um einen bestimmten
Buchstaben zu wählen, erschwert, insbesondere dann, wenn ein Sonderzeichen,
wie z.B. „@“, gewählt werden soll.
Sofern ein Benutzer im System authentifiziert ist, belegen wir seine vorhandenen
Daten in Formularfelder vor, um jeden unnötigen Tippaufwand zu vermeiden.
Besonders dann, wenn man bedenkt, dass alle paar Sekunden ein €-Cent
Onlinegebühren anfallen.

Funktionstasten
Alle WAP-Handys haben zwei frei belegbare Funktionstasten unterhalb des
Displays. Diese können in WML-Seiten für bestimmte Funktionen verwendet
werden. Einige Handys besitzen bereits vordefinierte Tasten für die Funktionen:
OK, Zurück, Hilfe, Reset, Optionen oder Löschen. Genau das aber, ist der Grund
wieso wir in der Implementierung auf die Programmierung der Funktionstasten
verzichten mussten, denn die vordefinierten Funktionen für die Tasten variieren
von Gerät zu Gerät. Zur Lösung dieses Problems und zur Gewährleistung, dass
5
Kemper spricht hier von einer „verkrüppelten Tastatur“ [Kemp01].
7
auf allen Handys die Navigation einheitlich erscheint, verwendeten wir Links
anstelle der Funktionstasten, die wir am Seitenende platzierten.

Speicher
Die Endgeräte besitzen einen nicht zu unterschätzenden kleinen Speicher. Bei
unseren Tests auf verschiedenen Handys, erschienen oft Meldungen wie
„message-body too long“, die darauf hinwiesen, dass die gesendete WML-Seite
trotz Kodierung zu groß ist. Die in unserer Projektarbeit erfahrene
Schmerzensgrenze für eine WML-Seite, betrug 1 KB in kompilierter Form. Das ist
besonders dann problematisch, wenn man bedenkt, dass die WML-Seiten
dynamisch durch die Java Server Pages generiert werden. Soll beispielsweise
eine Liste der Fahrzeugmodelle als ein SELECT-Feld in einer WML-Card
dargestellt werden, so ist darauf zu achten, dass die Liste nicht allzu lang wird,
damit sie nicht die 1 KB-Grenze überschreitet. In solchen Fällen zwingen die noch
unzureichenden Speicherkapazitäten der Geräte die Programmierung, die zu groß
geratenen WML-Seiten in kleinere, getrennte Einheiten an das Handy zu schicken.

Handypuffer (Cache)
Eine aufgerufene WML-Seite wird im Handy-Cache zwischengespeichert. Hat der
Programmierer vergessen im Header der WML-Datei die Lebensdauer der Seite
auf 0 zu setzen, bleibt diese Seite so lange im Cache bis diese abgelaufen ist.
Dies ist von größter Wichtigkeit, da man in der Testphase zwar Simulatoren hat,
wie z.B. das Nokia Toolkit (vgl. Abschnitt 3.1), das auf regulären PCs läuft, jedoch
hat man i. d. R. nicht allzu viele Handys, bei denen man sich erlauben könnte, eine
Woche lang zu warten bis der Cache die Seite freigibt.

Bilder
WAP erlaubt die Integration von Bildern in WML Seiten. Das Format heißt WBMP
(Wireless Bitmap) und erlaubt lediglich eine Farbtiefe von 2 Bit. Die Idee der
Splash-Screens konnte sich nicht einmal im Web durchsetzen6. Wir haben
unseren anfänglich verwendeten Splash-Screen von unserer Startseite entfernt, da
er keinen zusätzlichen Nutzen für den Kunden bietet. Die Übertragungsleistungen
der Mobilfunknetzbetreiber sind noch zu gering und das Laden eines WBMPs
folglich zu langsam und zu teuer.

Trends
Die Zukunft weist auf eine immer wahrscheinlichere Konvergenz zwischen den
Handys und den PDAs hin, den so genannten Smart Phones [Ross01, S. 45].
Diese Geräte werden den Benutzern größere Farbdisplays, sowie einen größeren
Umfang an Funktionalitäten und eine bessere Bedienbarkeit bieten können. Die
6
Ein Splash-Screen ist meist ein Logo oder Bild das am Anfang eines Programms oder einer
Präsentation eingeblendet wird. Vgl. auch [Pusc01].
8
Endgerätehersteller sind bestrebt leistungsfähigere Geräte zu erzeugen, um die
neuen Mobilfunknetztechnologien auszuschöpfen7. Auch die quantitative
Verbreitung der mobilen Endgeräte wird stark zunehmen8.
2.1.2.2 Mobilfunknetz
Das Mobilfunknetz stellt die Netzinfrastruktur der mobilen Welt dar, das von den
Netzwerkbetreibern gestellt wird. Es besteht in der Regel aus Zellen. Jede Zelle wird
von einem Sende- und Empfangsmast9, mit einer bestimmten Reichweite10, gebildet.
2.1.2.2.1 Netze (GSM, HSCD, GRPS, EDGE-GMS, UMTS)
Es gibt eine Vielzahl von verschiedenen Mobilfunknetzen, die hier kurz erläutert
werden.

GSM 900/1800 (Global System for Mobile Communications) ist der in Europa
verwendete Standard für Mobiltelefonie [MoAh01], der eine vergleichsweise
geringe Datenübertragungsrate (durchschnittliche Geschwindigkeit 7.500 Bit/s)
aufweist.

HSCD (High Speed Circuit Switched Data) ist ein neuerer Standard im GSMSystem zur schnelleren Datenübertragung (durchschnittliche Geschwindigkeit
34.000 Bit/s).

EDGE-GSM (Enhanced Data Rates for GSM Evolution) ist noch eine Generation
weiter als GSM und soll Datenraten bis zu 384.000 Bit/s liefern. Es bietet eine
Wachstumschance für die Anbieter, die keine UMTS-Lizenzen erhalten haben
[MoAh01].

GPRS (General Packet Radio Service) ist ein Übertragungsstandard der schnell
genug ist (durchschnittliche Geschwindigkeit 40.000 Bit/s), um per Mobiltelefon mit
uneingeschränkter Farbdarstellung im Internet zu surfen. Die Abrechnung erfolgt
pro Datenpaket.
7
Beispiel 1: Das neue Nokia 7650 integriert alle Funktionen eines Mobiltelefons mit einer digitalen
Kamera und bietet zusätzliche Funktionen wie WAP, Kalender, Email, MMS (Multimedia Messaging
Service), Java VM, etc., an [Oebb02]. Beispiel 2: Das Modell Nokia 9210i integriert eine volle
Tastatur.
8
Die Gartner Group prognostiziert, dass im Jahr 2004 die Anzahl mobiler Endgeräte die der PCs mit
Internet–Zugang übersteigen wird [Ross01, S. 45].
9
Auch Antenne oder Basisstation (engl. BTS = Base Tranceiver Station).
10
Makrozellen haben eine Reichweite von mehreren Kilometern. Mikrozellen von einigen wenigen 100
Metern [WeHa01, S. 12].
9

UMTS (Universal Mobile Telecommunications System) ist ein schneller, internetfähiger Übertragungsstandard. Die sich noch im Aufbau befindenden UMTS-Netze
unterstützen auch GSM und WAP. Zu UMTS noch einige kritische Bemerkungen
[Ross01, S. 62 ff.]:

Finanzieller Aspekt
In Finnland wird bereits im Sommer 2002 die UMTS-Technologie zum Einsatz
kommen, während sie in Deutschland bis mindestens Mitte 2003 warten
muss11. Grund ist die Versteigerung der Lizenzen Mitte 2000, für die die
Mobilfunknetzbetreiber in Deutschland Milliardenbeträge zahlten. In anderen
europäischen Ländern waren die Investitionskosten für die Lizenzen wesentlich
geringer.

Technologischer Aspekt
Mit UMTS wurde ein breitbandiger mobiler Internet-Zugang mit 2 MBits/s
angepriesen. Jedoch zahlte man 99 Milliarden DM für das „paired band“, das
für symmetrische Kommunikation ausgelegt ist, aber nur 500 Millionen DM für
das „unpaired band“, das sich für asymmetrische Dienste12 eignet, wie
typischerweise das Modell Internet einer ist.

Technischer Aspekt
Hinzu kommt das Problem der Funkzellenatmung [Ross01, S. 66]. In UMTS
teilen sich alle Teilnehmer gleichzeitig die Bandbreite13, während beim jetzigen
GSM ein Teilnehmer nach dem anderen an der Reihe ist. Wächst die
Teilnehmerzahl,
so
schrumpft
die
Funkzelle
und
umgekehrt
(Funkzellenatmung). Effekt: Teilnehmer fallen aus dem Empfangsbereich der
Basisstation heraus. Es steht also nicht fest, mit welcher Datenrate der Kunde
zu rechnen hat. Zu erwarten sind 120 KBits/s.
2.1.2.2.2 Netzwerkbetreiber
Die Netzwerkbetreiber (in Deutschland: D1, D2, E-Plus, Viag, etc.) haben bezüglich
der Zellverteilung zwei Probleme zu lösen: die der Flächendeckung14 und die der
Netzkapazität15.
11
Gehört in den Nachrichten des Senders Bayern 5 Radio, Mai 2002.
12
Asymmetrische Dienste charakterisieren sich durch eine hohe Bandbreite zum Kunden und einem
relativ schmalbandigen Rückkanal, vergleichbar mit ADSL (in Deutschland).
13
UMTS nutzt hierfür das CDMA-Verfahren (Code Division Multiple Access).
14
Probleme entstehen meist in nicht so dicht besiedelten Gebieten. Für den Nutzer äußern sie sich als
Funklöcher.
10
2.1.2.3 WAP-Gateway
Der WAP-Gateway ist eher als ein Proxy Server als ein Gateway im eigentlichen
Sinne zu sehen, da er Anfragen bearbeitet (Request Handling), Daten temporär
speichert, sie kodiert und dekodiert und sich nicht nur auf das Weiterleiten von Daten
beschränkt.
Ein WAP-Gateway besteht aus zwei Komponenten:

Dem Protocol Gateway, der für die Übersetzung der WAP-Protokolle in InternetProtokolle zuständig ist.16

Dem Coder/Decoder (CODEC), der WML und WMLScript Dateien in ein für das
mobile Netz geeignete Binärformat WBXML (WAP Binary XML Content Format),
überträgt.
Das WAP-Gateway wird von den Mobilfunkbetreibern gestellt.
2.1.2.4 Contentprovider
Die Contentprovider stellen Inhalte bereit, die Benutzer mit ihren mobilen Endgeräten
abrufen können. Damit der Web-Servers WAP-Inhalte bedienen kann, ist dieser mit
folgenden MIME-Typen zu konfigurieren:
Datei-Endung
MIME-TYPE
Beschreibung
.wml
text/vnd.wap.wml
WML-Datei
.wmls
text/vnd.wap.wmlscript
WMLScript-Datei
.wbmp
image/vnd.wap.wbmp
WBMP-Grafik
Abbildung 3.2.4/1 Die WAP MIME-TYPEN
Von den Contentprovidern wird in Zukunft ganz entscheidend der Erfolg des WAPs
abhängen. Die wichtigste Frage ist, welche Kunden bereit sind für welche Dienste, wie
viel Geld auszugeben. Ohne Dienste die einen wahren Mehrwert bieten, wird der
Kunde nicht bereit sein, die anfänglich hohen Kosten für den Zugang zur mobilen Welt
zu zahlen.
15
In Ballungszentren kann es vorkommen, dass zu Stoßzeiten das Netz einfach zusammenbricht.
UMTS (Universal Mobile Telecommunications Systems) wird durch seine größere Bandbreite zu
mehr Stabilität und Kapazität führen.
16
Die Kommunikation zwischen WAP-Gateway und Web-Server (HTTP, TCP/IP) bzw. WAP-Gateway
und Endgerät (WAP) erfolgt mit zwei unterschiedlichen Protokollfamilien und muss daher übersetzt
werden.
11
2.1.2.5 Beispiel
Der WAE User Agent des Handys, baut mit dem WAP-Gateway des
Mobilfunknetzanbieters über das Mobilfunknetz Kontakt auf und fordert die
entsprechende Datei an. Der WAP-Stack im WAP Client kommuniziert mit dem
Protokoll-Stack im WAP-Gateway und sendet ihm den kodierten Request. Der WAPGateway stellt somit die Schnittstelle zwischen dem Mobilfunknetz und dem Internet
dar. Der CODEC des WAP-Gateways dekodiert die erhaltene Anfrage und ruft den
Web-Server auf, der den Content bereitstellt, und bittet um die besagte WML-Datei.
Dabei übersetzt der Protocol-Gateway die WAP-Protkolle in Web-Protokolle (HTTP
und TCP/IP). Der Web-Server sucht das WML-File und sendet es über HTTP (Hyper
Text Transfer Protocol) an den WAP-Gateway. Der CODEC des WAP-Gateways
wandelt den WML-Text in Binärcode um, der dann über das Funknetz wieder zum
Handy gesendet wird. Der WAP-STACK empfängt die Datei und letztendlich dekodiert
und interpretiert der Handy-Browser (Micro Browser) den Binärcode und zeigt den
Inhalt der Datei danach auf dem Display an.
2.1.3 WAP-Protokolle
Die Protokollfamilie des WAPs ist ein Schichtmodell, das fünf17 Schichten beinhaltet
(WAP-Stack). Es kommt bei der Kommunikation zwischen dem mobilen
Empfangsgerät und einem Verbindungspunkt, und zwischen dem Mobilnetz und dem
Internet, zur Anwendung [Bros00, S. 12].
WAP-Modell
Anwendungsschicht (WAE)
WWW-Modell
HTML, JavaScript, etc.
Sitzungsschicht (WSP)
HTTP
Transaktionsschicht(WTP)
Sicherheitsschicht (WTLS)
TLS v1.0
Transportschicht (WDP)
TCP, UDP
Trägerdienste (CSD, SMS, GPRS...)
IP, Datalink Layer, Physical Layer
Abbildung 2.1.3/1 Das WAP-Modell und das Web-Modell18.
17
In der Literatur werden oft nur die obersten 4 Schichten (WSP bis WDP) erwähnt. Vgl. auch mit
[WeHa01, S. 22].
18
Grafik angelehnt an [WeHa01, S. 25].
12

WAE (Wireless Application Environment) hat den Zweck, Inhalte zu erzeugen
(Content Generators19) und/oder darzustellen (Endgeräte). Zwei wesentliche
Elemente in den Endgeräten sind der Microbrowser (WAE User Agent), zur
Darstellung von Inhalten auf dem Bildschirm, und die Wireless Telephony
Application (WTA User Agent), mit denen sich Funktionen der Endgeräte steuern
lassen, z.B. integrierte Telefonbücher oder Terminplaner, etc. Diese in
Bibliotheken organisierten Funktionen, können über die WTA-Schnittstelle (WTAInterface20) durch WML (vgl. Abschnitt 2.1.4) oder WMLScript aufgerufen werden.

WSP (Wireless Session Protocol) etabliert, verwaltet und beendet Sitzungen
zwischen Client und Server.

WTP (Wireless Transaction Protocol) ist ein Übertragungsprotokoll, das auf
geringe Übertragungskapazität ausgerichtet ist und benötigt wird, um interaktiv mit
Anwendungen kommunizieren zu können [Bros00, S. 12].

WTLS (Wireless Transport Layer Security) ist ein optionales Element für
zusätzliche Sicherheit. Das Pendant im Internet war noch vor kurzem unter SSL
v3.0 bekannt21.

WDP (Wireless Datagramm Protocol) organisiert den eigentlichen Transport über
das Datenkabel.

Trägerdienste (engl. Bearer Services) oder auch Datendienste, werden von den
Mobilfunknetzbetreibern angeboten und bilden die Grundlage für WAP-Dienste
[WeHa01, S. 12]. Beispielsweise baut WAP auf dem Trägerdienst SMS (Short
Message Service) auf, bietet aber mehr Interaktionsmöglichkeiten und eine
größere Übertragungsleistung als dieser [Rich00], da ein SMS Datenpaket
lediglich auf 160 Bytes begrenzt ist. Der Trägerdienst CSD (Circuit-Switched Data)
stellt eine permanente Verbindung zum WAP-Gateway her und erreicht bis zu
9.600 Bits/s [WeHa01, S. 12].
19
Gemeint sind hier Anwendungen, die auf Webservern dynamische Inhalte erzeugen.
20
Siehe auch [VaTa00, S. 70]. Es wird unterschieden zwischen public , network-specific und networkcommon WTAI. Das public WTAI bietet zwei Funktionen: make call und send DTMF tones. Die
anderen beiden WTAIs haben einen wesentlich größeren Funktionsumfang, ihr Zugriff ist jedoch
restriktiver.
21
SSL (engl. Secure Sockets Layer) ist heute als TLS( Transport Layer Security) bekannt [WeHa01, S.
22].
13
2.1.4 WML (Wireless Markup Language)
WML stammt von XML (Extensible Markup Language) ab und ist eine
Seitenbeschreibungssprache zur Darstellung von Inhalten auf tragbaren Endgeräten.
Sie ist nicht so umfangreich wie HTML (Hyper Text Markup Language) und muss sich
strikt an die Dokumententypdefinition (DTD = DOCUMENT TYPE DEFINITION)
halten.
Jede WML- Datei ist vom MIME-Type22 „text/vnd.wap.wml“ und trägt die Endung
„.wml“. Im Dateikopf (Header) steht die XML-Version und der Verweis auf die
Definition des verwendeten Dokumententyps.
<?xml version=“1.0“ ?>
<! DOCTYPE wml PUBLIC “-//WAPFORUM//DTD WML 1.1/EN“ “http//www.wapforum.org/DTD/wml_1.1.xml“>
Eine WML-Datei (auch Deck oder Kartenstapel), wird komplett übertragen und in den
Handy-Speicher abgelegt. Ein Deck besteht aus mehreren Karten (engl. „cards“), in
denen die darzustellende Inhalte stehen. Eine WML-Datei kann theoretisch beliebig
viele Karten enthalten, jedoch stellen die Endgeräte nicht genügend Speicher zur
Verfügung, um eine allzu große Zahl an Karten aufnehmen zu können. Ist das Deck
geladen, kann man von Karte zu Karte springen. Ruft man jedoch eine Karte auf
einem anderen Deck auf, dauert das länger, da erst eine andere WML-Datei geladen
werden muss. Daher sollte man zusammengehörige Karten auf ein Deck platzieren
[MoAh01, S. 181].
Eine Möglichkeit WML-Seiten dynamischer zu gestalten, ist WMLScript zu verwenden.
Das Pendant in der HTML-Welt stellt Java Script dar. Beispielsweise kann man auch
Dienste der WTAI-Bibliothek (Wireless Telephony Applications Interface) in einem
WMLScript
verwenden,
um
einen
Anruf23
zu
starten:
„WTAPublic.makeCall(“5302645“);“. Allerdings müssen die Skripte als eigene Datei mit
der Endung .wmls gespeichert und schließlich vom Microbrowser separat geladen
werden. Eine WMLScript-Funktion wird stets von einem WML-Deck aufgerufen. Dabei
werden ihm eine oder mehrere Variablen mitgegeben. Wenn die Funktion der
aufgerufenen WMLScript-Datei durchgeführt wurde, gibt sie das Resultat in Form einer
oder mehrerer Variablen wieder an das WML-Deck zurück, von wo aus es dann auf
dem Display angezeigt wird.
In unserem Projekt verwenden wir nicht WMLScript, da wir die WML-Seiten durch die
Java Server Pages dynamisch generieren und so mit Daten versorgen.
22
MIME-Type (Multipurpose Internet Mail Extension) teilt dem Browser mit, welche Art von Datei an
ihn geschickt wird.
23
Auch ein Link in einer WML-Datei ist möglich: <go href=“wtai://wp/mc;$number“/>. Vgl. [Nisk99].
14
Probleme und Grenzen bei der Implementierung mit WML, bedingt durch die
Eigenschaften der mobilen Endgeräte, wurden in Abschnitt 2.1.2.1.2 beschrieben.
2.2 JSP (Java Server Pages)
JSP ist Teil von J2EE (Java 2 Enterprise Edition) und benutzt die JAVA Technology,
die durch ihre Plattformunabhängigkeit besticht: 'write once run anywhere’.
Damit JSP-Dateien interpretiert werden können, bedarf es der Installation des Tomcat
4.024, der wiederum das JDK 1.3 als installiert voraussetzt.
In unserem Projekt gehen die Anfragen der mobilen Clients zu den Java Servlets25.
Die Servlets selbst kommunizieren mit der Datenbank und starten Abfragen bzw.
modifizieren und erzeugen Daten mit SQL. Die JSP-Seiten werden in unserem
Anwendungsmodell von den Servlets mit Daten versorgt. Die JSP Engine führt die
JSP-Seiten aus und generiert dynamisch WML-Seiten, die zu den mobilen Clients
zurückgesendet werden.
Abbildung 2.2/1 Anwendungsmodell Servlet – JSP26.
Wenn eine JSP-Seite zum ersten Mal aufgerufen wird und folglich noch nicht im
Server existiert, wird diese in eine Java Servlet Klasse kompiliert und gespeichert. Das
ermöglicht sehr schnelle Antwortzeiten für spätere Anfragen auf diese Seite. Der
Vorteil liegt darin, dass die Seiten nicht jedes Mal neu kompiliert werden müssen.
Allerdings sind gerade diese Eigenschaften in der Entwicklungs- und Testphase
hinderlich. Theoretisch müsste der Tomcat die kompilierten Versionen löschen, wenn
eine neuere Version einer JSP-Seite auf den Server eingespielt wird. In unseren bei
der Projektarbeit gesammelten Erfahrungen, war es aber tatsächlich so, dass die alten
Dateien erst per Hand gelöscht werden mussten.
24
Tomcat 4.0, entwickelt von Apache Software Foundation's Jakarta Project, ist ein Open Source
Server und ein kostenloser Servlet Container und JSP Engine. Download unter:
http://jakarta.apache.org/tomcat.
25
Java Servlets sind eine Standard-Erweiterung von Java.
26
Grafik entnommen aus: http://java.sun.com/products/jsp/whitepaper.html.
15
3 Entwicklungstools in der Implementierungs- und Testphase
Nahm die Implementierung der Schnäppchenbörse schon immens viel Zeit in
Anspruch, so erst Recht das Fehlersuchen und Testen. Die Fehlersuche stellte sich oft
als sehr schwierig heraus, da die Fehlermeldungen in den Simulationsprogrammen27
auf den PCs und erst recht die auf den Handys, nicht sehr hilfreich waren, um
herauszufinden wo die Fehlerursache lag. In den folgenden Abschnitten sind die zwei
verwendeten Entwicklungstools erklärt, die zur Implementierung und zum Testen von
JSP und WML notwendig sind.
3.1 Nokia Toolkit 1.2
Unabhängig ob die Dateien auf dem WAP-Server oder auf dem lokalen Rechner
gespeichert sind, bietet das Nokia Toolkit eine Entwicklungsumgebung zur Simulation,
Fehlerfindung und Generierung von WML-Seiten. Da die WML-Seiten mit JSP
dynamisch generiert werden, erstellten wir mit dem Toolkit keine WML Dateien,
sondern betrachteten lediglich den Output der JSP-Seiten (Syntax und Visualisierung).
Das Toolkit zeigt die kompilierte Größe, die geschätzte Übertragungszeit, sowie die
Fehler einer WML-Datei an. Es überprüft die WML-Dateien rein auf Syntaxfehler. Oft
musste das Tool jedoch neu gestartet werden, da es immer wieder abstürzte.
Das Testen mit dem Handy selbst, erfolgte erst nach erfolgreicher Simulation, denn es
ist zu langsam und auch zu teuer für eine Fehlersuche.
3.2 JBuilder 4
Das Entwicklungstool von Borland eignet sich zur Programmierung von JAVAAnwendungen. Wir kreierten damit die Java Servlets und die JSP-Seiten. Letztere
konnten wir aber mit diesen Tool nicht simulieren, da der Output vom MIME-Type
WML in der Vorschau des JBuilders nicht dargestellt werden kann.
27
Man verwendet sog. Emulatoren, mit denen der Entwickler in der Lage ist, die Darstellung der WapSeite auf dem Computer oder dem Web zu simulieren [Pusc01].
16
4 Zusammenfassung
Das Projekt Schnäppchenbörse ist mittlerweile erfolgreich abgeschlossen. Anfangs
wurde es als eine B2C-Lösung implementiert und parallel bis Januar 2002, für die
AVAG, als B2B-Lösung angepasst und verkauft. Zusätzlich entwickelten wir in einer
zweiten Phase, personalisierte Elemente für unsere Schnäppchenbörse.
Die Technologie JSP hat sich als eine gute Lösung bei der Implementierung der
Schnäppchenbörse erwiesen. Was die WAP-Technologie betrifft, muss man diese
einer differenzierteren Betrachtung unterziehen. So mag WML durchwegs ausreichend
sein, um für mobile Endgeräte Inhalte zu generieren, die an Einfachheit nicht zu
bestechen sind. Aber die Aspekte der Endgeräte, der Mobilfunknetze und der
Contentprovider lassen eine isolierte Betrachtung nicht sinnvoll erscheinen.
Solange keine zuverlässige und effiziente Infrastruktur, leistungsstarke Endgeräte und
nutzenversprechende Inhalteanbieter dem WAP ein Fundament bieten, sind
Technologien wie WML alleine nicht ausbaufähig.
17
Literaturverzeichnis
[Bros00]
Brosius, F.: WML – die Wireless Markup Language. Addison-Wesley Verlag, München u.a.
2000.
[Imml01]
Immler C.: Gut geWAPnet – Mobiles Internet. Internet Intern o. Jg. (2001) 1, S. 125-133.
[Kemp01]
Kemper F.: Gesenkte Erwartungen. Internet World o. Jg. (2001) 7, S. 64-66.
[MoAh01]
Mocker H.; Mocker U.; Ahlreep J.: Handbuch E-COMMUNICATION. DatakontextFachverlag, Frechen 2001, S. 167-184.
[Nisk99]
Niskanen P.: Inside WAP – Programming Applications with WML and WMLScript. Addison
Wesley Verlag, London u.a. 1999.
[Oebb02]
Oebbeke A.: Special: Mobiles Leben. UNI COMPACT o. Jg. (2002) 1, S. 12-15.
[Pusc01]
Puscher F.: Die bessere WAP-Site. Internet World o. Jg. (2001) 7, S. 72-73.
[Rich00]
Richard, P. J.: Wap – Mobil im Internet. Smart Books Verlag, Kilchberg 2000.
[Ross01]
Rossbach G.: Mobile Internet / Deutscher Internet Kongress Karlsruhe 2001. dpunkt.verlag,
Heidelberg 2001.
[VaTa00]
Van der Heijden, M.; Taylor M.: Understanding WAP: Wireless Applications, Devices, and
Services. ARTECH HOUSE Verlag, Norwood 2000.
[WeHa01]
Wenz, C.; Hauser, T.: WAP – Architektur – Programmierung – Referenz. Hanser Verlag,
München u.a. 2001.