Synchronisation mobiler Anwendungen auf Basis der Java 2 Micro Edition

Transkript

1 Fakultät II Informatik, Wirtschafts- und Rechtswissenschaften Department für Informatik Abteilung Systemsoftware und verteilte Systeme Individuelles Projekt Synchronisation mobiler Anwendungen auf Basis der Java 2 Micro Edition Jasper Mammen Nadorster Str Oldenburg Erstprüfer: Prof. Dr.-Ing. Oliver Theel Zweitprüfer: Dipl.-Inform. Philipp Hahn Oldenburg, den 30. August 2005

2 Zusammenfassung Die folgende Arbeit beschäftigt sich mit der Synchronisation von Anwendungen auf Basis der Java 2 Micro Edition (J2ME). Neben dem Aufbau und den grundlegenden Eigenschaften der J2ME werden gängige Verfahren des Datenaustauschs und der Datensynchronisation beschrieben. Die Verwendbarkeit dieser Verfahren im Rahmen der J2ME-Plattform wird mittels einiger Beispielanwendungen evaluiert. Die dabei gesammelten Erfahrungen werden dokumentiert und dienen als Basis eines Resümees bezüglich der heutigen Möglichkeiten und Einschränkungen der J2ME-Plattform. Abschließend wird ein Ausblick auf die zukünftige Entwicklung der J2ME gegeben.

3 Inhaltsverzeichnis 1 Einleitung 4 2 Die Java 2 Micro Edition Konfigurationen Die Connected, Limited Device Configuration (CLDC) Die Connected Device Configuration (CDC) Profile Das Mobile Information Device Profile (MIDP) Das Information Module Profile (IMP) Die Profile der CDC Optionale Pakete Das Personal Information Management und das FileConnection API Das Wireless Messaging API Die Java APIs für Bluetooth Das Remote Method Invocation Optional Package Die J2ME Web Services Specification Das JDBC Optional Package Sicherheit Datensynchronisation und J2ME Kommunikationsprotokolle in der J2ME: Das Generic Connection Framework Webservices Der Aufbau von Webservices Webservices in der J2ME

4 INHALTSVERZEICHNIS Einsatz von Webservices in mobilen Anwendungen SyncML Systemarchitekturen Protokolle und Verfahren Verwendung von SyncML auf Basis der J2ME Push Dienste Lokale Verbindungen via Bluetooth Praktische Evaluation Anforderungen Anwendung für Mensapläne Nutzung von Webservices Prototyp zur Datensynchronisation über SyncML Entwurf Architektur System Komponenten Server Struktur der Mensaplan-Anwendung Desktop-Relay SyncML-Prototyp Implementierung Verwendete Entwicklungsumgebung Mensaplan Servlet Mensaplan-Anwendung Desktop-Relay Mensaplan Webservice Mensaplan MIDlet mit Kommunikation via Webservice SyncML-Prototyp Resümee Beurteilung der Anwendungsentwicklung auf Basis der CLDC Vorteile der Entwicklung auf Basis der CLDC Probleme aufgrund der geringen Leistungsfähigkeit der Geräte

5 INHALTSVERZEICHNIS Schwierigkeiten aufgrund zu offener Spezifikationen Aus den Restriktionen der CLDC resultierende Probleme Fragmentation der CLDC-Plattform Konsequenzen für die Datensynchronisation mobiler Anwendungen Die zukünftige Entwicklung der CDC Fazit und Ausblick

6 Kapitel 1 Einleitung Der gängige Einsatzbereich von Computeranwendungen war lange Zeit der stationäre Desktop- Computer. Eine fortschreitende Miniaturisierung der technischen Komponenten des Computers ermöglicht jedoch in zunehmendem Maße die Realisierung von kleinen, leistungsfähigen, mobilen Geräten. Klassische Computeranwendungen, wie Textverarbeitung oder sind damit nicht länger an einen festen Arbeitsplatz gebunden, sondern können auch unterwegs verwendet werden. Darüber hinaus entstehen durch den Einsatz mobiler Geräte auch völlig neue Anwendungsfelder. Benutzer mobiler Anwendungen können wichtige Informationen an jedem Ort und zu jeder Zeit abrufen. Zudem können den Benutzern relevante Informationen auch in Abhängigkeit von ihrem derzeitigen Aufenthaltsort zur Verfügung gestellt werden (sogenannte Location-based Services). Über Anwendungen für solche mobile Szenarien wird zur Zeit viel diskutiert. Dabei müssen sowohl die Bedürfnisse der Nutzer, als auch die technische Machbarkeit berücksichtigt werden. Ein erster Überblick hinsichtlich der Vielfalt an verfügbaren mobilen Geräten lässt sich durch deren Einordnung in grundlegende Klassen mit ähnlicher Leistungsfähigkeit gewinnen. Am geringsten sind die Unterschiede zu den Desktop-Computern in der Klasse der Notebooks. Diese tragbaren Computer bieten eine den stationären Systemen zumeist ebenbürtige Leistung. Aus diesem Grund können auf den Notebooks auch die ursprünglich für Desktop-Computer entwickelten Anwendungen genutzt werden. Größe und Gewicht der Notebooks führen allerdings dazu, dass die Benutzer diese nicht ständig bei sich tragen, zudem wird die Mobilität durch einen vergleichsweise hohen Stromverbrauch eingeschränkt. Am anderen Ende der Leistungsfähigkeit findet sich die Geräteklasse der Mobiltelefone. Diese zeichnen sich vor allem durch geringe Größe und Stromverbrauch aus, und sind damit hinsichtlich der Mobilität klar im Vorteil die meisten Nutzer haben ihr Mobiltelefon ständig dabei. Dieser Vorteil wird jedoch mit geringer Rechen- und Speicherkapazität und einem kleinen Display erkauft, Anwendungen für Mobiltelefone müssen diese Limitationen berücksichtigen. Als Plattform für die Entwicklung von Anwendungen für diese Geräte hat sich die Java 2 Micro Edition (J2ME) etabliert, deren Möglichkeiten im Rahmen dieser Arbeit untersucht werden sollen. Zwischen den Notebooks und Mobiltelefonen findet sich eine weitere Klasse von mobilen Geräten,

7 5 die der Smartphones und PDAs. Ein PDA (Persönlicher Digitaler Assistent) ist ein tragbarer, kleiner Computer, der speziell der Verwaltung von Adressen und Terminen dient. Darüber hinaus können zusätzliche Anwendungen installiert werden. Die Hardware der PDAs stellt einen Kompromiss zwischen Leistungsfähigkeit und Mobilität dar: Rechen- und Speicherkapazität ermöglichen auch umfangreichere Anwendungen, auch die Größe des Displays ist zur Darstellung komplexerer Oberflächen geeignet. Zugleich sind die Geräte klein genug, um vom Benutzer ständig mitgeführt werden zu können, der relativ geringe Stromverbrauch bietet eine ausreichende Nutzungsdauer im mobilen Einsatz. Die Smartphones zeichnen sich durch ähnliche Eigenschaften aus, zusätzlich haben sie ein integriertes Mobiltelefon. Die Benutzer eines Smartphones können somit die Funktionalität von PDA und Mobiltelefon nutzen, ohne gleich zwei Geräte mit auf Reisen nehmen zu müssen. Aus diesem Grund haben auch die Hersteller klassischer PDAs damit begonnen, ihre Geräte um die Fähigkeit zum mobilen Telefonieren zu erweitern. Eine weitere Konvergenz der beiden Gerätearten ist zu erwarten. Auch für viele Smartphones und PDAs steht die Java 2 Micro Edition als Plattform zur Anwicklung mobiler Anwendungen zu Verfügung. Daneben können Anwendungen für diese Geräte auch nativ für das jeweilige Betriebssystem entwickelt werden. Die heute gängigen Plattformen sind Embedded Linux, PalmOS, SymbianOS und Windows Mobile. Anwendungen auf mobilen Geräten sind häufig Bestandteil umfangreicherer Informationssysteme. Sie stehen in Interaktion mit stationären Desktop-Rechnern oder Servern, von denen sie spezifische Daten beziehen, oder an die sie im mobilen Einsatz entstandene Modifikationen zurückliefern. Es stehen einige standardisierte Verfahren zur Verfügung, Daten zwischen Computersystemen auszutauschen und abzugleichen. Inwieweit durch die Limitationen der mobilen Geräte die Verwendbarkeit dieser Verfahren eingeschränkt wird, soll im Rahmen der folgenden Arbeit in Erfahrung gebracht werden. Dabei wird als Grundlage der Entwicklung mobiler Anwendungen die Java 2 Micro Edition Gegenstand der Untersuchung sein. Sie ist plattformübergreifend auf einer Vielzahl an Geräten verfügbar. Laut Herstellerangaben wurden bis Mitte 2005 über 700 Millionen Geräte mit einer Unterstützung für die J2ME ausgeliefert [c t05b]. Bislang wurden allerdings hauptsächlich kleinere Spiele auf Basis der J2ME erstellt. Ob der Entwicklungsstand der Plattform mittlerweile auch die Realisierung komplexerer mobiler Anwendungen erlaubt, soll anhand der Implementierung einiger Beispielanwendungen und Prototypen überprüft werden. Im folgenden Kapitel werden die Struktur, die Möglichkeiten und die Einschränkungen der J2ME Plattform erläutert. Kapitel 3 beinhaltet eine nähere Betrachtung von Konzepten und Anforderungen, die die Datensynchronisation von Anwendungen mit sich bringen. Dabei wird auch auf die Möglichkeiten der Realisierung im Rahmen der Entwicklung mit der J2ME eingegangen. In Kapitel 4 werden die Ergebnisse einer praktischen Evaluation, bestehend aus Konzeption und Implementierung von Beispielanwendungen und Prototypen dokumentiert. Abschließend wird im letzten Kapitel aus den vorangegangenen Überlegungen und den gesammelten Erfahrungen bei der Umsetzung ein Resümee bezüglich der momentanen Möglichkeiten der J2ME Plattform gezogen, sowie ein Ausblick auf die zukünftige Entwicklung in diesem Bereich zu geben versucht.

8 Kapitel 2 Die Java 2 Micro Edition Die Java 2 Micro Edition ist eine Java Plattform für ressourcenbeschränkte Geräte wie Mobiltelefone, PDAs, Smartphones, Auto-Navigationssysteme oder Settop-Boxen. Es handelt sich analog zur Java 2 Standard Edition um eine interpretierte Sprache, deren Bytecode auf einer Virtuellen Maschine ausgeführt wird, die auf den jeweiligen proprietären Betriebssystemen der Geräte aufsetzt. Es gibt jedoch eine Reihe von Unterschieden zur Standard Edition, die im folgenden erläutert werden. Die Java 2 Micro Edition existiert seit 1999, als Sun Microsystems beschloss, die im Laufe der Jahre sehr umfangreich gewordene Java Plattform in drei Editionen aufzuteilen: die Java 2 Enterprise Edition (J2EE) für serverseitige Lösungen, die Java 2 Standard Edition (J2SE) für Desktop-Applikationen und die Java 2 Micro Edition (J2ME) für ressourcenbeschränkte Geräte [SUN99]. Zu diesem Zeitpunkt gab es eine steigende Nachfrage nach Java basierten Lösungen für kleine Geräte, und es entstanden für diese Zwecke einige von Java 1.1 abgeleitete Plattformen mit reduzierter Funktionalität (bspw. EmbeddedJava [SUNa] oder PersonalJava [SUNd]). Die J2ME sollte hier eine Vereinheitlichung der Entwicklung für kleine Geräte ermöglichen. Bedingt durch die differenzierten Eigenschaften der Vielzahl ressourcenbeschränkter Geräte mussten jedoch, im Gegensatz zu den Desktop- und Servereditionen, heterogenere Anforderungen erfüllt werden. Aus diesem Grund besteht die J2ME nicht aus einer einzelnen, sondern aus einer Sammlung von Spezifikationen. Die Eigenschaften eines Gerätes werden dabei durch ein oder mehrere Profile spezifiziert, die jeweils auf den Grundfunktionen einer Konfiguration basieren. Zusätzlich können optionale Pakete für spezielle oder neue Leistungsmerkmale eines Gerätes hinzukommen. Eine Herausforderung bei der Entwicklung der J2ME bedeutet die Gewährleistung der Plattformunabhängigkeit auf den unterschiedlichen Geräten. Sämtliche Spezifikationen der J2ME entstehen aus diesem Grund im Rahmen des Java Community Process [JCPa] unter Beteiligung verschiedenster Firmen der Informationstechnologie- und Telekommunikationsbranche. Der JCP wurde Ende 1998 von Sun Microsystems initiiert, um einen formalen aber schnellen Weg der kooperativen Entwicklung und Aktualisierung von Java Spezifikationen zu ermöglichen. Vorschläge zu neuen Java- Technologien oder Bibliotheken heißen Java Specification Requests (JSR) und durchlaufen einen partizipativen, durch Meilensteine bestimmten Prozess [JCPb], an dessen Ende in der Regel neben der Spezifikation auch eine Referenzimplementierung sowie eine umfangreiche Testsuite zur Zertifizierung spezifikationskonformer Implementierungen stehen.

9 2.1 KONFIGURATIONEN 7 Abbildung 2.1: Konfigurationen, Profile und optionale Pakete (aus [Sch04]) Es obliegt dann den Hardwareherstellern, die Spezifikationen für ihre Geräte zu implementieren. Das Bestehen der Kompatibilitätstests wird durch Sun überprüft und zertifiziert. Die enge Kooperation der beteiligten Unternehmen sichert die standardisierte Umsetzung und größtmögliche Verbreitung auf einer Vielzahl von Geräten unterschiedlicher Hersteller. Sämtliche Spezifikationen der J2ME sind im Rahmen des JCP erarbeitet worden, auf dessen Webseiten detailierte Informationen zu den einzelnen JSRs zugänglich sind [JSRa]. Insbesondere finden sich dort die Informationen zu allen, im Folgenden näher betrachteten JSRs. Auf die jeweilige explizite Angabe der Quelle wird daher verzichtet. 2.1 Konfigurationen Eine Konfiguration stellt die unterste Schicht der J2ME-Architektur dar. Es wird jeweils eine virtuelle Maschine und eine Klassenbibliothek mit grundlegender Funktionalität für die darauf aufbauenden Profile und optionalen Pakete zur Verfügung gestellt. Eine Konfiguration beschreibt somit eine allgemeinere Klasse von Geräten, während die Profile stärker auf spezielle Gerätetypen zugeschnitten sind. Momentan sind zwei verschiedene Konfigurationen spezifiziert: Die Connected Device Configuration (CDC) im JSR-36 und die Connected, Limited Device Configuration (CLDC) im JSR-30. Sie unterscheiden sich hinsichtlich ihres Funktionsumfanges und den daraus resultierenden Anforderungen an die Hardware der Geräte. Bedingt durch die Abhängigkeit der Profile von den Eigenschaften der zu Grunde liegenden Konfiguration ergeben sich innerhalb der J2ME zwei getrennte Säulen Die Connected, Limited Device Configuration (CLDC) Die CLDC wurde für kleinste Geräte, wie Mobiltelefone, Smartphones und PDAs entworfen, die eine begrenzte Rechenleistung, geringe Speicherkapazität und niedrige Bandbreite der Netzverbindung aufweisen. Von der benötigten Speicherkapazität (160 bis 512 Kilobyte) leitet sich auch der

10 2.1 KONFIGURATIONEN 8 Name der verwendeten virtuellen Maschine ab KVM steht für Kilobyte Virtual Machine. Um eine Java-Laufzeitumgebung trotz dieser begrenzter Ressourcen zu realisieren, mussten einige Einschränkungen bezüglich der Sprache selbst, der virtuellen Maschine und der Kernbibliotheken vorgenommen werden. Unter anderem bietet die KVM keine Fließkomma-Arithmetik, da die Hardware vieler Geräte dies nicht unterstützt und eine Implementation in Software relativ rechen- und speicherintensiv wäre. fehlt der KVM die Fähigkeit zur Introspektion aus java.lang.reflect. Damit sind auch darauf aufbauende Technologien wie Objekt-Serialisierung und Remote Method Invokation nicht einsetzbar. (Siehe Kapitel 3) fehlen im Vergleich zur J2SE in Paketen einige Klassen (bspw. in java.util das Collection Framework), oder die Methoden der Klassen wurden reduziert (bspw. fehlt in java.util.date u.a. die tostring() Methode). wurde das Sicherheitsmodell gegenüber der J2SE vereinfacht. Dies hat zur Folge, daß der Aufruf nativer Funktionen via Java Native Interface (JNI) nicht möglich ist, ebensowenig erlaubt die KVM benutzerdefinierte Class Loader (Siehe Kapitel 2.4). musste das Verfahren zur Verifizierung des Bytecodes geändert werden. Die KVM übernimmt nur einen Teil dieses Prozesses der rechen- und speicherintensive Part, Preverification genannt, wird schon bei der Erstellung der Anwendung vorgenommen (Siehe Kapitel 2.4). unterstützt die KVM zwar nebenläufige Threads, allerdings keine ausgefeilteren Funktionen, wie Thread-Groups oder Daemon-Threads. ist die Größe von Anwendungen auf maximal 64 Kilobyte beschränkt. Die parallele Ausführung mehrerer Anwendungen ist nicht möglich. wurde die Speicherverwaltung (Garbage Collection) den Einschränkungen angepasst. Entfernt wurden dabei auch alle Möglichkeiten der Anwendung, auf die Speicherverwaltung Einfluss zu nehmen. Trotz dieser Einschränkungen wurde die Konsistenz zur Klassenbibliothek der J2SE in weiten Teilen erreicht. Die CLDC besteht aus den Paketen java.lang (Fundamentale Klassen), java.util (Kollektionen, Datum und Uhrzeit, Zufallszahlengenerator) und java.io (Stream- und Readerklassen für Ein- und Ausgaben), welche eine echte Teilmenge der gleichnamigen Klassen der J2SE darstellen. Änderungen sind durch die oben angeführten Limitationen der KVM, sowie die Bereinigung von veralteten Methoden und Klassen bedingt. Die Verwaltung von Netzwerkverbindungen, die sich bei der Standard Edition im Paket java.net findet, wurde umstrukturiert: Die CLDC bringt einen einheitlichen Ansatz zum Behandeln von Verbindungen, das Generic Connection Framework (GCF), das im Paket javax.microedition.io untergebracht ist. Die CLDC selbst spezifiziert jedoch nur allgemeine Schnittstellen, während die konkreten Verbindungsprotokolle in den Profilen implementiert werden. Anfang 2003 wurde die Version 1.1 der CLDC-Spezifikation fertiggestellt (JSR-139), die hauptsächlich die Unterstützung von Fließkommaoperationen festschreibt. Die Verbreitung kompatibler Geräte ist momentan recht gering. Zudem gibt es noch kein Profil, welches diese Version explizit erfordern

11 2.2 PROFILE 9 würde Die Connected Device Configuration (CDC) Bezüglich Rechenleistung und Speicher findet sich zwischen den kleinsten mobilen Geräten und der Desktop Welt, eine weitere Klasse von Geräten, für die die Connected Device Configuration (CDC) gedacht ist. Dazu gehören größere PDAs, Navigations- bzw. Multimediasysteme für das Auto oder TV- Settop Boxen. Die typische Hardware dieser Klasse von Geräten besteht aus einem 32-bit Prozessor, mindestens zwei Megabyte Speicher sowie einer oft dauerhaften Netzverbindung mit vergleichsweise hoher Bandbreite. Somit ist in der CDC eine vollständige virtuelle Maschine vorgesehen, die auf geringen Speicherbedarf optimiert wurde, die Compact Virtual Machine (CVM). Im Vergleich zur VM der Standard Edition ist die Garbage Collection der geringeren Speicherausstattung angepasst, und es fehlen die Hotspot Techniken zur Laufzeitoptimierung funktional sind beide jedoch identisch. Die Klassenbibliothek der CDC bildet nur eine minimale Basis. Zusammen mit den darauf aufbauenden Profilen ergibt sich jedoch ein relativ vollständiges Abbild des Kerns der J2SE API in Version 1.3 (Siehe Kapitel 2.2.3). Im Zuge der Weiterentwicklung der CDC Plattform (JSRs 216 bis 219) soll weitestgehende Kompatibilität zur Version 1.4 der J2SE erreicht werden. Möglich scheint dies nicht zuletzt durch die steigende Leistungsfähigkeit der Hardware dieser Geräteklasse. 2.2 Profile Die Profile bauen auf den Basisfunktionalitäten der Konfigurationen auf und sind stärker auf einen bestimmten Gerätetyp zugeschnitten. Sie beinhalten beispielsweise Schnittstellen zur Ein-/Ausgabe oder zur persistenten Datenhaltung. Oberhalb der CLDC sind zwei Profile spezifiziert: das Mobile Information Device Profile (MIDP), welches sich den Möglichkeiten und Einschränkungen von Mobiltelefonen und Smartphones widmet, und das Information Module Profile (IMP) für per Mobilfunk vernetzte Systeme, beispielsweise in Getränkeautomaten. Die Arbeit an einem weiteren auf der CLDC basierenden Profil, dem PDA Profile (PDAP), wurde mittlerweile eingestellt. Stattdessen soll die für PDAs benötigte Funktionalität durch zwei optionale Pakete für das MIDP realisiert werden (Siehe Kapitel 2.3.1). Auf der Seite der CDC existieren drei Profile, die aufeinander aufbauen und sich im Wesentlichen durch den Umfang der Unterstützung graphischer Oberflächen unterscheiden Das Mobile Information Device Profile (MIDP) Das am weitesten verbreitete Profil der J2ME ist das Mobile Information Device Profile (MIDP). Die große Mehrzahl an Mobiltelefonen oder Smartphones wird heute mit Unterstützung für Java und damit dem MIDP ausgeliefert. Anwendungen für das MIDP, sogenannte Midlets, durchlaufen während der Ausführung einen Lebenszyklus ähnlich dem der Java Applets. Gesteuert wird dieser von einer speziellen, in jedem MIDP

12 2.2 PROFILE 10 Paket java.microedition.io java.microedition.midlet java.microedition.lcdui javax.microedition.game javax.microedition.media javax.microedition.pki javax.microedition.rms Inhalt Das Generic Connection Framework ist im MIDP um Deklarationen für die Protokolle UDP, HTTP, HTTPS und SSL sowie für die Kommunikation über serielle Schnittstellen erweitert. Grundfunktionalität für Applikationen, unter anderem Steuerung des Lebenszyklus. Das Lowest Common Denominator Interface (LCDUI) unterstützt die Implementierung von Bedienoberflächen. Das Game API vereinfacht die Programmierung von 2D-Spielen. Das MIDP 2.0 Media API (M2MAPI) dient der Wiedergabe und Aufzeichnung von Medien. Dieses Paket repräsentiert Zertifikate einer Pubic Key Infrastructure. Die Zertifikate werden unter anderem bei sicheren Verbindungen über SSL und HTTPS eingesetzt. Das Record-Management-System (RMS) ist eine einfache, satzorientierte Datenbankschnittstelle, über die sich persistente Daten im Endgerät verwalten lassen. Tabelle 2.1: Pakete des MIDP 2.0 Profils kompatiblen Gerät vorhandenen Komponente, der Application Management Software (AMS), die auch für Installation, Updates und die Einhaltung des Sicherheitskontextes verantwortlich ist. Die AMS steuert immer nur eine Anwendung, die gleichzeitige Ausführung mehrerer Anwendungen (Multitasking) ist nicht möglich. Das MIDP beinhaltet eine eigene, nicht zum AWT oder Swing kompatible Benutzungsschnittstelle (javax.microedition.lcdui). Diese gliedert sich in einen Low-Level Teil, der einen vollen Zugriff auf das Display des Gerätes bietet, und eine High-Level API, die eine einfache Verwendung gängiger Elemente wie Dialoge, Formulare oder Listen ermöglicht. Die konkrete Ausgestaltung und Anordnung dieser Elemente geschieht entsprechend des gerätespezifischen Look-and-Feel weitgehend automatisch. Mit dem Record-Management-System (RMS) wird eine Schnittstelle für die persistente Datenhaltung integriert, und das Generic Connection Framework wird im MIDP um die Protokolle UDP und HTTP erweitert. Aufbauend auf der in JSR-37 spezifizierten ersten Version des MIDP gibt es seit Ende 2002 das MIDP in Version 2.0 (JSR-118). Es bringt ein neues, feiner abgestuftes Sicherheitsmodell inklusive der Möglichkeit zur automatischen Aktivierung von Programmen über das Netz mittels Push Registry (siehe Kapitel 3.4). Die Fähigkeiten der Benutzeroberfläche wurden erweitert, sowie eigene Schnitt-

13 2.2 PROFILE 11 stellen für Multimedia- und Spielfunktionalitäten hinzugefügt. MIDP 2.0 ist ungefähr seit Mitte 2004 das gängige Profil neuer Mobiltelefone. Einen guten Anhaltspunkt bieten die Grafikfähigkeiten des Gerätes: Ist ein Farbdisplay vorhanden, wurde in den meisten Fällen auch die Version 2.0 des MIDP implementiert. Angesichts der hohen Verbreitung dieses Profils und der umfassenden Beteiligung von Geräteherstellern und Mobilfunkprovidern am Spezifikationsprozess scheint die Weiterentwicklung gesichert zu sein. Die Arbeiten an der nächsten Version (JSR-271) laufen momentan und sollen im Laufe des Jahres 2006 abgeschlossen werden Das Information Module Profile (IMP) Das Einsatzgebiet des Information Module Profile (IMP) sind Module im Bereich der Machine-to- Machine-Kommunikation, die Mobilfunknetze nur zur Datenübertragung verwenden und keine Benutzungsoberfläche benötigen. Diese Module finden sich als Komponenten beispielsweise in Automaten oder Ortungseinheiten. So könnte ein Getränkeautomat mit dem IMP selbständig Nachschub ordern, oder ein Nutzer könnte die aktuelle Position eines IMP-Gerätes mit angeschlossenem GPS- Empfänger feststellen. Das IMP in Version 1.0 (JSR-195) stellt eine echte Teilmenge des MIDP 1.0 dar. Version 2.0 (JSR- 228) basiert auf dem MIDP 2.0 und erbt damit auch dessen Sicherheitsfunktionalitäten und die Möglichkeit der Aktivierung über das Netz. Via GCF können auch serielle Schnittstellen genutzt werden, um Leuchtanzeigen oder kleine LCDs anzusteuern Die Profile der CDC Die CDC-basierten Profile sind durchweg an die J2SE in Version 1.3 angelehnt, um die Erstellung von mobilen Anwendungen für Entwickler mit Java Kenntnissen zu erleichtern. Das Foundation Profile (JSR-46) erweitert die CDC nahezu vollständig um den Kern der J2SE API, ergänzt um das Paket javax.microedition.io, zur leichteren Portierung von CLDC-Anwendungen, bietet aber keinerlei Funktionalität im Bezug auf graphische Oberflächen. Das Personal Basis Profile (JSR-129) beinhaltet das Foundation Profile und stellt zusätzlich einen Teil des Abstract Window Toolkit (AWT) für einfache graphische Oberflächen zur Verfügung. Das Personal Profile (JSR-62) beinhaltet beide vorigen Profile und bietet neben der vollständigen AWT-API auch die Verwendung von Applets. Es ist zudem zur Migration von Anwendungen des JDK 1.1 basierten J2ME-Vorgängers PersonalJava vorgesehen. Durch diese Abstufung der graphischen Darstellungsmöglichkeiten eignen sich die Profile der CDC für relativ unterschiedliche Geräte. Je nach Eigenschaften der Benutzungsoberfläche muss nur der hierfür nötige Teil der Profile zur Verfügung gestellt werden. Zukünftig soll die J2SE API auch in Version 1.4 umgesetzt werden, die Weiterentwicklung der CDC und der zugehörigen Profile findet sich in den JSRs 216 bis 219. Zusätzlich ist zur Gestaltung anspruchsvoller grafischer Oberflächen mit dem Advanced Graphics and User Interface Optional Package (JSR-209) eine Implementierung des Swing-Frameworks geplant, die auf der nächsten Version des Personal Profile aufbauen soll.

14 2.3 OPTIONALE PAKETE Optionale Pakete Optionale Pakete stellen Funktionalitäten bereit, die nur für spezielle Anwendungen relevant sind oder von Hardwaremerkmalen abhängen, die nicht unbedingt in allen Geräten einer Klasse vorhanden sind. Die optionalen Pakete ermöglichen eine verbesserte Nutzung der Eigenschaften der Ablaufumgebung durch die J2ME-Anwendungen und schließen damit die Lücke zu den nativen Anwendungen. Andererseits sinkt die Portabilität von Anwendungen, die optionale Pakete voraussetzen, und es entsteht die Gefahr einer weiteren Fragmentierung der J2ME-Plattform. Ein Versuch, dieser Problematik entgegenzuwirken, stellt die aus dem JSR-185 hervorgegangene Spezifikation Java Technology for the Wireless Industrie (JTWI) dar. Sie ergänzt das MIDP um die optionalen Pakete Wireless Messaging und Mobile Media API und fordert zusätzlich ein Farbdisplay mit höherer Auflösung. Damit sollen die Grundfunktionalitäten momentan gängiger Mobiltelefone für J2ME-Anwendungen bereitgestellt, und das Ganze mit einem prägnanten Label versehen werden. Im Folgenden werden einige optionalen Pakete kurz vorgestellt, die im Kontext der Personalisierung und der Datenübertragung und -synchronisation von besonderem Interesse sind Das Personal Information Management und das FileConnection API Die Spezifikation zum Personal Information Management (PIM) API findet sich im JSR-75. Ursprünglich vorgesehen war die Definition eines eigenständigen Profils für PDAs auf Basis der CLDC, dieser Plan wurde jedoch verworfen. Stattdessen sollen zwei separate, optionale Pakete für das MIDP die für PDAs benötigte Funktionalität realisieren: Das FileConnection API für den Zugriff auf das Dateisystem des Gerätes bzw. von Speicherkarten, sowie das PIM API als Schnittstelle zu den internen Datenbanken für Kalender, Telefonbuch und To-Do-Listen. Beide Funktionen werfen Fragen der Sicherheit auf, die erst auf Basis des MIDP 2 Profils zufriedenstellend gelöst werden konnten. Die Spezifikationen wurden im Juni 2004 verabschiedet, erste Geräte, die diese APIs implementieren, sind seit dem Frühjahr 2005 verfügbar Das Wireless Messaging API Das im JSR-120 spezifizierte Wireless Messaging API (WMA) ermöglicht J2ME-Anwendungen den Zugriff auf die Sende- bzw. Empfangsschnittstelle für Kurzmitteilungen (SMS). Dies können neben normalen Textmitteilungen auch Binärnachrichten sein. Die Verbindung wird wie bei der CLDC üblich über das Generic Connection Framework abgewickelt die URL besteht dabei aus dem Protokollnamen sms:// gefolgt von der Telefonummer des Empfängers. Der Empfang von Kurznachrichten erfolgt durch eine laufende Anwendung oder per Aktivierung über die Push Registry, wozu eine Portnummer zur Identifikation an die URL angehängt werden muss. Version 2.0 der WMA (JSR-205) unterstützt zusätzlich auch den Multimedia Message Service MMS, über den verschiedene Formate (Texte, Bilder, Audio oder Video) mit einer Nachricht verschickt werden können.

15 2.3 OPTIONALE PAKETE Die Java APIs für Bluetooth Bluetooth ist eine Technologie zur drahtlosen Datenübertragung auf kurzen Distanzen. Für die J2ME steht ein in JSR-82 spezifiziertes optionales Paket zur Verfügung, welches Schnittstellen zur Kommunikation über Bluetooth-Verbindungen bietet. Das API fällt recht umfangreich aus, da neben verschiedenen, aufeinander aufbauenden Protokollen auch die Suche nach Diensten bzw. Geräten, sowie Sende- und Empfangsschnittstellen enthalten sind (mehr dazu in Kapitel 3.5) Das Remote Method Invocation Optional Package Die Remote Method Invocation (RMI) [RMI] ermöglicht innerhalb der Java Plattform den Aufruf von Methoden entfernter Objekte, sogenannte Remote Procedure Calls (RPC). Für den Entwickler geschieht der Vorgang recht transparent, ein entfernter Methodenaufruf unterscheidet sich kaum von einem lokalen die Kommunikationsfunktionen sind in einer automatisch generierbaren Klasse, dem Stub, gekapselt. Die RMI API (JSR-66) steht als optionales Paket ausschließlich für die CDC zur Verfügung. Es beinhaltet nur die für Clients benötigte Funktionalität, Serverdienste können auf mobilen Geräten nicht angeboten werden Die J2ME Web Services Specification Die Web Services ermöglichen es, ähnlich den RPCs, auf die Funktionalität entfernter Komponenten zuzugreifen. Im Gegensatz zur auf die Java Welt beschränkten RMI verwenden Web Services jedoch eine auf der Extensible Markup Language (XML) basierende standardisierte Kodierung, welche einen hohen Grad an Interoperabilität gewährleisten soll. JSR-172 spezifiziert eine Schnittstelle zur Nutzung von Web Services mit der J2ME die serverseitige Bereitstellung von Diensten entfällt auch hier. Da die Profile der CLDC den Umgang mit XML- Dokumenten nicht beherrschen, bringt das Paket neben der Unterstützung des zur Kommunikation verwendeten Simple Object Access Protocols (SOAP) auch einen XML Parser mit (mehr dazu in Kapitel 3.2) Das JDBC Optional Package Java Database Connectivity (JDBC) bezeichnet eine einheitliche Schnittstelle zu relationalen Datenbanken verschiedener Hersteller auf der Java-Plattform. Die API beinhaltet den Aufbau von Datenbankverbindungen, die Übermittlung von SQL-Abfragen und die Transformation und Bereitstellung der gelieferten Ergebnisse für das Java Programm. Das optionale JDBC Paket (JSR-169) ermöglicht einen direkten Datenbankzugriff für mobile Anwendungen, ist allerdings nur auf Basis der CDC spezifiziert. Das API stellt eine echte Teilmenge des java.sql Paketes aus der Standard Edition dar.

16 2.4 SICHERHEIT Sicherheit Die Nutzung von Anwendungen auf mobilen Geräten stellt an die Ablaufumgebung hohe Anforderungen bezüglich der Sicherheit. Diese muss einerseits gewährleisten, dass eine fehlerhafte Anwendung nicht zu einem Absturz des Gerätes führen oder Systemdaten (beispielsweise die des Adressbuchs) korrumpieren kann, andererseits muss auch der Zugriff auf bestimmte Ressourcen des Systems überwacht werden. So sollte zum Beispiel eine Netzverbindung nur dann aufgebaut werden können, wenn der Benutzer dies auch wünscht. Die Java 2 Standard Edition verfügt über ein umfangreiches Sicherheitsmodell, mit dessen Hilfe Code aus unterschiedlichen Quellen ein differenzierter Zugriff auf Systemressourcen gewährt werden kann. In der CDC sind diese Sicherheitsfunktionen ebenfalls vorhanden, die CLDC muss wegen der Ressourcenbeschränkungen darauf verzichten. Aus diesem Grund ist die virtuelle Maschine der CLDC sehr restriktiv konzipiert. Sie erlaubt keine Aufrufe nativer Funktionen, ebensowenig benutzerdefinierte Class Loader. Die einzige Möglichkeit, diese Beschränkungen zu umgehen, besteht in der Modifizierung der KVM selbst dies ist jedoch im Allgemeinen nur den Herstellern der Geräte möglich. Als Konsequenz daraus können auf die CLDC gründende Profile und optionale Pakete nicht nachträglich installiert werden. Eigene Erweiterungen zur Nutzung nativer Komponenten sind ebenfalls nicht realisierbar. Auch das Verfahren zur Verifizierung des Bytecodes einer Anwendung musste modifiziert werden. In der J2SE werden alle aus externen Quellen geladenen Klassen einem Integritätscheck unterzogen, um die Sicherheit des Systems zu gewährleisten. Dieser Algorithmus hätte die begrenzten Ressourcen mobiler Geräte überfordert; so kommt für die CLDC stattdessen ein zweistufiges Verfahren zum Einsatz, bei dem der rechen- und speicherintensive Teil, die sogenannte Preverification, schon bei der Erstellung der Anwendung vorgenommen wird. Dabei werden spezielle StackMap-Attribute in die.class Datei eingefügt, welche die Verifikation zur Laufzeit wesentlich vereinfachen. Für den Zugriff auf Sicherheitskritische Ressourcen über die APIs der J2ME wurde in Version 2.0 der MIDP-Spezifikation ein neues Berechtigungsmodell eingeführt. Nötig wurde dies nicht zuletzt durch eine steigende Anzahl von Paketen, die auf native Ressourcen zugreifen, beispielsweise auf das Dateisystem der Geräte, interne Datenbanken oder spezielle Funkverbindungen, wie Bluetooth, Push-Dienste oder SMS. Anwendungen, deren Integrität durch ein Zertifikat überprüft werden kann, werden als vertrauenswürdig (trusted) eingestuft. Allen anderen (also auch allen MIDP 1.0 kompatiblen) verwehrt die Laufzeitumgebung den Zugriff auf bestimmte Schnittstellen gänzlich, während sie für andere jeweils den Nutzer um Erlaubnis fragen müssen. Die vertrauenswürdigen Anwendungen werden bei der Installation je nach Herkunft ihrer Zertifikate verschiedenen Sicherheitsdomänen (Security Domain) zugeordnet. Eine Sicherheitsdomäne definiert eine Reihe von Berechtigungen (Permissions), die jeweils eine bestimmte Funktionalität regeln. Der Name der Berechtigung leitet sich dabei von dem Paket oder der Klasse ab, welche die gewünschte Funktionalität ermöglichen. Beispielsweise wird die Erlaubnis, HTTP-Verbindungen aufzubauen, anhand der Berechtigung java.microedition.io.connector.http überprüft. Es gibt Allowed Permissions, die in einer bestimmten Sicherheitsdomäne grundsätzlich zur Verfügung stehen, und User Permissions, bei denen eine Rückfrage an den Benutzer gestellt wird. Hier wird

17 2.4 SICHERHEIT 15 zusätzlich festgehalten, ob die Erlaubnis dauerhaft (blanket) oder nur für eine Sitzung (session) bzw. den aktuellen Aufruf (oneshot) erteilt wird. Das Zertifizierungsverfahren nutzt asymmetrische Verschlüsselungsalgorithmen und kann mehrstufig erfolgen (Bildung von Zertifikatketten, einer sogenannten Chain of Thrust). Der Anbieter einer Anwendung bildet eine Prüfsumme über das zu installierende Archiv (der.jar-datei) und verschlüsselt diese mit seinem privaten Schlüssel. Die Prüfsumme und der öffentliche Schlüssel (das Zertifikat) werden dann im Applikatonsdeskriptor (der.jad-datei) mitgeliefert. Dadurch kann eine Manipulation des Archivs erkannt werden, allerdings nur, wenn der Applikationsdeskriptor aus einer vertrauenswürdigen Quelle stammt. Um dies zu gewährleisten kann ein Zertifikat selbst noch einmal signiert werden, und zwar letzten Endes von einer anerkannten Certificate Authority, deren öffentlicher Schlüssel im Endgerät fest gespeichert wurde. Der Grund für dieses Vorgehen liegt in der begrenzten Speicherkapazität der Geräte, die Schlüssel sämtlicher relevanter Anbieter zu speichern wäre nicht praktikabel. Es ist für den Benutzer allerdings auch nicht möglich, zusätzliche Schlüssel hinzuzufügen. Anwendungen, die nur mit einem Schlüssel des Entwicklers signiert wurden (sogenannte Self-Signed Certificates) können nicht installiert werden! Anwendungen für die CLDC laufen also grundsätzlich innerhalb einer sehr beschränkten Sandbox- Umgebung, der Zugriff auf kritische, native Schnittstellen ist reglementiert. Allerdings ist die Sicherheit des Systems auch nur gewährleistet, solange keine Möglichkeit besteht, aus der Sandbox auszubrechen. Eine Methode, dies zu erreichen, wurde Ende 2004 veröffentlicht [c t04a]. Dabei wurde unter anderem eine Lücke in der Preverification ausgenutzt, die dazu führt, dass eine speziell präparierte Anwendung die Überprüfung zur Laufzeit passieren und auf Speicherbereiche außerhalb der Sandbox zugreifen kann. Auch in den Bluetooth-Implementierungen vieler aktueller Mobiltelefone wurden Schwachstellen gefunden, die den Zugriff auf sensible Funktionen von außerhalb ermöglichen [c t04c]. Da ein Update der KVM bislang nur über das Einspielen einer neuen Firmware des Gerätes möglich ist, sind derartige Sicherheitslücken als sehr kritisch anzusehen: Die Hersteller erlauben den Austausch der Firmware nur durch ihre Servicepartner, sodass die Geräte der allermeisten Nutzer wohl anfällig bleiben werden. Abhilfe scheint aber in Sicht zu kommen: Die Spezifikationen zum Mobile Operational Management (JSR-232) sollen bis Ende 2005 fertiggestellt werden. Systemadministratoren und Mobilfunkbetreiber sollen hierdurch in die Lage versetzt werden, veröffentlichte Softwareupdates und Modulergänzungen einfacher an die mobilen Geräte zu verteilen [c t05b]. Der Verlauf der weiteren Entwicklung bleibt allerdings abzuwarten. Die Gerätehersteller sehen eine mögliche Lösung dieses Problems wohl auch in der Kontrolle der Installation von Anwendungen mithilfe der Signierung. Anstatt die Software ihrer Geräte erst in einem ausgereifteren Zustand auf den Markt zu bringen, stellen sie geprüfte Anwendungen bereit und können sich so zusätzlich als Zwischenhändler für mobile Dow- nloads etablieren. Aus dem für das Jahr 2008 prognostizierten Marktvolumenen von Multimedia- Content auf Mobiltelefonen in Höhe von 70 Milliarden Euro [c t04b] ergibt sich eine verlockende Perspektive für die Gerätehersteller.

18 Kapitel 3 Datensynchronisation und J2ME Anwendungen auf mobilen Geräten stehen als Teil umfangreicherer Informationssysteme häufig in Interaktion mit stationären Computern, von denen sie spezifische Daten beziehen, oder an die sie im mobilen Einsatz entstandene Modifikationen zurückliefern. Oftmals ist dabei eine dauerhafte Verbindung zum stationären Teil des Systems nicht möglich oder zu langsam bzw. kostspielig, sodass ein kontinuierlicher Abgleich der Daten nicht praktikabel ist. In diesen Fällen muss später ein Austausch in beide Richtungen erfolgen, bei dem die Aktualität der Daten wieder hergestellt wird. Die Limitationen der Geräte erfordern in vielen Fällen den Einsatz spezieller Proxy-Lösungen, bei denen Informationen für die mobilen Anwendungen eigens aufbereitet werden. Im Folgenden werden standardisierte Verfahren beschrieben, Daten zwischen Computersystemen auszutauschen und abzugleichen, die im Rahmen der anschließenden Evaluation auf ihre Verwendbarkeit in Anwendungen auf Basis der J2ME untersucht werden. Zunächst werden Besonderheiten im Hinblick auf die grundlegenden Kommunikationsmöglichkeiten der J2ME gezeigt. Sollen mobile Anwendungen ausschließlich diese einfachen Kommunikationsprotokolle nutzen, müssen geeignete Datenformate und Synchronisationsprotokolle eigens entworfen werden. Der Vorteil dieser Vorgehensweise liegt in einer effizienten Nutzung der Geräteressourcen, Nachteile sind die mangelnde Kompatibilität zu anderen Anwendungen und die erforderliche Implementierung geeigneter Methoden für die Kommunikation. Webservices ermöglichen die plattformunabhängige Übertragung strukturierter Daten, stellen aber durch die Verwendung XML-basierter Nachrichten erhöhte Anforderungen an die Bandbreite der Verbindung und die Leistungsfähigkeit der Geräte. Geeignete Verfahren zur Datensychronisation müssen jedoch auch bei der Verwendung von Webservices entworfen werden. Noch höhere Anforderungen an die Hardware der Geräte stellt das ebenfalls auf dem Austausch von XML-Nachrichten basierende SyncML-Protokoll. Dafür bietet es ein sehr ausgereiftes und standardisiertes Konzept zur Datensynchronisation. Ein direkter Datenaustausch zwischen mobilen Anwendungen kann durch die Verwendung von lokalen Bluetooth-Funkverbindungen durchgeführt werden. Damit eröffnen sich neue Möglichkeiten; es ergeben sich aber auch Probleme hinsichtlich der Synchronisation der Daten.

19 3.1 KOMMUNIKATIONSPROTOKOLLE IN DER J2ME: DAS GENERIC CONNECTION FRAMEWORK 17 CLDC Connector (Connection Factory) <<creates>> <<Interface>> Connection <<exception>> ConnectionNotFoundException Profile / optionale Pakete <<Interface>> Datagram Connection <<Interface>> Input Connection <<Interface>> Output Connection <<Interface>> StreamConnectionNotifier beispielsweise MessageConnection <<Interface>> (WMA) L2CAP (Bluetooth) <<Interface>> MIDP 2.0 Stream Connection <<Interface>> Content Connection beispielsweise <<Interface>> FileConnection RFComm (Bluetooth) <<Interface>> <<Interface>> <<Interface>> <<Interface>> <<Interface>> UDPDatagram Connection Comm Connection Socket Connection HTTP Connection ServerSocket Connection Push Registry <<Interface>> <<Interface>> Secure Connection HTTPS Connection Abbildung 3.1: Das Generic Connection Framework 3.1 Kommunikationsprotokolle in der J2ME: Das Generic Connection Framework Bei der Entwicklung der J2ME wurde der Bereich Netzwerkkommunikation im Vergleich zur J2SE- API neu strukturiert, hauptsächlich weil der Umfang des java.net Paketes den Speicherbedarf der mobilen Geräte zu sehr erhöht hätte. Daneben stand auch der Wunsch, einen konsistenteren Umgang mit den verschiedenen Kommunikationsprotokollen und eine höhere Flexibilität hinsichtlich des Austauschs der herstellerspezifischen Implementierungen zu ermöglichen. Es entstand das Generic Connection Framework (GCF), ein überwiegend auf Interfaces aufgebautes API. Alle Arten von Verbindungen werden über die statische Methode Connector.open() der Connection Factory geöffnet. Dabei wird ein String übergeben, dessen Anfang das jeweilige Protokoll definiert, gefolgt von einer Netzwerkadresse in einem protokollabhängigen Format. Beispielsweise initialisiert eine HTTP-Verbindung, socket://host:port einen Socket für ausgehende TCP-Verbindungen, socket://:port einen Socket für eingehende TCP-Verbindungen (keine Hostangabe), btspp://deviceid:serviceuid eine Bluetooth RFComm-Verbindung, sms://telefonnummer[:port] eine MessageConnection für Kurzmitteilungen, file:///<wurzel>/<verzeichnis> den Zugriff auf das Dateisystem. Zurückgeliefert wird ein Connection-Objekt, welches je nach ausgewähltem Protokoll ein entsprechend von Connection abgeleitetes Interface implementiert. Dieser Ansatz erlaubt die Un-

20 3.2 WEBSERVICES 18 terstützung verschiedener Verbindungsarten unter Beibehaltung eines großen Teils des Codes der Anwendung. Im MIDP 2.0 ist nur die Unterstützung der Protokolle HTTP und HTTPS zwingend vorgeschrieben, alle anderen sind als optional ausgewiesen. Dies scheint zunächst etwas verwunderlich, da HTTP zumeist auf TCP als Transportprotokoll aufsetzt. In Mobilfunknetzen arbeitet TCP jedoch relativ ineffizient: Protokollseitige Mechanismen, wie Flusskontrolle oder Quittungen, die für eine zuverlässige Datenübertragung sorgen, vertragen sich relativ schlecht mit der vergleichsweise hohen Fehlerrate und Latenzzeit in diesen Netzen. Deshalb wird auf einigen Mobiltelefonen HTTP nicht per TCP/IP, sondern über das Wireless Session Protocol (WSP) [WSP] transportiert. Dieses wurde speziell auf die Eigenschaften von Mobilfunknetzen abgestimmt und bietet darüber hinaus einige neue Funktionen, beispielsweise eine Unterstützung für Sessions. Analog kann als sicheres Transportprotokoll statt Secure Sockets Layer (SSL) bzw. Transport Layer Security (TLS), Wireless Transport Layer Security (WTLS) [WTL] verwendet werden. In diesen Fällen läuft die Kommunikation über ein WAP-Gateway, das die Umsetzung der WAP-spezifischen Protokolle auf TCP bzw. TLS/SSL vornimmt. Bidirektionale Kommunikation, beispielsweise zur Realisierung des Datenaustausches zwischen zwei mobilen Geräten, setzt die Verwendung von Protokollen der Transportschicht voraus. Um einen TCP-Serverdienst zu registrieren wird Connector.open() mit einem Parameter der Form socket://:port aufgerufen. Das Interface StreamConnectionNotifier bietet für einen solchen ServerSocket die Methode acceptandopen(), die wartet, bis ein Client eine Verbindung zum lokalen Endpunkt aufbaut und anschließend eine SocketConnection-Instanz zurückliefert. Die Möglichkeiten von Serverdiensten werden durch die Aktivierung der Anwendung via Push Registry noch erweitert (siehe Kapitel 3.4). Einige, bei der Kommunikation über HTTP mitunter benötigte Funktionen müssen weiterhin in die Anwendung selbst integriert werden. Werden beispielsweise vom Server Cookies zum Session- Tracking vorausgesetzt, muss die Anwendung dies explizit implementieren, ebenso fehlt im GCF die automatische Behandlung von HTTP-Redirects. Davon abgesehen bietet das GCF aber einen Komfort im Umgang mit Netzverbindungen, der die Berücksichtigung von Low-Level Eigenarten der Protokolle in vielen Fällen überflüssig macht. 3.2 Webservices Webservices dienen dem Datenaustausch und entfernten Funktionsaufrufen zwischen heterogenen Informationssystemen bzw. Anwendungen über Netzwerke. Für diesen Zweck wurden eine Reihe von offenen Protokollen und Standards definiert, deren Einhaltung eine weitgehende Interoperabilität zwischen verschiedenen Programmiersprachen und Betriebssystemen sicherstellen soll [Ngh02]. Die Entwicklung wird von herstellerübergreifenden Organisationen, namentlich dem World Wide Web Consortium (W3C) [W3Ca] und der Organization for the Advancement of Structured Information Standards (OASIS) [OAS] koordiniert.

21 3.2 WEBSERVICES Der Aufbau von Webservices Das Format sämtlicher Protokolle und Standards im Rahmen der Webservices basiert auf der Extensible Markup Language (XML). Die Verwendung von stardardisierten XML-Formaten ermöglicht die Plattform- und Sprachunabhängigkeit der Webservices und führt zu mensch- und maschinenlesbaren Nachrichten. Als Kommunikationsprotokoll und zur Serialisierung der Daten wird zumeist das Simple Object Access Protocol (SOAP) [SOA] genutzt. Ein Client sendet einen Request mittels SOAP an einen Server, der die gewünschte Funktion einer Anwendung aufruft und das Ergebnis wieder per SOAP an den Client zurück sendet. In der Regel wird SOAP mittels HTTP transportiert, um z.b. Probleme mit Firewalls zu vermeiden. Alternativ können aber auch andere Transportprotokolle verwendet werden, beispielsweise das Simple Mail Transfer Protocol (SMTP), das Wireless Session Protocol (WSP) oder das Object Exchange Protocol (OBEX siehe Kapitel 3.5),. Zur Beschreibung der Funktionalität eines Webservices dient die Web Services Description Language (WSDL) [W3Cc]. Ein WSDL-Dokument beinhaltet die Datenstrukturen und Schnittstellen der angebotenen Funktionen eines Webservies. Da diese recht komplex werden können ermöglichen viele Frameworks die automatische Generierung von WSDL-Dokumenten und Serverklassen (sogenannten Skeletons) anhand des Codes der Anwendung, die als Webservice bereitgestellt werden soll. Analog dazu wird oft auch der clientseitige Code zur Nutzung eines Webservices anhand des vom Server bezogenen WSDL-Dokuments automatisch generiert. Ein sogenannter Stub sorgt für die Komposition des Request und die Analyse der Response. Der Entwickler muss den Stub nur noch in die Anwendung integrieren und kann über diesen die Funktionalität des Webservices nutzen: MensaWebService stub=new MensaWebService(url); WeekData thisweek = stub.getthisweek(); WeekData nextweek = stub.getnextweek(); Bis auf die Notwendigkeit der Behandlung von Ausnahmen, die im Zusammenhang mit Fehlern bei der Kommunikation mit dem Server entstehen können, unterscheiden sich somit entfernte Aufrufe syntaktisch nicht von lokalen Webservices in der J2ME Zur Nutzung von Webservices im Rahmen der J2ME wurde im JSR-172 ein optionales Paket für CDC und CLDC spezifiziert. Das WS-API beinhaltet Funktionen zum Parsen von XML-Dokumenten und ermöglicht die Nutzung entfernter Dienste mittels SOAP. Die serverseitige Bereitstellung von Diensten ist dagegen nicht Bestandteil der Spezifikation. Zur Analyse von XML-Dokumenten haben sich in der Java-Welt die Java APIs for XML Processing (JAXP) [JAXb] etabliert. Diese stellen zwei unterschiedliche Methoden des Umgangs mit XML-Daten zur Verfügung: Die erste besteht in einer ereignisgesteuerten, sequentiellen Verarbeitung, während bei der zweiten Methode das gesamte Dokument analysiert und in Form eines hierarchischen Objektbaums zugänglich gemacht wird. Das WS-API beinhaltet mit dem Simple API for XML Parsing (SAX)