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
