Location Based Services am Beispiel eines

Сomentários

Transcrição

Location Based Services am Beispiel eines
Fachhochschule Fulda
University of Applied Sciences
Fachbereich Angewandte Informatik
Schwerpunkt Telekommunikation
Location Based Services am Beispiel
eines interaktiven Stadtführers
auf Basis von J2ME
Diplomarbeit von Olaf Lange
14. Dezember 2005
Betreuende Professoren:
Prof. Dr. Hans-Helmut Paul,
Prof. Dr. Jan-Torsten Milde
Zusammenfassung
- II -
Zusammenfassung
In der vorliegenden Arbeit wird ein interaktiver Stadtführer modelliert. Dieses System
stellt ortsbezogene Informationen zu Sehenswürdigkeiten auf dem Mobiltelefon dar. Die
Informationen werden zentral von einem Web Service bezogen. Die Implementierung
wird in der Programmiersprache Java realisiert. Das Potenzial von solchen und ähnlichen
Anwendungen wird erörtert. Aufgrund des Ortsbezuges werden solche Applikationen als
Location Based Services (LBS) bezeichnet.
Es werden verschiedene Techniken der Lokalisierung von Mobiltelefonen beschrieben und
gegenübergestellt. Im Vordergrund steht das satellitengesteuerte Lokalisierungssystem
Global Positioning System (GPS).
Desweiteren werden essentielle Grundlagen zur Entwicklung mobiler Anwendungen in der
Java 2 Micro Edition (J2ME) dargestellt. In diesem Zusammenhang wird die Programmierung von MIDlets und die persistente Speicherung von Daten auf dem Mobiltelefon
beleuchtet. Speziell wird die Anbindung von einem externen GPS-Empfänger und die Verbindung zu Web Services beschrieben.
Der interaktiver Stadtführer wird als Client-Server-Architektur modelliert. Das zugrunde
liegende Konzept ist in mehreren Schichten aufgebaut. Es hat einen starken modularen
Charakter, der es erlaubt, Komponenten auszutauschen oder das System durch neue
Komponenten zu erweitern. Das Konzept und die daraus folgende Implementierung lässt
sich auf andere Projekte übertragen. Aufgrund dieser Eigenschaften spricht man von
einem Framework.
Die Schnittstelle zwischen dem Client und dem Server wird als Web Service modelliert.
Dadurch wird sichergestellt, dass ein anderer Dienst - egal in welcher Programmiersprache er entwickelt wurde oder auf welcher Rechnerarchitektur er läuft - die Kommunikationsschnittstelle nutzen kann.
Inhaltsverzeichnis
- III -
Inhaltsverzeichnis
Zusammenfassung.............................................................................................II
Inhaltsverzeichnis............................................................................................III
Abbildungsverzeichnis.......................................................................................VI
Tabellenverzeichnis..........................................................................................VII
1 Einleitung.........................................................................................................1
1.1 Motivation..................................................................................................1
1.2 Ziele der vorliegenden Diplomarbeit...............................................................2
1.3 Aufbau der Diplomarbeit...............................................................................3
2 Mobile Anwendungen.......................................................................................4
2.1 Einordnung.................................................................................................5
2.1.1 Mobile Anwendungen.............................................................................5
2.1.2 Location Based Services.........................................................................5
2.2 Bestandsaufnahme......................................................................................6
2.2.1 Entwicklung des Mobiltelefons.................................................................6
2.2.2 Aktueller Mobilfunkmarkt.......................................................................7
2.2.3 Derzeitige Java-Anwendungen................................................................8
2.3 Abschätzung des Potenzials...........................................................................9
2.3.1 Wirtschaftliches Potenzial.......................................................................9
2.3.2 Erwartungen der Nutzer.......................................................................10
2.4 Mögliche Anwendungen...............................................................................11
2.4.1 Bereich „Orientierung“.........................................................................11
2.4.2 Bereich „Einkaufen“.............................................................................11
2.4.3 Bereich „Vergnügung“..........................................................................12
2.4.4 Bereich „Sicherheit und Notfälle“...........................................................13
2.4.5 Sonstige Anwendungen........................................................................14
2.5 Klassifizierung mobiler Anwendungen...........................................................15
2.5.1 Anforderungen und Klassifizierung.........................................................15
2.5.2 Klassifizierung der möglichen Anwendungen............................................16
2.6 Kritische Erfolgsfaktoren.............................................................................17
2.6.1 Technische Faktoren............................................................................17
2.6.2 Kundenspezifische Faktoren..................................................................17
Inhaltsverzeichnis
- IV -
3 Lokalisierungssysteme...................................................................................18
3.1 Satellitengestützte Systeme........................................................................19
3.1.1 Global Positioning System (GPS)...........................................................19
3.1.2 DGPS.................................................................................................22
3.1.3 AGPS.................................................................................................23
3.1.4 GALILEO............................................................................................23
3.2 Zellenbasierte Systeme...............................................................................24
3.2.1 GSM/GPRS-Netze................................................................................24
3.2.2 UMTS-Netze.......................................................................................26
3.2.3 WLAN................................................................................................27
3.2.4 Bluetooth...........................................................................................28
3.3 Gegenüberstellung der Systeme...................................................................29
4 J2ME Grundlagen............................................................................................32
4.1 Überblick über die Technologie.....................................................................33
4.1.1 Eigenschaften der J2ME zugehörigen Endgeräte.......................................33
4.1.2 Architektur der J2ME............................................................................34
4.2 CLDC (Konfiguration)..................................................................................36
4.2.1 Einschränkungen.................................................................................36
4.2.2 Das Generic Connecetion Framework (GCF).............................................37
4.3 MIDP (Profil).............................................................................................38
4.3.1 Der MIDlet-Lebenszyklus......................................................................38
4.3.2 Das LCDUI-Modell................................................................................39
4.3.3 Record Management System (RMS).......................................................40
4.4 Web Service API (optionales Paket)..............................................................41
4.4.1 Generelle Merkmale von Web Services....................................................41
4.4.2 Funktionsbereiche der API....................................................................43
4.5 Hello MIDlet (Praxisbeispiel)........................................................................44
4.5.1 Quellcode...........................................................................................44
4.5.2 Erzeugen der MIDlet Suite....................................................................45
5 Systemanalyse...............................................................................................46
5.1 Systemidee...............................................................................................47
5.1.1 Anforderungsbeitragende......................................................................47
5.1.2 Systemanforderungen..........................................................................48
5.2 Anwendungsfälle........................................................................................50
5.2.1 Essentielle Anwendungsfälle..................................................................50
5.2.2 Systemanwendungsfälle.......................................................................53
5.2.3 Anwendungsfall-Ablaufmodell................................................................55
5.3 Prototyp: Informationsdarstellung................................................................57
Inhaltsverzeichnis
-V-
6 Anwendungsdesign........................................................................................58
6.1 Anwendungsarchitektur..............................................................................59
6.2 Datenspeicherungsschicht...........................................................................61
6.2.1 Namespace-Datenbank........................................................................61
6.2.2 Content-Datenbank.............................................................................63
6.3 Datenzugriffsschicht...................................................................................65
6.4 Anwendungslogikschicht.............................................................................66
6.4.1 Namensauflösung................................................................................66
6.4.2 Informationsaufbereitung.....................................................................67
6.4.3 Lokalisierung......................................................................................69
6.4.4 Dialog-Agent......................................................................................71
6.5 Übertragungsschicht...................................................................................72
6.6 Präsentationsschicht...................................................................................73
6.6.1 Darstellung.........................................................................................73
6.6.2 Konfiguration......................................................................................75
7 Implementierung............................................................................................76
7.1 Datenspeicherungsschicht...........................................................................77
7.2 Datenzugriffsschicht...................................................................................77
7.3 Anwendungslogikschicht.............................................................................78
7.3.1 Namensauflösung................................................................................78
7.3.2 Informationsaufbereitung.....................................................................80
7.3.3 Lokalisisierung....................................................................................81
7.3.4 Dialog-Agent .....................................................................................84
7.4 Übertragungsschicht...................................................................................85
7.5 Präsentationsschicht...................................................................................86
7.5.1 Darstellung.........................................................................................86
7.5.2 Konfiguration......................................................................................87
7.6 Anwendungstest........................................................................................88
8 Diskussion der erreichten Ergebnisse.............................................................89
8.1 Realisierung des interaktiven Stadtführers.....................................................89
8.2 Mobile Java-Programmierung in der J2ME......................................................90
8.3 Potenzial und Techniken von LBS.................................................................91
Abkürzungsverzeichnis/Glossar........................................................................92
Literaturverzeichnis........................................................................................100
Erklärung........................................................................................................101
Hinweise zum Copyright..................................................................................101
Anlagen...........................................................................................................105
Abbildungsverzeichnis
- VI -
Abbildungsverzeichnis
Abbildung 1 Das aktuell viel verkaufte Mobiltelefon Sony Ericsson K750i ......................7
Abbildung 2 „Wer wird Millionär“, Java-Spiel auf dem Mobiltelefon...............................8
Abbildung 3 „Handy-Finder“, Anwendung zum Wiederfinden des Mobiltelefons von O2 .14
Abbildung 4 Generelle Anforderungen an Location Based Services (LBS).....................15
Abbildung 5 Konstellation der 24 Satelliten auf den sechs Umlaufbahnen beim GPS......19
Abbildung 6 GPS-Maus „Holux GR-230“, Beispiel für ein GPS-Empfangsgerät...............20
Abbildung 7 Idealisierte Visualisierung des im GPS eingesetzten Ortungsverfahrens......20
Abbildung 8 Grafische Darstellung der Auswirkung von Laufzeitfehlern beim GPS.........21
Abbildung 9 Funktionsweise von Differential GPS, einer Weiterentwicklung von GPS . . . .22
Abbildung 10 Struktur der Mobilfunknetze nach GSM (Funkzugangs- und Kernnetz)......24
Abbildung 11 Vereinfachte Architektur von UMTS (Funkzugangs- und Kernnetze).........26
Abbildung 12 Unterteilung der Java 2 Technologie....................................................33
Abbildung 13 Konfiguration, Profile und optionale Pakete der J2ME.............................34
Abbildung 14 Klassendiagramm des J2ME Paketes java.microedtion.io, Ausschnitt........37
Abbildung 15 Der MIDlet-Lebenszyklus, gesteuert von der AMS bzw. vom MIDlet.........38
Abbildung 16 Klassendiagramm des J2ME Paketes java.microedition.lcdui, Ausschnitt...39
Abbildung 17 Persistenten Datenhaltung mit Hilfe des RMS in der J2ME......................40
Abbildung 18 Funktionsweise von Web Services inklusiver beteiligter Instanzen...........41
Abbildung 19 Generelle Struktur von SOAP-Nachrichten............................................42
Abbildung 20 Quellcode eines einfachen MIDlets mit der Ausgabe „Hello World“...........44
Abbildung 21 Anforderungsbeitragende des interaktiven Stadtführers.........................47
Abbildung 22 Essentiellen Anwendungsfällen des interaktiven Stadtführers..................50
Abbildung 23 Anwendungsfälle der Lokalisierung beim interaktiven Stadtführer...........53
Abbildung 24 Anwendungsfälle der Seitenaufruf beim interaktiven Stadtführer.............54
Abbildung 25 Ablauf der Lokalisierung beim interaktiven Stadtführer..........................55
Abbildung 26 Ablauf des Seitenaufrufes beim interaktiven Stadtführer........................56
Abbildung 27 Prototyp der Informationsdarstellung beim interaktiven Stadtführers.......57
Abbildung 28 Die Client-Server-Architektur des interaktiven Stadtführers....................60
Abbildung 29 ER-Modell der Namespace-Datenbank zur Namensauflösung, Server.......61
Abbildung 30 Positionsdaten und -speicherung von Sehenswürdigkeiten in Fulda..........63
Abbildung 31 ERR-Modell der Content-Datenbank für die Inhaltsspeicherung, Server....64
Abbildung 32 Klassendiagramm der Schicht „Datenzugriff“, Web Service.....................65
Abbildung 33 Klassendiagramm der Schicht „Namensauflösung“, Web Service.............66
Abbildung 34 Klassendiagramm der Schicht „Informationsaufbereitung“, Web Services .68
Abbildung 35 Klassendiagramm der Schicht „Lokalisierung“, hier mobiler Client...........69
Abbildung 36 Zusammenspiel beteiligter Klassen bei der Mobiltelefon-Lokalisierung......70
Abbildungsverzeichnis
- VII -
Abbildung 37 Klassendiagramm der Schicht „Dialog-Agent“, Web Service....................71
Abbildung 38 Nachrichtenaustausch der mobilen Clients mit dem Web Service.............72
Abbildung 39 Klassendiagramm der Schicht „Darstellung“, mobiler Client....................74
Abbildung 40 Klassendiagramm der Konfiguration, mobiler Client...............................75
Abbildung 41 Quellcode-Ausschnitt des MySQL Datenzugriffes, Klasse DBConnector.....77
Abbildung 42 Darstellung möglicher Positionen und Gebiete zur Namensauflösung.......78
Abbildung 43 Darstellung der Flächenberechnung für die Namensauflösung.................79
Abbildung 44 Quellcode-Ausschnitt der Seitenerzeugung, Klasse Contentservice..........80
Abbildung 45 Übertragung der GPS Daten von der GPS-Maus zum Mobiltelefon............81
Abbildung 46 Quellcode der Positionsdaten-Ermittlung (GPS), Klasse GPSLocator.........82
Abbildung 47 Quellcode der Positionsdaten-Ermittlung (GPS) - Fortsetzung.................83
Abbildung 48 XML Nachricht einer Server Antwort für die Seite des Fuldarer Doms.......85
Abbildung 49 Quellcode-Ausschnitt der Client Konfiguration, Klasse Configuration........87
Abbildung 50 Positionsdaten von Sehenswürdigkeiten und Testpositionen in Fulda........88
Abbildung 51 Start-Bildschirm der Anwendung „KToolbar“ des WTK..........................107
Abbildung 52 Installationswizard der J2EE-SDK Installation.....................................108
Abbildung 53 Administratioinsoberfläche des Applikation Servers von Sun.................109
Abbildung 54 Shellscript zum Starten des Applikation Servers als Daemon ................110
Abbildung 55 Konfiguration von EclipseME, Eclipse-Plugin für die J2ME......................112
Tabellenverzeichnis
Tabelle 1 Motivation zur Nutzung mobiler Dienste, Ergebnisse einer Studie..................10
Tabelle 2 Klassifizierung der vorgestellten möglicher mobilen Anwendungen................16
Tabelle 3 Gegenüberstellung satellitengestützter Lokalisierungssysteme......................31
Tabelle 4 Gegenüberstellung zellenbasierter Lokalisierungssysteme............................31
Tabelle 5 Kurzfassung der Systemanforderungen an den interaktiven Stadtführer.........49
Tabelle 6 „Einstellungen ändern“, ein Anwendungsfall des interaktiven Stadtführers . . . .51
Tabelle 7 „Anwender lokalisieren“, ein Anwendungsfall des interaktiven Stadtführers....51
Tabelle 8 „Seite anzeigen“, ein Anwendungsfall des interaktiven Stadtführers..............52
Tabelle 9 „Namensraum ändern“, ein Anwendungsfall des interaktiven Stadtführers.....52
Tabelle 10 „Information ändern“, ein Anwendungsfall des interaktiven Stadtführers......52
Tabelle 11 Verwendeten Symbole in den UML-Klassendiagrammen.............................58
Tabelle 12 Übersicht über die Pakete der Anwendung des interaktiven Stadtführeres. . . .76
Tabelle 13 Design-Veränderungen auf Grund des Verzichtes des Web Service API.........84
Tabelle 14 Ergebnisse eines „interaktiven Stadtführer“ Systemtestes..........................88
Tabelle 15 Übersicht über die in dieser Diplomarbeit eingesetzte Software.................106
1 Einleitung
-1-
1 Einleitung
1.1 Motivation
In den letzten 20 Jahren verbreitete sich das Mobiltelefon in einem rasanten Tempo. „Mit
fast 1,5 Milliarden verkauften Abonnements und Prepaid-Karten gibt es weltweit mehr
Mobiltelefone als Festnetzanschlüsse“ [DPA 2004]. Die Entwicklung ging von unhandlichen einfachen Telefonen zu kleinen Alleskönnern mit hochauflösendem Farbdisplay,
Organizer und integrierter Kamera. Es ist zu erwarten, dass dieser Trend weiter
voranschreitet und Mobiltelefone bald über noch mehr Speicherplatz und Funktionen
verfügen.
Das mobile Telefonieren ist bereits zu einer Selbstverständlichkeit geworden. Durch die
enorme Leistungssteigerung der Geräte und die damit verbunden zunehmende Mobilität
der Anwender ergibt sich der Wunsch nach neuen Anwendungen, die dieser Entwicklung
gerecht werden. Anwendungen, welche die geografische Position des Mobiltelefons lokalisieren und Dienste mit Bezug zum aktuellen Standpunkt des Benutzers anbieten
können, werden hierbei eine wichtige Rolle spielen. In diesem Zusammenhang spricht
man von ortsbezogenen Diensten oder Location Based Services (LBS).
Hohe Investitionen, zum Beispiel bei der Einführung der kostspieligen Breitbandnetze
(UMTS) im Jahr 2000, haben auch bei Netzbetreibern hohe Erwartungen an neue
Anwendungen geweckt. Verstärkt wird dies durch die Tatsache, dass der deutsche Mobilfunkmarkt als gesättigt gilt. Hinter mobilen Anwendungen aus den Bereichen Einkaufen,
Werbung, Unterhaltung, etc. verbirgt sich ein gewaltiges Umsatzpotential (vgl. [Koelmel
2002]). Bei der Suche nach Anwendungen mit einem großen Benutzeraufkommen, wie
derzeit beispielsweise der SMS Dienst, sind LBS eines der meist diskutierten Themen.
Heutzutage unterstützen nahezu alle auf dem Markt erhältlichen Mobiltelefone die Programmiersprache Java in der Java 2 Micro Edition (J2ME), wodurch eine plattformunabhängige Implementierung von Anwendungen für das Mobiltelefon ermöglicht wird.
Bereits heute sind viele Spiele für Mobiltelefone in Java programmiert. Diese genießen
insbesondere bei Jugendlichen eine hohe Beliebtheit. Die Möglichkeit, Anwendungen in
eine für viele Entwickler bereits bekannten und objektorientierten Programmiersprache
zu implementieren, fördert zusätzlich die Entwicklung neuer mobiler Anwendungen.
1 Einleitung
-2-
1.2 Ziele der vorliegenden Diplomarbeit
Das Ziel dieser Diplomarbeit ist es, eine exemplarische mobile Anwendung als Location
Based Services (LBS) zu konzipieren und zu implementieren. Konkret soll ein interaktiver
Stadtführer entwickelt werden, der ortsbezogene Informationen zu Sehenswürdigkeiten
in unmittelbarer Umgebung bereitstellt. Geschichtliche oder architektonische Hintergrundinformationen in Form von Texten und Bildern sollen beispielsweise ausgegeben
werden. Das Mobiltelefon muss lokalisiert werden, damit anhand der ermittelten Positionsdaten Informationen zu dem aktuellen Standpunkt ausgegeben werden können. Das
Potenzial von ähnlichen mobilen Diensten soll erörtert werden.
Die Anwendung muss so konzipiert sein, dass verschiedene Systeme zur Lokalisierung
des Mobiltelefones verwendet werden können. Die verschiedenen Lokalisierungssysteme
sollen untersucht und ihre Vor- und Nachteile gegenübergestellt werden. Im Vordergrund
sollen Techniken analysiert werden, die Geräte im Freien lokalisieren.
Es gilt zu klären, was für Möglichkeiten die Programmiersprache Java für die Implementierung mobiler Anwendungen sowie für die Realisierung von Location Based Services
(LBS) bietet. Die darzustellenden Informationen sollen zentral über einen Web Service
bereitgestellt werden. Die mobile Anwendung muss eine Internet-Verbindung zu diesem
Server aufbauen und soll die darzustellenden Informationen über den bereitgestellten
Dienst ermitteln. Von der mobilen Anwendung werden Interaktionsmöglichkeiten sowie
die persistente Speicherung von Einstellungen auf dem Mobiltelefon verlangt.
Der interaktive Stadtführer soll so abstrakt wie möglich entwickelt werden. Die Lokalisierung des Mobiltelefons soll als ein austauschbares Modul gekapselt werden. Die
darzustellenden Informationen müssen von der zugrunde liegenden Technik getrennt
werden. Ziel ist es, die gesamte Anwendung so zu entwickeln, dass diese ein Framework
bildet und nicht nur auf den Nutzen als interaktiver Stadtführer beschränkt ist.
1 Einleitung
-3-
1.3 Aufbau der Diplomarbeit
Diese Diplomarbeit gliedert sich primär in einen theoretischen und einen praktischen Teil.
Im Theorieteil wird auf das Potenzial von Anwendungen auf dem Mobiltelefon eingegangen und die grundlegenden Technologien erläutert. Der praktische Teil zeigt den
Entwurf und die Implementierung des interaktiven Stadtführers.
Im 2. Kapitel wird die Entwicklung des Mobiltelefons und das Potenzial von mobilen
Anwendungen erläutert. Mögliche zukünftige Applikationen werden vorgestellt und unter
bestimmten Gesichtspunkten klassifiziert.
Eine Analyse der verschiedenen Lokalisierungssyteme wird im 3. Kapitel vorgenommen.
Vordergründig wird die Ortung über GPS sowie über die Mobilfunkzelle beschrieben. Zum
Ende des Kapitels werden die unterschiedlichen Systeme bewertet und gegenübergestellt.
Einen Überblick über die Java 2 Micro Edition (J2ME) liefert das 4. Kapitel. Auf die GUIProgrammierung, die persistente Datenhaltung und auf die Kommunikation von J2MEAnwendungen mit Web Services wird eingegangen. Anhand eines Praxisbeispiels wird die
Implementierung einer einfachen Anwendung erläutert.
Das 5. Kapitel beschreibt die erste Phase des Prozesses der Softwareerstellung. Die dem
interaktiven Stadtführer zugrunde liegende Systemidee wird vorgestellt. Des Weiteren
werden die Systemanforderungen sowie die möglichen Anwendungsfälle identifiziert.
Das Design der zu erstellenden Anwendung wird im folgenden Kapitel konzipiert. Dabei
wird die Anwendungsarchitektur beschrieben. Anhand von Klassendiagrammen und
anderen UML-Diagrammen werden die Komponenten des Systems modelliert.
Das 7. Kapitel beschreibt die konkrete Implementierung des interaktiven Stadtführers.
Aufgrund der Komplexität der Anwendung werden nur bestimmte Implementierungsdetails vorgestellt.
Die erzielten Ergebnisse werden im letzten Kapitel zusammengefasst. Das erarbeitete
Design und die Implementierung des interaktiven Stadtführers wird beurteilt. Kritisch bewertet wird die Verwendung der Programmiersprache Java für die Implementierung von
mobilen Anwendungen in Verbindung mit Location Based Services (LBS).
2 Mobile Anwendungen
-4-
2 Mobile Anwendungen
In diesem Kapitel werden mobile Anwendungen und in diesem Zusammenhang Location
Based Services (LBS) definiert. Eine eher inhaltliche und weniger technisch fixierte Betrachtungsweise steht hierbei im Vordergrund. Es wird die rasante Entwicklung des Mobiltelefons und die derzeitige Marktsituation beschrieben. Anschließend werden aktuelle
mobile Java-Anwendungen vorgestellt.
Es wird das Potenzial von mobilen, insbesondere ortsbezogenen Anwendungen analysiert.
Das Spektrum reicht von Applikationen aus den Bereichen „Orientierung“ über „Einkaufen“, „Vergnügung“ bis hin zu „Notfallsystemen“. Anschließend werden diese
Anwendungen unter bestimmten Gesichtspunkten klassifiziert. Am Ende des Kapitels
werden kritische Erfolgsfaktoren erörtert.
2 Mobile Anwendungen
-5-
2.1 Einordnung
2.1.1 Mobile Anwendungen
Der Begriff „Mobile Anwendungen“ beschreibt Anwendungen, die speziell für mobile Endgeräte, wie z.B. Mobiltelefone, Smartphones, PDAs oder auch mobile Kleincomputer wie
Laptops entwickelt wurden. Die Geräte sind klein, räumlich unabhängig und verfügen in
der Regel über kabellose Verbindungen zu anderen Geräten.
Die Entwicklung von Anwendungen für Laptops oder PDAs ist schon lange nicht mehr revolutionär. Hingegen öffnet die Idee, auf einem Mobiltelefon zusätzliche Anwendungen
bereitzustellen, heutzutage ungeahnte Möglichkeiten. Das Mobiltelefon ist klein, kostengünstig und sehr weit verbreitet.
2.1.2 Location Based Services
„Unter Location Based Services (LBS) versteht man ortsgebundene Dienste, die auf den
Aufenthaltsort des Nutzers abgestimmte Informationen liefern“ [Coric 2003].
Internet-Anwender sind bei der Suche nach einem bestimmten Thema häufig überfordert,
die passende Information zu finden. Das Problem liegt meistens nicht darin, dass es
keine Informationen zu dem gesuchten Thema gibt. Vielmehr ist das Auffinden der Informationen durch die Fülle von anderen Informationen erschwert. LBS haben das Ziel,
auf den Standort des mobilen Benutzers zugeschnittene Informationen bereitzustellen.
Durch die Ortung des Endgerätes kann das breite Informationsangebot automatisch individuell nach dem Standort des Benutzers gefiltert werden. Es ist beispielsweise möglich,
nur Informationen zu Hotels in unmittelbarer Nähe anstatt zu allen Hotels in Deutschland
zu übermitteln.
Als Client für die Nutzung von LBS können alle mobilen Endgeräte eingesetzt werden.
Entscheidend ist, dass das Endgerät lokalisiert werden und dadurch der Dienst auf den
Standort des Benutzers abgestimmte Informationen liefern kann.
2 Mobile Anwendungen
-6-
2.2 Bestandsaufnahme
2.2.1 Entwicklung des Mobiltelefons
Als die ersten Mobiltelefone auf den Markt kamen, haben sicherlich die wenigsten Menschen daran gedacht, dass diese Geräte bald anders als wie nur zum Telefonieren genutzt
werden könnten. Die Freiheit, fast überall und ohne kompliziertes Hinzutun zu telefonieren, faszinierte in kürzester Zeit weltweit Milliarden von Menschen. Das Telefonieren
stand für sie im Vordergrund. Doch schon bald entwickelte sich das Mobiltelefon zum
wahren Alleskönner.
Als heutzutage beispiellose Massenanwendung gilt der SMS-Dienst, über den sich Kurznachrichten an andere Telefonteilnehmer verschicken lassen. „In 2005 werden laut Forrester in Westeuropa rund 135 Milliarden solcher Nachrichten verschickt, in fünf Jahren
soll diese Zahl auf über 171 Milliarden ansteigen“ [Heise 2005]. „In Deutschland wurden
2004 nach Angaben des Branchenverbandes VATM 23 Milliarden SMS verschickt (zum
Vergleich: MMS mit 116 Millionen)“ [Wikipedia 2005].
In jüngster Zeit entwickelte sich das Mobiltelefon immer mehr zu einem kombinierten
Multifunktionsgerät mit Funktionen als Telefon, Organizer, Kamera, MP3-Player, Navigationsgerät und Spielkonsole. Für diese Geräte hat sich inzwischen die Bezeichnung
Smartphone durchgesetzt. Insbesondere dadurch bedingt, dass alle aktuellen Mobiltelefone über mehrere der dargestellten Funktionen verfügen, wird heute der Begriff Smartphone häufig mit dem Begriff Mobiltelefon gleichgesetzt. In dieser Diplomarbeit werden
die Bezeichnungen ebenfalls synonym verwendet.
Insbesondere auf Grund der hohen Verbreitung von Smartphones gegenüber anderen
mobilen Endgeräten, wie z.B. PDAs, bezieht sich diese Diplomarbeit hauptsächlich auf
Smartphones oder allgemein auf Mobiltelefone.
2 Mobile Anwendungen
-7-
2.2.2 Aktueller Mobilfunkmarkt
Während heute die meisten aktuellen Mobiltelefone mit Funktionen wie Kamera oder
Spielekonsole ausgestattet sind, gibt es zum Zeitpunkt dieser Diplomarbeit noch kein Mobiltelefon auf dem deutschen Mobilfunkmarkt mit GPS-Empfänger. Dies wird sich spätestens Anfang des Jahres 2006 mit der Markteinführung des UMTS-Mobiltelefons SXG75
von Siemens ändern (vgl. [Golem 2005]). Dieses auf der CeBit 2005 vorgestellte Gerät
verfügt über einen integrierten GPS-Empfänger. Es ist anzunehmen, dass andere Hersteller diesem Trend folgen werden und vergleichbare Geräte auf dem deutschen Mobilfunkmarkt anbieten werden.
„Was man mit modernen Mobiltelefonen alles anfangen kann, machen uns schon seit Jahren die Japaner vor“ [Winter 2004]. In Japan gehört der GPS-Empfänger bereits zur gängigen Ausstattung eines neuen Mobiltelefons, wodurch ganz neue Anwendungen und
Spiele ermöglicht werden (siehe Kapitel 2.4). In Japan wird es ab dem Jahre 2007 zur
Pflicht, alle Mobiltelefone der 3. Generation (UMTS) mit einem GPS-Empfänger auszustatten. Dies dient vor allem der Lokalisierung von Hilfesuchenden im Falle eines Notrufs
(vgl. [Albert 2004]).
Vom Fehlen eines GPS-Empfängers abgesehen, verfügen aktuelle Mobiltelefone auf
dem deutschen Mobilfunkmarkt bereits über
ein breites Spektrum an zusätzlichen
Funktionen. Beispielsweise verfügt das aktuell viel verkaufte Mobiltelefon K750i (siehe Abbildung 1) von Sony Ericsson über
eine 2-Megapixel- Kamera, einen integrierten MP3-Player und einer austauschbaren Speicherkarte. Auch Geräte von
anderen Herstellern, wie z.B. das SGH-E720
von Samsung, das 6230i von Nokia oder
das S75 von Siemens, besitzen ähnliche
Funktionen.
Abbildung 1 Das aktuell viel verkaufte Mobiltelefon Sony Ericsson K750i
2 Mobile Anwendungen
-8-
2.2.3 Derzeitige Java-Anwendungen
Heutige Mobiltelefone stellen einige plattformabhängige Anwendungen bereit. Beispielsweise verfügen alle aktuellen Mobiltelefone über einen Organizer. Durch den Einzug der
Programmiersprache Java auf dem Mobiltelefon ist es darüber hinaus möglich geworden,
plattformunabhängige Anwendungen zu programmieren. Heutzutage ist die Unterstützung der J2ME (Java-Edition speziell für mobile Geräte, siehe Kapitel 4) ein fester
Bestandteil aktueller Mobiltelefone.
Die meisten der heutigen J2ME-Anwendungen sind
Spiele. Das Spektrum reicht von einfach gestalteten
Puzzlespielen bis hin zu aufwendigen Sport-Spielen
oder Flugsimulatoren. Einige dieser Spiele sind bereits beim Kauf des Mobiltelefons installiert, andere
lassen sich über diverse Internet-Portale beziehen. In
dem vielseitigen Angebot findet man Spiele wie „Wer
wird Millionär“ (siehe Abbildung 2), Skat oder Billard.
Spiele, die nicht bereits beim Kauf installiert sind,
lassen sich in der Regel gegen eine Gebühr aus dem
Internet direkt auf das Mobiltelefon herunterladen.
Die eigentliche Installation ist trivial. Heutzutage
genießen Spiele auf dem Mobiltelefon insbesondere
bei Jugendlichen eine hohe Beliebtheit. Java hat sich
bei der Spiele-Programmierung für Mobiltelefone als
ein Quasi-Standard durchgesetzt.
Die J2ME bietet neben der Spiele-Programmierung die
Möglichkeit, mobile Anwendungen zu programmieren,
die einerseits plattformunabhängig sind, andererseits
nahtlos in die grafische Oberfläche des jeweiligen Mo-
Abbildung 2 „Wer wird Millionär“,
Java-Spiel auf dem Mobiltelefon
biltelefons integrieren werden. Einige solcher Anwendungen findet man bereits heute auf
diversen Mobiltelefonen. Beispielsweise ist auf dem Mobiltelefon K750i von Sony Ericsson
eine Java-Anwendung installiert, welche die Welt grafisch mit den verschiedenen
Zeitzonen und aktuellen Uhrzeiten darstellt. Trotz der umfangreichen Möglichkeiten die
Java für die Programmierung von mobilen Anwendungen bietet, gibt es bis heutzutage,
von den Java-Spielen abgesehen, nur wenige andere Anwendungen.
2 Mobile Anwendungen
-9-
2.3 Abschätzung des Potenzials
2.3.1 Wirtschaftliches Potenzial
Der Mobilfunk ist eine der dynamischsten Branchen. In kaum einem anderen Wirtschaftszweig kommen neue Produkte schneller auf den Markt und sind die Innovationszyklen
kürzer. Die Menschen werden mobiler und mit ihnen die Kommunikation. Erreichbarkeit
überall und zu jeder Zeit kennzeichnet unseren Alltag. „Längst übersteigt die Zahl der
Mobilfunkteilnehmer die der Festnetzanschlüsse. Über 71 Millionen Mobilfunk-Nutzer gibt
es derzeit in Deutschland, noch vor zehn Jahren waren es weniger als vier Millionen. Parallel zu den Nutzer-Zahlen steigen auch die Umsätze. Der Gesamtumsatz der Branche hat
sich seit 1995 fast verzwanzigfacht. 2004 erzielte die Mobilfunkbranche einen Gesamtumsatz von 22,1 Milliarden Euro“ [IZMF 2005].
Das wirtschaftliche Potential von mobilen Diensten wie Location Based Services (LBS) ist
schwer abzuschätzen. Durch den Bezug der Informationen zu dem jeweiligen Ort ist die
Entwicklung von ganz neuen innovativen Anwendungen möglich. Nicht ohne Grund sprechen Experten davon, dass sich hinter Anwendungen aus dem Bereich mobiles Einkaufen,
mobile Werbung, mobile Unterhaltung etc. ein gewaltiges Umsatzpotential verbirgt (vgl.
[Bager 2002], [Koelmel 2002]).
LBS profitieren stark von der ständigen erweiterten Kommunikationsinfrastruktur, da sie
damit von überall auf große Datenbestände zugreifen können. Die UMTS-Lizenzversteigerungen im Jahr 2000 haben damit die Netzanbieter zu visionären Versprechungen über
mögliche Dienste verleitet und somit zu einer regelrechten Euphorie um die ortsbezogenen Dienste geführt. Nachdem sich dieser Anflug von Begeisterung gelegt hat, ist es an
der Zeit, über realisierbare Dienste nachzudenken.
2 Mobile Anwendungen
- 10 -
2.3.2 Erwartungen der Nutzer
Location Based Services (LBS) gelten als neue innovative Anwendungen, jedoch ist der
derzeitige Nutzen solcher Dienste noch als gering einzuschätzen (vgl. [Koelmel 2002],
[Theisen 2002]). Um erfolgreich neue Anwendungen auf dem Markt zu etablieren, ist die
Analyse der Erwartung der Mobilfunk-Nutzer an diese Dienste von einer um so größeren
Bedeutung.
„The Boston Consulting Group“ führte im November 2000 eine umfangreiche Studie in
den USA, Japan, Deutschland, Frankreich, Schweden und Australien durch. Es wurden
insgesamt 1800 Anwender befragt. Auch wenn diese Studie bereits ein paar Jahre zurückliegt, ist das Ergebnis, die Aufzeichnung der Motivation zur Nutzung mobiler Dienste,
auch noch heute aussagekräftig.
Motivation
Anteil der Nennung
1 Zeit sparen
84%
2 in Echtzeit auf aktuelle Informationen zugreifen
83%
3 einfach und effizienter kommunizieren
81%
4 Kontakt zu Familie und Freunden halten
74%
5 Sicherheit in Notsituationen haben
71%
6 über niedrige Preise / Sonderangebote informiert sein
54%
7 Spass haben
53%
8 den PC für bestimmte Aufgaben ersetzen
53%
9 bestimmte Anwendungen nutzen
49%
10 Neugierde
47%
11 Zeitvertreib (engl. kill time)
37%
12 neue Freunde kennen lernen
25%
Tabelle 1 Motivation zur Nutzung mobiler Dienste, Ergebnisse einer Studie
(vgl. [Koelmel 2002])
Andere Studien untersuchen das Interesse an konkreten mobilen Diensten. Die „Forresters Consumer Technograhpics Studie“ (September 2000) befragte 8000 MobilfunkNutzer nach ihren Interessen an mobilen Diensten. Bei dieser Studie wird deutlich, dass
ein großes Interesse an ortsbezogenen mobilen Diensten besteht. Eine Online-Umfrage
von Yellowmap aus dem Jahre 2002 mit 479 Befragten zeigt, dass 83% der Teilnehmenden an einem Preisvergleich im Ortsbezug, 82% an einer City-Navigation, 78%
an einem Parkplatz-Finder und 65% an Buddy-Finder interessiert sind (vgl. [Koelmel
2002]).
2 Mobile Anwendungen
- 11 -
2.4 Mögliche Anwendungen
2.4.1 Bereich „Orientierung“
Aufgrund des Vorhandenseins der Ortsinformationen lassen sich eine ganze Reihe von
Diensten entwickeln, die nahe liegende Objekte auflisten und den Benutzer über ein integriertes Navigationssystem zur einer bestimmten Stelle leiten. Diese Dienste würden
dem Benutzer helfen, sich in einer womöglich fremden Stadt zu orientieren. Vorstellbar
sind in diesem Zusammenhang Anwendungen, die den nächsten freien Parkplatz oder
Geldautomaten anzeigen, Hotels oder Restaurants in der unmittelbaren Umgebung auflisten oder eine Karte mit dem aktuellen Standpunkt des Benutzers liefern würden.
Ein etwas komplizierter zu realisierender Dienst ist ein Stau-Frühwarnsystem. Der
Benutzer würde sich beim Losfahren an einem entfernten Server anmelden. In regelmäßigen Zeitabständen würde die aktuelle Position des Fahrers ermittelt werden. Der Server
würde erkennen, dass der Fahrer sich auf einen Stau zubewegt und würde eine Warnmeldung und einen Vorschlag, wie dieser Stau umfahren werden könnte, senden.
Während die bis jetzt vorgestellten Systeme sich auf eine Lokalisierung außerhalb von
Gebäuden bezogen, sind auch Dienste innerhalb von Gebäuden denkbar. In diesem Zusammenhang spricht man oft von einer Indoor-Lokalisierung. In großen Gebäuden, wie
z.B. Museen, Messehallen oder in Einkaufszentren, kann ein mobiler Dienst dem
Anwender bei der Orientierung helfen. Findet ein Anwender in einem Supermarkt ein bestimmtes Produkt nicht, könnte ihm das Mobiltelefon bei der Suche nach dem entsprechenden Regal weiterhelfen. Ein Messebesucher fände den gesuchten Ausstellungsstand
über die auf seinem mobilen Endgerät angezeigte Karte bzw. liesse sich womöglich sogar
über die Sprachsteuerung an den Stand lotsen.
2.4.2 Bereich „Einkaufen“
Ein auch für die Wirtschaft sehr wichtiger Anwendungsbereich ist das mobile Einkaufen
(engl. Shopping). Ein mobiler Anwender könnte sich mit Hilfe seines Mobiltelefons über
spezielle Sonderangebote informieren. Auf diesem Weg könnte eine nahe liegende und
billige Tankstelle ausfindig gemacht werden. Ein anderer Dienst könnte die am Wochenende bzw. nachts geöffnete Notfall-Apotheke anzeigen.
Mobile Werbung steht im engen Zusammenhang mit dem mobilen Einkaufen. Supermärkte könnten z.B. eine Anwendung bereitstellen, die Einkäufern mit Mobiltelefonen
aktuelle Sonderangebote beim Betreten des Marktes mitteilen würden.
2 Mobile Anwendungen
- 12 -
2.4.3 Bereich „Vergnügung“
In unserer heutigen Gesellschaft hat das Vergnügen und der Spass einen hohen Stellenwert. Betrachtet man das Mobiltelefon aus privater Sicht, so gibt es wohl nur sehr wenige
Fälle (z.B. bei kranken Menschen), wo das Telefon wirklich überlebenswichtig ist. Trotzdem gibt es in unserer Gesellschaft nur wenige Menschen, die auf diese Mobilität verzichten möchten. Das Mobiltelefon macht unsere Gesellschaft spontaner und dadurch unkomplizierter. Wie bereits unter 2.3.2 dargestellt, sind gerade dies auch Merkmale, die von
mobilen Diensten gefordert werden. Insofern ist es nicht verwunderlich, dass eine ganze
Menge von möglichen Anwendungen aus dem Bereich „Vergnügung“ vorstellbar sind.
Auf der einen Seite sind einfache Dienste, wie z.B. die Darstellung des Kinoprogramms,
Informationen über Veranstaltungen (engl. Events) oder die Auflistung der Öffnungszeiten der Stamm-Kneipe möglich. Andererseits lassen sich komplexere Systeme, wie
z.B. ein interaktiver Stadtführer (engl. City-Guide), konzipieren. In dieser Diplomarbeit
wird ein solches System entworfen (siehe Kapitel 5 und 6) und die Implementierung
vorgestellt (siehe Kapitel 7).
Eine ganz andere Anwendung ist ein Dating-Service. Frisch kennengelernte Pärchen
könnten über das Mobiltelefon nicht nur ihre Vorlieben austauschen, sondern zugleich
eine Meldung auf dem Mobiltelefon erhalten, wenn sich ihre Traumperson gerade in ihrer
Nähe befände. Ein ähnliches Szenario stellt ein Buddy-Finder (zu deutsch: KumpelFinder) dar. Registrierte, sich in der Nähe befindende Freunde könnte über das System
auf dem Display angezeigt oder zu einem spontanen Treffen eingeladen werden.
Die Japaner zeigen mit dem „Mogi-Spiel“ das Potenzial von ortsbezogenen MobiltelefonSpielen. Die Spielidee ist relativ einfach: „Auf dem Display ihres Mobiltelefons sind bunte
Objekte auf einem vereinfachten Stadtplan der japanischen Hauptstadt zu sehen. Das
Ziel des Spiels ist es, bestimmte über die Stadt verteilte Schätze einzusammeln. Natürlich sind diese Kostbarkeiten rein virtuell. Kommt ein Mitspieler in die Funkzelle, in der
sich das betreffende Objekt befinden soll, gilt es als eingesammelt und ändert die Farbe.
Dem Sammler werden dafür Punkte gutgeschrieben“ [Winter 2004]. Zusätzlich kann man
das Spielgeschehen über das Internet verfolgen und Teams bilden. „Seit diese Mischung
aus elektronischem Quartett und virtueller Schnitzeljagd vor einem Jahr gestartet ist
(Stand 2004), verfallen nun immer mehr Mobilisten dem Mogi-Fieber. Experten sagen
dieser Spiel-Spezies eine große Zukunft voraus“ [Winter 2004].
2 Mobile Anwendungen
- 13 -
2.4.4 Bereich „Sicherheit und Notfälle“
Viele Anwender sehen das Mobiltelefon als wichtigen Begleiter für Notfälle. Bedingt durch
die Mobilität lässt sich in einer Notfallsituation, wie z.B. ein Autounfall, schnell Hilfe anfordern. Durch die Ortung des Mobiltelefons kann der Helfende die Position des Hilferufenden ohne dessen direkte Mithilfe ausfindig machen. Vorstellbar wären in diesem Zusammenhang ein im Auto integriertes Endgerät, dass einen Alarm an die Notrufzentrale
auslöst, wenn das Auto in einen Unfall verwickelt ist (z.B. Airbags wurden ausgelöst) und
der Anwender auf die Aufforderung der Anwendung nicht reagiert. Mit ähnlichen Mitteln
könnte ein gestohlenes Auto lokalisiert werden.
Eine andere denkbare Anwendung wäre ein Notfall-System für Lawinen-Opfer. Bevor ein
Skifahrer losfährt, würde sich dieser mit seinem Mobiltelefon an einem Servicecenter registrieren lassen. Im Falle einer Lawine würden automatisch die Positionen der registrierten Skifahrer abgefragt werden. Befände sich eine Person im Lawinengebiet, würde
versucht werden, Kontakt zu dieser Person aufzunehmen. Wäre dies nicht möglich, könnte gezielt nach dieser Person über die Ortung des Mobiltelefons gesucht werden.
Die Nachverfolgung (engl. Tracking) einer Person über die regelmäßige Ortung des Mobiltelefons ist einerseits aus personenrechtlichen Gründen fraglich. Andererseits bietet die
Nachverfolgung ein weiteres Anwendungsgebiet, über das in Zukunft zu diskutieren gilt.
Beispielsweise wäre es technisch durchaus möglich, eine passwortgeschützte InternetAnwendung zu entwickeln, die die Position des Partners grafisch darstellt. Fährt dieser
z.B. auf der A7 von Hamburg nach Fulda, könnte der Partner im Internet genau sehen,
wann sein Partner losgefahren ist und wann und wo er sich befände. Mit ähnlichen Mitteln
sind Anwendungen möglich, die z.B. kranke oder orientierungslose Menschen orten.
Ängstliche Eltern könnten ihr Kind schnell wiederfinden, wenn sie über die Ortung des
Mobiltelefons Informationen über den aktuellen Standort ihres Kindes erhalten würden.
Desweiteren sind eine ganze Reihe von Anwendungen im Katastrophenschutz denkbar.
Einsatzleiter könnten über die Position der Hilfskräfte informiert sein und dadurch gezielter den Einsatz koordinieren. Helfenden könnte über das Display des Mobiltelefons
der nächste Strom- oder Wasseranschluss angezeigt werden. Auch zur geografischen
Orientierung könnten die kleinen Geräte benutzt werden. Zu beachten ist, dass für solche
Dienste die Infrastruktur des Mobilfunks intakt sein muss. Ein hervorragend durchdachtes
System hilft nicht, wenn in der Notsituation keine mobile Übertragung mehr möglich ist.
2 Mobile Anwendungen
- 14 -
2.4.5 Sonstige Anwendungen
Eine ganze Reihe von Anwendungen sind vorstellbar, die sich nicht in die vorgestellten
Kategorien einordnen lassen. Einige dieser Ideen werden nachfolgend kurz vorgestellt.
Im Geschäftsbereich ist ein Dienst denkbar, der einen Ausdruck von einem Notebook oder
einem anderen mobilen Gerät automatisch auf den nahe liegensten Drucker weiterleiten
würde. Im Industriebereich sind sehr spezielle Anwendungen vorstellbar, die z.B. positionsabhängig einen Roboter fernsteuern.
Im privaten Bereich ist der „HandyFinder“ zu nennen. Diesen Dienst bietet
der deutsche Mobilfunkanbieter O2 an.
Verlegt der Kunde sein Mobiltelefon,
kann er das eingeschaltete Gerät über
das „O2-Active-Portal“ wiederfinden.
Das Mobiltelefon wird über die Mobilfunkzelle lokalisiert. Der gefundene Ort
wird für den Kunden grafisch dargestellt (siehe Abbildung 3). Auf die Genauigkeit einer solchen Ortung wird im
Kapitel 3.2 detailiert eingegangen.
Neben den ortsbezogenen Diensten gibt
es selbstverständlich Anwendungen, die
ohne Lokalisierung auskommen. Einige
Abbildung 3 „Handy-Finder“, Anwendung zum
Wiederfinden des Mobiltelefons von O2
(entnommen aus dem O2-Active-Portal)
von diesen Anwendungen sind reine Standalone-Anwendungen. Beispiele hierfür sind die
bereits heute viel verbreiteten Spiele auf dem Mobiltelefon. Denkbar wären
Anwendungen, die z.B. Auskunft über Bahnverbindungen oder Buslinien geben könnten.
Natürlich lassen sich solche Dienste durch den Ortsbezug veredeln. Eine Anwendung
muss ohne Ortsbezug z.B. nach dem Abfahrtort fragen, während eine Anwendung mit
Ortskenntnissen diese automatisch herausfinden kann.
Andere Beispiele für mögliche mobile Anwendungen ohne Ortsbezug sind: das Anzeigen
von Kontoauszügen, die Darstellung aktueller Börsenkurse, Nachrichten oder Fernsehen
auf dem Mobiltelefon.
2 Mobile Anwendungen
- 15 -
2.5 Klassifizierung mobiler Anwendungen
2.5.1 Anforderungen und Klassifizierung
Location Based Services (LBS) beschreiben ein breites Feld von ortsbezogenen Diensten
mit stark unterschiedlichem Informationsbedarf. Im vorigen Abschnitt wurde eine Einteilung nach verschiedenen Anwendungsbereichen vorgenommen. Im Folgenden wird eine
Klassifizierung durchgeführt, die sich auf technische Anforderungen bezieht. In der Diplomarbeit „Location Server“ [Roeder 2004] werden Anforderungen an LBS unter den in
der Abbildung 4 dargestellten Gesichtspunkten beschrieben.
Abdeckung
Genauigkeit
global
hoch
lokal
gering
absolut
symbolisch
relativ
Darstellung
des Ortes
Abbildung 4 Generelle Anforderungen an Location Based Services (LBS)
(vgl. [Roeder 2004])
Die Genauigkeit der Positionsermittlung ist insbesondere im Hinblick auf das einzusetzende Lokalisierungssystem (siehe Kapitel 3) von großer Bedeutung. Um z.B. den
Autofahrer an das richtige Ziel zu leiten, benötigt ein Navigationssystem genaue Positionsangaben. Ein System das ortsbezogene Werbung übermittelt, stellt hingegen geringe
Anforderungen an die Genauigkeit der Positionsangaben. Systeme, die global oder nur lokal agieren, sind zu unterscheiden. Ein interaktiver Museumsführer ist nur auf bestimmte
Räume beschränkt, während ein ortsbezogenes Notfallsystem global agiert. Die Darstellung des Ortes kann absolut, symbolisch oder relativ zu einem Bezugspunkt geschehen.
Für das erwähnte Notfallsystem ist die absolute Position eines Benutzers wichtig. Ein System, was Freunde im näheren Umkreis zeigt, arbeitet eher mit relativen, ein interaktiver
Stadtführer hingegen mit symbolischen Ortsangaben.
2 Mobile Anwendungen
- 16 -
2.5.2 Klassifizierung der möglichen Anwendungen
Die Tabelle 2 beschreibt die Merkmale der in diesem Kapitel vorgestellten möglichen mobilen Anwendungen. Die angegebene Genauigkeit der Positionsbestimmung sowie die
anderen aufgezeigten Kriterien sind als eine mögliche Interpretation der Anwendungsdefinition zu verstehen. Sie gelten nicht als festes Kriterium für die Entwicklung solcher
Anwendungen.
Anwendung
Genauigkeit Posi- Abdeckung Positionsermittlung
tionsermittlung
Darstellung
des Ortes
Navigationssystem
sehr hoch (< 20m)
global
absolut
Finder (Parkplatz, Geldautomat, Hotels, Restaurants)
hoch (< 50m)
global (in Städten) relativ
Stau-Frühwarnsystem
niedrig (< 500m)
global
absolut
Leitsystem (Museen, Messen,
Einkaufszentren)
sehr hoch (< 1m)
lokal (Indoor)
relativ
Shopping (Tankstelle, NotfallApotheke)
hoch (< 50m)
global (in Städten) relativ
Werbung (Sonderangebote)
mittel (< 100m)
lokal
absolut
Events (Kino, Veranstaltungen, niedrig (< 1km)
Öffnungszeiten Kneipe)
global
symbolisch
Interaktiver Stadtführer
hoch (< 50m)
global (in Städten) symbolisch
Dating-System oder BuddyFinder
hoch (< 50m)
global
relativ
LBS-Spiele (Mogi-Spiel)
mittel (< 100m)
lokal oder global
absolut
Notruf (Autounfall)
mittel (< 200m)
global
absolut
Lawinen-Überwachung
hoch (< 50m)
global
absolut
Nachverfolgung (Partner,
kranke Menschen, Kinder)
mittel (< 300m)
global
absolut
Katastrophenschutz (Strom-, hoch (< 50m)
Wasseranschluss)
global
relativ
Druckerauswahl
sehr hoch (< 5m)
lokal (Indoor)
relativ
Robotersteuerung
sehr hoch (< 1m)
lokal (ggf. Indoor)
relativ
Handy-Finder
mittel (< 300m)
global
absolut
Auskunft (Bahn-, Busfahrplan) mittel (< 200m)
global
relativ
Tabelle 2 Klassifizierung der vorgestellten möglicher mobilen Anwendungen
2 Mobile Anwendungen
- 17 -
2.6 Kritische Erfolgsfaktoren
2.6.1 Technische Faktoren
Im Kapitel 3 werden die unterschiedlichen Lokalisierungssysteme detailiert beleuchtet.
Vorgreifend ist zu sagen, dass es kein Lokalisierungssystem gibt, das alle Anforderungen
an die Lokalisierung ausreichend erfüllt. Einige der vorgestellten Dienste verlangen eine
sehr genaue Lokalisierung, die außerhalb von Gebäuden nur mit GPS ermöglicht werden
kann. Jedoch sind GPS-Empfänger in den heute auf dem deutschen Mobilfunkmarkt
erhältlichen Mobiltelefonen noch nicht integriert. Attraktive Endgeräte können in Zukunft
die Nutzung der Dienste nachhaltig fördern.
Für die Entwicklung innovativer Anwendungen sind Standards sowie eine plattform- und
betreiberunabhängige Implementierung notwendig. Nur unter diesen Voraussetzungen ist
eine hohe Verbreitung und der damit verbundene Erfolg neuer Anwendung möglich.
„Allerdings bedeutet für viele Mobilfunkbetreiber das Heranlassen an Daten auch Verlust
von Kunden, also halten sie ihre Netze „geschlossen“ und versuchen sich durch die nur in
ihrem Netz verfügbaren Dienste gegenseitig Kunden abzuwerben“ [Coric 2003].
2.6.2 Kundenspezifische Faktoren
Das Kundenverhalten ist nur sehr schwer berechenbar. Für den Anwender wird die einfache Handhabung und die schnell zu erzielenden Vorteile ortsbezogener Dienste eine
wichtige Rolle spielen. Entsprechend einfach muss die Bereitstellung und die Installation
neuer Anwendungen gestaltet werden.
Damit ortsbezogene Dienste ihren Markterfolg erreichen, müssen Mobilfunkbetreiber
einfache Abrechnungsmodelle (z.B. Flatrate für die Datenübertragung) dem Kunden anbieten. Schließlich wird die Neugierde und das Interesse an diesen innovativen
Anwendungen die Kunden langfristig binden. Die Einnahmen durch die Übertragung der
Datenpakete wird den Betreibern zum gewünschten Umsatz verhelfen.
3 Lokalisierungssysteme
- 18 -
3 Lokalisierungssysteme
In diesem Kapitel werden eine Vielzahl von satellitengestützten und zellenbasierten Lokalisierungssystemen vorgestellt. Vordergründig wird die Ortung über GPS sowie über die
Mobilfunkzelle beschrieben. Auf eine konkrete Implementierung der Anbindung von GPS
mit Hilfe der Programmiersprache Java wird im Kapitel 7.3.3 eingegangen.
Dieses Kapitel beschreibt die Grundlagen der Lokalisierung und stellt die derzeit verfügbaren Systeme gegenüber. Keines der Systeme erfüllt alle Anforderungen, der im vorigen
Kapitel vorgestellten möglichen Dienste. Dafür ergänzen sich die Systeme in ihren Attributen, weshalb eine genaue Betrachtungsweise für die Auswahl des jeweils einzusetzenden Lokalisierungssystems notwendig ist.
3 Lokalisierungssysteme
- 19 -
3.1 Satellitengestützte Systeme
Eine Kategorie von Lokalisierungssystemem benutzt Satelliten zur Positionsbestimmung.
„Ist die Position mehrerer Satelliten und der Abstand zu ihnen zu einem bestimmten Zeitpunkt bekannt, lässt sich die Position äußerst präzise bestimmen. Einer der weiteren Vorteile der satellitengestützten Lokalisierungssysteme ist die breite Verfügbarkeit“ [Fleuren
2004]. Nachteilig ist, dass die Lokalisierung abhängig von einer Sichtverbindung zu den
Satelliten ist. Aus diesem Grund scheidet die Technik für die Lokalisierung innerhalb von
Gebäuden (auch als Indoor-Lokalisierung bezeichnet) aus. In diesem Abschnitt werden
die Systeme GPS und dessen Weiterentwicklungen sowie das noch in der Entwicklung befindliche GALILEO, vorgestellt.
3.1.1 Global Positioning System (GPS)
„Das Global Positioning System (GPS) ist das am häufigsten genutzte Positionierungsund Navigationssystem der Welt. Es wurde vom US-Verteidigungsministerium für das
Militär in Auftrag gegeben, hat ungefähr zwölf Milliarden US-Dollar gekostet und kann
seit 1998 weltweit genutzt werden. Der offizielle Name ist NAVSTAR (Abkürzung für Navigation Satellite Timing and Ranging)“ [Fleuren 2004].
GPS besteht aus insgesamt drei Segmenten (vgl. [Panitzki 2005]):
 Das Raumsegment besteht aus 24 sta-
tionären Satelliten auf sechs Umlaufbahnen. Auf jeder Bahn bewegen sich
vier Satelliten (siehe Abbildung 5). Jeder
Satellit umrundet in einer Höhe von
20.200 km alle 12 Stunden die Erde. Die
Umlaufbahnen sind so angeordnet, dass
von jedem Punkt der Erde Sichtkontakt
zu mindestens 4-6 Satelliten besteht. Jeder Satellit verfügt über Hilfsraketen, mit
denen die Umlaufbahn gegebenenfalls
korrigiert werden kann.
Abbildung 5 Konstellation der 24 Satelliten
auf den sechs Umlaufbahnen beim GPS
[TU Ilmenau 2005]
3 Lokalisierungssysteme
- 20 -
 Das Kontrollsegment besteht aus dem US Space Command in Colorado Springs sowie
aus fünf Bodenstationen von wo aus die Satelliten beobachtet und kontrolliert werden.
Gegebenenfalls werden die Bahnen der Satelliten korrigiert oder Updates durchgeführt.
 Das Benutzersegment besteht aus GPS Empfangsgerä-
ten, die aus den ausgestrahlten Signalen der Satelliten
ihre momentane Position errechnen. Eine GPS-Maus ist
ein solches Gerät. Gegenüber aufwendigeren GPS-Receivern verfügen GPS-Mäuse weder über zusätzliche Software noch über ein Display zur Anzeige der Position. Die
Mäuse übertragen die aktuell ermittelten Positionsdaten
über z.B. Bluetooth an andere Geräte. Ein solches Empfangsgerät ist in Abbildung 6 dargestellt.
Abbildung 6 GPS-Maus „Holux GR-230“, Beispiel für
ein GPS-Empfangsgerät
Das bei GPS angewandte Ortungsverfahren beruht auf dem Prinzip der Entfernungsbestimmung durch Messung der Laufzeit von Signalen. Jeder Satellit sendet laufend ein Datenpaket aus, das die Sendezeit und die augenblickliche Position des Satelliten enthält.
Der Empfänger auf der Erde bestimmt die Ankunftszeit des Signals. Aus der bekannten
Ausbreitungsgeschwindigkeit c = 300m/ms und der ermittelten Laufzeit t des Signals
lässt sich die Entfernung R zum Satelliten berechnen: R = c x t (vgl. [Panitzki 2005] und
[Abel 2005]).
Mit drei solcher Messungen zu verschiedenen Satelliten kann man die Position
des Empfängers im dreidimensionalen
Raum bestimmen. Vom jeweiligen Satelliten aus gesehen befindet sich der Empfänger auf der Oberfläche einer Kugel, deren Radius gerade über die Signallaufzeit
bestimmt wurde. Zwei solcher Kugeloberflächen schneiden sich in einem Kreis, der
wiederum die dritte Kugeloberfläche in
einem Punkt schneidet. Die Abbildung 7
verdeutlicht diese Zusammenhänge (vgl.
[Panitzki 2005] und [Abel 2005]).
Abbildung 7 Idealisierte Visualisierung des
im GPS eingesetzten Ortungsverfahrens
[Panitzki 2005]
3 Lokalisierungssysteme
- 21 -
In der vorigen Erklärung wurde das Ortungsverfahren vereinfacht und idealisiert dargestellt. In Wirklichkeit lässt sich die gesuchte Position nicht punktgenau bestimmen. Der
Grund hierfür ist die extrem hohe Anforderung an die Zeitmessung, die für die Entfernungsbestimmung zu den Satelliten notwendig ist. Die Signale werden mit Lichtgeschwindigkeit (ca. 300 m/ms) übertragen. Die Laufzeit beträgt nur zwischen 0,067 und
0.086 Sekunden. „Ein Laufzeitfehler von einer tausendstel Sekunde würde einen Distanzfehler von 300 km bewirken und damit das System unbrauchbar machen. Die erforderliche Präzision lässt sich nur mit Atomuhren erreichen. An Bord der Satelliten werden daher Cäsium- und Rubidiumatomuhren verwendet, die regelmäßig von den Bodenstationen
kontrolliert und nachgeregelt werden“ [Abel 2005]. Prinzipiell benötigt man im Empfänger die gleiche Genauigkeit. Der Einsatz von Atomuhren im Empfangsgerät ist jedoch
zu kostspielig.
Wie in Abbildung 8 dargestellt, bilden die kugelförmigen Ausbreitungswellen auf Grund
der Laufzeitfehler in der Regel keinen gemeinsamen Schnittpunkt, sondern eine Dreieck.
Da der Messfehler auf der Ungenauigkeit der Empfängeruhr beruht ist der Fehler bei allen
Entfernungsmessungen gleich groß. Durch Mittelwertberechnungen wird der Messfehler
reduziert. Fundierte mathematische Informationen sind aus den Quellen [Abel 2005] und
[TU Ilmenau 2005] zu entnehmen. Für diese Berechnungen ist ein weiterer Bezugspunkt
und somit ein Sichtkontakt zu einem weiteren Satellit notwendig (vgl. [Panitzki 2005]).
Abbildung 8 Grafische Darstellung der Auswirkung von Laufzeitfehlern beim GPS
(vgl. [Panitzki 2005])
Sofern der Sichtkontakt zu mindestens vier Satelliten (Normalfall) besteht, ermöglicht
GPS eine weltweite Positionsbestimmung (geographische Länge, Breite und Höhe) und
Zeitinformation mit bisher unerreichter Genauigkeit (vgl. [TU Ilmenau 2005]). Die Radiosignale können Wolken, Glas und Kunstoff durchdringen, aber keine soliden Hindernisse,
wie Häuser oder Berge. Die Genauigkeit der Positionsbestimmung beträgt ca. 15 Meter.
3 Lokalisierungssysteme
- 22 -
3.1.2 DGPS
Differential Global Positioning System (DGPS) ist eine Bezeichnung für Verfahren, die
mehrere GPS-Empfänger zur Erhöhung der Genauigkeit verwenden. Bei dem Verfahren
gibt es einen Empfänger, dessen Position bestimmt werden soll und mindestens einen
weiteren Empfänger, dessen Position bekannt ist (GPS-Basisstation). Ein solcher Aufbau
ist in Abbildung 9 dargestellt.
Eine Basisstation kann diverse Informationen über die Ursachen ermitteln, z.B. warum
die mittels GPS bestimmte Position fehlerhaft ist, da deren Position bekannt ist. Mit
diesen Informationen (Korrekturdaten) von einer Basisstation kann die Genauigkeit der
Positionsdaten des zu ortenden Empfängers erhöht werden. Die erreichbare Genauigkeit
ist u.a. vom Abstand zwischen dem mobilem Empfänger und der Basisstation abhängig.
Durch das beschriebene Verfahren sind Genauigkeiten von unter einem Meter möglich.
gesuchte
Position
genau bekannte
Position
Abbildung 9 Funktionsweise von Differential GPS, einer Weiterentwicklung von GPS
[TU Ilmenau 2005]
3 Lokalisierungssysteme
- 23 -
3.1.3 AGPS
GPS verfügt über eine hohe Genauigkeit in der Positionsbestimmung. Nachteilig ist, dass
die Zeit, die bis zu einer ersten Positionsbestimmung vergeht, mit 30-60 Sekunden, im
schlimmsten Fall mehreren Minuten, relativ lang ist. Außerdem sind in geschlossenen
Räumen und in städtischer Umgebung die Satellitensignale so schwach, dass sie nicht detektiert werden können. Der Stromverbrauch des GPS-Empfängers ist relativ hoch.
„A-GPS (Assisted-GPS) verringert diese Probleme, indem es das Mobilfunknetz dazu
benutzt, dem Empfänger Hilfsdaten zu übermitteln. Beim konventionellen GPS hat der
Empfänger zwei Aufgaben. Er misst die Ankunftszeit der Signale und er liest die von den
Satelliten gesendeten Daten, die u.a. Bahnparameter und Fehlerkorrekturen enthalten.
Beim A-GPS werden die Satellitendaten von Referenzempfängern gelesen, die an Orten
mit guter Sicht zum Himmel aufgestellt sind, so dass der mobile Empfänger nur die
Ankunftszeiten messen muss. Außerdem ist anhand der Funkzelle, die das Mobiltelefon
bedient, der ungefähre Ort bekannt. Dieser wird verwendet, um den Suchbereich für die
Satellitensignale (Identität der sichtbaren Satelliten, ungefähre Ankunftszeit, Doppelverschiebung) einzuschränken und somit die Messung zu beschleunigen“ [Wikipedia 2005].
3.1.4 GALILEO
„GALILEO ist ein unabhängiges ziviles europäisches globales Satellitennavigations- und
Zeitgebungssystem“ [Rat der EU 2005]. GALILEO ist für zivile Zwecke konzipiert und unterliegt nicht, wie das amerikanische GPS und das russische GLONASS, einer nationalen
militärischen Kontrolle. Auf GLONASS wird in dieser Diplomarbeit nicht weiter eingegangen, das technische Grundprinzip unterscheidet sich wenig vom GPS, eine zivile
Nutzung des russischen Systems ist nicht vorgesehen. „Im Rahmen von GALILEO sind ein
oder mehrere Dienste für offene, kommerzielle, sicherheitskritische Such- und Rettungszwecke vorgesehen“ [TU Ilmenau 2005].
„Der erste Testsatellit startet im Dezember 2005. Der Probebetrieb mit vier Satelliten ist
für 2008 vorgesehen, 2010/11 soll das System mit allen 30 Satelliten verfügbar sein.
Verfügbarkeit und Integrität sind die Schlüsselkriterien, die GALILEO im Gegensatz zu
GPS ausnahmslos erfüllen soll, um auch für sicherheitskritische Anwendungen eingesetzt
werden zu können“ [Wikipedia 2005].
3 Lokalisierungssysteme
- 24 -
3.2 Zellenbasierte Systeme
Für den Netzbetreiber ist es möglich, die Position eines Mobilfunkteilnehmers festzustellen, da dessen Mobiltelefon im ständigen Kontakt zu den Basisstationen steht. Im
Folgenden wird auf die unterschiedlichen Mobilfunknetze und die Lokalisierung über die
Mobilfunkzelle eingegangen. Darüber hinaus wird die Lokalisierung von Endgeräten über
WLAN und Bluetooth vorgestellt.
3.2.1 GSM/GPRS-Netze
Das Global System for Mobile Communications (GSM) ist der weltweit am meisten verbreitete Mobilfunk-Standard. In Deutschland ist GSM die technische Grundlage der Dund E-Netze. Die Struktur der Mobilfunknetze nach GSM zeigt die Abbildung 10. Jede
Zelle im Funkzugangsnetz (engl. Radio Access Network) enthält eine Basisstation, die als
BST bezeichnet wird. Mehrere BST, die im Frequenzbereich von 900 MHz bzw. von 1800
MHz arbeiten, werden an einen Kontroller BSC angeschlossen, über den sie einen Zugang
zu einer Vermittlungsstelle MSC im Kernnetz (engl. Core Network) haben. Zu den Aufgaben von BSC gehören die Steuerung und Kontrolle der Funk-Ressourcen von BTSs und
die Herstellung von Verbindungen zu einer Vermittlungsstelle MSC (vgl. [Badach 2005]).
Abbildung 10 Struktur der Mobilfunknetze nach GSM (Funkzugangs- und Kernnetz)
(vgl. [Badach 2005])
AC: Authentication Center, BSC: Base Station Controller, BTS: Base Transceiver Station, EIR: Equipment
Identication Register, HLR: Home Location Register, GMSC: Gateway MSC, MS: Mobile Station, MSC: Message Switching Center, RAN: Radio Access Network, VLR: Visitor Location Register
3 Lokalisierungssysteme
- 25 -
Damit ein mobiles Telefonieren möglich ist, verfügt das Kernnetz über einige
Komponenten, die jedoch für die Lokalisierung eines Mobiltelefons irrelevant sind. Diese
Komponenten, die konkret die Register EIR und HLR sowie das AC und das GMSC sind,
werden in der Abbildung 10 nur vollständigkeitshalber dargestellt. Eine Erläuterung
dieser Bestandteile ist aus [Badach 2005] zu entnehmen.
Um eine Lokalisierung von mobilen Endgeräte über das GSM-Netz durchzuführen, verfügt
jede Vermittlungsstelle MSC über ein Register VLR. In diesem Register werden alle mobilen Teilnehmer aufgelistet, die sich aktuell in den zugeordneten Zellen aufhalten. Jede
Zelle wird durch eine eindeutige Nummer identifiziert, die auch als Cell-ID bezeichnet
wird. Ein eingeschaltetes Mobiltelefon ist immer genau einer Zelle zugeordnet. „Das Endgerät führt ständig Messungen der Signalstärke und -qualität der aktuellen Zelle sowie
der Feldstärke der Nachbarzellen durch. Dieser Bericht wird an den BSC gesendet (bei
GSM alle 480 ms)“ [Wikipedia 2005]. Der BSC entscheidet ob eine neue BST gewählt
werden soll. Durch die Zuordnung eines eingeschaltetes Mobiltelefon zu einer Zelle, ist es
möglich, einen Anruf an einen mobilen Teilnehmer weiterzuleiten. Die Information, in
welcher Zelle sich der Teilnehmer befindet, kann aber auch zur Lokalisierung verwendet
werden, da eine Zelle einen bestimmten geografischen Bereich abdeckt. Es ist keine zusätzliche Technik für die Lokalisierung notwendig. Darüberhinaus funktioniert die Lokalisierung auch in Gebäuden.
General Packet Radio Service (GPRS) stellt eine Erweiterung der Mobilfunknetze nach
GSM um die Funktionen für die Paketvermittlung (engl. Packet Switching) dar. Diese
Erweiterung betrifft nur das Core Network, weswegen die Lokalisierung von mobilen Endgeräten zum GSM identisch ist.
Auf Basis von GSM/GPRS gibt es eine Vielzahl verschiedener Verfahren zur Bestimmung
des Standortes. Bei dem Verfahren der Annäherung (engl. Proximity) wird die Position
nicht über geometrische Berechnungen, wie es beispielsweise bei der GPS-Ortung geschieht, sondern über die Position der aktuell zuständigen Basisstation postuliert. Die Genauigkeit des Verfahrens hängt stark von der Größe der Funkzelle ab. Die Zellen im GSM
bzw. GPRS Netz sind normalerweise grob kreisrund und je nach Standort stark unterschiedlich groß. In Städten sind die Zellen relativ klein, was eine Positionsangabe von ungefähr 300 Metern ermöglicht. In ländlichen Gebieten haben die Zellen einen Radius von
bis zu 35 Kilometern (vgl. [Fleuren 2004]). Es sei an dieser Stelle auf die Diplomarbeit
„Location Server“ [Roeder 2004] verwiesen, welche weitere Verfahren beschreibt. Diese
Verfahren setzen jedoch eine Erweiterung der Netzstruktur oder der Endgeräte voraus.
3 Lokalisierungssysteme
- 26 -
3.2.2 UMTS-Netze
„Universal Mobile Telekommunikation System (UMTS) ist als Weiterentwicklung der im
Moment eingesetzten GSM-Technik ein System zur mobilen Datenübertragung. Mit UMTS
wird erstmals die schnelle drahtlose Übertragung großer Datenmengen möglich“ [Bayer.
Landesamt 2004]. UMTS ist ein europäisches Mobilfunk-Konzept, welches Teil des Standards IMT-2000 ist (vgl. [Badach 2005]).
Im August 2000 wurden für insgesamt knapp 100 Milliarden DM (grob ca. 51 Milliarden
Euro) die UMTS-Lizenzen für Deutschland versteigert (vgl. [Heise 2000]). Seit dem 1.
Quartal 2004 kann UMTS in Deutschland in allen Mobilfunk-Netzen genutzt werden. Das
Netz wird derzeit ausgebaut und ist in Ballungsgebieten bereits verfügbar. Die jetzige Infrastruktur von UMTS ermöglicht eine Datenrate von 384 kBit/s. Durch ein höherwertiges
Modulationsverfahren 16-QAM soll in naher Zukunft eine theoretische Datenrate von 14,4
Mbit/s erreicht werden. Das Verfahren wird als High Speed Downlink Packet Access (HSDPA) bezeichnet.
Abbildung 11 Vereinfachte Architektur von UMTS (Funkzugangs- und Kernnetze)
(vgl. [Badach 2005])
CS: Circuit Switched, PS: Packet Switched, RNC: Radio Network Controller, GGSN: Gateway GPRS Support
Node, SGSN: Serving GPRS Support Node, UTRAN: UMTS Terrestrial Radio Access Network, weitere
Abkürzungen wie in Abbildung 10
3 Lokalisierungssysteme
- 27 -
Eine vereinfachte Architektur von UMTS ist in Abbildung 11 dargestellt. UMTS kombiniert
die Leistungsmerkmale der Leitungsvermittlung, also der GSM-Technik, und der Paketvermittlung, also der GPRS-Technik. Das Kernnetz der Leitungsvermittung wird bei UMTS
als CS-Domaine bezeichnet und ist vollkommen vergleichbar mit dem Kernnetz bei GSM
(siehe Abbildung 10). Der Paketvermittlungsteil bei UMTS wird durch die sogenannte PSDomaine präsentiert und entspricht der Funktion bei GPRS. Die aufwendigste Erweiterung
von UMTS ist die Einführung von UTRAN als eigenständiges UMTS-Funkzugangsnetz parallel zum bereits etablierten GSM Funkzugangsnetz.
Die Lokalisierung von Endgeräten im UMTS ist prinzipiell sehr ähnlich zur Lokalisierung
im GSM/GPRS. Der entscheidende Unterschied besteht in der Verwendung des neuen
Funkzugangsnetzes UTRAN. Es werden deutlich mehr und somit kleinere Zellen als im
GSM Netz verwendet. In z.B. Ballungsgebieten, wo UMTS bereits verfügbar ist, kann dadurch die Genauigkeit der Lokalisierung deutlich erhöht werden.
3.2.3 WLAN
Die bereits in vielen Gebäuden oder sogar Städten installierten Funknetze (WLAN) nach
dem Standard IEEE 802.11 stellen heutzutage eine echte Konkurrenz zu UMTS dar.
WLAN bietet mit bis zu 54 Mbit/s eine deutlich höhere Datenrate. „Im Gegensatz zu
UMTS entwickelt sich die Netzstruktur bei WLAN ungeordnet und durch unterschiedliche
Gruppen. Es entsteht eine Vielfalt eher unabhängiger, sehr heterogener Funkzellen an
stark frequentierten Hotspots. Wegen des geringen technischen und wirtschaftlichen Aufwands sind neben den Telekommunikationsunternehmen eine Reihe anderer Unternehmen, wie Hotels und Kaffeehaus-Ketten, vertreten, die in WLAN einen Zusatzservice
für ihre eigenen Kunden sehen. Hierdurch entstehen besonders in Stadtbereichen private
WLAN-Netzwerke, die sich auch als Alternative zu UMTS sehen“ [Turczyk 2005].
Aufgrund der positiven Merkmale von WLAN ist anzunehmen, dass insbesondere in Städten WLAN auch in Zukunft weiter stark ausgebaut wird. In vielen deutschen (Innen-)
Städten gibt es bereits eine gut ausgebaute WLAN-Anbindung. Die Technik verfügt über
keine zentrale Struktur, die z.B. die Zellen eindeutig adressiert oder die über
Komponenten verfügt, welche eine Zuordnung von mobilen Teilnehmern zu aktuellen
Zellen speichert. Aus diesem Gründen, wird sich WLAN wahrscheinlich nicht flächendeckend etablieren.
3 Lokalisierungssysteme
- 28 -
In lokal beschränkten Gebieten kann eine relativ genaue Lokalisierung mit Hilfe von
WLAN durchgeführt werden. Das WLAN Netz setzt sich aus mehreren relativ kleinen
Zellen zusammen. „Die Antennen handelsüblicher 802.11 Endgeräte lassen 30 bis 100
Meter Reichweite auf freier Fläche erwarten. Mit neuester Technik lassen sich sogar 80
Meter in geschlossenen Räumen erreichen“ [Wikipedia 2005]. In jeder Zelle befindet sich
ein sogenannter Access Point, der als Koppelelement zwischen den mobilen Endgeräten
und dem restlichen Netzwerk fungiert. Jeder Access Point, verfügt über eine Kennung des
Funknetztes, die als Service Set Identifier (SSID) bezeichnet wird. Endgeräte können die
Kennung des aktuell für sie zuständigen Access Point auslesen. Denkbar ist die Implementierung eines Servers, der die Zuordnung von SSIDs zu absoluten Positionen speichert. Mit Hilfe dieser Daten könnte ein WLAN-Endgerät genauer als bei UMTS lokalisiert
werden kann.
Derzeit verfügen Mobiltelefone noch nicht über integrierte WLAN-Module, hingegen
verfügen aktuelle PDAs häufig über solche Module bzw. lassen sich entsprechend erweitern. „Eine aktuelle Studie des US-Marktforschungsinstituts ABI Research rechnet bis zum
Jahre 2009 mit weltweit 100 Millionen verkauften WLAN-Mobiltelefonen. Mit diesen Mobiltelefonen kann sowohl in WLAN- als auch in GSM-Netzen telefoniert werden“ [DSL Web
2005]. Auch in Hinblick auf VoIP (Voice over IP) ist eine Kombination dieser beiden
Techniken im Endgerät für die Zukunft sehr interessant. Durch VoIP ist es möglich, mit
einem Mobiltelefon beispielsweise im WLAN-Bereich eines Unternehmens über das IPNetz kostengünstig und mit zusätzlichen Features wie die Erreichbarkeit über eine Festnetznummer zu telefonieren.
3.2.4 Bluetooth
Bluetooth arbeitet wie WLAN im 2,4 GHz Frequenzband und wurde in erster Linie als
Kabelersatz für Peripheriegeräte entwickelt. Die meisten der heute käuflichen Mobiltelefone sind mit Bluetooth ausgestattet. Die Technik wird für die Datenübertragung zu
anderen Mobiltelefonen, Computern oder Druckern eingesetzt. Auch bei der kabellosen
Anbindung von Headsets hat sich Bluetooth etabliert. Die Reichweite von Bluetooth beträgt 10-100 m, die maximale Datenrate liegt bei 1 Mbit/s (vgl. [Wikipedia 2005]). Bluetooth ist insbesondere für die Indoor-Lokalisierung interessant, da auf Grund der
geringen Reichweite eine genaue Lokalisierung erreicht wird und eine große Anzahl von
Endgeräten über die notwendige Technik verfügen. Hingegen ist die Technik für die Outdoor-Lokalisierung nicht geeignet. Eine Infrastruktur ist nicht vorhanden und die Installation wäre auf Grund der geringen Reichweite und Datenrate unakzeptabel. Die
eigentliche Lokalisierung könnte ähnlicher der Lokalisierung bei WLAN über eine Netzkennung realisiert werden.
3 Lokalisierungssysteme
- 29 -
3.3 Gegenüberstellung der Systeme
In diesem Kapitel wurden eine Vielzahl von Lokalisierungssystemen vorgestellt. Trotzdem
wurde auf bestimmte Systeme, die für diese Diplomarbeit weniger relevant sind, nicht
detailiert eingegangen. Die meisten dieser Systeme beziehen sich auf eine räumlich stark
beschränkte Lokalisierung, sind noch in der Entwicklungsphase oder benötigen sehr spezielle Endgeräte. An dieser Stelle sei auf die Diplomarbeit „Location Server“ [Roeder
2004] sowie auf die Diplomarbeit „Location Sensing für ortsabhängige Dienste auf Basis
von Web Services“ [Fleuren 2004] verwiesen. Beide Arbeiten erörtern die Grundlagen der
Lokalisierung und speziellen Techniken.
Festzuhalten bleibt, dass keines der vorgestellten Systeme universelle Eigenschaften aufweist, aber sich die Systeme in ihren Attributen ergänzen. Die satellitengestützten Systeme verfügen über einen globalen, weltweiten Abdeckungsbereich, welche eine Ortsbestimmung auf der ganzen Erde mit relativ hoher Genauigkeit ermöglicht. Das derzeit am
meisten eingesetzte System ist GPS. Es bleibt abzuwarten, ob das europäische System
GALILEO nach dessen Einführung ein ähnlicher Erfolg wie GPS bevorsteht. Die positiven
Merkmale von GALILEO auch gegenüber GPS sprechen dafür.
Die zellenbasierte Lokalisierung von Endgeräten hat gegenüber der satellitengestützten
den großen Vorteil, dass sie nicht durch Hauswände oder Schluchten gehindert wird. Eine
Sichtverbindung ist nicht notwendig und die Lokalisierung über die Mobilfunkzelle weißt
eine hohe Abdeckung auf. Sie ist gerade in Großstädten mit hoher Mobilfunkzellendichte
relativ genau, jedoch nicht zu vergleichen mit der Genauigkeit von GPS. Häufig reicht die
Genauigkeit der Lokalisierung insbesondere bei Anwendungen, die auf die Indoor-Lokalisierung aufsetzen, nicht aus. Für solche Anwendungen sind Techniken wie WLAN oder
Bluetooth interessanter, sie erreichen auf einem eher kleinem Abdeckunsbereich eine höhere Genauigkeit als über die Lokalisierung über die Mobilfunkzelle.
Die Kombination von verschiedenen Verfahren ermöglicht eine hohe Flexibilität und eine
Indoor- und Outdoor-Lokalisierung. In diesem Zusammenhang ist das A-GPS System
sehr interessant. Das zu Grunde liegende Verfahren stellt eine Kombination aus GPS und
der Ortung über die Mobilfunkzelle dar. Eine mögliche Kombination von Bluetooth und
GPS ist ebenfalls denkbar. Es muss je nach Anforderungen der Anwendung abgewogen
werden, welches Lokalisierungssystem oder welche Kombination vom System am besten
geeignet ist. Neue Verfahren und Techniken, wie auch die Weiterentwicklung von GPS zu
DGPS, werden die Qualität der Lokalisierung in Zukunft weiter vorantreiben.
3 Lokalisierungssysteme
- 30 -
Natürlich ist für die Wahl des einzusetzenden Lokalisierungssystemes auch maßgeblich,
wie weit Systeme bereits von Endgeräten unterstützt werden. Aktuelle Mobiltelefone
lassen sich selbstverständlich über die Mobilfunkzelle lokalisieren. Die meisten heutigen
Mobiltelefone verfügen über Bluetooth. Es ist zu erwarten, dass in naher Zukunft verstärkt GPS-Empfänger in die Geräte eingebaut werden. Vergleichbares gilt für WLAN-Module, über die auch das mobile Telefonieren über Voice over IP möglich wird. PDAs
verfügen bereits über solche Schnittstellen oder lassen sich einfach mit entsprechenden
Modulen erweitern.
Bei GPS findet die Ortung des Gerätes beim Anwender statt, während die Ortung über die
Mobilfunkzelle beim Netzbetreiber und nicht im Endgerät stattfindet. Daraus ergeben sich
unterschiedliche Vor- und Nachteile. Aus Sicht des Datenschutzes ist die Ortung über
GPS unkritischer, da der Benutzer selbst entscheiden kann, wann sein Mobiltelefon geortet wird. Hingegen schreckt Anwendern der Gedanke ab, dass ein Netzbetreiber stets
über die aktuelle Position des Anwenders informiert ist. Diese Daten benötigen einen
besonderen Schutz. Da Netzbetreiber diese Daten nur mit Einverständnis des jeweiligen
Teilnehmers weitergeben dürfen, ist die Einführung von netzunabhängigen
Anwendungen, die diese Daten für die Diensterbringung benötigen, erschwert. Um Marktvorteile gegenüber anderen Netzbetreibern zu besitzen, geben Netzbetreiber die Lokalisierungsdaten ungern an dritte weiter, stattdessen entwerfen sie proprietäre
Anwendungen, die nur für ihre Kunden zugänglich sind. Hinzu kommt, dass die Ortung
über GPS für den Endkunden kostenlos ist, während der Netzbetreiber eine Gebühr für
die Ortung über die Mobilfunkzelle verlangt. Für kleine Gebiete (z.B. innerhalb eines
Museums, Campus, Stadtteil) bietet die Lokalisierung über Bluetooth oder WLAN den Vorteil, dass die Ortung unabhängig von dem Netzbetreiber stattfindet und zugleich nicht auf
einen Sichtkontakt zu einer Gegenstation angewiesen ist. Davon abgesehen, ist die
Ortung genauer als über die Mobilfunkzelle. Die Ortung findet in diesen Fällen beim
Dienstanbieter und auch nicht beim Anwender statt. Bei bestimmten Anwendungen kann
die Durchführung der Lokalisierung auf dem Endgerät ein Nachteil sein. Vorstellbar sind
in diesem Zusammenhang Dienste, die sicherstellen müssen, dass der Anwender keine
Möglichkeit hat, seinen Standort mit Absicht zu fälschen (z.B. bei einer Anwendung, die
das gestohlene Auto lokalsiert). Befindet sich die Lokalisierungstechnik im Endgerät, ist
die Manipulation zumindest einfacher möglich, als wenn diese zentral realisiert wird.
3 Lokalisierungssysteme
- 31 -
In den Tabelle 3 und 4 werden die satellitengestützten und die zellenbasierten Lokalisierungssysteme gegenübergestellt. Unter dem Merkmal „Verfügbarkeit des Systems“
wird die aktuelle Situation zu Grunde gelegt. Beispielsweise ist das GALILEO-System
derzeit noch nicht verfügbar, wird jedoch nach seiner Einführung eine hohe globale
Verfügbarkeit für den Anwender gewähren. Letzteres wird als Merkmal „Abdeckungsbereich“ in den Tabellen dargestellt.
System
GPS
DGPS
AGPS
GALILEO
Merkmale
Genauigkeit
⊕
⊕⊕
⊕⊕
⊕⊕
Abdeckungsbereich (Outdoor)
⊕⊕
⊕⊕
⊕⊕
⊕⊕
Abdeckungsbereich (Indoor)
⊖⊖
⊖⊖
⊕
⊖
Verfügbarkeit des Systems
⊕⊕
⊕
⊖
⊖⊖
✔ / ✘
✔ / ✔
✔ / ✘
✔
✳
✔
Ortung im Endgerät/Netzbetreiber ✔ / ✘
kostenlose Nutzung
✔
Endgeräte (integriert/erweiterbar)
Mobiltelefone
✘ / ✔
✘ / ✔
✘ / ✔
✘ / ✘
PDAs
✳ / ✔
✳ / ✔
✳ / ✔
✘ / ✘
Notebooks
✘ / ✔
✘ / ✔
✘ / ✘
✘ / ✘
Tabelle 3 Gegenüberstellung satellitengestützter Lokalisierungssysteme
Legende: ✔ : möglich, ✳ : teilweise möglich, ✘ : nicht möglich,
⊕ : wird zufriedenstellend erfüllt, ⊖ : wird nicht zufriedenstellend erfüllt
System
GSM
UMTS
WLAN
Bluetooth
Merkmale
Genauigkeit

Abdeckungsbereich (Outdoor)
bis ⊖⊖
⊕ bis ⊖

⊕
⊕⊕
⊕
⊖
⊖⊖
Abdeckungsbereich (Indoor)
⊕


⊖⊖
Verfügbarkeit des Systems
⊕⊕
⊕
⊕
⊕
✘ / ✔
✘ / ✔
✘ / ✔
✘
✳
✳
Ortung im Endgerät/Netzbetreiber ✘ / ✔
kostenlose Nutzung
✘
Endgeräte (integriert/erweiterbar)
Mobiltelefone
✔ / ✘
✳ / ✘
✳ / ✘
✔ / ✘
PDAs
✳ / ✘
✳ / ✘
✳ / ✔
✔ / ✘
Notebooks
✘ / ✔
✘ / ✔
✔ / ✔
✳ / ✔
Tabelle 4 Gegenüberstellung zellenbasierter Lokalisierungssysteme
Legende: ✔ : möglich, ✳ : teilweise möglich, ✘ : nicht möglich,
⊕ : wird zufriedenstellend erfüllt, ⊖ : wird nicht zufriedenstellend erfüllt
4 J2ME Grundlagen
- 32 -
4 J2ME Grundlagen
Dieses Kapitel liefert wesentliche Grundlagen der Java 2 Micro Edition (J2ME). Als erstes
wird ein Überblick über die unterschiedlichen Java Editionen und den zugeordneten Geräten präsentiert. Die bei der J2ME Version vorhandenen Einschränkungen, bedingt durch
die leistungsschwachen Endgeräte, werden aufgezeichnet. Weiterhin wird ein Überblick
über die J2ME Architektur geliefert.
Es wird auf die GUI-Programmierung, die persistente Datenhaltung und mögliche Netzwerkverbindungen in der J2ME eingegangen. Detailiert werden die Merkmale von Web
Services und die Anbindung von J2ME Anwendungen an diese Dienste mit Hilfe der Web
Service API beschrieben.
Zum Ende des Kapitels wird ein Praxisbeispiel vorgestellt. Es wird die Implementierung
eines einfachen „Hello World“ - MIDlets beschreiben. Die Erzeugung eines JAR-Archivs
und einer JAD-Datei wird erläutert. Diese Dateien sind für die Installation einer J2ME
Anwendung auf dem Mobiltelefon notwendig.
4 J2ME Grundlagen
- 33 -
4.1 Überblick über die Technologie
Die Programmiersprache Java wird von einer Vielzahl von Geräten, angefangen von
extrem leistungsfähigen Servern über PCs und Laptops bis hin zu Mobiltelefonen oder
PDAs, unterstützt. Aufgrund der verschiedenen Merkmale dieser Geräte, unterteilte Sun
im Juni 1999 die Plattform in drei Editionen. Die Abbildung 12 liefert einen Überblick über
diese verschiedenen Editionen und den ihnen zugeordneten Endgeräten. Die in diesem
Kapitel behandelten Elemente sind in dieser und in der folgenden Abbildung fett gedruckt
dargestellt.
Server
PDA
Workstation
PC
Java 2
Enterprise
Edition
Laptop
Java 2
Standard
Edition
Pager
Set-Top-Box
Point of Sales
Videotelefon
Mobiltelefon
CDC
Smartcard
CLDC
Java 2 Micro Edition
Java Programming Language
HotSpot
JVM
KVM
CardVM
Abbildung 12 Unterteilung der Java 2 Technologie
(vgl. [Schmatz 2004], [Kroll 2005])
4.1.1 Eigenschaften der J2ME zugehörigen Endgeräte
Die J2ME (Java 2 Micro Edition) ist eine Edition, die speziell für mobile Endgeräte, wie
zum Beispiel Mobiltelefone, entwickelt wurde. Diese Geräte weisen bestimmte gemeinsame Eigenschaften auf (vgl. [Frech 2003], [Metzger 2004]):
 limitierte Rechenleistung (langsamer Prozessor, geringe Performance)
 eingeschränkte Speicherkapazität
 begrenzte Eingabemöglichkeiten (keine oder nur eine kleine Tastatur, Ziffernblatt)
 begrenzte Darstellungsmöglichkeiten (kleine Displays, geringe Auflösung)
 zum Teil niedrige Übertragungsgeschwindigkeit
 zum Teil begrenzte Stromverzorgung (Akku)
4 J2ME Grundlagen
- 34 -
4.1.2 Architektur der J2ME
„Verglichen mit den größeren Editionen deckt die J2ME ein heterogenes Feld von Geräten
ab. Der Versuch, ein einheitliches Softwareprodukt zu schaffen das für alle Geräte gleichermaßen gut geeignet ist, wäre vermutlich zum Scheitern verurteilt gewesen. Die J2ME
definiert sich durch verschiedene Spezifikationen, die zusammen mehrere Plattformen
bilden. Jede dieser Plattform ist für eine bestimmte Kategorie von Endgeräten ausgelegt“
[Schmatz 2004]. Die High-Level-Architektur der J2ME ist in Abbildung 13 dargestellt. Auf
Konfiguration
CLDC
CDC
Viruelle Maschine (VM)
KVM
JVM
Betriebssystem
RMI Profile
Personal Profile
Foundation Profile
PDAP
MIDP
Profile
RMI
SIP API
PDA Optional P.
Bluetooth API
Location API
Web Service API
MMAPI
Optionale
Pakete
WMA
die Funktionen der einzelnen Schichten wird auf der folgenden Seite eingegangen.
z.B. Symbian OS, PalmOS, Linux, Windows CE
Abbildung 13 Konfiguration, Profile und optionale Pakete der J2ME
(vgl. [Schmatz 2004], [Kroll 2005])
4 J2ME Grundlagen
- 35 -
„Die Konfiguration beschreibt die verfügbaren Grundfunktionen der virtuellen Maschine
für eine Klasse von Geräten mit ähnlicher Leistungsfähigkeit“ [Kroll 2005]. Zur Zeit gibt
es zwei Konfigurationen: Die CLDC (Connected, Limited Device Configuration) ist für mobile stark ressourcenbeschränkte Endgeräte wie Mobiltelefone ausgelegt. Die CDC
(Connected Device Configuration) eignet sich für leistungsfähige, zum Teil stationäre
Endgeräte, wie z.B. Set-Top-Boxen. Während die CDC eine vollständige Java Virtual Machine (JVM) bereitstellt, verfügt die CLDC Konfiguration über eine abgespeckte Kilobyte
Virtual Machine (KVM). Auf die CLDC wird in diesem Kapitel auf den folgenden Seiten eingegangen.
Die Profile erweitern die Konfiguration um spezielle Leistungsmerkmale für einen bestimmten Typ von Geräten. Bestandteil der Profile sind beispielsweise Klassen für die
Benutzerschnittstelle und die persistente Datenhaltung. Die Profile und in manchen Fällen
die optionalen Pakete sind an eine bestimmte Konfiguration gebunden. Wegen dieser
Abhängigkeit haben sich innerhalb der J2ME de facto zwei getrennte Säulen herausgebildet. „Das wichtigste Profil ist das MIDP (Mobil Information Device Profile), dessen erste
Version im September 2000 erschienen ist. Seit November 2002 liegt die Spezifikation in
der aktuellen Version 2.0 vor“ [Schmatz 2004]. Das PDAP (PDA Profil) stellt ein spezielles
Profil für PDAs dar. Wichtige Merkmale des MIDPs werden in Abschnitt 4.3 dargestellt.
„Ein optionales Paket ist eine Klassenbibliothek, die eine über die Profile hinausreichende, fortgeschrittene Funktionalität anbietet“ [Schmatz 2004]. Anders als bei den Profilen, sind Endgeräte nicht verpflichtet eine Implementierung bereitzustellen um die Kriterien einer J2ME Unterstützung zu erfüllen. Für die drahtlose Anbindung einer GPS-Maus
ist die Bluetooth API notwendig. Eine Implementierung wird im Kapitel 7.3.3 vorgestellt.
Mit Hilfe des Web Service API kann eine J2ME Anwendung mit Web Services kommunizieren. Diese API unterstützt das SOAP und einen eingeschränkten SAX-Parser. Im Abschnitt 4.4 wird detailiert auf dieses API eingegangen.
4 J2ME Grundlagen
- 36 -
4.2 CLDC (Konfiguration)
Die CLDC (Connection Limited Device Configuration) ist die übliche
CLDC
Konfiguration für Mobiltelefone und ähnliche Geräte mit sehr
beschränkten Eigenschaften. Die CLDC ist derzeit in der Version
1.0 und in dessen Weiterentwicklung in der Version 1.1 verfügbar. Beide Konfigurationen
stellen geringe Anforderungen an die Endgeräte. Beispielsweise wird in der Version 1.0
nur ein Speicherbedarf von 128kB verlangt. Im Folgenden wird die Beschränktheit dieser
Konfiguration und das GCF (Generic Connection Framework) vorgestellt.
4.2.1 Einschränkungen
Aufgrund der notwendigen Kompaktheit der KVM unterliegt die CLDC einer ganzen Reihe
von Einschränkungen. Zu diesen zählen beispielsweise (vgl. [Topley 2002], [Schmatz
2004], [Frech 2003]):
 keine Floating Point Unterstützung. Die CLDC 1.0 unterstützt keine Fließkomma-
zahlen (float und double), da die Berechnung solcher Zahlen sehr rechenintensiv ist
und die meisten Geräte nicht über eine spezielle Hardware zur Berechnung der Zahlen
verfügen. Durch die Weiterentwicklung der Endgeräte stieg auch die Rechenleistung
und Speicherkapazität, weswegen die CLDC 1.1 mit der Fließkomma-Arithmetik ausgestattet wurde.
 keine Java Native Interface (JNI). Es können keine Bibliotheken anderer Program-
miersprachen verwendet werden.
 kein ClassLoader. Die KVM verwendet einen fest eingebauten Class Loader. Die
Möglichkeit, ihn durch einen benutzerdefinierten Class Loader zu ersetzen, besteht
nicht.
 keine Reflections: Die Fähigkeit, Metadaten über die Struktur von Klassen, Methoden
und Variablen zur Laufzeit bereitzustellen, ist in der KVM nicht vorhanden.
 keine Thread-Gruppen oder Dameon-Threads. Nur einfache Threads sind möglich.
In der Version 1.0 der CLDC steht noch keine Methode zur Verfügung um einen Thread
zu unterbrechen (engl. interrupt).
 keine finalization() Methode oder schwache Referenzen. Damit wird die Arbeit
des Garbage-Collectors wesentlich einfacher. Ressourcen werden gespart.
4 J2ME Grundlagen
- 37 -
4.2.2 Das Generic Connecetion Framework (GCF)
Bei diesem Framework handelt es sich um eine Vereinheitlichung von Netzwerkzugriffen.
Der Verbindungsaufbau geschieht in J2ME generell über die Klasse Connector. Die Klasse
liefert bei erfolgreichem Verbindungsaufbau ein konkretes Objekt, welches die Schnittstelle Connection implementiert, zurück. Dieses Objekt kann in eine der in Abbildung
14 dargestellten Verbindungsarten konvertiert werden, da alle weiteren Schnittstellen
von Connection abgeleitet sind (vgl. [Kroll 2005]). Beispiele wie dieses Framework für
eine HTTP-Verbindung zu einem Web Server genutzt werden kann, sind in [Topley 2002]
und [Schmatz 2004] beschrieben.
java.microedtion
io
Connector
ConnectionNotFoundException
<interface>
Connection
<interface>
DatagramConnection
<interface>
StreamConnectionNotifier
<interface>
InputConnection
<interface>
OutputConnection
<interface>
StreamConnection
<interface>
ContentConnection
<interface>
HttpConnection
Abbildung 14 Klassendiagramm des J2ME Paketes java.microedtion.io, Ausschnitt
4 J2ME Grundlagen
- 38 -
4.3 MIDP (Profil)
Wie bereits dargestellt ist das wichtigste Profil für die CLDC das
MIDP
MIDP (Mobile Information Device Profile), welches heutzutage von
nahezu allen auf dem Markt verfügbaren Mobiltelefonen unter-
stützt wird. „Anwendungen für das MIDP heißen MIDlets. Ein MIDlet ist eine gewöhnliche
Java-Klasse, die von der abstrakten Klasse MIDlet aus der MIDP-Bibliothek abgeleitet
ist. Ein oder mehrere MIDlets bilden eine MIDlet-Suite, welche die kleinste installierbare
Einheit darstellt“ [Schmatz 2004].
4.3.1 Der MIDlet-Lebenszyklus
Jedes MIDP kompatible Gerät verfügt über einen AMS (Application Management Software). Diese Komponente ist unter anderem für die Steuerung des MIDlet-Lebenszyklus, zu
den Aktionen wie Starten, Pausieren und Beenden der Anwendung gehören, verantwortlich. Die Zustände und die Zustandsübergänge sind in der Abbildung 15 dargestellt. Die
genannten Aktionen können außerhalb der eigentlichen Anwendung durch die AMS ausgelöst werden. Das Eintreffen eines Anrufes ist ein Beispiel für die Notwendigkeit einer
Java Anwendung von außen durch die AMS zu Pausieren. Das MIDlet kann aber auch von
selbst Zustandsänderungen auslösen. Die meisten MIDlets bieten z.B. einen Menüpunkt
zum Verlassen des Programms an. Wenn der Benutzer diesen auswählt, erledigt das
MIDlet die erforderlichen Aufräumarbeiten und ruft die von der Basisklasse ererbte Methode notfiyDestroyed() auf. Der Aufruf bewirkt, dass die Änderung der AMS mitgeteilt
und der Zustandsübergang nach Destroyed durchgeführt wird.
(1) AMS: Konstruktor
(4) AMS: destroyApp()
(6) MIDlet: notifyDestroyed()
Paused
(2) AMS: startApp()
(3) AMS: pauseApp()
Active
(5) MIDlet: notifyPaused()
Garbage Collection
Destroyed
(4) AMS: destroyApp()
(6) MIDlet: notifyDestroyed()
Abbildung 15 Der MIDlet-Lebenszyklus, gesteuert von der AMS bzw. vom MIDlet
(vgl. [Schmatz 2004])
4 J2ME Grundlagen
- 39 -
4.3.2 Das LCDUI-Modell
Aufgrund der Tatsache, dass ein mobiles Endgerät, wie ein Mobiltelefon, völlig andere
Display- und Bedienungseigenschaften als ein PC oder Laptop aufweist, wurde in der
J2ME ein komplett neues GUI-Modell entwickelt. Dabei orientiert sich dieses Modell an
dem „kleinsten gemeinsamen Nenner“ der Fähigkeiten der Endgeräte und trägt dementsprechend die Bezeichnung Lowest Common Denominator User Interface (LCDUI). Es
wird zwischen einem High-Level API und einem Low-Level API unterschieden. Ersteres
unterstützt eine Menge von Dialogelementen für die Erstellung einer Benutzeroberfläche.
Mit Hilfe der Low-Level API ist es möglich direkt auf dem Bildschirm zuzugreifen. Die
meisten Spiele benutzten dieses API. In dieser Diplomarbeit wird die High-Level API
verwendet. Die Abbildung 16 zeigt einen Ausschnitt des LCDUI Paket.
java.microedtion
midlet
benutzt
MIDlet
lcdui
1
<interface>
Command
Listener
0...1 benutzt
Canvas
Screen
Form
benutzt
0...1
List
TextBox
beinhaltet
0...n
Item
<interface>
benutzt 0...1 ItemCommand
Listener
ChoiceGroup
DateField
Display
High-Level API
beinhaltet
Alert
<interface>
ItemState
Listener
0...1 hat
Low-Level API
0...n
Command
Displayable
ImageItem
Gauge
StringItem
TextField
Abbildung 16 Klassendiagramm des J2ME Paketes java.microedition.lcdui, Ausschnitt
(vgl. [Topley 2002] und [Schmatz 2004])
4 J2ME Grundlagen
- 40 -
4.3.3 Record Management System (RMS)
„In vielen Anwendungen ist es wünschenswert, bestimmte Daten wie Einstellungen und
Arbeitsergebnisse dauerhaft zu speichern, um sie in in einer Folgesitzung weiterverwenden zu können. Die MIDP-Spezifikation fordert, dass die Hardware über einen nicht
flüchtigen Speicher mit einer für Anwendungsdaten nutzbaren Kapazität von mindestens
8 kB verfügen muss“ [Schmatz 2004]. Das Record Management System (RMS) bietet
eine transparente Programmierschnittstelle für lesende und schreibende Zugriffe auf
diese persistenten Daten. Für die Implementierung des RMS ist jeder Hardwarehersteller
selbst verantwortlich.
Das RMS arbeitet nach dem Vorbild einer einfachen satzorientierten Datenbank. Eine Datenbank, die als Record-Store bezeichnet wird, enthält eine Menge ungetypter Datensätze
variabler Länge. Jeder Datensatz ist durch einen eindeutigen Identifikator gekennzeichnet, der die Funktion eines Primärschlüssels übernimmt. Die Abbildung 17 verdeutlicht
die Zusammenhänge. Im MIDP 1.0 waren Record-Stores anderer MIDlet-Suites grundsätzlich nicht sichtbar. Seit MIDP 2.0 ist der Zugriff auf fremde Stores, entsprechenden
Rechte vorausgesetzt, möglich (vgl. [Schmatz 2004]).
Record-Store S
MIDlet-Suite A
MIDlet a
id
record
MIDlet b
1
2
3
... ...
Abbildung 17 Persistenten Datenhaltung mit Hilfe des RMS in der J2ME
(vgl. [Schmatz 2004])
Die Klasse RecordStore aus dem Paket javax.microedition.rms stellt die gesamte
Funktionalität für die persistente Datenhaltung zur Verfügung. Eine mögliche Implementierung wird im Kapitel 7.5.2 am Beispiel des interaktiven Stadtführer vorgestellt.
4 J2ME Grundlagen
- 41 -
4.4 Web Service API (optionales Paket)
In den Kapiteln 5-7 wird eine mobile Anwendung entwickelt, die
Web Service API
Informationen über z.B. Sehenswürdigkeiten von einem entfernten
Server über das Internet auf das Mobiltelefon überträgt. Für sol-
che Client-Server-Architekturen werden häufig Web Services eingesetzt, da diese eine offene und flexible Architektur ermöglichen. Im Folgenden werden grundlegende Merkmalen von Web Services erläutert. Anschließend werden die Funktionen der Web Service API
erläutert. Die API ermöglicht eine Anbindung von J2ME Anwendungen an Web Services.
In dem Tutorial [Armstrong 2005] und in der Quelle [Hein 2003] ist die Implementierung
von Web Services und in [Schmatz 2004] die Anbindung an diese Services beschrieben.
4.4.1 Generelle Merkmale von Web Services
„Ein Web Service ist vereinfacht dargestellt ein Stück Logik, das sich irgendwo auf einem
Server im Internet befindet und sich über Standard-Internet-Protokolle wie HTTP oder
SMTP ansprechen lässt. Ein Web Service kann hierbei ein sehr einfaches, aber auch ein
sehr komplex handhabbares Gebilde sein – wie bei Browser-basierten Anwendungen, bei
denen das Spektrum von einfachen HTML-Seiten bis zu komplexen Anwendungen reicht.
Der Unterschied ist einfach, das ein Web Service die Funktionalität für Programme erreichbar macht und damit eine Reihe neuer Möglichkeiten im Umgang mit verteilten
abgelegten Informationen eröffnet, denn nun kann man mit Programmen verschiedene
Dienste im Internet erreichen und zu neuen Diensten kombinieren“ [Hein 2003].
Web Services bilden die drei wichtigsten
Verzeichnis
(Service-Broker)
Teile der Zusammenarbeit zwischen Client
UDDI
und Server ab: Das Zusammenfinden,
Binden und den Datenaustausch. Die Abbildung 18 verdeutlicht die Funktionsweise und die beteiligten Instanzen. Der
auffinden
registrieren
WSDL
WSDL
Service-Anbieter veröffentlicht in einem
Verzeichnis die Beschreibung seiner
SOAP oder
XML-RPC
Dienste. Der Konsument durchsucht das
Verzeichnis und wählt den gewünschten
Dienst aus. Anschließend findet die An-
ServiceKonsumer
Datenaustausch
ServiceAnbieter
bindung des Konsumenten an den An-
Abbildung 18 Funktionsweise von Web Ser-
bieter statt. Der Konsument kann schließ-
vices inklusiver beteiligter Instanzen
lich auf Methoden des Anbieters zugreifen
(vgl. [Wikipedia 2005] und [Hein 2003])
(vgl. [Wikipedia 2005]).
4 J2ME Grundlagen
- 42 -
Die Grundlage für Web Service bilden folgende vier Standards:
 Das UDDI (Universal Description and Discovery Interface) stellt einen standardisierten
Verzeichnisdienst zum Publizieren und zum Auffinden von Web Services zur Verfügung.
Es wird ein dezentrales System aus mehreren UDDI-Knotenpunkte bereitgestellt. Diese
Knoten gleichen untereinander die registrierten Einträge zum Auffinden der Web Services ab (vgl. [Hein 2003]).
 Die WSDL (Web Service Description Language) stellt eine weitere Basistechnologie für
die Entwicklung von Web Services dar. Die Aufgabe bei der Entwicklung einer Web Service-Beschreibung in WSDL besteht darin, eine Schnittstelle zwischen einem bereitgestellten Dienst und einem anfragenden Client zu definieren. Eine solche Definition
beinhaltet z.B. die unterstützten Methoden und deren Parameter. „Durch die
Verwendung der WSDL-Beschreibung wird es möglich, Web Services automatisch zu
propagieren und neue Funktionalität mit einem minimalen Anpassungsaufwand am
Code der Server- und Client-Applikationen zu entwickeln“ [Hein 2003].
 Das SOAP (Simple Objekt Access Protocol) dient wie XML-RPC (XML-Remote Procedu-
re Calls) zur Kommunikation zwischen Konsument und Anbieter. Hier wird der eigentliche Aufruf gestartet. Das SOAP stellt eine Weiterentwicklung des XML-RPC dar.
In der SOAP-Spezifikation [W3C 2000] ist genau
festgelegt, was eine gültige SOAP-Nachricht
(engl. Message) ist und welche Elemente sie enthalten darf. Die Abbildung 19 zeigt die generelle
Struktur einer SOAP-Nachricht, die nach dem
Head-Body-Pattern modelliert ist. Ein SOAP-Envelope ist ein Container, der ein (optionales) Header-Element und ein Body-Element enthält. Im
Head-Bereich sind Metainformationen, wie z.B.
Informationen über Routing, Verschlüsselung
oder Transaktionen, untergebracht. Im Body der
Nachricht sind, wie auch bei HTML, die Nutzdaten
SOAP-Message
SOAP-Part
SOAP-Envelope
SOAP-Header
Header-Element
Header-Element
SOAP-Body
XML-Nutzdaten
Fault-Element
untergebracht. Die Daten können dabei unter
anderem für entfernte Methodenaufrufe oder
Attachment-Part
(Fehler-)Meldungen stehen. Anschließend können
mögliche Anhänge folgen. Binärdateien können
Abbildung 19 Generelle Struktur
durch Nutzung von MIME-Mechanismen ange-
von SOAP-Nachrichten
bunden werden (vgl. [Wikipedia 2005]).
(vgl. [Hein 2003])
4 J2ME Grundlagen
- 43 -
Die vorgestellten Standards basieren alle auf der Extensible Markup Language (XML) und
der Transformation von aus XML generierten Objekten. Diese Auszeichnungssprache
verfügt über eine ganze Reihe von positiven Merkmalen, die somit auch Web Services
auszeichnen:
 XML beschreibt eine eindeutige und baumartige Struktur von Daten mit Hilfe von soge-
nannten XML Tags. „XML benutzt die Tags im Gegensatz zu HTML nur zur Abgrenzung
von Daten und überlässt die Interpretation der Daten allein der Anwendung, die sie
verarbeitet“ [Mintert 2002]. Die Erscheinungsform (Layout) oder die mögliche Weiterverarbeitung dieser Daten werden nicht in XML definiert. Dadurch wird gewährleistet
das die XML Daten für unterschiedliche Anwendungen als Quelle dienen können.
 XML erleichtert es einem Computer, Daten zu generieren oder zu lesen und sorgt dafür,
dass eine bestimmte Datenstruktur eindeutig bleibt. XML ist erweiterbar, plattformunabhängig und unterstützt Internationalisierung/Lokalisierung und Unicode. XML Daten
können maschinell auf syntaktische Korrektheit überprüft werden (vgl. [Mintert 2002]).
XML Daten werden im Textformat gespeichert, was dem Entwickler das Debuggen von
Anwendungen und das Verstehen der Datenstruktur vereinfacht.
 XML ist als eine W3C-Entwicklung lizenzfrei und ein etablierter Standard. Die Gene-
rierung bzw. das Parsen (zu deutsch analysieren) von XML wird von vielen Programmiersprachen unterstützt. Als Kerntechnologien sind die Programmiersprachen unabhängigen APIs: Simple API for XML (SAX) und Document Object Model (DOM) zur
Verarbeitung von XML-Nachrichten definiert.
4.4.2 Funktionsbereiche der API
Ziel der Web Service API (JSR-172) ist es, Programmierschnittstellen für die J2ME bereitzustellen, um die Nutzung von Web Services zu vereinfachen. Die Spezifikation deckt
im Wesentlichen zwei Funktionsbereiche ab (vgl. [Schmatz 2004]):
 Das Zerlegen von Dokumenten, die in er XML verfasst sind, in einzelne syntaktischen
Elementen – das so genannte Parsen. Die API greift auf eine Teilmenge des Java APIs
for XML Processing (JAXP) zurück. Die Web Service API unterstützt nur den SAXParser, während in der eigentlichen JAXP auch DOM implementiert ist.
 Das Aufrufen von entfernten Diensten über das auf XML basierende SOAP. Es wird eine
Untermenge des Java APIs for XML based Remote Procedure Calls (JAX-RPC) für den
Aufruf von Web Services unterstützt. Die serverseitige Dienstbereistellung und eine
UDDI Unterstützung ist dagegen nicht Gegenstand der API.
4 J2ME Grundlagen
- 44 -
4.5 Hello MIDlet (Praxisbeispiel)
Die folgende Anleitung erklärt, wie ein einfaches MIDlet erstellt wird. Die Installation der
notwendigen Entwicklungswerkzeuge wird in diesem Abschnitt vorausgesetzt. In der
Anlage A wird die Einrichtung der Entwicklungswerkzeuge beschrieben. Die Installation
von J2SE und J2ME ist zwingend notwendig. Die Installation der Entwicklungsumgebung
Eclipse mit dem EclipseME Plugin wird empfohlen.
4.5.1 Quellcode
In Abbildung 20 wird der Quellcode einer einfachen Anwendung dargestellt. Das MIDlet
gibt „Hello World“ auf dem Display aus und stellt einen Menüpunkt zum Beenden bereit.
import javax.microedition.lcdui.*;
import javax.microedition.midlet.*;
public class MyMIDlet extends MIDlet implements CommandListener {
private final Command EXIT_COMMAND;
private Form form;
public MyMIDlet() {
super();
EXIT_COMMAND = new Command ("Exit", Command.EXIT,0);
form = new Form("MIDlet-Titel");
form.setCommandListener(this);
// Interface aktivieren
form.addCommand(EXIT_COMMAND);
// Command hinzufügen
form.append("Hello MIDlet");
// StringItem hinzufügen
}
}
/* Methode wird beim Starten des MIDlets aufgerufen
protected void startApp() {
Display.getDisplay(this).setCurrent(form);
}
*/
/* Methode wird beim Wechsel in den Pause-Zustand aufgerufen
protected void pauseApp() { }
*/
/* Methode wird beim Beenden aufgerufen
protected void destroyApp(boolean unconditional) { }
*/
/* Methode, des CommandListener Interface
*/
public void commandAction(Command command, Displayable displayable) {
if (command == EXIT_COMMAND) {
// Beenden ausgewählt?
destroyApp(true);
// beende MIDlet
notifyDestroyed();
// AMS über Ende informieren
}
}
Abbildung 20 Quellcode eines einfachen MIDlets mit der Ausgabe „Hello World“
4 J2ME Grundlagen
- 45 -
4.5.2 Erzeugen der MIDlet Suite
Mit Hilfe der Anwendung KToolbar lassen sich auf einfachem Wege über eine grafische
Oberfläche MIDlet-Suites erzeugen. Die Anwendung ist bereits bei der Installation des
J2ME Wireless Toolkit (WTK) enthalten. Eine MIDlet-Suite setzt sich aus einer JAR und
einer JAD Datei zusammen. Beide Dateien stellen eine Einheit für die Installation mobiler
Java-Anwendungen auf dem Mobiltelefon dar.
Nach dem Starten von KToolbar erstellt man unter File -> New Project... ein neues
Projekt. Als Projektname kann z.B. HelloWorld und als MIDlet Class Name MyMIDlet
eingetragen werden. Anschließend erscheint ein Fenster, in dem verschiedenste Einstellungen bezüglich der Anwendung vorgenommen werden können. Diese Einstellungen
werden teilweise in der MANIFEST.MF und in einer JAD-Datei gespeichert. Das Manifest
wird zusammen mit dem Bytecode und anderen Ressourcen, z.B. Bilder, in eine JAR-Datei verpackt. Es enthält Informationen über die verwendete Konfiguration und das
verwendete Profil, die enthaltenen MIDlets, sowie den Namen und die Version der MIDlet-Suite und deren Urheber. Ähnliche Informationen beinhaltet die JAD-Datei, die nicht
wie das Manifest im JAR-Archiv enthalten ist. In der JAD-Datei ist zum Beispiel vermerkt,
wie groß das JAR-Archiv ist. Beide Dateien liegen im Klartext vor.
Durch das Erzeugen eines neuen Projektes werden einige Verzeichnisse automatisch
durch die Anwendung KToolbar angelegt. Für die in der Anlage beschriebenen Installation, wird im Falle dieser Beispielanwendung, das Projektverzeichnis /usr/lib/jvm/java1.5.0-sun-1.5.0_03/WTK2.2/apps/HelloWorld erstellt.
 Im Verzeichnis /scr ist der Quellcode gespeichert. Für diese Beispielanwendung muss
eine Datei MyMIDlet.java mit dem Quellcode aus der Abbildung 20 angelegt werden.
 Im Verzeichnis /res werden z.B. Bilder und Icons gespeichert. Diese werden von
KToolbar mit in das JAR-Archiv eingebunden.
 Im Verzeichnis /bin speichert KToolbar die MANIFEST.MF-, JAD- und JAR-Dateien.
Zum Erzeugen des JAR-Archives muss unter KToolbar Project -> Package -> Create
Package ausgewählt werden. Kopiert man die erzeugte JAD- und JAR-Datei auf ein Mobiltelefon, lässt sich die Beispielanwendung auf dem Gerät installieren. Zum Simulieren
des Mobiltelefons kann KToolbar ebenfalls verwendet werden. Hierfür muss das geladene
Projekt über Run ausgeführt werden.
5 Systemanalyse
- 46 -
5 Systemanalyse
Ziel dieser Diplomarbeit ist die Entwicklung eines interaktiven Stadtführers. Dieses Kapitel beschreibt die erste Phase des Prozesses der Softwareerstellung. Die zugrunde
liegende Systemidee wird definiert. Insbesondere werden die unterschiedlichen Anforderungen an das zu erstellende System aufgezeigt. Anschließend werden mögliche
Anwendungsfälle beschrieben. Zum Ende des Kapitels wird ein Prototyp des interaktiven
Stadtführers vorgestellt.
Dieses Kapitel beschreibt das zu erstellende System in erster Linie aus Sicht des Anwenders. Zum besseren Verständnis der Strukturen und Abläufe wird die standardisierte
Beschreibungssprache Unified Modeling Language (UML) eingesetzt.
5 Systemanalyse
- 47 -
5.1 Systemidee
Es soll ein interaktiver Stadtführer für das Mobiltelefon entwickelt werden. Ziel ist es,
von der Position des Benutzers abhängige Informationen über beispielsweise Sehenswürdigkeiten auf dem Mobiltelefon darzustellen. Die Position des Benutzers soll automatisch ermittelt werden. Das System soll sich aus der Anwendung auf dem Mobiltelefon
(Client) und einem Web Service (Server) zusammensetzen. Das System muss als ein
Framework konzipiert werden, wodurch es möglich wird, das System durch Module zu
erweitern und in einem anderen Kontext wiederzuverwenden.
5.1.1 Anforderungsbeitragende
Noch bevor die Anforderungen an das zu erstellende System ermittelt werden, gilt es zu
klären, wer überhaupt Anforderungen an das System stellt. Die Abbildung 21 zeigt die
unterschiedlichen Anforderungsbeitragenden.
Anwender
Administrator
Interaktiver Stadtführer
Moderator
Systementwickler
Abbildung 21 Anforderungsbeitragende des interaktiven Stadtführers
Der Anwender ist im konkreten Fall des interaktiven Stadtführers ein Tourist, der sich
über historische Gebäude oder andere Sehenswürdigkeiten an seinem aktuellen Standpunkt informieren will. Als Anzeigegerät soll ein Mobiltelefon dienen. Der Moderator ist
für die Inhalte der darzustellenden Informationen verantwortlich. Die Informationen
sollen beispielsweise über ein Web-Interface gepflegt werden. Die Sichtweise des Administrators hingegen ist technisch und nicht inhaltlich geprägt. Er ist für die Installation und Erreichbarkeit des Systems verantwortlich. Der Systementwickler betrachtet
das System konzeptionell und implementell. Er ist für die Weiterentwicklung des Systems
und die Integration in andere Systeme zuständig.
5 Systemanalyse
- 48 -
5.1.2 Systemanforderungen
Nachfolgend werden die unterschiedlichen Systemanforderungen der Anforderungsbeitragenden analysiert. Die Tabelle 5 auf der folgenden Seite liefert eine Übersicht über die
unterschiedlichen Anforderungen.
Der Anwender verlangt eine einfach zu bedienende und funktional einwandfreie
Anwendung für das Mobiltelefon. Die Applikation muss zumindest auf den heute handelsüblichen Mobiltelefonen einfach zu installieren und ausführbar sein. Die anfallenden Kosten müssen für den Anwender transparent sein, anderenfalls würde er womöglich die
Anwendung nicht einsetzen wollen. Durch die Lokalisierung des Anwenders entstehen
sensible Daten, von denen der Anwender einen angemessenen Schutz verlangt. Von den
genannten Rahmenbedingungen und Qualitätsanforderungen abgesehen, erwartet der
Anwender ein System, das konkrete und fundierte Informationen zu den Sehenswürdigkeiten seines Standortes liefert. Er erwartet Informationen in Form von Texten und
Bildern sowie Orientierungshilfen um andere Sehenswürdigkeiten in der unmittelbaren
Umgebung aufzufinden. Ihm muss es möglich sein, zwischen angebotenen Informationen
zu wählen und dadurch interaktiv mit dem System in Verbindung zu treten. Das Interesse
des Anwenders ist der für ihn zugute kommende Mehrwert durch die mobile Anwendung.
Trotz einer hohen Informationsfülle muss das System für den Moderator übersichtlich
und wartbar sein. Die Pflege der Information muss zentral geschehen. Änderungen
müssen transparent sein, so dass eine Informationsänderung keine Anpassung der mobilen Anwendung auslöst. Aus Sicht des Moderators ist eine Endanwendung, zum Beispiel
in Form eines Web-Interfaces, zur Informationspflege wünschenswert.
Der Administrator ist nicht an der Darstellung oder der Pflege der Information interessiert. Er verlangt eine einfache Installation des Servers und eine Wartbarkeit des Systems. Möglichst geringe anfallenden Kosten und einen akzeptablen Ressourcenverbrauch
(z.B. Speicherplatz, CPU-Last) werden erwartet. Die Möglichkeit Teile der Anwendung auf
verschiedene Server zu verteilen, stellt ein Qualitätsmerkmal für den Administrator dar.
Dem Systementwickler ist eine mögliche Wiederverwendung von Teilen des Systems
sowie die Integration neuer Module wichtig. Er verlangt ein System, dass in unterschiedlichen Schichten aufgebaut ist. Er erwartet eine hohe Abstraktion, um die Möglichkeit der
Wiederverwendbarkeit zu erhöhen. Deshalb sollte das System so abstrakt wie möglich
konzipiert werden und dadurch ein Framework für ähnliche Anwendungen darstellen.
5 Systemanalyse
Anforderungsbeitragende
Anwender
- 49 Verbindlichkeit
Pflicht
Art der Anforderung
Rahmenbedingung
Definition der Anforderung
einfache Installation
Datenschutz (Lokalisierung)
kalkulierbare Kosten
Qualität
hohe Geräteunterstützung
einfache Benutzbarkeit
hohe Verfügbar- und Zuverlässigkeit
Inhaltlich
Informationen zu Sehenswürdigkeiten
Möglichkeit der Lokalisierung
Orientierungshilfen mit Standortbezug
Darstellung von Texten und Bildern
hohe Informationsabdeckung
korrekte fundierte Informationen
Funktional
Interaktionsmöglichkeiten
Konfigurationsmöglichkeiten
eigenständige Ortung (z.B. GPS)
Optional
Funktional
Multimedia Informationen
zentrale Ortung (z.B. Funkzelle)
Moderator
Absicht
Funktional
Sprachwahl (z.B. Deutsch, Englisch)
Pflicht
Qualität
hohe zentrale Wartbarkeit
hohe Skalierbarkeit
hohe Erweiterbarkeit
hohe Verfügbarkeit
Änderungsauswirkung in Echtzeit
Administrator
Funktional
Editieren von Darstellungselementen
Absicht
Funktional
Web-Oberfläche (Informationspflege)
Pflicht
Rahmenbedingung
einfache Installation, Wartung
Qualität
akzeptabler Ressourcenverbrauch
geringe (Betriebs-) Kosten
hohe Zuverlässigkeit
hohe Erweiterbarkeit
Systementwickler
Absicht
Qualität
mögliche Skalierbarkeit (Verteilung)
Pflicht
Qualität
hohe Wiederverwendbarkeit
hohe Abstraktion
Modularität und Kapselung
Design unterteilt in Schichten
Tabelle 5 Kurzfassung der Systemanforderungen an den interaktiven Stadtführer
5 Systemanalyse
- 50 -
5.2 Anwendungsfälle
5.2.1 Essentielle Anwendungsfälle
Aus Anwendersicht muss es möglich sein, bestimmte lokale Einstellungen zu ändern oder
beliebige Seiten mit Informationen zu zum Beispiel Sehenswürdigkeiten anzuzeigen. Im
Normalfall möchte der Anwender zunächst die zu seinem Standort passende Übersichtsseite angezeigt bekommen. Hierfür muss es möglich sein, das Mobiltelefon automatisch
zu lokalisieren und die zu dem Ort des Anwenders passende Seite zu laden.
Der Moderator soll die Möglichkeit haben, die anzuzeigenden Informationen zu modifizieren. Damit diese Informationen bestimmten Lokationen zugeordnet werden können,
muss ein hierarchischer Namensraum geschaffen werden. Dieser eindeutige Namensraum
muss anhand der aktuellen Positionsdaten des Anwenders die gesuchten Informationen
auflösen können. Einstellungen, wie z.B. die gewählte Sprache oder die Adresse des Web
Services, sollen lokal am Mobiltelefon, alle anderen Daten zentral in zwei Datenbanken
gespeichert werden. Das in Abbildung 22 dargestellte UML-Anwendungsfalldiagramm
zeigt die essentiellen (engl. essential) Anwendungsfälle des zu erstellenden Systems.
interaktiver Stadtführer
<<essential>>
Einstellungen ändern
Local
Mobiltelefoneinstellungen
<<essential>>
Anwender lokalisieren
Anwender
<<essential>>
Seite anzeigen
DB
Namensauflösung
<<essential>>
Namensraum ändern
Moderator
<<essential>>
Information ändern
Abbildung 22 Essentiellen Anwendungsfällen des interaktiven Stadtführers
DB
Seiteninformation
5 Systemanalyse
- 51 -
Die Tabellen 6-10 liefern eine detailiertere Beschreibung der in der Abbildung 22 dargestellten essentiellen Anwendungsfälle. Der strukturelle Aufbau der Beschreibung der
essentiellen Anwendungsfälle ist aus [Oestereich 2001] entnommen.
Name:
Einstellungen ändern <essential>>
Kurzbeschreibung:
Einstellungen, wie z.B. die gewählte Sprache, das einzusetzende Lokalisierungssystem oder die Adresse des Servers werden persistent und lokal auf dem mobilen Endgerät gespeichert.
Akteure:
Anwender
Auslöser:
Anwender möchte die geänderten Einstellungen speichern
eingehende Informationen: gewählte Sprache, gewähltes Lokalisierungssystem und
Adresse des Servers
Ergebnisse:
veränderte Einstellungen, die auch nach einem Neustart der
Anwendung vorhanden sind
Nachbedingungen:
laufende Anwendung wird auf die neuen Einstellungen
angepasst (z.B. Änderung der Sprache)
Ablauf:
1.
2.
3.
4.
Anzeige der aktuellen Einstellungen
Anwender speichert modifizierte Einstellungen
persistente Speicherung der Einstellungen
Einstellungen der laufenden Anwendung aktualisieren
Tabelle 6 „Einstellungen ändern“, ein Anwendungsfall des interaktiven Stadtführers
Name:
Anwender lokalisieren <essential>>
Kurzbeschreibung:
Die Position des Anwenders wird lokalisiert und die Anzeige
der zu dem Standort passenden Information wird ausgelöst.
Akteure:
Anwender
Auslöser:
Anwender möchte die zu seinem Standort passenden Informationen angezeigt bekommen
Vorbedingungen:
ein gültiges Lokalisierungssystem ist ausgewählt
Ergebnisse:
eine symbolische Adresse, die für den Aufruf der Informationen verwendet wird
Nachbedingungen:
automatisches Anzeigen der Seite mit der ermittelten symbolischen Adresse
Ablauf:
1. Positionsermittlung durch Lokalisierungssystem(e)
2. Transferierung der Positionsdaten in absolute Daten
3. Auflösung der absoluten Positionsdaten in eine symbolische Adresse
Tabelle 7 „Anwender lokalisieren“, ein Anwendungsfall des interaktiven Stadtführers
5 Systemanalyse
- 52 -
Name:
Seite anzeigen <essential>>
Kurzbeschreibung:
Eine Seite (z.B. mit Informationen zu einer Sehenswürdigkeit) wird auf dem Display des Mobiltelefons dargestellt.
Akteure:
Anwender
Auslöser:
Anwender wählt im Menü eine Seitenverknüpfung aus oder
führt eine Lokalisierung durch, dessen Nachbedingung ein
Seitenaufruf ist
Vorbedingungen:
eine gültige Adresse zur Identifizierung der Seite
eingehende Informationen: die Adresse der aufzurufenden Seite
Ergebnisse:
eine neue Seite wird auf dem Display angezeigt
Nachbedingungen:
Aktualisierung des Menüs (Verknüpfung zu anderen Seiten)
Ablauf:
1. laden der gewünschten Seiten
2. darstellen der Seite auf dem Display des Mobiltelefons
Tabelle 8 „Seite anzeigen“, ein Anwendungsfall des interaktiven Stadtführers
Name:
Namensraum ändern <essential>>
Kurzbeschreibung:
Zu Positionsdaten wird eine Namensauflösung zu einer
eindeutigen Adresse hinzugefügt, geändert oder gelöscht.
Akteure:
Moderator
Auslöser:
Der Moderator speichert eine neue oder veränderte
Namensauflösung oder löscht eine bestehende.
Vorbedingungen:
die gewählte Adresse ist noch nicht anderweitig vergeben
eingehende Informationen: absolute Positionsdaten und eine symbolische Adresse
Ergebnisse:
Bestätigung oder Ablehnung der Änderung
Nachbedingungen:
zu neuen Adressen sollten Informationen erstellt werden
Ablauf:
1. einbinden / auffinden der Positionsdaten in der Struktur
2. modifizieren / hinzufügen der Adresse
Tabelle 9 „Namensraum ändern“, ein Anwendungsfall des interaktiven Stadtführers
Name:
Information ändern <essential>>
Kurzbeschreibung:
Eine Seite mit Informationen über z.B. Sehenswürdigkeiten
wird neu angelegt, geändert oder gelöscht.
Akteure:
Moderator
Auslöser:
Der Moderator speichert die Veränderung der Seite.
Vorbedingungen:
Die Adresse der Seite ist im Namensraum eingetragen.
eingehende Informationen: Informationen der Seite
Ergebnisse:
Bestätigung oder Ablehnung der Änderung
Ablauf:
1. auffinden der symbolischen Adresse im Namensraum
2. modifizieren oder neu anlegen der Seite
Tabelle 10 „Information ändern“, ein Anwendungsfall des interaktiven Stadtführers
5 Systemanalyse
- 53 -
5.2.2 Systemanwendungsfälle
„Im Folgenden werden die essentiellen Anwendungsfälle aufgegriffen und konkretisiert.
Dabei werden nun auch konkrete Umgebungsbedingungen und Anforderungen berücksichtigt, auch solche die sich aus der technischen Architektur ergeben“ [Oestereich
2001]. Im Vordergrund dieser Diplomarbeit steht die Informationsaufbereitung auf dem
Mobiltelefon des Anwenders. Aus diesem Grund wird im Folgenden ausschließlich auf die
Konkretisierung der essentiell beschriebenen Anwendungsfälle „Anwender lokalisieren“
und „Seite anzeigen“ eingegangen.
Wie unter 5.1.2 geschildert, sollen auf dem Mobiltelefon des Anwenders nur Informationen dargestellt werden, die für den Standort des Benutzers relevant sind. Um dies zu
ermöglichen, muss das Mobiltelefon lokalisiert werden. Wie bereits dargestellt, wird
verlangt, dass die Anwendung so konzipiert ist, das verschiedene Lokalisierungssysteme
unterstützt werden. Im Kapitel 3 wurden die Merkmale der verschiedenen Systeme
vorgestellt. Im Falle des interaktiven Stadtführers wird eine Outdoor-Lokalisierung gefordert. GPS liefert die genauesten Daten für eine solche Lokalisierung, weshalb dieses
System konkret implementiert werden soll.
Die konkreten Systemanwendungsfälle des Anwendungsfalles „Anwender lokalisieren“
zeigt das Use-Case-Diagramm der Abbildung 23. Die Lokalisierung des Mobiltelefons
kann einerseits direkt beim Anwender wie z.B. über GPS, anderseits zentral am Server
wie z.B. über die Mobilfunkzelle stattfinden. Diese Tatsache muss entsprechend in dem
Design der Anwendung berücksichtigt werden.
Lokalisierung
DB
<<essential>>
Anwender lokalisieren
Namensauflösung
Anwender
GPS
Empfänger
Anwender über
GPS lokalisieren
Anwender über
Funkzelle lokalisieren
DB
Zelldaten des
Netzbetreibers
Abbildung 23 Anwendungsfälle der Lokalisierung beim interaktiven Stadtführer
5 Systemanalyse
- 54 -
Eine Namensauflösung von den Positionsdaten zu einer eindeutigen symbolischen
Adresse, die zum Aufruf der Informationsseite notwendig ist, soll unabhängig von dem
gewählten Lokalisierungssystem stattfinden. Um dies zu realisieren, müssen die Lokalisierungsdaten jedes einzelnen Systems zunächst in absolute allgemein gültige Positionsdaten transferiert werden. Die GPS-Positionsdaten sind bereits absolut und sollen
daher als Standard für das zu erstellende System verwendet werden. Die Lokalisierung
über die Mobilfunkzelle liefert eine eindeutige Zellen-Nummer, der eine absolute Position
zugeordnet werden muss. Anschließend kann die Namensauflösung genauso durchgeführt
werden wie es bei GPS der Fall ist.
Beim Anwendungsfall „Seite anzeigen“ ist zwischen einer lokal verfügbaren Seite und
einer Seite, die zunächst über das Internet vom Server bezogen werden muss, zu unterscheiden. Die Abbildung 24 verdeutlicht die konkreten Systemanwendungsfälle. Die
Startseite der Anwendung und die Fehlerseite sind Beispiele für lokale Seiten. Alle Seiten
mit Informationen, wie z.B. Sehenswürdigkeiten, müssen über das Internet geladen
werden. Dadurch kann sichergestellt werden, dass ein Moderator inhaltliche Änderungen
an den Informationen vornehmen kann, ohne dass ein Update der mobilen Anwendung
notwendig ist. Die Änderungen wirken sich wie gewünscht in Echtzeit aus.
Seitenaufruf
<<essential>>
Seite aufrufen
Anwender
lokal verfügbare
Seite aufrufen
entfernte Seite vom
Server aufrufen
DB
Seiteninformation
Abbildung 24 Anwendungsfälle der Seitenaufruf beim interaktiven Stadtführer
5 Systemanalyse
- 55 -
5.2.3 Anwendungsfall-Ablaufmodell
Im Folgenden werden die Abläufe einiger Anwendungsfälle in Form von Aktivitäsdiagrammen modelliert. Es wird ein vollständiger Ablauf mit möglichen Ausnahmen und Varianten dargestellt. Die Abbildung 25 zeigt den Ablauf des Anwendungsfalles „Anwender
lokalisieren“. Die Abbildung 26 stellt den Ablauf „Seite aufrufen“ dar.
Anwender lokalisieren
Anwender fordert zu seinem aktuellen
Standpunkt die passende Seite an
identifiziere verfügbares
Lokalisierungssystem
[Kein System vorhanden]
[System vorhanden]
ermittel die aktuellen
Positionsdaten
deaktiviere aktuelles
Lokalisierungssystem
[Systemfehler]
[Daten sind
nicht absolut]
[Transferfehler]
[Daten sind absolut]
transferiere in absolute
Positionsdaten
ermittel die
symbolische Adresse
Lokalisierungsfehler
ermittelte symbolische Adresse
Abbildung 25 Ablauf der Lokalisierung beim interaktiven Stadtführer
5 Systemanalyse
- 56 -
Seite aufrufen
Anwender fordert eine Seite an
prüfe ob gesuchte Seite
im lokalen Speicher
[vorhanden]
[nicht vorhanden]
prüfe ob eine lokale
Seite gesucht wird
[lokale Seite]
[keine lokale Seite]
ermittel Seite vom
entfernten Server
lade lokale Seite in den
lokalen Speicher
[Transferfehler]
[ok]
lade entfernte Seite in
den lokalen Speicher
Anzeige der
gewünschten Seite
keine Seite gefunden
Referenz auf Seite im lokalen Speicher
Abbildung 26 Ablauf des Seitenaufrufes beim interaktiven Stadtführer
5 Systemanalyse
- 57 -
5.3 Prototyp: Informationsdarstellung
Die Abbildung 27 zeigt einen Prototyp einer möglichen Informationsdarstellung auf dem
Mobiltelefon. Es wird die Lokalisierung des Anwenders am Fuldarer Dom gezeigt. Die Pfeile verdeutlichen einige der Interaktionsmöglichkeiten.
Stadtführer
Stadtführer
Willkommen auf der
Startseite des
Stadtführer. Diese
Anwendung ist Teil
der Diplomarbeit von
Olaf Lange.
Veränderungen der
Einstellungen überleben einen Neustart.
Lokalisierungssystem:
0 Automatisch
0 GPS
0 Lokalisierungsserver
Einstellungen
Beenden
Orten
Mehr
Fulda: Dom
Sie befinden sich vor
dem Fuldarer Dom.
Über das Menü erhalten Sie detailiertere
Informationen.
Orten
Mehr
Einstellungen
Wählen
Speichern
Fulda: Dom
Startseite
Dom: Architektur
Dom: Geschichte
Umgebung (Karte)
Fulda
Beenden
Wählen
Dom: Architektur
Der Dom mit einer
Länge von 99 Metern
und einer Kuppelhöhe
von 39m wird an der
Vorderseite von zwei
Türmen von 57 m
Höhe flankiert.
Zurück
Fulda: Karte
Mehr
Mehr
Fulda: Dom
Fulda
Fulda:
Fulda:
Fulda:
Fulda:
Fulda:
Zurück
Mehr
Schloss
Michaelskirche
Schlosspark
Orangerie
Dom
Wählen
Abbildung 27 Prototyp der Informationsdarstellung beim interaktiven Stadtführers
6 Anwendungsdesign
- 58 -
6 Anwendungsdesign
In diesem Kapitel wird das Design der zu erstellenden Anwendung vorgestellt. Das komplette System ist in mehrere Schichten aufgeteilt. Zuerst wird ein Gesamtüberblick über
die Anwendungsarchitektur geliefert. Anschließend werden die einzelnen Schichten detailiert beschrieben. Jede Schicht bietet den höher liegenden Schichten ein oder mehrere
Dienste an. Die Definition dieser Dienste beschreibt was eine Schicht anbietet, jedoch
nicht wie dieser Dienst erbracht wird. In diesem Kapitel werden die Dienstdefinitionen in
einem eingerahmten Text vor der Beschreibung der Diensterbringung dargestellt.
Dieses Kapitel beschreibt das zu erstellende System in erster Linie aus Sicht des Systementwicklers. Zum besseren Verständnis von Strukturen und Abläufen wird wie bereits im
vorigen Kapitel die standardisierte Beschreibungssprache Unified Modeling Language
(UML) eingesetzt. Nachfolgend werden einige Besonderheiten der in diesem Kapitel
dargestellten Klassendiagramme erläutert:
es wird ein Objekt erzeugt
es wird auf ein oder mehrere Objekte zugegriffen
Tabelle 11 Verwendeten Symbole in den UML-Klassendiagrammen
6 Anwendungsdesign
- 59 -
6.1 Anwendungsarchitektur
Das System beinhaltet mehrere Teil-Anwendungen, die auf unterschiedlichen Geräten
ausgeführt werden. Aus diesem Grund spricht man auch von einem verteilten System.
Der mobile Client (Mobiltelefon) dient als Benutzerschnittstelle. Auf dem Gerät werden
die Informationen dargestellt und Benutzereingaben entgegengenommen. Die Schnittstelle zwischen dem mobilen Clients und einem dienstanbietenden Internet-Server wird
auf Grund der im Kapitel 4.4 dargestellten Vorteile als Web Services modelliert. Dieser
Service greift auf einen Namensdienst zu und ist für die Informationsaufbereitung zuständig. Damit die Informationen und Inhalte der Anwendung gepflegt werden können, wird
ein Web-Client konzipiert. Über dessen grafisches Web-Interface kann der Moderator die
auf dem Mobiltelefon des Anwenders anzeigenden Informationen ändern. Damit dies
möglich ist, kommuniziert der Web-Client mit einem Web-Server. Der Server dient als
Schnittstelle zur Datenbank und als Informationsaufbereiter. Der Web Service kommuniziert mit dem mobilen Clients über das SOAP, während die HTML als Kommunikationsschnittstelle zwischen Web-Server und Web-Client dient. Die Datenspeicherung wird über
eine zentrale Datenbank realisiert. Sowohl der Web Service als auch der Web-Server
kommunizieren über die SQL mit dem Datenbankmanagementsystem (DBMS).
Abbildung 28 zeigt die zugrunde liegende mehrschichtige Client-Server-Architektur. Die
Aufteilung einer Anwendung in mehrere Schichten ist eine typische Vorgehensweise in
der Softwareentwicklung. Die Implementierung des Systems wird durch eine solche
Struktur deutlich vereinfacht, da innerhalb einer Schicht nur ein bestimmter Teil der
Gesamtanwendung realisiert werden muss. Die Aufteilung in Schichten ermöglicht eine
losere Kopplung zwischen der Darstellung, der eigentlichen Anwendungslogik und der Datenhaltung. Die Austauschbarkeit dieser Elemente wird dadurch sichergestellt, dass standardisierte Protokolle für die Kommunikation verwendet werden.
Auf die Konkretisierung und die Implementierung des Web-Clients und des Web-Servers
wird in dieser Diplomarbeit verzichtet. Möglich wäre die Implementierung eines offenen
Systems, welches die Informationspflege beliebigen Internet-Usern ermöglichen würde.
Sogenannte Wikis erfüllen diese Erwartung. Ein solches System müsste an die Bedürfnisse von Location Based Services(LBS) angepasst werden.
Sowohl der Web-Client als auch der mobile Client sind als Thin-Client konzipiert. Das
heißt, ihre Aufgabe besteht ausschließlich in der Ausgabe von Informationen und in der
Benutzerschnittstelle. Eine Ausnahme dieses Konzeptes stellt die Lokalisierung dar. Im
Falle von GPS übernimmt der mobile Client die Lokalisierung des Mobiltelefons.
6 Anwendungsdesign
- 60 -
Mobiler Client
Web-Client
Präsentationsschicht
Konfiguration
Darstellung
Darstellung
Konfiguration
Übertragungsschicht
Web
Service
SOAP über
HTTP
HTML über
HTTP
WebServer
Anwendungslogikschicht
Dialog-Agent
Namensauflösung
Lokalisierung
Informationsaufbereitung
Dialog-Agent
Namenspflege
Informationspflege
Datenzugriffsschicht
Datenzugriff
über SQL
Datenzugriff
über SQL
DBMS
Datenspeicherungsschicht
NamespaceDatenbank
ContentDatenbank
Abbildung 28 Die Client-Server-Architektur des interaktiven Stadtführers
(Anmerkung: Komponenten mit kursiver, nicht fett gedruckter Schrift sind optional und werden in dieser Diplomarbeit nicht implementiert)
6 Anwendungsdesign
- 61 -
6.2 Datenspeicherungsschicht
6.2.1 Namespace-Datenbank
Die Aufgabe der untersten Schicht der Anwendungsarchitektur
NamespaceDatenbank
ist die persistente Speicherung von Anwendungsdaten. Die Namespace-Datenbank speichert die Namenszuordnungen von
absoluten Positionsdaten zu symbolischen Adressen.
Für die Speicherung der Anwendungsdaten werden aufgrund der geforderten Modularität
und Skalierbarkeit zwei Datenbanken anstatt einer gemeinsamen konzipiert. Die Namespace-Datenbank ist in Abbildung 29 dargestellt. Diese Datenbank speichert die Positionsdaten und die damit verknüpften symbolischen Adressen, während die noch vorzustellende Content-Datenbank für die Speicherung der Informationsseiten zuständig ist.
Die Namespace-Datenbank setzt sich aus den Relationen Location und LocationDetail
zusammen. Als Primärschlüssel beider Relationen dient die symbolische Adresse, die konkret als URL modelliert wird. Das DNS speichert eine Zuordnung von Domainnamen zu
IP-Adressen. Ein vergleichbarer Namensraum wird in dieser Diplomarbeit realisiert. Jedoch anders als es bei dem DNS der Fall ist, kann eine Position (vgl. mit einer IPAdresse) nicht eindeutig einer URL zugeordnet werden. Gemeinsam ist beiden Namensräumen die Eindeutigkeit der Zusammensetzung der URL und der damit verbundenen
Hierarchie. Ein Gebiet, das durch eine Subdomain beschrieben wird, ist stets eine Teilmenge der Domain. Das Gebiet kann jedoch Gebiete anderer Subdomains schneiden.
Die Relation Location spezifiziert ungefähr die Konturen eines Gebiets durch ein Rechteck. Die Attribute latitude und longitude speichern die kleinsten Werte für die Breiten- und Längengrade dieses Gebietes. Die Attribute latiudeMask und longitudeMask
definieren die Entfernung zu dem höchst möglichen Breiten- und Längengrad-Werten.
latitude
url
latitudeMask
url
Location
longitude
1
longitudeMask
hat
0...n
number
LocationDetail
longitude
latitude
Abbildung 29 ER-Modell der Namespace-Datenbank zur Namensauflösung, Server
6 Anwendungsdesign
- 62 -
Der Vorteil der Beschreibung der Konturen eines Gebietes durch ein Rechteck liegt in der
Einfachheit. Durch eine passende SQL-Anweisung kann sehr effizient festgestellt werden,
ob ein Referenzpunkt innerhalb der Konturen liegt oder nicht. Die Abbildung 30 zeigt exemplarisch ermittelte absolute Positionsdaten von Sehenswürdigkeiten der Stadt Fulda.
In der Farbe Blau sind die durch die Relation Location beschriebenen Rechtecke eingezeichnet. Für das Schloss sind die zwei notwendigen Positionsdaten in blauen Ziffern
angegeben, analog sind die Positionsdaten anderer Gebiete abzulesen. Insbesondere
beim Schloss wird die Ungenauigkeit dieses Verfahrens deutlich. Das Rechteck beschreibt
nur eine ungefähre, nicht ausreichend genaue Position des eigentlichen Gebietes.
In der Relation LocationDetail werden detailierte Positionsdaten gespeichert. Mit Hilfe
dieser Daten ist es möglich, ein Gebiet nicht nur als eine Rechteck, das parallel zu den
Breiten- und Längengraden angeordnet sein muss, sondern exakt als ein Polygon zu
beschreiben. In der Abbildung 30 sind die exakten Positionsdaten exemplarisch für das
Schloss mit roten Ziffern angegeben. Die Punkte werden mit einer laufenden Nummer
durchnummeriert. Zu einem Gebiet kann es beliebig viele detailierte Positionsdaten geben. Prinzipiell würde die Beschreibung eines Gebietes über die LocationDetails Relation für eine Gebietsbestimmung ausreichen. Die ungenaue Bestimmung über die Location
Relation ermöglicht jedoch eine grobe Filterung der womöglichen großen Anzahl von
vorhandenen Gebieten. Dadurch müssen deutlich weniger Tupel der LocationDetail Relation ausgewertet werden, was erheblich Rechenleistung spart.
Längengrad
(longitude)
50°33.x
3500
Michaels
kirche
6358/
3177 (2)
Orangerie
3000
7170/
2893 (3)
Schloss
2500
Dom
4674/
2207 (1)
2000
4674/
1800
1500
2500
7170/
3177
3000
3500
4000
4500
5220/
1800 (0)
5000
5500
6000
Breitengrad
6500 (latitude)
9°40.x
Abbildung 30 Positionsdaten und -speicherung von Sehenswürdigkeiten in Fulda
Legende: blau: exakte Konturen der Gebiete, rot: grobe Konturen der Gebiete
6 Anwendungsdesign
- 63 -
6.2.2 Content-Datenbank
Aufgabe der Content-Datenbank ist die persistente Spei-
ContentDatenbank
cherung aller Informationsseiten. Jede Seite setzt sich aus verschiedensten Elementen und Befehlen zusammen. Diese Zusammenhänge müssen in der Datenbank abgebildet werden.
Die Abbildung 31 zeigt für die Content-Datenbank das zugrunde liegende ERR-Modell.
Das Modell ist abstrakt definiert und nicht auf Informationen zu Sehenswürdigkeiten wie
im Falle des interaktiven Stadtführers beschränkt. Die Anforderungen an das System bezüglich einer hohen Erweiter- und Wiederverwendbarkeit werden dadurch befriedigt, dass
das gesamte Design unabhängig von den darzustellenden Informationen ist. Sowohl das
dargestellte ERR-Modell als auch die restliche Anwendung ist so konzipiert, dass sogar
unterschiedliche Sprachen unterstützt werden.
Eine Seite (engl. Page) setzt sich aus mehreren Befehlen (engl. Commands) und
Elementen (engl. Items) zusammen. Ein Element kann unterschiedlichsten Typs sein. In
dieser Diplomarbeit werden nur Text-Elemente (engl. StringItem) und Bild-Elemente
(engl. ImageItem) verwendet. Die Abbildung 31 zeigt entsprechende Relationen für diese
Elemente. Relationen für andere Elemente, wie z.B. Textfelder (engl. TextField) oder
Auswahlfelder (engl. ChoiceGroup) werden in diesem Design konzeptionell berücksichtigt, jedoch in dieser Diplomarbeit nicht implementiert. Alle Elemente haben gemeinsam, dass sie eine Spezialisierung der Relation Item darstellen. Zu einem späteren Zeitpunkt wird dargestellt, wie eine Vererbung zur Darstellung der Elemente in der Programmiersprache eingesetzt wird. Die im ERR-Modell verwendete Generalisierung bildet diese
Abstraktion entsprechend auf Datenbankebene ab (vgl. [Elmasri 2002]).
Die Struktur einer jeden Seite ist unabhängig von der gewählten Sprache. Hingegen unterscheiden sie sich von dem darzustellenden Text. Aus diesem Grund werden alle Texte
in der Relation Translation abgebildet. Beispielsweise wird in der Relation Page definiert, dass eine Seite einen Titel haben kann. Dieser Titel ist natürlich sprachabhängig,
weswegen nur eine Referenz durch eine TextId gespeichert wird. In der Relation Translation wird die eigentliche Übersetzung für jede Sprache gespeichert. Beispielsweise
wird definiert, dass der Titel einer Seite mit Informationen zur Architektur im englischen
als „Architecture“ und im Deutschen mit „Architektur“ übersetzt werden soll. Die verfügbaren Sprachen speichert die Relation Language.
6 Anwendungsdesign
- 64 -
url
url
titleTextId
1
labelTextId
commandId
1
Page
type
hat
0...n
Command
0...n
0...n
priority
forwardUrl
hat
hat
languageId
textId
0...n
name
0...n
Language
Text
hat
textId
1
0...n
1
0...n
language
1
Translation
1
translation
hat
hat
itemId
0...n
0...n
url
0...n
StringItem
Item
itemType
textTextId
itemId
labelTextId
d
itemId
altText
ImageItem
image
layout
TextField
DateField
Gauge
ChoiceGroup
Abbildung 31 ERR-Modell der Content-Datenbank für die Inhaltsspeicherung, Server
(Anmerkung: Gestrichelte Relationen sind optional und werden in dieser Diplomarbeit nicht implementiert)
6 Anwendungsdesign
- 65 -
6.3 Datenzugriffsschicht
Die Datenzugriffsschicht bietet den höher liegenden Schich-
Datenzugriff
über SQL
ten einen Dienst an, der gezielt bestimmte Inhalte aus den Datenbanken Namespace und Content ausliest. Die Kapselung des
Zugriffes auf diese Datenbanken ist die Aufgabe dieser Schicht.
Der Datenbankzugriff wird über Klassen des Paketes webservice.dataaccess realisiert.
Die Abbildung 32 zeigt das zugehörige Klassendiagramm. Für den Zugriff wird für jede
Datenbank eine eigene Klasse bereitgestellt. Für die Namespace Datenbank steht die
Klasse NamespaceQuery, für die Content Datenbank die Klasse ContentQuery zur Verfügung. Die public-Methoden von Objekten dieser Klassen ermöglichen anderen Paketen Informationen aus der Datenbank abzufragen. Intern erzeugen Objekte der dargestellten
Klassen SQL-Anweisungen (engl. SQL statements), die über Objekte der Klasse DBConncetor auf der jeweiligen Datenbank ausgeführt werden. Die vorgestellte Kapselung des
Datenzugriffs bieten den Vorteil, dass die Datenspeicherung für andere Pakete transparent ist und somit beliebig erweitert oder ausgetauscht werden kann.
webservice
nameservice
NameService
dataaccess
hat
1
contentservice
ContentService
NamespaceQuery
+NamespaceQuery()
+getURLs()
+getLocationDetails()
ContentQuery
+ContentQuery()
hat +getPage()
1 +getItemDetails()
+getItems()
+getText()
+getTopPages()
+getSubPages()
hat
1
hat
DBConnector
#DBConnector()
#getResultSet()
1
Abbildung 32 Klassendiagramm der Schicht „Datenzugriff“, Web Service
6 Anwendungsdesign
- 66 -
6.4 Anwendungslogikschicht
6.4.1 Namensauflösung
Die Namensauflösung bietet einen Dienst an, über den abso-
Namensauflösung
lute Positionsdaten zu einem passenden symbolischen Namen
(URL) aufgelöst werden. Die konkrete Implementierung wird
vor anderen Schichten bzw. Paketen gekapselt.
Die Namensauflösung wird über das Paket webservice.nameservice bereitgestellt (siehe
Abbildung 33). Der eigentliche Dienst ist in der Klasse Nameservice realisiert. Die Klasse
benutzt ein Objekt der Klasse NamespaceQuery aus dem Paket webservice.nameservice
für die Datenbankabfrage. Der Zugriff von anderen Paketen auf diesen Dienst erfolgt
nicht direkt über die Klasse Nameservice, sondern ist durch eine Fassade (engl. Facade)
von dem restlichen System abgeschirmt. „Das Fassadenmuster fördert die lose Kopplung
zwischen dem Subsystem und seinem Klient“ [Gamma 2004]. Durch den Einsatz der
Fassade wird eine feste Schnittstelle zu dem Dienst der Namensauflösung definiert. Die
eigentliche Realisierung des Dienstes ist für andere Pakete transparent. Durch die
Fassade ist es möglich, die Namensauflösung unabhängig zu implementieren oder das
System zu verteilen, ohne dass Klassen anderer Pakete (in diesem Fall die Klasse Controller) verändert werden müssen.
webservice
nameservice
Controller
benutzt
1
NameserviceFacade
+NameserviceFacade()
+getURL()
1
verwaltet
dataaccess
Nameservice
#Nameservice()
#getURL()
#getURLStrict()
benutzt
NamespaceQuery
1
Abbildung 33 Klassendiagramm der Schicht „Namensauflösung“, Web Service
6 Anwendungsdesign
- 67 -
6.4.2 Informationsaufbereitung
Die Informationsaufbereitung verpackt die Inhalte einer be-
Informationsaufbereitung
stimmten Seite in ein DOM-Element. Die Seite wird über ihre
eindeutige URL adressiert und kann verschiedenste Unterelemente, wie z.B. Text oder Bilder beinhalten.
Die Abbildung 35 zeigt das Klassendiagramm der Pakete webservice.contentservice
und webservice.elements. Das erste Paket beinhaltet eine Fassade, die wie die Fassade
zur Namensauflösung, eine einheitliche Schnittstelle zu dem restlichen System zur Verfügung stellt. Die Nameservice-Schnittstelle liefert eine URL zurück, während die Contentservice-Schnittstelle eine Referenz auf ein Objekt der Klasse Component aus dem Paket
elements liefert.
Das Paket elements stellt eine Umsetzung des Entwurfmusters Kompositum dar. Die abstrakte Klasse Component definiert die Schnittstelle zum Zugriff auf alle Kindobjekte. Die
Klasse Page ist ein Kompositum, da Objekte dieser Klasse selbst wieder Objekte der
Klasse Component beinhalten können. Bei der Informationsdarstellung gibt es verschiedene Elemente, die über ähnliche Merkmale verfügen. Aus diesem Grunde wurde die abstrakte Klasse Item eingeführt. Die Klassen StringItem zur Darstellung von Text und
die Klasse ImageItem zur Darstellung von Bildern sind Unterklassen der Item Klasse.
Möchte man das System durch Auswahlfelder, Regler, Textfelder oder Datumsfelder (vgl.
Kapitel 4.3.2) erweitern, müssten entsprechende Unterklassen der Item Klasse implementiert werden. An dieser Stelle wird der Vorteil der Verwendung eines Kompositums
deutlich. Eine Erweiterung der Struktur durch z.B. Textfelder führt zu keiner Veränderung
in der Klasse Controller. Außerhalb des Paketes wird jede Komponente (engl.
Component) identisch behandelt, unabhängig davon, ob es sich um eine Seite (engl.
Page) oder nur um ein einfaches Element wie ein Textelement (engl. StringItem) handelt.
In der Datenbank sind in mehreren Relationen alle zu einer Seite gehörigen Elemente
gespeichert. Damit die Struktur in Objekten abgebildet werden kann, ermittelt ein Objekt
der Klasse Contentservice des Paketes webservice.contentservice die Seiteninformationen. Anschließend wird ein Objekt der Klasse ElementFactory des Paketes webservice.element zur Erstellung des Kompositums benutzt. Durch diese Fabrik (engl.
Factory) wird das Erzeugen des Kompositums von anderen Paketen gekapselt.
6 Anwendungsdesign
- 68 -
webservice
contentservice
ContentserviceFacade
benutzt
1
+ContentserviceFacade()
+getComponent()
dataaccess
verwaltet
1
Controller
benutzt
1
Contentservice
ContentQuery
#Contentservice()
#getComponent()
benutzt
greift zu
1
elements
1
ComponentFactory
Component
#Component()
+getDOMElement()
Page
#Page()
+getSOAPElement()
Sphere
#Sphere()
+getDOMElement()
+ComponentFactory()
+createPage()
+createPages()
+createStringItem()
+createImageItem()
+createSphere()
Pages
#Pages()
+getDOMElement()
#addSubpage()
StringItem
#StringItem()
+getDOMElement()
Item
#Item()
+getDOMElement()
ImageItem
#ImageItem()
+getDOMElement()
Abbildung 34 Klassendiagramm der Schicht „Informationsaufbereitung“, Web Services
6 Anwendungsdesign
- 69 -
6.4.3 Lokalisierung
Die Lokalisierung ist für die Ortung des Mobiltelefons und die
Lokalisierung
Ermittlung der absoluten Positionsdaten zuständig. Die Lokalisierung kann sowohl beim Anwender als auch zentral stattfinden.
In dieser Diplomarbeit wird die Lokalisierung über GPS und somit durch den mobilen Client realisiert. Das Klassendiagramm des Paketes mobileclient.locator zeigt die Abbildung 35. Die serverseitige Implementierung eines ähnlichen Paketes, könnte die Lokalisierung über die Mobilfunkzelle oder andere Lokalisierungssysteme realisieren.
mobileclient
benutzt
locator
<<realize>>
1
<<interface>>
LocatorListener
LocatorCreator
hat
+setLocation()
1
Location
Controller
+OK
verwaltet +REFRESHING
+ERROR_BLUETOOTH
1
+ERROR_DEVICE
+ERROR_CONNCETION
+ERROR_CONVERT
+NO_LOCATION_DATA
+LocatorCreator()
+getLocator()
+getLocatorType()
+destroyAllLocator()
Locator
#LocatorListener
#Locator()
+isActive()
+setActive()
+getLocation()
#destroyLocator()
+Location()
+getLatitude()
+getLongitude()
+getType()
GPSLocator
greift zu
1
WebserviceLocator
#WebserviceLocator()
+getLocation()
#destroyLocator()
#GPSLocator()
+getLocation()
+serviceDescovered()
+serviceSearchCompleted()
+deviceDiscovered()
+inquiryCompleted()
#destroyLocator()
Abbildung 35 Klassendiagramm der Schicht „Lokalisierung“, hier mobiler Client
6 Anwendungsdesign
- 70 -
Die abstrakte Klasse Locator definiert die Schnittstelle, die ein Lokalisierungssystem
aufweisen muss. Durch die Abstraktion kann ein Klient (in diesem Fall die Klasse Controller) jedes Lokalisierungssystem identisch behandeln. Es wird ein LocatorListener
als Interface definiert. Dadurch ist ein asynchroner Methodenaufruf von Klients beim Locator möglich. Das Interface stellt sicher, dass der Klient nicht auf den Rückgabewert
(z.B. der Positionsdaten) warten muss. Er muss nicht blockieren und wird über das Interface über die ermittelten Positionsdaten oder andere Ereignisse informiert.
Die Auswahl des Lokalisierungssystems und die damit unmittelbar verbundene Objekterzeugung eines konkreten Systems (z.B. WebserviceLocator oder GPSLocator) wird
vom restlichen System durch die Klasse LocatorCreator gekapselt. Ein Klient (in
diesem Fall die Klasse Controller) muss nicht über das konkrete System informiert sein.
Die eigentliche Auswahl des zu verwendenden Systems ist Aufgabe der Klasse LocatorCreator. Dadurch ist es möglich, ein neues Lokalisierungssystem, z.B. eine Lokalisierung
über Bluetooth oder WLAN, einzubinden, ohne dass ein Klient darüber informiert werden
muss. Hierfür müsste eine neue Unterklasse von Locator implementiert und eine entsprechende Anpassung der Klasse LocatorCreator vorgenommen werden. Das Sequenzdiagramm der Abbildung 36 zeigt das mögliche Zusammenspiel der Klasse Controller
mit dem Paket mobileclient.locator. Über das Interface LocatorListener liefert der
Locator ein Objekt der Klasse Location, welches die ermittelten Positionsdaten
beinhaltet. Dieses Positionsdaten können für die Namensauflösung verwendet werden.
Anwender lokalisieren
:Controller
Anwendung
wird gestartet
Aktuelles Lokalisierungssystem ermitteln
Absolute Position ermitteln
new()
locatorCreator:
LocatorCreator
getLocator()
new()
locator
locator:
GPSLocator
getLocation()
new()
Eintreten der
Positionsdaten
(Interface)
location:
Location
setLocation(location)
Abbildung 36 Zusammenspiel beteiligter Klassen bei der Mobiltelefon-Lokalisierung
6 Anwendungsdesign
- 71 -
6.4.4 Dialog-Agent
Der Dialog-Agent horcht auf Anfragen von Clients und stellt
Dialog-Agent
die Schnittstelle zum Web Service zur Verfügung. Über das
SOAP werden angeforderte Seiten bzw. URLs von Seiten an den
Client zurückgegeben.
Die Abbildung 37 zeigt das Klassendiagramm des Paketes webservice. Eingehende
Anfragen von Clients werden über den generierten Web Service direkt an ein Objekt der
Klasse Controller weitergeleitet. Handelt es sich um eine Anfrage bezüglich einer
Namensauflösung, so wird die NameserviceFacade für die Generierung der Antwort
(engl. response) verwendet. Handelt es sich um eine Anfrage bezügliche einer Informationsseite, wird die ContentserviceFacade benutzt. Diese liefert eine Referenz auf ein
Objekt der Klasse Component, über die ein DOM-Element ermittelt wird. In jedem Fall
übergibt der Controller eine SOAP-Nachricht als Rückgabewert an das aufrufende
Servlet.
webservice
nameservice
NameserviceFacade
benutzt
1
contentservice
Controller
#getURL()
#getContent()
ContentserviceFacade
benutzt
1
elements
greift zu
1
Component
Abbildung 37 Klassendiagramm der Schicht „Dialog-Agent“, Web Service
6 Anwendungsdesign
- 72 -
6.5 Übertragungsschicht
Die Übertragungsschicht dient dem Nachrichtenaustausch
SOAP über
HTTP
zwischen den mobilen Clients und dem Web Serivce. Die Nachrichten werden mit Hilfe des standardisierten Protokolls SOAP
über eine HTTP-Verbindung übertragen.
Die Abbildung 38 zeigt die beteiligten Klassen beim Nachrichtenaustausch zwischen den
mobilen Clients und dem Web Service. Die Clients agieren aktiv. Sie stellen eine Anfrage
(engl. request) an den Server, der wiederum eine Antwort (engl. response) generiert und
diese an den Client zurückschickt. Ein Server ist in der Regel für mehrere Clients zuständig.
Der Nachrichtenaustausch wird über das SOAP realisiert. Die Nutzdaten der SOAP-Nachricht werden in XML kodiert. Durch das gewählte Design wird eine Plattform und Programmiersprachen unabhängige standardisierte Schnittstelle für den Datenaustausch definiert. Im Kapitel 4.4 wurden einige Vorteile von SOAP und XML dargestellt.
1
mobileclient
locator
PageCreator
webservice
...
n
mobileclient
HTTP Verbindung
(SOAP-Protokoll)
MyServlet
locator
PageCreator
Abbildung 38 Nachrichtenaustausch der mobilen Clients mit dem Web Service
6 Anwendungsdesign
- 73 -
6.6 Präsentationsschicht
6.6.1 Darstellung
Die Präsentationsschicht stellt die oberste Schicht in der
Darstellung
Anwendungsarchitektur dar. Sie ist für die Darstellung der Informationen auf dem Mobiltelefon des Anwenders und der damit
verbundenen Dialog-Steuerung verantwortlich.
Die Abbildung 39 zeigt das Klassendiagramm der Pakete mobileclient und mobileclient.pages. Letzteres Paket speichert alle Informationen, die für die Darstellung einer
Seite notwendig sind. Jede Seite wird durch ein Objekt der Klasse Page repräsentiert. Zu
dieser Klasse gibt es Unterklassen, die spezielle lokale Seiten darstellen. Im konkreten
Fall ist dies die Startseite (Klasse HomePage) sowie die Einstellungsseite (Klasse SettingPage). Die Klassen CommandFeatures und ItemFeatures stellen Hilfsklassen für die
Klasse Page dar. In ihr werden spezielle Merkmale von Befehlen (engl. command) beziehungsweise Elementen (engl. item) für die interne Verarbeitung gespeichert.
Ein Klient (im konkreten Fall die Klasse Controller) greift von den genannten Klassen
nur auf Methoden der Klasse Page zu. Der Konstruktor der Klasse Page ist als protected
deklariert, weswegen kein direktes Erzeugen von Objekten dieser Klasse außerhalb des
Paketes möglich ist. Der Controller kann somit keine Seiten selbstständig erzeugen,
sondern benutzt ein Objekt der Klasse PageCreator zum Erzeugen dieser Objekte. Der
Vorteil liegt darin, dass die Klasse Controller nicht wissen muss, ob eine Seite lokal
verfügbar ist (wie z.B. die Seite zum Editieren der Einstellungen) oder ob die Informationen erst über das Internet auf das Mobiltelefon geladen werden müssen. Es ist die Aufgabe der Klasse PageCreator die Informationen gegebenenfalls über den Web Service
zu laden. Damit der Controller nicht auf einen Rückgabewert des Objektes der Klasse
PageCreator warten muss, wurde das Interface PageListener definiert. Das Laden
einer Seite oder einer URL einer Seite geschieht asynchron. Der Controller wird nicht
blockiert, sondern vom Objekt der Klasse PageCreator über das Interface informiert,
wenn neue Informationen vorliegen.
Die Klasse MyMIDlet stellt das MIDlet der mobilen Anwendung zur Verfügung. MyMIDlet
erzeugt ein Objekt der Klasse Controller. Alle eintreffenden Ereignisse werden an dieses
Objekt weitergeleitet. Der Controller hält wiederum eine Referenz auf das MIDlet.
6 Anwendungsdesign
- 74 -
mobileclient
Controller
MyMIDlet
+commandAction()
+itemStateChanged()
#startApp()
#pauseApp()
#destroyApp()
#setContent()
#setAlert()
1
pages
#Controller()
+setLocation()
+setAlert()
verwaltet +setPage()
+setPageURL()
+setConfigChange()
#setCommandAction()
#setItemStateChanged()
#destroyApplication()
greift zu
<<realize>>
benutzt
n
Page
CommandFeatures
#LINK_COMMAND
#SEND_COMMAND
+PAGE_EXIT
+PAGE_LOCATE
#CommandFeatures()
#getCommandType()
#getLinkPageURL()
#Page()
+getForm()
+getCommandAction()
+getItemStateChanged()
#addItem()
#addCommand()
#detectedCommand()
n
greift zu
ItemFeatures
#STRINGITEM
#TEXTFIELD
#DATEFIELD
#GAUGE
#CHOICEGROUP
#IMAGEITEM
#ItemFeatures()
#getItemType()
#getListenerActions()
#setValue()
#getValue()
greift zu
n
HomePage
<<interface>>
PageListener
+setAlert()
+setPageURL()
+setPage()
1
greift zu
PageCreator
+PageCreator()
+getPageURL()
+getPage()
SettingPage
+PAGE_URL
+PAGE_URL
#HomePage()
#SettingPage()
#detectedCommand()
Abbildung 39 Klassendiagramm der Schicht „Darstellung“, mobiler Client
1
6 Anwendungsdesign
- 75 -
6.6.2 Konfiguration
Aufgabe der Konfiguration ist die persistente Speicherung der
Konfiguration
Einstellungen auf dem Mobiltelefon. Die Aufbereitung und Bereitstellung dieser Einstellungen für alle Klassen der mobilen
Anwendung ist ebenfalls notwendig.
Die Abbildung 40 zeigt das Klassendiagramm des Paketes mobileclient.settings. In
diesem Paket ist die komplette Konfiguration für die mobile Anwendung definiert. In der
Abbildung wird exemplarisch das Zusammenspiel der Klasse Controller mit diesem Paket gezeigt. Eine ganze Reihe von weiteren Klassen greifen auf die gleiche Weise auf
dieses Paket zu. Damit die Konfiguration für alle Klassen identisch ist, wird die Klasse
Configuration als ein Singleton definiert. Über dieses Objekt kann auch auf ein Objekt
der Klasse Language zugegriffen werden. Implementiert ein Klient das Interface ConfigListener, wird er stets über Änderungen in der Konfiguration informiert.
mobilclient
greift zu
settings
<<realize>>
<<interface>>
ConfigListener
+CHANGE_SERVICE_URL
+CHANGE_SYSTEM
+CHANGE_LANGUAGE
+setConfigChange()
Controller
greift zu
1
Language
#Language()
+getCommandLabel()
+getPageTitle()
+getItemLabel()
+getStringItem()
+getAlertTitle()
+getAlertString()
1
Configuration
hat
1
+SYSTEM_AUTOMATIC
+SYSTEM_GPS
+SYSTEM_WEBSERVICE
+LANGUAGE_ENGLISH
+LANGUAGE_GERMAN
+getInstance()
+setConfigListener()
+getLanguage()
+getLanguageID()
+getLocationsystem()
+getServiceURL()
+setLanguage()
+setLocationsystem()
+setServiceURL()
+setDefaultSettings()
GermanLanguage
#GermanLanguage()
Abbildung 40 Klassendiagramm der Konfiguration, mobiler Client
6 Anwendungsdesign
- 76 -
7 Implementierung
Dieses Kapitel beschreibt die konkrete Implementierung des interaktiven Stadtführers.
Im vorigen Kapitel wurden mehrere Anwendungsschichten definiert. An Hand dieser
Struktur wird die konkrete Implementierung erläutert. Auf Grund der Komplexität der
Anwendung werden im Folgenden nur bestimmte Implementierungsdetails vorgestellt.
Die gesamte Anwendung setzt sich aus folgenden Paketen zusammen:
Web Service
Mobiler Client
webservice
mobileclient
webservice.contentservice
mobileclient.locator
webservice.dataaccess
mobileclient.pages
webservice.nameservice
mobileclient.settings
webservice.topics
Tabelle 12 Übersicht über die Pakete der Anwendung des interaktiven Stadtführeres
Der Web Service wird durch einen Applikation Server auf einem dieser Diplomarbeit zur
Verfügung stehenden Testsystem angeboten. Die URL lautet: http://olaflange.homelinux.org/webservice. Die Datenbank wird durch einen MySQL-Server auf dem Testsystem
bereitgestellt. Zur Ausführung des mobilen Clients dient das Mobiltelefon K750i von Sony
Ericsson. Die GPS-Maus Holux GR-230 versorgt das Mobiltelefon mit Positionsdaten. Die
Installation der notwendigen Software ist in der Anlage A beschrieben.
Der komplette Quellcode des Systems liegt dieser Diplomarbeit bei. Eine ausführliche Dokumentation ist aus dem generierten JavaDoc, der ebenfalls dieser Arbeit beiliegt, zu entnehmen. Sowohl die Dokumentation als auch der Quellcode ist in englischer Sprache.
7 Implementierung
- 77 -
7.1 Datenspeicherungsschicht
Im vorigen Kapitel wurden eine Namespace Datenbank für die Speicherung der Daten zur
Namensauflösung und eine Content Datenbank für die Speicherung der eigentlichen Informationsseiten konzipiert. Als DBMS wird MySQL eingesetzt. Dieses System ist OpenSource und somit kostenlos verfügbar. MySQL erfüllt die Erwartungen an eine relationale
Datenbank, wie sie durch das Design der Anwendung verlangt wird.
Die Open-Source Anwendung phpMyAdmin ermöglicht einen direkten Zugriff auf den
MySQL-Server. Die für den interaktiven Stadtführer konzipierten Datenbanken und Relationen können über diese Anwendung angelegt werden. Um diesen Vorgang zu
vereinfachen wurden SQL-Anweisungen (engl. SQL statements) erzeugt, welche die Relationen automatisch anlegen. Diese und weitere Anweisungen für die Erzeugung von
einigen Tupeln sind in den beigefügten Dateien dieser Diplomarbeit zu finden.
7.2 Datenzugriffsschicht
Der Datenbankzugriff erfolgt über das Paket webservice.dataaccess. Die Klasse DBConnector benutzt das JDBC API für MySQL. Die Abbildung 43 zeigt einen Teil der Methode getResultSet(), die dieses API nutzt, um SQL-Anweisungen auf den Datenbanken
auszuführen. Um mehrere Anfragen über eine Datenbankverbindung zuzulassen, wird die
Verbindung, anders als dargestellt, erst nach einer bestimmten Leerlaufzeit beendet.
/* [...] class and method definition not specified in this example
*/
Connection connection = null; // database connection
Statement statement = null; // statement to performed a query
ResultSet resultSet = null; // contain the results of the query
try {
/* get mysql driver and connect to database
*/
Class.forName(DRIVER).newInstance();
connection = DriverManager.getConnection(URL,USERNAME, PASSWORD);
/* execute query (for example: “SELECT * FROM PAGE“)
*/
statement = connection.createStatement(); // get new statement
resultSet = statement.executeQuery(query); // get result set of query
/* close connection to database
connection.close();
}
catch (Exception exception) {} // exception not specified
Abbildung 41 Quellcode-Ausschnitt des MySQL Datenzugriffes, Klasse DBConnector
*/
7 Implementierung
- 78 -
7.3 Anwendungslogikschicht
7.3.1 Namensauflösung
Im Design des interaktiven Stadtführers wurde eine Struktur für die Speicherung der Positionsdaten (siehe Kapitel 6.2.1) festgelegt. Mit Hilfe dieser Daten wird ein Dienst implementiert, welcher zu einer gegebenen Position eine symbolischen Adresse ermittelt.
Nachfolgend wird der zugrunde liegende Algorithmus anhand eines Beispieles erläutert.
Die Abbildung 41 verdeutlicht die Zusammenhänge. Auf die Darstellung des Quelltextes
wird an dieser Stelle verzichtet.
Im ersten Schritt ermittelt der Algorithmus alle Gebiete für die gilt, dass eine gegebene
Referenzposition in den groben Konturen des Gebietes liegt. Die Datenzugriffsschicht
stellt einen entsprechenden Dienst zur Verfügung. In der Abbildung 41 sind die Referenzpositionen (P1-P3) in der Farbe Grün eingezeichnet. Die groben Konturen der Gebiete
sind in der Farbe Blau dargestellt. Aus der Abbildung wird deutlich, dass alle Referenzpositionen in den groben Konturen des Doms, hingegen nur die Positionen P1 und P2 in den
groben Konturen der Michaelskirche liegen. Die exakten Konturen sind durch die Farbe
Rot gekennzeichnet. Die Position P1 befindet sich zwar innerhalb der groben Kontur der
Michaelskirche, jedoch nicht innerhalb der exakten Kontur. Im ersten Schritt wird die Position P1 jedoch dem Gebiet der Michaelskirche zugeordnet.
Längengrad
(longitude)
50°33.x
Dom
(dom.fulda.de)
3500
3000
Längengrad
Michaelskirche
(longitude)
(michaelskirche.fulda.de)
50°33.x
3500
P1
3000
P2
P3
2500
2000
1500
1500
3000
3500
Breitengrad
(latitude)
9°40.x
2500
P2
P3
2500
2000
2500
P1
3000
3500
Breitengrad
(latitude)
9°40.x
Abbildung 42 Darstellung möglicher Positionen und Gebiete zur Namensauflösung
Legende: blau: exakte Konturen der Gebiete, rot: grobe Konturen der Gebiete, grün: Referenzpositionen
Anmerkung: Aus Darstellungsgründen werden zwei identische Koordinantensysteme nebeneinander dargestellt
7 Implementierung
- 79 -
Im zweiten Schritt ermittelt der Algorithmus für alle im ersten Schritt gefundenen Gebiete, ob die Referenzposition auch in den exakten Konturen des Gebietes liegt. Vereinfacht erklärt, wird für jede Strecke zwischen zwei benachbarten Randpunkten berechnet,
ob die Referenzposition auf der dem Gebiet zugeneigten oder der abgeneigten Seite
dieser Strecke liegt. Befindet sich die Position für alle Strecken auf der dem Gebiet
zugeneigten Seite, ist die Position auch in den exakten Konturen des Gebietes, anderenfalls nicht. Die beschriebene Vorgehensweise wird mathematisch durch Determinanten
realisiert. Die Parameter sind jeweils zwei Randpunkte und die Referenzposition. Jede Determinante beschreibt die relative Position zu einer Strecke. Sind alle Determinanten größer bzw. kleiner oder gleich 0 ist die Referenzposition in den exakten Konturen des Gebietes. Eine Determinante nimmt den Wert 0 an, wenn die Position genau auf der Strecke
liegt. Im konkreten Beispiel liegt die Position P2 in den exakten Konturen beider Gebiete.
Die Positionen P1 und P3 werden eindeutig dem Dom (dom.fulda.de) zugeordnet.
Im dritten Schritt ermittelt der Algorithmus für alle Referenzpositionen, die noch nicht
eindeutig einem Gebiet zugeordnet werden konnten, das auszuwählende Gebiet. Für alle
gültigen Gebiete wird eine Flächenberechnung durchgeführt. Jedes Gebiet wird in Dreiecke unterteilt. Es gibt genau zwei Dreiecke weniger als Bezugspunkte (siehe Abbildung
42). Die Fläche eines beliebigen Dreieckes kann mit dem Kosinussatz errechnet werden.
Die Summe aller Dreiecke ergibt die Gesamtfläche. Gebiete mit Innenwinkeln größer als
180° müssen zunächst geglättet werden. Das Gebiet mit der kleinsten Fläche wird ausgewählt. Für die Position P2 wird die Michaelskirche (michaelskirche.fulda.de) ausgewählt.
Längengrad
(longitude)
50°33.x
3500
Dom
(www.dom.fulda.de)
A = D1 + D2 + D3
3000
3500
3000
P2
D2
2500
Längengrad
Michaelskirche
(longitude)
(michaelskirche.fulda.de)
50°33.x
D2 P2
2500
2000
2000
1500
1500
3000
D1
D3
D1
2500
A = D1 + D2
3500
Breitengrad
(latitude)
9°40.x
2500
3000
3500
Breitengrad
(latitude)
9°40.x
Abbildung 43 Darstellung der Flächenberechnung für die Namensauflösung
Legende: blau: exakte Konturen, rot: grobe Konturen, grün: Referenzpositionen, orange: Dreiecke
7 Implementierung
- 80 -
7.3.2 Informationsaufbereitung
Der Dienst der Informationsaufbereitung wird über die Klasse Contentservice angeboten. Diese Klasse bietet eine Methode getPages() an, über die mehrere Seiten erzeugt
und als Kompositum zurückgegeben werden. Intern wird für jede Seite die geschützte
Methode getPage() aufgerufen. Die Abbildung 44 zeigt den Quellcode dieser Methode.
Ein Objekt der Klasse ContentQuery ermöglicht die Ermittlung von Informationen aus
der Datenbank. Über ein Objekt der Klasse ComponentFactory wird das im Design konzipierte Kompositium erzeugt.
/* [...] class definition not specified in this example
*/
private ContentQuery contentQuery = new ContentQuery();
private ComponentFactory componentFactory = new ComponentFactory();
private Page getPage(String url, int language) {
ResultSet pageResultSet = null;
ResultSet toppagesResultSet = null;
ResultSet subpagesResultSet = null;
Page page = null;
try {
pageResultSet = contentQuery.getPage(url); // page informations
if (pageResultSet.next()) { // get first result in set, available?
page = componentFactory.createPage(pageResultSet.getString(“url“),
contentQuery.getText(Integer.parseInt(pageResultSet
.getString(“titleTextId“)), language)); // create the page
setItemsToPage(page, url, language); // set the items for the page
subpagesResultSet = contentQuery.getSubPages(url); // get subpages
while (subpagesResultSet.next()) { // for all sub pages
page.addSphere(componentFactory.createSphere(contentQuery
.getText(subpagesResultSet.getInt(“titleTextId“), language),
subpagesResultSet.getString(“url“), Sphere.SUB_PAGE));
}
toppagesResultSet = contentQuery.getTopPages(url); // get toppages
if (toppagesResultSet.next()) { // top page available?
page.addSphere(componentFactory.createSphere(contentQuery
.getText(toppagesResultSet.getInt(“titleTextId“), language),
toppagesResultSet.getString(“url“), Sphere.TOP_PAGE));
}
}
}
}
catch (SQLException exception) {
exception.printStackTrace();
}
return page;
Abbildung 44 Quellcode-Ausschnitt der Seitenerzeugung, Klasse Contentservice
7 Implementierung
- 81 -
7.3.3 Lokalisisierung
In dieser Diplomarbeit wird die Lokalisierung über eine externe GPS-Maus realisiert.
Dieses kleine Gerät sendet kontinuierlich aktuelle GPS Positionsdaten über die Bluetooth
Schnittstelle an andere Geräte. Für die Übertragung der Daten wird der NMEA-Standard
verwendet. Die Abbildung 45 verdeutlicht das Zusammenspiel der GPS-Maus mit dem
Mobiltelefon. In dieser Diplomarbeit wurde die GPS-Maus Holux GR-230 (siehe Abbildung) verwendet. Prinzipiell kann jede GPS-Maus, die den NMEA-Standard unterstützt
und Bluetooth verwendet, für die Lokalisierung eingesetzt werden.
...$GPRMC,102336.053,A,5033.2500,N,00940.4020,E,
0.00,39.34,071005,,*33...
Bluetooth Verbindung
Abbildung 45 Übertragung der GPS Daten von der GPS-Maus zum Mobiltelefon
(Anmerkung: Das Beispiel zeigt eine Lokalisierung am Fuldarer Dom, Position: 50.33° 2500 N, 9.40° 4022 E)
Wie im Kapitel 4.1.2 dargestellt, wird ein Bluetooth API (JSR-82) für die Unterstützung
von Bluetooth Geräten in der J2ME bereitgestellt. Nicht alle Java-fähigen Mobiltelefone
unterstützen dieses API, da es sich um ein optionales Paket handelt. Das in dieser Diplomarbeit verwendete Mobiltelefon K750i von Sony Ericsson unterstützt wie viele der
heute handelsüblichen Mobiltelefone das API.
Die Klasse GPSLocator realisiert die Ermittlung der Positionsdaten über die GPS-Maus.
Die Funktionalität lässt sich durch folgende Schritte beschreiben:
 detektieren aller erreichbaren Bluetooth Geräte
 suchen nach einer Bluetooth GPS-Maus
 eine bestimmte Zeit langes Mitschneiden der von der Maus gesendeten Daten
 analysieren dieser Daten und ermitteln der aktuellen absoluten Position
Zur Realisierung der ersten zwei Schritte wird das Interface DiscoveryListener der
Bluetooth API verwendet. Über dieses Interface werden alle entfernten Bluetooth Geräte
detektiert. Die Suche der GPS-Maus kann über den angebotenen Service oder über den
Gerätenamen geschehen. Im Falle der eingesetzten GPS-Maus wird der Gerätename
verwendet, da keine Service-Bezeichnung vorliegt. Die Geräteerkennung geschieht über
einen Thread, der durch die geschützte Methode getDevices() gestartet wird.
7 Implementierung
- 82 -
Die Implementierung der letzten beiden Schritte, in denen der Datenstrom (engl.
Stream) mitgeschnitten und analysiert wird, ist über die Methode createLocation()
realisiert. Die Abbildungen 46 und 47 zeigen den zugehörigen Quellcode.
Gegebenenfalls wird auf das Ende des Threads, der die entfernten Geräte erkennt, gewartet. In der J2ME sind die Methoden interrupt() und isIterrupted() für Threads nicht
implementiert. Aus diesem Grund wird das global definierte Flag interrupt eingeführt,
um festzulegen, ob der GPSLocator beendet werden soll. Schließlich wird über die Bluetooth-Adresse der GPS-Maus eine Verbindung aufgebaut und der Datenstrom für eine bestimmte Zeit mitgeschnitten. Die J2ME unterstützt keinen StringTokenizer, weswegen der
Datenstrom etwas umständlicher manuell zerlegt werden muss. Hier dienen die Methoden
indexOf() und substring() des String Objektes. Über die Konstante REFERENCE_VALUE wird
festgelegt, wie viele Vergleichswerte aus dem Datenstrom gelesen werden sollen. Der
Mittelwert dieser Werte stellt die absoluten Breiten- und Längengrad-Werte dar. Über das
Interface LocationListener wird der aufrufende Client (im konkreten Fall ein Objekt der
Klasse Controller) informiert.
private void createLocation() {
Location location = null;
StreamConnection streamConnection = null;
InputStream inputStream = null;
InputStreamReader inputStreamReader = null;
String stream = "";
String url = null;
int indexGPRMC = 0;
int longitude = 0;
int latitude = 0;
int i = 0;
if (deviceThread.isAlive()) { // init-thread alive?
locatorListener.setLocation(this,new Location(Location.REFRESHING));
try {
deviceThread.join(); // waits until init-thread suspends
}
catch (InterruptedException exception) { }
}
if (interrupt) { // is it a destroy call?
return;
}
if (remoteDevice == null) { // is no device available?
locatorListener.setLocation(this,new Location
(Location.ERROR_NO_DEVICE));
return; // returns with error
}
Abbildung 46 Quellcode der Positionsdaten-Ermittlung (GPS), Klasse GPSLocator
7 Implementierung
- 83 -
else {
url = "btspp://" + remoteDevice.getBluetoothAddress()
+ ":1;authenticate=false;master=false;encrypt=false";
try {
streamConnection = (StreamConnection) Connector.open(url);
inputStream = streamConnection.openInputStream();
inputStreamReader = new InputStreamReader(inputStream);
for (i = 0; i < STREAM_LENGTH * REFERENCE_VALUES; i++) {
stream += (char) inputStreamReader.read(); // read gps stream
}
inputStreamReader.close();
inputStream.close();
streamConnection.close();
}
catch (IOException exception) {
locatorListener.setLocation(this, new Location
(Location.ERROR_CONNECTION));
return;
}
for (i = 0; i < REFERENCE_VALUES; i++) { // parses in gps data
indexGPRMC = stream.indexOf("$GPRMC", indexGPRMC); // start data
}
}
}
/* is the stream ok ? */
if (indexGPRMC > 0 && stream.length() >= indexGPRMC + 41) {
longitude += Integer.parseInt(stream.substring(indexGPRMC + 20,
indexGPRMC + 20 + 4)
+ stream.substring(indexGPRMC + 20 + 5, indexGPRMC + 20 + 9))
/ REFERENCE_VALUES; // parses longitude from stream
latitude += Integer.parseInt(stream.substring(indexGPRMC + 33,
indexGPRMC + 33 + 4)
+ stream.substring(indexGPRMC + 33 + 5, indexGPRMC + 33 + 9))
/ REFERENCE_VALUES; // parses latitude from stream
}
else {
locatorListener.setLocation(this, new Location
(Location.ERROR_CONVERT));
return;
}
location = new Location(latitude, longitude); // create new location
locatorListener.setLocation(this, location); // set to client
Abbildung 47 Quellcode der Positionsdaten-Ermittlung (GPS) - Fortsetzung
7 Implementierung
- 84 -
7.3.4 Dialog-Agent
Im Kapitel 4.4 wurde beschrieben, wie mit Hilfe der Web Service API (JSR-172) eine Verbindung zu einem Web Service unter der J2ME aufgebaut werden kann. Die Unterstützung dieses API ist genauso wie das Bluetooth API vom Gerät abhängig und nicht erforderlich, um den Kriterien der J2ME Unterstützung zu genügen. Das für diese Diplomarbeit verwendete Mobiltelefon unterstützt wie viele der heute handelsüblichen Mobiltelefonen das API noch nicht.
Um ein Testsystem entwickeln zu können und um die Anforderungen auf eine breite Geräteunterstützung gerecht zu werden, wird in dieser Diplomarbeit auf den Einsatz des
Web Service API verzichtet. Diese Entscheidung trägt einige Konsequenzen mit sich, die
auch Auswirkungen auf die Implementierung des Servers und somit auf die Realisierung
des Dialog-Agents haben. Eine Übersicht über die notwendigen Veränderungen liefert die
Tabelle 13. Eine Implementierung mit Hilfe eines Web Services wird bewusst im Design
der Anwendung (Kapitel 6.4.4) konzipiert, um eine optimale Lösung des interaktiven
Stadtführers vorzustellen.
Im Design konzipiert
Tatsächlich implementiert
Protokoll
SOAP, WSDL
nur XML
Schnittstelle
Web Service
Servlet (Web-Komponente)
Parser (Client)
SAX-Parser
eigen entwickelter Parser
Tabelle 13 Design-Veränderungen auf Grund des Verzichtes des Web Service API
Auf Grund der notwendigen Veränderungen stellt der Server anstatt eines Web Services
ein Servlet als Web-Komponente zur Verfügung. Die Implementierung der Klasse MyServlet wird notwendig, um eine öffentliche Schnittstelle anzubieten. Das Servlet liefert
als Antwort (engl. response) einen XML Datenstrom (engl. stream). Diese XML-Nachricht
wird über ein Objekt des Kompositums mit Hilfe von DOM erstellt. Das Modell ermöglicht
auf einfache Weise die Objektstruktur in XML abzubilden. Der konzipierte Web Service
würde so implementiert werden, dass die XML-Nachricht als Nutzdaten in den SOAP Body
eingefügt werden würde.
7 Implementierung
- 85 -
7.4 Übertragungsschicht
Auf Grund der im vorigen Abschnitt dargestellten Problematik der Geräteunterstützung
für das Web Service API, wird für die Übertragung der Daten vom Server zum mobilen
Client nicht wie konzipiert das SOAP, sondern nur eine XML Nachricht verwendet. Durch
den Verzicht auf das SOAP entfällt auch die Web Service Beschreibung in WSDL, welche
eine Schnittstelle zwischen dem bereitgestellten Dienst und einem anfragenden Client definieren würde (vgl. [Hein 2003]). Dadurch bedingt muss manuell festgelegt werden,
über welche Aufrufe der Server erreichbar und wie die XML Struktur der Antwort (engl.
response) definiert ist. Ein weiterer Nachteil ist, dass Bilder oder andere Daten nicht in
die SOAP Nachricht eingebettet, sondern extra separat aus dem Internet geladen werden
müssen.
Der Server, der für diese Diplomarbeit verwendet wird, verlangt als Parameter entweder
absolute Positionsdaten oder die URL der Seite mit der gewählten Sprache. Der Aufruf
von http://olaflange.homelinux.org/webservice?url=dom.fulda.de?language=2 liefert beispielsweise die in Abbildung 48 dargestellte Antwort. Sie besteht aus ein oder mehreren
Seiten (engl. Pages), die sich jeweils aus beliebig vielen Elementen (engl. Items) und
beliebig vielen Umgebungen (engl. Spheres) zusammensetzen. Der Informationsgehalt
von Element (z.B. StringItem) ist als Attribut im Start-Tag definiert, anstatt normalen
Text in Form eines CDATA-Abschnittes aufzunehmen. Dadurch kann die Implementierung
des zu erstellenden XML Parsers (siehe nächste Seite) vereinfacht werden.
<?xml version="1.0" encoding="UTF-8"?>
<pages>
<page title="Fulda: Dom" url="dom.fulda.de">
<items>
<stringItem text="Sie befinden sich vor dem Dom St.Salvator und
Bonifatius zu Fulda. Über das Menü erreichen Sie detailiertere
Informationen zum Dom."/>
<imageItem altText="Fulda_Dom.png"
image="http://olaflange.homelinux.org/pics/Fulda_Dom.png"
label="Das Foto zeigt den Fuldarer Dom" layout="1"/>
</items>
<spheres>
<sphere pageURL="dom.fulda.de/architektur"
title="Dom: Architektur" type="2"/>
<sphere pageURL="dom.fulda.de/geschichte"
title="Dom: Geschichte" type="2"/>
<sphere pageURL="dom.fulda.de/sphere"
title="Umgebung (Karte)" type="2"/>
<sphere pageURL="fulda.de" title="Fulda" type="1"/>
</spheres>
</page>
</pages>
Abbildung 48 XML Nachricht einer Server Antwort für die Seite des Fuldarer Doms
7 Implementierung
- 86 -
7.5 Präsentationsschicht
7.5.1 Darstellung
Im diesem Abschnitt wird weniger auf die Realisierung des MIDlets, das durch die Klasse
MyMIDlet präsentiert wird, eingegangen. Im Kapitel 4.5 wurde ein Beispiel für die Erzeugung eines einfachen MIDlets dargestellt. Auf vergleichbare Weise wird das MIDlet des interaktiven Stadtführers bereitgestellt. Für die Kontrolle der Anwendung ist ein Objekt der
Klasse Controller zuständig. Dieses Objekt benutzt ein Objekt der Klasse PageCreator,
um die Adresse des aktuellen Standpunktes oder um unbekannte Seiten zu ermitteln. Im
folgenden soll die Funktionsweise dieser Erzeugers beschrieben werden.
Um die Informationen zu einer Sehenswürdigkeit oder um die zugeordnete Adresse der
aktuellen Position zu erhalten, wird eine Verbindung zu dem Web Service mit Hilfe des im
Kapitel 4.2.2 vorgestellten Generic Connecetion Framework (GCF) aufgebaut. Der PageCreator übergibt die URL mit der ausgewählten Sprache bzw. die Positionsdaten an den
Web Service. Die Antwort ist eine bereits im vorigen Abschnitt beschriebene XML-Nachricht. Das Web Service API stellt einen SAX-Parser zur Verfügung, der jedoch auf Grund
der mangelnden Geräteunterstützung nicht verwendet werden kann. Die XML-Nachricht
muss deshalb manuell zerlegt werden. Ein StringTokenizer wird in der J2ME nicht unterstützt, weswegen die Nachricht nur durch Suchen nach Tags und Leerzeichen zwischen
Attributen zerlegt werden kann. Auf diese Weise werden syntaktische XML Konstrukte erkannt, die durch entsprechende Methodenaufrufe einem Objekt der inneren Klasse
ParserHandler übergeben werden. Dieser Handler ist so aufgebaut wie der DefaultHandler, der bei einer Zerlegung einer XML-Nachricht mit Hilfe von SAX (Web Service API)
benutzt werden würde. Dadurch ist eine Austauschbarkeit gewährleistet.
Der implementierte ParserHandler stellt wie der DefaultHandler drei öffentliche (engl.
public) Methoden zur Verfügung:
 startElement() wird bei einem öffnenden Tag eines Elementes aufgerufen
 characters() wird für den dazwischen befindlichen Inhalt aufgerufen
 endElement() wird bei einem schließenden Tag eines Elementes aufgerufen
Durch die Aufrufe dieser Methoden erzeugt der Handler neue Page Objekte bzw. eine
neue URL. Die Methode characters() ist leer, da kein Text in Form eines CDATA-Abschnittes in der gegebenen XML-Struktur vorliegt.
7 Implementierung
- 87 -
7.5.2 Konfiguration
Die Konfiguration der gesamten mobilen Anwendung wird wie im Design gefordert zentral
definiert. Die Klasse Configuration kapselt die gesamte Konfiguration. Diese Klasse ist
als Singleton definiert, damit alle Klienten auf dasselbe Objekt zugreifen können, ohne
eine Referenz durchreichen zu müssen. Das Entwurfsmuster des Singletons wird durch
einen privat deklarierten Konstruktor und durch eine Klassen-Methode zum Erlangen des
Objektes realisiert (siehe Abbildung 49). Dadurch ist sichergestellt, dass es nur ein
Objekt dieser Klasse geben kann.
Die persistente Speicherung der Konfiguration, wie sie theoretisch im Kapitel 4.3.3 vorgestellt wurde, ist ebenfalls über die Klasse Configuration realisiert. Im Quellcode der Abbildung 49 wird das RecordStore Cityguide geöffnet und einige Werte ausgelesen. Wird
die Konfiguration geändert, werden die neuen Werte in das RecordStore zurückgeschrieben. Der schreibende Zugriff ist nicht in dem Quellcode der Abbildung dargestellt.
private Configuration() {
byte[] data = null;
try {
/* Open or creates a new record store on the mobilephone */
recordStore = RecordStore.openRecordStore("Cityguide", true);
if (recordStore.getNumRecords() == 0) { // no records found?
setDefaultSettings(); // creates and sets default settings
}
else {
data = recordStore.getRecord(RECORD_ID_SERVICE_URL);
serviceURL = new String(data);
data = recordStore.getRecord(RECORD_ID_LOCATION_SYSTEM);
selectedLocationsystem = Integer.parseInt(new String(data));
data = recordStore.getRecord(RECORD_ID_LANGUAGE);
selectedLanguage = Integer.parseInt(new String(data));
}
}
}
catch (Exception e) { } // exception not specified
setLanguage();
public static Configuration getInstance() {
if (configuration == null) { // is singleton not created?
configuration = new Configuration(); // creates singleton
}
return configuration; // return singleton
}
Abbildung 49 Quellcode-Ausschnitt der Client Konfiguration, Klasse Configuration
7 Implementierung
- 88 -
7.6 Anwendungstest
Um die Funktionsweise des interaktiven Stadtführers zu testen, wurden einige Sehenswürdigkeiten der Stadt Fulda in den Datenbanken erfasst. Die Abbildung zeigt die Sehenswürdigkeiten mit den zugehörigen Längen- und Breitengraden. In der Farbe grün
sind sechs Testpositionen eingezeichnet. Das Telefon wurde mit Hilfe der GPS-Maus an
allen Positionen korrekt lokalisiert. Die erwarteten Informationen zu dem jeweiligen
Standort wurden auf dem Display des Mobiltelefons angezeigt. Die Tabelle 14 zeigt die
ermittelten Daten. An der Position 2 befinden sich die Informationen zu dem Schloss im
lokalen Cache, da dieselbe URL bereits an der Position 1 aufgerufen wurde. Die Position 5
wird dem kleinsten Gebiet, der Michaelskirche, zugeordnet.
Längengrad
(longitude)
50°33.x
3500
Michaels
kirche
Orangerie
P3
3000
P4
Schloss
2500
Dom
P6
2000
1500
2500
3000
3500
4000
4500
5000
5500
6000
Breitengrad
6500 (latitude)
9°40.x
Abbildung 50 Positionsdaten von Sehenswürdigkeiten und Testpositionen in Fulda
Legende: blau: exakte Konturen der Gebiete, rot: grobe Konturen der Gebiete, grün: Testpositionen
Position
Breiten
Längengrad
ermittelte URL
Seitenaufruf
1
9°40.5240
50°33.1977
schloss.fulda.de
entfernt (Server)
2
9°40.5139
50°33.2386
schloss.fulda.de
lokal (Cache)
3
9°40.4127
50°33.3266
orangerie.fulda.de
entfernt (Server)
4
9°40.4312
50°33.2780
fulda.de
entfernt (Server)
5
9°40.3423
50°33.2792
michaelskirche.fulda.de
entfernt (Server)
6
9°40.4003
50°33.2315
dom.fulda.de
entfernt (Server)
Tabelle 14 Ergebnisse eines „interaktiven Stadtführer“ Systemtestes
8 Diskussion der erreichten Ergebnisse
- 89 -
8 Diskussion der erreichten Ergebnisse
8.1 Realisierung des interaktiven Stadtführers
Das Ziel dieser Diplomarbeit, einen interaktiven Stadtführer zu entwickeln, wurde erfolgreich umgesetzt. Im Kapitel 5 wurden die konkreten Anforderungen an dieses System ermittelt. Im folgenden Kapitel wurde ein abstraktes Anwendungsdesign entwickelt und anschließend die Implementierung des Systems vorgestellt. Die mobile Anwendung lässt
sich auf einfachem Wege auf dem Mobiltelefon installieren. Mit Hilfe einer GPS-Maus wird
die Position des Mobiltelefons automatisch ermittelt. Über eine Internet-Verbindung
erhält die Applikation die konkret darzustellenden Informationen von einem Internet-Server. Eine zentrale Pflege der Inhalte ist durch die gewählte Client-Server-Architektur und
die Realisierung zweier Datenbanken möglich.
Auf eine Implementierung eines Web Services musste aufgrund der fehlenden Geräteunterstützung des Web Service APIs verzichtet werden. Ein solcher Dienst würde eine
vollständig unabhängige Implementierung von Server und Client ermöglichen. Durch die
Verwendung von XML zum Nachrichtenaustausch wurde auch ohne die Verwendung des
APIs eine lose Kopplung zwischen der mobilen Anwendung und dem Internet-Server geschaffen. Im Kapitel 4.4 wurden einige Vorteile von XML erörtert. Die Wahl dieser Auszeichnungssprache erweist sich trotz des relativ hohen Overheads, die diese Sprache enthält, als angemessen. Der Server erzeugt mit Hilfe von DOM auf einfachem Wege XMLNachrichten. Clientseitig wurde ein eigenständiger XML-Parser implementiert. Zahlreiche
Tests zeigen, dass dieser Parser einwandfrei die Nachrichten des Servers analysiert und
die entsprechenden Informationen für die Anzeige auf dem Mobiltelefons ermittelt.
Die Anwendung unterstützt die Übertragung und die Darstellung von Texten und Bildern.
Das abstrakte Design der gesamten Anwendung ist als positiv zu bewerten. Eine einfache
Erweiterbarkeit wird gewährleistet. Das System wurde so konzipiert, dass Daten für die
Erzeugung von anderen Dialogelementen (z.B. Eingabefelder, Optionsfelder) problemlos
übertragen werden kann. Bedingt durch die Modularität des Systems und durch die mehrschichtige Anwendungsarchitektur wurde ein Framework für ähnliche Anwendungen geschaffen. Die Trennung des darzustellenden Inhalts von der zu Grunde liegenden Technik, ermöglicht die Wiederverwendung des Systems in einem völlig anderen Kontext. Ein
Austausch des Lokalisierungssystems ist durch die gewählte Abstraktion einfach möglich.
8 Diskussion der erreichten Ergebnisse
- 90 -
8.2 Mobile Java-Programmierung in der J2ME
Alle auf dem deutschen Mobilfunkmarkt erhältlichen Mobiltelefone unterstützten die Programmiersprache Java in der Java 2 Micro Edition (J2ME), wodurch eine plattform- und
geräteunabhängige Entwicklung von mobilen Anwendungen möglich ist. Die in dieser Diplomarbeit entwickelten J2ME-Applikationen konnten in der Praxis problemlos im Emulator und auf dem Mobiltelefon K750i von Sony Ericsson ausgeführt werden.
Die Merkmale der J2ME wurden im Kapitel 4 erörtert. Die Edition bietet umfangreiche
Möglichkeiten der GUI-Programmierung. Mit Hilfe der High-Level-API des LCDUIs können
verschiedene Dialogelemente (z.B. Navigationsmenüs, Texte, Auswahllisten, etc.) erzeugt
und auf dem Display des Mobiltelefons angezeigt werden. Die Ereignis-Behandlung (engl.
Event-Handling) ermöglicht eine einfache Verarbeitung von Interaktionen wie z.B. das
Auswählen von Menüeinträgen oder die Eingabe in Textfeldern. Hervorzuheben ist die
konsequente Trennung zwischen der Erzeugung und der Anordnung von Dialogelementen. Die High-Level-API stellt keine Möglichkeiten der Anordnung von Elementen auf dem
Display zur Verfügung, wie es z.B. die Swing-Programmierung (J2SE) mit Hilfe von Layout-Managers erlaubt. Die klare Trennung ist positiv zu bewerten, da sichergestellt wird,
dass Java-Anwendungen, die auf dem High-Level-API basieren, exakt dem Aussehen und
der Bedienung (engl. Look & Feel) anderer Anwendungen des Gerätes entsprechen.
Die J2ME ermöglicht eine persistente Speicherung von einzelnen Daten. Der verfügbare
Speicherplatz ist auf Grund der Geräteeigenschaften sehr beschränkt, jedoch ausreichend, um z.B. Konfigurationsdaten dauerhaft zu speichern. Die Funktionsweise und
Handhabung sind einfach. Ein ähnliches Speicherungssystem wäre deshalb manchmal
auch in der J2SE wünschenswert.
Die J2ME verfügt über eine ganze Reihe von optionalen Paketen, welche spezielle APIs
bereitstellen. Diese Pakete werden bedauerlicherweise nicht von jedem Java-Mobiltelefon
unterstützt, wodurch die allgemeine Verwendung des APIs stark eingeschränkt wird. Im
Fokus dieser Diplomarbeit steht das Web Service API (siehe Kapitel 4.4). Es wird eine
Schnittstelle zum Zugriff auf Web Services über das SOAP bereitgestellt. Ein SAX-Parser
vereinfacht das Analysieren der Nutzdaten der SOAP-Nachricht. Das API ist als ausgereift
und gut implementiert zu bewerten. Das API wird allerdings nur von den wenigsten aktuellen Mobiltelefonen unterstützt. Wie weit Web Services in Zukunft als Schnittstelle zwischen einer mobilen Java-Anwendung und einem Internet-Server dienen, wird maßgeblich davon abhängen, wie schnell neue Mobiltelefone dieses optionale Paket unterstützen.
8 Diskussion der erreichten Ergebnisse
- 91 -
8.3 Potenzial und Techniken von LBS
Im Kapitel 2 wurde das wirtschaftliche Potenzial von mobilen Anwendungen und Location
Based Services (LBS) abgeschätzt. Es wurde festgestellt, dass neuen Anwendungen, die
gezielt ortsbezogene Informationen zur Verfügung stellen, ein großes Interesse bei Mobilfunk-Nutzern wecken. Bis zum heutigen Tage werden jedoch nur sehr wenige LBS
angeboten. In dieser Diplomarbeit wurde ein breites Spektrum von möglichen mobilen
Anwendungen vorgestellt. Es ist zu erwarten, dass sich diese oder ähnliche Applikationen
in den nächsten Jahren etablieren werden.
Die dargestellten Anwendungen weisen unterschiedliche Erwartungen an die Positionsbestimmung auf. Im Kapitel 3 wurden verschiedene Lokalisierungssysteme untersucht und
ihre Merkmale gegenübergestellt. Keines der heute verfügbaren Systeme erfüllt alle Kriterien für eine universell einsetzbare Positionsbestimmung. Es wurde festgestellt, dass
die Systeme sich gegenseitig ergänzen.
Das satellitengestützte GPS erweist sich derzeit als das genaueste System mit der
höchsten Gebietsabdeckung. Jedoch ist dieses System für eine Indoor-Lokalisierung (z.B.
bei einer Positionsbestimmung in Gebäuden) ungeeignet. Für eine solche Lokalisierung
müssen zellenbasierte Systeme verwendet werden. Die Lokalisierung über die Mobilfunkzelle stellt eine solche Möglichkeit dar. Damit LBS einen optimalen Dienst erbringen
können, müssen verschiedene Lokalisierungssysteme sinnvoll kombiniert werden.
Die heute auf deutschem Mobilfunkmarkt erhältlichen Mobiltelefone verfügen noch nicht
über einen integrierten GPS-Empfänger. Eine Positionsbestimmung ohne zusätzliche Geräte ist nur über die Mobilfunkzelle oder im Fall eines lokal stark beschränkten Gebietes
mit Hilfe von Bluetooth möglich. Gegenüber GPS sind diese Positionsbestimmungen ungenau und nur für einige der vorgestellten Anwendungen ausreichend. Im Jahr 2006
werden die ersten Mobiltelefone mit einem integrierten GPS-Empfänger auf dem deutschen Markt verfügbar sein. Bedingt durch die Verfügbarkeit dieser Technologie im Mobiltelefon, ist zu erwarten, dass es zu einer stärkeren Verbreitung und Nutzung ortsbezogener Anwendungen kommen wird.
Abkürzungsverzeichnis/Glossar
- 92 -
Abkürzungsverzeichnis/Glossar
AMS
Jedes MIDP kompatible Gerät verfügt über einen AMS (Application Management Software). Diese Komponente ist unter anderem für die
Steuerung des MIDlet-Lebenszyklus (zu den Aktionen wie Starten,
Pausieren und Beenden der Anwendung gehören) verantwortlich.
API
Ein Application Programming Interface (API) ist eine EntwicklungsSchnittstelle, die ein Softwaresystem einem Programmierer zur Verfügung stellt, damit dieser unter Verwendung dieses Softwarepaketes
neue Programme entwickeln kann.
Applikation
Server
„Ein Application Server ist ein Server in einem Computernetzwerk, auf
dem spezielle Software-Applikationen ausgeführt werden. Häufig meint
man dabei Software-Applikationen mit einer drei- oder mehrschichtigen Architektur, wie sie z.B. vom J2EE- oder .NET-Framework
vorgeschlagen werden“ [Wikipedia 2005].
Bluetooth
„Bluetooth ist ein Industriestandard für die drahtlose Vernetzung von
Geräten über kurze Distanz. Bluetooth bietet eine drahtlose Schnittstelle, über die sowohl mobile Kleingeräte wie Mobiltelefone und PDAs
als auch Computer und Peripheriegeräte miteinander kommunizieren
können“ [Wikipedia 2005].
CDC, CLDC
Die CDLC (Connected, Limited Device Configuration) und die CDC
(Connected Device Configuration) sind zwei Konfigurationen der J2ME
die unter anderem die Leistungsfähigkeit der virtuellen Maschine
beschreiben. Die CLDC ist für mobile stark ressourcenbeschränkte
Endgeräte wie Mobiltelefone ausgelegt. Die CDC eignet sich für leistungsfähige, zum Teil stationäre Endgeräte, wie z.B. Set-Top-Boxen.
Cell-ID
Der Cell-Indetifier (Cell-ID) ist eine Kennung einer Funkzelle, die diese
zusammen mit dem Location Area Code landesweit und zusätzlich mit
dem Country Code weltweit kennzeichnet (vgl. [Fleuren 2004]).
Daemon
„Als Daemon bzw. Dämon bezeichnet man unter Unix und seinen Derivaten ein Programm, das im Hintergrund abläuft und bestimmte
Dienste zur Verfügung stellt“ [Wikipedia 2005].
DNS
Das Domain Name System (DNS) ist ein hierarchisches System zur
Zuordnung von Klartextnamen (z.B. www.fh-fulda.de) zu IP-Adressen
(z.B. 193.174.25.51) und umgekehrt.
DOM
Das Document Object Model (DOM) ist eine API für den Zugriff auf
XML-Dokumente. Sie wird vom W3C definiert. „Es basiert auf der Konvertierung von XML-Dokumenten in eine Menge von Objekten, mit
denen sich innerhalb einer Applikation komfortabel arbeiten lässt. Auf
dieser Objektdarstellung lassen sich dann verschiedene Arten von
Transformationen durchführen (Einfügen, Löschen, Ändern von
Knoten, Kopieren von Dokumentenfragmenten usw.)“ [Hein 2003].
Abkürzungsverzeichnis/Glossar
- 93 -
ER-Modell
oder ERM
Das Entity-Relationship-Modell, kurz ER-Modell oder ERM, dient dazu,
im Rahmen der Datenmodellierung einen Ausschnitt der realen Welt zu
beschreiben. Das ER-Modell besteht meist aus einer Grafik und einer
Beschreibung der darin verwendeten einzelnen Elemente. Es dient zum
einen in der konzeptionellen Phase der Anwendungsentwicklung der
Verständigung zwischen Anwendern und Entwicklern. Zum anderen
dient es in der Implementierungsphase als Grundlage für das Design
der Datenbank (vgl. [Wikipedia 2005]).
EER-Modell
Das Enhanced-ER-Modell, kurz EER-Modell, beinhaltet alle
Modellierungskonzepte des ER-Modells. Darüber hinaus umfasst es
weitere Konzepte, wie z.B. Generalisierung (vgl. [Elmasri 2002]).
Framework
„Framework (engl. Rahmenwerk, Fachwerk) ist ein Begriff aus der
Softwaretechnik und wird insbesondere im Rahmen der objektorientierten Softwareentwicklung sowie bei komponentenbasierten
Entwicklungs-Ansätzen verwendet“ [Wikipedia 2005]. Ziel von Frameworks ist es ein abstraktes Gerüst zu bilden, was für andere
Anwendungen wiederverwendet werden kann.
GCF
Bei dem Generic Connecetion Framework (GCF) handelt es sich um
eine Vereinheitlichung von Netzwerkzugriffen unter der J2ME. Unter
anderem werden HTTP-Verbindungen zu entfernten Internet Servern
ermöglicht.
Generalisierung
Bei der Generalisierung werden die Unterschiede zwischen mehreren
Entitätstypen unterdrückt, ihre gemeinsamen Merkmale identifiziert
und zu einer einzigen Superklasse zusammengefasst (vgl. [Elmasri
2002]). Die Superklasse wird im ERR-Modell durch eine separate Relation dargestellt.
GSM
„Das Global System of Mobile Communication (GSM) ist ein
technischer Standard für die digitale Funktelefonie. In Deutschland
werden dazu Frequenzbereiche um 900 MHz (D-Netze) sowie um 1800
MHz (E-Netze) eingesetzt. Zusätzlich zur Übertragung von Sprache
können in diesen Netzen auch Daten mit 9600 bps übertragen
werden.“
GPRS
General Packet Radio Service (GPRS) wurde geschaffen, um mit einem
GSM-Mobilfunknetz paketorientierte und schnellere Datenübertragung
zu ermöglichen. GPRS stellt eine Vorstufe für die dritte Mobilfunkgeneration UMTS dar.
GPL
Die GNU General Public License (GPL) ist eine von der Free Software
Foundation herausgegebene Lizenz für die Lizenzierung freier Software
nach den Grundlagen von Open Source. Ein Programm unter dieser Lizenz kann für jeden Zweck frei genutzt, verteilt und weiterentwickelt
werden.
GPS
„Das Global Positioning System (GPS) ist ein satellitengestütztes Navigationssystem zur weltweiten Positionsbestimmung, das vom USVerteidigungsministerium betrieben wird“ [Wikipedia 2005].
Abkürzungsverzeichnis/Glossar
- 94 -
GPS-Maus
Eine GPS-Maus ist ein einfaches GPS-Empfangsgerät, welches aus den
ausgestrahlten Signalen der GPS-Satelliten die momentane Position
errechnet. Gegenüber aufwendigeren GPS-Receivern verfügen GPSMäuse weder über zusätzliche Software noch über ein Display zur
Anzeige der Position. Die Mäuse übertragen die aktuell ermittelten Positionsdaten, z.B. über Bluetooth, an andere Geräte.
GUI
Als Graphical User Interface (GUI) wird die grafische Schnittstelle zwischen Computer (oder anderen Endgerät) und dem Benutzer bezeichnet. Die GUI stellt Informationen auf dem Monitor bzw. der Anzeige
dar und ermöglicht dem Benutzer interaktiv mit dem System in Verbindung zu treten.
Handler
Handler ist ein Begriff aus der ereignisgetriebenen Programmierung.
Ein Handler stellt Funktionen bereit, die ein Ereignis im allgemeinen
Sinne verarbeitet. Der Begriff wird oft synonym zu Callback gebraucht.
(vgl. [Ullenboom 2005])
HTML
Die Hypertext Markup Language (HTML) ist ein Dokumentenformat zur
Auszeichnung von Hypertext und wurde 1989 von Tim Berners-Lee am
CERN in Genf festgelegt. HTML wurde vom W3C weiterentwickelt und
ist heute der gängige Standard für die Realisierung von Internetseiten.
(vgl. [Wikipedia 2005])
HTTP
„Das Hypertext Transfer Protocol (HTTP) ist ein Protokoll zur Übertragung von Daten über ein Netzwerk. Es wird hauptsächlich eingesetzt, um Webseiten und andere Daten aus dem World Wide Web
(WWW) in einen Webbrowser zu laden“ [Wikipedia 2005].
IEEE 802.11
(WLAN)
„IEEE 802.11 (WLAN) bezeichnet einen Industriestandard für drahtlose
Netzwerkkommunikation. Herausgeber ist das Institute of Electrical
and Electronics Engineers (IEEE)“ [Wikipedia 2005]. Es kann eine maximale Übertragungsrate von 56 Mbit/s erreicht werden.
J2EE
Die Java 2 Enterprise Edition (J2EE) enthält die J2SE mit zusätzlichen
Paketen, wie EJB, JSP, Servlets, JavaMail und Web Application Server.
J2ME
Java 2 Micro Edition (J2ME) ist eine hoch-optimierte „schlanke“ JavaLaufzeit-Umgebung für den Einsatz in Produkten wie Mobiltelefonen,
Kartenlesern, Pagern, PDA, Palmtops, Set-Top-Boxen, Navigationssystemen und Maschinen-Steuerungen. J2ME ist inbesondere für Geräte
mit wenig Speicher und Prozessorleistung optimiert.
J2SE
Die Java 2 Platform Standard Edition (J2SE) ist eine Sammlung von
grundlegenden Java-APIs. Die J2SE dient als Grundlage für die J2EE
und J2ME-Technologien.
JavaDoc
JavaDoc ist ein Werkzeug das automatisch aus Java-Quelltexten eine
Dokumentation in HTML erzeugt. Dazu müssen spezielle Kommentare
im Quelltext zur Beschreibungen von Klassen und Felder eingefügt
werden.
JAX-RPC
„JAX-RPC ist eine Java Bibliothek um Remote Procedure Calls auf XMLBasis ausführen zu können. Die aktuelle Version der JAX-RPC API ist
die Version 1.1. Mit Version 2.0 wird die API Teil der XML basierten
Web Services (JAX-WS) sein“ [Wikipedia 2005].
Abkürzungsverzeichnis/Glossar
- 95 -
JAXP
Die Java APIs for XML Processing (JAXP) stellt eine Programmierschnittstelle zur Verfügung, mit dessen Hilfe XML-Dokumente
analysiert werden können. Das API ist in der JSR-63 dokumentiert. Es
werden mit einem SAX-Parser und dem DOM zwei unterschiedliche Ansätze zur Verfügung gestellt. (vgl. [Schmatz 2004])
JDBC
„Java Database Connectivity (JDBC) ist ein API der Java-Plattform, die
eine einheitliche Schnittstelle zu Datenbanken verschiedener Hersteller
bietet und speziell auf relationale Datenbanken ausgerichtet ist“ [Wikipedia 2005].
JRE
Die Java Runtime Environment (JRE), zu deutsch Java-Laufzeitumgebung, stellt unter anderem eine virtuelle Maschine (JVM) zur Verfügung. Sie wird benötigt, um Java-Applikationen auszuführen. Für das
Compilieren von Java Anwendungen ist die J2SE und ggf. die J2ME
bzw. die J2EE notwendig.
Java VM oder
JVM
„Die Java Virtual Machine (abgekürzt Java VM oder JVM) ist eine Laufzeitumgebung und virtuelle Maschine für Software. Die Java Virtual
Machine führt den so genannten Java-Bytecode aus“ [Wikipedia 2005].
KVM
Die KVM (Kilobyte Virtual Machine) ist eine abgespeckte virtuelle Maschine, die speziell für leistungsschwache Endgeräte wie z.B. Mobiltelefone entwickelt wurde. „Das wichtigste Entwurfsziel der KVM
bestand darin, die essenziellen Eigenschaften der Programmiersprache
Java zu unterstützten und gleichzeitig mit einer Speicherkapazität von
insgesamt 160 bis 512 kB auszukommen“ [Schmatz 2004].
LBS
„Unter Location Based Services (LBS) versteht man ortsgebundene
Dienste, die auf den Aufenthaltsort des Nutzers abgestimmte Informationen liefern (vgl. [Coric 2003]).
LCDUI
Das Lowest Common Denominator User Interface (LCDUI) stellt eine
High-Level-API und eine Low-Level-API für die Realisierung von Bedienoberflächen auf mobilen Endgeräten unter J2ME bereit.
MIDlet
Ein MIDlet ist ein Softwareprogramm für ein Mobiltelefon oder vergleichbares mobiles Gerät, welches in der Programmiersprache Java
geschrieben ist und dem MIDP entspricht (vgl. [Wikipedia 2005]).
MIDlet-Suite
Eine MIDlet-Suite ist die kleinste installierbare Einheit einer J2MEAnwendung. Ein oder mehrere MIDlets bilden eine MIDlet-Suite (vgl.
[Schmatz 2004])
MIDP
„MIDP (Mobile Information Device Profile) ist ein Profil der J2ME, das
speziell auf die Fähigkeiten mobiler Endgeräte wie Mobiltelefonen ausgelegt ist. Es umfasst Funktionen zur Ansteuerung und Abfrage von
ITU-T Einhandtastaturen, Miniaturbildschirmen, flüchtigen und nichtflüchtigen Speichern im Kilobyte-Bereich etc“ [Wikipedia 2005].
MySQL
MySQL ist ein SQL-Datenbankverwaltungssystem. MySQL ist freie
Software und steht seit einiger Zeit unter der GPL und einer kommerziellen Lizenz (Dual Licence) zur Verfügung. Es gehört zu den am weitesten verbreiteten Open-Source-Programmen (vgl. [Wikipedia 2005]).
Abkürzungsverzeichnis/Glossar
- 96 -
NMEA
Der National Marine Electronics Association (NMEA)-Standard ist ein
Übertragungsstandard im maritimen Bereich. Hauptanwendung ist
hierbei die Weitergabe von Positionsdaten eines Global Navigation Satellite System (GNNS) an andere Geräte.
Open Source
Open Source bzw. Quelloffenheit bedeutet, dass es jedem ermöglicht
wird, Einblick in den Quelltext eines Programmes zu haben. Die Open
Source Initiative wendet den Begriff Open Source auf alle Software an,
deren Lizenzverträge den folgenden Merkmalen entspricht: Die Software (d.h. der Programmcode) liegt in einer für den Menschen lesbaren und verständlichen Form vor. Die Software darf beliebig kopiert,
verbreitet und genutzt werden. Die Software darf verändert und in der
veränderten Form weitergegeben werden (vgl. [Wikipedia 2005]).
Parser
Ein Parser (zu deutsch Analysator oder Zerteiler) ist ein Programm,
das entscheidet, ob eine Eingabe zur Sprache einer bestimmten
Grammatik gehört. Ein XML-Parser zerteilt z.B. die XML-Knoten,
Elemente und Attribute in einzelne Teile.
PDA
Personal Digital Assistent (PDA) sind Mini-Computer die im Grunde die
Funktionen eines Kalenders oder Notizbuches übernehmen. Inzwischen
beherrschen allerdings PDAs deutlich mehr und können ebenso auch
Videos und Musik abspielen oder zum Schreiben von Dokumenten oder
Tabellen genutzt werden.
Prepaid-Karte
„Eine Prepaid-Karte (Guthabenkarte) ist eine vorausbezahlte Mobiltelefonkarte ohne Vertragsbindung, deren Guthaben abtelefoniert werden
kann. Es fallen nur die reinen Gesprächskosten an; eine Grundgebühr
wird nicht erhoben“ [Wikipedia 2005].
RMS
Das RMS (Record Management System) bietet eine transparente Programmierschnittstelle für lesende und schreibende Zugriffe auf diese
persistenten Daten innerhalb der MIDP-Spezifikation.
SAX
Mit Hilfe der Simple API for XML Parsing (SAX) wird eine XML-Datei
wie ein Datenstrom eingelesen. Für erkannte Elemente wird ein Ereignis ausgelöst. „Dies ist mit dem Nachteil verbunden, dass wahlfreier
Zugriff auf ein einzelnes Element nicht ohne Zwischenspeicherung
möglich ist. SAX ist im Gegensatz zu DOM jedoch nicht so speicherhungrig, weil das XML-Dokument nicht vollständig im Speicher
abgelegt ist“ [Ullenboom 2005].
Servlet
„Als Servlets bezeichnet man Java-Klassen, deren Instanzen innerhalb
eines Webservers Anfragen von Clients entgegennehmen und beantworten. Solche Klassen müssen immer die Schnittstelle „javax.servlet.Servlet“ oder eine davon abgeleitete (normalerweise „javax.servlet.http.HttpServlet“) implementieren“ [Wikipedia 2005].
Set-Top-Boxen „Unter dem Begriff Set-Top-Box (englisch für Draufstellkasten) versteht man in der Unterhaltungselektronik ein Gerät, das an ein
anderes angeschlossen wird und damit zusätzliche Funktionen liefert.
Das Basisgerät ist meist ein Fernseher „älterer“ Generation, welcher
durch eine Set-Top-Box für neue Dienste erweitert wird. So ist es zum
Beispiel möglich, digitales Fernsehen über den Fernseher zu betrachten“ [Wikipedia 2005].
Abkürzungsverzeichnis/Glossar
- 97 -
SDK
„Ein Software Development Kit (SDK) ist eine Sammlung von Programmen und Dokumentationen zu einer bestimmten Software, die es
Software-Entwicklern erleichtern bzw. erst ermöglichen soll, eigene
darauf basierende Anwendungen zu erstellen“ [Wikipedia 2005].
Singleton
„Das Einzelstück (engl. Singleton) ist ein in der Softwareentwicklung
eingesetztes Entwurfsmuster und gehört zur Kategorie der Erzeugungsmuster (engl. Creational Patterns). Es stellt sicher, dass zu einer
Klasse nur genau ein Objekt erzeugt werden kann und ermöglicht
einen globalen Zugriff auf dieses Objekt“ [Wikipedia 2005].
Smartphone
Smartphones sind moderne Mobiltelefone, die nicht nur Gespräche und
Daten übertragen, sondern auch Termine verwalten oder Adressen
speichern können. Ziel ist die Verknüpfung eines Mobiltelefons mit den
Funktionen eines PDA.
SMS
Short Message Service (SMS) ist ein Telekommunikationsdienst zur
Übertragung von Textnachrichten, der zuerst für den GSM-Mobilfunk
entwickelt wurde und nun auch im Festnetz verfügbar ist.
SMTP
Das Simple Mail Transfer Protocol (SMTP) ist ein einfaches Übertragungsprotokoll, das den Versand von E-Mails in Computer-Netzwerken regelt.
SOAP
Simple Object Access Protocol (SOAP) ist ein Protokoll, mit dessen Hilfe Daten zwischen Systemen ausgetauscht und Remote Procedure
Calls (RPC) durchgeführt werden können. SOAP stützt sich auf die
Dienste anderer Standards: XML zur Repräsentation der Daten und Internet-Protokolle der Transport- und Anwendungsschicht zur Übertragung der Nachrichten. Die gängigste Kombination ist SOAP über
HTTP (vgl. [Wikipedia 2005]).
StringTokeni-
Die Java-Klasse StringTokenizer ermöglicht eine Zeichenkette in Token
zu zerlegen, wobei die Klasse nicht an bestimmte Trenner gebunden
ist, sie können vielmehr völlig frei gewählt werden. In der Voreinstellung sind Tabulator, Leerzeichen und Zeilentrenner die Delimiter (vgl.
[Ullenboom 2005]).
zer
SQL
SQL ist eine deklarative Abfragesprache für Relationale Datenbanken.
SQL wird im allgemeinen Sprachgebrauch als Abkürzung für „Structured Query Language“ aufgefasst, obwohl laut American National
Standards Institute (ANSI) SQL eigentlich ein eigenständiger Name ist
(vgl. [Wikipedia 2005]).
Tag
In der Datenverarbeitung und Informatik steht das englische Wort Tag
(Etikett, Anhänger, Aufkleber, Marke) für die Auszeichnung eines Datenbestandes mit zusätzlichen Informationen. In Auszeichnungssprachen (engl. mark-up languages) wie XML oder HTML bezeichnet das
Wort Tag die in Kleiner- und Größerzeichen eingeschlossenen Kürzel
(vgl. [Wikipedia 2005]).
UDDI
Das UDDI (Universal Description and Discovery Interface) stellt eine
standardisierte Methode für das Publizieren und das Auffinden von
Web Services zur Verfügung (vgl. [Hein 2003]).
Abkürzungsverzeichnis/Glossar
- 98 -
UML
Die Unified Modeling Language (UML) ist eine standardisierte Sprache
für die Modellierung von Software und anderen Systemen. Im Sinne
einer Sprache definiert die UML dabei Bezeichner für die meisten Begriffe, die für die Modellierung wichtig sind, und legt mögliche Beziehungen zwischen diesen Begriffen fest. Die UML definiert weiter grafische Notationen für diese Begriffe und für Modelle von statischen
Strukturen und von dynamischen Abläufen (vgl. [Wikipedia 2005]).
UMTS
Universal Mobile Telecommunications System (UMTS) ist der Mobilfunkstandard der dritten Generation. UMTS ermöglicht Bandbreiten
von bis zu 2 Mbit/s. Allerdings teilen sich alle Teilnehmer einer Funkzelle diese Bandbreite, sodass dieser Wert eher theoretisch ist.
URL
Uniform Resource Locator (URL), engl. „einheitlicher Ortsangeber für
Ressourcen“, identifiziert eine Ressource über ihren primären Zugriffsmechanismus (z.B. HTTP) und den Ort (engl. location) der Ressource
in Computernetzwerken.
Vererbung
Vererbung in der objektorientierten Programmierung heißt, dass eine
abgeleitete Klasse Methoden und Objekte der Basisklasse ebenfalls
besitzt, also „erbt“. Somit kann sie auch darauf zugreifen.
virtuellen Maschine
„Eine virtuelle Maschine (VM) ist allgemein ein Modell eines Prozessors
und der zugehörenden Systemarchitektur, dessen Rechenweise unabhängig von der technischen Ausführung beschrieben wird“ [Wikipedia 2005].
W3C
Das World Wide Web Consortium (W3C) ist das Gremium zur Standardisierung das World Wide Web betreffender Techniken. Zu diesen
Techniken zählen unter anderem HTML, XML und DOM.
Web Services
Web Services sind Dienste, die über XML-kodierte Nachrichten kommunizieren. Web Services verwenden folgende Standards als Grundlage: WSDL zur Beschreibung der Schnittstelle, SOAP für die Kommunikation und UDDI als Verzeichnisdienst. XML wird als Grundlage
für zahlreiche Beschreibungen innerhalb von Web Services genutzt.
Wiki
Ein Wiki ist eine im World Wide Web verfügbare Seitensammlung, die
von den Benutzern nicht nur gelesen, sondern auch online geändert
werden kann. Wikis ähneln damit Content Management Systemen. Wie
bei Hypertexten üblich, sind die einzelnen Seiten und Artikel eines
Wikis durch Querverweise (Links) miteinander verbunden. Dazu gibt es
in der Regel eine Bearbeitungsfunktion, die ein Eingabefenster öffnet,
in dem der Text des Artikels bearbeitet werden kann (vgl. [Wikipedia
2005]).
WLAN
Wireless Local Area Network (WLAN) ist ein Netzwerk im Lokalbereich,
das seine Daten durch Funk versendet, in der Regel auf einer unlizenzierten Frequenz wie dem 2,4-GHz-Band. In einem solchen drahtlosen Netzwerk ist es nicht nötig, dass die Geräte zur Datenübertragung Sichtkontakt zueinander haben, wie dies bei einer InfrarotVerbindung der Fall ist. WLANs sind im Standard der IEEE 802.11-Familie beschrieben.
Abkürzungsverzeichnis/Glossar
- 99 -
WSDL
Die Web Service Description Language (WSDL) stellt eine Basistechnologie für die Entwickelung von Web Services dar. Sie ist im wesentlichen eine Spezifikation, die festlegt, wie Web Services über eine XMLGrammatik beschrieben werden können. Die Sprache definiert die
Schnittstellen zwischen einem bereitgestellten Dienst und einem
anfragenden Clienten (vgl. [Hein 2003]).
WTK
„Das J2ME Wireless Toolkit (WTK) von Sun Microsystems ist ein Werkzeug für das Übersetzen, Paketieren und Ausführen von MIDlet-Suites“
[Schmatz 2004].
XML
Die Extensible Markup Language (XML) ist ein Standard zur Erstellung
strukturierter, maschinen- und menschenlesbarer Dateien. XML definiert dabei den grundsätzlichen Aufbau solcher Dateien. Für die konkreten Anwendungsfälle müssen die Details des Dateiaufbaus jedoch
weiter spezifiziert werden. Die Grundidee ist dabei, Daten und ihre
Darstellung voneinander zu trennen.
Literaturverzeichnis
- 100 -
Literaturverzeichnis
[DPA 2004] DPA: Jeder fünfte Mensch hat ein Handy (2004),
http://www.stern.de/computer-technik/telefon/?id=533529
[Koelmel 2002] Bernhard Kölmel: Location Based Services: Wünsche und Realität
(2002), http://www.e-lba.com/YellowMap LBS Wuensche und Realität.pdf
[Coric 2003] Elmedina Coric, Yvonne Dünßer: Location Based Services - Hoffnungsträger
der Service Provider (2003), http://www.cawar.de/seminar/ss03/Ausarbeitungen/LBS
Markt.pdf
[Heise 2005] Heise Verlag, Studie: SMS behält Löwenanteil des mobilen Datenverkehrs,
2005 http://www.heise.de/mobil/newsticker/meldung/58329
[Wikipedia 2005] Wikipedia-Gemeinde (freiwillige Autoren): die freie Wikipedia Enzyklopädie, insbesondere die Seiten: A-GPS, Applikation Server, Bluetooth, Daemon, ERM,
Framework, Galileo, GPS, Handover, HTML, HTTP, IEEE, JAX-RPC, JDBC, JVM, MIDlet,
MIDP, MySQL, Open Source, Prepaid, Reichweite und Antennen, Servlet, Set-Top-Boxen,
SDK, Singleton, SMS, SOAP, SQL, Tags, UML, VM, Web Service, Wiki (2005),
http://de.wikipedia.org/
[Golem 2005] : Siemens zeigt UMTS-Handy mit vollwertigem GPS-Empfänger (2005),
http://www.golem.de/0503/36792.html
[Winter 2004] Marie-Anne Winter: Schatzsuche per GPS-Handy (2004), http://www.teltarif.de/arch/2004/kw16/s13467.html
[Albert 2004] B. Albert: GPS in Handys wird in Japan 2007 zur Pflicht (2004),
http://www.areamobile.de/news/1987.html
[IZMF 2005] IZMF: Warum stellt der Mobilfunk einen wesentlichen Wirtschaftsfaktor
dar? (2005), http://www.izmf.de/html/de/586.html
[Bager 2002] Jo Bager (Heise-Verlag): Das Handy kennt den Weg (2002), http://www.heise.de/mobil/artikel/50855
Literaturverzeichnis
- 101 -
[Theisen 2002] Carsten Theisen: Location Based Services zwischen Interesse und Befürchtungen (2002),
http://www.absatzwirtschaft.de/psasw/fn/asw/SH/0/sfn/cn_artikel_print/id/24109/aktele
m/Document_1003186/
[Roeder 2004] Patrick Röder: Location Server (2004), http://www.patrick-roeder.de/roeder_diplom.pdf
[Fleuren 2004] Tino Fleuren: Location Sensing für ortsabhängige Dienste auf Basis von
Web Services (2004), http://www.icsy.de/~archiv/DPArchiv.0099.pdf
[Panitzki 2005] Michael Panitzki: Navigation - GPS (2005),
http://home.arcor.de/m.panitzki/html/navigation/gps.htm
[TU Ilmenau 2005] TU Ilmenau: Das Grundprinzip des GPS und DGPS (2005),
http://ikmcip1.e-technik.tu-ilmenau.de/~traut/gps_www/gps_main.htm
[Abel 2005] Heinrich Abel: GPS: Global Positioning System? - Funktionsweise und mathematische Grundlagen (2005), http://www2.fht-esslingen.de/~abel/gps/Abel-GPS.htm
[Rat der EU 2005] Der Rat der EU: Beschluss des Rates über die Unterzeichnung eines
Kooperationsabkommens über ein ziviles globales Satellitennavigationssystem (GNSS)
(2005), http://europa.eu.int/eur-lex/lex/LexUriServ/site/de/com/2005/com2005_0350de01.pdf
[Badach 2005] Anatol Badach: Voice over IP - Die Technik (2005), Carl Hanser Verlag
[Bayer. Landesamt 2004] Bayerisches Landesamt für Umweltschultz: Handy und Mobilfunk (2004), http://www.bayern.de/lfu/umwberat/data/band/handy_mobilfunk.pdf
[Heise 2000] Heise Verlag: Hintergrund: Die Gewinner der sechs UMTS-Lizenzen
(2000), http://www.heise.de/newsticker/meldung/11330
[Turczyk 2005] Lars Arne Turczyk: WLAN und UMTS – Konkurrenz oder Ergänzung?
(2005), http://www.elektroniknet.de/topics/kommunikation/fachthemen/2005/0004/index_a.htm
[DSL Web 2005] DSL Web: USA: Über 100 Städte wollen WLAN-Netze aufbauen (2005),
http://www.dslweb.de/dsl-news/USA--Ueber-100-Staedte-wollen-WLAN-Netze-aufbauenNews-1225.htm
[Schmatz 2004] Klaus-Dieter Schmatz: Java 2 Micro Edition - Entwicklung mobiler
Anwendungen mit CLDC und MIDP (2004), dpunkt.verlag
Literaturverzeichnis
- 102 -
[Kroll 2005] Michael Kroll, Hans-Gerd Lipinski: Technologieüberblick: Die Java 2 Micro
Edition (J2ME), Connected Limited Device Configuration (2005), http://www.medizin.unikoeln.de/projekte/gmds-mocomed/workshop2001/tagungsband/2_low.pdf
[Frech 2003] Tobias Frech: Mobile / Wireless Applications mit J2ME am Beispiel eines
Instant-Messaging-Clients (2003), http://www.linecity.de/downloads/Diplomarbeit_Tobias_Frech.pdf
[Metzger 2004] Steffen Metzger, Marco Dengel: Ein virtueller Museumsbegleiter Entwicklung einer mobilen multimedialen Anwendung unter Verwendung der Java 2 Micro
Edition und Bluetooth (2004)
[Topley 2002] Kim Topley: J2ME in a nutsthell (202), O´Reilly
[Armstrong 2005] Eric Armstrong u.a. (Sun Microsystems): The J2EE™ 1.4 Tutorial
(2005), http://java.sun.com/j2ee/1.4/docs/tutorial/doc/J2EETutorial.pdf
[Hein 2003] Manfred Hein, Henner Zeller: Java Web Services - Entwicklung plattformübergreifender Dienste mit J2EE, XML und SOAP (2003), Addison Wesley
[W3C 2000] The Word Wide Web Consortium (W3C): Simpel Object Access Protocol
(SOAP) 1.1 (2000), http://www.w3.org/TR/SOAP
[Mintert 2002] Stefan Mintert: XML & Co, Die W3C-Spezifikation für Dokumenten- und
Datenarchitektur (2002), Addison-Wesley
[Oestereich 2001] Bernd Oestereich: Objektorientierte Softwareentwicklung (2001),
Oldenbourg
[Elmasri 2002] Ramez Elmasri, Shamkant B. Navathe: Grundlagen von Datebanksystemen (2002), Addison-Wesley
[Gamma 2004] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Elemente
wiederverwendbarer objektorientierter Software (2004), Addison-Wesley
[Ullenboom 2005] Christian Ullenboom: Java ist auch eine Insel, Programmieren für die
Java 2-Plattform in der Version 5 (2005), Galileo Computing
[Goetz 2000] Rüdiger Goetz: Die Runlevels und die Init-Skripte (2000), http://r-goetz.de/linux/bg/runlevels.html
Anmerkung: Auf der beiliegenden CD-ROM sind alle Informationen aus Internet-Quellen
sind als Kopie enthalten. Der Zugriff auf diese Quellen erfolgte am 06.12.2005.
- 103 -
Erklärung
Hiermit erkläre ich, dass ich die von mir eingereichte Diplomarbeit „Location Based Services am Beispiel eines interaktiven Stadtführers auf Basis von J2ME“ selbstständig und
nur unter Verwendung der angegebenen Quellen und Hilfsmitteln angefertigt habe.
Fulda, den 14.12.2005
____________________________
(Name des Verfassers)
Hinweise zum Copyright
Hiermit stelle ich dieses Dokument, inklusive der zu dieser Diplomarbeit zugehörigen
Quelltexte unter die GPL-Lizenz. Ich freue mich, wenn ich auf diesem Wege andere
Entwickler und die Open-Source-Community unterstützen kann.
Fulda, den 14.12.2005
____________________________
(Name des Verfassers)
- 104 -
Anlagen
- 105 -
Anlagen
Anlage A: Installation für Entwickler...............................................................106
A.1 J2SE SDK................................................................................................107
A.2 J2ME Wireless Toolkit...............................................................................107
A.3 J2EE SDK inklusive Applikation Server........................................................108
A.4 MySQL Datenbank....................................................................................110
A.5 Apache2 und phpMyAdmin........................................................................110
A.6 DynDNS..................................................................................................111
A.7 Eclipse....................................................................................................111
A.8 EclipseME (Eclipse Plugin).........................................................................112
A.9 Lamboz (Eclipse Plugin)............................................................................113
Anlage B: CD-ROM zur Diplomarbeit (Verzeichnisstruktur)
Binaerdateien
Dokumente
JavaDoc
Programme
Quellcode
Quellen
Anlage A: Installation für Entwickler
- 106 -
Anlage A: Installation für Entwickler
Nachfolgend wird die Installation sowie die Konfiguration der in dieser Diplomarbeit eingesetzten Entwicklungswerkzeuge beschrieben. Die dargestellte Anleitung dient der Einrichtung eines Entwicklungssystems. Als Betriebssystem wird das Linux-System Suse
Professional 9.3 eingesetzt. Alle betriebssystem-spezifischen Angaben beziehen sich auf
dieses System. Alle eingesetzte Software, abgesehen von den Java-Plattformen, sind
Open-Source. Auf der dieser Diplomarbeit beiliegenden CD-ROM befinden sich die notwendigen Installationsdateien.
Es wird auf die Installation der unterschiedlichen Java-Plattformen (J2SE, J2ME, J2EE)
eingegangen. Die Einrichtung des Applikation Servers von Sun Microsystems wird ebenso
wie die Installation des Datenbanksystems MySQL beschrieben. Die Einrichtung von phpMyAdmin auf einem Apache-Webserver wird dargestellt. Die Notwendigkeit und die Einrichtung von DynDNS wird beschrieben. Ebenfalls wird die Integration von J2ME und J2EE
in Eclipse erläutert. Eine Übersicht über die eingesetzte Software liefert die Tabelle 15.
Software /
Modul
Voraussetzungen
Beschreibung
verwendete
Version
J2SE
-
Java 2 Stadard Edition (SDK)
5.0.03
J2ME
J2SE
Java 2 Micro Edition (Wireless Toolkit) 2.2
J2EE
-
Java 2 Enterprice Edition (SDK)
1.4
MySQL
-
Freier Datenbankserver
4.1.10
Apache2
-
PHP Webserver
2.0.53
phpMyAdmin MySQL, Apache2 Webtool zur Datenbankadministration
2.6.4
DynDNS
-
Dynamic DNS (für Namensauflösung)
-
Eclipse
J2SE
Java-Entwicklungsumgebung
3.1.1
EclipseME
Eclipse, J2ME
Eclipse Plugin für J2ME-Entwicklung
1.1.0
Lamboz
Eclipse, J2EE
Eclipse Plugin für J2EE-Entwicklung
3.1
Tabelle 15 Übersicht über die in dieser Diplomarbeit eingesetzte Software
A.1 J2SE SDK
- 107 -
A.1 J2SE SDK
In dieser Diplomarbeit wird die J2SE Version (5.0) eingesetzt. Suse 9.3 Professional wird
mit der vorigen Java-Version ausgeliefert, weswegen die aktuelle Version über die Homepage http://www.java.sun.com von Sun Microsystems bezogen werden muss. Zum Ausführen von J2SE-Anwendungen (JRE) ist die Installation des Paketes java-1_5_0-sun1.5.0_03-5.i586.rpm notwendig. Um J2SE-Anwendungen entwickeln zu können, muss
das Paket java-1_5_0-sun-devel-1.5.0_03-5.i586.rpm zusätzlich installiert werden. In
der Konsole lässt sich mit dem Kommando java -version die aktuell verwendete JavaVersion anzeigen.
A.2 J2ME Wireless Toolkit
Zur Installation von J2ME bietet Sun Microsystems http://www.java.sun.com ein Gesamtpaket an, dass neben der J2ME noch zusätzliche Tools und Pakete enthält. Das Gesamtpaket wird als Wireless-Toolkit bezeichnet und wird in der Version 2.2 in dieser Diplomarbeit verwendet. Voraussetzung für die Installation des Toolkits ist eine bereits installierte J2SE. Für die Linux-Systeme wird eine Binärdatei bereitgestellt, welche als root
über den Konsolen-Aufruf ./j2me_wireless_toolkit-2_2-linux-i386.bin ausgeführt
werden kann. Das Installationsscript fragt nach dem Pfad zur SDK, wo der Pfad zur aktiven J2SE angegeben werden muss. Im Falle der unter Kapitel A beschriebenen J2SE Installation lautet dieser: /usr/lib/jvm/java-1.5.0-sun-1.5.0_03/bin. Das Toolkit kann
z.B. nach /usr/lib/jvm/java-1.5.0-sun-1.5.0_03/WTK2.2/ installiert werden. Das
Wireless-Toolkit stellt die Anwendung KToolbar bereit (siehe Abbildung 51), mit dessen
Hilfe J2ME-Projekte erstellt, compiliert und ausgeführt werden können. Aufgerufen wird
diese Anwendung über /usr/lib/jvm/java-1.5.0-sun-1.5.0_03/WTK2.2/bin # ./
ktoolbar.
Abbildung 51 Start-Bildschirm der Anwendung „KToolbar“ des WTK
A.3 J2EE SDK inklusive Applikation Server
- 108 -
A.3 J2EE SDK inklusive Applikation Server
Für die Realisierung von Web Services und Servlets ist die J2EE notwendig. Diese lässt
sich wie alle anderen Java-Plattformen über die Homepage http://www.java.sun.com von
Sun Microsystems beziehen. In dieser Diplomarbeit wird die Version J2EE 1.4 eingesetzt.
Es empfiehlt sich die komplette SDK zu installieren. Diese beinhaltet den Sun Microsystems Applikation Server (Plattform Edition), die J2SE 5.0 sowie Beispiele und Dokumentationen zu J2EE.
Die Installation wird über den Aufruf von ./j2eesdk-1_4_02_2005Q2-linux-ml.bin
gestartet. Es öffnet sich ein Installationswizard. Nach Bestätigung der Lizenzbedingungen
und der Wahl des Installationsverzeichnis (Standard: /opt/SUNWappserver), erscheint
das in Abbildung 52 dargestellte Fenster. Bei einem Entwicklungssystem, auf dem keine
hohe Sicherheit verlangt wird, kann die erste Option zum Speichern des Admin-Passwortes ausgewählt werden. Standardmäßig horcht der Applikation Server auf dem Port
8080. In dieser Diplomarbeit wird der HTTP-Port auf 80 gesetzt. Dadurch ist kein zusätzlicher Proxy für die Weiterleitung der HTTP-Anfragen aus dem Internet über den Router
an den Server notwendig (siehe Kapitel A). Im darauffolgenden Fenster besteht die
Möglichkeit bestimmte Optionen für die Installation festzulegen, diese können ohne
Änderungen übernommen werden. Anschließend startet die eigentliche Installation.
Abbildung 52 Installationswizard der J2EE-SDK Installation
A.3 J2EE SDK inklusive Applikation Server
- 109 -
Nach der Installation wird unter /opt/SUNWappserver/bin/asadmin ein konsolen-basiertes Tool zur Administration des Applikation Servers bereitgestellt. Standardmäßig ist die
Domäne domain1 eingerichtet. Über den Aufruf von /opt/SUNWappserver/bin/asadmin
start-appserv wird der Applikation Server gestartet. Das Stoppen des Servers sowie die
Verwaltung der Domänen ist über dieses Tool ebenfalls möglich.
Ist der Applikation Server gestartet, erreicht man im Browser über den HTTP-Aufruf
http://localhost:4848/ den Anmeldebildschirm der grafischen Administrationsoberfläche
für die Standarddomaine domain1. Die Abbildung 53 zeigt die Administrationsoberfläche
nach erfolgreicher Anmeldung.
Abbildung 53 Administratioinsoberfläche des Applikation Servers von Sun
Mit Hilfe des Deployment Tools lassen sich Server-Applikationen erstellen, öffnen und
schließlich auf den Applikation Server einbinden (engl. deployn). Das Tool wird über das
Kommando /opt/SUNWappserver/bin/deploytool aufgerufen.
A.3 J2EE SDK inklusive Applikation Server
- 110 -
Damit der Applikation Server automatisch nach einem Neustart gestartet wird, muss ein
neuer Daemon in Form eines Shellscriptes erstellt werden (siehe Abbildung 54):
#! /bin/sh
/opt/SUNWappserver/bin/asadmin start-appserv
Abbildung 54 Shellscript zum Starten des Applikation Servers als Daemon
Das Shellscript wird zum Beispiel unter dem Namen SunServer im Verzeichnis /etc/init.d gespeichert. Die Ausführungsrechte für dieses Skript müssen für den Benutzer root
gesetzt werden. Die Integration des Daemons in ein Runlevel kann mit Hilfe von YAST
vorgenommen werden. Eine Aktivierung des Daemons ohne Zuhilfenahme von YAST ist in
[Goetz 2000] beschrieben. Unter YAST -> System -> Runlevel-Editor wird eine Liste
der verfügbaren Dienste angezeigt. In dieser Liste wird der eben erstelle Daemon aufgelistet. Im Expertenmodus ist es möglich den Daemon, z.B. für die Runlevel 3 (Full
Multiuser Mode) und 5 (X11 – grafische Oberfläche), zu aktivieren. Nach einem Wechsel
in einen dieser Runlevels wird der Applikation Server automatisch gestartet.
A.4 MySQL Datenbank
Um bestimmte Informationen für z.B. einen Web Service persistent und zentral abzuspeichern ist das Einrichten einer MySQL-Datenbank notwendig. MySQL ist das populärste
Open-Source Datenbankmanagementsystem (DBMS), weshalb es auch in dieser Diplomarbeit eingesetzt wird (Version: 4.1.10). Zur Installation muss das von Suse mitgelieferte
Paket mysql z.B. mit Hilfe von YAST installiert werden. Damit MySQL beim Systemstart
gestartet wird, muss unter YAST -> System -> Runlevel-Editor der Dienst für zum
Beispiel das Runlevel 3 und 5 aktiviert werden.
A.5 Apache2 und phpMyAdmin
Da in dieser Diplomarbeit kein Client zur Informationspflege implementiert wurde,
können Änderungen nur direkt auf der Datenbank eingetragen werden. Hierfür bietet sich
die Open-Source PHP-Applikation phpMyAdmin an. Mit phpMyAdmin lassen sich MySQLDatenbanken einfach und schnell über das HTTP mit einem Browser ansprechen. Zunächst muss der Apache2 Webserver (Paket apache2, eingesetzte Version 2.0.53) zum
Beispiel mit Hilfe von YAST installiert werden. Unter YAST -> Netzwerkdienste ->
HTTP-Server wird der Webserver Dienst aktiviert und der Port eingestellt (z.B. Port
8080, der Port 80 ist bereits vom Applikation Server belegt). PhpMyAdmin kann von der
Projekt-Homepage http://www.phpmyadmin.net bezogen und muss in das Verzeichnis
/srv/www/htdocs/phpMyAdmin kopiert werden. Anschließend erreicht man die Applikation über die Adresse http://localhost:8080/phpMyAdmin.
A.6 DynDNS
- 111 -
A.6 DynDNS
Für diese Diplomarbeit steht kein bereits ins Internet integrierter Java Applikation Server
zur Verfügung. Aus diesem Grund wird der private Rechner, wie im Kapitel A beschrieben, als Applikation Server eingerichtet. Die Internet-Anbindung erfolgt über einen
DSL-Zugang und einem DSL-Router. Mit dieser Internetverbindung steht keine statische
öffentliche IP-Adresse zur Verfügung. Die externe IP-Adresse des DSL-Routers ändert
sich nach jeder Internet-Neuverbindung (engl. Reconnect). Zu einer Neuverbindung
kommt es spätestens nach 24 Stunden, da nach dieser Zeit der Provider die Verbindung
automatisch trennt und der DSL-Router die Verbindung neu aufbauen muss.
Damit Anfragen der J2ME-Anwendungen erfolgreich zu dem Applikation Server weitergeleitet werden können, sind zwei Dinge notwendig: Einerseits muss der DSL-Router die
externen HTTP-Anfragen (engl. HTTP-Request) an den privaten Rechner, der als Server
agiert, weiterleiten. Anderseits muss ein dynamischer DNS Dienst die Umsetzung des
Domainnamens zur aktuellen IP-Adresse des Routers realisieren. Die richtige Weiterleitung der HTTP-Anfragen wird auf dem DSL-Router konfiguriert. Da die Konfiguration
von dem eingesetzten Router abhängig ist, wird auf eine detailierte Beschreibung an
dieser Stelle verzichtet. Der private Rechner muss über eine feste IP-Adresse verfügen.
Für die Namensauflösung des Domainnamens zu der aktuellen IP-Adresse wird in dieser
Diplomarbeit das kostenlose System DynDNS http://www.dyndns.com eingesetzt. Es
wurde die Subdomain www.olaflange.homelinux.org zum Testen des interaktivem Stadtführers bei DynDNS registriert. Auf dem DSL-Router wurde ein Dienst aktiviert, der DynDNS automatisch über die aktuelle IP-Adresse informiert.
A.7 Eclipse
Eclipse ist ein mächtiges und frei verfügbares Framework (Open Source), das meist als
Java Entwicklungsumgebung genutzt wird. Eclipse ist selbst in Java geschrieben und somit auf unterschiedlichen Systemen (z.B. Linux, Mac, Windows) ausführbar. Durch die
Möglichkeit das System durch zusätzliche Plugins zu erweitern, ist es möglich eine individuelle Umgebung einzurichten. Die dadurch erzielte Flexibilität und Erweiterbarkeit trägt
maßgeblich zum Erfolg von Eclipse bei. Die aktuelle Version von Eclipse kann von der
Projekt-Homepage http://www.eclipse.org bezogen werden. Eclipse muss nicht wie andere Software installiert werden, sondern wird einfach durch das Aufrufen von eclipse im
Eclipse-Verzeichnis gestartet. In dieser Diplomarbeit wird die Version 3.1.1 eingesetzt.
A.8 EclipseME (Eclipse Plugin)
- 112 -
A.8 EclipseME (Eclipse Plugin)
Durch das Open-Source Plugins EclipseME ist es möglich J2ME Anwendungen unter Eclipse zu entwickeln und aus der Entwicklungsumgebung heraus im Emulator auszuführen.
Das Einrichten des Plugins gestaltet sich sehr einfach. Es müssen lediglich die Plugin JARArchive in das Verzeichnis /eclipse/plugins und das Feature JAR-Archiv in das /eclipse/features kopiert werden. Diese Archive lassen sich über die Projekt-Homepage
http://www.eclipse.org beziehen.
Nach dem Neustart von Eclipse muss das Java 2 Wireless Toolkit (WTK) eingerichtet
werden. Hierzu müssen die Benutzervorgaben wie in Abbildung 55 dargestellt über die
Menüleiste Window->Preferences aufgerufen werden. Unter J2ME->Platform
Components lässt sich mit einem Klick ins Kontextmenü vom WTK ein neues Toolkit hinzufügen. Als Verzeichnis muss im Falle der unter Kapitel A beschriebenen Installation /
usr/lib/jvm/java-1.5.0-sun-1.5.0_03/WTK2.2/ angegeben werden. Anschließend
kann ein neues J2ME MIDlet Suite Projekt über File->New->Project erstellt werden.
Abbildung 55 Konfiguration von EclipseME, Eclipse-Plugin für die J2ME
A.9 Lamboz (Eclipse Plugin)
- 113 -
A.9 Lamboz (Eclipse Plugin)
Durch das Open-Source Plugins Lamboz ist es möglich J2EE Anwendungen unter Eclipse
zu entwickeln und direkt in verschiedenen Applikation Servern einzubinden. Das Einrichten des Plugins gestaltet sich sehr einfach. Es müssen lediglich die Plugin-Dateien in das
Verzeichnis /eclipse/plugins und die Feature Dateien in das /eclipse/features kopiert werden. Diese Dateien lassen sich über die Projekt-Homepage http://www.objectlearn.com beziehen. In dieser Diplomarbeit wird die Version 3.1 des Lamboz-Plugins eingesetzt.

Documentos relacionados