Synchronisation mobiler Anwendungen auf Basis der Java 2 Micro ...
Synchronisation mobiler Anwendungen auf Basis der Java 2 Micro ...
Synchronisation mobiler Anwendungen auf Basis der Java 2 Micro ...
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Fakultät II – Informatik, Wirtschafts- und Rechtswissenschaften<br />
Department für Informatik<br />
Abteilung Systemsoftware und verteilte Systeme<br />
Individuelles Projekt<br />
<strong>Synchronisation</strong> <strong>mobiler</strong> <strong>Anwendungen</strong> <strong>auf</strong> <strong>Basis</strong> <strong>der</strong><br />
<strong>Java</strong> 2 <strong>Micro</strong> Edition<br />
Jasper Mammen<br />
Nadorster Str. 72<br />
26123 Oldenburg<br />
Erstprüfer: Prof. Dr.-Ing. Oliver Theel<br />
Zweitprüfer: Dipl.-Inform. Philipp Hahn<br />
Oldenburg, den 30. August 2005
Zusammenfassung<br />
Die folgende Arbeit beschäftigt sich mit <strong>der</strong> <strong>Synchronisation</strong> von <strong>Anwendungen</strong> <strong>auf</strong> <strong>Basis</strong> <strong>der</strong> <strong>Java</strong><br />
2 <strong>Micro</strong> Edition (J2ME). Neben dem Aufbau und den grundlegenden Eigenschaften <strong>der</strong> J2ME werden<br />
gängige Verfahren des Datenaustauschs und <strong>der</strong> Datensynchronisation beschrieben. Die Verwendbarkeit<br />
dieser Verfahren im Rahmen <strong>der</strong> J2ME-Plattform wird mittels einiger Beispielanwendungen<br />
evaluiert. Die dabei gesammelten Erfahrungen werden dokumentiert und dienen als <strong>Basis</strong><br />
eines Resümees bezüglich <strong>der</strong> heutigen Möglichkeiten und Einschränkungen <strong>der</strong> J2ME-Plattform.<br />
Abschließend wird ein Ausblick <strong>auf</strong> die zukünftige Entwicklung <strong>der</strong> J2ME gegeben.
Inhaltsverzeichnis<br />
1 Einleitung 4<br />
2 Die <strong>Java</strong> 2 <strong>Micro</strong> Edition 6<br />
2.1 Konfigurationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
2.1.1 Die Connected, Limited Device Configuration (CLDC) . . . . . . . . . . . . . . 7<br />
2.1.2 Die Connected Device Configuration (CDC) . . . . . . . . . . . . . . . . . . . . 9<br />
2.2 Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
2.2.1 Das Mobile Information Device Profile (MIDP) . . . . . . . . . . . . . . . . . . . 9<br />
2.2.2 Das Information Module Profile (IMP) . . . . . . . . . . . . . . . . . . . . . . . . 11<br />
2.2.3 Die Profile <strong>der</strong> CDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11<br />
2.3 Optionale Pakete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12<br />
2.3.1 Das Personal Information Management und das FileConnection API . . . . . . 12<br />
2.3.2 Das Wireless Messaging API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12<br />
2.3.3 Die <strong>Java</strong> APIs für Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13<br />
2.3.4 Das Remote Method Invocation Optional Package . . . . . . . . . . . . . . . . . 13<br />
2.3.5 Die J2ME Web Services Specification . . . . . . . . . . . . . . . . . . . . . . . . . 13<br />
2.3.6 Das JDBC Optional Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13<br />
2.4 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14<br />
3 Datensynchronisation und J2ME 16<br />
3.1 Kommunikationsprotokolle in <strong>der</strong> J2ME:<br />
Das Generic Connection Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17<br />
3.2 Webservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18<br />
3.2.1 Der Aufbau von Webservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19<br />
3.2.2 Webservices in <strong>der</strong> J2ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
INHALTSVERZEICHNIS 2<br />
3.2.3 Einsatz von Webservices in mobilen <strong>Anwendungen</strong> . . . . . . . . . . . . . . . . 20<br />
3.3 SyncML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21<br />
3.3.1 Systemarchitekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21<br />
3.3.2 Protokolle und Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22<br />
3.3.3 Verwendung von SyncML <strong>auf</strong> <strong>Basis</strong> <strong>der</strong> J2ME . . . . . . . . . . . . . . . . . . . 23<br />
3.4 Push Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23<br />
3.5 Lokale Verbindungen via Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24<br />
4 Praktische Evaluation 25<br />
4.1 Anfor<strong>der</strong>ungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26<br />
4.1.1 Anwendung für Mensapläne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26<br />
4.1.2 Nutzung von Webservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27<br />
4.1.3 Prototyp zur Datensynchronisation über SyncML . . . . . . . . . . . . . . . . . 27<br />
4.2 Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28<br />
4.2.1 Architektur System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28<br />
4.2.2 Komponenten Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28<br />
4.2.3 Struktur <strong>der</strong> Mensaplan-Anwendung . . . . . . . . . . . . . . . . . . . . . . . . 29<br />
4.2.4 Desktop-Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31<br />
4.2.5 SyncML-Prototyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31<br />
4.3 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32<br />
4.3.1 Verwendete Entwicklungsumgebung . . . . . . . . . . . . . . . . . . . . . . . . 32<br />
4.3.2 Mensaplan Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34<br />
4.3.3 Mensaplan-Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35<br />
4.3.4 Desktop-Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41<br />
4.3.5 Mensaplan Webservice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41<br />
4.3.6 Mensaplan MIDlet mit Kommunikation via Webservice . . . . . . . . . . . . . . 43<br />
4.3.7 SyncML-Prototyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45<br />
5 Resümee 54<br />
5.1 Beurteilung <strong>der</strong> Anwendungsentwicklung <strong>auf</strong> <strong>Basis</strong> <strong>der</strong> CLDC . . . . . . . . . . . . . 54<br />
5.1.1 Vorteile <strong>der</strong> Entwicklung <strong>auf</strong> <strong>Basis</strong> <strong>der</strong> CLDC . . . . . . . . . . . . . . . . . . . 54<br />
5.1.2 Probleme <strong>auf</strong>grund <strong>der</strong> geringen Leistungsfähigkeit <strong>der</strong> Geräte . . . . . . . . . 55
INHALTSVERZEICHNIS 3<br />
5.1.3 Schwierigkeiten <strong>auf</strong>grund zu offener Spezifikationen . . . . . . . . . . . . . . . 57<br />
5.1.4 Aus den Restriktionen <strong>der</strong> CLDC resultierende Probleme . . . . . . . . . . . . . 57<br />
5.1.5 Fragmentation <strong>der</strong> CLDC-Plattform . . . . . . . . . . . . . . . . . . . . . . . . . 58<br />
5.1.6 Konsequenzen für die Datensynchronisation <strong>mobiler</strong> <strong>Anwendungen</strong> . . . . . . 59<br />
5.2 Die zukünftige Entwicklung <strong>der</strong> CDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60<br />
5.3 Fazit und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Kapitel 1<br />
Einleitung<br />
Der gängige Einsatzbereich von Computeranwendungen war lange Zeit <strong>der</strong> stationäre Desktop-<br />
Computer. Eine fortschreitende Miniaturisierung <strong>der</strong> technischen Komponenten des Computers<br />
ermöglicht jedoch in zunehmendem Maße die Realisierung von kleinen, leistungsfähigen, mobilen<br />
Geräten. Klassische Computeranwendungen, wie Textverarbeitung o<strong>der</strong> E-Mail sind damit nicht<br />
länger an einen festen Arbeitsplatz gebunden, son<strong>der</strong>n können auch unterwegs“ verwendet werden.<br />
”<br />
Darüber hinaus entstehen durch den Einsatz <strong>mobiler</strong> Geräte auch völlig neue Anwendungsfel<strong>der</strong>.<br />
Benutzer <strong>mobiler</strong> <strong>Anwendungen</strong> können wichtige Informationen an jedem Ort und zu je<strong>der</strong> Zeit<br />
abrufen. Zudem können den Benutzern relevante Informationen auch in Abhängigkeit von ihrem<br />
<strong>der</strong>zeitigen Aufenthaltsort zur Verfügung gestellt werden (sogenannte Location-based Services). Über<br />
<strong>Anwendungen</strong> für solche mobile Szenarien wird zur Zeit viel diskutiert. Dabei müssen sowohl die<br />
Bedürfnisse <strong>der</strong> Nutzer, als auch die technische Machbarkeit berücksichtigt werden.<br />
Ein erster Überblick hinsichtlich <strong>der</strong> Vielfalt an verfügbaren mobilen Geräten lässt sich durch <strong>der</strong>en<br />
Einordnung in grundlegende Klassen mit ähnlicher Leistungsfähigkeit gewinnen. Am geringsten<br />
sind die Unterschiede zu den Desktop-Computern in <strong>der</strong> Klasse <strong>der</strong> Notebooks. Diese tragbaren<br />
Computer bieten eine den stationären Systemen zumeist ebenbürtige Leistung. Aus diesem Grund<br />
können <strong>auf</strong> den Notebooks auch die ursprünglich für Desktop-Computer entwickelten <strong>Anwendungen</strong><br />
genutzt werden. Größe und Gewicht <strong>der</strong> Notebooks führen allerdings dazu, dass die Benutzer<br />
diese nicht ständig bei sich tragen, zudem wird die Mobilität durch einen vergleichsweise hohen<br />
Stromverbrauch eingeschränkt.<br />
Am an<strong>der</strong>en Ende <strong>der</strong> Leistungsfähigkeit findet sich die Geräteklasse <strong>der</strong> Mobiltelefone. Diese zeichnen<br />
sich vor allem durch geringe Größe und Stromverbrauch aus, und sind damit hinsichtlich <strong>der</strong><br />
Mobilität klar im Vorteil – die meisten Nutzer haben ihr Mobiltelefon ständig dabei. Dieser Vorteil<br />
wird jedoch mit geringer Rechen- und Speicherkapazität und einem kleinen Display erk<strong>auf</strong>t,<br />
<strong>Anwendungen</strong> für Mobiltelefone müssen diese Limitationen berücksichtigen. Als Plattform für die<br />
Entwicklung von <strong>Anwendungen</strong> für diese Geräte hat sich die <strong>Java</strong> 2 <strong>Micro</strong> Edition (J2ME) etabliert,<br />
<strong>der</strong>en Möglichkeiten im Rahmen dieser Arbeit untersucht werden sollen.<br />
Zwischen den Notebooks und Mobiltelefonen findet sich eine weitere Klasse von mobilen Geräten,
5<br />
die <strong>der</strong> Smartphones und PDAs. Ein PDA (Persönlicher Digitaler Assistent) ist ein tragbarer, kleiner<br />
Computer, <strong>der</strong> speziell <strong>der</strong> Verwaltung von Adressen und Terminen dient. Darüber hinaus können<br />
zusätzliche <strong>Anwendungen</strong> installiert werden. Die Hardware <strong>der</strong> PDAs stellt einen Kompromiss zwischen<br />
Leistungsfähigkeit und Mobilität dar: Rechen- und Speicherkapazität ermöglichen auch umfangreichere<br />
<strong>Anwendungen</strong>, auch die Größe des Displays ist zur Darstellung komplexerer Oberflächen<br />
geeignet. Zugleich sind die Geräte klein genug, um vom Benutzer ständig mitgeführt werden<br />
zu können, <strong>der</strong> relativ geringe Stromverbrauch bietet eine ausreichende Nutzungsdauer im mobilen<br />
Einsatz.<br />
Die Smartphones zeichnen sich durch ähnliche Eigenschaften aus, zusätzlich haben sie ein integriertes<br />
Mobiltelefon. Die Benutzer eines Smartphones können somit die Funktionalität von PDA und Mobiltelefon<br />
nutzen, ohne gleich zwei Geräte mit <strong>auf</strong> Reisen nehmen zu müssen. Aus diesem Grund<br />
haben auch die Hersteller klassischer PDAs damit begonnen, ihre Geräte um die Fähigkeit zum mobilen<br />
Telefonieren zu erweitern. Eine weitere Konvergenz <strong>der</strong> beiden Gerätearten ist zu erwarten.<br />
Auch für viele Smartphones und PDAs steht die <strong>Java</strong> 2 <strong>Micro</strong> Edition als Plattform zur Anwicklung<br />
<strong>mobiler</strong> <strong>Anwendungen</strong> zu Verfügung. Daneben können <strong>Anwendungen</strong> für diese Geräte auch nativ<br />
für das jeweilige Betriebssystem entwickelt werden. Die heute gängigen Plattformen sind Embedded<br />
Linux, PalmOS, SymbianOS und Windows Mobile.<br />
<strong>Anwendungen</strong> <strong>auf</strong> mobilen Geräten sind häufig Bestandteil umfangreicherer Informationssysteme.<br />
Sie stehen in Interaktion mit stationären Desktop-Rechnern o<strong>der</strong> Servern, von denen sie spezifische<br />
Daten beziehen, o<strong>der</strong> an die sie im mobilen Einsatz entstandene Modifikationen zurückliefern. Es stehen<br />
einige standardisierte Verfahren zur Verfügung, Daten zwischen Computersystemen auszutauschen<br />
und abzugleichen. Inwieweit durch die Limitationen <strong>der</strong> mobilen Geräte die Verwendbarkeit<br />
dieser Verfahren eingeschränkt wird, soll im Rahmen <strong>der</strong> folgenden Arbeit in Erfahrung gebracht<br />
werden.<br />
Dabei wird als Grundlage <strong>der</strong> Entwicklung <strong>mobiler</strong> <strong>Anwendungen</strong> die <strong>Java</strong> 2 <strong>Micro</strong> Edition Gegenstand<br />
<strong>der</strong> Untersuchung sein. Sie ist plattformübergreifend <strong>auf</strong> einer Vielzahl an Geräten verfügbar.<br />
Laut Herstellerangaben wurden bis Mitte 2005 über 700 Millionen Geräte mit einer Unterstützung<br />
für die J2ME ausgeliefert [c’t05b]. Bislang wurden allerdings hauptsächlich kleinere Spiele <strong>auf</strong> <strong>Basis</strong><br />
<strong>der</strong> J2ME erstellt. Ob <strong>der</strong> Entwicklungsstand <strong>der</strong> Plattform mittlerweile auch die Realisierung<br />
komplexerer <strong>mobiler</strong> <strong>Anwendungen</strong> erlaubt, soll anhand <strong>der</strong> Implementierung einiger Beispielanwendungen<br />
und Prototypen überprüft werden.<br />
Im folgenden Kapitel werden die Struktur, die Möglichkeiten und die Einschränkungen <strong>der</strong> J2ME<br />
Plattform erläutert. Kapitel 3 beinhaltet eine nähere Betrachtung von Konzepten und Anfor<strong>der</strong>ungen,<br />
die die Datensynchronisation von <strong>Anwendungen</strong> mit sich bringen. Dabei wird auch <strong>auf</strong> die<br />
Möglichkeiten <strong>der</strong> Realisierung im Rahmen <strong>der</strong> Entwicklung mit <strong>der</strong> J2ME eingegangen. In Kapitel<br />
4 werden die Ergebnisse einer praktischen Evaluation, bestehend aus Konzeption und Implementierung<br />
von Beispielanwendungen und Prototypen dokumentiert.<br />
Abschließend wird im letzten Kapitel aus den vorangegangenen Überlegungen und den gesammelten<br />
Erfahrungen bei <strong>der</strong> Umsetzung ein Resümee bezüglich <strong>der</strong> momentanen Möglichkeiten <strong>der</strong><br />
J2ME Plattform gezogen, sowie ein Ausblick <strong>auf</strong> die zukünftige Entwicklung in diesem Bereich zu<br />
geben versucht.
Kapitel 2<br />
Die <strong>Java</strong> 2 <strong>Micro</strong> Edition<br />
Die <strong>Java</strong> 2 <strong>Micro</strong> Edition ist eine <strong>Java</strong> Plattform für ressourcenbeschränkte Geräte wie Mobiltelefone,<br />
PDAs, Smartphones, Auto-Navigationssysteme o<strong>der</strong> Settop-Boxen. Es handelt sich analog zur<br />
<strong>Java</strong> 2 Standard Edition um eine interpretierte Sprache, <strong>der</strong>en Bytecode <strong>auf</strong> einer Virtuellen Maschine<br />
ausgeführt wird, die <strong>auf</strong> den jeweiligen proprietären Betriebssystemen <strong>der</strong> Geräte <strong>auf</strong>setzt. Es gibt<br />
jedoch eine Reihe von Unterschieden zur Standard Edition, die im folgenden erläutert werden.<br />
Die <strong>Java</strong> 2 <strong>Micro</strong> Edition existiert seit 1999, als Sun <strong>Micro</strong>systems beschloss, die im L<strong>auf</strong>e <strong>der</strong> Jahre<br />
sehr umfangreich gewordene <strong>Java</strong> Plattform in drei Editionen <strong>auf</strong>zuteilen: die <strong>Java</strong> 2 Enterprise Edition<br />
(J2EE) für serverseitige Lösungen, die <strong>Java</strong> 2 Standard Edition (J2SE) für Desktop-Applikationen<br />
und die <strong>Java</strong> 2 <strong>Micro</strong> Edition (J2ME) für ressourcenbeschränkte Geräte [SUN99].<br />
Zu diesem Zeitpunkt gab es eine steigende Nachfrage nach <strong>Java</strong> basierten Lösungen für kleine<br />
Geräte, und es entstanden für diese Zwecke einige von <strong>Java</strong> 1.1 abgeleitete Plattformen mit reduzierter<br />
Funktionalität (bspw. Embedded<strong>Java</strong> [SUNa] o<strong>der</strong> Personal<strong>Java</strong> [SUNd]). Die J2ME sollte hier<br />
eine Vereinheitlichung <strong>der</strong> Entwicklung für kleine Geräte ermöglichen. Bedingt durch die differenzierten<br />
Eigenschaften <strong>der</strong> Vielzahl ressourcenbeschränkter Geräte mussten jedoch, im Gegensatz zu<br />
den Desktop- und Servereditionen, heterogenere Anfor<strong>der</strong>ungen erfüllt werden. Aus diesem Grund<br />
besteht die J2ME nicht aus einer einzelnen, son<strong>der</strong>n aus einer Sammlung von Spezifikationen. Die<br />
Eigenschaften eines Gerätes werden dabei durch ein o<strong>der</strong> mehrere Profile spezifiziert, die jeweils <strong>auf</strong><br />
den Grundfunktionen einer Konfiguration basieren. Zusätzlich können optionale Pakete für spezielle<br />
o<strong>der</strong> neue Leistungsmerkmale eines Gerätes hinzukommen.<br />
Eine Herausfor<strong>der</strong>ung bei <strong>der</strong> Entwicklung <strong>der</strong> J2ME bedeutet die Gewährleistung <strong>der</strong> Plattformunabhängigkeit<br />
<strong>auf</strong> den unterschiedlichen Geräten. Sämtliche Spezifikationen <strong>der</strong> J2ME entstehen<br />
aus diesem Grund im Rahmen des <strong>Java</strong> Community Process [JCPa] unter Beteiligung verschiedenster<br />
Firmen <strong>der</strong> Informationstechnologie- und Telekommunikationsbranche. Der JCP wurde Ende<br />
1998 von Sun <strong>Micro</strong>systems initiiert, um einen formalen aber schnellen Weg <strong>der</strong> kooperativen Entwicklung<br />
und Aktualisierung von <strong>Java</strong> Spezifikationen zu ermöglichen. Vorschläge zu neuen <strong>Java</strong>-<br />
Technologien o<strong>der</strong> Bibliotheken heißen <strong>Java</strong> Specification Requests (JSR) und durchl<strong>auf</strong>en einen partizipativen,<br />
durch Meilensteine bestimmten Prozess [JCPb], an dessen Ende in <strong>der</strong> Regel neben <strong>der</strong><br />
Spezifikation auch eine Referenzimplementierung sowie eine umfangreiche Testsuite zur Zertifizierung<br />
spezifikationskonformer Implementierungen stehen.
2.1 KONFIGURATIONEN 7<br />
Abbildung 2.1: Konfigurationen, Profile und optionale Pakete (aus [Sch04])<br />
Es obliegt dann den Hardwareherstellern, die Spezifikationen für ihre Geräte zu implementieren.<br />
Das Bestehen <strong>der</strong> Kompatibilitätstests wird durch Sun überprüft und zertifiziert. Die enge Kooperation<br />
<strong>der</strong> beteiligten Unternehmen sichert die standardisierte Umsetzung und größtmögliche Verbreitung<br />
<strong>auf</strong> einer Vielzahl von Geräten unterschiedlicher Hersteller. Sämtliche Spezifikationen <strong>der</strong><br />
J2ME sind im Rahmen des JCP erarbeitet worden, <strong>auf</strong> dessen Webseiten detailierte Informationen zu<br />
den einzelnen JSRs zugänglich sind [JSRa]. Insbeson<strong>der</strong>e finden sich dort die Informationen zu allen,<br />
im Folgenden näher betrachteten JSRs. Auf die jeweilige explizite Angabe <strong>der</strong> Quelle wird daher<br />
verzichtet.<br />
2.1 Konfigurationen<br />
Eine Konfiguration stellt die unterste Schicht <strong>der</strong> J2ME-Architektur dar. Es wird jeweils eine virtuelle<br />
Maschine und eine Klassenbibliothek mit grundlegen<strong>der</strong> Funktionalität für die dar<strong>auf</strong> <strong>auf</strong>bauenden<br />
Profile und optionalen Pakete zur Verfügung gestellt. Eine Konfiguration beschreibt somit eine allgemeinere<br />
Klasse von Geräten, während die Profile stärker <strong>auf</strong> spezielle Gerätetypen zugeschnitten<br />
sind. Momentan sind zwei verschiedene Konfigurationen spezifiziert: Die Connected Device Configuration<br />
(CDC) im JSR-36 und die Connected, Limited Device Configuration (CLDC) im JSR-30. Sie unterscheiden<br />
sich hinsichtlich ihres Funktionsumfanges und den daraus resultierenden Anfor<strong>der</strong>ungen<br />
an die Hardware <strong>der</strong> Geräte. Bedingt durch die Abhängigkeit <strong>der</strong> Profile von den Eigenschaften <strong>der</strong><br />
zu Grunde liegenden Konfiguration ergeben sich innerhalb <strong>der</strong> J2ME zwei getrennte Säulen.<br />
2.1.1 Die Connected, Limited Device Configuration (CLDC)<br />
Die CLDC wurde für kleinste Geräte, wie Mobiltelefone, Smartphones und PDAs entworfen, die<br />
eine begrenzte Rechenleistung, geringe Speicherkapazität und niedrige Bandbreite <strong>der</strong> Netzverbindung<br />
<strong>auf</strong>weisen. Von <strong>der</strong> benötigten Speicherkapazität (160 bis 512 Kilobyte) leitet sich auch <strong>der</strong>
2.1 KONFIGURATIONEN 8<br />
Name <strong>der</strong> verwendeten virtuellen Maschine ab – KVM steht für Kilobyte Virtual Machine. Um eine<br />
<strong>Java</strong>-L<strong>auf</strong>zeitumgebung trotz dieser begrenzter Ressourcen zu realisieren, mussten einige Einschränkungen<br />
bezüglich <strong>der</strong> Sprache selbst, <strong>der</strong> virtuellen Maschine und <strong>der</strong> Kernbibliotheken vorgenommen<br />
werden.<br />
Unter an<strong>der</strong>em<br />
• bietet die KVM keine Fließkomma-Arithmetik, da die Hardware vieler Geräte dies nicht unterstützt<br />
und eine Implementation in Software relativ rechen- und speicherintensiv wäre.<br />
• fehlt <strong>der</strong> KVM die Fähigkeit zur Introspektion aus java.lang.reflect. Damit sind auch<br />
dar<strong>auf</strong> <strong>auf</strong>bauende Technologien wie Objekt-Serialisierung und Remote Method Invokation nicht<br />
einsetzbar. (Siehe Kapitel 3)<br />
• fehlen im Vergleich zur J2SE in Paketen einige Klassen (bspw. in java.util das Collection<br />
Framework), o<strong>der</strong> die Methoden <strong>der</strong> Klassen wurden reduziert (bspw. fehlt in<br />
java.util.Date u.a. die toString() Methode).<br />
• wurde das Sicherheitsmodell gegenüber <strong>der</strong> J2SE vereinfacht. Dies hat zur Folge, daß <strong>der</strong> Aufruf<br />
nativer Funktionen via <strong>Java</strong> Native Interface (JNI) nicht möglich ist, ebensowenig erlaubt die<br />
KVM benutzerdefinierte Class Loa<strong>der</strong> (Siehe Kapitel 2.4).<br />
• musste das Verfahren zur Verifizierung des Bytecodes geän<strong>der</strong>t werden. Die KVM übernimmt<br />
nur einen Teil dieses Prozesses – <strong>der</strong> rechen- und speicherintensive Part, Preverification genannt,<br />
wird schon bei <strong>der</strong> Erstellung <strong>der</strong> Anwendung vorgenommen (Siehe Kapitel 2.4).<br />
• unterstützt die KVM zwar nebenläufige Threads, allerdings keine ausgefeilteren Funktionen,<br />
wie Thread-Groups o<strong>der</strong> Daemon-Threads.<br />
• ist die Größe von <strong>Anwendungen</strong> <strong>auf</strong> maximal 64 Kilobyte beschränkt. Die parallele<br />
Ausführung mehrerer <strong>Anwendungen</strong> ist nicht möglich.<br />
• wurde die Speicherverwaltung (Garbage Collection) den Einschränkungen angepasst. Entfernt<br />
wurden dabei auch alle Möglichkeiten <strong>der</strong> Anwendung, <strong>auf</strong> die Speicherverwaltung Einfluss<br />
zu nehmen.<br />
Trotz dieser Einschränkungen wurde die Konsistenz zur Klassenbibliothek <strong>der</strong> J2SE in weiten Teilen<br />
erreicht. Die CLDC besteht aus den Paketen java.lang (Fundamentale Klassen), java.util (Kollektionen,<br />
Datum und Uhrzeit, Zufallszahlengenerator) und java.io (Stream- und Rea<strong>der</strong>klassen<br />
für Ein- und Ausgaben), welche eine echte Teilmenge <strong>der</strong> gleichnamigen Klassen <strong>der</strong> J2SE darstellen.<br />
Än<strong>der</strong>ungen sind durch die oben angeführten Limitationen <strong>der</strong> KVM, sowie die Bereinigung<br />
von veralteten Methoden und Klassen bedingt.<br />
Die Verwaltung von Netzwerkverbindungen, die sich bei <strong>der</strong> Standard Edition im Paket java.net<br />
findet, wurde umstrukturiert: Die CLDC bringt einen einheitlichen Ansatz zum Behandeln von Verbindungen,<br />
das Generic Connection Framework (GCF), das im Paket javax.microedition.io untergebracht<br />
ist. Die CLDC selbst spezifiziert jedoch nur allgemeine Schnittstellen, während die konkreten<br />
Verbindungsprotokolle in den Profilen implementiert werden.<br />
Anfang 2003 wurde die Version 1.1 <strong>der</strong> CLDC-Spezifikation fertiggestellt (JSR-139), die hauptsächlich<br />
die Unterstützung von Fließkommaoperationen festschreibt. Die Verbreitung kompatibler Geräte ist<br />
momentan recht gering. Zudem gibt es noch kein Profil, welches diese Version explizit erfor<strong>der</strong>n
2.2 PROFILE 9<br />
würde.<br />
2.1.2 Die Connected Device Configuration (CDC)<br />
Bezüglich Rechenleistung und Speicher findet sich zwischen den kleinsten mobilen Geräten und <strong>der</strong><br />
Desktop Welt, eine weitere Klasse von Geräten, für die die Connected Device Configuration (CDC) gedacht<br />
ist. Dazu gehören größere PDAs, Navigations- bzw. Multimediasysteme für das Auto o<strong>der</strong> TV-<br />
Settop Boxen. Die typische Hardware dieser Klasse von Geräten besteht aus einem 32-bit Prozessor,<br />
mindestens zwei Megabyte Speicher sowie einer oft dauerhaften Netzverbindung mit vergleichsweise<br />
hoher Bandbreite.<br />
Somit ist in <strong>der</strong> CDC eine vollständige virtuelle Maschine vorgesehen, die <strong>auf</strong> geringen Speicherbedarf<br />
optimiert wurde, die Compact Virtual Machine (CVM). Im Vergleich zur VM <strong>der</strong> Standard Edition<br />
ist die Garbage Collection <strong>der</strong> geringeren Speicherausstattung angepasst, und es fehlen die Hotspot<br />
Techniken zur L<strong>auf</strong>zeitoptimierung – funktional sind beide jedoch identisch.<br />
Die Klassenbibliothek <strong>der</strong> CDC bildet nur eine minimale <strong>Basis</strong>. Zusammen mit den dar<strong>auf</strong> <strong>auf</strong>bauenden<br />
Profilen ergibt sich jedoch ein relativ vollständiges Abbild des Kerns <strong>der</strong> J2SE API in Version<br />
1.3 (Siehe Kapitel 2.2.3). Im Zuge <strong>der</strong> Weiterentwicklung <strong>der</strong> CDC Plattform (JSRs 216 bis 219) soll<br />
weitestgehende Kompatibilität zur Version 1.4 <strong>der</strong> J2SE erreicht werden. Möglich scheint dies nicht<br />
zuletzt durch die steigende Leistungsfähigkeit <strong>der</strong> Hardware dieser Geräteklasse.<br />
2.2 Profile<br />
Die Profile bauen <strong>auf</strong> den <strong>Basis</strong>funktionalitäten <strong>der</strong> Konfigurationen <strong>auf</strong> und sind stärker <strong>auf</strong> einen<br />
bestimmten Gerätetyp zugeschnitten. Sie beinhalten beispielsweise Schnittstellen zur Ein-/Ausgabe<br />
o<strong>der</strong> zur persistenten Datenhaltung.<br />
Oberhalb <strong>der</strong> CLDC sind zwei Profile spezifiziert: das Mobile Information Device Profile (MIDP), welches<br />
sich den Möglichkeiten und Einschränkungen von Mobiltelefonen und Smartphones widmet,<br />
und das Information Module Profile (IMP) für per Mobilfunk vernetzte Systeme, beispielsweise in Getränkeautomaten.<br />
Die Arbeit an einem weiteren <strong>auf</strong> <strong>der</strong> CLDC basierenden Profil, dem PDA Profile<br />
(PDAP), wurde mittlerweile eingestellt. Stattdessen soll die für PDAs benötigte Funktionalität durch<br />
zwei optionale Pakete für das MIDP realisiert werden (Siehe Kapitel 2.3.1).<br />
Auf <strong>der</strong> Seite <strong>der</strong> CDC existieren drei Profile, die <strong>auf</strong>einan<strong>der</strong> <strong>auf</strong>bauen und sich im Wesentlichen<br />
durch den Umfang <strong>der</strong> Unterstützung graphischer Oberflächen unterscheiden.<br />
2.2.1 Das Mobile Information Device Profile (MIDP)<br />
Das am weitesten verbreitete Profil <strong>der</strong> J2ME ist das Mobile Information Device Profile (MIDP). Die<br />
große Mehrzahl an Mobiltelefonen o<strong>der</strong> Smartphones wird heute mit Unterstützung für <strong>Java</strong> und<br />
damit dem MIDP ausgeliefert.<br />
<strong>Anwendungen</strong> für das MIDP, sogenannte Midlets, durchl<strong>auf</strong>en während <strong>der</strong> Ausführung einen Lebenszyklus<br />
ähnlich dem <strong>der</strong> <strong>Java</strong> Applets. Gesteuert wird dieser von einer speziellen, in jedem MIDP
2.2 PROFILE 10<br />
Paket<br />
java.microedition.io<br />
java.microedition.midlet<br />
java.microedition.lcdui<br />
javax.microedition.game<br />
javax.microedition.media<br />
javax.microedition.pki<br />
javax.microedition.rms<br />
Inhalt<br />
Das Generic Connection Framework ist im MIDP um<br />
Deklarationen für die Protokolle UDP, HTTP, HTTPS<br />
und SSL sowie für die Kommunikation über serielle<br />
Schnittstellen erweitert.<br />
Grundfunktionalität für Applikationen, unter an<strong>der</strong>em<br />
Steuerung des Lebenszyklus.<br />
Das Lowest Common Denominator Interface (LCDUI)<br />
unterstützt die Implementierung von Bedienoberflächen.<br />
Das Game API vereinfacht die Programmierung von<br />
2D-Spielen.<br />
Das MIDP 2.0 Media API (M2MAPI) dient <strong>der</strong> Wie<strong>der</strong>gabe<br />
und Aufzeichnung von Medien.<br />
Dieses Paket repräsentiert Zertifikate einer Pubic Key<br />
Infrastructure. Die Zertifikate werden unter an<strong>der</strong>em<br />
bei sicheren Verbindungen über SSL und HTTPS eingesetzt.<br />
Das Record-Management-System (RMS) ist eine einfache,<br />
satzorientierte Datenbankschnittstelle, über die<br />
sich persistente Daten im Endgerät verwalten lassen.<br />
Tabelle 2.1: Pakete des MIDP 2.0 Profils<br />
kompatiblen Gerät vorhandenen Komponente, <strong>der</strong> Application Management Software (AMS), die auch<br />
für Installation, Updates und die Einhaltung des Sicherheitskontextes verantwortlich ist. Die AMS<br />
steuert immer nur eine Anwendung, die gleichzeitige Ausführung mehrerer <strong>Anwendungen</strong> (Multitasking)<br />
ist nicht möglich.<br />
Das MIDP beinhaltet eine eigene, nicht zum AWT o<strong>der</strong> Swing kompatible Benutzungsschnittstelle<br />
(javax.microedition.lcdui). Diese glie<strong>der</strong>t sich in einen Low-Level Teil, <strong>der</strong> einen vollen<br />
Zugriff <strong>auf</strong> das Display des Gerätes bietet, und eine High-Level API, die eine einfache Verwendung<br />
gängiger Elemente wie Dialoge, Formulare o<strong>der</strong> Listen ermöglicht. Die konkrete Ausgestaltung<br />
und Anordnung dieser Elemente geschieht entsprechend des gerätespezifischen Look-and-Feel<br />
weitgehend automatisch. Mit dem Record-Management-System (RMS) wird eine Schnittstelle für die<br />
persistente Datenhaltung integriert, und das Generic Connection Framework wird im MIDP um die<br />
Protokolle UDP und HTTP erweitert.<br />
Aufbauend <strong>auf</strong> <strong>der</strong> in JSR-37 spezifizierten ersten Version des MIDP gibt es seit Ende 2002 das MIDP<br />
in Version 2.0 (JSR-118). Es bringt ein neues, feiner abgestuftes Sicherheitsmodell inklusive <strong>der</strong><br />
Möglichkeit zur automatischen Aktivierung von Programmen über das Netz mittels Push Registry<br />
(siehe Kapitel 3.4). Die Fähigkeiten <strong>der</strong> Benutzeroberfläche wurden erweitert, sowie eigene Schnitt-
2.2 PROFILE 11<br />
stellen für Multimedia- und Spielfunktionalitäten hinzugefügt. MIDP 2.0 ist ungefähr seit Mitte 2004<br />
das gängige Profil neuer Mobiltelefone. Einen guten Anhaltspunkt bieten die Grafikfähigkeiten des<br />
Gerätes: Ist ein Farbdisplay vorhanden, wurde in den meisten Fällen auch die Version 2.0 des MIDP<br />
implementiert.<br />
Angesichts <strong>der</strong> hohen Verbreitung dieses Profils und <strong>der</strong> umfassenden Beteiligung von<br />
Geräteherstellern und Mobilfunkprovi<strong>der</strong>n am Spezifikationsprozess scheint die Weiterentwicklung<br />
gesichert zu sein. Die Arbeiten an <strong>der</strong> nächsten Version (JSR-271) l<strong>auf</strong>en momentan und sollen<br />
im L<strong>auf</strong>e des Jahres 2006 abgeschlossen werden.<br />
2.2.2 Das Information Module Profile (IMP)<br />
Das Einsatzgebiet des Information Module Profile (IMP) sind Module im Bereich <strong>der</strong> Machine-to-<br />
Machine-Kommunikation, die Mobilfunknetze nur zur Datenübertragung verwenden und keine Benutzungsoberfläche<br />
benötigen. Diese Module finden sich als Komponenten beispielsweise in Automaten<br />
o<strong>der</strong> Ortungseinheiten. So könnte ein Getränkeautomat mit dem IMP selbständig Nachschub<br />
or<strong>der</strong>n, o<strong>der</strong> ein Nutzer könnte die aktuelle Position eines IMP-Gerätes mit angeschlossenem GPS-<br />
Empfänger feststellen.<br />
Das IMP in Version 1.0 (JSR-195) stellt eine echte Teilmenge des MIDP 1.0 dar. Version 2.0 (JSR-<br />
228) basiert <strong>auf</strong> dem MIDP 2.0 und erbt damit auch dessen Sicherheitsfunktionalitäten und die<br />
Möglichkeit <strong>der</strong> Aktivierung über das Netz. Via GCF können auch serielle Schnittstellen genutzt<br />
werden, um Leuchtanzeigen o<strong>der</strong> kleine LCDs anzusteuern.<br />
2.2.3 Die Profile <strong>der</strong> CDC<br />
Die CDC-basierten Profile sind durchweg an die J2SE in Version 1.3 angelehnt, um die Erstellung<br />
von mobilen <strong>Anwendungen</strong> für Entwickler mit <strong>Java</strong> Kenntnissen zu erleichtern. Das Foundation Profile<br />
(JSR-46) erweitert die CDC nahezu vollständig um den Kern <strong>der</strong> J2SE API, ergänzt um das Paket<br />
javax.microedition.io, zur leichteren Portierung von CLDC-<strong>Anwendungen</strong>, bietet aber keinerlei<br />
Funktionalität im Bezug <strong>auf</strong> graphische Oberflächen. Das Personal <strong>Basis</strong> Profile (JSR-129) beinhaltet<br />
das Foundation Profile und stellt zusätzlich einen Teil des Abstract Window Toolkit (AWT) für<br />
einfache graphische Oberflächen zur Verfügung. Das Personal Profile (JSR-62) beinhaltet beide vorigen<br />
Profile und bietet neben <strong>der</strong> vollständigen AWT-API auch die Verwendung von Applets. Es ist<br />
zudem zur Migration von <strong>Anwendungen</strong> des JDK 1.1 basierten J2ME-Vorgängers Personal<strong>Java</strong> vorgesehen.<br />
Durch diese Abstufung <strong>der</strong> graphischen Darstellungsmöglichkeiten eignen sich die Profile <strong>der</strong> CDC<br />
für relativ unterschiedliche Geräte. Je nach Eigenschaften <strong>der</strong> Benutzungsoberfläche muss nur <strong>der</strong><br />
hierfür nötige Teil <strong>der</strong> Profile zur Verfügung gestellt werden. Zukünftig soll die J2SE API auch in<br />
Version 1.4 umgesetzt werden, die Weiterentwicklung <strong>der</strong> CDC und <strong>der</strong> zugehörigen Profile findet<br />
sich in den JSRs 216 bis 219. Zusätzlich ist zur Gestaltung anspruchsvoller grafischer Oberflächen<br />
mit dem Advanced Graphics and User Interface Optional Package (JSR-209) eine Implementierung des<br />
Swing-Frameworks geplant, die <strong>auf</strong> <strong>der</strong> nächsten Version des Personal Profile <strong>auf</strong>bauen soll.
2.3 OPTIONALE PAKETE 12<br />
2.3 Optionale Pakete<br />
Optionale Pakete stellen Funktionalitäten bereit, die nur für spezielle <strong>Anwendungen</strong> relevant sind<br />
o<strong>der</strong> von Hardwaremerkmalen abhängen, die nicht unbedingt in allen Geräten einer Klasse vorhanden<br />
sind. Die optionalen Pakete ermöglichen eine verbesserte Nutzung <strong>der</strong> Eigenschaften <strong>der</strong><br />
Abl<strong>auf</strong>umgebung durch die J2ME-<strong>Anwendungen</strong> und schließen damit die Lücke zu den nativen<br />
<strong>Anwendungen</strong>.<br />
An<strong>der</strong>erseits sinkt die Portabilität von <strong>Anwendungen</strong>, die optionale Pakete voraussetzen, und es<br />
entsteht die Gefahr einer weiteren Fragmentierung <strong>der</strong> J2ME-Plattform. Ein Versuch, dieser Problematik<br />
entgegenzuwirken, stellt die aus dem JSR-185 hervorgegangene Spezifikation <strong>Java</strong> Technology<br />
for the Wireless Industrie (JTWI) dar. Sie ergänzt das MIDP um die optionalen Pakete Wireless Messaging<br />
und Mobile Media API und for<strong>der</strong>t zusätzlich ein Farbdisplay mit höherer Auflösung. Damit<br />
sollen die Grundfunktionalitäten momentan gängiger Mobiltelefone für J2ME-<strong>Anwendungen</strong> bereitgestellt,<br />
und das Ganze mit einem prägnanten Label versehen werden.<br />
Im Folgenden werden einige optionalen Pakete kurz vorgestellt, die im Kontext <strong>der</strong> Personalisierung<br />
und <strong>der</strong> Datenübertragung und -synchronisation von beson<strong>der</strong>em Interesse sind.<br />
2.3.1 Das Personal Information Management und das FileConnection API<br />
Die Spezifikation zum Personal Information Management (PIM) API findet sich im JSR-75. Ursprünglich<br />
vorgesehen war die Definition eines eigenständigen Profils für PDAs <strong>auf</strong> <strong>Basis</strong> <strong>der</strong> CLDC,<br />
dieser Plan wurde jedoch verworfen. Stattdessen sollen zwei separate, optionale Pakete für das MIDP<br />
die für PDAs benötigte Funktionalität realisieren: Das FileConnection API für den Zugriff <strong>auf</strong> das<br />
Dateisystem des Gerätes bzw. von Speicherkarten, sowie das PIM API als Schnittstelle zu den internen<br />
Datenbanken für Kalen<strong>der</strong>, Telefonbuch und To-Do-Listen.<br />
Beide Funktionen werfen Fragen <strong>der</strong> Sicherheit <strong>auf</strong>, die erst <strong>auf</strong> <strong>Basis</strong> des MIDP 2 Profils zufriedenstellend<br />
gelöst werden konnten. Die Spezifikationen wurden im Juni 2004 verabschiedet, erste<br />
Geräte, die diese APIs implementieren, sind seit dem Frühjahr 2005 verfügbar.<br />
2.3.2 Das Wireless Messaging API<br />
Das im JSR-120 spezifizierte Wireless Messaging API (WMA) ermöglicht J2ME-<strong>Anwendungen</strong> den Zugriff<br />
<strong>auf</strong> die Sende- bzw. Empfangsschnittstelle für Kurzmitteilungen (SMS). Dies können neben normalen<br />
Textmitteilungen auch Binärnachrichten sein. Die Verbindung wird wie bei <strong>der</strong> CLDC üblich<br />
über das Generic Connection Framework abgewickelt – die URL besteht dabei aus dem Protokollnamen<br />
sms:// gefolgt von <strong>der</strong> Telefonummer des Empfängers.<br />
Der Empfang von Kurznachrichten erfolgt durch eine l<strong>auf</strong>ende Anwendung o<strong>der</strong> per Aktivierung<br />
über die Push Registry, wozu eine Portnummer zur Identifikation an die URL angehängt werden<br />
muss. Version 2.0 <strong>der</strong> WMA (JSR-205) unterstützt zusätzlich auch den Multimedia Message Service<br />
MMS, über den verschiedene Formate (Texte, Bil<strong>der</strong>, Audio o<strong>der</strong> Video) mit einer Nachricht verschickt<br />
werden können.
2.3 OPTIONALE PAKETE 13<br />
2.3.3 Die <strong>Java</strong> APIs für Bluetooth<br />
Bluetooth ist eine Technologie zur drahtlosen Datenübertragung <strong>auf</strong> kurzen Distanzen. Für die J2ME<br />
steht ein in JSR-82 spezifiziertes optionales Paket zur Verfügung, welches Schnittstellen zur Kommunikation<br />
über Bluetooth-Verbindungen bietet.<br />
Das API fällt recht umfangreich aus, da neben verschiedenen, <strong>auf</strong>einan<strong>der</strong> <strong>auf</strong>bauenden Protokollen<br />
auch die Suche nach Diensten bzw. Geräten, sowie Sende- und Empfangsschnittstellen enthalten<br />
sind (mehr dazu in Kapitel 3.5).<br />
2.3.4 Das Remote Method Invocation Optional Package<br />
Die Remote Method Invocation (RMI) [RMI] ermöglicht innerhalb <strong>der</strong> <strong>Java</strong> Plattform den Aufruf von<br />
Methoden entfernter Objekte, sogenannte Remote Procedure Calls (RPC). Für den Entwickler geschieht<br />
<strong>der</strong> Vorgang recht transparent, ein entfernter Methoden<strong>auf</strong>ruf unterscheidet sich kaum von einem lokalen<br />
– die Kommunikationsfunktionen sind in einer automatisch generierbaren Klasse, dem Stub,<br />
gekapselt.<br />
Die RMI API (JSR-66) steht als optionales Paket ausschließlich für die CDC zur Verfügung. Es beinhaltet<br />
nur die für Clients benötigte Funktionalität, Serverdienste können <strong>auf</strong> mobilen Geräten nicht<br />
angeboten werden.<br />
2.3.5 Die J2ME Web Services Specification<br />
Die Web Services ermöglichen es, ähnlich den RPCs, <strong>auf</strong> die Funktionalität entfernter Komponenten<br />
zuzugreifen. Im Gegensatz zur <strong>auf</strong> die <strong>Java</strong> Welt beschränkten RMI verwenden Web Services jedoch<br />
eine <strong>auf</strong> <strong>der</strong> Extensible Markup Language (XML) basierende standardisierte Kodierung, welche einen<br />
hohen Grad an Interoperabilität gewährleisten soll.<br />
JSR-172 spezifiziert eine Schnittstelle zur Nutzung von Web Services mit <strong>der</strong> J2ME – die serverseitige<br />
Bereitstellung von Diensten entfällt auch hier. Da die Profile <strong>der</strong> CLDC den Umgang mit XML-<br />
Dokumenten nicht beherrschen, bringt das Paket neben <strong>der</strong> Unterstützung des zur Kommunikation<br />
verwendeten Simple Object Access Protocols (SOAP) auch einen XML Parser mit (mehr dazu in Kapitel<br />
3.2).<br />
2.3.6 Das JDBC Optional Package<br />
<strong>Java</strong> Database Connectivity (JDBC) bezeichnet eine einheitliche Schnittstelle zu relationalen Datenbanken<br />
verschiedener Hersteller <strong>auf</strong> <strong>der</strong> <strong>Java</strong>-Plattform. Die API beinhaltet den Aufbau von Datenbankverbindungen,<br />
die Übermittlung von SQL-Abfragen und die Transformation und Bereitstellung <strong>der</strong><br />
gelieferten Ergebnisse für das <strong>Java</strong> Programm.<br />
Das optionale JDBC Paket (JSR-169) ermöglicht einen direkten Datenbankzugriff für mobile <strong>Anwendungen</strong>,<br />
ist allerdings nur <strong>auf</strong> <strong>Basis</strong> <strong>der</strong> CDC spezifiziert. Das API stellt eine echte Teilmenge des<br />
java.sql Paketes aus <strong>der</strong> Standard Edition dar.
2.4 SICHERHEIT 14<br />
2.4 Sicherheit<br />
Die Nutzung von <strong>Anwendungen</strong> <strong>auf</strong> mobilen Geräten stellt an die Abl<strong>auf</strong>umgebung hohe Anfor<strong>der</strong>ungen<br />
bezüglich <strong>der</strong> Sicherheit. Diese muss einerseits gewährleisten, dass eine fehlerhafte<br />
Anwendung nicht zu einem Absturz des Gerätes führen o<strong>der</strong> Systemdaten (beispielsweise die des<br />
Adressbuchs) korrumpieren kann, an<strong>der</strong>erseits muss auch <strong>der</strong> Zugriff <strong>auf</strong> bestimmte Ressourcen<br />
des Systems überwacht werden. So sollte zum Beispiel eine Netzverbindung nur dann <strong>auf</strong>gebaut<br />
werden können, wenn <strong>der</strong> Benutzer dies auch wünscht.<br />
Die <strong>Java</strong> 2 Standard Edition verfügt über ein umfangreiches Sicherheitsmodell, mit dessen Hilfe Code<br />
aus unterschiedlichen Quellen ein differenzierter Zugriff <strong>auf</strong> Systemressourcen gewährt werden<br />
kann. In <strong>der</strong> CDC sind diese Sicherheitsfunktionen ebenfalls vorhanden, die CLDC muss wegen<br />
<strong>der</strong> Ressourcenbeschränkungen dar<strong>auf</strong> verzichten. Aus diesem Grund ist die virtuelle Maschine<br />
<strong>der</strong> CLDC sehr restriktiv konzipiert. Sie erlaubt keine Aufrufe nativer Funktionen, ebensowenig<br />
benutzerdefinierte Class Loa<strong>der</strong>.<br />
Die einzige Möglichkeit, diese Beschränkungen zu umgehen, besteht in <strong>der</strong> Modifizierung <strong>der</strong> KVM<br />
selbst – dies ist jedoch im Allgemeinen nur den Herstellern <strong>der</strong> Geräte möglich. Als Konsequenz<br />
daraus können <strong>auf</strong> die CLDC gründende Profile und optionale Pakete nicht nachträglich installiert<br />
werden. Eigene Erweiterungen zur Nutzung nativer Komponenten sind ebenfalls nicht realisierbar.<br />
Auch das Verfahren zur Verifizierung des Bytecodes einer Anwendung musste modifiziert werden.<br />
In <strong>der</strong> J2SE werden alle aus externen Quellen geladenen Klassen einem Integritätscheck unterzogen,<br />
um die Sicherheit des Systems zu gewährleisten. Dieser Algorithmus hätte die begrenzten Ressourcen<br />
<strong>mobiler</strong> Geräte überfor<strong>der</strong>t; so kommt für die CLDC stattdessen ein zweistufiges Verfahren zum<br />
Einsatz, bei dem <strong>der</strong> rechen- und speicherintensive Teil, die sogenannte Preverification, schon bei <strong>der</strong><br />
Erstellung <strong>der</strong> Anwendung vorgenommen wird. Dabei werden spezielle StackMap-Attribute in die<br />
.class Datei eingefügt, welche die Verifikation zur L<strong>auf</strong>zeit wesentlich vereinfachen.<br />
Für den Zugriff <strong>auf</strong> Sicherheitskritische Ressourcen über die APIs <strong>der</strong> J2ME wurde in Version 2.0<br />
<strong>der</strong> MIDP-Spezifikation ein neues Berechtigungsmodell eingeführt. Nötig wurde dies nicht zuletzt<br />
durch eine steigende Anzahl von Paketen, die <strong>auf</strong> native Ressourcen zugreifen, beispielsweise <strong>auf</strong><br />
das Dateisystem <strong>der</strong> Geräte, interne Datenbanken o<strong>der</strong> spezielle Funkverbindungen, wie Bluetooth,<br />
Push-Dienste o<strong>der</strong> SMS. <strong>Anwendungen</strong>, <strong>der</strong>en Integrität durch ein Zertifikat überprüft werden kann,<br />
werden als vertrauenswürdig (trusted) eingestuft. Allen an<strong>der</strong>en (also auch allen MIDP 1.0 kompatiblen)<br />
verwehrt die L<strong>auf</strong>zeitumgebung den Zugriff <strong>auf</strong> bestimmte Schnittstellen gänzlich, während<br />
sie für an<strong>der</strong>e jeweils den Nutzer um Erlaubnis fragen müssen.<br />
Die vertrauenswürdigen <strong>Anwendungen</strong> werden bei <strong>der</strong> Installation je nach Herkunft ihrer Zertifikate<br />
verschiedenen Sicherheitsdomänen (Security Domain) zugeordnet. Eine Sicherheitsdomäne definiert<br />
eine Reihe von Berechtigungen (Permissions), die jeweils eine bestimmte Funktionalität regeln.<br />
Der Name <strong>der</strong> Berechtigung leitet sich dabei von dem Paket o<strong>der</strong> <strong>der</strong> Klasse ab, welche die<br />
gewünschte Funktionalität ermöglichen. Beispielsweise wird die Erlaubnis, HTTP-Verbindungen<br />
<strong>auf</strong>zubauen, anhand <strong>der</strong> Berechtigung java.microedition.io.Connector.http überprüft. Es<br />
gibt Allowed Permissions, die in einer bestimmten Sicherheitsdomäne grundsätzlich zur Verfügung<br />
stehen, und User Permissions, bei denen eine Rückfrage an den Benutzer gestellt wird. Hier wird
2.4 SICHERHEIT 15<br />
zusätzlich festgehalten, ob die Erlaubnis dauerhaft (blanket) o<strong>der</strong> nur für eine Sitzung (session) bzw.<br />
den aktuellen Aufruf (oneshot) erteilt wird.<br />
Das Zertifizierungsverfahren nutzt asymmetrische Verschlüsselungsalgorithmen und kann mehrstufig<br />
erfolgen (Bildung von Zertifikatketten, einer sogenannten Chain of Thrust). Der Anbieter einer<br />
Anwendung bildet eine Prüfsumme über das zu installierende Archiv (<strong>der</strong> .jar-Datei) und verschlüsselt<br />
diese mit seinem privaten Schlüssel. Die Prüfsumme und <strong>der</strong> öffentliche Schlüssel (das<br />
Zertifikat) werden dann im Applikatonsdeskriptor (<strong>der</strong> .jad-Datei) mitgeliefert. Dadurch kann eine<br />
Manipulation des Archivs erkannt werden, allerdings nur, wenn <strong>der</strong> Applikationsdeskriptor aus<br />
einer vertrauenswürdigen Quelle stammt. Um dies zu gewährleisten kann ein Zertifikat selbst noch<br />
einmal signiert werden, und zwar letzten Endes von einer anerkannten Certificate Authority, <strong>der</strong>en<br />
öffentlicher Schlüssel im Endgerät fest gespeichert wurde. Der Grund für dieses Vorgehen liegt in <strong>der</strong><br />
begrenzten Speicherkapazität <strong>der</strong> Geräte, die Schlüssel sämtlicher relevanter Anbieter zu speichern<br />
wäre nicht praktikabel. Es ist für den Benutzer allerdings auch nicht möglich, zusätzliche Schlüssel<br />
hinzuzufügen. <strong>Anwendungen</strong>, die nur mit einem Schlüssel des Entwicklers signiert wurden (sogenannte<br />
Self-Signed Certificates) können nicht installiert werden!<br />
<strong>Anwendungen</strong> für die CLDC l<strong>auf</strong>en also grundsätzlich innerhalb einer sehr beschränkten Sandbox-<br />
Umgebung, <strong>der</strong> Zugriff <strong>auf</strong> kritische, native Schnittstellen ist reglementiert. Allerdings ist die Sicherheit<br />
des Systems auch nur gewährleistet, solange keine Möglichkeit besteht, aus <strong>der</strong> Sandbox<br />
auszubrechen. Eine Methode, dies zu erreichen, wurde Ende 2004 veröffentlicht [c’t04a]. Dabei wurde<br />
unter an<strong>der</strong>em eine Lücke in <strong>der</strong> Preverification ausgenutzt, die dazu führt, dass eine speziell<br />
präparierte Anwendung die Überprüfung zur L<strong>auf</strong>zeit passieren und <strong>auf</strong> Speicherbereiche außerhalb<br />
<strong>der</strong> Sandbox zugreifen kann. Auch in den Bluetooth-Implementierungen vieler aktueller Mobiltelefone<br />
wurden Schwachstellen gefunden, die den Zugriff <strong>auf</strong> sensible Funktionen von außerhalb<br />
ermöglichen [c’t04c].<br />
Da ein Update <strong>der</strong> KVM bislang nur über das Einspielen einer neuen Firmware des Gerätes möglich<br />
ist, sind <strong>der</strong>artige Sicherheitslücken als sehr kritisch anzusehen: Die Hersteller erlauben den Austausch<br />
<strong>der</strong> Firmware nur durch ihre Servicepartner, sodass die Geräte <strong>der</strong> allermeisten Nutzer wohl<br />
anfällig bleiben werden.<br />
Abhilfe scheint aber in Sicht zu kommen: Die Spezifikationen zum Mobile Operational Management<br />
(JSR-232) sollen bis Ende 2005 fertiggestellt werden. Systemadministratoren und Mobilfunkbetreiber<br />
sollen hierdurch in die Lage versetzt werden, veröffentlichte Softwareupdates und Modulergänzungen<br />
einfacher an die mobilen Geräte zu verteilen [c’t05b]. Der Verl<strong>auf</strong> <strong>der</strong> weiteren Entwicklung<br />
bleibt allerdings abzuwarten. Die Gerätehersteller sehen eine mögliche Lösung dieses Problems<br />
wohl auch in <strong>der</strong> Kontrolle <strong>der</strong> Installation von <strong>Anwendungen</strong> mithilfe <strong>der</strong> Signierung. Anstatt die<br />
Software ihrer Geräte erst in einem ausgereifteren Zustand <strong>auf</strong> den Markt zu bringen, stellen sie geprüfte“<br />
<strong>Anwendungen</strong> bereit und können sich so zusätzlich als Zwischenhändler für mobile Dow-<br />
”<br />
nloads etablieren. Aus dem für das Jahr 2008 prognostizierten Marktvolumenen von Multimedia-<br />
Content <strong>auf</strong> Mobiltelefonen in Höhe von 70 Milliarden Euro [c’t04b] ergibt sich eine verlockende<br />
Perspektive für die Gerätehersteller.
Kapitel 3<br />
Datensynchronisation und J2ME<br />
<strong>Anwendungen</strong> <strong>auf</strong> mobilen Geräten stehen als Teil umfangreicherer Informationssysteme häufig in<br />
Interaktion mit stationären Computern, von denen sie spezifische Daten beziehen, o<strong>der</strong> an die sie im<br />
mobilen Einsatz entstandene Modifikationen zurückliefern. Oftmals ist dabei eine dauerhafte Verbindung<br />
zum stationären Teil des Systems nicht möglich o<strong>der</strong> zu langsam bzw. kostspielig, sodass<br />
ein kontinuierlicher Abgleich <strong>der</strong> Daten nicht praktikabel ist. In diesen Fällen muss später ein Austausch<br />
in beide Richtungen erfolgen, bei dem die Aktualität <strong>der</strong> Daten wie<strong>der</strong> hergestellt wird. Die<br />
Limitationen <strong>der</strong> Geräte erfor<strong>der</strong>n in vielen Fällen den Einsatz spezieller Proxy-Lösungen, bei denen<br />
Informationen für die mobilen <strong>Anwendungen</strong> eigens <strong>auf</strong>bereitet werden.<br />
Im Folgenden werden standardisierte Verfahren beschrieben, Daten zwischen Computersystemen<br />
auszutauschen und abzugleichen, die im Rahmen <strong>der</strong> anschließenden Evaluation <strong>auf</strong> ihre Verwendbarkeit<br />
in <strong>Anwendungen</strong> <strong>auf</strong> <strong>Basis</strong> <strong>der</strong> J2ME untersucht werden.<br />
Zunächst werden Beson<strong>der</strong>heiten im Hinblick <strong>auf</strong> die grundlegenden Kommunikationsmöglichkeiten<br />
<strong>der</strong> J2ME gezeigt. Sollen mobile <strong>Anwendungen</strong> ausschließlich diese einfachen Kommunikationsprotokolle<br />
nutzen, müssen geeignete Datenformate und <strong>Synchronisation</strong>sprotokolle eigens entworfen<br />
werden. Der Vorteil dieser Vorgehensweise liegt in einer effizienten Nutzung <strong>der</strong> Geräteressourcen,<br />
Nachteile sind die mangelnde Kompatibilität zu an<strong>der</strong>en <strong>Anwendungen</strong> und die erfor<strong>der</strong>liche Implementierung<br />
geeigneter Methoden für die Kommunikation.<br />
Webservices ermöglichen die plattformunabhängige Übertragung strukturierter Daten, stellen aber<br />
durch die Verwendung XML-basierter Nachrichten erhöhte Anfor<strong>der</strong>ungen an die Bandbreite <strong>der</strong><br />
Verbindung und die Leistungsfähigkeit <strong>der</strong> Geräte. Geeignete Verfahren zur Datensychronisation<br />
müssen jedoch auch bei <strong>der</strong> Verwendung von Webservices entworfen werden.<br />
Noch höhere Anfor<strong>der</strong>ungen an die Hardware <strong>der</strong> Geräte stellt das ebenfalls <strong>auf</strong> dem Austausch<br />
von XML-Nachrichten basierende SyncML-Protokoll. Dafür bietet es ein sehr ausgereiftes und standardisiertes<br />
Konzept zur Datensynchronisation.<br />
Ein direkter Datenaustausch zwischen mobilen <strong>Anwendungen</strong> kann durch die Verwendung von lokalen<br />
Bluetooth-Funkverbindungen durchgeführt werden. Damit eröffnen sich neue Möglichkeiten;<br />
es ergeben sich aber auch Probleme hinsichtlich <strong>der</strong> <strong>Synchronisation</strong> <strong>der</strong> Daten.
3.1 KOMMUNIKATIONSPROTOKOLLE IN DER J2ME:<br />
DAS GENERIC CONNECTION FRAMEWORK 17<br />
CLDC<br />
Connector<br />
(Connection Factory)<br />
<br />
<br />
Connection<br />
<br />
ConnectionNotFoundException<br />
Profile /<br />
optionale Pakete<br />
<br />
Datagram Connection<br />
<br />
Input Connection<br />
<br />
Output Connection<br />
<br />
StreamConnectionNotifier<br />
beispielsweise<br />
MessageConnection<br />
<br />
(WMA)<br />
L2CAP (Bluetooth)<br />
<br />
MIDP 2.0<br />
Stream Connection<br />
<br />
Content Connection<br />
beispielsweise<br />
<br />
FileConnection<br />
RFComm (Bluetooth)<br />
<br />
<br />
<br />
<br />
<br />
UDPDatagram Connection<br />
Comm Connection<br />
Socket Connection<br />
HTTP Connection<br />
ServerSocket Connection<br />
Push Registry<br />
<br />
<br />
Secure Connection<br />
HTTPS Connection<br />
Abbildung 3.1: Das Generic Connection Framework<br />
3.1 Kommunikationsprotokolle in <strong>der</strong> J2ME:<br />
Das Generic Connection Framework<br />
Bei <strong>der</strong> Entwicklung <strong>der</strong> J2ME wurde <strong>der</strong> Bereich Netzwerkkommunikation im Vergleich zur J2SE-<br />
API neu strukturiert, hauptsächlich weil <strong>der</strong> Umfang des java.net Paketes den Speicherbedarf <strong>der</strong><br />
mobilen Geräte zu sehr erhöht hätte. Daneben stand auch <strong>der</strong> Wunsch, einen konsistenteren Umgang<br />
mit den verschiedenen Kommunikationsprotokollen und eine höhere Flexibilität hinsichtlich<br />
des Austauschs <strong>der</strong> herstellerspezifischen Implementierungen zu ermöglichen. Es entstand das Generic<br />
Connection Framework (GCF), ein überwiegend <strong>auf</strong> Interfaces <strong>auf</strong>gebautes API.<br />
Alle Arten von Verbindungen werden über die statische Methode Connector.open() <strong>der</strong> Connection<br />
Factory geöffnet. Dabei wird ein String übergeben, dessen Anfang das jeweilige Protokoll definiert,<br />
gefolgt von einer Netzwerkadresse in einem protokollabhängigen Format. Beispielsweise initialisiert<br />
• http://host:port/file eine HTTP-Verbindung,<br />
• socket://host:port einen Socket für ausgehende TCP-Verbindungen,<br />
• socket://:port einen Socket für eingehende TCP-Verbindungen (keine Hostangabe),<br />
• btspp://deviceID:ServiceUID eine Bluetooth RFComm-Verbindung,<br />
• sms://telefonnummer[:port] eine MessageConnection für Kurzmitteilungen,<br />
• file://// den Zugriff <strong>auf</strong> das Dateisystem.<br />
Zurückgeliefert wird ein Connection-Objekt, welches je nach ausgewähltem Protokoll ein entsprechend<br />
von Connection abgeleitetes Interface implementiert. Dieser Ansatz erlaubt die Un-
3.2 WEBSERVICES 18<br />
terstützung verschiedener Verbindungsarten unter Beibehaltung eines großen Teils des Codes <strong>der</strong><br />
Anwendung.<br />
Im MIDP 2.0 ist nur die Unterstützung <strong>der</strong> Protokolle HTTP und HTTPS zwingend vorgeschrieben,<br />
alle an<strong>der</strong>en sind als optional ausgewiesen. Dies scheint zunächst etwas verwun<strong>der</strong>lich, da HTTP zumeist<br />
<strong>auf</strong> TCP als Transportprotokoll <strong>auf</strong>setzt. In Mobilfunknetzen arbeitet TCP jedoch relativ ineffizient:<br />
Protokollseitige Mechanismen, wie Flusskontrolle o<strong>der</strong> Quittungen, die für eine zuverlässige<br />
Datenübertragung sorgen, vertragen sich relativ schlecht mit <strong>der</strong> vergleichsweise hohen Fehlerrate<br />
und Latenzzeit in diesen Netzen. Deshalb wird <strong>auf</strong> einigen Mobiltelefonen HTTP nicht per TCP/IP,<br />
son<strong>der</strong>n über das Wireless Session Protocol (WSP) [WSP] transportiert. Dieses wurde speziell <strong>auf</strong> die<br />
Eigenschaften von Mobilfunknetzen abgestimmt und bietet darüber hinaus einige neue Funktionen,<br />
beispielsweise eine Unterstützung für Sessions. Analog kann als sicheres Transportprotokoll statt Secure<br />
Sockets Layer (SSL) bzw. Transport Layer Security (TLS), Wireless Transport Layer Security (WTLS)<br />
[WTL] verwendet werden. In diesen Fällen läuft die Kommunikation über ein WAP-Gateway, das<br />
die Umsetzung <strong>der</strong> WAP-spezifischen Protokolle <strong>auf</strong> TCP bzw. TLS/SSL vornimmt.<br />
Bidirektionale Kommunikation, beispielsweise zur Realisierung des Datenaustausches zwischen<br />
zwei mobilen Geräten, setzt die Verwendung von Protokollen <strong>der</strong> Transportschicht voraus. Um<br />
einen TCP-Serverdienst zu registrieren wird Connector.open() mit einem Parameter <strong>der</strong> Form<br />
socket://:port <strong>auf</strong>gerufen. Das Interface StreamConnectionNotifier bietet für einen solchen<br />
ServerSocket die Methode acceptAndOpen(), die wartet, bis ein Client eine Verbindung<br />
zum lokalen Endpunkt <strong>auf</strong>baut und anschließend eine SocketConnection-Instanz zurückliefert.<br />
Die Möglichkeiten von Serverdiensten werden durch die Aktivierung <strong>der</strong> Anwendung via Push Registry<br />
noch erweitert (siehe Kapitel 3.4).<br />
Einige, bei <strong>der</strong> Kommunikation über HTTP mitunter benötigte Funktionen müssen weiterhin in<br />
die Anwendung selbst integriert werden. Werden beispielsweise vom Server Cookies zum Session-<br />
Tracking vorausgesetzt, muss die Anwendung dies explizit implementieren, ebenso fehlt im GCF<br />
die automatische Behandlung von HTTP-Redirects. Davon abgesehen bietet das GCF aber einen<br />
Komfort im Umgang mit Netzverbindungen, <strong>der</strong> die Berücksichtigung von Low-Level Eigenarten<br />
<strong>der</strong> Protokolle in vielen Fällen überflüssig macht.<br />
3.2 Webservices<br />
Webservices dienen dem Datenaustausch und entfernten Funktions<strong>auf</strong>rufen zwischen heterogenen<br />
Informationssystemen bzw. <strong>Anwendungen</strong> über Netzwerke. Für diesen Zweck wurden eine Reihe<br />
von offenen Protokollen und Standards definiert, <strong>der</strong>en Einhaltung eine weitgehende Interoperabilität<br />
zwischen verschiedenen Programmiersprachen und Betriebssystemen sicherstellen soll<br />
[Ngh02]. Die Entwicklung wird von herstellerübergreifenden Organisationen, namentlich dem World<br />
Wide Web Consortium (W3C) [W3Ca] und <strong>der</strong> Organization for the Advancement of Structured Information<br />
Standards (OASIS) [OAS] koordiniert.
3.2 WEBSERVICES 19<br />
3.2.1 Der Aufbau von Webservices<br />
Das Format sämtlicher Protokolle und Standards im Rahmen <strong>der</strong> Webservices basiert <strong>auf</strong> <strong>der</strong> Extensible<br />
Markup Language (XML). Die Verwendung von stardardisierten XML-Formaten ermöglicht die<br />
Plattform- und Sprachunabhängigkeit <strong>der</strong> Webservices und führt zu mensch- und maschinenlesbaren<br />
Nachrichten.<br />
Als Kommunikationsprotokoll und zur Serialisierung <strong>der</strong> Daten wird zumeist das Simple Object Access<br />
Protocol (SOAP) [SOA] genutzt. Ein Client sendet einen Request mittels SOAP an einen Server,<br />
<strong>der</strong> die gewünschte Funktion einer Anwendung <strong>auf</strong>ruft und das Ergebnis wie<strong>der</strong> per SOAP an den<br />
Client zurück sendet. In <strong>der</strong> Regel wird SOAP mittels HTTP transportiert, um z.B. Probleme mit Firewalls<br />
zu vermeiden. Alternativ können aber auch an<strong>der</strong>e Transportprotokolle verwendet werden,<br />
beispielsweise das Simple Mail Transfer Protocol (SMTP), das Wireless Session Protocol (WSP) o<strong>der</strong> das<br />
Object Exchange Protocol (OBEX siehe Kapitel 3.5),.<br />
Zur Beschreibung <strong>der</strong> Funktionalität eines Webservices dient die Web Services Description Language<br />
(WSDL) [W3Cc]. Ein WSDL-Dokument beinhaltet die Datenstrukturen und Schnittstellen <strong>der</strong> angebotenen<br />
Funktionen eines Webservies. Da diese recht komplex werden können ermöglichen viele<br />
Frameworks die automatische Generierung von WSDL-Dokumenten und Serverklassen (sogenannten<br />
Skeletons) anhand des Codes <strong>der</strong> Anwendung, die als Webservice bereitgestellt werden soll.<br />
Analog dazu wird oft auch <strong>der</strong> clientseitige Code zur Nutzung eines Webservices anhand des vom<br />
Server bezogenen WSDL-Dokuments automatisch generiert. Ein sogenannter Stub sorgt für die Komposition<br />
des Request und die Analyse <strong>der</strong> Response. Der Entwickler muss den Stub nur noch in die<br />
Anwendung integrieren und kann über diesen die Funktionalität des Webservices nutzen:<br />
MensaWebService stub=new MensaWebService(url);<br />
WeekData thisWeek = stub.getThisWeek();<br />
WeekData nextWeek = stub.getNextWeek();<br />
Bis <strong>auf</strong> die Notwendigkeit <strong>der</strong> Behandlung von Ausnahmen, die im Zusammenhang mit Fehlern bei<br />
<strong>der</strong> Kommunikation mit dem Server entstehen können, unterscheiden sich somit entfernte Aufrufe<br />
syntaktisch nicht von lokalen.<br />
3.2.2 Webservices in <strong>der</strong> J2ME<br />
Zur Nutzung von Webservices im Rahmen <strong>der</strong> J2ME wurde im JSR-172 ein optionales Paket für CDC<br />
und CLDC spezifiziert. Das WS-API beinhaltet Funktionen zum Parsen von XML-Dokumenten und<br />
ermöglicht die Nutzung entfernter Dienste mittels SOAP. Die serverseitige Bereitstellung von Diensten<br />
ist dagegen nicht Bestandteil <strong>der</strong> Spezifikation.<br />
Zur Analyse von XML-Dokumenten haben sich in <strong>der</strong> <strong>Java</strong>-Welt die <strong>Java</strong> APIs for XML Processing<br />
(JAXP) [JAXb] etabliert. Diese stellen zwei unterschiedliche Methoden des Umgangs mit XML-Daten<br />
zur Verfügung: Die erste besteht in einer ereignisgesteuerten, sequentiellen Verarbeitung, während<br />
bei <strong>der</strong> zweiten Methode das gesamte Dokument analysiert und in Form eines hierarchischen Objektbaums<br />
zugänglich gemacht wird. Das WS-API beinhaltet mit dem Simple API for XML Parsing (SAX)
3.2 WEBSERVICES 20<br />
zur sequentiellen Verarbeitung von XML-Daten nur einen Teil des JAXP; das umfangreichere Document<br />
Object Model (DOM) wird wegen des ungleich höheren Ressourcenbedarfs nicht unterstützt.<br />
Der Aufruf von Webservices via SOAP wird durch eine Teilmenge <strong>der</strong> <strong>Java</strong> APIs for XML based Remote<br />
Procedure Calls (JAX-RPC) [JAXa] realisiert. Sun liefert im Wireless Toolkit ab Version 2.1 auch einen<br />
Stub-Generator für das WS-API mit.<br />
Die endgültige Spezifikation des WS-API datiert <strong>auf</strong> den März 2004. Geräte, <strong>auf</strong> denen dieses optionale<br />
Paket implementieren wird, sind zur Zeit noch recht selten. Aufgrund des relativ grossen<br />
Umfangs des Paketes zeichnet sich ab, dass es zunächst eher <strong>auf</strong> leistungsfähigeren Geräten wie<br />
Smartphones und PDAs Verwendung findet.<br />
Die zur Nutzung von Webservices nötige Funktionalität kann allerdings auch über Bibliotheken an<strong>der</strong>er<br />
Anbieter in eine Anwendung integriert werden, da hierzu keine nativen Komponenten <strong>der</strong><br />
Geräte angesprochen werden müssen. Im Open Source Bereich finden sich dazu eine Reihe von Projekten,<br />
die sich vor allem im Umfang <strong>der</strong> unterstützten Funktionalität und damit auch im Speicherbedarf<br />
<strong>der</strong> Bibliothek unterscheiden. Am ausgereiftesten scheinen zur Zeit zwei Projekte: kXML/kSOAP<br />
[kOb] bietet eine umfangreiche Unterstützung von XML-Technologien für die CLDC, während sich<br />
das unter dem Dach <strong>der</strong> Apache Foundation entwickelte Mirae [Mir] <strong>auf</strong> eine offene Implementierung<br />
des WS-APIs beschränkt. Mirae bietet im Gegensatz zu kSOAP auch einen Stub-Generator.<br />
Aufgrund <strong>der</strong> momentan noch geringen Verbreitung des optionalen WS-Paketes ist bei <strong>Anwendungen</strong>,<br />
die <strong>auf</strong> möglichst vielen Geräten l<strong>auf</strong>fähig sein sollen, die Integration einer dieser Bibliotheken<br />
vorzuziehen.<br />
3.2.3 Einsatz von Webservices in mobilen <strong>Anwendungen</strong><br />
Webservices ermöglichen eine komfortable Integration <strong>mobiler</strong> <strong>Anwendungen</strong> in bestehende Systeme<br />
unabhängig von <strong>der</strong>en Plattform o<strong>der</strong> Programmiersprache. Die Werkzeuge zur automatischen<br />
Codegenerierung <strong>der</strong> Webservice-Frameworks können dem Entwickler die Arbeit stark erleichtern -<br />
eigene Protokolle und Kodierungen zur Datenübertragung erübrigen sich in vielen Fällen.<br />
Demgegenüber steht vor allem ein nicht unerheblicher Overhead <strong>der</strong> textbasierten Protokolle. Dies<br />
ist gerade bei <strong>Anwendungen</strong> <strong>auf</strong> mobilen Geräten <strong>auf</strong>grund <strong>der</strong> geringeren Rechenleistung und<br />
Bandbreite <strong>der</strong> Netzverbindung problematisch. Um dem entgegenzuwirken, werden für mobile<br />
Systeme auch modifizierte Verfahren entwickelt. So verwendet beispielsweise das JXME-Projekt<br />
[JXM], eine Portierung des plattformunabhängigen Peer-to-Peer Netzwerks JXTA“ [JXT] <strong>auf</strong> mobile<br />
”<br />
Geräte, ein eigenes binäres XML-Format. Dies führt zu einem erheblich geringeren Ressourcenbedarf<br />
- unabdingbar angesichts des regen Nachrichtenaustausches zwischen den Teilnehmern eines solchen<br />
Netzes [RS03]. Ein weiteres binäres XML-Format speziell für den Einsatz in Mobilfunknetzen<br />
ist WAP Binary XML [WBX].<br />
Weitere Probleme ergeben sich trotz aller theoretischen Interoperabilität auch aus vielen kleinen<br />
Inkompatibilitäten zwischen den diversen Frameworks unterschiedlicher Anbieter. Die im Rahmen<br />
<strong>der</strong> CDC mögliche, direktere Anbindung einer mobilen Anwendung an <strong>Java</strong>-Systeme mittels RMI<br />
funktioniert wesentlich reibungsloser und effizienter, ist aber nicht so universell einsetzbar wie die<br />
Webservices.
3.3 SYNCML 21<br />
3.3 SyncML<br />
SyncML ist ein plattformunabhängiger, offener Standard zur Datensynchronisation. Die Entwicklung<br />
läuft seit Anfang 2000 und wird unter dem Dach <strong>der</strong> Open Mobile Alliance [OMA] koordiniert.<br />
Beteiligt sind zahlreiche Unternehmen <strong>der</strong> Mobilfunk- und IT-Branche, unter an<strong>der</strong>em Sony Ericsson,<br />
IBM, Palm, Motorola, Symbian, Nokia und Siemens. Ziel dieser Kooperation ist es, die bestehenden,<br />
untereinan<strong>der</strong> inkompatiblen Lösungen zur Datensynchronisation durch einen einheitlichen<br />
Standard zu ersetzen. Neben <strong>der</strong> Datensynchronisation soll SyncML auch zur Administration <strong>mobiler</strong><br />
Geräte und <strong>Anwendungen</strong> (dem sogenannten Over-The-Air Provisioning) verwendet werden. Eine<br />
separate Expertengruppe widmet sich diesem Anwendungsfeld.<br />
Mittels SyncML können Daten unterschiedlicher <strong>Anwendungen</strong> <strong>auf</strong> verschiedenen Geräten ausgetauscht<br />
und im Gesamtkontext konsistent gehalten werden. Dies ermöglicht eine Integration <strong>mobiler</strong><br />
<strong>Anwendungen</strong> in bestehende Informationssysteme. Grundsätzlich eignet sich SyncML für die <strong>Synchronisation</strong><br />
verschiedenster Daten. Zur Zeit verfügbare SyncML-<strong>Anwendungen</strong> dienen meist dem<br />
Abgleich persönlicher Daten, wie Adressbücher, Terminkalen<strong>der</strong>, Aufgabenlisten o<strong>der</strong> Emails. Die<br />
Kommunikation erfolgt mittels XML-basierter Nachrichten und kann über unterschiedliche Verbindungen<br />
durchgeführt werden. Neben <strong>der</strong> gängigen Kommunikation via HTTP sind weitere Verbindungsarten,<br />
beispielsweise über serielle Kabel, Bluetooth, o<strong>der</strong> das Wireless Session Protocol, spezifiziert.<br />
Dabei wurden die Restriktionen <strong>mobiler</strong> Verbindungen, insbeson<strong>der</strong>e die geringe Bandbreite<br />
und die Unzuverlässigkeit <strong>der</strong> Kommunikation berücksichtigt, z.B. durch die optionale Verwendung<br />
eines binären XML-Formats.<br />
3.3.1 Systemarchitekturen<br />
SyncML-Lösungen basieren in <strong>der</strong> Regel <strong>auf</strong> einer Client/Server-Architektur: Auf dem Server werden<br />
die relevanten Daten zentral verwaltet, die Clients verfügen über lokale Kopien dieser Daten.<br />
Auf den Clients vorgenommene Än<strong>der</strong>ungen werden in unregelmäßigen Abständen an den Server<br />
übermittelt und in die zentrale Datenbasis <strong>auf</strong>genommen. Wenn zwei Clients an denselben Daten<br />
Än<strong>der</strong>ungen vornehmen kommt es beim Übernehmen dieser Än<strong>der</strong>ungen <strong>auf</strong> dem Server zu Konflikten.<br />
Der Server hat dafür Sorge zu tragen, das diese Konflikte erkannt und adäquat gelöst werden;<br />
die Clients brauchen sich nicht darum zu kümmern.<br />
Ein System mit einer solchen zentralen Verwaltung <strong>der</strong> Daten erlaubt keinen direkten Datenaustausch<br />
zwischen den Clients. Alternativ wären auch Peer-to-Peer-Systeme unter Verwendung von<br />
SyncML realisierbar. Die Clients müssen dabei die Verbreitung von Än<strong>der</strong>ungen <strong>der</strong> gemeinsam<br />
genutzten Datenbasis an alle Teilnehmer des Systems sicherstellen und dabei <strong>auf</strong>tretende Konflikte<br />
eigenständig lösen. Dies stellt erhöhte Anfor<strong>der</strong>ungen an die Anwendung, die beson<strong>der</strong>s im mobilen<br />
Kontext ins Gewicht fallen. Wegen <strong>der</strong> ungleich höheren Komplexität werden Peer-to-Peer-Systeme<br />
im Rahmen <strong>der</strong> Datensynchronisation zur Zeit noch recht selten genutzt. SyncML wurde daher <strong>auf</strong><br />
die Verwendung in Client/Server-Architekturen optimiert.
3.3 SYNCML 22<br />
3.3.2 Protokolle und Verfahren<br />
Die elementaren Bestandteile des SyncML-Standards sind das Representation Protocol und das <strong>Synchronisation</strong><br />
Protocol. Die Art <strong>der</strong> Identifikation <strong>der</strong> einzelnen Daten und <strong>der</strong> dar<strong>auf</strong> auszuführenden<br />
Operationen sind im Representation Protocol spezifiziert. Zur Identifikation erhält je<strong>der</strong> Datensatz<br />
des Systems eine eindeutige Nummer, den Unique Identifier (UID). Operationen sind beispielsweise<br />
das Hinzufügen, Löschen o<strong>der</strong> Modifizieren von Daten. Um komplexere Transaktionen zu erlauben,<br />
kann eine Gruppe von Anweisungen auch mithilfe <strong>der</strong> Atomic-Kommandos zusammengefasst<br />
werden.<br />
Das <strong>Synchronisation</strong> Protocol spezifiziert den Abl<strong>auf</strong> <strong>der</strong> Kommunikation zwischen Client und Server<br />
und die Struktur <strong>der</strong> dabei ausgetauschten Nachrichten. In <strong>der</strong> Regel beginnt <strong>der</strong> Client den<br />
<strong>Synchronisation</strong>sprozess, die Initiative kann aber auch vom Server ausgehen (Siehe Kapitel 3.4 zu<br />
Push-Diensten im Rahmen <strong>der</strong> J2ME). Zunächst werden sogenannte Initialization Messages ausgetauscht.<br />
Diese Phase kann eine Authentifizierung beinhalten. Zudem können Informationen über<br />
das verwendete Datenformat o<strong>der</strong> zu berücksichtigende Limitationen des Clients (z.B. die maximale<br />
Größe <strong>der</strong> Datenpakete <strong>auf</strong>grund einer geringen Kapazität des Nachrichtenpuffers) übermittelt<br />
werden.<br />
Im Zuge <strong>der</strong> Initialisierung wird auch <strong>der</strong> Typ <strong>der</strong> durchzuführenden <strong>Synchronisation</strong> ermittelt. Dazu<br />
sendet <strong>der</strong> Client den genauen Zeitpunkt <strong>der</strong> letzten <strong>Synchronisation</strong> mit dem Server. Anhand<br />
dieser Information kann festgestellt werden, welche Daten seit diesem Zeitpunkt hinzugefügt, modifiziert<br />
o<strong>der</strong> gelöscht wurden. Diese Daten werden im Folgenden ausgetauscht: Bidirektional, wenn<br />
beide Seiten geän<strong>der</strong>te Daten übermitteln müssen (Two-way Sync) o<strong>der</strong> unidirektional, wenn nur <strong>auf</strong><br />
client- bzw. serverseite Modifikationen zu verzeichnen sind. Eine Beson<strong>der</strong>heit stellt <strong>der</strong> sogenannte<br />
Slow Sync dar, bei dem sämtliche Daten ausgetauscht werden müssen. Dies ist bei <strong>der</strong> ersten <strong>Synchronisation</strong><br />
zwischen Client und Server nötig und kann darüber hinaus beim Auftreten von Problemen<br />
erfor<strong>der</strong>lich werden.<br />
Im Anschluss an die Initialisation kann <strong>der</strong> eigentliche Datenaustausch erfolgen. Dabei werden die<br />
mit auszuführenden Operationen und UID versehenen Datensätze übermittelt. Das Format <strong>der</strong> Daten<br />
ist prinzipiell beliebig. Für den Austausch von Adressen und Terminen sind vCard sowie vCalendar<br />
gängige Formate [vCa].<br />
In <strong>der</strong> letzte Phase <strong>der</strong> <strong>Synchronisation</strong> sendet <strong>der</strong> Client Informationen über erfolgreich<br />
übernommene Än<strong>der</strong>ungen, sowie die UIDs neu hinzugefügter Datensätze an den Server. Dieses<br />
Data Mapping ist nötig, da die Clients im Allgemeinen kürzere UIDs zur Identifizierung <strong>der</strong><br />
Datensätze verwenden, als <strong>der</strong> Server. Dieser speichert sogenannte globale UIDs, mit denen eine<br />
größere Menge an Datensätzen verwaltet werden kann. Der Server kann anhand <strong>der</strong> Informationen<br />
<strong>der</strong> Mapping-Nachricht die lokalen UIDs <strong>der</strong> Clients den korrespondierenden globalen zuordnen.<br />
Diese Abbildungen werden für jeden Client <strong>auf</strong> dem Server gespeichert – zukünftige Än<strong>der</strong>ungen an<br />
den Daten <strong>der</strong> Clients können so vom Server mit <strong>der</strong>en lokalen UIDs versehen übermittelt werden.<br />
Dieses Vorgehen wurde <strong>auf</strong>grund <strong>der</strong> Limitationen <strong>der</strong> mobilen Clients gewählt, denn so brauchen<br />
sie keine Umsetzung <strong>der</strong> UIDs durchführen.
3.4 PUSH DIENSTE 23<br />
3.3.3 Verwendung von SyncML <strong>auf</strong> <strong>Basis</strong> <strong>der</strong> J2ME<br />
Ein optionales Paket zur Integration <strong>der</strong> Datensynchronisation mittels SyncML in die J2ME ist geplant<br />
(JSR-230); die Arbeiten befinden sich allerdings noch in einem recht frühen Stadium. Eine Alternative<br />
bietet das Sync4j-Framework [Syn]. Dieses beinhaltet neben einem in <strong>Java</strong> implementiertem<br />
SyncML-Server auch einen rudimentären Client für die J2ME. Dieser kann als <strong>Basis</strong> für eine Integration<br />
des SyncML-Protokolls in mobile <strong>Anwendungen</strong> dienen.<br />
Einen Zugriff <strong>auf</strong> die internen Adress- und Termindatenbanken <strong>mobiler</strong> Geräte ermöglicht das in<br />
JSR-75 spezifizierte PIM-API, dessen Funktionalität im Rahmen <strong>der</strong> praktischen Evaluation näher<br />
erläutert wird.<br />
3.4 Push Dienste<br />
Mit <strong>der</strong> Push Registry erweitert das MIDP 2.0 mobile <strong>Anwendungen</strong> um die Fähigkeit, in Reaktion<br />
<strong>auf</strong> asynchrone Ereignisse selbständig zu starten. Die Push Registry ist Bestandteil <strong>der</strong> Application<br />
Management Software, welche die Installation und Verwaltung <strong>der</strong> J2ME-<strong>Anwendungen</strong> steuert. Es<br />
gibt zwei Arten <strong>der</strong> Registrierung: Eine dynamische zur L<strong>auf</strong>zeit und eine statische, über spezielle<br />
Attribute im Applikationsdeskriptor, bei <strong>der</strong> Installation.<br />
Auslösende Ereignisse für die Aktivierung einer Anwendung können entwe<strong>der</strong> zeitgesteuerte Alarme<br />
o<strong>der</strong> eingehende Netzverbindungen sein. Die zeitgesteuerte Aktivierung lässt sich für Terminplaner<br />
o<strong>der</strong> periodisch auszuführende Routinetätigkeiten nutzen. Mithilfe <strong>der</strong> Aktivierung über das<br />
Netzwerk kann ein externes Informationssystem die mobile Anwendung direkt über Än<strong>der</strong>ungen<br />
wichtiger Daten informieren o<strong>der</strong> auch eine Standortlokalisierung des Gerätes einleiten.<br />
Ein netzwerkaktivierendes Ereignis wird durch eine URL beschrieben, die einen Serverdienst <strong>auf</strong><br />
dem lokalen Endgerät definiert (Syntax analog zum GCF). Zur Differenzierung verschiedener Dienste<br />
bzw. <strong>Anwendungen</strong> dient die Portnummer. Die Push Registry nimmt ankommende Daten stellvertretend<br />
entgegen, beispielsweise den Aufbau einer TCP-Verbindung o<strong>der</strong> die Pufferung einer eingehenden<br />
Kurzmitteilung. Im Zuge <strong>der</strong> Aktivierung werden diese Daten an die Anwendung weitergegeben,<br />
die zu <strong>der</strong>en Verarbeitung einen entsprechenden Serverdienst starten muss.<br />
Die Behandlung von eingehenden Verbindungen <strong>auf</strong> mobilen Geräten wird durch die Push Registry<br />
sehr vereinfacht, ein Problem besteht jedoch <strong>auf</strong> <strong>der</strong> Gegenseite: Um eine mobile Anwendung per<br />
TCP o<strong>der</strong> UDP von außen ansprechen zu können, muss die IP-Adresse des Gerätes bekannt sein<br />
– die meisten Mobilfunkbetreiber verwenden aber eine dynamische Adressvergabe. Die Abbildung<br />
unverän<strong>der</strong>licher Merkmale, wie Telefonnummer o<strong>der</strong> Subscriber Identity (Kennung <strong>der</strong> SIM-Karte)<br />
<strong>auf</strong> die IP-Adresse ist nur in <strong>der</strong> Domäne des Mobilfunkbetreibers möglich, da hierfür <strong>der</strong> Zugriff<br />
<strong>auf</strong> die Infrastruktur des Netzes nötig ist.<br />
Auch die Möglichkeit, Kurzmitteilungen zur Aktivierung zu verwenden, ist nicht ohne Schwierigkeiten<br />
durchführbar. Hier kann zwar anhand <strong>der</strong> Telefonnummer ein Gerät direkt adressiert werden,<br />
doch viele SMS-Gateways unterstützen keine Binärnachrichten mit Portangabe.
3.5 LOKALE VERBINDUNGEN VIA BLUETOOTH 24<br />
3.5 Lokale Verbindungen via Bluetooth<br />
Bluetooth ist eine Technologie zur drahtlosen Kommunikation mit einer Reichweite von bis zu 100<br />
Metern und einer vergleichsweise geringen Bandbreite von maximal 2,2 Megabit pro Sekunde. Die<br />
Entwicklung wurde von <strong>der</strong> Firma Ericsson begonnen. Seit 1999 werden die Spezifikationen unter<br />
Beteiligung diverser Hersteller <strong>der</strong> Computer- und Mobilfunkbranche innerhalb <strong>der</strong> Bluetooth Special<br />
Interest Group [SIG] entwickelt. Ziel ist die Schaffung eines allgemeinen Standards für die drahtlose<br />
Verbindung von Geräten über kurze Distanzen. Heute finden sich Bluetooth-Module in Desktop-<br />
Computern, PDAs, Mobiltelefonen, Multimediasystemen im Auto und in Peripheriegeräten wie<br />
Druckern, Modems, Tastaturen o<strong>der</strong> Telefon-Headsets. Die Bluetooth-Module zeichnen sich durch<br />
einen geringen Stromverbrauch aus, <strong>der</strong> durch eine Begrenzung <strong>der</strong> Reichweite <strong>auf</strong> 10 Meter noch<br />
weiter reduziert werden kann. Damit eignet sich Bluetooth sehr gut für die Verwendung in mobilen<br />
Geräten.<br />
Den Nutzern soll die Verwendung einer Bluetooth-Verbindung möglichst einfach gemacht werden.<br />
Zu diesem Zweck werden für einzelne Einsatzbereiche sogenannte Profile spezifiziert, welche<br />
die Kopplung von Geräten vereinfachen sollen. Beispielsweise das Basic Printing Profile<br />
für eine Übermittlung von Drucker<strong>auf</strong>trägen, das Dial-up Networking Profile für Internet-<br />
Einwahlverbindungen, das Headset-Profile für Sprachübertragung, o<strong>der</strong> das Serial Port Profile für<br />
eine serielle Datenübertragung. Die Profile können zur Datenübertragung <strong>auf</strong> verschiedene Protokolle<br />
zurückgreifen. Die für die Entwicklung <strong>mobiler</strong> <strong>Anwendungen</strong> relevanten höheren Protokolle<br />
<strong>der</strong> Transport- und Anwendungsebene werden im Folgenden kurz erläutert; <strong>auf</strong> die physische Datenübertragung<br />
(Baseband- bzw. Radio-Layer) wird dabei nicht näher eingegangen.<br />
Dem Aufbau einer Verbindung dient das Service Discovery Protocol (SDP), welches die Suche nach<br />
Geräten und Diensten ermöglicht. Als <strong>Basis</strong>protokoll dient das Logical Link Control and Adaptation<br />
Protocol (L2CAP). Mittels L2CAP können Daten über eine paketorientierte Verbindung übertragen<br />
werden. Das RFComm-Protokoll (Radio Frequency Communication nutzt das L2CAP und bietet dar<strong>auf</strong><br />
<strong>auf</strong>bauend stromorientierte Verbindungen.<br />
Auf <strong>der</strong> Ebene <strong>der</strong> Anwendungschicht befindet sich das sitzungsorientierte Object Exchange Protocol<br />
(OBEX). Es bietet eine mit HTTP vergleichbare Funktionalität. OBEX erhält eine beson<strong>der</strong>e Bedeutung<br />
im Kontext <strong>der</strong> Datensynchronisation, da eine Reihe weiterer Protokolle <strong>der</strong> Anwendungsschicht<br />
unter Verwendung von OBEX spezifiziert wurden, unter an<strong>der</strong>em auch SyncML.<br />
Um <strong>Anwendungen</strong> <strong>auf</strong> <strong>Basis</strong> <strong>der</strong> J2ME die Nutzung von Bluetooth-Verbindungen zu ermöglichen<br />
wurde für diesen Zweck ein optionales Paket spezifiziert (JSR-82). Auf einem Großteil <strong>der</strong> mobilen<br />
Geräte mit integriertem Bluetooth-Modul ist diese Schnittstelle implementiert. Damit eröffnet sich<br />
eine zusätzliche Möglichkeit <strong>der</strong> Kommunikation bei <strong>der</strong> Entwicklung <strong>mobiler</strong> <strong>Anwendungen</strong> <strong>auf</strong><br />
<strong>Basis</strong> <strong>der</strong> J2ME.<br />
Von den oben erwähnten Protokollen stellt das Bluetooth-API SDP, L2CAP und RFComm zur<br />
Verfügung. Eine Unterstützung des OBEX-Protokolls wurde dagegen nur als optional spezifiziert.
Kapitel 4<br />
Praktische Evaluation<br />
Die Möglichkeiten <strong>der</strong> Datenübertragung und -synchronisation im Rahmen <strong>der</strong> J2ME-Plattform sollen<br />
anhand von Beispielanwendungen und Prototypen evaluiert werden. Dabei sollen die im vorigen<br />
Kapitel vorgestellten Technologien eingesetzt und <strong>auf</strong>tretende Probleme dokumentiert werden.<br />
Der Fokus <strong>der</strong> Evaluation liegt dabei <strong>auf</strong> <strong>der</strong> Connected, Limited Device Configuration in Verbindung<br />
mit dem Mobile Information Device Profile. Dieser Schwerpunkt wurde gewählt, da in einem<br />
überwiegenden Teil <strong>der</strong> heute verfügbaren mobilen Geräte dieses Profil Verwendung findet. Die<br />
Verbreitung <strong>der</strong> Connected Device Configuration ist dagegen momentan recht gering, auch <strong>auf</strong> den<br />
leistungsfähigeren PDAs und Smartphones.<br />
Die CLDC wird in <strong>der</strong> Regel von den Herstellern <strong>auf</strong> ihre jeweiligen Geräte portiert, und vor <strong>der</strong><br />
Auslieferung fest in <strong>der</strong>en Firmware integriert. Im Gegensatz dazu werden virtuelle Maschinen für<br />
die CDC durchgängig von Drittanbietern für verschiedene Betriebsysteme <strong>mobiler</strong> Geräte entwickelt.<br />
Von Sun wird zwar eine Referenzimplementation <strong>der</strong> CDC bereitgestellt, allerdings nur für<br />
Linux/x86-Systeme. Sie ist nicht für den Endnutzer gedacht, son<strong>der</strong>n soll als <strong>Basis</strong> für Portierungen<br />
<strong>der</strong> CDC <strong>auf</strong> die verschiedenen Plattformen <strong>der</strong> Geräte dienen. Einzig für den Zaurus, einem Linuxbasierten<br />
PDA von Sharp, ist von Sun eine CDC-Implementation erhältlich [SUNb].<br />
Auf <strong>der</strong> weit verbreiteten Pocket PC-Plattform existieren einige virtuelle Maschinen für <strong>Java</strong> von Drittanbietern<br />
[Ber]. Für Endnutzer verfügbar sind jedoch nur Implementationen von Personal<strong>Java</strong>, einer<br />
<strong>auf</strong> <strong>Java</strong> Version 1.1.8 basierenden Plattform, die seit Ende 1999 nicht mehr weiterentwickelt wird.<br />
Vollständige Implementationen <strong>der</strong> CDC für PocketPCs bieten die JBed-VM <strong>der</strong> Firma Esmertec [Jbe]<br />
und die J9-JVM von IBM [J9]. Diese müssen jedoch von den Geräteherstellern lizensiert werden. Wegen<br />
<strong>der</strong> zusätzlichen Kosten finden sie sich nur in einigen Geräten <strong>der</strong> gehobenen Preisklasse.<br />
Die J9-VM steht auch für einige Geräte mit PalmOS-Betriebssystem zur Verfügung, allerdings nur<br />
eine CLDC-Implementation. Verbreiteter ist auch <strong>auf</strong> dem Palm noch das ältere Personal<strong>Java</strong>. Geräte<br />
mit SymbianOS [Sym] bieten zwar durchgängig die CLDC-Konfiguration, die CDC wird bisher jedoch<br />
nicht unterstützt.<br />
Es erscheint somit wünschenswert, mobile <strong>Anwendungen</strong> <strong>auf</strong> <strong>Basis</strong> <strong>der</strong> CLDC zu entwickeln, um<br />
den Einsatz <strong>auf</strong> möglichst vielen mobilen Geräten zu erreichen. Im Gegensatz zur CDC Plattform,<br />
die sich im Wesentlichen nur in den Möglichkeiten <strong>der</strong> graphischen Oberfläche von <strong>der</strong> <strong>Java</strong> Standard
4.1 ANFORDERUNGEN 26<br />
Edition unterscheidet, sind die Limitationen <strong>der</strong> CLDC jedoch erheblich umfangreicher und betreffen<br />
auch in viel stärkerem Maße die Datensynchronisation.<br />
Die Evaluation soll klären, welche Verfahren zur <strong>Synchronisation</strong> <strong>mobiler</strong> <strong>Anwendungen</strong> <strong>auf</strong> <strong>Basis</strong><br />
<strong>der</strong> CLDC sinnvoll zu verwenden sind, beziehungsweise die Grenzen des Einsatzes <strong>der</strong> CLDC <strong>auf</strong>zeigen.<br />
Im Folgenden werden die Anfor<strong>der</strong>ungen an die Evaluation, <strong>der</strong> Entwurf <strong>der</strong> <strong>Anwendungen</strong><br />
sowie <strong>der</strong>en Implementierung dargestellt. Eine abschließende eine Zusammenfassung <strong>der</strong> dabei gesammelten<br />
Ergebnisse folgt im nächsten Kapitel.<br />
4.1 Anfor<strong>der</strong>ungen<br />
Die Anfor<strong>der</strong>ungen an die zu entwickelnden <strong>Anwendungen</strong> gründen sich primär <strong>auf</strong> die Technologien,<br />
die dabei untersucht werden sollen. Vorzugsweise soll <strong>auf</strong> die Verwendung optionaler Pakete verzichtet<br />
werden, um die <strong>Anwendungen</strong> <strong>auf</strong> möglichst vielen mobilen Geräten einsetzen zu können.<br />
Dem Einstieg in die Entwicklung mit <strong>der</strong> J2ME dient dabei eine Anwendung zur Darstellung von<br />
Speiseplänen <strong>der</strong> Mensa des Studentenwerks <strong>der</strong> Universität Oldenburg <strong>auf</strong> mobilen Endgeräten<br />
wie Mobiltelefonen o<strong>der</strong> Organizern. Dabei sollen zunächst grundlegende Erfahrungen mit den<br />
Fähigkeiten des MIDPs im Bezug <strong>auf</strong> die graphische Oberfläche, die persistente Datenhaltung und<br />
den Datentransfer über Mobilfunknetze gemacht werden. Die Datenübertragung per HTTP wird<br />
mithilfe des Generic Connection Frameworks <strong>der</strong> J2ME realisiert. Die Daten werden vorher aus Effizienzgründen<br />
von einer Serveranwendung <strong>auf</strong>bereitet und in einer eigenen Kodierung übertragen.<br />
Anschließend soll die Anwendung durch eine Komponente zum lokalen Datenaustausch zwischen<br />
zwei Geräten via Bluetooth erweitert werden.<br />
Dar<strong>auf</strong> <strong>auf</strong>bauend sollen fortgeschrittenere Möglichkeiten des Datenaustausches erprobt werden:<br />
Zunächst soll mittels einer modifizierten Version <strong>der</strong> Mensaplan-Anwendung die Kodierung <strong>der</strong><br />
Daten in XML und die Übertragung über das Simple Object Access Protocol realisiert werden. Abschließend<br />
soll anhand eines Prototypen <strong>der</strong> Zugriff <strong>auf</strong> die internen Datenbanken zur Verwaltung<br />
von Adressen und Terminen <strong>der</strong> mobilen Geräte und die <strong>Synchronisation</strong> <strong>der</strong> Daten mit einem entsprechenden<br />
Server mittels Synchronization Markup Language realisiert werden. Bei <strong>der</strong> Kommunikation<br />
mittels SOAP und SyncML soll auch untersucht werden, inwiefern sich diese Technologien auch<br />
über Bluetooth-Verbindungen nutzen lassen.<br />
4.1.1 Anwendung für Mensapläne<br />
Das Studentenwerk Oldenburg stellt die jeweils aktuellen Mensapläne <strong>auf</strong> ihren Webseiten zur<br />
Verfügung, ein Abruf dieser Daten von mobilen Geräten gestaltet sich jedoch problematisch: Das<br />
Layout dieser Seiten ist für mobile Geräte nicht optimal gestaltet. Gerade bei relativ kleinen Displays,<br />
wie sie bei Mobiltelephonen die Regel sind, lassen sich die Informationen kaum sinnvoll ablesen.<br />
Darüber hinaus erhöht die Darstellung in HTML das benötigte Übertragungsvolumen nicht<br />
unwesentlich – das Verhältnis <strong>der</strong> eigentlichen Nutzdaten zu den gesamten HTML-Seiten beträgt<br />
insgesamt ungefähr 5 Kilobyte, gegenüber mehr als 200 KiB.<br />
Die Mensaplan-Anwendung soll ihre Daten von einem hierfür zu implementierenden Proxy-Server
4.1 ANFORDERUNGEN 27<br />
beziehen, <strong>der</strong> die relevanten Daten aus den Webseiten des Studentenwerks extrahiert und für mobile<br />
Geräte <strong>auf</strong>bereitet. Dadurch kann das Volumen <strong>der</strong> zu übertragenden Daten verringert und das<br />
<strong>auf</strong>wendige Parsen <strong>der</strong> HTML-Seiten <strong>auf</strong> den Server ausgelagert werden. Die Darstellung <strong>auf</strong> dem<br />
Endgerät erfor<strong>der</strong>t eine eigene graphische Oberfläche.<br />
Im Vergleich zu standardisierten Verfahren, Internetseiten für die Darstellung <strong>auf</strong> mobilen Endgeräten<br />
zu optimieren [WAP], ermöglicht diese Vorgehensweise die Datenspeicherung und eine Personalisierung<br />
<strong>der</strong> Darstellung direkt <strong>auf</strong> dem Gerät. Darüber hinaus kann ein direkter Datenaustausch<br />
zwischen mobilen Geräten via Bluetooth realisiert werden. Analog kann eine direkte Kommunikation<br />
über Bluetooth auch mit einem Desktop-Computer stattfinden. Diese Möglichkeit soll<br />
mittels einer kleinen Anwendung genutzt werden, welche die Mensapläne aus dem Internet abruft<br />
und via Bluetooth an die Mensaplan-Anwendung überträgt. Dadurch kann <strong>der</strong> Abruf <strong>der</strong> Daten<br />
über das kostenpflichtige Mobilfunknetz gespart werden. Es wäre auch denkbar, <strong>auf</strong> diese Weise<br />
einen kleinen Server zu realisieren, über den sich beispielsweise am Aufgang zur Mensa die neue<br />
Pläne via Bluetooth übertragen ließen.<br />
4.1.2 Nutzung von Webservices<br />
Zunächst soll grundsätzlich untersucht werden, inwiefern sich vorhandene Webservices aus dem<br />
Internet in <strong>Anwendungen</strong> <strong>auf</strong> <strong>Basis</strong> <strong>der</strong> J2ME <strong>auf</strong>rufen lassen. Dazu wird jeweils ein kleiner Prototyp<br />
benötigt, <strong>der</strong> einen Webservice <strong>auf</strong>ruft, und die empfangenen Daten <strong>auf</strong> dem Display ausgibt.<br />
Anschließend soll die Datenübertragung <strong>der</strong> Mensaplan-Anwendung per Webservice realisiert werden.<br />
Dazu müssen sowohl Server als auch mobile Anwendung entsprechend modifiziert werden.<br />
Über die Bluetooth Verbindung sollen ebenfalls XML-kodierte Daten übertragen werden. Hierzu<br />
soll das Object Exchange Protocol Verwendung finden, da bei <strong>auf</strong>wendigeren Protokollen (beispielsweise<br />
SyncML) zumeist OBEX als Transportprotokoll über Bluetooth vorgesehen ist, und so erste<br />
Erfahrungen hiermit gesammelt werden können.<br />
4.1.3 Prototyp zur Datensynchronisation über SyncML<br />
Die Kommunikation unter Nutzung <strong>der</strong> Synchronization Markup Language soll anhand eines weiteren<br />
Prototypen betrachtet werden. Dieser soll <strong>auf</strong> die internen Datenbanken zur Verwaltung von<br />
Adressen des mobilen Gerätes zugreifen, diese Daten innerhalb <strong>der</strong> Anwendung modifizieren und<br />
schließlich mit einem Server mittels SyncML synchronisieren können. Aufbauend <strong>auf</strong> einem solchen<br />
Prototyp könnten personalisierbare <strong>Anwendungen</strong> entwickelt werden, die es dem Benutzer<br />
ermöglichen, für spezielle <strong>Anwendungen</strong> eine partielle Sicht <strong>auf</strong> die vorhandenen Daten zu bekommen<br />
und diese Teile mit an<strong>der</strong>en Benutzern o<strong>der</strong> <strong>Anwendungen</strong> abzugleichen.<br />
Eine Beispielanwendung im Bereich <strong>der</strong> Adressenverwaltung wäre <strong>der</strong> Austausch von Adressen<br />
unter den Studenten eines Seminares o<strong>der</strong> einer Projektgruppe. In diesem Kontext wäre es<br />
wünschenswert, persönliche Daten nur teilweise zur Verfügung stellen zu können, beispielsweise<br />
nur den Namen und die Email-Adresse. Darüber hinaus sollten diese Adressen noch einer eigenen<br />
Kategorie ( Seminar XY“) zugeordnet werden können. Der Austausch bzw. die Aktualisierung <strong>der</strong><br />
”
4.2 ENTWURF 28<br />
Daten könnten dann über einen zentralen Server o<strong>der</strong> direkt zwischen den mobilen Geräten <strong>der</strong> Teilnehmer<br />
erfolgen.<br />
Anhand des Prototypen soll erprobt werden, inwieweit sich solche <strong>Anwendungen</strong> <strong>auf</strong> <strong>Basis</strong> <strong>der</strong><br />
J2ME realisieren lassen. Zunächst wird die <strong>Synchronisation</strong> <strong>der</strong> Daten mittels eines zentralen Servers<br />
untersucht. Anschließend soll geprüft werden, ob ein Datenabgleich auch lokal mit einem weiteren<br />
mobilen Gerät o<strong>der</strong> einer Desktop-Anwendung über die Bluetooth-Schnittstelle realisiert werden<br />
kann.<br />
4.2 Entwurf<br />
In <strong>der</strong> Entwurfsphase wurde zunächst die Systemarchitektur gewählt und eine grobe Struktur <strong>der</strong> zu<br />
implementierenden Programme entworfen. Zudem wurden geeignete Bibliotheken zur Realisierung<br />
<strong>der</strong> geplanten Funktionen gesichtet und ausgewählt.<br />
4.2.1 Architektur System<br />
Für die Mensaplan-Anwendung wird eine Client/Server-Architektur realisiert, mit optionalem, direktem<br />
Datenaustausch <strong>der</strong> Clients untereinan<strong>der</strong>. Der Server dient dabei als Proxy, <strong>der</strong> die Daten<br />
<strong>der</strong> Mensapläne aus den Internetseiten des Studentenwerks extrahiert und für die mobile Anwendung<br />
<strong>auf</strong>bereitet zur Verfügung stellt. Der Einfachheit halber wird bei <strong>der</strong> Desktop-Anwendung <strong>auf</strong><br />
die Integration eines Parsers verzichtet. Die Desktop-Anwendung fungiert als Relay, das die Mensadaten<br />
über das Internet vom Server bezieht, und dann lokal per Bluetooth an den Client überträgt.<br />
Für den SyncML Prototypen wird ein entsprechen<strong>der</strong> SyncML-Server genutzt. Dieser kann die Daten<br />
auch mit weiteren Servern o<strong>der</strong> Desktop <strong>Anwendungen</strong> synchronisieren, primär ist allerdings<br />
die Kommunikation zwischen <strong>mobiler</strong> Anwendung und SyncML-Server von Interesse.<br />
4.2.2 Komponenten Server<br />
Der Server ist ebenfalls in <strong>Java</strong> geschrieben und nutzt Apache Tomcat [Tom] als Servlet-Container.<br />
Ein Servlet stellt für die Mensaplan-Anwendung <strong>auf</strong>bereitete Daten <strong>der</strong> Mensapläne <strong>der</strong> Universität<br />
Oldenburg zur Verfügung. Zum Parsen <strong>der</strong> HTML-Seiten des Studentenwerks werden <strong>der</strong> HTML-<br />
Scanner/Tag-Balancer NekoHTML [Nek] und <strong>der</strong> XML-Parser Xerces [Xer] verwendet. Die Daten<br />
werden zunächst sehr einfach kodiert und als Text im UTF-8 Format (ermöglicht die Verwendung<br />
von Son<strong>der</strong>zeichen) per HTTP verschickt. Anschließend wird <strong>der</strong> Server modifiziert: Als Framework<br />
für Webservices wird Apache Axis [Axi] genutzt, für die Daten eine entsprechende XML-Kodierung<br />
gewählt.<br />
Als Server zur Datensynchronisation mittels SyncML wird zunächst <strong>der</strong> Sync4j-Server [Syn] genutzt,<br />
da <strong>der</strong> Client ebenfalls <strong>der</strong> Sync4j-Plattform entstammt. Darüber hinaus wird die Kompatiblität<br />
<strong>der</strong> Kommunikation über SyncML mit einem weiteren SyncML-fähigen Server getestet. Hierfür<br />
erscheint unter Linux Multisync [mul] am geeignetsten. Diese Anwendung wurde zunächst zur Syn-
4.2 ENTWURF 29<br />
Abbildung 4.1: Architektur Mensaplan<br />
chronisation von Geräten <strong>der</strong> Palm-Plattform mit Desktop-<strong>Anwendungen</strong> entwickelt und mittlerweile<br />
um eine eigenständige SyncML-Komponente erweitert.<br />
4.2.3 Struktur <strong>der</strong> Mensaplan-Anwendung<br />
Der Programmcode <strong>der</strong> Mensaplan-Anwendung wird in drei Pakete unterteilt: Das Paket<br />
mensaplan.connection beinhaltet die Klassen für die HTTP- und Bluetooth-Verbindungen,<br />
im Paket mensaplan.data finden sich die Datenhaltungsklassen und im Paket mensaplan.ui<br />
befinden sich die Klassen <strong>der</strong> graphischen Oberfläche mit den dazugehörigen Command-Listenern.<br />
Abbildung 4.2 gibt einen Überblick über die Klassen und Pakete, die blau eingezeichneten Klassen<br />
gehören zur ersten Version mit einfacher Datenübertragung über HTTP, die roten Klassen<br />
realisieren stattdessen die Datenübertragung via Webservice. Die modifizierte Anwendung zur<br />
Nutzung von Webservices benötigt zwei zusätzliche Bibliotheken. Da die im JSR-172 standardisierte<br />
Webservice-API bisher kaum verbreitet ist, findet hierzu die Open Source Implementation<br />
Mirae [Mir] Verwendung, die mit in das Midlet integriert wird. Die Entscheidung für Mirae wurde<br />
<strong>auf</strong>grund des ausgereiften Eindrucks und des mitgelieferten Stub-Generators getroffen, <strong>der</strong> bei<br />
alternativen Webservice-Bibliotheken für die J2ME (beispielsweise kSOAP [kOb]) lei<strong>der</strong> fehlt. Die<br />
WS-API wird während <strong>der</strong> Implementierungsphase ebenfalls einer näheren Betrachtung unterzogen,<br />
da diese in Zukunft bei stärkerer Verbreitung den Einsatz einer separaten Bibliothek für die<br />
Nutzung von Webservices überflüssig machen könnte.<br />
Die zweite Bibliothek, die dem Midlet hinzugefügt wird, ist AvetanaOBEX [aveb], welche die<br />
Fähigkeiten JSR-82 kompatibler J2ME-Geräte um eine Unterstützung für das OBEX-Protokoll erwei-
4.2 ENTWURF 30<br />
mensaplan.ui<br />
MainUI<br />
private boolean btSupport;<br />
public MainUI(Model data, boolean btSupport)<br />
public void commandAction()<br />
WeekUI<br />
private String weekTitle;<br />
<br />
public WeekUI(Week week, String title)<br />
public void commandAction()<br />
DayUI<br />
<br />
public DayUI(Day day, String title)<br />
public void commandAction()<br />
<br />
Date2String<br />
static public String toString(Long date)<br />
<br />
RemoteDeviceUI<br />
BlueToothUI<br />
public RemoteDeviceUI()<br />
public BlueToothUI(Model data)<br />
public void commandAction()<br />
BLUElet<br />
public static int selectedDevice = -1;<br />
public BLUElet()<br />
public ServiceRecord[] getDiscoveredServices()<br />
public getFirstDiscoveredService()<br />
public getSelectedDevice()<br />
public void startInquiry(int mode, UUID[] serviceUUIDs)<br />
Listener<br />
public void deviceDiscovered()<br />
public void inquiryCompleted(int complete)<br />
public void servicesDiscovered(int transId, ServiceRecord[] records)<br />
public void serviceSearchCompleted(int transId, int complete)<br />
Mensaplan<br />
public Mensaplan()<br />
protected void startApp()<br />
protected void pauseApp()<br />
protected void destroyApp(boolean arg0)<br />
mensaplan.data<br />
DataStore<br />
static public void load(Model data)<br />
static public void save(Model data)<br />
Model<br />
private String url = "http://server.url";<br />
public Model(String url)<br />
private void checkDates()<br />
<br />
Week<br />
private long date;<br />
public Week(long date, Day mon, Day tue, Day wed, Day thu, Day fri)<br />
public void decode(String uri, String localName, String qName, Attributes attributes, String value)<br />
public void serialize(StringBuffer buffer)<br />
public byte[] getBytes()<br />
public void setBytes(byte[] recordStoreData)<br />
<br />
Day<br />
private String menu;<br />
private String alt;<br />
private String ausw;<br />
private String wloy;<br />
public Day(String ausw, String wloy, String alt, String menu)<br />
public void decode(String uri, String localName, String qName, Attributes attributes, String value)<br />
public void serialize(StringBuffer buffer)<br />
Dates<br />
private long thisWeek;<br />
private long nextWeek;<br />
public Dates(long thisWeek, long nextWeek)<br />
public void decode(String uri, String localName, String qName, Attributes attributes, String value)<br />
public void serialize(StringBuffer buffer)<br />
<br />
<br />
<br />
<br />
mensaplan.connection<br />
WSConnection<br />
MensaDataStub<br />
private String enduri;<br />
public WSConnection(Model data)<br />
public void run()<br />
public MensaDataStub(String enduri)<br />
public Dates getCurrentDate()<br />
public Week getThisWeek()<br />
public Week getNextWeek()<br />
IPConnection<br />
<br />
public IPConnection(Model data)<br />
public void run()<br />
MensaDataIF<br />
public Dates getCurrentDate()<br />
public Week getThisWeek()<br />
public Week getNextWeek()<br />
ProcessInput<br />
static public boolean parse(byte[] input, int length, Model data)<br />
BluetoothServer<br />
public BluetoothServer(Model data)<br />
public void run()<br />
BluetoothClient<br />
public BluetoothClient(Model data)<br />
public void setServiceRecord()<br />
public void run()<br />
Abbildung 4.2: Klassendiagramm Midlet
4.2 ENTWURF 31<br />
tert. Die erste Version <strong>der</strong> Datenübertragung per Bluetooth nutzt das einfachere RFComm-Protokoll.<br />
Die Übertragung von XML-Objekten und insbeson<strong>der</strong>e SyncML sind jedoch mit OBEX als zugrundeliegendem<br />
Transportprotokoll spezifiziert.<br />
4.2.4 Desktop-Relay<br />
Diese Anwendung für Desktop PCs bietet die Möglichkeit, die Daten für die Mensaplan-Anwendung<br />
via Bluetooth <strong>auf</strong> das mobile Gerät zu übertragen. Dazu werden die Daten über das Internet vom<br />
MensaServlet bezogen und dann ein BT-Serverdienst eröffnet. Auf diese Weise könnte auch ein<br />
lokaler Servicepoint realisiert werden, an dem mobile Geräte über eine Bluetooth Verbindung mit<br />
aktuellen Daten versorgt werden.<br />
Um diesen Dienst <strong>auf</strong> Desktop-Systemen zu ermöglichen wird die Bibliothek AvetanaBluetooth<br />
[avea] genutzt. Diese implementiert die JSR-82 Pakete javax.bluetooth und<br />
javax.microedition.io für die J2SE. Dadurch kann <strong>der</strong> Code <strong>der</strong> mobilen Anwendung nahezu<br />
unverän<strong>der</strong>t übernommen werden. Die Bibliothek ist plattformübergreifend für Linux, MacOS<br />
X und Windows verfügbar, die nativen Komponenten sind Teil des avetanaBluetooth-Archivs<br />
[GCH04].<br />
4.2.5 SyncML-Prototyp<br />
Der Prototyp wird <strong>auf</strong> <strong>Basis</strong> des Sync4j-Frameworks [Syn] realisiert. Dieses beinhaltet einen <strong>auf</strong> <strong>Java</strong><br />
basierenden SyncML-Server und Unterstützung für diverse Clienten und Datenformate. Darunter<br />
findet sich auch eine Beispielanwendung für die J2ME, mittels <strong>der</strong>er Daten über eine HTTP-<br />
Verbindung mit dem Server synchronisiert werden können. Diese soll als <strong>Basis</strong> des SyncML-<br />
Prototyps dienen. Die Schnittstellen zu internen Datenbanken <strong>der</strong> Adressverwaltung des mobilen<br />
Gerätes stellt das optionale Personal Information Management-Paket (JSR-75) zur Verfügung.<br />
Zu Beginn des Entwurfs des Prototypen stand die Entscheidung, <strong>auf</strong> welche Weise <strong>der</strong> Zugriff <strong>auf</strong><br />
die Adressdatenbanken erfolgen soll. Erste Versuche <strong>auf</strong> dem zum Testen des PIM-APIs verwendeten<br />
Palm Treo ergaben, dass kein Zugriff <strong>auf</strong> das für eine Datensychronisation immanent wichtige<br />
Revision-Feld möglich ist. In diesem Feld wird das Datum <strong>der</strong> letzten Än<strong>der</strong>ung <strong>der</strong> Datenbankeinträge<br />
von Adressbuch und Kalen<strong>der</strong> festgehalten, eine direkte <strong>Synchronisation</strong> kann ohne diese<br />
Information nicht durchgeführt werden. Um Verän<strong>der</strong>ungen <strong>der</strong> Daten durch die nativen <strong>Anwendungen</strong><br />
des Gerätes zu erkennen, sind also innerhalb <strong>der</strong> <strong>Java</strong>-Anwendung persistent gespeicherte<br />
Prüfsummen von allen Datenbankeinträgen nötig.<br />
Die Sync4j-Beispielanwendung speichert alle notwendigen Daten komplett mithilfe des Record Management<br />
Systems (RMS) des MIDPs innerhalb <strong>der</strong> Anwendung. Um möglichst schnell zu Ergebnissen<br />
zu kommen, wurde dieses Vorgehen bei <strong>der</strong> Entwicklung des Prototypens beibehalten. Statt<br />
Prüfsummen zu verwenden, werden sämtliche relevante Daten mittels RMS innerhalb <strong>der</strong> Anwendung<br />
gespeichert. Dadurch kann die Struktur <strong>der</strong> Beispielanwendung weitestgehend beibehalten<br />
werden: Die Methoden zum Zugriff <strong>auf</strong> die internen Datenbanken werden in einer eigenen Klasse<br />
gekapselt und jeweils <strong>auf</strong>gerufen, bevor ein Zugriff <strong>auf</strong> die im RMS gespeicherten Daten erfolgt. Abbildung<br />
4.3 zeigt die relevanten Klassen <strong>der</strong> Anwendung, die modifizierten Methoden sind in blau
4.3 IMPLEMENTIERUNG 32<br />
kennzeichnet. Neu hinzugekommen ist das Paket syncclient.pim, in dem sich neben <strong>der</strong> angesprochenen<br />
PIM-Klasse zwei Klassen zur Realisierung einer beispielhaften graphischen Oberfläche<br />
zur Betrachtung und Modifikation von Adressbucheinträgen des Gerätes finden.<br />
4.3 Implementierung<br />
Im Folgenden werden Beson<strong>der</strong>heiten beschrieben, die sich bei <strong>der</strong> Implementierung im Rahmen <strong>der</strong><br />
J2ME gezeigt haben, insbeson<strong>der</strong>e die dabei <strong>auf</strong>getretenen Probleme. Zunächst wird die verwendete<br />
Entwicklungsumgebung beschrieben, anschließend die Implementierung <strong>der</strong> einzelnen <strong>Anwendungen</strong>.<br />
4.3.1 Verwendete Entwicklungsumgebung<br />
Als Entwicklungsumgebung wurde die Ecplise Plattform [Ecla] Version 3.0 unter Linux verwendet.<br />
Die Beson<strong>der</strong>heiten <strong>der</strong> Entwicklung mit <strong>der</strong> J2ME vereinfacht dabei das EclipseME-Plugin [Eclb].<br />
Es bietet die Integration des J2ME Wireless Toolkits (WTK) [SUNc], <strong>der</strong> Referenzplattform von Sun,<br />
und an<strong>der</strong>er herstellerspezifischer Entwicklungsumgebungen. Dies ermöglicht einen komfortablen<br />
Wechsel zwischen Bibliotheken und Emulatoren verschiedener Hersteller und erleichtert somit das<br />
Testen <strong>auf</strong> verschiedenen Plattformen. Das standardisierte Unified Emulator Interface soll diese Flexibilität<br />
för<strong>der</strong>n und eine einheitliche Anbindung an L<strong>auf</strong>zeitumgebung und Debugger schaffen. Die<br />
Mehrzahl <strong>der</strong> großen Hersteller hat ihre Entwicklungswerkzeuge mittlerweile dahingehend angepasst.<br />
Ein Problem stellt allerdings die Verfügbarkeit <strong>der</strong> Werkzeuge unter Linux dar. Neben Suns<br />
Referenzplattform läuft nur die Entwicklungsumgebung von Nokia weitgehend problemlos unter<br />
Linux, wobei auch diese beiden Anbieter neue Versionen ihrer Werkzeuge zunächst nur für Windows<br />
veröffentlichen. Immerhin unterscheiden sich Linux- und Windows-Versionen nicht hinsichtlich<br />
ihrer Funktionalität; beispielsweise finden sich im WTK neben den Bibliotheken und dem Emulator<br />
auch Werkzeuge zur Betrachtung von Speicherverbrauch und Netzverbindungen <strong>der</strong> emulierten<br />
<strong>Anwendungen</strong> o<strong>der</strong> ein Stub-Generator zur Vereinfachung <strong>der</strong> Nutzung von Webservices.<br />
An<strong>der</strong>e zur Entwicklung von J2ME <strong>Anwendungen</strong> nützliche Werkzeuge stehen dagegen betriebssystemübergreifend<br />
zur Verfügung. Der ProGuard Obfuscator [Pro] reduziert den Umfang des Codes<br />
<strong>der</strong> Anwendung durch die Entfernung nicht benötigter Methoden und Klassen und eine Verkürzung<br />
von Klassen-, Methoden- und Variablennamen <strong>auf</strong> ein o<strong>der</strong> zwei Zeichen. Antenna [Ant] bietet J2ME<br />
spezifische Ant-Tasks, beispielsweise preverification, obfuscation o<strong>der</strong> Signierung. Zur Erstellung von<br />
.jar-Archiven integriert das EclipseME-Plugin auch diese Werkzeuge. Darüberhinaus kann ein dazugehöriger<br />
Application Descriptor (die .jad-Datei) generiert und bearbeitet werden.<br />
Die Entwicklung von J2ME <strong>Anwendungen</strong> ist <strong>auf</strong> dieser <strong>Basis</strong> mit frei verfügbaren Programmen<br />
unter Linux komfortabel möglich, einziges Manko bleibt die relativ geringe Auswahl an Emulatoren<br />
verschiedener Hersteller. Eine kostenpflichtige alternative Entwicklungsumgebung für die J2ME<br />
unter Linux bietet IBM mit dem WebSphere Studio Device Developer (WSDD). IBM hat das WSDD insbeson<strong>der</strong>e<br />
<strong>auf</strong> die eigene J9-VM abgestimmt, sodass sie sich bei <strong>der</strong> Entwicklung von <strong>Anwendungen</strong><br />
für Geräte mit dieser VM anbietet. So wird beispielsweise ein sehr leistungsfähiger Stub-Generator
4.3 IMPLEMENTIERUNG 33<br />
syncclient.pim<br />
syncclient.midlet<br />
ContactForm<br />
public ContactForm(Record record, PIMStore pimStore)<br />
SyncClientMIDlet<br />
public Record saveContact()<br />
public SyncClientMIDlet()<br />
protected void startApp()<br />
protected void pauseApp()<br />
protected void destroyApp()<br />
public genMainScr()<br />
public List displayDB()<br />
public void commandAction()<br />
private void initializePIMData()<br />
private void synchronize()<br />
private void deleteRecord(Record record)<br />
DataList<br />
public DataList(PIMStore pimStore)<br />
UIDMap<br />
public UIDMap()<br />
public String getPimUID(String UID)<br />
public void addMapping(String UID, String pimUID)<br />
public void removeMapping(String UID)<br />
public Hashtable getReverseMapping()<br />
PIMStore<br />
public PIMStore()<br />
public Record addPIMContact(Record record2add)<br />
public Record modifyPIMContact(Record modifiedRecord)<br />
public boolean deletePIMContact(String UID)<br />
public Hashtable getReverseMapping()<br />
protected Record addPIMContact(Contact contact2add)<br />
protected Record modifyPIMContact(String UID, Contact modContact)<br />
protected fromSerialFormat(String vCard)<br />
protected String toSerialFormat(Contact contact)<br />
private retrievePIMContact(String UID)<br />
syncclient.sps<br />
DataStore<br />
Record<br />
private String key;<br />
private char state;<br />
private String content;<br />
public Record(byte[] recordStoreData)<br />
public Record(String key, char state, String content)<br />
public getters/setters()<br />
public byte[] getBytes()<br />
public DataStore(String recordStoreName)<br />
public void setLastTimestamp(long lastTimestamp)<br />
public long getLastTimestamp()<br />
public void deleteRecord(String key)<br />
public void storeRecord(Record record)<br />
public Vector getNoDeletedRecords()<br />
public Vector getRecords(char state)<br />
public void startDSOperations()<br />
public void commitDSOperations()<br />
syncclient.spds<br />
SyncManagerImpl<br />
protected SyncManagerImpl(DataStore dataStore, PIMStore pimStore)<br />
public void sync()<br />
private String syncInitialization()<br />
private String syncModifications()<br />
private String sendAlertMessage()<br />
private void syncMapping()<br />
private String postRequest(String request)<br />
private void checkStatus(String msg, String statusOf)<br />
private void checkServerAlerts(String msg)<br />
private void prepareInizializationMessage()<br />
private boolean processModifications(String modifications)<br />
private void prepareModificationMessage()<br />
private void prepareAlertMessage()<br />
private void prepareMappingMessage()<br />
private void loadResources()<br />
private String createAlerts(String sourceUri)<br />
private Vector filterRecordsForFastSync()<br />
private Vector filterRecordsForSlowSync()<br />
private String prepareSyncTag(Vector records, String sourceURI)<br />
private int getSourceAlertCode(String sourceURI)<br />
private String getContent(Record record)<br />
Abbildung 4.3: Klassendiagramm SyncML-Client (nur relevante Klassen)
4.3 IMPLEMENTIERUNG 34<br />
für die Verwendung von Webservices mitgeliefert und <strong>Anwendungen</strong> können direkt <strong>auf</strong> einem J9-<br />
Emulator getestet werden. Ohne das WSDD muss hierzu die J9-VM <strong>auf</strong> einem Palm-Emulator installiert<br />
werden, um dann eine Anwendung <strong>auf</strong> <strong>der</strong> emulierten VM zu installieren – die Fehlersuche<br />
wird dadurch sehr erschwert.<br />
Zum Testen <strong>der</strong> <strong>Anwendungen</strong> wurden neben den Emulatoren im Wesentlichen drei Geräte verwendet,<br />
welche die Palette an unterschiedlichen Plattformen recht gut abdecken: In die Klasse <strong>der</strong> einfachen<br />
Mobiltelefone mit Unterstützung für <strong>Java</strong> und Bluetooth fällt das Nokia 6230. Das Nokia 7650 ist<br />
dagegen ein Smartphone <strong>auf</strong> SymbianOS <strong>Basis</strong> und bietet neben <strong>Java</strong> und Bluetooth vor allem einen<br />
größeren Bildschirm. Aus <strong>der</strong> Geräteklasse <strong>der</strong> PDAs mit J2ME Unterstützung steht ein Palm Treo<br />
650 Smartphone zur Verfügung, welches als einziges dieser Geräte die PIM und Webservices API<br />
implementiert, aber lei<strong>der</strong> keinen Zugriff <strong>auf</strong> Bluetooth unter <strong>Java</strong> ermöglicht. Die Kommunikation<br />
über Bluetooth konnte somit nur anhand <strong>der</strong> beiden Nokia Geräte getestet werden.<br />
4.3.2 Mensaplan Servlet<br />
Der Server nutzt einen XML-Parser, um die Daten <strong>der</strong> Mensapläne aus den Webseiten des Studentenwerks<br />
zu extrahieren. Dieser erzeugt aus einer HTML-Seite eine Baumstruktur, aus <strong>der</strong> die<br />
relevanten Informationen ausgewählt werden können. Eine graphische Ausgabe dieses DOM-Baums<br />
ermöglicht es, die hierzu nötigen Befehle einfach abzulesen. Der Einsatz eines DOM-Parsers wurde<br />
gewählt, da <strong>auf</strong> den Webseiten des Studentenwerks keinerlei Trennung zwischen Layout und Inhalt<br />
vorgenommen wurde: Sie bestehen aus tief verschachtelten HTML-Tabellen, in <strong>der</strong>en Zellen sich die<br />
verschiedenen Gerichte für die einzelnen Wochentage wie<strong>der</strong>finden. Zudem kann <strong>der</strong> DOM-Parser<br />
bei eventuellen Än<strong>der</strong>ungen am Layout <strong>der</strong> Seiten des Studentenwerks unkompliziert angepasst<br />
werden.<br />
org.w3c.dom.traversal.TreeWalker walker=dom.createTreeWalker(doc,nodeFilter);<br />
for(int i=0;i
4.3 IMPLEMENTIERUNG 35<br />
den Wochen mit einem Pipe-Symbol getrennt werden. Innerhalb <strong>der</strong> Daten einer Woche wird das<br />
Dollarzeichen zur Trennung verwendet. Als erstes wird <strong>der</strong> long-Wert des Datums geschrieben (Vergangene<br />
Zeit in Millisekunden nach <strong>der</strong> standard base time 01.01.1970, 00:00:00 GMT). Dieses Datumsformat<br />
wurde gewählt, da <strong>Java</strong> intern ohnehin mit diesem Wert arbeitet. Eine bestimmte Woche wird<br />
von <strong>der</strong> Server-Anwendung mit diesem Zeitstempel versehen, <strong>der</strong> Wert ist danach im gesamten System<br />
gültig. Dadurch kann es auch bei einem Datenaustausch zwischen zwei mobilen <strong>Anwendungen</strong><br />
nicht zu Inkonsistenzen <strong>auf</strong>grund geringfügig unterschiedlicher Uhrzeiten <strong>auf</strong> den Geräten kommen.<br />
Im Anschluss an das Datum folgen die Wochentage von Montag bis Freitag. Je<strong>der</strong> Tag beinhaltet<br />
eine Zeichenkette für Menü, Alternativ, Auswahl und Wechloy in dieser Reihenfolge.<br />
$1122854400000$Shop Suey mit Huhnfleisch, Gemüse und Sojakeimen, Reis<br />
Joghurt mit Aprikosen<br />
$Chinakohlsalat<br />
Vollkornnudeln überbacken, Tomaten-Basilikumsauce<br />
Frisches Obst<br />
$ ...<br />
Ab Freitag 15 Uhr werden die Seiten des Studentenwerks <strong>auf</strong> aktualisierte Daten überprüft, um diese<br />
dann gegebenenfalls zu übernehmen.<br />
4.3.3 Mensaplan-Anwendung<br />
Eine Anwendung für das MIDP wird grundsätzlich von <strong>der</strong> abstrakten Klasse<br />
javax.microedition.midlet.MIDlet abgeleitet, die den Lebenszyklus <strong>der</strong> Anwendung verwaltet.<br />
Der Aufbau eines MIDlets ist vergleichbar mit dem eines Applets aus <strong>der</strong> J2SE. Es gibt definierte<br />
Zustände und Methoden, die bei einem Zustandswechsel <strong>auf</strong>gerufen werden. Nach dem<br />
Initieren eines MIDlets wird die Methode startApp() <strong>auf</strong>gerufen, in <strong>der</strong> die Darstellung <strong>auf</strong><br />
dem Bildschirm gestartet wird (display.setCurrent(mainMenu)). Eine Unterbrechung <strong>der</strong> Programmausführung,<br />
beispielsweise zur <strong>der</strong> Annahme eines Telefonanrufs kann über pauseApp()<br />
geregelt werden. Beim Fortsetzen wird wie<strong>der</strong> startApp() <strong>auf</strong>gerufen. Der Lebenszyklus eines<br />
MIDlets endet mit dem Aufruf von destroyApp().<br />
Der Konstruktor des Mensaplan-Midlets erzeugt die Objekte zur Datenhaltung, dabei werden gegebenenfalls<br />
<strong>auf</strong> dem Gerät gespeicherte Daten geladen. Wenn das Gerät Bluetooth nach JSR-82<br />
unterstützt, werden die entsprechenden Klassen instanziiert. Anschließend wird das Hauptmenü<br />
erstellt.<br />
4.3.3.1 Datenklassen und persistente Datenhaltung mit dem RMS<br />
Im Paket mensaplan.data finden sich die Datenhaltungsklassen: ein Day-Objekt speichert die Tagesgerichte<br />
für Menü, Alternativ, Auswahl und Wechloy jeweils als Zeichenkette. Ein Week-Objekt<br />
beinhaltet neben den fünf Wochentagen das Anfangsdatum <strong>der</strong> Woche als long-Wert.<br />
Die Haupt-Datenklasse lädt bei <strong>der</strong> Initialisierung die Daten <strong>der</strong> betrachteten zwei Wochen aus dem<br />
persistenten Speicher des Geräts und überprüft diese <strong>auf</strong> Aktualität. Die Klasse DataStore bietet<br />
hierzu Methoden zum Zugriff <strong>auf</strong> das Record-Management-System (RMS).
4.3 IMPLEMENTIERUNG 36<br />
Das RMS API ist eine einfache satzorientierte Datenbankschnittstelle, über die sich persistente Daten<br />
im Gerät verwalten lassen. Ein Record-Store besteht aus einer Anzahl Records mit variabler<br />
Länge, ein Record selbst ist ein einfaches Byte-Array ohne vorgegebene Struktur. Die Daten einer<br />
ganzen Woche werden jeweils in einem Record gespeichert, die Klasse Week stellt dazu die Methoden<br />
getBytes() bzw. setBytes(Byte[]rsData) bereit.<br />
Der Zugriff <strong>auf</strong> einen Record erfolgt anhand einer ID, die beim Erstellen des Records vom RMS<br />
vergeben wird. Wird ein Record gelöscht erlaubt das RMS keine erneute Vergabe <strong>der</strong>selben ID.<br />
Der gängige Weg zum Wie<strong>der</strong><strong>auf</strong>finden von Records besteht darin, einen speziellen Filter zu erstellen<br />
und diesen an das RMS zu übergeben. Zurückgeliefert wird eine RecordEnumeration in <strong>der</strong><br />
dann <strong>der</strong> gewünschte Record gesucht werden muss. Um dies zu vermeiden erstellt die Mensaplan-<br />
Anwendung nur einmal beim Anlegen des Record-Stores neue Records, danach werden diese einfach<br />
mit neuen Daten überschrieben. Die Daten <strong>der</strong> aktuellen Woche finden sich damit immer unter<br />
<strong>der</strong> RecordID 1, die Daten <strong>der</strong> nächsten unter <strong>der</strong> RecordID 2.<br />
//openRecordStore(name,true) erzeugt einen RS,<br />
//wenn noch keiner unter diesem Namen vorhanden ist<br />
if (RecordStore.listRecordStores()==null){<br />
RecordStore store=RecordStore.openRecordStore("Mensa",true);<br />
byte [] tmp;<br />
tmp=data.getThisWeek().getBytes();<br />
store.addRecord(tmp,0,tmp.length);<br />
tmp=data.getNextWeek().getBytes();<br />
store.addRecord(tmp,0,tmp.length);<br />
store.closeRecordStore();<br />
}<br />
//Daten laden:<br />
data.getThisWeek().setBytes(store.getRecord(1));<br />
//Daten speichern:<br />
byte [] tmp=data.getThisWeek().getBytes();|<br />
store.setRecord(1,tmp,0,tmp.length);<br />
Die Daten werden bei Beendigung des MIDlets in <strong>der</strong> Record-Store geschrieben.<br />
protected void destroyApp(boolean arg0){<br />
DataStore.save(data);<br />
}<br />
4.3.3.2 Graphische Oberfläche<br />
Die Schnittstelle für graphische Oberflächen des MIDP glie<strong>der</strong>t sich in Low- und High-Level APIs<br />
<strong>auf</strong>. Das Low-Level API ermöglicht den vollen Zugriff <strong>auf</strong> den Bildschirm des Gerätes <strong>auf</strong> Pixelebene.<br />
Das High-Level API bietet vordefinierte Dialogelemente, wie Formulare, Listen, Text- und<br />
Grafikboxen, Eingabefel<strong>der</strong> o<strong>der</strong> Popupfenster. Das genaue Aussehen dieser Elemente ist dabei von<br />
<strong>der</strong> Implementierung des jeweiligen Geräts abhängig. Eine gleichzeitige Mischung aus High- und<br />
Low-Level Elementen <strong>auf</strong> dem Bildschirm ist nicht möglich.
4.3 IMPLEMENTIERUNG 37<br />
Abbildung 4.4: Graphische Oberfläche <strong>der</strong> Mensaplan-Anwendung<br />
Für die Mensaplan-Anwendung reichen die Möglichkeiten aus, die das High-Level API bietet, da<br />
nur textuelle Informationen angezeigt werden sollen. Neben <strong>der</strong> einfacheren Benutzung liegt ein<br />
weiterer Vorteil <strong>der</strong> Verwendung des High-Level APIs auch in <strong>der</strong> Anpassung <strong>der</strong> Darstellung an<br />
die Fähigkeiten des Geräts – <strong>auf</strong> einem größeren Display werden die Informationen automatisch<br />
entsprechend vorteilhafter dargestellt (siehe Abbildung 4.4). Bei <strong>der</strong> Gestaltung <strong>der</strong> Menüführung<br />
wurde allerdings <strong>auf</strong> kleinere Displays Rücksicht genommen, es werden maximal fünf Menüpunkte<br />
gleichzeitig dargestellt. Es wäre möglich, auch hier eine dynamische Anpassung vorzunehmen, indem<br />
bei <strong>der</strong> Initialisierung die Größe des Displays abgefragt würde. Da die Anwendung keine komplexe<br />
Menüführung benötigt wird dar<strong>auf</strong> verzichtet.<br />
Die Klassen für die graphische Oberfläche inklusive <strong>der</strong> dazugehörigen Command-Listener finden<br />
sich im Paket mensaplan.ui. Den Untermenüs für Tag bzw. Woche wird jeweils ein Datenobjekt<br />
vom Typ Day o<strong>der</strong> Week übergeben, <strong>der</strong> Titel dieser Menüs wird durch die Hilfsklasse<br />
Date2String erzeugt, da die CLDC 1.0 eine date.toString() Methode lei<strong>der</strong> nicht anbietet.<br />
Der Menüpunkt <strong>der</strong> Bluetooth Komponente wird nur angezeigt, wenn das Gerät auch das Bluetooth<br />
API für <strong>Java</strong> unterstützt. Beim Aufbau einer Verbindung über Bluetooth muss zunächst nach<br />
Geräten und den von diesen angebotenen Diensten gesucht werden. Für diese Device und Service<br />
Discovery des Bluetooth Clients wird Bluelet [Blu] verwendet, eine frei verfügbare Komponente, die<br />
hierzu eine graphische Oberfläche für die J2ME erstellt.<br />
4.3.3.3 Netzverbindung<br />
Die Klassen für die Kommunikation über Internet bzw. Bluetooth Verbindungen finden sich im Paket<br />
mensaplan.connection. Die Kommunikation findet dabei stets in eigenen Threads statt, um
4.3 IMPLEMENTIERUNG 38<br />
die weitere Programmausführung nicht zu blockieren.<br />
Die URL des Servers, <strong>der</strong> die <strong>auf</strong>bereiteten Daten <strong>der</strong> Mensapläne anbietet, wird aus dem Applikations<br />
Deskriptor ausgelesen und kann somit modifiziert werden, ohne die Anwendung neu kompilieren<br />
zu müssen. Das Auslesen erfolgt bei <strong>der</strong> Initialisierung <strong>der</strong> Anwendung durch den Aufruf von<br />
getAppProperty(" Server-URL "). Durch diese Properties im Applikations Descriptor können<br />
einem MIDlet beliebige Parameter übergeben werden.<br />
Über eine Instanz <strong>der</strong> Klasse IPConnection kann eine HTTP-Verbindung zum Server hergestellt<br />
werden. Die Kommunikation läuft über das Generic Connection Framework des MIDPs.<br />
Wenn die Übertragung erfolgreich war, werden die empfangene Daten <strong>der</strong> statischen Methode<br />
ProcessInput.parse() zur Verarbeitung übergeben.<br />
//Http-Verbindung zum Server (read-only,timeout enabled)<br />
HttpConnection hc = (HttpConnection)Connector.open(url,Connector.READ,true);<br />
InputStream in = hc.openInputStream();<br />
int contentLength = (int)hc.getLength();<br />
byte[] raw = new byte[contentLength];<br />
//Daten lesen<br />
in.read(raw);<br />
in.close();<br />
hc.close();<br />
ProcessInput.parse(raw,length,data);<br />
4.3.3.4 Verbindungen über Bluetooth<br />
Bei <strong>der</strong> Initialisierung <strong>der</strong> Anwendung wird zunächst überprüft, ob das Gerät Bluetooth unterstützt,<br />
und die entsprechenden <strong>Java</strong> Schnittstellen nach JSR-82 anbietet. Lei<strong>der</strong> gibt es keinen einheitlichen<br />
Mechanismus, mittels dessen <strong>Anwendungen</strong> feststellen können, ob ein bestimmtes Paket in <strong>der</strong> Abl<strong>auf</strong>umgebung<br />
implementiert ist. Einige Spezifikationen schreiben vor, dass die Versionsnummer des<br />
Pakets als System-Property abrufbar sein muss. Wenn die Versionsnummer nicht definiert ist kann<br />
die Anwendung davon ausgehen, dass das betreffende Paket nicht vorhanden ist. Für das optionale<br />
Bluetooth-Paket ist diese Anfor<strong>der</strong>ung nicht spezifiziert. Hier schafft die Suche nach einer Instanz<br />
<strong>der</strong> LocalDevice-Klasse Abhilfe – nur wenn sie gefunden wird, ist eine Unterstützung für Bluetooth<br />
gegeben.<br />
try{<br />
Class.forName("javax.bluetooth.LocalDevice");<br />
btSupport=true;<br />
}catch (ClassNotFoundException e){<br />
btSupport=false;<br />
}<br />
Ein je<strong>der</strong> Bluetooth-Dienst wird mittels einer eindeutigen UUID (Universally Unique Identifier,<br />
2,4 o<strong>der</strong> 16 Byte) definiert, für den Austausch <strong>der</strong> Mensapläne wird willkürlich<br />
0x0102030405060708090A0B0C0D0E0F10 gewählt. Anhand dieser UUID kann <strong>der</strong> Bluetooth<br />
Client bei <strong>der</strong> Gerätesuche einen passenden Server finden. Als Transportprotokoll für den Datenaustausch<br />
wird das stromorientierte RFComm-Protokoll genutzt.
4.3 IMPLEMENTIERUNG 39<br />
Server<br />
Zu Beginn je<strong>der</strong> Kommunikation muss <strong>der</strong> Bluetooth Stack initialisiert werden, dies gilt für Client<br />
und Server gleichermaßen. Der Server macht sich zusätzlich für an<strong>der</strong>e Geräte <strong>auf</strong>findbar. Durch<br />
die Übergabe von DiscoveryAgent.LIAC könnte hier die Kommunikation auch <strong>auf</strong> Clienten beschränkt<br />
werden, mit denen zuvor ein Pairing (Authentifizierung anhand von PINs) durchgeführt<br />
wurde. Dies müsste allerdings ausserhalb <strong>der</strong> <strong>Java</strong>-Anwendung stattfinden, das Bluetooth-API bietet<br />
hierzu keine Möglichkeit.<br />
LocalDevice device = LocalDevice.getLocalDevice();<br />
device.setDiscoverable(DiscoveryAgent.GIAC);<br />
Das Bereitstellen eines Serverdienstes verläuft nach dem gängigen Schema des Generic Connection<br />
Frameworks: Es wird eine Server-URL gebildet, die sich aus <strong>der</strong> UUID und dem verwendeten Protokoll<br />
zusammensetzt. Mit dieser wird über die Connection-Factory ein Connection Notifier erzeugt,<br />
und schließlich dessen Methode acceptAndOpen() <strong>auf</strong>gerufen. Diese blockiert nun den Thread<br />
solange, bis sich ein Client verbindet.<br />
String url = "btspp://localhost:0102030405060708090A0B0C0D0E0F10;name=Mensaplan";<br />
StreamConnectionNotifier notifier =(StreamConnectionNotifier)Connector.open(url);<br />
StreamConnection client = notifier.acceptAndOpen();<br />
Bei erfolgreichem Aufbau einer Verbindung liefert acceptAndOpen() eine StreamConnection<br />
zurück. An dieser Stelle könnte ein weiterer Thread speziell für diese Verbindung eröffnet werden,<br />
damit <strong>der</strong> Server <strong>auf</strong> weitere Verbindungen warten kann. Da die Hardware <strong>der</strong> meisten mobilen<br />
Geräte jedoch typischerweise nicht mehr als eine gleichzeitige Bluetooth Verbindung beherrscht,<br />
wird die Kommunikation mit dem Client in dem selben Thread durchgeführt.<br />
Client<br />
Auf <strong>der</strong> Seite des Clients muss zur Herstellung einer Verbindung zunächst ein Gerät gefunden<br />
werden, welches den Mensaplan-Dienst anbietet. Zur Device und Service Discovery dient die Klasse<br />
DiscoveryAgent des <strong>Java</strong> Bluetooth APIs. Nach Initialisierung des Bluetooth Stacks kann über<br />
Discovery Agent.startInquiry() eine Gerätesuche gestartet werden.<br />
LocalDevice device = LocalDevice.getLocalDevice();<br />
DiscoveryAgent agent = device.getDiscoveryAgent();<br />
agent.startInquiry( DiscoveryAgent.GIAC, new DiscoveryListener() );<br />
Wurde ein Gerät gefunden wird die Methode deviceDiscovered() des Listeners <strong>auf</strong>gerufen. Ob<br />
das Gerät gewünschte Dienste anbietet, kann mittels <strong>der</strong> Methode DiscoveryAgent.searchServices()<br />
festgestellt werden. Dazu wird dieser eine Liste mit UUIDs zur Identifizierung <strong>der</strong> gewünschten<br />
Dienste übergeben – In diesem Fall die eine, für den Austausch <strong>der</strong> Mensapläne definierte, UUID.<br />
public void deviceDiscovered(RemoteDevice remoteDevice, DeviceClass deviceClass){<br />
UUID [] serviceUUIDs={ mensaplanUUID };<br />
agent.searchServices(attributeSet, serviceUUIDs,<br />
remoteDevice, new DiscoveryListener() );<br />
}
4.3 IMPLEMENTIERUNG 40<br />
Nach Beendigung <strong>der</strong> Abfrage wird die Methode servicesDiscovered() des Listeners <strong>auf</strong>gerufen.<br />
Dabei wird eine Liste mit ServiceRecords übergeben. Ein solcher Record enthält eine Reihe<br />
von Informationen zu dem gefundenen Dienst, insbeson<strong>der</strong>e eine URL, mit <strong>der</strong> eine Verbindung<br />
zu diesem Dienst <strong>auf</strong>gebaut werden kann. Da searchServices() hier nur eine UUID übergeben<br />
wurde, wird entwe<strong>der</strong> eine leere Liste, o<strong>der</strong> im Erfolgsfall genau ein Record zurückgeliefert.<br />
public void servicesDiscovered(int transId, ServiceRecord[] records){<br />
if(records.length==1) validRecords.addElement(records[0]);<br />
}<br />
Der Benutzer hat nach Abschluss von Device und Service Discovery die Möglichkeit, aus einer Liste<br />
den gewünschten Kommunikationspartner zu wählen. Dessen URL wird aus dem dazugehörigen<br />
ServiceRecord bezogen, anschließend kann über das Generic Connection Framework die Verbindung<br />
hergestellt werden.<br />
String url =service.getConnectionURL(ServiceRecord.NOAUTHENTICATE_NOENCRYPT,false);<br />
StreamConnection con = (StreamConnection) Connector.open( url );<br />
Kommunikation<br />
Für die Kommunikation werden DataOutput- bzw. DataInpustreams verwendet, über die einfache<br />
Datentypen und Strings versendet werden können. Dieses Verfahren eignet sich nicht für beliebige<br />
Daten – <strong>der</strong> Empfänger muss die Abfolge <strong>der</strong> Datentypen in seinem DataInputStream kennen, um die<br />
Daten korrekt zu interpretieren. Beispielsweise muss folgenden DataOutputStream zur Übertragung<br />
<strong>der</strong> Daten einer Woche, ein korrespondieren<strong>der</strong> DataInputStream <strong>auf</strong> <strong>der</strong> Empfängerseite entgegen<br />
nehmen.<br />
Sen<strong>der</strong>:<br />
DataOutputStream out = connection.openDataOutputStream();<br />
out.writeLong(week.getDate());<br />
for (int i=0;i
4.3 IMPLEMENTIERUNG 41<br />
Abbildung 4.5: Datenaustausch zwischen Server und Client via Bluetooth<br />
Der Austausch <strong>der</strong> Mensadaten erfolgt nach einem einfachen Protokoll, bei dem zunächst die Anfangstermine<br />
<strong>der</strong> vorhandenen Daten zwischen Client und Server ausgetauscht werden. An dieser<br />
Stelle wissen somit beide Teilnehmer, wessen Daten aktueller sind und damit auch über die Struktur<br />
des nun folgenden Datenaustauschs Bescheid. Wenn <strong>der</strong> Server über aktuellere Daten verfügt, sendet<br />
er sie im Anschluss an die Anfangstermine. Sind dagegen die Daten des Clients aktueller, sendet<br />
er diese, und <strong>der</strong> Server aktualisiert seine Daten. Am Ende des Austauschs verfügen somit beide<br />
Teilnehmer über identische Daten.<br />
4.3.4 Desktop-Relay<br />
Durch die Verwendung avetanaBluetooth Bibliothek konnte <strong>der</strong> Code <strong>der</strong> mobilen Anwendung nahezu<br />
unverän<strong>der</strong>t übernommen werden. Die Daten werden über das Internet vom Mensaplan-Server<br />
bezogen, und mit dem Parser <strong>der</strong> mobilen Anwendung verarbeitet. Anschließend wird <strong>der</strong> BT-Server<br />
gestartet; auch hier wird die entsprechende Klasse aus <strong>der</strong> mobilen Anwendung verwendet. Einziger<br />
Unterschied: Durch die Eingabe von ’x’ kann <strong>der</strong> Benutzer die Anwendung vorzeitig beenden.<br />
4.3.5 Mensaplan Webservice<br />
Zur Realisierung des Mensaplan Dienstes als Webservice wird das Framework Apache Axis verwendet.<br />
Dieses bietet neben einem <strong>auf</strong> Servlets basierenden Server für Webservices auch Werkzeuge, die<br />
eine einfache Transformation bestehen<strong>der</strong> Webanwendungen ermöglichen.<br />
Zunächst läßt sich mittels <strong>Java</strong>2WSDL aus einem Interface <strong>der</strong> gewünschten Dienste in Verbindung<br />
mit den dazugehörigen Datenhaltungsklassen eine WSDL-Datei generieren. Diese beinhaltet die Datenstrukturen<br />
und Schnittstellen <strong>der</strong> angebotenen Funktionen, sowie die verwendete Kodierung <strong>der</strong><br />
SOAP Nachrichten. Die für den mobilen Client verwendete Mirae-Bibliothek unterstützt zwar mehrere<br />
Kodierungen, das optionale WS-Paket für die J2ME allerdings ausschließlich das mittlerweile<br />
gebräuchlichste Document Literal Encoding. Aus Kompatibilitätsgründen wurde somit diese<br />
Kodierung gewählt. Der Overhead bei <strong>der</strong> Kommunikation mittels SOAP ist im Vergleich zur vorher<br />
verwendeten eigenen Kodierung zwar gestiegen, bleibt aber noch vertretbar.<br />
4.3 IMPLEMENTIERUNG 42<br />
4.3 IMPLEMENTIERUNG 43<br />
4.3.6 Mensaplan MIDlet mit Kommunikation via Webservice<br />
Das Mensaplan MIDlet wird mittels <strong>der</strong> Mirae-Bibliothek um die Fähigkeit <strong>der</strong> Nutzung von<br />
Webservices erweitert. Ein Werkzeug zur Generierung von Stub-Klassen und Methoden zur De-<br />
/Serialisierung <strong>der</strong> Daten anhand <strong>der</strong> WSDL-Beschreibung des Webservices ist Bestandteil des Mirae-Pakets.<br />
Die notwendigen Erweiterungen des Codes können also teilweise automatisch erstellt<br />
werden.<br />
Auch für die Kommunikation via Bluetooth werden XML-kodierte Daten verwendet, indem dieselben<br />
Methoden zur De-/Serialisierung <strong>der</strong> Daten wie beim Webservice genutzt werden. Zusätzlich<br />
wird die Verwendung des Object Exchange Protocols zum Datenaustausch nötig. Diese Funktionalität<br />
wird dem MIDlet über die AvetanaOBEX-Bibliothek hinzugefügt.<br />
Für diese Version des Mensaplan MIDlets werden somit die Klassen des Connection-Paketes angepasst,<br />
die Datenhaltungsklassen um die entsprechenden Methoden zur XML-Kodierung ergänzt<br />
und die beiden Bibliotheken eingebunden.<br />
4.3.6.1 Aufruf des Webservices<br />
Der Abruf <strong>der</strong> Daten per Webservice gestaltet sich recht transparent, die Kommunikation mit dem<br />
Server ist in <strong>der</strong> Klasse MensaDataStub gekapselt. Hier werden die jeweiligen SOAP-Aufrufe zusammengestellt<br />
und die eintreffenden Nachrichten mittels XML-Parser verarbeitet. Zu Beginn <strong>der</strong><br />
Kommunikation werden die Anfangstermine <strong>der</strong> Daten des Servers abgerufen, die eigentlichen Daten<br />
werden nur übertragen, wenn sie aktueller sind als die vorhandenen.<br />
MensaDataStub stub=new MensaDataStub(data.getURL());<br />
Dates checkDates=stub.getCurrentDate();<br />
if (checkDates.getThisWeek() > data.getThisWeek().getDate()){<br />
data.setThisWeek(stub.getThisWeek());<br />
}<br />
if (checkDates.getNextWeek()>data.getNextWeek().getDate()){<br />
data.setNextWeek(stub.getNextWeek());<br />
}<br />
Bei <strong>der</strong> Implementierung ergaben sich allerdings Probleme: Der Aufruf des Webservices funktionierte<br />
zunächst nicht. Letztlich waren diese <strong>auf</strong> kleinere Unstimmigkeiten bei <strong>der</strong> Behandlung<br />
von XML-Namespaces, zwischen dem serverseitigen Axis-Framework und dem Mirae-Stubgenerator<br />
zurückzuführen. Auch <strong>der</strong> Aufruf von Webservices an<strong>der</strong>er Anbieter aus dem Internet zu Testzwecken<br />
ergab ein ähnliches Bild, nur wenige funktionierten <strong>auf</strong> Anhieb. Der Abruf komplexerer<br />
Daten war immer mit einer Nachbearbeitung <strong>der</strong> automatisch generierten Stubs verbunden. Dies ist<br />
nicht unbedingt dem Stubgenerator des Mirae-Paketes anzulasten, eine komfortable Nutzung von<br />
Webservices ist wohl in den meisten Fällen nur möglich, wenn <strong>der</strong> Client mit demselben Framework<br />
erstellt wird, wie <strong>der</strong> Server. Eine problemlose plattform- und programmiersprachenunabhängige<br />
Kommunikation über Webservices bleibt zum heutigen Zeitpunkt lei<strong>der</strong> noch Fiktion.<br />
Der Stubgenerator im Wireless Toolkit 2.2, <strong>der</strong> Stubs für das optionale WS-Paket erstellen
4.3 IMPLEMENTIERUNG 44<br />
soll, ist in dieser Hinsicht noch eingeschränkter, da er nur Webservices akzeptiert, die im<br />
Document Literal Encoding angeboten werden. Auch wenn sich dieses Format mittlerweile<br />
durchzusetzen scheint, gibt es immer noch viele Webservices, die im ursprünglichen<br />
SOAP RPC Encoding angeboten werden [enc].<br />
4.3.6.2 OBEX-Verbindungen über Bluetooth<br />
Für die Kommunikation über Bluetooth wurde dieselbe XML-Kodierung für die Daten verwendet,<br />
wie bei <strong>der</strong> Übertragung per Webservice. Dies bot sich an, da die Methoden zu De-/Serialisierung<br />
<strong>der</strong> Daten schon vorhanden waren. Als Kommunikationsprotokoll wurde das Object Exchange<br />
Protocol gewählt, da es eine dem HTTP äquivalente Funktionalität bietet. Die bisher verwendete<br />
Übertragung per RFComm-Protokolls hätte wenig Sinn ergeben, da die De-/Enco<strong>der</strong>-Methoden in<br />
diesem Fall nicht direkt mit dem Output-/Inputstream <strong>der</strong> Verbindung arbeiten können.<br />
Server<br />
Der Bluetooth-Server stellt einen OBEX-Push Dienst für die Datenübertragung <strong>der</strong> XML-kodierten<br />
Mensapläne bereit. Für OBEX-Push Dienste ist die UUID 0x1105 definiert. Das Paket mit den<br />
OBEX-Klassen findet sich bei Benutzung <strong>der</strong> avetanaOBEX-Bibliothek nicht, wie man von <strong>der</strong> JSR-<br />
82 Spezifikation ableiten könnte, unter javax.obex.*, weil <strong>der</strong> Namensraum javax von keiner<br />
Anwendung für eigene Klassen benutzt werden darf. Aus diesem Grund läuft <strong>der</strong> Aufbau<br />
einer Verbindung auch nicht über das Generic Connection Framework ab, son<strong>der</strong>n über die Klasse<br />
de.avetana.obexsolo.OBEXConnector. Eine nachträgliche Integration neuer Verbindungstypen<br />
in das GFC ist lei<strong>der</strong> nur den Geräteherstellern möglich [Gme05].<br />
Unterschiede finden sich auch im weiteren Abl<strong>auf</strong>: Nach dem Connect eines Clients wird die folgende<br />
Kommunikation über einen Request-Handler abgewickelt, <strong>der</strong> hierfür entsprechende Methoden<br />
anbietet.<br />
notifier = (de.avetana.javax.obex.SessionNotifier)<br />
OBEXConnector.open("btgoep://localhost:0x1105");<br />
ServerRequestHandler srh=new RequestHandler(this);<br />
notifier.acceptAndOpen(srh);<br />
Die Methode onConnect() des Request-Handlers dient dem Initialisieren <strong>der</strong> Kommunikation,<br />
onGet() <strong>der</strong> Datenübertragung und onDisconnect() dem Abbau <strong>der</strong> Verbindung. Zur Bestimmung<br />
<strong>der</strong> zu liefernden Daten wird in onGet() das Feld Hea<strong>der</strong>Set.NAME des RequestHea<strong>der</strong>s<br />
ausgewertet.<br />
Je nach gefor<strong>der</strong>ten Daten werden <strong>der</strong> Methode zur Serialisierung aus <strong>der</strong> Mirae-Bibliothek<br />
(Enco<strong>der</strong>.serialize) die entsprechenden Parameter und <strong>der</strong> OutputStream übergeben.<br />
public int onGet(Operation op){<br />
Hea<strong>der</strong>Set hs = op.getReceivedHea<strong>der</strong>s();<br />
String type=(String)hs.getHea<strong>der</strong>(Hea<strong>der</strong>Set.NAME);<br />
OutputStream out=op.openOutputStream();
4.3 IMPLEMENTIERUNG 45<br />
if (type.equals("thisWeek.xml")){<br />
methodName = new javax.xml.namespace.QName(" urn:MensaData","getThisWeekReturn");<br />
paramName = new javax.xml.namespace.QName(" urn:MensaData","Week");<br />
inInfo[0]=new InputParameterInfo(data.getThisWeek(),"thisWeek",paramName);<br />
}<br />
...<br />
Enco<strong>der</strong>.serialize(methodName, inInfo, Constants.STYLE_DOCUMENT, out);<br />
}<br />
Client<br />
Die Device und Service Discovery des Clients wird mit <strong>der</strong> geän<strong>der</strong>ten UUID durchgeführt. Mit <strong>der</strong><br />
erhaltenen URL wird mittels OBEXConnector.open() eine ClientSession eröffnet. Über diese<br />
können die OBEX-Requests gestellt werden.<br />
Zunächst wird ein Hea<strong>der</strong>Set erstellt, dann die Kommunikation mit dem Server mittels<br />
connect() initialisiert. Ein Aufruf von get() liefert ein Operation-Objekt zurück, über das<br />
<strong>auf</strong> Hea<strong>der</strong> und InputStream <strong>der</strong> Antwort des Servers zugegriffen werden kann. Welche Daten<br />
beim get() jeweils abgerufen werden sollen wird dem Server über das Feld Hea<strong>der</strong>Set.NAME des<br />
Hea<strong>der</strong>s <strong>der</strong> OBEX-Nachrichten mitgeteilt. Die Dekodierung des erhaltenen Inputstreams erfolgt<br />
mithilfe <strong>der</strong> Mirae-Bibliothek.<br />
ClientSession cs=(ClientSession) OBEXConnector.open(url);<br />
Hea<strong>der</strong>Set hs=cs.createHea<strong>der</strong>Set();<br />
hs.setHea<strong>der</strong>(Hea<strong>der</strong>Set.TYPE, "text/xml");<br />
hs.setHea<strong>der</strong>(Hea<strong>der</strong>Set.NAME, Ïnitialize");<br />
Hea<strong>der</strong>Set serverResponse=cs.connect(hs);<br />
if (serverResponse.getResponseCode()==OBEX_HTTP_OK){<br />
hs.setHea<strong>der</strong>(Hea<strong>der</strong>Set.NAME, "dates.xml");<br />
Operation op=cs.get(hs);<br />
InputStream is=op.openInputStream();<br />
}<br />
Deco<strong>der</strong> deco<strong>der</strong>= new Deco<strong>der</strong>(new Dates(),Constants.TYPE_DOCLIT,"getCurrentDateReturn");<br />
deco<strong>der</strong>.decode(is);<br />
Dates serverDates=((Dates)deco<strong>der</strong>.getParam());<br />
is.close(); op.close();<br />
Dem Verbindungs<strong>auf</strong>bau folgt zunächst ein Abruf <strong>der</strong> Anfangstermine <strong>der</strong> beiden Wochen. Im Anschluss<br />
daran werden die Wochendaten bezogen, wenn diese aktueller als die vorhandenen des Clients<br />
sind.<br />
4.3.7 SyncML-Prototyp<br />
Zur Erläuterung <strong>der</strong> Funktionsweise des SyncML-Prototypen wird zunächst die verwendete interne<br />
Datenstruktur für die Adressbucheinträge beschrieben. Die eigentliche <strong>Synchronisation</strong> mit dem
4.3 IMPLEMENTIERUNG 46<br />
Abbildung 4.6: Sequenzdiagramm SycnML-Client<br />
Server erfolgt anhand eines speziellen, für jeden Eintrag vorhandenen Statusfeldes. Beim Start <strong>der</strong><br />
Anwendung muss zunächst ein Abgleich <strong>der</strong> Adressbucheinträge des Gerätes mit den innnerhalb<br />
<strong>der</strong> Anwendung gespeicherten Daten vorgenommen werden. Aufgetretene Verän<strong>der</strong>ungen müssen<br />
dabei registriert, und in die internen Daten <strong>der</strong> Anwendung übernommen werden. Dabei müssen<br />
auch die Statusfel<strong>der</strong> zur <strong>Synchronisation</strong> entsprechend gesetzt werden. Zur Bearbeitung <strong>der</strong> Daten<br />
innerhalb <strong>der</strong> Anwendung kommt eine entsprechende graphische Oberfläche hinzu. Den Abl<strong>auf</strong> <strong>der</strong><br />
nötigen Funktionen beschreibt das Sequenzdiagramm in Abbildung 4.6.<br />
4.3.7.1 Interne Datenstruktur<br />
Zentrales Element des SyncML-Prototypen sind die im Record Management System gespeicherten internen<br />
Daten. In einem Record sind jeweils die Daten eines einzelnen Kontaktes aus dem Adressbuch<br />
des Gerätes gespeichert. Ein solcher Record besteht aus drei Teilen: Zunächst ist einem jeden Kontakt<br />
eine systemweit gültige, eindeutige Nummer zur Identifizierung (UID) zugeordnet.<br />
Desweiteren wird <strong>der</strong> aktuelle <strong>Synchronisation</strong>sstatus gespeichert. ’N’ zeigt an, dass dieser Kontakt
4.3 IMPLEMENTIERUNG 47<br />
neu <strong>auf</strong> dem Gerät erstellt und noch nicht an den Server übermittelt wurde. Lokale Än<strong>der</strong>ungen an<br />
vormals mit dem Server synchronisierten Kontakten werden durch ein ’U’ als gesetztem Status festgehalten.<br />
Ein lokal gelöschter Kontakt, dessen Entfernung noch an den Server übermittelt werden<br />
muss, wird mit einem ’D’ markiert. Wenn keine lokalen Verän<strong>der</strong>ungen an einem Kontakt vorgenommen<br />
wurden, wird dies durch einen ungesetzen Status ’ ’ angezeigt.<br />
Im Anschluss an den Status folgen die eigentlichen Daten des Kontaktes, kodiert im zum Austausch<br />
von Adressbucheinträgen gängigen vCard-Format [vCa].<br />
Der Zugriff <strong>auf</strong> die Records des RMS erfolgt über die Methoden storeRecord(record) und<br />
deleteRecord(key) <strong>der</strong> Klasse syncclient.sps.DataStore. Ob ein zu speichern<strong>der</strong> Record<br />
neu hinzugefügt werden soll, o<strong>der</strong> eine Än<strong>der</strong>ung eines bestehenden Records darstellt, wird in<br />
storeRecord(record) ermittelt.<br />
4.3.7.2 Initialisierung<br />
Bei <strong>der</strong> Initialisierung <strong>der</strong> Anwendung werden alle Einträge <strong>der</strong> Adressdatenbank des Gerätes<br />
eingelesen und mit den intern gespeicherten Daten verglichen. Innerhalb <strong>der</strong> Methode<br />
storeRecord(record) des DataStore wird bei neuen Kontakten ein entsprechen<strong>der</strong> Record<br />
erstellt, bei modifizierten Kontakten werden die geän<strong>der</strong>ten Werte übernommen und <strong>der</strong> Status <strong>auf</strong><br />
’U’ gesetzt.<br />
Um festzustellen, ob Kontakte <strong>auf</strong> dem Gerät gelöscht wurden, wird die UID eines jeden eingelesenen<br />
Kontaktes temporär gespeichert. Nach Beendigung des Einlesens werden alle internen Records<br />
dar<strong>auf</strong>hin überprüft, ob ein entsprechen<strong>der</strong> Kontakt gerade eingelesen wurde. Ist dies nicht <strong>der</strong><br />
Fall, wurde <strong>der</strong> dazugehörige Kontakt <strong>auf</strong> dem Gerät gelöscht, und <strong>der</strong> Record wird mit einem ’D’<br />
markiert.<br />
ContactList myContacts = (ContactList) PIM.getInstance().openPIMList<br />
(PIM.CONTACT_LIST, PIM.READ_ONLY);<br />
pimEnumeration=myContacts.items();<br />
Hashtable importedRecords=new Hashtable();<br />
while (pimEnumeration.hasMoreElements()){<br />
contact = (Contact)pimEnumeration.nextElement();<br />
key=contact.getString(Contact.UID,0);<br />
record=new Record(key,’N’, pimStore.toSerialFormat(contact));<br />
dataStore.storeRecord(record);<br />
importedRecords.put(key,"true");<br />
}<br />
while (recordEnumeration.hasNextElement()) {<br />
record = new Record(recordEnumeration.nextRecord());<br />
if (importedRecords.get(record.getKey())==null)<br />
deleteRecord(record);<br />
}
4.3 IMPLEMENTIERUNG 48<br />
Abbildung 4.7: Graphische Oberfläche des SyncML-Clients<br />
4.3.7.3 Bearbeiten von Kontakten<br />
Der Benutzer kann im Rahmen <strong>der</strong> Anwendung neue Kontakte hinzufügen und bestehende<br />
verän<strong>der</strong>n o<strong>der</strong> löschen. Hierzu wurde eine aus zwei Teilen bestehende graphische Oberfläche<br />
implementiert (siehe Abbildung 4.7). Die Klasse syncclient.pim.DataList erzeugt eine<br />
Liste aller vorhandenen Kontakte, die gelöscht o<strong>der</strong> ausgewählt werden können. Die Klasse<br />
syncclient.pim.ContactForm erstellt ein Formular, mittels dessen Kontakte modifiziert, o<strong>der</strong><br />
neu angelegt werden können.<br />
In <strong>der</strong> Spezifikation zur PIM-API finden sich keine Datenfel<strong>der</strong>, die verpflichtend implementiert<br />
werden müssen. Vor Benutzung eines Feldes muss immer überprüft werden, ob es von <strong>der</strong> jeweiligen<br />
Implementierung unterstützt wird. Diese Überprüfung findet hier im Konstruktor <strong>der</strong> Klasse<br />
syncclient.pim.PIMStore statt, in <strong>der</strong> sich alle Methoden zum Zugriff <strong>auf</strong> die Adressdatenbank<br />
des Gerätes finden. Die getestete Implementation <strong>der</strong> PIM-API <strong>auf</strong> dem Palm ermöglicht lei<strong>der</strong><br />
nur den Zugriff <strong>auf</strong> sehr wenige Fel<strong>der</strong> <strong>der</strong> Datenbank.<br />
ContactList myContacts = (ContactList) PIM.getInstance().openPIMList<br />
(PIM.CONTACT_LIST, PIM.READ_ONLY);<br />
int sup_NameSize=myContacts.stringArraySize(Contact.NAME);<br />
boolean sup_NameFamily=myContacts.isSupportedArrayElement<br />
(Contact.NAME, Contact.NAME_FAMILY);<br />
boolean sup_NameGiven=myContacts.isSupportedArrayElement<br />
(Contact.NAME, Contact.NAME_GIVEN);<br />
boolean sup_TelNR=myContacts.isSupportedField(Contact.TEL);<br />
boolean sup_Home=myContacts.isSupportedAttribute(Contact.TEL,Contact.ATTR_HOME);
4.3 IMPLEMENTIERUNG 49<br />
Je nachdem, welche Datenfel<strong>der</strong> unterstützt werden, blendet ContactForm entsprechende Texteingabefel<strong>der</strong><br />
ein. Wenn <strong>der</strong> Benutzer die Än<strong>der</strong>ungen abspeichern möchte, wird zunächst <strong>der</strong> Kontakt<br />
<strong>der</strong> Adressdatenbank des Gerätes geän<strong>der</strong>t, anschließend <strong>der</strong> Record im RMS.<br />
Contact workContact=myContacts.createContact();<br />
String[]name=new String[pim.sup_NameSize];<br />
name[Contact.NAME_GIVEN]=nameGiven.getString();<br />
name[Contact.NAME_FAMILY]=nameFamily.getString();<br />
workContact.addStringArray(Contact.NAME, Contact.ATTR_NONE, name);<br />
workContact.addString(Contact.TEL, Contact.ATTR_HOME, tel.getString());<br />
Record modRecord=pimStore.modifyPIMContact(UID,workContact);<br />
modRecord.setState(’U’);<br />
dataStore.storeRecord(modRecord);<br />
Beim Löschen von Kontakten können zwei Fälle unterschieden werden: Im Normalfall wird nur <strong>der</strong><br />
Kontakt <strong>auf</strong> dem Gerät gelöscht und <strong>der</strong> Record im RMS mit dem Status ’D’ versehen. Sollte <strong>der</strong><br />
zu löschende Kontakt aber noch nicht mit dem Server synchronisiert worden sein (Status ’N’) kann<br />
auch <strong>der</strong> Record sofort gelöscht werden.<br />
4.3.7.4 <strong>Synchronisation</strong><br />
Wird vom Benutzer die <strong>Synchronisation</strong> gewünscht, muss zunächt eine Instanz <strong>der</strong> Klasse<br />
syncclient.spds.SyncManagerImpl erzeugt werden. Dabei wird <strong>der</strong> im RMS gespeicherte<br />
Zeitstempel <strong>der</strong> letzten <strong>Synchronisation</strong> abgerufen und zugleich ein Neuer angelegt, <strong>der</strong> am Ende<br />
einer erfolgreichen <strong>Synchronisation</strong> wie<strong>der</strong> ins RMS geschrieben werden kann. Als Erstes wird jetzt<br />
eine Initialization-Nachricht zusammengestellt. Aus Gründen <strong>der</strong> Effizienz werden die zu sendenden<br />
Nachrichten zu einem großen Teil aus Textbausteinen zusammengefügt. Zum Parsen <strong>der</strong> XMLkodierten<br />
Antworten findet ein sogenannter Pull-Parser Verwendung, <strong>der</strong> relativ wenig Ressourcen<br />
benötigt.<br />
Als Antwort sendet <strong>der</strong> Server in seiner Initialization-Nachricht die Art <strong>der</strong> durchzuführenden Datensynchronisation<br />
o<strong>der</strong> eine Fehlermeldung. Wenn zuvor noch keine <strong>Synchronisation</strong> zwischen<br />
Client und Server stattgefunden hat, muss ein Slow-Sync durchgeführt werden. Dabei muss <strong>der</strong><br />
Client sämtliche Daten an den Server senden, mit Ausnahme <strong>der</strong> mit ’D’ markierten. Die Methode<br />
filterRecordsForSlowSync() <strong>der</strong> Klasse DataStore liefert die entsprechenden Records<br />
zurück. Wenn zuvor schon eine erfolgreiche <strong>Synchronisation</strong> zwischen Server und Client erfolgt ist,<br />
reicht ein sogenannter Fast-Sync. Dabei werden nur jene Daten zum Server übertragen, die sich seit<br />
<strong>der</strong> letzten <strong>Synchronisation</strong> geän<strong>der</strong>t haben.<br />
Nachdem <strong>der</strong> Client diese Modification-Nachricht zusammengestellt und an den Server gesendet hat,<br />
antwortet dieser ebenfalls mit einer solchen Nachricht. Sie enthält alle neuen o<strong>der</strong> geän<strong>der</strong>ten Kontakte<br />
im vCard-Format sowie die UIDs <strong>der</strong> zu löschenden. Die Än<strong>der</strong>ungen werden zunächst in <strong>der</strong><br />
Adressdatenbank des Gerätes vorgenommen, anschließend ins RMS übernommen. Beispielsweise<br />
wird das Hinzufügen eines neuen Kontaktes folgen<strong>der</strong>maßen realisiert:
4.3 IMPLEMENTIERUNG 50<br />
String key<br />
= getXMLTagValue((String) addTags.elementAt(i), TAG_LOC_URI);<br />
String content = getXMLTagValue((String) addTags.elementAt(i), TAG_DATA);<br />
Record record = new Record(key, ’ ’, content);<br />
record=pimStore.addPIMContact(record);<br />
dataStore.storeRecord(record);<br />
mappings.put(record.getKey(), key);<br />
In einem Hashtable werden die UIDs von neu hinzugefügten Kontakten gespeichert. Viele <strong>Anwendungen</strong><br />
übernehmen nicht die vom Server kommende globale UID (kurz GUID) son<strong>der</strong>n vergeben<br />
beim Speichern eine eigene, lokale UID (LUID). Die PIM-API erlaubt es ebenfalls nicht, eine UID<br />
vorzugeben, son<strong>der</strong>n legt beim Speichern eine eigene fest. Aus diesem Grund muss eine Abbildung<br />
von <strong>der</strong> globalen <strong>auf</strong> die lokale UID vorgenommen werden. Laut SyncML-Spezifikationen sollte <strong>der</strong><br />
Server diese Arbeit übernehmen, die Abbildungen werden somit vom Client beim Abspeichern gesammelt,<br />
und in einer abschließenden Mapping-Nachricht an den Server gesandt.<br />
Lei<strong>der</strong> funktionierte dies beim verwendeten Sync4j-Server nicht einwandfrei. Hin und wie<strong>der</strong> schien<br />
<strong>der</strong> Server das aktuelle Mapping zu vergessen“ und es kam dar<strong>auf</strong>hin zu duplizierten Datensätzen.<br />
”<br />
Um diese Fehler zu umgehen übernimmt <strong>der</strong> Client selbst die Abbildung von LUID <strong>auf</strong> GUID und<br />
zwar direkt beim Auslesen <strong>der</strong> Kontakte aus <strong>der</strong> Adressdatenbank. In den Records im RMS und für<br />
die Kommunikation mit dem Server wird durchgängig die GUID verwendet. Das Mapping wurde in<br />
<strong>der</strong> Klasse syncclient.pim.UIDMap implementiert, welche die Abbildungen persistent im RMS<br />
ablegt. Bei <strong>der</strong> Initialisierung <strong>der</strong> Anwendung werden die Daten aus dem RMS ausgelesen und für<br />
einen schnellen Zugriff in einem Hashtable gespeichert.<br />
Nach Abschluss <strong>der</strong> Kommunikation mit dem Server werden vom SyncManager noch sämtliche<br />
Records mit dem Status ’ ’ versehen und <strong>der</strong> neue Zeitstempel im RMS abgelegt – die Datensätze<br />
sind jetzt synchronisiert.<br />
4.3.7.5 Zugriff <strong>auf</strong> die PIM-Datenbank<br />
Sämtliche Methoden für den Zugriff <strong>auf</strong> die Adressdatenbank des Gerätes finden sich in <strong>der</strong> Klasse<br />
syncclient.pim.PIMStore. Details zu den einzelnen Methoden werden im Folgenden erläutert.<br />
Dabei werden insbeson<strong>der</strong>e die Probleme mit <strong>der</strong> Implementation <strong>der</strong> PIM-API, <strong>auf</strong> dem zu Testzwecken<br />
verwendeten Palm dokumentiert.<br />
Import und Export von Adressdaten<br />
Die PIM-API beinhaltet statische Methoden zum Import und Export von Adressdaten aus dem<br />
vCard-Format. Welche Formate von <strong>der</strong> jeweiligen Implementation unterstützt werden, lässt sich mit<br />
PIM.getInstance().supportedSerialFormats(PIM.CONTACT_LIST) abfragen. Zum Imund<br />
Export eines Kontaktes dienen folgende Methoden:<br />
PIM.getInstance().toSerialFormat(contact,outputstream,encoding,format)<br />
PIM.getInstance().fromSerialFormat(inputstream, encoding)<br />
Die Spezifikation sieht vor, dass von <strong>der</strong> jeweiligen Implementation nicht unterstützte Fel<strong>der</strong>
4.3 IMPLEMENTIERUNG 51<br />
beim Import ignoriert werden. Ein Contact-Objekt soll aber in jedem Fall erzeugt werden.<br />
Die Implementation <strong>der</strong> PIM-API <strong>auf</strong> dem Palm tat dies allerdings nicht: Wenn bestimmte Fel<strong>der</strong><br />
<strong>der</strong> zu importierenden vCard gesetzt werden, wird <strong>der</strong> Import mit NullPointer- o<strong>der</strong><br />
ArrayIndexOutOfBounds-Exceptions beendet, obwohl die vCards keine syntaktischen Fehler<br />
<strong>auf</strong>wiesen.<br />
Behelfsmäßig wurde bei den Tests des Prototypen dar<strong>auf</strong> geachtet, dass die vom Server übermittelten<br />
vCards diese Einträge nicht enthalten – eine annehmbare Lösung stellt dies jedoch nicht dar. Eine<br />
Anwendung, die beliebige Adressdaten im vCard importieren soll, müsste demnach einen eigenen<br />
Parser für diese Zwecke implementieren.<br />
Zugriff <strong>auf</strong> einzelne Adressen des Gerätes<br />
Um <strong>auf</strong> Einträge <strong>der</strong> Adressdatenbank des Gerätes zuzugreifen, bietet das PIM-API Methoden, mit<br />
denen die Datenbank nach bestimmten Kriterien durchsucht werden kann. Am sinnvollsten eignet<br />
sich die UID eines bestimmten Eintrages zu dessen Identifizierung. Lei<strong>der</strong> lieferte die Implementation<br />
<strong>der</strong> PIM-API <strong>auf</strong> dem Palm keine Ergebnisse, wenn nach <strong>der</strong> UID gesucht wurde, obwohl die<br />
Spezifikation diese Möglichkeit ausdrücklich vorsieht. Aus diesem Grund wurde für den Prototypen<br />
die Suche selbst implementiert: Je<strong>der</strong> Eintrag <strong>der</strong> Datenbank muss dabei ausgelesen und <strong>auf</strong> seine<br />
UID überprüft werden.<br />
Alle Zugriffe <strong>auf</strong> einzelne Adressen werden über die Methode PIMStore.retrievePIMContact<br />
durchgeführt, <strong>der</strong> die UID des gewünschten Kontaktes übergeben wird. Eventuell muss innerhalb<br />
dieser Methode eine Abbildung von <strong>der</strong> globalen <strong>auf</strong> die lokale UID vorgenommen werden (Siehe<br />
Kapitel 4.3.7.4).<br />
String pimUID=mapping.getPimUID(GUID);<br />
if (pimUID!=null)GUID=pimUID;<br />
myContacts=(ContactList) PIM.getInstance().openPIMList(PIM.CONTACT_LIST, PIM.READ_ONLY);<br />
Enumeration pimEnumeration = myContacts.items();<br />
Contact searchContact=null;<br />
while (pimEnumeration.hasMoreElements()){<br />
searchContact=(Contact)pimEnumeration.nextElement();<br />
if (searchContact.getString(Contact.UID,0).equals(GUID))<br />
return searchContact;<br />
}<br />
Hinzufügen neuer Adressen<br />
Neue Adressen können vom Benutzer innerhalb <strong>der</strong> Anwendung erstellt, o<strong>der</strong> im Zuge <strong>der</strong> <strong>Synchronisation</strong><br />
vom Server übermittelt werden. In letzterem Fall muss eine Abbildung von <strong>der</strong> globalen <strong>auf</strong><br />
die lokale UID gespeichert werden. Die lokale UID ergibt sich, nachdem ein Kontakt in <strong>der</strong> Adressdatenbank<br />
abgelegt wurde (commit()).<br />
myContacts =(ContactList) PIM.getInstance().openPIMList(PIM.CONTACT_LIST,PIM.READ_WRITE);<br />
Contact contact2add=myContacts.importContact(fromSerialFormat(record2add.getContent()));<br />
contact2add.commit();
4.3 IMPLEMENTIERUNG 52<br />
String globalUID = record2add.getKey();<br />
String localUID = contact2add.getString(Contact.UID,0);<br />
mapping.addMapping(globalUID,localUID);<br />
Modifizieren bestehen<strong>der</strong> Adressen<br />
Die Modifikation bestehen<strong>der</strong> Adressen gestaltet sich etwas komplizierter. Ein Eintrag in <strong>der</strong> Adressdatenbank<br />
kann nicht komplett überschrieben werden, daher müssen die vom Server erhaltenen<br />
neuen Werte in sämtliche Fel<strong>der</strong> des Eintrages übernommen werden. Es gibt unterschiedliche<br />
Arten von Fel<strong>der</strong>n, beispielsweise wird <strong>auf</strong> Namen und Adresse eines Eintrages mittels eines<br />
StringArrays zugegriffen, während Telefonummern o<strong>der</strong> Emailadressen als Zeichenketten<br />
gespeichert sind. Zu jedem Eintrag ist zusätzlich die Vergabe von speziellen Attributen möglich,<br />
zum Beispiel bei Telefonnummern ATTR.HOME, ATTR.MOBILE, ATTR.PREFERED etc. Einige Fel<strong>der</strong><br />
können zudem mehrfach vorkommen, beispielsweise mehrere Telefonnummern o<strong>der</strong> eine Adresse<br />
mit HOME, und eine mit WORK als Attribut. Der Codeausschnitt zeigt die Übernahme von Fel<strong>der</strong>n, die<br />
Zeichenketten speichern.<br />
Zudem sollte vor dem Zugriff <strong>auf</strong> ein jedes Feld überprüft werden, ob die jeweilige Implementation<br />
<strong>der</strong> PIM-API dieses Feld auch unterstützt. Da vom Server kommende Modifikationen<br />
zunächst mittels fromSerialFormat() deserialisiert werden, kann diese Überprüfung entfallen:<br />
Laut Spezifikation sollte diese Methode <strong>der</strong> PIM-API nur die Fel<strong>der</strong> übernehmen, die<br />
<strong>auf</strong> <strong>der</strong> jeweiligen Plattform unterstützt werden und die restlichen einfach ignorieren. Mittels<br />
modifiedContact.getFields() kann dann <strong>auf</strong> die Fel<strong>der</strong> des importierten Contacts zugegriffen<br />
werden, die auch alle unterstützt werden.<br />
oldContact=retrievePIMContact(UID);<br />
int [] modFields=modifiedContact.getFields();<br />
for (int i=0;i
4.3 IMPLEMENTIERUNG 53<br />
Löschen von Adressen<br />
Der zu löschende Adressbucheintrag wird in <strong>der</strong> Datenbank lokalisiert, und kann dann entfernt<br />
werden. Eventuell muss zusätzlich eine vorhandene Abbildung <strong>der</strong> UID gelöscht werden.<br />
Contact contact2delete=retrievePIMContact(UID);<br />
myContacts =(ContactList) PIM.getInstance().openPIMList(PIM.CONTACT_LIST,PIM.READ_WRITE);<br />
if(contact2delete!=null){<br />
mapping.removeMapping(contact2delete.getString(Contact.UID,0));<br />
myContacts.removeContact(contact2delete);<br />
}<br />
4.3.7.6 Kompatibilität mit an<strong>der</strong>en SyncML-Lösungen<br />
Ein wesentlicher Vorteil von SycnML ist die Möglichkeit, Daten zwischen <strong>Anwendungen</strong> unterschiedlicher<br />
Anbieter zu sychronisieren. Zu Testzwecken wurde eine <strong>Synchronisation</strong> zwischen dem<br />
SyncML-Prototypen und dem Multisync-Server versucht. Lei<strong>der</strong> blieben diese Versuche ohne Erfolg,<br />
die Kommunikation ging über die Initialisierungsphase nicht hinaus. Der genaue Fehler ließ sich<br />
nicht lokalisieren, wird aber <strong>auf</strong> <strong>der</strong> Seite des Servers vermutet.<br />
Multisync wird zur Zeit vollständig überarbeitet und neu strukturiert, <strong>der</strong> Fokus <strong>der</strong> Entwicklung<br />
liegt dabei insbeson<strong>der</strong>e <strong>auf</strong> dem SyncML-Teil. Dieser soll in eine eigene Bibliothek ausgelagert<br />
werden, damit auch an<strong>der</strong>e <strong>Anwendungen</strong> unter Linux die Funktionalität von SyncML zur Datensynchronisation<br />
nutzen können. Zusätzlich soll neben HTTP auch OBEX als Transportprotokoll genutzt<br />
werden. Die Entwickler von Multisync haben <strong>auf</strong>grund dieser umfangreichen Än<strong>der</strong>ungen<br />
seit einigen Monaten keine neue Version mehr freigegeben. Die Versuche mussten daher mit einer<br />
älteren Version durchgeführt werden, <strong>der</strong>en SyncML-Implementation als experimentell gekennzeichnet<br />
war.<br />
Die Zukunft des Multisync-Projekts kann jedoch positiv eingeschätzt werden. Dafür spricht eine rege<br />
Beteiligung von Entwicklern, die sich schon längere Zeit mit <strong>der</strong> Datensynchronisation beschäftigen.<br />
Eine standardisierte Bibliothek würde sicherlich zu einer steigenden Verbreitung von SyncMLfähigen<br />
<strong>Anwendungen</strong> unter Linux führen.
Kapitel 5<br />
Resümee<br />
Durch die Evaluation konnte ein guter Einblick in die Möglichkeiten und Probleme bei <strong>der</strong> <strong>Synchronisation</strong><br />
<strong>mobiler</strong> <strong>Anwendungen</strong> <strong>auf</strong> <strong>Basis</strong> <strong>der</strong> J2ME gewonnen werden. Bei <strong>der</strong> abschließenden Beurteilung<br />
sollen neben den technischen Ursachen <strong>der</strong> <strong>auf</strong>getretenen Probleme auch weitere Faktoren<br />
benannt werden, die den Einsatz <strong>der</strong> J2ME für die Entwicklung <strong>mobiler</strong> <strong>Anwendungen</strong> in Frage stellen.<br />
Ein Ausblick <strong>auf</strong> zukünftige Entwicklungen im Bereich <strong>der</strong> J2ME soll zeigen, welche Lösungen<br />
für die hier dokumentierten Probleme in Zukunft zu erwarten sind. Eine wichtige Rolle spielt in<br />
diesem Zusammenhang die weitere Verbreitung <strong>der</strong> Plattform, denn nur wenn neue Entwicklungen<br />
auch <strong>auf</strong> einer ausreichenden Zahl an Geräten unterstützt werden, wird die Anwendungsentwicklung<br />
<strong>auf</strong> <strong>Basis</strong> <strong>der</strong> J2ME sinnvoll.<br />
5.1 Beurteilung <strong>der</strong> Anwendungsentwicklung <strong>auf</strong> <strong>Basis</strong> <strong>der</strong> CLDC<br />
Die Evaluation <strong>der</strong> betrachteten Verfahren zur Datensynchronisation brachte viele Schwierigkeiten<br />
bei <strong>der</strong> Entwicklung entsprechen<strong>der</strong> <strong>mobiler</strong> <strong>Anwendungen</strong> <strong>auf</strong> <strong>Basis</strong> <strong>der</strong> CLDC zu Tage. Die<br />
Gründe dafür sind unterschiedlich: Einige Probleme sind klar <strong>der</strong> geringen Leistungsfähigkeit <strong>der</strong><br />
betreffenden Geräte geschuldet, an<strong>der</strong>e haben ihren Ursprung in relativ offen gehaltenen Spezifikationen<br />
einzelner Pakete. Darüber hinaus sind gewisse Restriktionen <strong>der</strong> Plattform von den Herstellern<br />
durchaus beabsichtigt; Schwierigkeiten, die hieraus resultieren, sind für den Entwickler umso<br />
ärgerlicher.<br />
Im Folgenden sollen die bei <strong>der</strong> Evaluation <strong>auf</strong>getretenen Probleme im Kontext <strong>der</strong> Gesamtentwicklung<br />
<strong>der</strong> CLDC-Plattfom betrachtet werden. Die Problematik <strong>der</strong> drohenden Fragmentation<br />
<strong>der</strong> Plattform wird dabei einer geson<strong>der</strong>ten Betrachtung unterzogen. Dem gegenübergestellt werden<br />
zunächst die positiven Aspekte bei <strong>der</strong> Entwicklung CLDC-basierter <strong>Anwendungen</strong>.<br />
5.1.1 Vorteile <strong>der</strong> Entwicklung <strong>auf</strong> <strong>Basis</strong> <strong>der</strong> CLDC<br />
Eine L<strong>auf</strong>zeitumgebung für <strong>Anwendungen</strong> <strong>auf</strong> <strong>Basis</strong> <strong>der</strong> CLDC findet sich zum heutigen Zeitpunkt<br />
<strong>auf</strong> sehr vielen mobilen Geräten. Kaum ein Mobiltelefon o<strong>der</strong> Smartphone wird mehr ohne eine vir-
5.1 BEURTEILUNG DER ANWENDUNGSENTWICKLUNG AUF BASIS DER CLDC 55<br />
tuelle Maschine für die CLDC ausgeliefert. Damit existiert ein lukrativer Markt für <strong>Anwendungen</strong> <strong>auf</strong><br />
dieser Plattform.<br />
Die J2ME ermöglicht eine plattformunabhängige Entwicklung <strong>auf</strong> einer Vielzahl unterschiedlicher<br />
Geräte: Das MIDP in Version 2.0 ist weit verbreitet, bietet eine relativ umfangreiche Funktionalität<br />
und die jeweiligen Implementationen <strong>der</strong> Gerätehersteller entsprechen ausreichend genau den Spezifikationen.<br />
Die Verheißungen des Slogans ”´Write once, run anywhere“ könnten realisiert werden –<br />
solange die Funktionalität des MIDP 2.0 für die Entwicklung ausreicht. Sobald eine Anwendung jedoch<br />
<strong>auf</strong> optionale Pakete angewiesen ist, reduziert sich die Anzahl <strong>der</strong> verwendbaren Geräte lei<strong>der</strong><br />
drastisch.<br />
Sehr angenehm ist <strong>der</strong> Umstieg <strong>auf</strong> die J2ME-Plattform für Entwickler mit Erfahrung im Umgang<br />
mit <strong>der</strong> <strong>Java</strong> Standard Edition. Die Unterschiede des Sprachumfangs und <strong>der</strong> API halten sich in Grenzen,<br />
für gängige Entwicklungsumgebungen ist eine Unterstützung <strong>der</strong> J2ME erhältlich, o<strong>der</strong> bereits<br />
integriert. Einige Details sind <strong>auf</strong> <strong>der</strong> J2ME-Plattform sogar vorteilhafter gelöst, als bei <strong>der</strong> Standard<br />
Edition: Beispielsweise ermöglicht <strong>der</strong> Aufbau des Generic Connection Frameworks eine einheitliche<br />
und komfortable Verwendung unterschiedlichster Arten von Netzverbindungen.<br />
Positiv hervorzuheben ist auch die Bluetooth-API. Die meisten Geräte mit Bluetooth-Technik implementieren<br />
diese Schnittstelle und erlauben so J2ME-<strong>Anwendungen</strong> die Kommunikation via Bluetooth.<br />
In <strong>der</strong> <strong>Java</strong> Standard Edition findet sich nichts Vergleichbares. Einziges Manko in diesem Zusammenhang<br />
bleibt die uneinheitliche Unterstützung des OBEX-Protokolls. Da dieses in <strong>der</strong> Spezifikation<br />
<strong>der</strong> Bluetooth-API als optional vorgesehen ist, unterstützen lei<strong>der</strong> nur sehr wenige Geräte das<br />
OBEX-Protokoll. Dieser Mangel lässt sich zwar durch die Integration einer zusätzlichen Bibliothek<br />
in die Anwendung beheben – durch eine verpflichtende Unterstützung des OBEX-Protokolls wäre<br />
die Bluetooth-API aber um einiges universeller einsetzbar geworden, da eine Reihe von Protokollen<br />
<strong>der</strong> Anwendungsschicht OBEX als Transportprotokoll für Bluetooth-Verbindungen nutzen.<br />
5.1.2 Probleme <strong>auf</strong>grund <strong>der</strong> geringen Leistungsfähigkeit <strong>der</strong> Geräte<br />
Mit Problemen, die <strong>der</strong> geringen Leistungsfähigkeit <strong>der</strong> mobilen Geräte geschuldet sind, wurde im<br />
Vorfeld <strong>der</strong> Evaluation gerechnet. Im Wesentlichen beschränkte sich dieses Problemfeld <strong>auf</strong> die Restriktion<br />
<strong>der</strong> maximal möglichen Größe einer Anwendung von 64 Kilobyte. Komplexere <strong>Anwendungen</strong><br />
stoßen schnell an dieses Limit, insbeson<strong>der</strong>e wenn zusätzliche Bibliotheken mit integriert werden<br />
müssen. Im Rahmen <strong>der</strong> Evaluation ergaben sich für den Umfang <strong>der</strong> einzelnen <strong>Anwendungen</strong><br />
folgende Werte:<br />
Die Größe <strong>der</strong> ersten Version <strong>der</strong> Mensaplan-Anwendung beträgt rund 19 Kilobyte – ohne die Klassen<br />
<strong>der</strong> Bluetooth-Verbindung wären es noch 8 Kilobyte weniger. Es bleibt ein großer Spielraum<br />
für zusätzliche Features, denkbar wäre beispielsweise eine personalisierte Darstellung, o<strong>der</strong> die<br />
Übernahme von Mensadaten in den Terminkalen<strong>der</strong> des Gerätes.<br />
Bei <strong>der</strong> zweiten Version <strong>der</strong> Mensaplan-Anwendung wurde zur Nutzung des Webservices eine entsprechende<br />
Bibliothek integriert. Diese hat einen Umfang von ca. 22 Kilobyte, vor allem wegen des<br />
nötigen XML-Parsers. Zusammen mit den zusätzlichen Methoden zur De-/Serialisierung <strong>der</strong> Daten<br />
in XML, wächst die Größe <strong>der</strong> Anwendung <strong>auf</strong> 45 Kilobyte. Bei etwas komplexeren <strong>Anwendungen</strong>
5.1 BEURTEILUNG DER ANWENDUNGSENTWICKLUNG AUF BASIS DER CLDC 56<br />
dürfte bei einer Integration dieser Webservice-Bibliothek die Grenze von 64 Kilobyte schnell erreicht<br />
sein. Hier gilt es abzuwägen, ob die Verwendung des optionalen Webservice-Paketes nicht vorteilhafter<br />
ist, auch wenn dadurch die Zahl <strong>der</strong> unterstützten Geräte drastisch sinkt.<br />
Um auch über die Bluetooth-Verbindung XML-kodierte Daten zu übertragen, wurde OBEX als Transportprotokoll<br />
verwendet. Die mangelnde Unterstützung des OBEX-Protokoll durch die Bluetooth-<br />
API macht hierfür den Einsatz einer Bibliothek nötig. Diese hat eine Größe von 10 Kilobyte, zusammen<br />
mit den für die Kommunikation via Bluetooth ohnehin nötigen Methoden stieg <strong>der</strong> Umfang <strong>der</strong><br />
gesamten Anwendung <strong>auf</strong> 63 Kilobyte. Der Einsatz von OBEX in J2ME-<strong>Anwendungen</strong> ergibt somit<br />
lei<strong>der</strong> nur in speziellen Fällen Sinn.<br />
Aus diesem Grund wurde auch beim SyncML-Prototypen dar<strong>auf</strong> verzichtet, die <strong>Synchronisation</strong><br />
via Bluetooth zu erproben. Diese Anwendung weist ohnehin schon eine Größe von 41 Kilobyte <strong>auf</strong>,<br />
hauptsächlich bedingt durch die Verwendung des XML-basierten SyncML. Die Anwendung wurde<br />
nur als Prototyp implementiert, daher ließe sich durch eine Optimierung des Programmcodes sicherlich<br />
noch etwas Speicherplatz einsparen. Es bleibt dennoch fraglich, ob dann die OBEX-Bibliothek<br />
erfolgreich genutzt werden könnte .<br />
Das Größenlimit von 64 Kilobyte stellt also ein ernsthaftes Problem bei <strong>der</strong> Entwicklung von <strong>Anwendungen</strong><br />
zur Datensynchronisation dar. Eine mögliche Lösung wäre es, optionale Pakete vorauszusetzen.<br />
Das Webservice-API würde nicht nur den Einsatz einer zusätzlichen Bibliothek zur Nutzung<br />
von Webservices überflüssig machen – <strong>der</strong> integrierte XML-Parser könnte auch die Größe <strong>der</strong><br />
SyncML-Anwendung entscheidend verringern.<br />
Diese Lösung ist jedoch im Bezug <strong>auf</strong> das OBEX-Protokoll nicht möglich: Das Bluetooth-API ist ohnehin<br />
ein optionales Paket, und OBEX ist darin als optionale Komponente spezifiziert. Dies führt<br />
dazu, dass nur <strong>auf</strong> einem sehr kleinen Teil <strong>der</strong> Geräte mit Bluetooth-API auch das OBEX-Protokoll<br />
zur Verfügung steht.<br />
Eventuell wird es dem Benutzer in Zukunft möglich sein, zusätzliche Bibliotheken, unabhängig von<br />
<strong>der</strong> Anwendung, <strong>auf</strong> dem Gerät zu installieren. Zumindest in den Vorschlägen zur nächsten Spezifikation<br />
des MIDPs in Version 3 [JSRb] finden sich auch solche shared libraries. Erfor<strong>der</strong>lich wäre dazu<br />
allerdings eine erhebliche Öffnung <strong>der</strong> bislang sehr restriktiven J2ME-Plattform.<br />
Die naheliegendste Lösung des Problems besteht in einer einfachen Erhöhung des Größenlimits<br />
<strong>der</strong> <strong>Anwendungen</strong>, ermöglicht durch die steigende Leistungsfähigkeit <strong>der</strong> Geräte. Einige Hersteller<br />
erlauben schon heute die Installation umfangreicherer <strong>Anwendungen</strong>; spezifiziert wird diese<br />
Än<strong>der</strong>ung aber wohl erst in <strong>der</strong> nächsten Version des MIDP.<br />
Weitere Probleme im Zusammenhang mit <strong>der</strong> geringen Leistungsfähigkeit <strong>der</strong> Geräte konnten erfreulicherweise<br />
nicht festgestellt werden. Selbst die Erprobung des SyncML-Prototypen, bei dessen<br />
Entwicklung nur am Rande <strong>auf</strong> Perfomanz Wert gelegt wurde, ergab keine weiteren Schwierigkeiten.<br />
Bei Initialisierung und <strong>Synchronisation</strong> dieser Anwendung werden relativ viele Daten verarbeitet,<br />
<strong>auf</strong> dem Emulator zeigt sich dabei ein starker Anstieg des Speicherverbrauchs. Auf dem Gerät<br />
ist dies nicht spürbar, die Garbage Collection <strong>der</strong> KVM scheint recht effizient zu arbeiten. Bei an<strong>der</strong>en<br />
Anwendungsfel<strong>der</strong>n mag die geringe Rechen- und Speicherkapazität <strong>der</strong> mobilen Geräte einen<br />
limitierenden Faktor darstellen – im Kontext <strong>der</strong> Datensynchronisation spielt dies nur eine untergeordnete<br />
Rolle.
5.1 BEURTEILUNG DER ANWENDUNGSENTWICKLUNG AUF BASIS DER CLDC 57<br />
5.1.3 Schwierigkeiten <strong>auf</strong>grund zu offener Spezifikationen<br />
Auf den zu Testzwecken verwendeten Geräten konnten erfreulicherweise keinerlei Inkompatibilitäten<br />
<strong>der</strong> jeweiligen Implementationen des MIDPs zur Referenzimplemenation von Sun festgestellt<br />
werden. Diese Erfahrung scheinen die meisten Entwickler zu teilen: Im Verl<strong>auf</strong> <strong>der</strong> Implementation<br />
wurden einige Internetforen für J2ME-Entwickler genutzt – von Problemen durch Inkompatibilitäten<br />
<strong>der</strong> MIDP-Implementationen <strong>der</strong> verschiedenen Hersteller wurde dabei kaum berichtet. Die Spezifikationen<br />
des MIDP scheinen also sehr wenig Spielraum bei <strong>der</strong> Implementierung zu lassen; zudem<br />
kann dem Profil eine gewisse Reife zugesprochen werden.<br />
Ganz an<strong>der</strong>s gestalteten sich die Versuche mit dem PIM-API: Zunächst wurde <strong>der</strong> SyncML-Client<br />
mithilfe des Emulators aus dem Wireless Toolkit getestet. Dieser bietet eine vollständige Implementation<br />
<strong>der</strong> PIM-API und erlaubt den Zugriff <strong>auf</strong> sämtliche Fel<strong>der</strong> eines Adressbucheintrages des<br />
Gerätes. Erste Tests <strong>auf</strong> dem Palm-Gerät ergaben ein völlig an<strong>der</strong>es Bild, kaum etwas funktionierte<br />
wie vorgesehen. Die Ursache hierfür liegt in einer sehr offenen Spezifikation <strong>der</strong> PIM-API. Zusätzlich<br />
lässt die Dokumentation <strong>der</strong> PIM-API für den Palm wichtige Detailfragen offen, sodass langwierige<br />
Tests nötig waren, um die Ursache <strong>der</strong> Probleme zu lokalisieren. In <strong>der</strong> Dokumentation einer an<strong>der</strong>en<br />
Implementationen dieser API werden die Restriktionen zumindest klar erläutert: Since the PIM<br />
”<br />
API leaves room for important variations among different manufacturers, it is important to be aware<br />
of certain implementation details for Nokia devices.“ [pim]<br />
Je größer <strong>der</strong> Spielraum für die Gerätehersteller bei <strong>der</strong> Implementierung einer Spezifikation ist, desto<br />
wahrscheinlicher werden Inkompatibilitäten zwischen den einzelnen Geräten. Das für die <strong>Synchronisation</strong><br />
essentielle Revision-Feld, in dem das Datum <strong>der</strong> letzten Än<strong>der</strong>ung eines Adressbucheintrages<br />
festgehalten wird, ist in <strong>der</strong> Spezifikation <strong>der</strong> PIM-API als optional ausgewiesen. Zur Zeit sind<br />
zwei Implementationen <strong>der</strong> PIM-API verfügbar, bei beiden kann nicht <strong>auf</strong> das Revision-Feld zugegriffen<br />
werden. Die Entwicklung von <strong>Anwendungen</strong> zur <strong>Synchronisation</strong> dieser Daten ist somit kaum<br />
möglich.<br />
Anhand <strong>der</strong> PIM-API ließ sich auch ein weiteres Problem gut nachvollziehen: Die Veröffentlichung<br />
von fehlerhaften Implementierungen durch die Hersteller. Dabei spielt <strong>der</strong> Zeitdruck bei <strong>der</strong> Entwicklung<br />
<strong>der</strong> Geräte eine große Rolle. Die PIM-API wurde beispielsweise im Juli 2004 endgültig<br />
spezifiziert, die erste Implementierung von IBM im März 2005 für den Palm Treo veröffentlicht. Die<br />
Methode zum Import von Adressbucheinträgen im vCard-Format weist Fehler <strong>auf</strong>, die eindeutig <strong>der</strong><br />
Implementierung <strong>der</strong> API zuzuschreiben sind. Obwohl die zu importierenden vCards <strong>der</strong> Spezifikation<br />
genau entsprachen, wurde <strong>der</strong> Import abgebrochen und eine Exception geworfen, die <strong>auf</strong> einen<br />
Fehler innerhalb <strong>der</strong> API deutet. Eine Möglichkeit, fehlerhafte Implementierungen durch eine verbesserte<br />
Version zu ersetzen besteht im Rahmen <strong>der</strong> CLDC-Plattform bislang nicht.<br />
5.1.4 Aus den Restriktionen <strong>der</strong> CLDC resultierende Probleme<br />
<strong>Anwendungen</strong> für die CLDC werden innerhalb einer sehr restriktiven Umgebung ausgeführt. Dies<br />
ist zunächst einmal positiv zu bewerten, weil dadurch eine sichere Ausführung von <strong>Anwendungen</strong><br />
<strong>auf</strong> dem mobilen Gerät möglich wird (siehe Kapitel 2.4 zu Sicherheitsmaßnahmen in <strong>der</strong> J2ME). Problematisch<br />
sind allerdings Einschränkungen, welche die Möglichkeiten des Benutzers beschneiden.
5.1 BEURTEILUNG DER ANWENDUNGSENTWICKLUNG AUF BASIS DER CLDC 58<br />
Anhand signierter <strong>Anwendungen</strong> kann sichergestellt werden, dass diese aus vertrauenswürdigen<br />
Quellen stammen. Wenn aber allein das Gerät, ohne jegliche Interaktionsmöglichkeit seitens des Benutzers,<br />
über die Vertrauenswürdigkeit einer Quelle entscheidet, ist damit zugleich auch sichergestellt,<br />
dass <strong>der</strong> Entwickler einer signierten Anwendung seine Vertrauenswürdigkeit durch die Zahlung<br />
einer Gebühr an eine offizielle Certificate Authority unter Beweis gestellt hat. Der Preis für eine<br />
von offizieller Stelle signierte Anwendung liegt bei einigen hun<strong>der</strong>t US-Dollar im Jahr [ver].<br />
Hat ein Entwickler seine Anwendung mittels eines sogenannten Self-Signed Certificate selber signiert,<br />
liegt die Verantwortung beim Benutzer: Er muss sicherstellen, diese Anwendung von einer Quelle<br />
zu beziehen, <strong>der</strong> er vertrauen kann – beispielsweise von <strong>der</strong> offiziellen Webseite des Entwicklers.<br />
Im Rahmen <strong>der</strong> J2ME werden Self-Signed Certificates allerdings grundsätzlich abgelehnt, ohne dass<br />
<strong>der</strong> Benutzer dies än<strong>der</strong>n könnte. Akzeptiert werden nur von offizieller Stelle signierte <strong>Anwendungen</strong>.<br />
Selbst erstellte <strong>Anwendungen</strong> können also nur unsigniert zur Verfügung gestellt werden und<br />
l<strong>auf</strong>en dann im Sicherheitskontext untrusted. In diesem Kontext ist eine dauerhafte Vergabe von Berechtigungen<br />
nicht möglich. Wenn eine Anwendung beispielsweise den Zugriff <strong>auf</strong> die Netzverbindung<br />
des Gerätes benötigt, muss <strong>der</strong> Benutzer dem bei jedem Start <strong>der</strong> Anwendung zustimmen.<br />
Bei <strong>der</strong> Entwicklung des SyncML-Prototypen gestaltete sich die Fehlersuche <strong>auf</strong> dem Palm aus diesem<br />
Grund etwas langwieriger: Bei jedem Start <strong>der</strong> Anwendung mussten zunächst drei Anfragen<br />
nach diversen Berechtigungen (PIM.READ, PIM.WRITE, CONNECTION.HTTP) beantwortet werden.<br />
Einem zahlenden Kunden ist dies sicherlich nicht zuzumuten – für den Entwickler wird die kostspielige<br />
Zertifizierung durch eine offizielle Certificate Authority unumgänglich.<br />
Der Umfang an Restriktionen, die den Benutzern <strong>der</strong> J2ME <strong>auf</strong>erlegt werden, könnte ein entscheiden<strong>der</strong><br />
Faktor für den weiteren Erfolg <strong>der</strong> Plattform sein. Automatische Updates <strong>der</strong> Geräte durch<br />
Hersteller o<strong>der</strong> Mobilfunkbetreiber dürften nicht nur dem Einsatz solcher Geräte im Unternehmenskontext<br />
entgegenstehen – auch viele private Nutzer könnte dies verärgern. Auf den Desktop-<br />
Computern und auch im Bereich <strong>der</strong> Smartphones und PDAs sind die Benutzer weitreichende Freiheiten<br />
in <strong>der</strong> Verwendung <strong>der</strong> Geräte gewohnt, umfangreiche Restriktionen könnten für die Hersteller<br />
schwer zu vermitteln werden. Die bisherigen Erfahrungen im Bereich des Brandings [c’t05a] von<br />
Geräten durch die Mobilfunkanbieter lassen hinsichtlich dieser Problematik zumindest eine gewisse<br />
Aufmerksamkeit seitens <strong>der</strong> Benutzer erkennen. Beispielsweise konnte ein Käufer eines Mobiltelefons,<br />
bei dem <strong>der</strong> Mobilfunkanbieter unerwünschte Funktionen des Gerätes durch eine Anpassung<br />
<strong>der</strong> Firmware deaktiviert hatte, vor Gericht eine Rückerstattung des K<strong>auf</strong>preises durchsetzen<br />
[c’t05d].<br />
5.1.5 Fragmentation <strong>der</strong> CLDC-Plattform<br />
Die CLDC ist als einheitliche, plattformübergreifende <strong>Basis</strong> für die Entwicklung <strong>mobiler</strong> <strong>Anwendungen</strong><br />
gedacht. Diese Einheitlichkeit führt jedoch dazu, dass neue Funktionalitäten nur sehr langsam in<br />
die Profile <strong>der</strong> CLDC integriert werden. Aus diesem Grund wurde die Möglichkeit geschaffen, optionale<br />
Pakete für die CLDC zu spezifizieren, die vergleichsweise schneller entworfen und umgesetzt<br />
werden können. Allerdings verringert sich die Einheitlichkeit <strong>der</strong> Plattform, je mehr <strong>Anwendungen</strong><br />
optionale Pakete voraussetzen.
5.1 BEURTEILUNG DER ANWENDUNGSENTWICKLUNG AUF BASIS DER CLDC 59<br />
Obwohl die CLDC-Plattform seit Ende 1999 existiert und seitdem ständig weiterentwickelt wird,<br />
fehlte lange Zeit die für professionelle <strong>Anwendungen</strong> nötige Funktionalität. Anfangs wurden <strong>auf</strong> <strong>Basis</strong><br />
<strong>der</strong> CLDC in erster Linie kleine Spiele entwickelt. Erst seit <strong>der</strong> Ende 2002 veröffentlichten Version<br />
2.0 des MIDPs stehen ausreichende Möglichkeiten zur Verfügung, auch komplexere <strong>Anwendungen</strong><br />
zu realisieren.<br />
Die Entwicklung von CLDC und MIDP muss dabei im Kontext <strong>der</strong> Fähigkeiten <strong>der</strong> mobilen Geräte<br />
gesehen werden: Obwohl die Produktlebenszyklen <strong>auf</strong> dem Markt für mobile Geräte sehr kurz sind,<br />
vergingen nach <strong>der</strong> endgültigen Festlegung <strong>der</strong> Spezifikationen <strong>der</strong> Version 2.0 des MIDPs noch<br />
einige Monate, bis dieses Profil bei den Geräteherstellern allgemeine Verwendung fand. Ungefähr<br />
seit Mitte des Jahres 2004 wird ein Großteil <strong>der</strong> neuen Mobiltelefone und Smartphones mit Unterstützung<br />
des MIDPs in Version 2.0 ausgeliefert. Zwischen <strong>der</strong> Verabschiedung des neuen Profils,<br />
und einer allgemeinen Verfügbarkeit <strong>auf</strong> einer Mehrzahl <strong>der</strong> im Einsatz befindlichen mobilen Geräte<br />
liegen also mindestens 2 Jahre, auch bei Annahme eines häufigen Wechsels <strong>der</strong> Gerätemodelle seitens<br />
<strong>der</strong> Benutzer.<br />
Die Arbeitsgruppe zur Weiterentwickelung des MIDPs plant die Verabschiedung <strong>der</strong> endgültigen<br />
Spezifikationen des Profils in Version 3.0 für Mitte 2006. Geplant ist unter an<strong>der</strong>em die Realisierung<br />
einiger Funktionen, <strong>der</strong>en Fehlen momentan die Ursache für die beginnende Fragmentation<br />
<strong>der</strong> CLDC-Plattform ist: Die Möglichkeit, optionale Pakete nachträglich zu installieren, sowie eine<br />
Unterstützung für Bibliotheken, die von mehreren <strong>Anwendungen</strong> gemeinsam genutzt werden<br />
können (shared libraries).<br />
Anhand <strong>der</strong> Erfahrungswerte bei <strong>der</strong> Einführung des MIDP 2.0 kann mit einer größeren Verbreitung<br />
von Geräten mit dem MIDP in Version 3.0 jedoch frühestens gegen Ende des Jahres 2007 gerechnet<br />
werden – die heutige Version des MIDPs wird also in den nächsten zwei bis drei Jahren <strong>Basis</strong> <strong>der</strong><br />
Anwendungsentwicklung bleiben. Während dieser Zeit wird zur CLDC-Plattform neue Funktionalität<br />
nur über weitere optionale Pakete hinzukommen können. Die sich abzeichnende Fragmentation<br />
<strong>der</strong> Plattform wird mittelfristig also sehr wahrscheinlich zunehmen.<br />
Ein möglicher Ausweg aus <strong>der</strong> Problematik könnte in <strong>der</strong> Spezifizierung eines weiteren Metapackages,<br />
ähnlich dem <strong>Java</strong> Technology for the Wireless Industry liegen (siehe Kapitel 2.3). Auf diese Weise<br />
könnte neben einer durch optionale Pakete erweiterten <strong>Basis</strong>plattform auch eine Erhöhung des<br />
Größenlimits <strong>der</strong> <strong>Anwendungen</strong> festgeschrieben werden. Viele <strong>der</strong> heute verfügbaren Geräte wären<br />
dafür sicherlich leistungsfähig genug.<br />
5.1.6 Konsequenzen für die Datensynchronisation <strong>mobiler</strong> <strong>Anwendungen</strong><br />
Bei <strong>der</strong> Entwicklung <strong>mobiler</strong> <strong>Anwendungen</strong> <strong>auf</strong> <strong>Basis</strong> <strong>der</strong> CLDC muss zunächst entschieden werden,<br />
ob <strong>der</strong> Einsatz optionaler Pakete mit den damit verbundenen erhöhten Anfor<strong>der</strong>ungen an die<br />
Geräte unumgänglich ist. Mit <strong>der</strong> Verwendung komplexerer Verfahren zur Datensynchronisation<br />
wird in den meisten Fällen die Nutzung eines optionalen Paketes notwendig, damit <strong>der</strong> beschränkte<br />
Speicherplatz <strong>auf</strong> dem Gerät vollständig für den Code <strong>der</strong> Anwendung genutzt werden kann. Das<br />
Webservice-API bietet neben Methoden zur Nutzung von Webservices auch einen XML-Parser, sodass<br />
dieses Paket eine gute Grundlage für standardisierte Verfahren zur Datensynchronisation darstellt.
5.2 DIE ZUKÜNFTIGE ENTWICKLUNG DER CDC 60<br />
Der Einsatz komplexerer Verfahren zur Datensynchronisation über eine Bluetooth-Verbindung scheitert<br />
lei<strong>der</strong> an <strong>der</strong> fehlenden Unterstützung des OBEX-Protokolls. Nur in Ausnahmefällen dürfte die<br />
Verwendung <strong>der</strong> zusätzlichen OBEX-Bibliothek noch genug Speicherplatz für die Anwendung lassen.<br />
Ebenso schwierig gestaltet sich die Interaktion mit den nativen Adress- und Termindatenbanken<br />
eines Gerätes über das optionale PIM-Paket. Eine einfache Personalisierung von <strong>Anwendungen</strong> ist<br />
damit möglich, eine weitergehende <strong>Synchronisation</strong> <strong>der</strong> Daten jedoch kaum zu realisieren.<br />
Der große Vorteil <strong>der</strong> CLDC-Plattform bleibt jedoch die weite Verbreitung <strong>auf</strong> den unterschiedlichsten<br />
Geräten. Wenn dieser genutzt werden soll, müssen bei <strong>der</strong> Entwicklung einige Kompromisse<br />
eingegangen werden. Solange sich die Komplexität <strong>der</strong> verwendeten Verfahren zur Datensynchronisation<br />
an den beschränkten Möglichkeiten <strong>der</strong> Geräte orientiert, sind auch umfangreichere <strong>Anwendungen</strong><br />
möglich. Sinnvoll ist in diesem Zusammenhang die Verwendung eines dezidierten Proxy-<br />
Servers, mit dessen Hilfe Daten speziell für die mobile Anwendung <strong>auf</strong>bereitet werden können.<br />
Auch die direkte Kommunikation zwischen mehreren mobilen <strong>Anwendungen</strong> über eine Bluetooth-<br />
Verbindung lässt sich unter Berücksichtigung <strong>der</strong> Limitationen <strong>der</strong> Plattform sinnvoll nutzen.<br />
5.2 Die zukünftige Entwicklung <strong>der</strong> CDC<br />
Wie bereits in den Überlegungen zur Evaluation geschil<strong>der</strong>t, sind Geräte mit einer Unterstützung<br />
für die Profile <strong>der</strong> CDC momentan kaum verfügbar. Um die Möglichkeiten <strong>der</strong> Entwicklung mit <strong>der</strong><br />
CDC abzuschätzen, bietet es sich daher an einen Blick in die Zukunft zu werfen.<br />
Wegen <strong>der</strong> großen Verbreitung des MIDPs konzentrierte sich die Weiterentwicklung <strong>der</strong> J2ME-<br />
Plattform in den Jahren 2001 bis 2004 <strong>auf</strong> die CLDC, die Entwicklung <strong>der</strong> CDC stagnierte hingegen.<br />
Erst gegen Ende 2004 wurde die Weiterentwicklung merklich beschleunigt, mit dem Ziel einer<br />
vollständigen Kompatibilität zur API <strong>der</strong> <strong>Java</strong> Standard Edition in Version 1.4, inklusive des Swing-<br />
Frameworks für die Gestaltung graphischer Oberflächen. Die endgültigen Spezifikationen wurden<br />
im August 2005 verabschiedet (JSR 216 bis 219).<br />
Die neue Version dürfte die Attraktivität <strong>der</strong> Plattform durch eine stark vereinfachte Migration<br />
von <strong>Anwendungen</strong> <strong>der</strong> J2SE <strong>auf</strong> mobile Geräte erhöhen. Zudem könnten die oben angesprochenen<br />
Probleme bei <strong>der</strong> Weiterentwicklung <strong>der</strong> CLDC-Plattform dazu führen, dass die Hersteller <strong>mobiler</strong><br />
Geräte verstärkt <strong>auf</strong> die CDC setzen werden. Für die weit verbreitete, herstellerübergreifende<br />
Symbian-Plattform ist eine zukünftige Unterstützung <strong>der</strong> CDC bereits angekündigt worden [c’t05c].<br />
Möglicherweise wird das ursprüngliche Konzept <strong>der</strong> J2ME-Plattform <strong>auf</strong> diese Weise doch noch<br />
realisiert: Die CLDC findet Verwendung in Mobiltelefonen, während die leistungsfähigeren Smartphones<br />
die CDC nutzen.<br />
Fraglich bleibt jedoch, ob sich eine breitere Unterstützung <strong>der</strong> CDC auch bei den PDAs und PocketP-<br />
Cs durchsetzen wird. Warum <strong>auf</strong> <strong>der</strong> leistungsfähigen Palm-Plattform im Moment nur die CLDC<br />
unterstützt wird, ist kaum verständlich. Die mangelnde Verfügbarkeit <strong>der</strong> CDC <strong>auf</strong> den PocketP-<br />
Cs, lässt sich hingegen anhand des angespannten Verhältnisses zwischen Sun und <strong>Micro</strong>soft, dem<br />
Hersteller des Windows Mobile-Betriebssystems <strong>der</strong> PocketPCs erklären. Ob PDAs und Smartphones
5.3 FAZIT UND AUSBLICK 61<br />
<strong>auf</strong> Linux-<strong>Basis</strong> in Zukunft weitere Verbreitung finden bleibt abzuwarten – eine Fortführung <strong>der</strong><br />
Unterstützung <strong>der</strong> CDC-Plattform <strong>auf</strong> diesen Geräten ist jedoch wahrscheinlich.<br />
5.3 Fazit und Ausblick<br />
Eine Entwicklung komplexerer <strong>Anwendungen</strong> <strong>auf</strong> <strong>Basis</strong> <strong>der</strong> J2ME ist zum heutigen Zeitpunkt kaum<br />
zu empfehlen: Geräte mit Unterstützung <strong>der</strong> Profile <strong>der</strong> CLDC sind weit verbreitet, die Plattform<br />
zeichnet sich allerdings durch umfangreiche Limitationen aus. Die Möglichkeiten diese zu verringern<br />
führen zu einer drastischen Verringerung des Umfangs verfügbarer Geräte. Die CDC steht<br />
dagegen grundsätzlich nur <strong>auf</strong> sehr wenigen Geräten zur Verfügung. Einzig im Kontext von Unternehmen<br />
o<strong>der</strong> an<strong>der</strong>en größeren Organisationen erscheint ein Einsatz komplexer <strong>Anwendungen</strong><br />
<strong>auf</strong> <strong>Basis</strong> <strong>der</strong> J2ME sinnvoll, wenn zusammen mit <strong>der</strong> Anwendung auch geeignete Geräte angeschafft<br />
werden. Speziell für diese Einsatzgebiete sind auch Komplettlösungen wie das WebSphere<br />
Studio Device Developer gedacht. IBM verspricht eine möglichst reibungslose Integration <strong>mobiler</strong> <strong>Anwendungen</strong><br />
in bestehende, <strong>auf</strong> IBM-Lösungen basierende Informationssysteme und versucht dieses<br />
Versprechen durch eine eigene virtuelle Maschine für ausgewählte mobile Geräte zu realisieren.<br />
Angesichts <strong>der</strong> Einschränkungen <strong>der</strong> J2ME-Plattform sollte zur Zeit auch die Entwicklung nativer<br />
<strong>Anwendungen</strong> in Betracht gezogen werden. Sowohl PalmOS, SymbianOS als auch Windows Mobile<br />
dürften jeweils <strong>auf</strong> einer größeren Anzahl an Geräten verfügbar sein, als die CDC, o<strong>der</strong> die CLDC<br />
in Verbindung mit bestimmten optionalen Paketen. Selbst Personal<strong>Java</strong> findet <strong>auf</strong>grund einer weiten<br />
Verbreitung noch rege Verwendung, obwohl diese Plattform von Sun schon lange nicht mehr<br />
weiterentwickelt wird.<br />
Für die Entwicklung mit <strong>der</strong> J2ME bleibt zunächst nur <strong>der</strong> Blick in die Zukunft. Dabei ergibt sich ein<br />
durchaus positives Bild, denn für viele <strong>der</strong> angesprochenen Kritikpunkte werden zur Zeit adäquate<br />
Lösungsansätze diskutiert und entwickelt. Die nachträgliche Installation von optionalen Paketen<br />
und shared libraries soll das in JSR-232 entwickelte Mobile Operational Management ermöglichen.<br />
Für Updates vorhandener Profile und Konfigurationen, beispielsweise zur Beseitigung von Sicherheitslücken<br />
und fehlerhaften Implementationen, wird die Mobile Service Architekture (JSR 248 und<br />
249) entwickelt. Eine Schnittstelle für die Datensynchronisation mittels SyncML soll das Data Sync<br />
API (JSR-230) schaffen, eine allgemeine Unterstützung von XML <strong>auf</strong> <strong>der</strong> J2ME-Plattform durch ein<br />
XML-API realisiert werden (JSR-280).<br />
Die Entwicklung dieser Pakete im <strong>Java</strong> Community Process befindet sich jedoch großenteils noch in <strong>der</strong><br />
Anfangsphase. Erst mit <strong>der</strong> Fertigstellung <strong>der</strong> nächsten Version des MIDPs (JSR-271) kann mit einer<br />
umfassenden Erneuerung <strong>der</strong> CLDC-Plattform gerechnet werden. Die dabei geplanten Än<strong>der</strong>ungen<br />
sind sehr ambitioniert und könnten zu einer vollwertigen Plattform <strong>auf</strong> <strong>Basis</strong> des MIDPs führen:<br />
Eine simultane Ausführung mehrerer <strong>Anwendungen</strong> mit <strong>der</strong> Möglichkeit <strong>der</strong> Kommunikation zwischen<br />
diesen, im Hintergrund abl<strong>auf</strong>ende <strong>Anwendungen</strong>, gemeinsam genutzte Bibliotheken und die<br />
nachträgliche Installation von Paketen würden die aktuellen Limitationen <strong>der</strong> Plattform Vergangenheit<br />
werden lassen.
5.3 FAZIT UND AUSBLICK 62<br />
Angesichts des Umfangs <strong>der</strong> geplanten Än<strong>der</strong>ungen steht allerdings zu befürchten, das einzelne Ziele<br />
wie<strong>der</strong> <strong>auf</strong>gegeben werden müssen, o<strong>der</strong> <strong>der</strong> Zeitplan zur Realisierung nicht eingehalten werden<br />
kann. An <strong>der</strong> Zeitspanne, in <strong>der</strong> diese Weiterentwicklungen zu Marktreife gebracht werden, wird<br />
sich auch zeigen, ob die Zusammenarbeit <strong>der</strong> beteiligten Unternehmen im <strong>Java</strong> Community Process<br />
effektiv funktioniert.<br />
Es bleibt in jedem Fall lohnenswert die weitere Entwicklung <strong>der</strong> J2ME im Auge zu behalten, denn<br />
eine leistungsfähige und flexible <strong>Basis</strong> zur plattformübergreifenden Entwicklung <strong>mobiler</strong> <strong>Anwendungen</strong><br />
könnte in Zukunft entstehen.
Literaturverzeichnis<br />
Ant ANTENNA PROJECT: An Ant-to-End Solution For Wireless <strong>Java</strong>. http://antenna.<br />
sourceforge.net/. – Online–Ressource, Abruf: 22. 05. 2005<br />
avea AVETANA GMBH: AvetanaBluetooth, a <strong>Java</strong>/JNI-Implementation of JSR-82 for Linux and<br />
J2SE. http://sourceforge.net/projects/avetanabt/. – Online–Ressource, Abruf:<br />
22. 05. 2005<br />
aveb AVETANA GMBH: AvetanaOBEX, an OBEX implementation for J2ME phones supporting JSR-<br />
82. http://sourceforge.net/projects/avetanaobex. – Online–Ressource, Abruf:<br />
22. 05. 2005<br />
Axi THE APACHE SOFTWARE FOUNDATION: Webservices Project - Axis. http://ws.apache.<br />
org/axis/. – Online–Ressource, Abruf: 22. 05. 2005<br />
Ber BERKA, Stan: JAVA for PocketPC PDA’s. http://www.berka.name/stan/jvm-ppc/<br />
java_for_pda.html. – Online–Ressource, Abruf: 08. 08. 2005<br />
Blu BEN HUI: J2ME application development resources for Bluetooth technology. http://benhui.<br />
net/modules.phpname=Bluetooth&page=bluelet.html. – Online–Ressource,<br />
Abruf: 22. 05. 2005<br />
c’t04a HEISE ONLINE: <strong>Java</strong>-Sicherheit <strong>auf</strong> Handys ausgehebelt. Version: 19.Oktober 2004. http://<br />
www.heise.de/newsticker/meldung/52321. – Online–Ressource, Abruf: 22. 06. 2005<br />
c’t04b HEISE ONLINE: Nokia wird Download-Händler. Version: 25.Oktober 2004. http://www.<br />
heise.de/newsticker/meldung/52477. – Online–Ressource, Abruf: 22. 06. 2005<br />
c’t04c HEISE ONLINE: Schwere Sicherheitslücken bei Bluetooth-Handys. Version: 29.Dezember 2004.<br />
http://www.heise.de/newsticker/meldung/54659. – Online–Ressource, Abruf:<br />
22. 06. 2005<br />
c’t05a HEISE ONLINE: Branding Extreme: T-Mobile bringt UMTS-Handy ohne Bluetooth-<br />
Datendienste. Version: 13.Mai 2005. http://www.heise.de/newsticker/meldung/<br />
59530. – Online–Ressource, Abruf: 23. 07. 2005<br />
c’t05b HEISE ONLINE: <strong>Java</strong>One 2005: <strong>Java</strong> für Handys wird ausgebaut. Version: 27.Juni 2005.<br />
http://www.heise.de/newsticker/meldung/61069. – Online–Ressource, Abruf:<br />
27. 06. 2005
LITERATURVERZEICHNIS 64<br />
c’t05c HEISE ONLINE: <strong>Java</strong>One 2005: Nokia setzt <strong>auf</strong> die Fernkonfiguration von Series-60-<br />
Handys. Version: 27.Juni 2005. http://www.heise.de/newsticker/meldung/<br />
61114. – Online–Ressource, Abruf: 27. 06. 2005<br />
c’t05d HEISE ONLINE: Urteil gegen Handy-Branding. Version: 13.März 2005. http://www.<br />
heise.de/newsticker/meldung/57462. – Online–Ressource, Abruf: 23. 07. 2005<br />
Ecla ECLIPSE FOUNDATION: Eclipse Platform. http://www.eclipse.org/. – Online–<br />
Ressource, Abruf: 22. 05. 2005<br />
Eclb ECLIPSEME PROJECT: EclipseME Plugin Homepage. http://www.eclipseme.org/. –<br />
Online–Ressource, Abruf: 22. 05. 2005<br />
enc MANES, Anne T.: Document vs. RPC style. http://searchwebservices.techtarget.<br />
com/ateQuestionNResponse/0,289625,s%id26_cid494324_tax289201,00.<br />
html. – Online–Ressource, Abruf: 08. 08. 2005<br />
GCH04 GMELIN, Moritz ; CAMPANA, Julien ; HARBAUM, Till: Bluetooth-Programmierung mit <strong>Java</strong><br />
<strong>auf</strong> dem Desktop. In: c’t 22 (2004)<br />
Gig GIGUERE, Eric ; SUN DEVELOPER NETWORK: Object Serialization in CLDC-Based<br />
Profiles. http://developers.sun.com/techtopics/mobility/midp/ttips/<br />
serialization/%. – Online–Ressource, Abruf: 22. 05. 2005<br />
Gme05 GMELIN, Moritz: Bluetooth-Handys: OBEX-<strong>Anwendungen</strong> mit <strong>Java</strong> entwickeln. In: c’t 8<br />
(2005)<br />
HMPT02 HANSMANN, Uwe ; METTALA, Riku ; PURAKAYASTHA, Apratim ; THOMPSON, Peter:<br />
SyncML: Synchronizing and Managing Your Mobile Data. Pearson Education, 2002. – ISBN<br />
0130093696<br />
HZ05 HEIN, Manfred ; ZELLER, Henner: <strong>Java</strong> WebServices. Addison-Wesley, 2005. – ISBN<br />
3827322316<br />
J9 INC., IBM: WebSphere Everyplace <strong>Micro</strong> Environment. http://www-306.ibm.com/<br />
software/wireless/weme/. – Online–Ressource, Abruf: 08. 08. 2005<br />
JAXa SUN MICROSYSTEMS, INC.: <strong>Java</strong> API for XML-Based RPC (JAX-RPC. http://java.sun.<br />
com/xml/jaxrpc/. – Online–Ressource, Abruf: 08. 07. 2005<br />
JAXb SUN MICROSYSTEMS, INC.: <strong>Java</strong> API for XML Processing (JAXP). http://java.sun.<br />
com/xml/jaxp/. – Online–Ressource, Abruf: 08. 07. 2005<br />
Jbe INC., Esmertec: Jbed CDC. http://www.esmertec.com/solutions/mobile_<br />
multimedia/jbed_cdc/. – Online–Ressource, Abruf: 08. 08. 2005<br />
JCPa JAVA COMMUNITY PROCESS: <strong>Java</strong> Community Process Program Overview. http://jcp.<br />
org/en/introduction/overview. – Online–Ressource, Abruf: 07. 06. 2005<br />
JCPb JAVA COMMUNITY PROCESS: JCP 2: Process Document. http://www.jcp.org/en/<br />
procedures/jcp2. – Online–Ressource, Abruf: 07. 06. 2005
LITERATURVERZEICHNIS 65<br />
JSRa JAVA COMMUNITY PROCESS: <strong>Java</strong> Specification Requests for J2ME. http://jcp.org/en/<br />
jsr/eclistBy=2. – Online–Ressource, Abruf: 07. 06. 2005<br />
JSRb JAVA COMMUNITY PROCESS: JSR 271: Mobile Information Device Profile 3. http://www.<br />
jcp.org/en/jsr/detailid=271. – Online–Ressource, Abruf: 21. 08. 2005<br />
JXM PROJECT JXTA: JXTA-J2ME (JXME) Platform Project. http://jxme.jxta.org/. –<br />
Online–Ressource, Abruf: 08. 07. 2005<br />
JXT PROJECT JXTA: Project JXTA Homepage. http://www.jxta.org/. – Online–Ressource,<br />
Abruf: 08. 07. 2005<br />
Knu03 KNUDSEN, Jonathan: Wireless <strong>Java</strong>: Developing with J2ME, Second Edition. Springer Verlag,<br />
2003. – ISBN 1-59059-077-5<br />
kOb KOBJECTS.ORG: Utility classes for J2ME. http://kobjects.sourceforge.net/. –<br />
Online–Ressource, Abruf: 08. 07. 2005<br />
McL02 MCLAUGHLIN, Brett: <strong>Java</strong> & XML. O’Reilly, 2002. – ISBN 389721296X<br />
Mir THE APACHE SOFTWARE FOUNDATION: Webservices Project - Mirae. http://ws.apache.<br />
org/mirae/index.html. – Online–Ressource, Abruf: 22. 05. 2005<br />
MK03 MICHAEL KROLL, Stefan H.: J2ME Developer’s Guide. Pearson Education, 2003. – ISBN<br />
3-8272-6509-6<br />
mul MULTISYNC PROJECT: Opensync. http://www.opensync.org/. – Online–Ressource,<br />
Abruf: 22. 07. 2005<br />
Nek THE APACHE SOFTWARE FOUNDATION: CyberNeko HTML Parser. http://people.<br />
apache.org/˜andyc/neko/doc/html/index.html. – Online–Ressource, Abruf:<br />
22. 05. 2005<br />
Ngh02 NGHIEM, Alex: IT Web Services: A Roadmap for the Enterprise. Prentice Hall, 2002. – ISBN<br />
0130097195<br />
OAS OASIS: Organization for the Advancement of Structured Information Standards. http://www.<br />
oasis-open.org/. – Online–Ressource, Abruf: 07. 07. 2005<br />
OMA OPEN MOBILE ALLIANCE: Open Mobile Alliance - Data <strong>Synchronisation</strong> Working<br />
Group. http://www.openmobilealliance.org/syncml. – Online–Ressource, Abruf:<br />
07. 07. 2005<br />
pim NOKIA, Forum: Introduction To The PIM API. http://www.forum.nokia.com/main/<br />
0,,1_0_15,00.html. – Online–Ressource, Abruf: 08. 08. 2005<br />
Pro PROGUARD PROJECT: Proguard <strong>Java</strong> obfuscation tools. http://proguard.<br />
sourceforge.net/. – Online–Ressource, Abruf: 22. 05. 2005<br />
RMI SUN MICROSYSTEMS, INC.: <strong>Java</strong> Remote Method Invocation. http://java.sun.com/<br />
products/jdk/rmi/. – Online–Ressource, Abruf: 10. 06. 2005
LITERATURVERZEICHNIS 66<br />
RS03 RUPP, Stephan ; SIEGMUND, Gerd: <strong>Java</strong> in <strong>der</strong> Telekommunikation. Grundlagen, Konzepte,<br />
<strong>Anwendungen</strong>. Dpunkt Verlag, 2003. – ISBN 3898642445<br />
Sch04 SCHMATZ, Klaus-Dieter: J2ME: Entwicklung <strong>mobiler</strong> <strong>Anwendungen</strong> mit CLDC und MIDP.<br />
dpunkt.verlag, 2004. – ISBN 3-89864-271-2<br />
SIG BLUETOOTH SPECIAL INTEREST GROUP: The Official Bluetooth Site. http://www.<br />
bluetooth.org. – Online–Ressource, Abruf: 22. 05. 2005<br />
SOA THE WORLD WIDE WEB CONSORTIUM (W3C): The Simple Object Access Protocol. http:<br />
//www.w3.org/TR/soap12-part0/. – Online–Ressource, Abruf: 22. 05. 2005<br />
SUNa SUN MICROSYSTEMS, INC.: Embedded<strong>Java</strong> Platform. http://java.sun.com/products/<br />
embeddedjava/. – Online–Ressource, Abruf: 06. 06. 2005<br />
SUNb SUN MICROSYSTEMS, INC.: J2ME Personal Profile for Zaurus. http://java.sun.com/<br />
developer/earlyAccess/pp4zaurus/. – Online–Ressource, Abruf: 06. 08. 2005<br />
SUNc SUN MICROSYSTEMS, INC.: J2ME Wireless Toolkit. http://java.sun.com/products/<br />
sjwtoolkit/. – Online–Ressource, Abruf: 06. 06. 2005<br />
SUNd SUN MICROSYSTEMS, INC.: Personal<strong>Java</strong> Platform. http://java.sun.com/products/<br />
personaljava/. – Online–Ressource, Abruf: 06. 06. 2005<br />
SUN99 SUN MICROSYSTEMS, INC.: Press Release: SUN outlines three Editions of JAVA2 Platform.<br />
Version: 15.Juni 1999. http://www.sun.com/smi/Press/sunflash/1999-06/<br />
sunflash.990615.15.html. – Online–Ressource, Abruf: 05. 06. 2005<br />
Sym LTD, Symbian: SymbianOS - mobile operating system. http://www.symbian.com/. –<br />
Online–Ressource, Abruf: 08. 08. 2005<br />
Syn FUNAMBOL.COM: Sync4j - <strong>Java</strong> SyncML Client and Server. http://sync4j.funambol.<br />
com/. – Online–Ressource, Abruf: 22. 05. 2005<br />
Tom THE APACHE SOFTWARE FOUNDATION: Tomcat Servlet Container. http://jakarta.<br />
apache.org/tomcat/. – Online–Ressource, Abruf: 22. 05. 2005<br />
Top02 TOPLEY, Kim: J2ME in a nutshell. O’Reilly, 2002. – ISBN 0-596-00253-X<br />
vCa IMC, Internet Mail C.: Personal Data Interchange. http://www.imc.org/pdi/. – Online–<br />
Ressource, Abruf: 08. 08. 2005<br />
ver (UTI), Unified Testing I.: <strong>Java</strong> Verified Program. http://www.javaverified.com/<br />
index.jsp. – Online–Ressource, Abruf: 08. 08. 2005<br />
W3Ca THE WORLD WIDE WEB CONSORTIUM (W3C): Web Services Activity. http://www.w3.<br />
org/2002/ws/. – Online–Ressource, Abruf: 07. 07. 2005<br />
W3Cb THE WORLD WIDE WEB CONSORTIUM (W3C): Web Services Architecture Usage Scenarios.<br />
http://www.w3.org/TR/ws-arch-scenarios/. – Online–Ressource, Abruf:<br />
07. 07. 2005
LITERATURVERZEICHNIS 67<br />
W3Cc THE WORLD WIDE WEB CONSORTIUM (W3C): Web Services Description Language (WSDL)<br />
Version 2.0. http://www.w3.org/TR/wsdl20-primer/. – Online–Ressource, Abruf:<br />
07. 07. 2005<br />
WAP WAP FORUM: The Wireless Application Protocol Forum. http://www.<br />
openmobilealliance.org/tech/affiliates/wap/wapindex.html. – Online–<br />
Ressource, Abruf: 22. 05. 2005<br />
WBFT04 WANG, Dapeng ; BAYER, Thomas ; FROTSCHER, Thilo ; TEUFEL, Marc ; WANG, Dapeng:<br />
<strong>Java</strong> Web Services mit Apache Axis. <strong>Java</strong>magazin, 2004. – ISBN 3935042574<br />
WBX WAP FORUM: Binary XML Content Format Specification. http://www.<br />
openmobilealliance.org/tech/affiliates/wap/wap-192-wbxml-200%<br />
10725-a.pdf. – Online–Ressource, Abruf: 05. 07. 2005<br />
WSP WAP FORUM: Wireless Session Protocol Specification. http://www.<br />
openmobilealliance.org/tech/affiliates/wap/wap-230-wsp-20010%<br />
705-a.pdf. – Online–Ressource, Abruf: 05. 07. 2005<br />
WTL WAP FORUM: Wireless Transport Layer Security Specification. http://www.<br />
openmobilealliance.org/tech/affiliates/wap/wap-261-wtls-2001%<br />
0406-a.pdf. – Online–Ressource, Abruf: 05. 07. 2005<br />
Xer THE APACHE SOFTWARE FOUNDATION: Xerces XML Parser. http://xml.apache.org/<br />
xerces2-j. – Online–Ressource, Abruf: 22. 05. 2005