Entwurf und Implementierung eines ortssensitiven Trouble-Ticket-Systems. Concept and implementation of a location-based trouble ticket system

Transkript

1 F Entwurf und Implementierung eines ortssensitiven Trouble-Ticket-Systems Concept and implementation of a location-based trouble ticket system Oliver Keim Bachelor Abschlussarbeit Betreuer: Prof. Dr. Georg J. Schneider Trier,

2 Danksagung An dieser Stelle möchte ich mich bei Herrn Professor Dr. Georg J. Schneider für die Unterstützung und Betreuung dieser Abschlussarbeit bedanken. Ebenso möchte ich mich für die bereitgestellte Hardware bedanken, welche die praxisnahe Umsetzung des Projektes ermöglicht hat.

3 Kurzfassung Diese Abschlussarbeit wurde im Rahmen des Bachelor-Infomatik Studiums an der Fachhochschule Trier angefertigt. Sie befasst sich mit dem Entwurf und der Implementierung eines ortssensitiven Trouble-Ticket-Systems. Schwerpunkt der Arbeit ist die Integration von Mobiltelefonen in dieses System 1. Hierbei kann das Servicepersonal anstehende Aufträge mit dem Mobiltelefon abrufen, wobei es nur diejenigen Aufträge erhält, die sich innerhalb einer bestimmten Reichweite zu ihm befinden. Voraussetzung hierfür ist die Verwendung eines GPS-fähigen Mobiltelefons. Die Serviceanfragen werden in einer Datenbank verwaltet. Die Kommunikation zwischen dieser Datenbank und den anfragenden Mobiltelefonen wird mit Hilfe einer Gateway-Anwendung realisiert. Weiterhin ist dieses Gateway für das Bereitstellen von Kartenmaterial zuständig, welches jeweils den kürzesten Weg zum Anwender bzw. Kunden aufzeigt. This Bachelor thesis deals with the design and the implementation of a locationbased Trouble Ticket System. The main focus of the project is the integration of mobile workers using cell phones with GPS functionality into this system. The user can access upcoming orders via her mobile phone in a way that only those orders, which are located within a certain reach are displayed. The service requests are stored in a database. The system uses a 3-tier architecture, whereas the communication between the database and the mobile phones is realized via a gateway. Furthermore, the gateway is responsible for the navigation to the point of the service request. It transmits belonging maps, which show the shortest way to the user. 1 Ein Trouble-Ticket-System, welches auch als Helpdesk-System bezeichnet wird, ist eine Software, die den Eingang, die Bearbeitung und jeweilige Lösungen von User-Anfragen verwaltet und koordiniert.

4 Inhaltsverzeichnis 1 Einleitung Motivation Ziele der Arbeit Verwandte Arbeiten Open Ticket Request System Request Tracker Vantive Resümee Grundlagen MySQL Apache Tomcat Java Micro Edition Konfigurationen und Profile Internet-Anbindung Recordstore Management System Google-Maps Google-Maps-API Google-Static-Maps-API Lokalisation Dijkstra-Algorithmus Konzept Realisierung und Implementierung Modellierung der Datenbank Gateway Die Klasse DBConnector Das Servlet MobileGate Das Servlet MapGate Das Servlet IndoorGate Berechnung des kürzesten Pfades Webinterface

5 Inhaltsverzeichnis V Konfiguration Map-Editor Graph-Editor Moblie Client-Software Kommunikation mit dem Gateway Lokalisation Anwendungsbeispiele Webinterface Anlegen eines Anwenders Anlegen einer Serviceanfrage Löschen eines Anwenders Client-Software Hauptmenü Konfiguration Abrufen offener Serviceanfragen Anzeige der Serviceanfragen Problembeschreibung und Auswahl Anzeige der Raumpläne Resümee und Ausblick Literatur Anhang A.1 Programmcode Gateway A.1.1 MobileGate A.1.2 MapGate A.1.3 IndoorGate A.2 Programmcode Client-Software A.2.1 HttpConnectionThread A.2.2 MapThread A.2.3 IndoorThread

6 Abbildungsverzeichnis 3.1 Lebenszyklus eines MIDlets Sequenzdiagramm der POST-Kommunikation Google-Map der Fachhochschule Trier Kommunikationsbeziehung der einzelnen Komponenten Entity Relationship Modell des TTS Verzeichnisstruktur Tomcat Klassendiagramm Gateway Anmeldung am TTS Programmablaufplan MobileGate Programmablaufplan MapGate Verzeichnistruktur auf dem Server Klassendiagramm Webinterface Konfigurationsmenü des Interfaces Karteneditor Map-Editor, Beispiel Schneidershof Standard-Google-Map / editierte Google-Map Graph-Editor, Beispiel Schneidershof Visualisierung Pfadberechnung Klassendiagramm der Client-Software Karte des Aussenbereichs PAP der Indoor-Navigation Hauptmenü der Client-Software GPS-unabhängiges Arbeiten URLs zum Gateway Maximale Entfernung zum User Konfiguration der Tastaturbelegung

7 1 Einleitung 1.1 Motivation In großen Unternehmen stellen die IT-Abteilungen Dienstleistungen zur Unterstützung der eigenen Anwender bereit. Hierbei erstreckt sich der Support meist über mehrere Unternehmensstandorte. Dieser Anwendungssupport besteht in der Regel aus dem First-, Second- und Third-Level-Support. Hierbei ist das oberste Ziel, den Anwendern bei Hard- und Softwareproblemen, Hilfe zu leisten. In Trouble-Ticket-Systemen (TTS) werden die Serviceanfragen (Calls) der Anwender in einer Datenbank erfasst und verwaltet. Ein Trouble-Ticket stellt hierbei die elektronische Form dieser Serviceanfragen dar. Diese Anfragen können einerseits eine Störung (incedent) oder andererseits eine Anfrage (service request) sein. TTS werden weiterhin für statistische Auswertungen und Analysen herangezogen. So ist es zum Beispiel möglich herauszufinden, wie viele Serviceanfragen zu welcher Zeit, von welchem Mitarbeiter bearbeitet wurden. Die Auswertungen führen zu wichtigen Kennzahlen, die unter anderem auch die Effizienz und Produktivität der Serviceabteilung darlegen. Weiterhin ist das Klassifizieren von Ausfällen und Serviceanfragen möglich. Aufbauend auf diesen Klassen können Wissensbasen generiert werden, die ein genaues Vorgehen für jedes Problem einer Klasse vorgeben. In modernen Trouble-Ticket-Systemen werden verschiedene Medien zum Verwalten und Koordinieren der Serviceanfragen kombiniert. So kann ein TTS beispielsweise aus einer Datenbankanwendung, Webinterface und -Diensten aufgebaut sein. Typischerweise werden die Serviceanfragen der Anwender von einer Hotline aufgenommen und in die Datenbank eingepflegt. Das Servicepersonal meldet sich mittels Client-Software oder Webinterface an der Datenbank an und wählt ihre Tickets bzw. Calls zur Bearbeitung aus (Second-Level-Support). Während sich das Personal im Einsatz befindet, können weitere Störungen oder Serviceanfragen an der Hotline eintreffen. In weniger dringenden Fällen stehen diese Anfragen meist an, bis das Servicepersonal wieder in der Zentrale ist. Das erneute Aufsuchen der Anwender kostet zusätzliche Zeit und führt zu unnötigen Kosten. Handelt es sich um dringende Fälle, so wird das Personal oftmals über Mobiltelefone kontaktiert. Hierbei stellen sich folgende Probleme: Die Hotline hat meist keine Kenntnis über den aktuellen Aufenthaltsort des Servicepersonals. Trifft al-

8 1.2 Ziele der Arbeit 2 so eine wichtige Anfrage ein, so stellt sich die Frage, welche Servicekraft zu diesem Zeitpunkt in der Nähe des betroffenen Anwenders ist. Nicht selten kommt es hierbei vor, dass die Hotline mehrere Servicemitarbeiter telefonisch kontaktieren muss, bis ein geeigneter Bearbeiter gefunden wurde. Dieser Vorgang stört nicht nur den Hotline-Betrieb, sondern führt weiterhin zu unnötigen Kosten. Insbesondere im Premium-User-Support 1 ist hierin ein weiteres Problem begründet. So könnten es einige Premium-User als störend empfinden, wenn das Servicepersonal die Arbeit zum Telefonieren unterbricht. Trotz Kenntnis dieser Probleme findet in zahlreichen Unternehmen die Anwenderunterstützung in der beschriebenen Art und Weise statt, worin die Motivation begründet ist, ein Trouble-Ticket-System zu entwerfen, welches die beschriebene Problematik weitestgehend löst. 1.2 Ziele der Arbeit Ziel dieser Arbeit ist die Optimierung von Serviceprozessen, die zu einer Erhöhung der Verfügbarkeit 2 der Unternehmensprozesse führen soll. Dieses Ziel soll durch den Entwurf und die Implementierung eines ortssensitiven Trouble-Ticket-Systems verfolgt werden, wobei der Schwerpunkt der Arbeit auf der Integration von Mobiltelefonen liegt. Mit Hilfe dieser Mobiltelefone, soll es dem Servicepersonal ermöglicht werden, Aufträge innerhalb eines Standortes oder einer bestimmten Reichweite, abzurufen. Zusätzlich soll die Möglichkeit eingeräumt werden, zu jedem Auftrag entsprechendes Kartenmaterial anzufordern. Dieses Kartenmaterial zeigt neben der Mobiltelefon- und Anwender-Position, auch den kürzesten Pfad zwischen Servicepersonal und User. Ebenso soll eine Indoor-Navigation implementiert werden, die das Auffinden der Anwender in Gebäuden ermöglicht. Eine solche Art der Navigation ist immer dann sinnvoll, wenn sich das Servicepersonal in großen Gebäudekomplexen oder Produktionshallen bewegt. Es werden in dieser Arbeit folgende Ziele gesetzt: Implementierung einer Datenbank Verwaltung der Anwenderdaten Verwaltung der Serviceanfragen Speichern von Standorten und Gebäuden Integration von Mobiltelefonen in das System Abrufen, Reservieren und Austragen der Serviceanfragen Darstellung von Kartenmaterial Darstellung von Raumplänen Kommunikation zwischen Dantenbank und Mobiltelefonen 1 Premium-User-Support ist die Unterstützung von Anwendern, deren Arbeitsausfall entweder hohe Kosten oder einen Imageschaden für das Unternehmen bedeutet. So fallen beispielsweise alle Dienstleistungen gegenüber dem Vorstand einer Aktiengesellschaft unter den Premium-User-Support 2 Die Verfügbarkeit gehört zu den IT-Grundwerten eines Unternehmens und ist ein Begriff aus dem Bereich der IT-Sicherheit. Da der Ausfall von Systemen zum Erliegen ganzer Geschäftsprozesse führen kann, wird die Verfügbarkeit oft als wichtigster Grundwert angesehen

9 2 Verwandte Arbeiten 2.1 Open Ticket Request System Das Open Ticket Request System (OTRS) ist ein Open-Source-Projekt, welches unter der GPL 1 Lizenz steht. Das Projekt wurde 2001 von Martin Edenhofer ins Leben gerufen und bis 2008 weltweit etwa mal eingesetzt. OTRS verwaltet Serviceanfragen und Problemstellungen kanalisiert, wobei die Anfragen via , Telefon, Fax und Webinterface aufgenommen werden. Zu jedem Ticket wird eine Historie geführt. Anfragen gleicher Art bzw. ähnlicher Problemstellung werden zu einem Problemthema zusammengefasst. Mehrere Bearbeiter können die Anfragen zur gleichen Zeit einsehen und beantworten. Die Bedienung dieses Systems ist über ein mehrsprachiges Webinterface möglich. Dieses Interface macht das System plattformunabhängig. Weiterhin ermöglicht es, dass auch externe Personen, wie zum Beispiel andere Mitarbeiter und Anwender, an der Bearbeitung der Serviceanfragen mitwirken können. OTRS ist in der Programmiersprache Perl implementiert. Einzelne Funktionen des Webinterfaces werden als separate Code-Module in das System integriert. Hierdurch wird das System leicht erweiterbar. Die Weboberfläche verfügt über die Template-Sprache DTL, wodurch die Daten des Systems flexibel und dynamisch ausgegeben werden. Die Kernkomponente des Systems ist ebenfalls eine Datenbank. Ursprünglich war OTRS auf die Verwendung von MySQL beschränkt. Im Laufe der Zeit wurde das System derart erweitert, dass auch ein Einsatz der Datanbanksysteme Oracle, DB2 und Microsoft SQL Server möglich ist. Die großen Vorteile von OTRS sind seine Skalierbarkeit und Erweiterbarkeit. Durch das Einbringen eigener Module wird das System genau auf die Unternehmensbedürfnisse angepasst. Weitere Informationen zum OTRS-Projekt können auf der Projektseite [Ede08] abgerufen werden. 1 Die Abkürzung GPL steht für General Public License und ist eine freie Lizenz, die von der Free Software Foundation herausgegeben wird.

10 2.4 Resümee Request Tracker Ebenso wie das OTRS, ist auch der Request Tracker (RT) in der Programmiersprache Perl implementiert. Hierbei handelt es sich ebenfalls um ein freies Trouble- Ticket-System zum Verwalten von Serviceanfragen via . Das System wurde 1996 von Jesse Vincent entworfen und entwickelt. Auch hier steht die Erweiterbarkeit des Systems im Vordergrund. Die Benutzer haben die Möglichkeit, das System sehr stark an ihre Bedürfnisse anzupassen. RT wird unter anderem von der NASA, Merrill Lynch 2 und dem Massachusetts Institute of Technology eingesetzt. Nähere Informationen zu diesem Trouble-Ticket- System sind auf den Webseiten von Best Practical [Bes08] abrufbar. 2.3 Vantive Vantive war ein amerikanisches Softwarehaus, welches in den 90er Jahren von Roger Sippl gegründet wurde und überwiegend im Bereich des Kundenbeziehungsmanagements (CRM) tätig war. Neben einer Vielzahl an Werkzeugen im CRM- Bereich, entwickelte Vantive auch Software im Bereich Kundensupport. Das erste Trouble-Ticket-System mit Namen Vantive Support wurde 1992 vermarktet. Das System verwaltet hierbei die Bereiche Produktsupport, Kundensupport und Kundenkritik. Zwei Jahre später wurde Vantive HelpDesk angeboten. Dieses System stellte eine interne Helpdesk-Anwendung dar und konnte zur Verwaltung und Behandlung von zahlreichen Sachverhalten genutzt werden. Sämtliche Softwareprodukte von Vantive waren auf Datenbanksystemen aufgebaut. Daher existierten Verträge mit Sybase und Oracle stand Vantive an der Spitze des CRM-Marktes. Heute gehört Vantive zu Oracle. 2.4 Resümee Die hier aufgeführten Trouble-Ticket-Systeme, bestehen aus einem Datenbanksystem und einer zugehörigen Schnittstelle zum Verwalten der Serviceanfragen. Sie verfügen über verschiedene Methoden zum Melden der Anfragen (Telefon, , Weboberfläche). Das Verwalten der Serviceanfragen geschieht hierbei mittels Webinterface oder einer speziell implementierten, grafischen Benutzeroberfläche. Auch wenn die vorgestellten Systeme hohe Skalierbarkeit und Erweiterbarkeit leisten, so existieren zur Zeit keine Module, die ein ortsunabhängiges Arbeiten erlauben. Damit das Servicepersonal mit aktuellen Aufträgen arbeiten kann, ist es nicht nur an einen Rechner gebunden, sondern benötigt auch einen entsprechenden Zugriff ins Unternehmensnetz. 2 Merril Lynch und Co. (ML), mit Sitz in New York gehört zu den bedeutendsten globalen Investmentbanken und ist weltweit einer der führenden Finanzdienstleister

11 2.4 Resümee 5 Die vorliegende Arbeit ermöglicht das Abrufen und Verwalten der Serviceanfragen durch Mobiltelefone. Hierbei sind zwei Arbeitsweisen möglich. Einerseits werden mit Hilfe des GPS nur diejenigen Aufträge angefragt, welche sich in einer akzeptablen Reichweite zum anfragenden Personal befinden. Im Hinblick auf die Robustheit des Systems, ist es aber auch möglich, dass Serviceanfragen standortbezogen, und somit GPS-unabhängig, angefordert werden können. Zu jedem Auftrag besteht die Möglichkeit, Kartenmaterial abzurufen, welches die Position des Mobiltelefons und die des Anwenders zeigt. Diese Vorgehensweise verleiht dem Support eine hohe Flexibilität und spart nicht nur Zeit, sondern auch Kosten. Vorraussetzung ist allerdings, dass ein solches System in Unternehmen eingesetzt wird, die über mehrere Standorte verfügen und eine hohe Anzahl an Anwendern aufweisen.

12 3 Grundlagen 3.1 MySQL Das relationale Datenbanksystem MySQL ist die Grundlage zahlreicher Webanwendungen und hat sich insbesondere in Verbindung mit dem Webserver Apache durchgesetzt. MySQL ist eine Open-Source-Software, die unter der General Public License steht. Dieses Datenbanksystem wurde ursprünglich von der schwedischen Firma MYSQL AB entwickelt, gehört allerdings heute zu SUN Microsystems. Um größtmögliche Flexibilität zu gewährleisten, kann MySQL auf über 20 Plattformen eingesetzt werden. Es existieren zahlreiche Unix- und Linux-Varianten. Das Datenbanksystem läuft aber auch unter Windows und OS/2 Versionen. Seit Anfang 2008 gibt es ebenfalls eine Symbian-Variante. Beim Einsatz von MySQL können einer Datenbank-Engine mehrere Datenbanken zugeordnet werden. Diese Datenbanken können wiederum mehrere Tabellen umfassen, die unterschiedliche Datentypen enthalten können. Die maximale Größe dieser Tabellen wird durch das Betriebssystem limitiert. Im Rahmen dieser Arbeit wird die MySQL-Datenbank für die Verwaltung der Anwender-, Standort- und Geodaten verwendet. Die Webseite von MySQL ist unter [MyS08] abrufbar. 3.2 Apache Tomcat Apache Tomcat ist eine Umgebung, die das Ausführen von Java-Code innerhalb eines Webservers erlaubt. Es handelt sich um einen Servlet-Container, der in der Programmiersprache Java implementiert ist. Servlets sind Java-Klassen, deren instanziierten Objekte, im Rahmen eines Webcontainers oder J2EE Applicationservers, Anfragen von Clients entgegennehmen und bearbeiten. Mithilfe des JSP- Compilers Jasper können auch JavaServerPages (JSP) in Servlets übersetzt und ausgeführt werden. Ergänzend stellt Tomcat einen vollständigen HTTP-Server bereit. Die Vorläufer von Tomcat wurden meist als Servlet- oder JSP-Engine klassifiziert. Tomcat vereint idealerweise beide Technologien in einer Umgebung. In der Praxis wird dem Servlet-Container meist ein Apache-Webserver vorgeschaltet, der

13 3.2 Apache Tomcat 7 die HTTP-Funktionalität übernimmt. Der HTTP-Server des Tomcat wird seltener verwendet. Er findet meist Anwendung in Entwicklungs- und Testumgebungen. Im Folgenden ist die typische Verzeichnisstruktur der Tomcat-Installation aufgelistet, wobei die wichtigsten Verzeichnisse erläutert werden. bin common conf logs server shared webapps work Das Verzeichnis bin beinhaltet die Skripte zum Starten und Beenden, sowie ausführbare Dateien. In common sind Bibliothek- und Klassendateien abgelegt, die sowohl von Tomcat selbst, als auch von Webanwendungen genutzt werden. Das Verzeichnis conf enthält sämtliche Konfigurationsdateien für Tomcat, sowie für einzelne Komponenten der Webanwendung. Hier befinden sich ebenfalls die Konfigurationsdateien server.xml und web.xml. In server werden die Bibliotheken abgelegt, die lediglich von Tomcat genutzt werden. Das Verzeichnis webapps verwaltet die Webanwendungen. Hier befindet sich die anwendungsspezifische Datei web.xml. In ihr werden die Standardeinstellungen für jede Webanwendung ergänzt oder überschrieben. Diese Datei wird auch als Deployment Descriptor bezeichnet und sollte nicht mit der allgemeinen web.xml im Verzeichnis conf verwechselt werden. Folgendes Code-Listing zeigt einen möglichen Inhalt dieser Datei. In diesem Beispiel wird das Servlet Test-Servlet definiert. Der Tag <servlet-name> definiert hierbei den Namen des Servlets. Im <servlet-class> - Tag wird die zugehörige Java-Klasse im entsprechenden Package angegeben. Im <servelt-mapping> - Tag wird festgelegt, durch welche URL das Servlet über den Browser angesprochen werden kann. 1 <?xml v e r s i o n = 1.0 encoding= ISO ?> 2 3 <!DOCTYPE web app 4 PUBLIC //Sun Microsystems, Inc. / /DTD Web A p p l i c a t i o n 2. 3 / /EN 5 http : / / java. sun. com/ j 2 e e / dtds /web app 2 3. dtd> 6 7 <web app> 8 9 <s e r v l e t > 10 <s e r v l e t name>test S e r v l e t </ s e r v l e t name> 11 <s e r v l e t c l a s s >Test Package. T e s t S e r v l e t </ s e r v l e t c l a s s > 12 </ s e r v l e t > <s e r v l e t mapping> 15 <s e r v l e t name>test S e r v l e t </ s e r v l e t name> 16 <url pattern >/t e s t </url pattern > 17 </ s e r v l e t mapping> </web app>

14 3.3 Java Micro Edition Java Micro Edition Konfigurationen und Profile Die Software auf den Mobiltelefonen ist in der Programmiersprache Java Micro Edition (JavaME) implementiert. Im Gegensatz zu den anderen Java Editionen bringt JavaME einen wesentlich kleineren Umfang an Bibliotheken und Methoden mit. Sie ist somit speziell an embedded Devices 1 angepasst. Diese Geräte verfügen zumeist nur über geringe, bis mittlere Speicherkapazität und Rechenleistung. Da JavaME eine Untermenge der Standard Edition darstellt, garantiert die Java Micro Edition eine gewisse Abwärtskompatibilität. Sie wird im Gegensatz zu den anderen Editionen in so gennante Konfigurationen und Profile unterteilt. Eine Konfiguration besteht aus der Virtual Machine und einer Basis-API (Profil). Sie ist genau auf ihre jeweilige Geräteklasse zugeschnitten. Somit wird sichergestellt, dass Java Programme, die für eine bestimmte Konfiguration geschrieben wurden, auch auf allen Geräten lauffähig sind, die diese Konfiguration unterstützen. Es existieren zwei gängige Arten von Konfigurationen. In dieser Arbeit wurde die Konfiguration Connected Limited Device Configuration (CLDC) in der Version 1.1 verwendet. Basis dieser Konfiguration ist die Kilobyte Virtual Machine (KVM). Sie ist im Vergleich zu den VMs anderer Editionen wesentlich kleiner und kompakter. Die CLDC stellt Systemfunktionen bereit und ermöglicht das dynamische Laden von Programmen. Zusätzlich werden die Bereiche Netzwerkverbindungen und Sicherheit einbezogen. Die zweite Konfiguration ist die Connected Device Configuration (CDC). Diese bildet im Gegensatz zur CLDC die gesamte Menge an Java Bibliotheken der Standard Edition ab. Hieraus resultiert auch die Verwendung der VM der Standard Edition. Die CDC ist nur für den Einsatz auf Geräten mit hoher Rechenleistung gedacht und kam daher für diese Arbeit nicht in Betracht. Wesentlicher Bestandteil der CLDC ist das Generic Connection Framework (GCF). Dieses Framework soll die Kommunikation von Netzwerkverbindungen unter verschiedenen Protokollen ermöglichen. In dieser Arbeit werden Netzverbindungen mittels UMTS, GPRS und WLAN realisiert. Das Verwendete Protokoll ist das HTTP. Die CLDC definiert die Interfaces des GCF und die Connection Factory, die durch die Klasse Connector repräsentiert wird. Eine Verbindung wird durch den Aufruf der statischen Methode Connector.open hergestellt. Diese Methode erhält als Parameter einen Uniform Resource Identifier (URI) im Datentyp String. Der Aufbau von Netzwerkverbindungen unter JavaME wird in Kapitel behandelt. Neben den Konfigurationen sind die Profile der zweite Bestandteil der Micro Edition. Profile sollen dem Programmierer die Softwareentwicklung auf dem mobilen Endgerät erleichtern. Hierzu erweitern Profile den Funktionsumfang der verwendeten Konfiguration. Das wohl bekannteste Profil in diesem Zusammenhang ist wohl das Mobile Information Device Profile (MIDP). Es setzt direkt auf der CDLC auf und wurde speziell für den Einsatz auf Mobiltelefonen entworfen. Das MIDP 1 Der Begriff Embedded Devices (eingebettete Geräte) umfasst in diesem Zusammenhang Handys, Smart-Phones und PDAs

15 3.3 Java Micro Edition 9 ermöglicht das Programmieren von Anwendungen, die von der Laufzeitumgebung gesteuert werden können. So kann eine Anwendung beispielsweise die Zustände AKTIV, PAUSE und ZERSTÖRT erreichen. Diese Funktionalität ist immer dann von großer Bedeutung, wenn das Display bzw. der Prozessor für andere, eintreffende Aufgaben benötigt wird. So wird eine Anwendung beispielsweise bei einem eintreffenden Anruf in den Zustand PAUSE versetzt. Der Steuerung dieser Zustände liegt die so genannte Application Management Software (AMS) zugrunde. Die AMS ruft hierbei Methoden der abstrakten Klasse MIDlet auf. Dies ermöglicht dann das Reagieren auf Zustandsänderungen. Abbildung 3.1 zeigt den Lebenszyklus eines MIDlets, so wie er in [UB06] beschrieben ist. Wie in Abbildung 3.1 Abbildung 3.1. Lebenszyklus eines MIDlets dargestellt, erzeugt die AMS ein neues Objekt des MIDlets, wobei der Standardkonstruktor aufgerufen wird. Im Standardkonstruktor sollten keine aufwändigen Operationen ausgeführt werden, da die eigentliche Anwendung zu diesem Zeitpunkt noch nicht gestartet ist. Nachdem der Konstruktor aufgerufen wurde, führt die AMS die Methode startapp aus, was das eigentliche Starten der Anwendung zur Folge hat. Soll die Anwendung in den Hintergrund treten, so wird die Methode pauseapp aufgerufen. Dies kann einmal durch die Anwendung selbst, oder durch die AMS geschehen. Wird beispielsweise eine Ressource von einem anderen Ereignis benötigt, so wechselt das Midlet in den Zustand PAUSE und gibt die Ressourcen frei. Über die Methode destroyapp kann die AMS dem MIDlet mitteilen, dass es beendet werden soll. Die-

16 3.3 Java Micro Edition 10 se Aufforderung zum Beenden der Anwendung soll das Freigeben von Ressourcen, das Speichern von Daten, sowie das Trennen von Verbindungen einleiten. Andererseits hat das MIDlet die Möglichkeit der AMS seine eigenen Zustandsänderungen mitzuteilen. Über die Methode notifypaused wird der AMS mitgeteilt, dass die Anwendung unterbrochen wird. Die Methode resumerequest wird bei der AMS nachgefragt, ob ein Wechsel in den Zustand AKTIV möglich ist. Ist dies der Fall, so führt die AMS die Methode startapp erneut aus. Der Aufruf der Methode notifydestroyed beendet die Anwendung Internet-Anbindung Eine Internetverbindung wird über das Generic Connection Framework (GCF) realisiert. Dieses Framework besteht aus zahlreichen Schnittstellen, die durch das MIDP Profil ergänzt und implementiert werden. Das GCF befindet sich im Package javax.microedition.io Verbindungsobjekte werden nicht durch öffentliche Konstruktoren erzeugt, sondern werden durch den Aufruf der statischen Methode Connector.open bezogen. Mittels Typanpassung wird das erhaltene Connector-Objekt in den Typ HttpConnection umgewandelt. Folgender Code-Auszug zeigt die Erzeugung eines HTTP- Verbindungsobjektes: 1 HttpConnection c o n n e c t i o n = ( HttpConnection ) 2 Connector. open ( http : / / mynet1. d n s a l i a s. net : 8 080/GW/ mobilegate ) ; Zum sequentiellen Lesen und Schreiben von Daten werden die Stream-Klassen des MIDP-Packages java.io verwendet. Zur Kommunikation über das HTTP-Protokoll dienen die beiden Methoden GET und POST. Die GET-Methode enthält die vollständige Anfrage im URI. Hierbei löst die Herstellung der Verbindung das Senden der Daten aus. Die Anfrage besteht meist aus dem Adressteil und den optionalen Parametern. Die Parameterliste wird durch ein? eingeleitet. Ein Parameter besteht immer aus dem Parameternamen, gefolgt von einem = - Zeichen und dem Wert des Parameters. Weitere Parameter werden durch ein & - Zeichen separiert. Die Codierung der Parameter muss im MIME-Typ application/x-www-form-urlencoded vorliegen. Die zweite Möglichkeit der Kommunikation über das HTTP ist die Verwendung der POST-Methode. Im Unterschied zur GET-Methode ist die Anforderung hierbei nicht im URI enthalten, sondern im Inhaltsteil der Anfrage selbst. Der Inhaltsteil besteht hierbei aus Attribut-Wert-Paaren, wobei diese ebenfalls durch ein & - Zeichen getrennt werden. Prizipiell besteht jede POST-Kommunikation aus den folgenden Schritten: 1. Öffnen der HTTP-Verbindung über die statische Methode Connector.open 2. Verwendung der POST-Methode durch Aufruf der Methode setrequestmethod 3. Eigenschaften, wie beispielsweise Länge und Codierung definieren mit setrequestproperty 4. OutputStream über die Methode openoutputstream erfragen 5. Schreiben des Inhaltsteils in den OutputStream

17 3.3 Java Micro Edition Abfragen des Serverstatus über getresponsecode 7. Erfragen des InputStream durch Aufruf der Methode openinputstream 8. Lesen der Serverantwort vom InputStream durch die Methode read Jeder Verbindungsaufbau sollte in einem eigenen Thread realisiert werden, der die oben beschriebenen Schritte durchläuft. Folgendes Sequenzdiagramm 3.2 zeigt die POST-Kommunikation eines Threads. Abbildung 3.2. Sequenzdiagramm der POST-Kommunikation

18 3.4 Google-Maps Recordstore Management System Das Profil MIDP stellt das Recordstore Management System (RMS) bereit, welches sich im Package javax.microedition.rms befindet. Dieses System kann mit einer kleinen Datenbank verglichen werden. Das RMS erlaubt das persistente Speichern von Daten auf dem Mobiltelefon. Hierbei bedeutet persistent, dass die gespeicherten Daten nach einem Neustart der Software bzw. des Mobiltelefons gespeichert bleiben. Die Daten werden im Datentyp RecordStore abgelegt. Ein MIDlet kann beliebig viele Instanzen dieses Datentyps verwalten. Ein RecordStore besteht hierbei aus einer Sammlung von Byte-Arrays, die mit einer zugehörigen ID beginnen. IDs entsprechen dem Primärschlüssel einer Datenbank. Der Lebenszyklus des RMS ist durch vier Zustände geprägt. Ein RecordStore wird im Zustand NOT EXISTS mit openrecordstore erzeugt. Besteht das RMS bereits, erfolgt der Übergang in den Zustand OPEN. Hier werden mit den Methoden addrecord, setrecord und deleterecord Daten verwaltet. Ein Zeitstempel markiert den Zeitpunkt der letzten Änderung. Mit getrecord werden Datensätze unter Angabe ihrer ID ausgelesen. Die Methode closerecordstore schließt das RMS und führt es in den Zustand CLOSED. Ein Zugriffsversuch führt in diesem Zustand zu einer RecordStoreNotOpenException. Die Methode deleterecordstore löscht die Daten des RMS, was zum Zustand NOT EXISTS führt. 3.4 Google-Maps Google-Maps-API Die Google-Maps-API ermöglicht das Darstellen von Karten auf Webseiten. Hierbei wird das Kartenmaterial mit Hilfe der Skript-Sprache Java-Skript eingebettet. Die API stellt zahlreich Werkzeuge zum Editieren des Kartenmaterials bereit. Weiterhin besteht die Möglichkeit, den erstellten Karten bestimmte Inhalte hinzuzufügen. Folgender Code-Ausschnitt zeigt ein einfaches Beispiel. Die Karte zeigt das Gelände der Fachhochschule in Trier. 1 <!DOCTYPE html //W3C//DTD XHTML 1. 0 S t r i c t //EN 2 http : / /www. w3. org /TR/ xhtml1 /DTD/xhtml1 s t r i c t. dtd > 3 <html xmlns= http : / /www. w3. org /1999/ xhtml > 4 <head> 5 <meta http equiv= content type content= t e x t / html ; c h a r s e t=utf 8 /> 6 <t i t l e >Google Maps J a v a S c r i p t API Example</ t i t l e > 7 <s c r i p t s r c = http : / / maps. g o o g l e. com/maps? f i l e =api&amp ; v=2&amp ; key=abcdef 8 type= t e x t / j a v a s c r i p t ></ s c r i p t > 9 <s c r i p t type= t e x t / j a v a s c r i p t > f u n c t i o n i n i t i a l i z e ( ) 12 { 13 i f ( GBrowserIsCompatible ( ) ) 14 { 15 var map = new GMap2( document. getelementbyid ( map canvas ) ) ; 16 map. s e t C e n t e r ( new GLatLng ( , ), 1 3 ) ;

19 3.4 Google-Maps } 18 } </ s c r i p t > 21 </head> 22 <body onload= i n i t i a l i z e ( ) onunload= GUnload() > 23 <div i d= map canvas s t y l e = width : 500px ; h e i g h t : 300px ></div> 24 </body> 25 </html> In Zeile 7 wird die Google-Maps-API geladen. Hierbei zeigt die URL auf die Java- Skript Datei, welche alle erforderlichen Symbole und Definitionen zur Verwendung der API enthält. Die Webseite enthält somit einen <script> - Tag, der auf diese URL verweist. In dieser URL muss weiterhin der Google-Maps-API-Key enthalten sein. Dieser eindeutige Schlüssel ist genau an eine bestimmte Domain gebunden und kann direkt von den Webseiten von Google bezogen werden. In obigem Beispiel lautet der Key abcdef. In Zeile 23 wird der Ort auf der Seite festgelegt, an dem die Karte dargestellt wird. Normalerweise wird hierfür ein div-element erzeugt, welches eine Referenz auf die Karte besitzt. Die Karte selbst, wird in Zeile 15, mit Hilfe eines Objektes vom Typ GMap2 erzeugt. Der Aufruf der Methode setcenter initialisiert die Karte. Diese Methode erwartet als Parameter ein Objekt vom Typ LatLng und einen Zoom-Faktor. Ein Objekt der Klasse GLatLng repräsentiert hierbei den Längen- und Breitengrad, an dem die Karte zentriert wird (Zeile 16). Die vollständige Google-Maps-API ist unter [Goo08a] abrufbar. Folgende Abbildung 3.3 zeigt die Karte, die von dem obigem Code erzeugt wird. Abbildung 3.3. Google-Map der Fachhochschule Trier

20 3.4 Google-Maps Google-Static-Maps-API Im Gegensatz zur Google-Maps-API erlaubt die Static-Maps-API das Einbetten von Google-Karten auf Webseiten ohne die Verwendung von Java-Skript. Es ist also kein dynamisches Nachladen der Seite erforderlich. Das Kartenmaterial wird hierbei über einen HTTP-Request erfragt. Als Antwort wird eine Karte im Bildformat gif, jpg oder png zurückgeliefert. Innerhalb einer Webseite kann das angeforderte Kartenmaterial als <src> - Attribut im <img> - Tag eingebettet werden. Die Funktionalitäten dieser API werden ständig von Google erweitert und sind unter [Goo08b] abrufbar. Die URL eines Static-Map-Request hat die folgende Form: Hierbei stellt parameters die Liste der Parameter dar. Einige dieser Parameter sind optional, andere, wie beispielsweise der Google-Maps-Key, sind zwingend notwendig. Die wichtigsten Parameter, die auch im Rahmen dieser Arbeit verwendet werden, sind folgende: center - zentriert die Karte an der angegebenen Position markers - setzt Marker an der angegebenen Stelle size - bestimmt die Kartengröße in Pixel maptype - gibt den Kartentyp an (Mobile oder Roadmap) format - Dateityp der Karte (jpg, gif, png32) path - zeichnet eine Linie zwischen zwei Punkten zoom - legt den Zoomfaktor der Karte fest key - der Google-Maps API-Key Diese Parameter werden jeweils durch ein & -Zeichen separiert und an den Request- String angehängt. Parameter, wie etwa center oder zoom, tauchen im URL-Request jeweils nur einmal auf. Problematisch sind jedoch Parameter wie markers oder path. Theoretisch können hier beliebig viele Marker oder Pfade gesetzt werden. Daher kann hier die Zeichenlänge der URL stark variieren. Die Problematik liegt nun in der Gesamtlänge des URL-Requests. Prinzipiell sind GET- und POST-Argumente in ihrer Länge nicht begrenzt. Jedoch begrenzt der häufig eingesetzte WWW-Cache Squid 2 in der src/url.h die maximale Länge von URLs. Somit wird auch die GET-Methode in Abhängigkeit des verwendeten Webservers eingeschränkt. Die Begrenzung des URL-Request-Strings liegt zwischen 255 Byte und maximal 4 KByte. Bezüglich des Zugriffs auf den Google- Maps-Server existiert eine Begrenzung von etwa 2 KByte. 2 Squid ist ein freier Proxyserver, der unter der General Public Licence (GNU) steht. Er zeichnet sich durch seine hervorragende Skalierbarkeit aus und unterstützt die gängigen Protokolle HTTP, HTTPS, FTP und Gopher.