Ausarbeitung
Werbung
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.
