und Thin Clients.

10. ITG-Fachtagung "Mobilfunk" des VDE, Osnabrück Juni 2005
VDE-Verlag 2005, ISBN 3-8007-2902-4
Entwicklung von Mobilkommunikationsanwendungen
im Spannungsfeld zwischen Rich und Thin Clients
Diederich Wermser, Fachhochschule Braunschweig/Wolfenbüttel
Frank Hauptmann, Netzlink Informationstechnik GmbH, Braunschweig
Vigo Sandhaus, Fachhochschule Braunschweig/Wolfenbüttel
Kontakt: [email protected]
Kurzfassung
Die Entwicklung von Anwendungslösungen auf Basis der mobilen Datenkommunikation kann sowohl vom klassisch kommunikationstechnischen Blickwinkel "Netzelemente und Protokolle" als auch unter der Perspektive
"Verteilte Softwaresysteme" gesehen werden.
Die Funktionen von Anwendungslösungen können entweder weitestgehend auf zentralen Servern realisiert werden. Auf den mobilen Endgeräten sind dann als einzige Funktionen die Darstellung der (grafischen) Nutzeroberfläche und die Möglichkeiten zur Aufnahme und Weiterleitung von Nutzeraktionen realisiert ("Thin Client").
Oder es erfolgt eine Verteilung der Funktionen zwischen zentral im Netz angeordneten Elementen und den mobilen Geräten, z.B. nach dem Prinzip "Maximise Coherence and Minimise Interaction", wie beim Entwurf verteilter Systeme üblich. In diesem Fall werden neben der Nutzeroberfläche weitere wesentliche Funktionen der Anwendungslösung durch auf den mobilen Geräten ablaufende Software realisiert ("Rich Client").
Der Beitrag diskutiert Vor- und Nachteile beider Lösungsvarianten, auch in Hinblick auf unterschiedliche Anwendungsbereiche. Die verschiedenen Aspekte werden durch Beispiele mobiler Anwendungslösungen illustriert,
die von den Autoren realisiert wurden.
1
Rich Client und Thin Client
nologie (z.B. Embedded, Java, Web vgl. [3]) klassifiziert.
Die Frage nach der Client-Architektur war in den
zurückliegenden Jahren eine der meistdiskutierten
Problemstellungen in der IT. Mit der Einführung
des Browsers als Front-End für Unternehmensanwendungen im leitungsgebundenen Internet entwickelte sich eine heftige Diskussion, ob der Browser
als Thin Client oder ein formularbasierter Rich
Client die richtige Wahl ist. Die Verfechter des
Rich Client führten hier meist die überlegene Usability und mögliche Offlinefähigkeiten ihrer Technologien ins Feld. Dagegen argumentierten die
Verfechter des Browsers als Client mit stark vereinfachter Verteilung der Anwendungen und daraus
deutlich sinkenden TCOs (Total Cost of Ownership). Das Web-Paradigma hat sich laut GartnerGroup heute durchgesetzt. In 2002 sollen mehr als
70% aller Anwendungsprojekte auf den Browser als
Nutzerschnittstelle gesetzt haben.
Die in diesem Artikel verwendete Abgrenzung
zwischen den einzelnen Client-Paradigmen klassifiziert nach dem Ort, an dem die Geschäftslogik
ausgeführt wird:
Der Rich (auch Fat) Client enthält fest einprogrammierte Anwendungslogik. Die Anwendung
läuft auf Server und Client verteilt. Die Darstellung
geschieht auf dem Client (z.B. SAP-GUI, 2-Tier
Datenbankanwendung). Softwareupdates können
nur durch manuelle Installation der Software auf
der Client-Hardware erfolgen. Bei Verwendung von
Rich Clients ist die Anwendung auch im Offlinebetrieb voll nutzbar. Lediglich der Online-Zugriff
auf Daten ist hier nicht möglich. Ein weiterer Vorteil ist, dass Rechenleistung vom Server auf den
Client verlagert werden kann. Der größte Nachteil
beim Einsatz von Rich Clients ist der mit der Anzahl der Nutzer steigende Wartungsaufwand. Die
Anwendungssoftware muss bei Updates und Neuinstallationen jeweils manuell auf den Clients installiert werden. Aus diesem Grund schneidet dieses
Zur Frage der Abgenzung zwischen Thin, Rich und
neuerdings auch Smart Clients gibt es verschiedene
Ansätze. Häufig wird nach der verwendeten Tech-
1/10
10. ITG-Fachtagung "Mobilfunk" des VDE, Osnabrück Juni 2005
VDE-Verlag 2005, ISBN 3-8007-2902-4
Client-Paradigma bei TCO-Berechnungen regelmäßig am schlechtesten ab.
diesen Endgeräten sind verschiedene Aspekte von
Bedeutung, die sich auch auf die Entscheidung für
Thin oder Rich Clients auswirken:
Ein Thin Client repräsentiert lediglich die Darstellungsschicht einer Anwendung. Er führt keinerlei
eigene Programmlogik aus (Webbrowser der 1.
Generation). Die Anwendungslogik läuft auf komplettt auf dem Server. Der Client übernimmt nur die
Darstellung. Aus vielen Gründen sind Thin Clients
heute weit verbreitet (vgl. [1]):
•
Die Mobilfunkbetreiber weisen den mobilen
Endgeräten IP-Adressen typisch nur temporär
zu (DHCP), teilweise werden auch nur nicht
routbare IP-Adressen vergeben. Dies bedingt
aufwändige Lösungen, um serverseitig initiierte Kommunikationsvorgänge möglich zu machen („Push-Funktion“). Abhilfe bieten hierfür
bisher nur mobile VPN – Dienste, die von einigen Betreibern angeboten werden bzw. in Vorbereitung sind.
•
Niedrige Bitraten und hohe Signallaufzeiten
stellen höhere Anforderungen an die Synchronisation von Protokollabläufen als bei Festnetzkommunikation.
•
Heutige kompakte mobile Endgeräte bieten
schlechte Voraussetzungen, um Nebenläufigkeit von Prozessen zu realisieren (siehe Ausführungen unten). Nebenläufigkeit ist insbesondere erforderlich, wenn gleichzeitig Nutzinteraktionen und timing-gerechte Reaktionen
auf Kommunikations-Protokolle auf Anwendungs-Ebene bedient werden müssen. Abbildung 2-1 illustriert das Problem der Nebenläufigkeit.
Ein Smart Client übernimmt die Darstellungsschicht einer Anwendung und kann vom Server aus
dynamisch mit Anwendungslogik versehen werden.
Die Anwendung läuft dabei auf Client und Server
(z.B. Webbrowser mit JavaScript/ ActiveX, .NET
Compact Framework, Java-Applets, Java Web
Start). Ein Smart Client ist also eine Mischung aus
einem Thin und einem Rich Client. Smart Clients
haben, genauso wie Rich Clients, gegenüber Thin
Clients den großen Vorteil der Offline-Fähigkeit
([2]). Das bedeutet, dass nicht immer eine Verbindung mit dem Server bestehen muss, um mit der
Anwendung arbeiten zu können. Weiterhin ermöglichen erst Smart Clients die Integration von Peripheriegeräten, wie z.B. Barcode Scannern oder
Druckern. Gegenüber Rich Clients entfällt das
Problem der Software-Verteilung. Die Clients werden beim Zugriff auf die Anwendung vom Server
aus automatisch mit der Software oder mit Updates
versorgt.
•
Bei Unternehmensanwendungen ist häufig eine
größere Anzahl mobiler Endgeräte im Einsatz.
In vielen Fällen kommen die Nutzer der Endgeräte nur unregelmäßig oder selten zum Firmengebäude. Eine Möglichkeit zur Fernprovisionierung und -wartung der Anwendungssoftware auf den mobilen Endgeräten über die
Funkschnittstellen ist daher unverzichtbar.
•
Mobile Endgeräte mit leistungsfähigen Prozessoren und Betriebssystemen (z.B. PDAs)
zeichnen sich heute meist durch kurze BatterieStandzeiten aus und sind damit für viele Anwendungsbereiche
wenig
geeignet.
•
Für sicherheitsrelevante Anwendungen, wie
z.B. im Bereich der Fernüberwachung technischer Anlagen, sind entsprechende Rich
Clients erforderlich, um eine Alarmierung auch
bei Ausfall des zugehörigen Servers sicher zu
stellen.
2
•
Die heute verfügbaren Werkzeuge zur Entwicklung von Anwendungslösungen für kompakte mobile Endgeräte als Zielumgebung sind
nach Erfahrung der Autoren heute noch sehr
unbefriedigend (siehe Abschnitt 4). Insbesondere die Kompatibilität zwischen Emulatoren
Thin Clients können sehr einfach in heterogenen
Umgebungen ausgeführt werden. Die Darstellung
wird vom Server mittels einer standardisierten
Markup Language an den Client übertragen (z.B.
WML, HTML, XHTML). Für den Server ist es
dabei belanglos, auf welcher Hardwareplattform der
Client läuft. Anwendungen können relativ einfach
eine weltweite Verteilung erreichen. Auf dem
zugreifenden Client ist lediglich die Installation
eines Browsers nötig.
Der größte Nachteil des Thin Clients ist dagegen
die mangelnde Offline-Fähigkeit und die vergleichsweise hohen Latenzzeiten bei der Dateneingabe.
Mit dem relativ neuen Konzept des Smart Clients
wird versucht, die Nachteile sowohl der Thin als
auch der Rich Clients zu überwinden.
Aspekte für die Entwicklung
mobiler Anwendungen
Für die Entwicklung von Anwendungslösungen
unter Nutzung von kompakten mobilen Endgeräten
und drahtlosen Kommunikationsverbindungen zu
2/10
10. ITG-Fachtagung "Mobilfunk" des VDE, Osnabrück Juni 2005
VDE-Verlag 2005, ISBN 3-8007-2902-4
in der Entwicklungsumgebung und der Ausführungsumgebung auf der jeweiligen Zielhardware
ist
meist
unzureichend.
•
Die Portierbarkeit von Client-Software zwischen verschiedenen Endgeräte-Typen ist eine
häufige Forderung von Anwendern, auch um
Investitionssicherheit zur erreichen. Thin
Client Lösungen, die mit Standard-Browsern
arbeiten, bieten diesbezüglich offensichtlich
Vorteile.
•
Die Nutzung von Standard-Browsern über
Schnittstellen zur drahtlosen Nahbereichskommunikation (Bluetooth und Infrarot (IrDA)) wird heute typisch noch nicht unterstützt.
Anwendungen auf Basis dieser Kommunikationsschnittstellen müssen also mit anderen
Client-Lösungen arbeiten. Dies gilt nicht für
WLAN, das für PDAs meist angeboten wird.
3
Abbildung 3-1: Prinzip der Nebenläufigkeit
JAVA ist von der Konzeption her plattformunabhängig. Durch sogenannten JSRs (Java Specification Request) werden Klassen und Methoden zur
Verfügung gestellt, die unterliegende Hardware auf
standardisierte Weise anzusteuern. Beispiele für
JSRs sind:
Möglichkeiten zur Entwicklung von Client Software unter
JAVA.
JSR 82: Java API für Bluetooth
JSR 118: MIDP 2.0
JSR 120: Wireless Messaging API (WMA)
JSR 135: Mobile Media API (MMAPI)
JSR 180: SIP API
Entscheidet man sich für eine Lösung mit Rich
Clients wird es nötig, Software zu entwickeln, die
auf kompakten mobilen Endgeräten (Mobiltelefonen) ablauffähig ist.
Beispielsweise ist es durch das MIDP (Mobile
Information Device Profile) möglich, Gerätespezifikationen, wie Displaygröße, IMEI etc., auszulesen
und mit in die Programmierung mit einzubeziehen.
Wie oben dargelegt, ist die Möglichkeit zur Realisierung von Nebenläufigkeit von wesentlicher Bedeutung. Da die bei mobilen Endgeräten üblichen
Betriebssysteme (insbesondere Symbian) kein Multitasking bieten, muß die Nebenläufigkeit in der
Anwendungsumgebung realisiert werden. Durch
Programmierung sogenannter „Listener“ kann der
Rich Client auf Nachrichten des Servers reagieren
(„Push Funktion“).
Die folgende Abbildung zeigt die Architektur der
Java Version für mobile Endgeräte (J2ME).
Die Programmiersprache JAVA bietet mit J2ME
(JAVA 2 Micro Edition) eine für die meisten mobilen Endgeräte verfügbare Programmierumgebung.
Sie verspricht damit die besten Voraussetzungen
auch für die Portierbarkeit von Anwendungen.
Abbildung 3-1: Architektur J2ME [9]
Ganz unten sind die Konfigurationen zu sehen.
Zum einen die CDC (Connected Device Configuration) für kompakte Endgeräte wie PDA und SetTopBoxen sowie die kleinere CLDC (Connected
3/10
10. ITG-Fachtagung "Mobilfunk" des VDE, Osnabrück Juni 2005
VDE-Verlag 2005, ISBN 3-8007-2902-4
Limited Device Configuration) für Mobiltelefone
und Smartphones.
Im Interesse eines minimalen Übertragungsvolumens werden lediglich die Zielkoordinaten und das
Trefferergebnis codiert über die Funkverbindung
übertragen. Die komplette Spielelogik befindet sich
auf den Clients, während der Server nur als PushServer für die ausgetauschten Nachrichten fungiert.
Darauf aufbauend erkennt man die Profile, darunter
auch das schon angesprochene MIDP (Mobile Independent Device Profile).
Die genannten JSRs wie Wireless Message API
oder MultiMediaAPI, sowie Bluetooth und SIP
(Session Initiation Protocol) sind darüber angeordnet.
4
Die folgende Abbildung zeigt zwei Screenshots der
realisierten Anwendung.
Beispiele für die Entwicklung
von mobilen Anwendungen
Im Folgenden werden einige Beispiele für mobile
Anwendungen beschrieben, die von den Autoren
konzipiert und realisiert wurden. Es werden sowohl
Thin Client als auch Rich Client Lösungen vorgestellt.
4.1
Anwendungsbeispiel 1: Schiffeversenken auf Blackberry Endgeräten
Abbildung 4-1: Mobiles Spiel „Schiffeversenken“
Das erste Anwendungsbeispiel gehört zur Kategorie
mobiler Spiele. Das Spiel funktioniert wie der bekannte Klassiker, den man zu zweit auf Papier
spielt.
Die Clients auf den mobilen Endgeräten wurden in
JAVA unter J2ME und Nutzung von MIDP 1.0, wie
auf den Blackberry Endgeräten der dargestellten
Generation verfügbar, realisiert.
Es handelt sich um ein „rundenbasiertes“ Spiel, d.h.
es ist immer nur ein Spieler am Zug, während der
andere wartet. Dies begünstigt eine Lösung mittels
Rich Clients.
4.2
Auf dem Endgerät befindet sich ein endlicher Zustandsautomat, der folgende Zustände annehmen
kann:
1.
2.
3.
4.
Anwendungsbeispiel 2: Fernsteuerung von Infotainmentfunktionen
im Fahrzeug über Bluetooth
Für die Volkswagen AG, Wolfsburg, wurde ein
Funktionsmuster für die Fernsteuerung von Infotainment-Funktionen in PKWs mittels Bluetoothfähiger Mobiltelefone entwickelt.
Bereit zum Schuss, Schussauswahl
Schuss mit Ergebnisempfang
Warten auf Angriff vom Gegner
Trefferanalyse und senden des Ergebnisses
Eine Rich Client Lösung bietet in diesem Umfeld
den Vorteil, dass keine hohen Ansprüche an die
Leistungsfähigkeit des betreffenden Prozessors im
Infotainment-System des Fahrzeugs gestellt werden
müssen (Embedded Prozessor).
Der Anfangszustand wird durch die Ermittlung des
Beginners realisiert, indem jeder Client eine Zufallszahl erzeugt, mit der Zahl des Gegners vergleicht und die höhere Zahl gewinnt.
Somit wurden Funktionen der Steuerungslogik und
die Generierung der Darstellung für die Nutzeroberfläche auf das mobile Endgerät verlagert. Dazu
wurde eine J2ME Anwendung geschrieben, die
über die Bluetooth API (JSR 82) per Bluetooth mit
dem entsprechenden On-Board Server des Fahrzeugs kommunizieren kann.
In Zustand 1 hat der Benutzer die Möglichkeit,
grafisch eine Zielkoordinate auf dem Spielfeld des
Gegners auszuwählen. Diese wird (Zustand 2) )
übertragen und das Ergebnis (Treffer oder kein
Treffer) wird ausgewertet. Zustand 3 nimmt Koordinaten entgegen, wertet diesen Schuss auf dem
Heimatfeld aus und überträgt das Ergebnis, während er das Ergebnis parallel auch auf dem Display
darstellt (Zustand 4).
Aufbauend auf dieser Verbindung schickt das mobile Endgerät Steuersignale in Form von Strings an
4/10
10. ITG-Fachtagung "Mobilfunk" des VDE, Osnabrück Juni 2005
VDE-Verlag 2005, ISBN 3-8007-2902-4
den Embedded Server. Dieser steuert dann Funktionen des Systems im Fahrzeug. Zum Test des mobilen Clients wurde ein Winamp-Player auf einem
PC gesteuert.
Die Anwendung ist auch in der Lage, Informationen des Servers, wie z.B. die Songliste einer abgespielten CD zu empfangen und auf dem Mobiltelefon für den Nutzer darzustellen.
Zielgerät war zunächst ein Nokia 6600. Im Rahmen
Untersuchungen konnte diese Anwendung ohne
Probleme auf andere Mobiltelefone, z.B. auf ein
Sony Ericsson P900 portiert werden. Lediglich eine
Anpassung an die unterschiedlichen DisplayGrößen ist notwendig.
Abbildung 4-3: Aufsetzen einer mobilen MultimediaKonferenz
Abbildung 4-4 zeigt das Medium Whiteboard auf
einem Smartphone, links mit freiem Zeichenbrett
und rechts mit einem Stadtplan, in dem Markierungen vorgenommen werden können.
Abbildung 4-2: Fernsteuerung von Infotainment-Funktionen
in Fahrzeugen mittels Mobiltelefon
4.3
Anwendungsbeispiel 3:
Mobile Mehrparteien Multimedia
Dienste
Das zukünftige „All-IP UMTS“ (UMTS Release 5
und folgende) basiert auf dem IMS (IP-based Multimedia Subsystem) als Kernnetz [10]. Als anwendungsorientiertes Steuerungsprotokoll wird das
Session Initiation Protocol (SIP) eingesetzt.
Abbildung
4-4:
Nutzung
des
Mediums
„Multiparty-
Whiteboard“ auf mobilen Endgeräten
Im Rahmen des Forschungsprojekts IMMS (IPbased Mobile Multimedia Services; [5], [4]) wurde
von den Autoren eine Anwendung für die mobile
Mehrparteien-Multimediakommunikation auf Basis
des IMS konzipiert und prototypisch realisiert.
Die implementierten Rich Clients realisieren sowohl die endlichen Zustandsautomaten für das SIPProtokoll („SIP-Stacks“) als auch die Clientseitigen Funktionen der Konferenzsteuerung und
die Clienten der unterstützten Medien (Whiteboard,
Chat; Streaming Medien (Sprache, Video) bisher
nicht implementiert) unter J2ME.
Abbildung 4-3 zeigt die Nutzeroberfläche zur Konferenzerstellung mit Konferenzname, Medien- und
Teilnehmerauswahl.
Die Realisierung von Nebenläufigkeit unter J2ME,
wo im Gegensatz zu J2SE kein Multi-Threading
unterstützt wird, stellte eine besondere Herausforderung dar.
Die Anforderungen dieser Anwendung machen die
Grenzen der Leistungsfähigkeit heutiger Endgeräte
deutlich.
5/10
10. ITG-Fachtagung "Mobilfunk" des VDE, Osnabrück Juni 2005
VDE-Verlag 2005, ISBN 3-8007-2902-4
4.4
Anwendungsbeispiel 4: Produktfamilie MOSIS
Ein kommerzieller Erfolg von Anwendungen auf
Basis der mobilen Datenkommunikation in großem
Umfang ist nur möglich, wenn entsprechende Anwendungslösungen vorgefertigt und leicht anpassbar für den jeweiligen spezifischen Bedarf verfügbar gemacht werden. Nur so lassen sich die Anforderungen der Anwender an niedrige Kosten, Zuverlässigkeit und Wartbarkeit der Software sowie kurze Projektrealisierungszeiträume erfüllen.
Vor diesem Hintergrund hat die Firma Netzlink in
Kooperation mit der Fachhochschule Braunschweig/Wolfenbüttel die Produktfamilie MOSIS
(Mobile Secure Interaction System) konzipiert und
implementiert [6], [7].
Abbildung 4-5: Durch MOSIS HIT-CaSe überwachte Systeme
MOSIS basiert auf einem serverseitigen Kernsystem, das wesentliche Funktionen für Anwendungsbereiche wie z.B. mobile CRM-Lösungen, mobile
Arbeitszeiterfassung oder die mobile Fernüberwachung und –steuerung technischer Anlagen bereitstellt (Abb. 4-8 und 4-9). Das Kernsystem ist auf
Basis eines J2EE Servers realisiert (Abb. 4-10). Die
Abbildungen 4-5 bis 4-7 zeigen exemplarisch die
Nutzeroberfläche der Lösung MOSIS HIT-CaSe
(Hospital Information Technology Calling Service),
die seit September 2004 am Städtischen Klinikum
Braunschweig zur kostengünstigen Sicherstellung
der 24h-Verfügbarkeit der IT-Anwendungen und –
Infrastruktur dieses Klinikums im Einsatz ist (Bereitschaftsdienst mit mobilen Endgeräten).
Abbildung 4-6: Schneller Zugriff auf den Status von Servern
Ausgehend von den im Abschnitt 2 genannten Gesichtspunkten und den oben genannten Randbedingungen kommerzieller Projekte nutzt MOSIS als
Basis-Lösung eine Thin Client Architektur. Zur
Lösung spezifischer Aufgaben, etwa der Überwachung der Funktionsfähigkeit des MOSIS Servers
selbst, werden problem-abhängig zusätzlich Rich
Clients eingesetzt.
Abbildung 4-7: Alarmmeldung wegen Ausfall eines Servers
6/10
10. ITG-Fachtagung "Mobilfunk" des VDE, Osnabrück Juni 2005
VDE-Verlag 2005, ISBN 3-8007-2902-4
Abbildung 4-8: Prinzip-Architektur des MOSIS-Systems
Abbildung 4-9: Funktionale Module des MOSIS-Systems
Abbildung 4-10: Software-Architektur des MOSIS-Systems
7/10
10. ITG-Fachtagung "Mobilfunk" des VDE, Osnabrück Juni 2005
VDE-Verlag 2005, ISBN 3-8007-2902-4
5
5.1
Erfahrungen mit Softwareentwicklung und -wartung für
mobile Rich Clients
Die mangelnde Kompatibilität zwischen den Endgeräten und den jeweiligen Emulatoren ist nach den
Erfahrungen der Autoren zur Zeit das wesentlichste
Hindernis für die erfolgreiche Entwicklung von
Rich Clients. Die Inkompatibilität betrifft typisch
insbesondere das I/O-Verhalten in Bezug auf
Kommunikationsschnittstellen (TCP/IP bzw. UDP)
und Nutzeroberflächen-APIs. Da Möglichkeiten
zum „On-Device-Debugging“ bisher nicht angeboten werden, kommt der Anwendungsentwickler in
die Situation, Debugging-Hilfsmittel, die auf dem
mobilen Zielgerät genutzt werden können, selbst
implementieren zu müssen.
Entwicklungsrandbedingungen
(Emulatoren, Endgeräte, Entwicklungsumgebungen)
Für die Implementation von Anwendungen für
mobile Endgeräte unter J2ME gibt es verschiedene
Entwicklungsumgebungen. Beispielhaft seien Eclipse, IBM Websphere und Sun One Studio 5 genannt.
Die dynamische Zuweisung von IP-Adressen zu
mobilen Endgeräten erfordert erheblichen Aufwand, um eine gesicherte Kommunikation zwischen Rich Clients und den zugehörigen Servern zu
erreichen.
Die Nutzung von Emulatoren in der jeweiligen,
rechner-gestützten Entwicklungsumgebung ist
Voraussetzung für eine effiziente Projektdurchführung. Sie erlauben insbesondere das Testen und
„Debuggen“ der entwickelten Software für das
mobile Endgerät. Der ausführbare Code wird somit
zunächst mit einem Emulator getestet, bevor er auf
der Zielhardware (Mobiltelefon) installiert wird.
Abbildung 5-1: Detailarchitektur einer OTA-Lösung
5.2
Fernwartung / Softwareverteilung
Beim so genannten „Over The Air Provisioning“
(OTA) handelt es sich um eine Technik, die zur
Software-Verteilung und Wartung über das Mobilfunknetz genutzt wird, so dass eine manuelle Verbindung mit einem Rechner nicht mehr notwendig
ist. Dies verspricht einen enormen Zeitgewinn und
ermöglicht eine schnelle, effiziente sowie kostensparende Distribution von Software für mobile
Clients. Dabei wird zwischen dem Einsatz so genannter Provisioning Portale und push-basierten
Provisioning Systemen unterschieden.
Wie oben erwähnt ist für den Einsatz von Rich
Clients in größeren Projekten mit vielen Endgeräten
die Ferninstallation und -wartung der Clientsoftware über die Funkschnittstelle unverzichtbar. Dabei muss insbesondere auch die Kompatibilität
fern-installierter Anwendungssoftware mit den
jeweils installierten Firmware-Versionen der mobilen Endgeräte gesichert werden.
Bei der Verwendung von Rich Clients muss die
Wartung von Client und Server miteinander synchronisiert werden, um sicherzustellen, dass auf
beiden Seiten der gleiche Releasestand der Software installiert ist.
Während bei dem Einsatzes eines Portals der User
eigenständig entsprechende Webseiten aufrufen
muss, um die gewünschte Software eigenhändig
8/10
10. ITG-Fachtagung "Mobilfunk" des VDE, Osnabrück Juni 2005
VDE-Verlag 2005, ISBN 3-8007-2902-4
auszuwählen, bekommt er dank des Provisioning
Systems proaktiv den Link zur Software zugespielt,
entweder per Channel-Push bei BlackberryHandhelds oder mittels WAP-Push bei MIDPkonformen Smartphones. Somit können mobile
Anwendungen von zentraler Stelle fern-installiert,
aktualisiert und konfiguriert werden, so dass ein
zuständiger Administrator serverseitig die aktuellen
Software-Stände der heterogenen, mobilen Endgeräte überwachen und beeinflussen kann. Nach erfolgreichem Abschluss der proaktiv angestoßenen
Installations- bzw. Updateprozesse erhält das Provisioning System einen detaillierten Status Report,
der bei Bedarf auch entsprechende Abrechnungsprozesse initiieren kann. Dank dieser Technik stehen nun auch technisch nicht versierten Nutzern
mobiler Endgeräte stets die aktuellsten SoftwareVersionen zur Verfügung.
Die Softwareaktualisierung der Clients kann für den
Nutzer unmerklich erfolgen. Die im J2ME Framework enthaltene AMS (Application Management
Software) bietet Basisfunktionen für die Realisierung von Over the Air Provisioning.
Abbildung
5-1
illustriert
eine
OTASoftwareinstallations und –wartungslösung, die im
Team der Autoren aktuell erprobt wird.
6
Ausblick
Die im Beitrag geschilderten heutigen Probleme bei
der Entwicklung von Rich Clients dürften innerhalb
der nächsten Jahre seitens der Hersteller mobiler
Endgeräte behoben werden. Die mit der zunehmenden Flächendeckung von UMTS realistisch verfügbaren höheren Bitraten verbessern einerseits die
Voraussetzungen für Thin Client basierte Lösungen. Gegenläufig dazu verbessert die schnell steigende Leistungsfähigkeit der Prozessoren mobiler
Endgeräte die Voraussetzungen für Rich Client
Lösungen. Die Entscheidung in der einen oder
anderen Richtung wird also weiterhin problemspezifisch getroffen werden müssen.
Für den kommerziellen Erfolg von Anwendungen
auf Basis der mobilen Datenkommunikation ist die
Verfügbarkeit vorgefertigter Lösungen, die eine
kostengünstige und risikolose Realisierung ermöglichen, in jedem Fall von zentraler Bedeutung, wie
am Beispiel der MOSIS Produktfamilie erläutert
wurde.
9/10
10. ITG-Fachtagung "Mobilfunk" des VDE, Osnabrück Juni 2005
VDE-Verlag 2005, ISBN 3-8007-2902-4
7
Literatur
8
[1] Rosemann,
M.;
Bachmendo,
B.:
Konzeption eines WWW-basierten Prozeßinformationssytems in Interaktion im Web – Innovative Kommunikationsformen, Teubner
1998 (Berichte des German Chapter of the
ACM; Bd. 50)
[2] Yuan, Michael Juntao: Enterprise J2ME –
developing Mobile Java Applications; Prentice
Hall; Upper Saddle River; 2004
[3] Golding, Paul; next generation wireless applications; Wiley; 2004
[4] Jusek, A.; Hans, M.; Kowalewski, F.; Wermser, D.: SIP-basierte Dienstentwicklung für
das IMS CN (UMTS Release 5). In: Mobilfunk - Stand der Technik und Zukunftsperspektiven, 9. VDE/ITG Fachtagung, VDEVerlag, Berlin 2004.
[5] Wermser, D.; Büch, C.; Hans, M.; Jusek, A.;
Kowalewski, F.: Adaptive Mobile Multimedia-Dienste für das zukünftige All-IP UMTS.
ITG-Fachtagung "Ambient Intelligence" auf
dem VDE Kongress 2004. VDE-Verlag, Berlin
2004.
[6] Wermser, D.; Wähling, S.-O.: Monitoring &
Control Integrating Wireless Agents and Mobile Users. ZVEI-Elektronik - Wireless Congress 2004. München Nov. 2004.
[7] Seidel, C.; Gruetz, R.; Wähling, S.-O.; Wermser, D.: Kostengünstige Sicherstellung der
Verfügbarkeit von DV-Systemen am Städtischen Klinikum Braunschweig, Systemrufbereitschaft und deren technische Umsetzung.
10. Fachtagung Praxis der Informationsverarbeitung in Krankenhaus und Versorgungsnetzen (KIS), Hamburg März 2005.
[8] it-frameworkssolutions GmbH: Mobile Anwendungen für Handy/PDA – Newsletter,
www.it-fws.de, 04.02.2004
[9] Schmatz, Klaus-Dieter: Java 2 Micro Edition,
dpunkt.verlag, 2004
[10] Poikselka, M. et al.: IMS – IP Multimedia
Concepts and Services in the Mobile Domain.
Wiley, New York, 2004.
Abkürzungen
AMS
API
AS
CDC
CLDC
ERP
CRM
DHCP
GPRS
GUI
HTML
IMEI
IMS
IMMS
IP
IrDA
J2ME
J2SE
J2EE
JSR
MIDP
MOSIS
OTA
SAP
Application Management Software
Application Programming Interface
Application Server
Connected Device Configuration
Connected Limited Device Configuration
Enterprise Resource Planning
Customer Relationship Management
Dynamic Host Configuration Protocol
General Packet Radio Service
Graphics User Interface
Hyper Text Markup Language
International Mobile Equipment Identity
IP-based Multimedia Subsystem
IP-based Mobile Multimedia Services
Internet Protocol
The Infrared Data Association
Java 2 Micro Edition
Java 2 Standard Edition
Java 2 Enterprise Edition
Java Standardisation Request
Mobile Information Device Profile
Mobile Secure Interaction System
Over the Air Provisioning
Systeme, Anwendungen und Produkte in
der Datenverarbeitung (ERP-Software)
SIP
Session Initiation Protocol
TCO
Total Cost of Ownership
TCP
Transmission Control Protocol
UDP
User Datagram Protocol
UML Unified Modeling Language
UMTS Universal Mobile Telecommunication
System
WAP Wireless Application Protocol
WML Wireless Markup Language
XHTML eXtensible Hyper Text Markup Language
10/10