Mobile Erfassung von Dispositionsinformationen einer

Transcription

Diplomarbeit mit dem Thema:
Mobile Erfassung von
Dispositionsinformationen einer
Werkseisenbahn in Form einer
verteilten Anwendung
Philipp Bönisch
Matr.-Nr.: 2839385
Fakultät Informatik
TU Dresden
31.03.2007
Mobile Endgeräte, wie PDAs, werden immer wichtiger, wenn es um die Effizienzsteigerung von Abläufen in Unternehmen geht. Eine zunehmende Anzahl an
Mitarbeitern wird mit ihnen ausgerüstet, um Kommunikationskosten zu sparen
und sie bei ihrer Arbeit möglichst gut zu unterstützen.
Doch ist die Einbindung mobiler Geräte in bereits vorhandene Systeme mit
etlichen Problemen verbunden. Darum beschäftigt sich diese Arbeit mit der
Integration eines mobilen Clients in eine bestehende Client-Server-Architektur.
Der Schwerpunkt liegt dabei besonders auf der Offline-Fähigkeit der mobilen
Anwendung, um auch im verbindungslosen Zustand die Arbeitsfähigkeit der
Anwendung zu gewährleisten.
Dafür werden bereits vorhandene Standards und Technologien untersucht, um
sie auf ihre Eignung zu prüfen und um Lösungsstrategien für Probleme aufzuzeigen. Aufbauend darauf wird ein eigenes Konzept entwickelt und vorgestellt.
Im Anschluss erfolgt eine Realisierung des Konzepts für eine verteilte Dispositionssoftware für (Werks-)Eisenbahnen. Mittels verschiedener Testreihen wird
danach die entstandene Lösung untersucht und bewertet.
Darüber hinaus beschäftigt sich die Arbeit mit dynamischen Netzwerken, mit
dem Ziel, eine Architektur zu schaffen, die die Vorteile von einer Client-ServerArchitektur und einer Peer-to-Peer-Architektur vereint. Das erarbeitete Konzept
ermöglicht selbstständige Clients, die sich gegenseitig unterstützen können und
erlaubt den Einsatz von Servern für Routine-Aufgaben, um die einzelnen Clients
zu entlasten.
Inhaltsverzeichnis
Inhaltsverzeichnis
1 Aufgabenstellung
9
1.1 Interpretation und Anmerkungen zu der Aufgabenstellung . . . . 11
Teil I
13
2 Einleitung
14
2.1 Analyse der Ausgangssituation . . . . . . . . . . . . . . . . . . . 14
2.2 Integration des mobilen Clients . . . . . . . . . . . . . . . . . . . 15
3 Begriffe, Konzepte und Klassifizierung
3.1 Synchronisation . . . . . . . . . . . . . .
3.1.1 Synchrone Replikation . . . . . . .
3.1.2 Asynchrone Replikation . . . . . .
3.1.3 Unidirektionale Synchronisation . .
3.1.4 Bidirektionale Synchronisation . .
3.1.5 SlowSync und PushSync . . . . . .
3.1.6 Funktions- versus Datenreplikation
3.2 Differenzerkennung . . . . . . . . . . . . .
3.3 Die Sprache SyncML . . . . . . . . . . . .
3.3.1 Details zu SyncML . . . . . . . . .
3.3.2 Die Kommunikation . . . . . . . .
3.3.2.1 Identifikation der Daten .
3.3.2.2 Der Ablauf . . . . . . . .
3.3.2.2.1 Initialisierung . .
3.3.2.2.2 Datenaustausch
3.3.2.2.3 Mapping . . . .
3.3.3 Fazit . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
18
19
19
19
19
20
20
21
22
22
22
23
23
23
24
24
4 Verfügbare Standards und Lösungen
4.1 Service Oriented Architecture? . . . . . . . . . . .
4.1.1 Der Nutzen von SOA für mobile Endgeräte
4.1.2 Der Einsatz von Agenten . . . . . . . . . .
4.1.3 Entwicklung von Diensten und Agenten . .
4.1.4 Mögliche Problemstellen . . . . . . . . . . .
4.1.5 Fazit . . . . . . . . . . . . . . . . . . . . . .
4.2 OneBridge Mobile Platform . . . . . . . . . . . . .
4.2.1 OneBridge Mobile Groupware . . . . . . . .
4.2.2 OneBridge Mobile Data Suite . . . . . . . .
4.2.3 OneBridge Monitoring Service . . . . . . . .
4.2.4 Fazit . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
26
28
28
29
30
31
33
33
34
34
5 Skizzierung der Lösung
5.1 Bewertung der einzelnen Möglichkeiten . . . . . . . . . . . . . .
5.1.1 Komplette oder teilweise Portierung der Geschäftslogik?
5.1.2 Die Warteschlange . . . . . . . . . . . . . . . . . . . . .
5.1.3 Die lokale Datenhaltung . . . . . . . . . . . . . . . . . .
.
.
.
.
34
35
35
36
36
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
Inhaltsverzeichnis
5.2
5.1.4 Die lokale Geschäftslogik . . . . . . . . . . . . . . . . .
5.1.5 Die Synchronisation . . . . . . . . . . . . . . . . . . .
5.1.6 Aufbau der Synchronisations-Nachrichten . . . . . . .
5.1.7 Das Konfliktmanagement . . . . . . . . . . . . . . . .
Umfang der zu portierenden Geschäftslogik und Daten . . . .
5.2.1 Analyse der Webservice-Aufrufe und Datenstrukturen
5.2.2 Auswertung der Analyse . . . . . . . . . . . . . . . . .
6 Die Lösung
6.1 Die Entwicklungsumgebung . . . . . . . . .
6.2 Die Implementierung . . . . . . . . . . . . .
6.2.1 Die Organisation des Clients . . . .
6.2.2 Der Agent . . . . . . . . . . . . . . .
6.2.3 Die Warteschlange . . . . . . . . . .
6.2.4 Die lokale Datenhaltung . . . . . . .
6.2.5 Die lokale Geschäftslogik/BIS-Logik
6.2.6 Die Synchronisation . . . . . . . . .
6.2.7 Das Konfliktmanagement . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
38
39
41
43
43
48
.
.
.
.
.
.
.
.
.
49
49
49
50
52
55
57
57
57
64
7 Auswertung und Bewertung
65
7.1 Das Testszenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.2 Die Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.3 Die Auswertung und Bewertung . . . . . . . . . . . . . . . . . . . 66
8 Abschluss und Ausblick
69
Teil II
73
9 Die Weiterentwicklung des BIS-Systems
9.1 Peer-to-Peer: Die neue Architektur für das BIS? .
9.1.1 Historische Entwicklung von Peer-to-Peer
9.2 Die neue Architektur . . . . . . . . . . . . . . . .
9.2.1 Die Anforderungen . . . . . . . . . . . . .
9.2.2 Die Architektur . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
74
74
75
76
76
77
10 nBIS im Detail
10.1 Die Client-Architektur . . . . . . . . . . . . .
10.2 Der Aufbau der Clients . . . . . . . . . . . . .
10.2.1 Abläufe mit Verbindung zum Server .
10.2.2 Abläufe ohne Verbindung zum Server .
10.2.3 Abläufe ohne Verbindung zum Master
10.2.4 Die Aufgaben des Masters . . . . . . .
10.2.5 Die Aufgaben der Server . . . . . . . .
10.2.6 Das Leeren der Warteschlangen . . . .
10.2.7 Bewertung . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
78
79
80
87
89
90
91
92
92
92
11 Verallgemeinerung des Konzepts nBIS
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
96
Inhaltsverzeichnis
Anhang
Literaturverzeichnis . . . . . . . . . . . . .
Tabellenverzeichnis . . . . . . . . . . . . . .
Abbildungsverzeichnis . . . . . . . . . . . .
Liste der Algorithmen . . . . . . . . . . . .
Listingverzeichnis . . . . . . . . . . . . . . .
Eine kurze Einführung in die Arbeitsabläufe
Einblicke in die Anwendung moBIS . . . . .
Glossar . . . . . . . . . . . . . . . . . . . .
Eigenständigkeitserklärung . . . . . . . . .
97
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
des BIS
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
99
.
i
. v
. vi
. vi
. vi
. vi
. vii
. x
. xvii
7
Fakultät Informatik Institut für Systemarchitektur, Professur Rechnernetze
Aufgabenstellung für die Diplomarbeit
Name, Vorname:
Studiengang:
Matr.-Nr.:
Bönisch, Philipp
Informatik
2839385
Thema: „Mobile Erfassung von Dispositionsinformationen einer Werkseisenbahn in
Form einer verteilten Anwendung“
Zielstellung:
Die Dispositions- und Betriebsdaten von Werkseisenbahnen werden in einem
Betriebsinformationssystem (BIS) verwaltet. Diese Softwareanwendung ist in Drei-SchichtArchitektur aufgebaut. Als Präsentationsschicht dienen dabei sowohl ortsfeste
Leitstellensysteme (Rich Clients) als auch Mobilcomputer, mit denen Mitarbeiter prozessnah
Daten erfassen und bearbeiten sollen. Die Leitstellensysteme kommunizieren über eine
Webservice-Schnittstelle mit der Geschäftslogik und verfügen über keine eigene
Datenhaltung.
Die mobilen Clients kommunizieren über GSM mit dem Serversystem, wobei im rauen
Umfeld von Werkseisenbahnen von einer eingeschränkten örtlichen Verfügbarkeit des
Funknetzes ausgegangen werden muss. Daten zur Bearbeitung mit dem mobilen Client
sollen deshalb lokal auf dem Mobilgerät gehalten werden, kleine Teile der Geschäftslogik
sollen ebenfalls lokal ausgeführt werden können. Der Umfang der lokalen Geschäftslogik ist
jedoch vom konkreten Anwendungsfall abhängig.
Aufgabe der vorzulegenden Diplomarbeit ist es, in der Literatur beschriebene
Lösungsansätze für die Integration der mobilen Clients zu analysieren und aufbauend auf der
vorhandenen Infrastruktur und Architektur des BIS-Systems eine Lösung zur Integration
mobiler Clients vorzuschlagen, die ein auf den jeweiligen Anwendungsfall abgestimmtes
Kommunikationsverhalten ermöglicht. Einen besonderen Schwerpunkt sollen
hierbei
Anwendungsfälle bilden, in denen eine Bearbeitung der Dispositionsdaten völlig ohne
Kommunikation mit dem Serversystem erfolgt, d.h. die aktualisierten Daten erst nach dem
Abschluss der Bearbeitung an das Zentralsystem zurück übermittelt werden können.
Ausgehend von einem typischen Anwendungsfall sollen softwaretechnische
Lösungsansätze vorgeschlagen und auf ihre Anwendbarkeit hin untersucht werden.
Außerdem sollte die Diplomarbeit eine Strategie (Schema) vorschlagen, um dynamische
Kooperation zwischen mobilen Geräten zu ermöglichen, wenn die horizontale
Kommunikation und Datenaustausch wichtig ist. Die Kooperation kann optimale "`Daten
routing"', dynamische Geräteerkennung usw. einschließen.
Die für die vorgeschlagene Lösung zu erstellenden Softwaremodule sollen spezifiziert und
prototypisch implementiert werden.
Externer Betreuer:
Betreuer TUD:
Verantwortlicher Hochschullehrer:
Institut:
Beginn am:
Einzureichen am:
Dr.-Ing. Steffen Oettich, CSC Ploenzke AG
Dr.-Ing. Waltegenius Dargie
Prof. Dr. rer. Nat. habil. Dr. h. c. Alexander Schill
Institut für Systemarchitektur
01. Oktober 2006
31. März 2007
Unterschicht des verantwortlichen Hochschullehrers
Verteiler: 1 x Prüfungsamt, 1 x HSL, 1 x Betreuer, 1 x Student
1 Aufgabenstellung
1.1 Interpretation und Anmerkungen zu der Aufgabenstellung
Im Verlauf der Entstehungszeit dieser Diplomarbeit hat der CSC-Mitarbeiter
Dipl.-Ing. Wolfgang Ehmeier von Dr. S. Oettich die Betreuung der Diplomarbeit
übernommen.
Die Aufgabenstellung teilt sich in zwei Bereiche auf. In dem ersten Teil, der
Hauptaufgabe, geht es um die Verbesserung eines mobilen Clients einer bereits
vorhandenen Client-Server-Architektur. Im Gegensatz zu den stationären Clients muss die mobile Anwendung auch ohne Verbindung zu einem Server in der
Lage sein, die Arbeit des Anwenders zu unterstützen, was bisher nicht der Fall
ist. Um dies zu erreichen müssen geeignete Strategien gefunden, untersucht und
angepasst oder entwickelt werden.
Dem voraus geht eine genau Analyse des jetzigen Systems, um mögliche Problemstellen aufzuzeigen. Im Anschluss daran sind bereits existierende Lösungen
und Technologien zu untersuchen, um daraus deren Lösungsstrategien zu ermitteln und Anforderungen für eine eigene Realisierung abzuleiten.
Das daraufhin entwickelte Konzept muss die ermittelten Probleme lösen und die
gestellten Anforderungen erfüllen. Dabei sollen möglichst vorhandene Technologien einbezogen werden, um den Entwicklungsaufwand so gering wie möglich
zu halten.
Zur Demonstration der Praxistauglichkeit des Konzepts soll es so implementiert
werden, dass damit typische Anwendungsfälle ausführbar sind.
Der zweite Teil beschäftigt sich damit, wie die Kommunikation noch zuverlässiger und effizienter gestaltet werden kann. Insbesondere soll hier betrachtet
werden, ob es noch weitere Möglichkeiten, außer den im ersten Teil betrachteten, gibt, wie der mobile Client auch ohne eine direkte Verbindung arbeitsfähig
bleiben kann. Ein Stichwort in diesem Zusammenhang sind Peer-to-Peer-Netze.
Für das Verständnis einzelner Abläufe ist es hilfreich, Grundkenntnisse über
den Ablauf im Bahnbetrieb, insbesondere einer Werkseisenbahnen, zu besitzen.
Der Abschnitt „Eine kurze Einführung in die Arbeitsabläufe des BIS“ im Anhang gibt einen kurzen Überblick über die typischen Abläufe in einem (Werks-)
Eisenbahnunternehmen, die von dem BIS-System unterstützt werden.
11
Teil I
13
2 Einleitung
2 Einleitung
Der erste Teil dieser Arbeit beschäftigt sich mit der Weiterentwicklung eines
mobilen Client, der bereits Teil einer existierenden verteilten Anwendung ist.
Der Schwerpunkt liegt hierbei auf der Realisierung einer Offline-Fähigkeit, so
dass der mobile Client auch noch ohne Verbindung zum Server arbeitsfähig wird.
Warum der mobile Client momentan dazu nicht in der Lage ist zeigt eine kurze
Betrachtung der Ausgangssituation.
Anschließend werden einige Begriffe und Konzepte vorgestellt, um einen Überblick über das Themengebiet zu geben und grundlegende Konzepte vorzustellen.
Daraus leiten sich die Anforderungen an eine konkrete Realisierung ab, die daraufhin dementsprechend entworfen und realisiert wird. In der nachfolgenden
Bewertung wird die Implementierung beurteilt und mittels einiger Kennzahlen
auf ihre Effizienz hin untersucht. Abschließend erfolgt ein kurzer Ausblick über
zukünftige Weiterentwicklungen, bevor es in den zweiten Teil übergeht.
2.1 Analyse der Ausgangssituation
Seit vielen Jahren stellt die Firma CSC die Anwendung BIS (Betriebsinformationssystem) in der Zweigstelle in Dresden her. Hierbei handelt es sich um eine
verteilte Anwendung zur Disponierung und Verwaltung von Betriebsdaten einer
Werkseisenbahn und wird beispielsweise von den Stahlwerken Bremen eingesetzt. Mit ihr können Rangieraufträge verwaltet (Welche Lok soll welchen Wagen
von wo nach wo fahren? Wie ist der aktuelle Status?), Ein- und Ausgangszüge
erfasst (Wurde die vorgemeldete Reihenfolge eingehalten? Stimmen die technischen Kenndaten?), Vorgänge protokolliert, Rechnungen erstellt und das aktuelle Gleisbild dargestellt werden. Zudem beinhaltet es noch einige Schnittstellen
zu Fremdsystemen wie denen von SAP.
Das BIS-System ist als Client-Server-Architektur organisiert, die aus drei Schichten besteht. Vereinfacht kann sie mit dem MVC-Modell (Model View Controller)
(siehe Abbildung 1) beschrieben werden.1
Die Sicht (View) wird durch die einzelnen Anwendungen auf den Clients präsentiert. Diese bereitet die Daten für die Nutzer auf und stellt sie dar. Des
Weiteren nimmt sie die Aktionen des Anwenders entgegen und leitet diese über
ein an SOAP (ehemals Simple Object Access Protocol) angelehntes Protokoll
an die Steuerung (Controller) weiter. Diese besteht aus einem Webserver, der
entsprechende Webservices zur Verfügung stellt, die die gesamte Geschäftslogik,
inklusive der Schnittstellen zu Fremdsystemen, kapseln. Die Daten werden aus
der Datenbank (Model) entnommen.
1
Aus softwaretechnologischer Sicht mag die Einordnung nicht ganz korrekt sein. In diesem
Fall soll das Modell nur anschaulich die Architektur des Systems charakterisieren. Bei
genauerer Betrachtung müsste man eine viel feingranularere Betrachtung vornehmen. So
besteht der Client selbst wieder aus dem MVC-Modell. Dies ist im Rahmen dieser Arbeit
aber nicht weiter von Interesse und wird deshalb vernachlässigt.
14
2 Einleitung
Abbildung 1: Die drei Schichten des MVC-Modells
Zur einfacheren Gestaltung der verteilten Datenhaltung verfügen die Clients
über keine eigene Datenspeicherung und besitzen damit auch keine eigene Geschäftslogik, da eine Geschäftslogik ohne verfügbare Daten nutzlos ist. Immer
wenn ein Client neue Daten benötigt, startet dieser einen Webservice-Aufruf,
um sich diese zu beschaffen. Manipulationen der Daten erfolgen nur durch den
Webservice. Somit sind Konflikte ausgeschlossen, die durch die parallele Änderung von Daten auftreten können.
Eine Ausnahme bilden die sogenannten Stammdaten. Darunter fallen alle Daten,
die sich gar nicht oder nur sehr selten ändern, wie beispielsweise Übersetzungstabellen von Kodes nach Text oder Gleislisten. Da diese zum einen relativ häufig
benötigt werden und zum anderen deren Anzahl relativ hoch ist (mehrere 10.000
Datensätze), werden sie bei jedem Start der Client-Anwendung komplett geladen und auf Vorrat gehalten. Dadurch erhöht sich die Arbeitsgeschwindigkeit.
Als weiteren Mechanismus zur Konfliktreduzierung gibt es ein Event-Management. Jedes Mal, wenn es zu einer Änderung in der Datenbank kommt, wird
ein Event an alle Clients gesendet, welches diese über die Änderung informiert.
Ein Automatismus auf den Clients sorgt dann dafür, dass bei Bedarf die entsprechenden Daten nachgeladen werden.
Dank dieser Mechanismen und der zuverlässigen Anbindung der Clients an die
Server über ein LAN (Local Area Network) ist das Konfliktpotential sehr niedrig und es kommt im laufenden Betrieb nur selten zu Problemen (meist das
Überschreiben von noch nicht gespeicherter Änderungen).
2.2 Integration des mobilen Clients
Im Jahr 2004 begann die Entwicklung eines mobilen Clients (moBIS (mobiles BIS)), der für die Ausführung auf einem PDA (Personal Digital Assistant)
ausgelegt ist. Hauptanwender sind die Lokrangierführer. Es sollen damit in erster Linie die Geschäftsprozesse zwischen ihnen und den Disponenten optimiert
werden, indem der Kommunikationsaufwand gesenkt wird. Die mobile ClientAnwendung erlaubt es dem Nutzer sich alle wichtigen Daten aus dem BIS anzeigen zu lassen und ermöglicht die Ausführung grundlegender Funktionalitäten.
15
2 Einleitung
Auf diese Weise können die Lokrangierführer und die Disponenten ihren originären Aufgaben nachgehen und werden nicht mehr durch eine gegenseitige
Kommunikation unterbrochen.
Die Grundfunktionalitäten bestehen aus der Rangierauftragsverarbeitung und
der Eingangszugbehandlung und erlauben eine zeitnahe Aktualisierung und Änderung der Daten im BIS-System. In den bisherigen Realisierungen ist der mobile Client über GPRS (General Packet Radio Service), einer recht langsamen
und unsicheren2 Verbindungstechnik, mit dem BIS-System verbunden.
Der mobile Client ist nach den gleichen Prinzipien entwickelt worden wie die
stationäre Variante. Auch er besitzt keine lokale Datenhaltung3 und Geschäftslogik. Wegen technischer Probleme4 nimmt er nur halb am Event-Management
teil. Zwar lösen auch seine Aufrufe, die zu Änderungen in den Daten führen,
Events aus, aber diese werden nicht an die mobilen Anwendungen weitergeleitet.
Durch diese Konstruktion kann es zu vielen Problemen kommen, die im Folgenden gelöst werden müssen. Inaktuelle Daten können zu Konflikten führen. Aufgrund seiner Daten entscheidet sich ein Client für eine bestimmte Aktion und
startet einen entsprechenden Aufruf. Zwischenzeitlich können sich die Daten
aber geändert haben und es kann dementsprechend zu einem Konflikt kommen,
der erkannt werden muss. Ansonsten gerät das System in einen inkonsistenten
Zustand und das Abbild der Realität stimmt mit ihr nicht mehr überein.
Sollte ein mobiles Gerät nicht über eine Verbindung zum Server verfügen, was
wesentlich wahrscheinlicher ist als bei einem stationären Client, ist die Anwendung faktisch nutzlos. Dem Nutzer können keine weiteren Informationen vermittelt werden als die, die gerade angezeigt werden, da, abgesehen von den
Stammdaten, keine weiteren Daten auf dem Gerät verfügbar sind. Weiterhin
können auch keine Aktionen ausgeführt werden, da eine lokale Geschäftslogik
fehlt und die Aufrufe auch nicht zwischengespeichert werden können.5
Als einzige Optimierung gegenüber den stationären Clients sind die Webservices
für den mobilen Client nach dem DTO-Muster (Data Transfer Object) realisiert.
Dieses sieht vor, in eine Nachricht möglichst viele Informationen aufzunehmen,
um zusätzliche Aufrufe zu dem gleichen Bereich einsparen zu können.
Abbildung 2 gibt einen zusammenfassenden Überblick über das komplette BISSystem und zeigt nochmals die einzelnen Kommunikationspfade auf.
2
Sicherheit bezieht sich in diesem Zusammenhang auf die Verfügbarkeit. Auf einem großen
Werksgelände kann es durch schlechte Ausleuchtung oder störende Produktionsanlagen
immer wieder zu einem Verbindungsabbruch kommen.
3
Wieder mit Ausnahme der Stammdaten, die auf dem mobilen Gerät auch über das Beenden
der Anwendung hinweg verfügbar bleiben.
4
Es ist nicht ohne weiteres möglich, bei Bedarf eine Verbindung vom Server zum Client über
GPRS aufzubauen.
5
Auch wenn die Anwendung über eine lokale Geschäftslogik verfügen würden, muss dennoch
ein entsprechender Aufruf an das BIS-System gesendet werden. Entweder, um dort die
Geschäftslogik nochmals ablaufen zu lassen oder um die geänderten Daten mitzuteilen.
16
Abbildung 2: Architektur des BIS-Systems inklusive mobiler Clients
Für eine Offline-Fähigkeit der mobilen Clients, also der Möglichkeit, dass der
Anwender auch ohne eine Verbindung zum Server arbeiten kann, ist demnach eine lokale Datenhaltung und Geschäftslogik notwendig. Die lokale Datenspeicherung hält möglichst viele Daten auf Vorrat, um den Anwender damit versorgen
zu können und um Webservice-Aufrufe für eine spätere Absendung zwischenspeichern zu können. Die lokale Geschäftslogik simuliert im verbindungslosen
Fall einen Webservice-Aufruf.
Um die Steigerung des Konfliktpotentials gering zu halten, müssen die Daten auf
den mobilen Geräten durch geeignete Mechanismen möglichst aktuell gehalten
werden (Synchronisationsmechanismen). Dennoch auftretende Konflikte sollten
möglicht alle erkannt und automatisch gelöst werden.
3.1 Synchronisation
Der regelmäßige Abgleich der lokalen Daten auf den mobilen Geräten mit den
Server-Daten ist wichtig für die Konfliktminimierung und steigert so den Nutzwert der mobilen Anwendung. Die Daten auf dem Server können sich teilweise
sehr schnell ändern und es ist wichtig, dass alle Teilnehmer über diese Änderungen informiert werden.
Synchronisation ist der Oberbegriff für eine Vielzahl von Verfahren zum Abgleich verschiedener Datenspeicher. Das Wort Synchronisation leitet sich aus den
beiden griechischen Wörtern „sýn“ (zusammen) und „chrónos“ (Zeit) ab und bedeutet wörtlich so viel wie „Herstellen von Gleichlauf“. Es steht für das zeitliche
17
aufeinander Abstimmen von Vorgängen, also dafür, dass Vorgänge in einer bestimmten Reihenfolge beziehungsweise gleichzeitig auftreten. In der Informatik
wird unter Synchronisation auch das Abgleichen von Daten in einem verteiltem
System verstanden. Dieser Vorgang wird auch als Replikation bezeichnet. Dabei kann man zwischen der unidirektionalen/Einwege-Synchronisation und der
bidirektionalen/Zweiwege-Synchronisation unterscheiden, die jeweils synchron
oder asynchron ausgeführt werden kann. [19]
3.1.1 Synchrone Replikation
Bei der synchronen Replikation sind die Quell- und die replizierten Daten immer
identisch. Dies kann durch das 2-Phasen-Commit-Protokoll gewährleistet werden. Dabei werden die einzelnen Datenmanipulationen in eine Schlange eingereiht und nacheinander abgearbeitet. Der Empfang und die erfolgreiche Durchführung der Manipulation müssen jeweils quittiert werden. Erst danach wird die
Nächste gesendet. Sollte es währenddessen zu einem Fehler kommen, wird der
gesamte Vorgang als nichtig angesehen und der Ausgangszustand wiederhergestellt (Rollback) (siehe Abbildung 3).
Abbildung 3: Erfolgreicher und nicht erfolgreicher Nachrichtenaustausch mit
dem 2-Phasen-Commit-Protokoll
Verwendung findet das Verfahren beispielsweise bei der ROWA-Strategie (Read
One Write All) in Datenbanksystemen (zum Beispiel Hot Standby Replikation
von SQL-Server Microsoft Datenbanken). Hierbei wird eine Schreiboperation
auch auf allen Replikaten durchgeführt (write all). Eine Leseoperationen kann
dann auf einem beliebigen Replikat oder dem Original (read one) ausgeführt
werden, da durch die write all-Taktik alle Replikate identisch sind. [59]
18
3.1.2 Asynchrone Replikation
Bei der asynchronen Synchronisation können sich die Ausgangsdaten und die Replikate durchaus unterscheiden. Lediglich zum Zeitpunkt der Replikation sind
die beiden Datensätze identisch (synchron). Eine einfache Variante wäre das
Transferieren von Dateien beispielsweise via FTP oder SSH. Somit stellen die
Replikate nur eine Momentaufnahme der Ausgangsdaten dar. Häufig kommt
diese Art der Replikation bei mobilen Datenbanken auf Notebooks zum Einsatz. Ein Problem, welches sich automatisch aus der Asynchronität ergibt, ist,
dass es bei einer späteren Synchronisation zu Konflikten kommen kann. Einzelne Änderungen werden bei diesem Verfahren nur an einem Objekt durchgeführt
(Original oder Replikat). Bei einer Zusammenführung dieser beiden Daten (Synchronisation) kann es zu Konflikten kommen, wenn sowohl das Original als auch
das Replikat manipuliert worden sind.
3.1.3 Unidirektionale Synchronisation
Hier findet die Synchronisation nur in eine Richtung statt und die Gegenseite
wird „ignoriert“. Angenommen, es gilt die Daten zwischen einem PDA und einem
Notebook abzugleichen. In diesem Fall würden nur die aktuellen Daten vom
Notebook auf den PDA oder umgekehrt übertragen werden und nicht darauf
geachtet, ob es nicht auch Änderungen auf der Gegenseite gegeben hat.
3.1.4 Bidirektionale Synchronisation
Bei dieser Variante werden beide Seiten in den Synchronisationsprozess einbezogen. Das heißt nach dem vorherigen Beispiel, dass das Notebook dem PDA seine
Änderungen mitteilt und ebenso der PDA dem Notebook. Sie sind somit gleichberechtigte Partner. Allerdings kann es hierbei unter Umständen zu Konflikten
kommen. Diese können beispielsweise mittels Priorisierung gelöst werden. Hierbei legt man fest, dass immer das jüngere Datum bevorzugt wird oder immer
das Notebook. Natürlich ist auch eine manuelle Auflösung durch den Nutzer
denkbar. Des Weiteren gibt es auch noch automatische Systeme, die selbstständig aufgrund einer Analyse der vorliegenden Daten versuchen den Konflikt zu
lösen.
3.1.5 SlowSync und PushSync
Neben der normalen Synchronisation gibt es noch das so genannte SlowSyncVerfahren. Hier werden nicht die Änderungsinformationen ausgetauscht, sondern
die kompletten Daten. SlowSync kommt in der Regel zum Einsatz, wenn die
Gegenseite noch keine Daten hat oder diese vollkommen veraltet sind.
Bei der Push-Synchronisation werden die Änderungsinformationen sofort übertragen, wenn eine Änderung anliegt (ähnlich dem Event-Management). Das
19
Push-Verfahren kommt zum Beispiel bei Informationsdiensten, wie einem Kamerasystem, zum Einsatz, das Sensordaten bei bestimmten Ereignissen an ein
Mobiltelefon überträgt.
3.1.6 Funktions- versus Datenreplikation
Hierbei handelt es sich um zwei Konzepte, wie getrennte Datenspeicher synchron
gehalten werden können. Die
Datenreplikation (in der Literatur oft auch als Replikation bezeichnet) führt den Abgleich über den Austausch der eigentlichen Daten
aus (siehe Abbildung 4).
Bei der
Funktionsreplikation (in der Literatur oft auch als Synchronisation
bezeichnet) werden die einzelnen Funktion, die zu einer Änderung
führen, ausgetauscht und jeweils auf beiden Seiten ausgeführt (siehe
Abbildung 5).
Dies können direkt Datenbankbefehle sein oder Anweisungen einer abstrakten
Schicht, wie zum Beispiel eines Webservices.
Abbildung 4: Funktionsweise der Datenreplikation
3.2 Differenzerkennung
Basis fast jeder Synchronisation ist die Ermittlung von Unterschieden (Differenzen) zwischen den abzugleichenden Datenspeichern, um nur die Änderungen
übertragen zu müssen. Je nach Szenario und Anforderungen können verschiedene Verfahren zum Einsatz kommen, von denen einige kurz vorgestellt werden.
Der einfachste Ansatz vergleicht die beiden zu synchronisierenden Datenbestände miteinander und stellt so die Unterschiede fest. Dies setzt allerdings voraus,
20
Abbildung 5: Funktionsweise der Funktionsreplikation
dass demjenigen, der den Vergleich durchführt, beide Datenbestände zur Verfügung stehen. Durch das ständige Gegenprüfen der Daten der Gegenstelle kann
es zudem zu einem sehr hohen Datenaufkommen kommen.
Eine zweite Möglichkeit ist das Führen einer Liste mit Änderungsinformationen.
Diese hält fest, welche Daten seit der letzten Synchronisation geändert worden
sind. So stehen zum Zeitpunkt der Synchronisation bereits alle nötigen Informationen zur Verfügung und es muss nicht erst die Differenz gebildet werden.
Dies entspricht dem Ansatz der Funktionsreplikation. Allerdings kann der dafür
notwendige Verwaltungsaufwand recht hoch werden, besonders wenn die Daten
auf der einen Seite sehr komplex sind und auf der anderen Seite nur wenige
davon benötigt werden.
Durch den Einsatz von Prüfsummen, Änderungszähler oder Zeitstempel kann
eine Minimierung des Datenaufkommen erreicht werden. So brauchen zu Anfang
nur die Prüfsummen ausgetaucht werden, anhand derer die Gegenseite dann
ermitteln kann, ob sich diese von den eigenen Prüfsummen unterscheiden. Mit
Änderungszählern kann relativ einfach zur Laufzeit ermittelt werden, welche
Daten sich überhaupt geändert haben.
3.3 Die Sprache SyncML
Die Sprache SyncML ist eine Beschreibungssprache, die den Nachrichtenverkehr
zu Synchronisationszwecken zwischen zwei Geräten, beispielsweise einem PC
und einem Handheld, spezifiziert. Vorgestellt wird sie, um einen kurzen Überblick über dieses komplexe Themengebiet zu vermitteln und um aufzuzeigen,
welche Probleme gelöst werden müssen.
Aktuell wird SyncML durch die OMA (Open Mobile Alliance) weiterentwickelt.
Nähere Details zu der Spezifikation können [11] und [17] entnommen werden.
Unter [20] sind OpenSource-Realisierungen für verschiedene Sprachen zu finden.
21
3.3.1 Details zu SyncML
In Anlehnung an die WSDL (WebService Description Language) handelt es
sich bei dieser Sprache ebenfalls um ein XML-Derivat (eXtensible Markup Language). Ebenso wie bei WSDL erfolgt die gesamte Kommunikation über XML.
Durch die Verwendung dieses offenen Standards ist eine plattformübergreifende
Realisierung möglich.
Allerdings ist das Datenaufkommen sehr hoch, wenn man die XML-Daten in
Klartext überträgt. Deswegen werden in vielen Realisierungen die Daten binär
mittels WBXML (WAP (Wireless Application Protocol) Binary XML) übertragen. Dieses kodiert wiederholt vorkommende Tags als binäre Token, die meist
nur ein Byte Platz beanspruchen.
Ein weiterer Vorteil der Sprache liegt in der Verwendung des HTTP-Protokolls
(HyperText Transfer Protocol) für den Transport der Daten. Falls eine sichere Verbindung benötigt wird kann auch das HTTPS-Protokoll (HTTP Secure)
eingesetzt werden. Der Einsatz dieser Protokolle bietet den großen Vorteil, dass
in der Regel keine Probleme mit Firewalls entstehen. Da dies auch das Protokoll des Internets ist, haben die meisten Unternehmen deswegen den dafür
notwendigen Port 80 freigeschaltet.
Falls die Synchronisation über eine USB-Schnittstelle, Infrarot oder Bluetooth
erfolgt, kommt häufig OBEX (OBject EXchange) zum Einsatz, eine Art verschlanktes HTTP mit sparsameren binär kodierten Headern. Hin und wieder
wird in Mobiltelefonen auch WSP (Wireless Session Protocol) genutzt, ebenfalls ein eingeschränktes HTTP, welches für WAP entwickelt worden ist.
3.3.2 Die Kommunikation
3.3.2.1 Identifikation der Daten
Damit die Synchronisation erfolgreich durchgeführt werden kann, müssen die
Daten auf beiden Seiten eindeutig identifizierbar sein. SyncML sieht dafür eindeutige IDs vor. Allerdings müssen die gleichen Daten auf der Client- und
Server-Seite nicht die gleiche ID besitzen. Stattdessen nutzt der Standard ein
ID-Mapping, dass in der Regel aus einer Tabelle mit ID-Pärchen besteht. Üblicherweise wird diese Tabelle vom Server verwaltet. Die IDs selber können beliebige Strings sein und müssen nur server-, statt systemweit eindeutig sein.
Zudem ist es notwendig, dass der Server und Client in der Lage sind, Änderungen
an den Datensätzen (gelöscht, geändert oder neu seit der letzten Synchronisation) festzustellen. Auf der Client-Seite gibt es die Vereinfachung, dass dieser
nicht zwischen geänderten und neuen Datensätzen unterscheiden können muss.
Zum Einsatz kommen kann hier jedes beliebige Verfahren. SyncML schreibt nur
vor, dass die auf dem Client und dem Server eingesetzten Verfahren unabhängig
voneinander sein müssen, um die Flexibilität des Systems zu wahren.
22
3.3.2.2 Der Ablauf
Der Start der Synchronisation erfolgt immer durch den Client und besteht aus einer Abfolge von Anfragen und Serverantworten, die über eine SyncML-Nachricht
ausgetauscht werden. Eine Nachricht besteht aus dem Kopf, in SyncML mit
SyncHdr bezeichnet, und dem Rumpf, dem sogenannten SyncBody. Der Kopf
enthält die Version des genutzten Protokolls, eine laufende Nummer für die Session, den Nachrichtentyp, den Absender und das Ziel. Eine Angabe der Nachrichtengröße ist insbesondere bei „kleinen6 “ Mobiltelefonen wichtig, da diese oft
nur wenige Kilobyte bearbeiten können.
Der Rumpf enthält die eigentlichen Kommandos, die für die Durchführung der
Synchronisation notwendig sind. Diese gliedert sich in drei Phasen:
• Initialisierung
• Datenaustausch
• Mapping
3.3.2.2.1 Initialisierung
Zu Beginn dieser Phase teilt der Client dem Server durch ein so genanntes AlertCommand über einen numerischen Kode seinen Synchronisationswunsch mit.
200 würde zum Beispiel zu einer „normalen“ Zweiwege-Synchronisation führen.
Über den Anchor-Eintrag in der Nachricht prüfen der Client und der Server, ob
sie beide von derselben vorhergegangenen Synchronisations-Session ausgehen.
Dafür enthält das Next-Feld eine Referenz auf die aktuelle Session für den Client
und das Last-Feld den entsprechenden Wert für die vorangegangene Session. Die
Überprüfung erfolgt auf Server-Seite. Dazu speichert dieser das Next-Feld am
Ende einer erfolgreichen Session. Bei Eintreffen eines neuen Alerts vergleicht
der Server das Last-Feld mit dem gespeicherten Next-Feld. Stimmen die beiden
Werte nicht überein, so ist die vermeintlich letzte Session nicht auf beiden Seiten
die gleiche und es kommt zu einem SlowSync.
Des Weiteren können die beiden Parteien ihre devInf (Device Information) austauschen, um festzustellen, welche Daten überhaupt synchronisiert werden können.
3.3.2.2.2 Datenaustausch
Nachdem die Initialisierungsphase abgeschlossen ist, steht fest, auf welche Art
und Weise die Synchronisation stattfinden soll. Über den Austausch der devInfs
wissen beide Seiten auch, welche Felder und Features unterstützt werden. Der
6
Klein im Sinne von wenig Speicher. Dies hängt im Allgemeinen nicht von der Größe des
Geräts ab.
23
Client sendet jetzt seine geänderten Daten (im Falle eines SlowSync seine kompletten Daten) an den Server. Dieser antwortet seinerseits mit seinen geänderten
Daten.
Dabei können diese Daten beliebig formatiert sein. Damit aber ein gewisses
Minimum an Kompabilität gewährleistet werden kann schreibt SyncML ein paar
unter PDAs weit verbreitete Formate vor, die unterstützt werden müssen. Dazu
zählen beispielsweise vCard für Kontakte und das Internet Message Format
gemäß RFC 2822 für E-Mails.
3.3.2.2.3 Mapping
In der letzten Phase der Synchronisation teilt der Client dem Server seine IDs
mit, damit dieser seine Mapping-Tabelle aktualisieren kann. Beendet wird die
komplette Session durch das Senden eines OK-Status an den Client. Erst danach
gilt die Session für den Client und den Server als abgeschlossen und der Server
kann das ganz am Anfang gesendete Next-Anchor abspeichern.
Einen Sonderfall bildet der Sync-Konflikt. Dieser tritt auf, wenn auf beiden
Seiten an dem gleichen Datensatz Änderungen vorgenommen worden sind. Die
Auflösung des Konflikts ist Sache des Servers. Allerdings schreibt SyncML nicht
vor, wie dies zu geschehen hat. Möglich wären beispielsweise einfache Priorisierung (Server überschreibt Änderungen des Client), Speichern beider Versionen
oder auch Algorithmen, die die Daten analysieren und zusammenführen können. Nicht vorgesehen ist ein interaktives Eingreifen des Nutzers. Realisieren
lässt sich dieses aber, indem zunächst beide Versionen gespeichert werden, um
dann im Nachhinein die falsche Version durch den Anwender löschen zu lassen.
3.3.3 Fazit
Durch die Verwendung offener Standards und der Nutzung von HTTP als Transportprotokoll setzt sich SyncML zunehmend durch. So bieten bereits über 250
Hersteller [11] Produkte an, die mit einer SyncML-Schnittstelle ausgerüstet sind.
Zudem wird der Standard immer weiter entwickelt und an neue Bedürfnisse und
Technologien angepasst. So sehen aktuelle Entwicklungen auch die Wiederaufnahme von abgebrochenen Synchronisationsvorgängen vor, damit bei einem Verbindungsfehler die Synchronisation nicht komplett neu gestartet werden muss.
Abschließend sind aus der vorangegangenen Diskussion teils schon bekannte,
teils neue Problemfelder erkennbar:
• Zuordnung: Wie können die Client- und Server-Daten identifiziert werden?
• Nachrichtenformat: Wie werden die Informationen übertragen (Löschen,
Neu, Änderung)?
• Kommunikationsablauf: Wer startet die Synchronisation? Wann ist sie beendet? In welcher Reihenfolge werden die Nachrichten ausgetauscht?
24
• Differenzerkennung: Wie werden unabhängig von der Gegenseite Unterschiede festgestellt?
• Synchronisationsrichtung: Teilt nur der Server seine Änderungen mit, oder
auch der Client?
• Konflikterkennung: Wie kann man Konflikte erkennen/vermeiden/beheben?
• Datenreduktion: Wie kann das Übertragungsvolumen so gering wie möglich gehalten werden?
• Übertragungsweg: Welche Protokolle erlauben einen möglichst flexiblen
Einsatz? Wie kann die Kommunikation gesichert werden? Wie können
beispielsweise Firewall-Hürden überwunden werden?
4.1 Service Oriented Architecture?
Im Kontext verteilter Anwendungen, wie das BIS eine ist, fällt häufig das Schlagwort SOA (Service Oriented Architecture). Hinter diesem Begriff verbirgt sich
mehr eine Idee als eine Technik. Es beschreibt das Verwalten, Erstellen und
Kombinieren von Softwareprozessen mit dem Ziel, die IT-Infrastruktur auf die
Geschäftsprozesse auszurichten. Sie soll so schnell auf geänderte Anforderungen
reagieren können und durch die Mehrfachnutzung der Dienste Kosten einsparen.
[27]
Ob man das BIS-System als dienstorientierte Architektur bezeichnen kann hängt
ganz von der Definition von SOA ab, derer es viele, teils sogar widersprüchliche, gibt. Die OASIS-Gruppe (Organization for the Advancement of Structured
Information Standards), die auch ein Referenzmodell für SOA entwickelt hat
(siehe [43]), definiert SOA als
„. . . paradigm for organizing and utilizing distributed capabilities
that may be under the control of different ownership domains“ [38].
Demnach besteht die Architektur aus beliebig vielen dynamischen7 und örtlich
verteilten Diensten, die von verteilten Anwendungen zur Erfüllung ihrer Aufgaben genutzt werden können. Abbildung 6 verschafft einen Überblick über den
Aufbau einer solchen Architektur.
Nach dieser Definition kann man BIS nicht zu den dienstorientierten Architekturen zählen, da es keine dynamischen Dienste gibt. Entweder ist der Webservice
verfügbar und dem Nutzer stehen alle Dienste zur Verfügung, oder der Webservice ist nicht verfügbar und demnach sind keine Dienste erreichbar.
7
Nicht jeder Dienst muss jederzeit verfügbar sein.
25
Abbildung 6: Übersicht über Basistechnologien für den Einsatz mit SOA [47]
Microsoft definiert SOA als
„. . . eine Software-Infrastruktur, in der die wesentlichen Funktionen
einer Anwendung bzw. Softwaremodule als Service organisiert sind.
Services können beliebig verteilt sein und lassen sich dynamisch zu
Geschäftsprozessen verbinden. SOA legt hierbei die Schnittstellen
fest, über die andere Systeme via Netzwerk diese Dienste nutzen
können“ [44].
Hier liegt das Hauptaugenmerk darauf, dass alle wesentlichen Funktionen einer
Anwendung als Dienst zur Verfügung gestellt werden. Ob diese verteilt und
wie dynamisch diese sind, ist nebensächlich. Hiernach kann das BIS als eine
dienstorientierte Architektur bezeichnet werden.
Viel wichtiger8 aber als die Frage, ob sich das BIS-System als Service Oriented Architecture bezeichnen darf, sind die Techniken, die bei SOA zum Einsatz
kommen – insbesondere die Konzepte zur Realisierung einer offline-fähigen Anwendung. In den kommenden Unterabschnitte werden einige von ihnen näher
erläutert, um die Ideen für die Realisierung guter9 , verteilter und offline-fähiger
Anwendungen darzulegen.
4.1.1 Der Nutzen von SOA für mobile Endgeräte
Viele Implementierungen setzen den Client nur als Vermittler in einer serverbasierten Anwendung ein – so auch das aktuelle moBIS. Er stößt Prozesse an und
übermittelt Daten an den Server. Die Validierung der Daten und Ausführung der
Geschäftslogik obliegt der Server-Anwendung. Diese Rollenverteilung ist nicht
immer möglich, befriedigt aber sehr viele Szenarios und ist relativ einfach zu
8
Zumindest aus technischer Sicht. Als modisches Schlagwort kann es ein wichtiges Argument
für das Marketing sein.
9
Im Sinne von Wartbarkeit und Wiederverwendbarkeit.
26
realisieren. Ein umgekehrtes Szenario ist deutlich aufwendiger und bringt viele
Probleme mit sich, wie zum Beispiel die dauerhafte Sicherung der Daten oder
das Ausführen der Geschäftslogik (beispielsweise zeitkritische Prozesse auf langsamen10 Geräten). Im Gegenzug wird der Client dadurch aber selbstständiger
und eine Weiterarbeit im verbindungslosen Zustand ermöglicht.
Um die einzelnen Bereiche Client-Logik, Geschäfts-Logik und Server-Logik klar
trennen zu können, muss zunächst der Begriff „Dienst“ genauer beschrieben
werden.
Ein Dienst (Service) stellt im Prinzip eine Applikation mit einer
Nachrichten-basierten, eventuell auch asynchronen, Schnittstelle dar,
die ihre Daten kapselt und unterstützt durch das 2-Phasen-CommitProtokoll für eine sichere11 Ausführung der Geschäftslogik sorgt. [36]
Aufgrund der Kapselung der Daten und den frei zugänglichen Schnittstellen
können Dienste auch beliebig kombiniert werden. So kann man mit nur einfachen Diensten eine komplexe Geschäftslogik realisieren. Typischerweise bestehen
diese aus vier Schichten:
• Schnittstelle
• Geschäftsprozessfassade
• Geschäftsregeln
• Datenzugriff
Die Schnittstelle bildet die Brücke zwischen dem Client und der Geschäftsprozessfassade. Ein einzelner Dienst kann verschiedene Schnittstellen haben, zum
Beispiel für einen Webservice und ein Warteschlangen-System. Im Allgemeinen
sind die Schnittstellen zustandslos. Dadurch gibt es keine Probleme, wenn beispielsweise nach einem Fehler die Schnittstelle erneut aufgerufen wird [23]. Eine
typische zustandslose Funktion könnte so aussehen: ändereKunde( Kunde ), im
Gegensatz zur zustandsbehafteten Funktion: ändereKundenName( String ).
Die Geschäftsprozessfassade wird über die Schnittstelle aufgerufen und implementiert das Controller-Pattern um die eigentlichen Geschäftsprozesse mit den
zugehörigen Regeln aufzurufen. Des Weiteren findet hier eine Transformation
der Daten von dem öffentlichen Format der Schnittstelle in die interne Datenstruktur statt.
Die Geschäftsregeln sind das Rahmenwerk für die eigentliche Durchführung eines
Dienstes. Sie legen zum Beispiel fest, wie die Mehrwertsteuer von einem Produkt
10
Im Vergleich zu einem Server-System bieten PDAs wesentlich geringere Speicher- und Rechenkapazitäten.
11
Sicherheit meint in diesem Zusammenhang die Einhaltung der ACID-Eigenschaften (atomic
(atomar), consistent (konsistent), isolated (isoliert) und durable (dauerhaft)).
27
berechnet werden soll. Erst mit Hilfe der Regeln werden Prozesse universell und
dadurch wiederverwendbar.
Über den Datenzugriff wird sichergestellt, dass die Daten auf Server-Seite immer
korrekt sind. Auch sollte der Dienst so gestaltet sein, dass er nicht blockierend
wirken kann, beispielsweise indem der Client ein Benachrichtigungsfenster öffnet, welches der Nutzer bestätigen muss, damit die Verarbeitung weiterlaufen
kann.
4.1.2 Der Einsatz von Agenten
Durch die strikte Trennung zwischen Client und Server (Datenkapselung, Geschäftslogik) und den Anspruch, die Client-Software möglichst flexibel zu gestalten, werden auf Client-Seite häufig Agenten eingesetzt, die dort die Ablaufsteuerung übernehmen.
Agenten können als Mittler zwischen Diensten und Clients betrachtet werden und nehmen die Rolle eines Proxy wahr. [36]
Typischerweise besteht die Arbeit aus eine Abfolge vielzähliger kleiner Schritte.
Um zum Beispiel eine E-Mail zu schreiben muss man den Empfänger angeben,
eine Betreffzeile eintragen, die Nachricht schreiben und so weiter. Die Aufgabe des Agenten besteht nun darin, die Eingaben zu sammeln, zu überprüfen
und gebündelt abzuschicken. Dabei ist der Agent selbst kein Bestandteil eines
Dienstes und ist so aus dessen Sichtweise per se nicht vertrauenswürdig. Deswegen wird jeder Austausch zwischen dem Agenten und dem Dienst authentifiziert
und autorisiert12 , sowie die übermittelten Daten vom Dienst validiert. Je nach
Dienst und System sind die einzelnen Prüfungen unterschiedlich streng.
Ein weiteres großes Unterscheidungsmerkmal zwischen einem Agenten und einem Dienst ist die Datenhaltung. Während es ein Agent in der Regel nur mit
einem Client zu tun hat, muss ein Dienst viele Clients bedienen und auch deren Daten verwalten können. Je nach Anzahl der Clients kann dies ein sehr
komplexer Vorgang sein (eventuell viele Schreiboperationen, Datenkonsistenz,
Autorisierung). Oft ist dies auch der Hauptgrund, warum sich ein Dienst relativ
schlecht skalieren lässt.
4.1.3 Entwicklung von Diensten und Agenten
Damit die Anwendung für mobile Endgeräte möglichst robust und zuverlässig
arbeiten kann, sollte der Agent im verbindungslosen Zustand in der Lage sein,
einen benötigten Dienst teilweise oder ganz zu simulieren. Dafür müssen die zu
simulierende Funktion genau analysiert und spezifiziert werden. Gleiches gilt
12
Authentifizierung und Autorisierung spielen in dem Zusammenhang diese Arbeit nur eine
sehr untergeordnete Rolle, da die Webservice-Schnittstelle des BIS-Systems von sich aus
nicht öffentlich ist. Nähere Informationen siehe zum Beispiel [18], [45] oder auch [53].
28
für die Daten, die für die Ausführung der Dienste benötigt werden. Allgemein
erweist sich folgende Herangehensweise als günstig:
1. Identifizierung der Anwendung, die mobil gemacht werden soll
2. Erstellen oder Ermitteln einer Schnittstelle, die den mobilen Kommunikationstechniken (GSM/UMTS, Bluetooth, Infrarot, WLAN) gerecht wird
3. Sicherstellen, dass der Client auch an die Daten kommen kann, die dieser
für den verbindungslosen Fall benötigt
4. Herausarbeiten, welche Funktionalitäten auch im Offline-Modus verfügbar sein sollten. Diese als Ein-Wege-Ruf realisieren, um Abhängigkeiten
zwischen Client und Server zu vermeiden
5. Funktionen, die nur mit einer Verbindung sinnvoll sind, sollten als RequestResponse-Ruf realisiert werden, um sicherzustellen, dass die Funktion auf
dem Server erfolgreich ausgeführt worden ist
6. Für die Funktionen unter Punkt 4 einen Agenten erstellen
• Benötigte Daten und Geschäftslogik finden
• Erstellen einer Schnittstelle für den Agenten, welche die eigentliche
Dienst-Schnittstelle kapselt. Dadurch ist der Dienst-Zugriff für die
Anwendung immer gleich und der Agent kümmert sich um die Online/Offline-Verwaltung
7. Implementieren eine Benutzer-Schnittstelle, die vom Agenten unterstützt
wird
Die Abbildung 7 stellt die einzelnen Schichten einer offline-fähigen Anwendung
schematisch dar.
4.1.4 Mögliche Problemstellen
Häufig benötigt die portierte Geschäftslogik lokale Daten auf dem mobilen Gerät. Die Replikation dieser Daten kann zu Problemen führen. Manchmal ist es
nicht möglich Daten zu replizieren, weil die Dienste keinen Zugriff darauf erlauben. Oft stellen sie auch nur aggregierte Daten zu Verfügung, um das Übertragungsvolumen klein zu halten. Die Geschäftslogik benötigt aber gelegentlich
noch weitere Daten, beispielsweise für Prüffunktionen. In diesem Fall müssen
dann mehr Daten auf den Client übertragen werden, als dieser eigentlich benötigt.
Mobile Geräte gibt es in den unterschiedlichsten Ausführungen (PDA, Smartphone, Mobiltelefone, UMPC (Ultra Mobile PC), Tablet-PC, (Sub-)Notebooks),
die sich sehr in Hardware (Prozessorausstattung, Speichergröße, Verbindungstechnologien) und Software (Dateisystem, Betriebssystem) unterscheiden. Deswegen muss die Client-Anwendung sehr flexibel und anpassbar gestaltet werden,
29
Abbildung 7: Schichten in einer offline-fähigen mobilen Anwendung
so dass die Geräte-Spezifika berücksichtigt werden können und dennoch der Wiederverwendungssgrad möglichst hoch ist. Dadurch werden Entwicklungs- und
Wartungskosten niedrig gehalten.
Problematisch kann es auch werden, wenn das System über Schnittstellen zu
Fremdsystemen verfügt. Auch bei offlinedurchgeführten Aufrufen muss gewährleistet sein, dass diese angesprochen werden.
Und auch hier treten wieder die Probleme mit den notwendigerweise verteilten
Daten und den daraus resultierenden Konfliktmöglichkeiten auf.
4.1.5 Fazit
Es gibt viele Möglichkeiten eine offline-fähige Anwendung zu entwerfen. Die
skizzierte Vorgehensweise hat den Vorteil, dass es eine klare Trennung zwischen
Client und Server gibt. Durch den Einsatz des Agenten, der im Prinzip den Server auf dem Client simuliert, bedeutet es für die eigentliche Client-Anwendung
keinen Unterschied, ob das Gerät gerade über eine Verbindung verfügt oder
nicht. Ohne großen Aufwand können so auch bereits existierende Anwendungen
offline-fähig gemacht werden.
Einen Gesamtüberblick über das System gibt die Abbildung 8. Es besteht aus
dem Agenten und der Anwendung auf der Client-Seite, sowie der Geschäftslogik
und Synchronisationsanwendung auf der Server-Seite. Die Dienste kommunizieren über wohldefinierte öffentliche Schnittstellen. Ein XML-Schemata beschreibt
die eigentlichen Nachrichtenstrukturen.
30
Abbildung 8: Architektur von SOA
Der Agent selbst bietet der Client-Anwendung eine feingranulare programmatische Schnittstelle an. Im verbindungslosen Fall kann er Teile der Geschäftslogik
simulieren, so dass die Anwendung normal weiterarbeiten kann und im besten
Fall davon nichts mitbekommt.
Problematisch für die Umsetzung ist die genaue Festlegung des Funktionsumfangs der zu simulierenden Geschäftslogik. Je umfangreicher sie ist, um so mehr
Daten benötigt der Client zur Ausführung. Aber andererseits ist ein sinnvolles
Arbeiten im Offline-Fall nicht mehr gegeben, wenn der Umfang zu klein ist.
Die Bestimmung des Umfangs sollte auf dem Motto beruhen: „So viel lokale
Geschäftslogik wie nötig und so wenig wie möglich“.
Das größte Problem ist aber die Aktualität der Daten auf dem Client, da sich
diese jederzeit auf dem Server ändern können. Um Konflikte zu vermeiden sollte
deswegen versucht werden, die Daten auf dem Client so aktuell wie möglich zu
halten, damit die dort getroffenen Entscheidung auf korrekten Daten beruhen.
Weitere Hinweise und Tipps für die Realisierung können unter anderem [36]
entnommen werden.
4.2 OneBridge Mobile Platform
Auf dem Markt existieren bereits fertige Lösungen, die damit werben, dass sie
mit mehr oder minder großem Aufwand existierende Anwendungen offline-fähig
machen können und sich damit auch leicht Offline-Anwendungen realisieren lassen. Diese werden direkt von Datenbankherstellern oder von Dritt-Anbietern
angeboten. Lösungen direkt von Datenbankanbietern scheiden meist sofort aus,
weil diese auf ein bestimmtes Datenbanksystem festgelegt sind. Damit wäre die
Lösung nicht mehr unabhängig von der Umgebung, in der sie eingesetzt werden
kann.
Die OneBridge Mobile Platform arbeitet unabhängig von einem bestimmten
Datenbanksystem und wird deswegen kurz vorgestellt. Hierbei handelt es sich
31
um eine Plattform zur Entwicklung mobiler Anwendungen. Sie besteht aus den
drei Teilen:
• OneBridge Mobile Groupware
• OneBridge Mobile Data Suite
• OneBridge Monitoring Service
Bis 2005 wurde sie von Extended Systems entwickelt und vertrieben. Dann wurde sie von Sybase für circa 71,3 Millionen Dollar (siehe [32]) übernommen und
ist jetzt in deren Tochterfirma iAnywhere Solutions Inc., welche Marktführer im
Bereich mobiler Infrastruktur ist [33], eingegliedert. Nach Angaben des Herstellers ermöglicht die Plattform eine „einfache und nahtlose Portierung bestehender
Unternehmensanwendungen auf mobile Umgebungen. Dies garantiert einen sicheren und zuverlässigen Informationsfluss zwischen mobilen Mitarbeitern und
dem Unternehmen. Die Plattform bietet einen integrierten, lösungsorientierten
Ansatz und unterstützt jedes mobile Gerät, jedes Unternehmenssystem und jeden Kommunikationsmodus – darunter Online, Offline, Real-Time (Echtzeit),
Push oder Synchronisation“ [28]. Die Abbildung 9 zeigt eine Übersicht über den
Aufbau der Infrastruktur unter Verwendung dieser Plattform.
Abbildung 9: Infrastruktur der OneBridge Mobile Platform [30]
32
4.2.1 OneBridge Mobile Groupware
Ursprünglich ist die Plattform entwickelt worden, um kostengünstig E-Mails und
PIM-Daten (Personal Information Manager) wie Termine, Kontakte und Aufgaben an mobile Endgeräte zu übertragen. Die OneBridge Mobile Groupware
selbst ist dabei unabhängig von den eingesetzten Geräten, dem Verbindungsmodus und der Groupware-Anwendung. Unterstützt werden unter anderem Microsoft Exchange, Lotus Domino und Novell GroupWise. [28]
4.2.2 OneBridge Mobile Data Suite
Die OneBridge Mobile Data Suite beinhaltet eine Reihe von Entwicklungswerkzeugen, die die Entwickler mobiler Software vom Design bis zur Implementierung unterstützen sollen. Sie beinhaltet Sync-Libraries, welche die Daten-Replizierungsprozesse unterstützen. Des Weiteren ist das OMAAT (OneBridge Mobile Application Acceleration Toolkit) enthalten, welches die Entwicklung mobiler Anwendungen erleichtert. Bereits vorhandene Anwendungen können ohne
„Umbau“ mit Push-Eigenschaften nachgerüstet werden. Durch das Embedded
Toolkit ist es möglich, mobile Anwendung in .NET oder Java ME (Java Micro
Edition) zu entwickeln, die Synchronisationsfähigkeiten, Webservices oder PushTechnologien integrieren, ohne dass separate Komponenten auf dem Client benötigt werden. Das Toolkit ist für .NET, .NET Compact Framework und Java
Micro Edition verfügbar. Angeblich soll man damit Anwendungen für mobile
Nutzer entwickeln können, „ohne sich Gedanken über Datenintegrität, Speicher
und Konektivität machen zu müssen“ [29].
Im Jahr 2005 ist die OneBridge Mobile Data Suite mit dem „Best of TechEd
2005“ in der Kategorie „Mobile Lösungen“ von den Magazinen Windows IT Pro
und SQL Server Magazine ausgezeichnet worden und hat sich damit gegen 260
Bewerber in insgesamt 10 Kategorien durchgesetzt. [22]
Neben den klassischen Synchronisationsverfahren, wie sie in Kapitel 3.1 beschrieben worden sind, bietet die Data Suite auch noch ein so genanntes Live Connect
an. Dieses synchronisiert automatisch die Daten im Hintergrund, sobald Änderungen vorgenommen worden sind. Im Gegensatz zum Push-Verfahren erlaubt
dieses auch eine Zwei-Wege-Kommunikation. Das Konfliktmanagement der Synchronisation ist frei konfigurierbar. Es stehen Priorisierung, sowie Regel-basierte
und automatische Konfliktlösungen zur Verfügung. Als Protokoll kommt auch
hier SyncML zum Einsatz (siehe Kapitel 3.3). Ein weiteres interessantes Merkmal ist, dass auch eine „multiple server table to single device table“-Option
vorhanden ist (Synchronisation aggregierter Daten). Das heißt, dass mehrere
serverseitige Tabellen während der Replikation/Synchronisation zu einer zusammengefasst werden können. Zusätzlich werden auch noch diverse Logging- und
Sicherheitsfeatures angeboten.
33
4.2.3 OneBridge Monitoring Service
Dieser Dienst kann alle OneBridge-Komponenten in einem Unternehmen beobachten. Sobald ein Problem auftritt können geeignete Gegenmaßnahmen ergriffen werden und so die Verfügbarkeit des Servers erhöht werden. Die Maßnahmen erstrecken sich von dem Verschicken von Status-Meldungen bis hin zu so
genannten Selbstheilungsprozessen. [31]
4.2.4 Fazit
Die OneBridge Mobile Platform, besonders die Data Suite, bietet viele interessante Features an. Besonders attraktiv im Kontext dieser Arbeit sind das Live
Connect und die „multiple server table to single device table“-Option.
Um jedoch nicht den zeitlichen Rahmen für diese Arbeit zu sprengen wird erst
einmal auf die Nutzung der Plattform verzichtet. Perspektivisch gesehen kann
ihr Einsatz oder der ähnlicher Produkte aber sinnvoll sein. Dies hängt vor allem von den zukünftig zu lösenden Problemen und der Kundenakzeptanz, ein
Drittsystem einzusetzen, ab.
Durch die vorangegangene Diskussion sind viele Problemfelder aufgezeigt worden, die bei dem Hinzufügen einer Offline-Fähigkeit berücksichtigt werden müssen. Dies sind unter anderem:
• Umfang der lokalen Datenhaltung und Geschäftslogik
– Einbeziehung von Schnittstellen zu Fremdsystemen
• Art und Weise der Datensynchronisation
– Ablaufsteuerung der Synchronisation
– Aufbau der Nachrichten
– Daten- oder Funktionsreplikation
– Konflikterkennung und -behebung
• Integration der Offline-Fähigkeiten in die Client-Anwendung
Die Lösungen dieser Probleme werden in den nachfolgenden Unterabschnitten
näher erläutert und basieren teilweise auf den bereits vorgestellten Konzepten.
Neben diesen Problemen muss die Lösung auch noch den allgemeinen Anforderungen an die mobile Anwendung gerecht werden, die durch die verschiedenen
Eigenschaften der einzelnen Aufrufe geprägt sind:
34
• Zeitgenaue Erfassung von Abläufen für die statistische Auswertung und
die richtige Wiedergabe der realen Welt durch das BIS
• Korrekte Erfassung der Abläufe für die Buchhaltung
• Reine Datenerfassung für die Datenpflege des Systems
Daneben sollte die Anwendung nach Möglichkeit immer über aktuelle Daten
verfügen, damit der Anwender bei seiner Arbeit so gut wie möglich unterstützt
wird und Konflikte weitestgehend vermieden werden.
5.1 Bewertung der einzelnen Möglichkeiten
5.1.1 Komplette oder teilweise Portierung der Geschäftslogik?
Der Umfang der lokalen Geschäftslogik, die auf den mobilen Client portiert wird,
beeinflusst das Design maßgeblich. Er legt implizit die Art der Datensynchronisation fest und welche Daten der Client lokal für den Offline-Fall vorhalten
muss.
Nur wenn die Geschäftslogik komplett portiert wird, kann die Synchronisation
rein datenorientiert (Datenreplikation) erfolgen. Wird sie nur teilweise portiert,
muss es einen Mechanismus geben, der den Server anweist, den nicht portierten
Teil auszuführen.
Durch die komplette Portierung kann das Konfliktpotential gesenkt werden. Die
Prüfung, ob ein Aufruf ausgeführt werden darf oder nicht, kann vollständig auf
dem Client durchgeführt werden. Bei einer nur teilweisen Portierung kann es
passieren, dass die lokale Logik einer Aktion zustimmt, obwohl der Server nach
einer Prüfung nicht zustimmen würde. Im Gegenzug benötigt der Client dafür
aber sehr viele Daten, die er für seine eigentliche Tätigkeit nicht braucht (Protokolldaten, komplette Tabellen anstelle von aggregierten Daten). Das erhöht
den Synchronisationsaufwand und das zu übertragende Datenvolumen13 , sowie
die Komplexität der auszuführenden Logik14 .
Neben den mobilen Clients gibt es weiterhin noch die stationären Clients, die
auf Basis der Webservices arbeiten. Wird deren Geschäftslogik komplett auf die
mobilen Clients portiert, existiert diese zwei Mal und muss damit auch doppelt
entwickelt und getestet werden. Des Weiteren leidet die Wartbarkeit. Ändern
sich Abläufe in einem Geschäftsprozess oder kommen neue hinzu, müssen die
Änderungen immer an zwei Stellen vorgenommen werden.
Aus diesen Gründen erfolgt die Portierung nach dem Prinzip aus Kapitel 4.1.5.
Das ermöglicht eine recht einfache Geschäftslogik unter Nutzung der Funktionsreplikation (dienstorientierte Kommunikation) und Zwischenspeicherung der
13
GPRS bietet zum Beispiel nur eine Übertragungsgeschwindigkeit von maximal 55,6 kbit/s
in der Praxis.
14
Komplexe Datenbankanweisungen können sich schnell zu einem Engpass auf einem mobilen
Gerät entwickeln.
35
eigentlichen Aufrufe. Der Umfang der Daten, die auf dem Client verfügbar sein
müssen, wird durch die Portierung nicht erhöht. Die lokale Logik arbeitet nur
auf den Daten, die der Client auch wirklich braucht und kann diese manipulieren. Zu einem späteren Zeitpunkt wird dann der eigentliche Aufruf und nicht
die geänderten Daten übertragen. Daraufhin kann die Server-Geschäftslogik im
kompletten Umfang ausgeführt werden, inklusive Bedienung der Schnittstellen
zu Fremdsystemen.
Diese Variante bietet zudem den Vorteil, dass sich etwaige Fehler in der lokalen
Geschäftslogik nicht auf das BIS-System auswirken. Zwar bekommt der Anwender zunächst falsche Ergebnisse durch sie geliefert, diese werden aber nicht an
den Server übermittelt und können durch einen späteren Datenabgleich wieder
behoben werden.
5.1.2 Die Warteschlange
Die zuvor beschriebene Kommunikation macht es notwendig, dass WebserviceAufrufe gespeichert werden können, um sie zu einem späteren Zeitpunkt übermitteln zu können. Dabei ist es wichtig, dass die Reihenfolge eingehalten wird,
um Probleme durch logische oder fachliche Abhängigkeiten zu vermeiden. Muss
beispielsweise Aufruf A vor B ausgeführt werden, müssen diese Aufrufe so auch
an den Server übermittelt werden. Ansonsten treten Konflikte auf, die bei Einhaltung der Reihenfolge nicht aufgetreten wären.
Des Weiteren müssen gespeicherte Aufrufe über die Lebenszeit der Anwendung
hinaus erhalten bleiben, sofern sie noch nicht gesendet worden sind. Das bedeutet, dass auch ein Neustart der Anwendung oder ein Absturz des mobilen
Geräts nicht zu einem Datenverlust führen darf. Ansonsten könnte die geleistete
Arbeit nicht dem Server mitgeteilt werden und damit auch nicht protokolliert
und abgerechnet werden.
Um Verwirrungen zu vermeiden, die zwischen einem Disponenten und einem Lokrangierführer auftreten können, wenn ein Aufruf noch nicht vom BIS-System
erfasst worden ist und damit beide über unterschiedliche Daten verfügen, sollte
der Anwender jederzeit in der Lage sein, seine aktuelle Warteschlange einzusehen. Das schafft Klarheit und erhöht die Nutzerakzeptanz.
5.1.3 Die lokale Datenhaltung
Die Speicherung von Daten auf dem mobilen Gerät ist ein wichtiger Bestandteil
der Realisierung einer Offline-Fähigkeit. Dadurch ist es der Anwendung möglich,
den Nutzer auch im verbindungslosen Fall mit Daten zu versorgen. Allerdings
nur, wenn der Umfang genügend groß ist. Ansonsten kann es passieren, das zwar
lokale Daten vorhanden sind, diese aber nicht ausreichen. Andererseits erhöhen
zu viele Daten nur unnötig den Aufwand. Deswegen gilt auch hier wieder die
Maxime: „So viel wie nötig, so wenig wie möglich“.
36
Da sich die Daten relativ häufig ändern können, muss es einen Mechanismus
geben, der die lokalen Daten mit den Server-Daten synchronisiert. Dennoch
kann es passieren, dass der Nutzer Entscheidungen auf der Basis veralteter, und
somit falscher, Daten trifft. Dies muss nach Möglichkeit erkannt werden und ist
Aufgabe des Konfliktmanagements. Um den Bediener nicht von seiner Arbeit
abzulenken, sollte der Abgleich automatisch und im Hintergrund ausgeführt
werden. Kommt es dadurch zu einer Änderung an den Daten, ist der Nutzer
gegebenenfalls darüber in Kenntnis zu setzen.
Damit sich die lokale Datenhaltung nicht als Flaschenhals der mobilen Anwendung entpuppt, muss ein schneller und einfacher Zugriff gewährleistet sein. Je
nach Umfang muss sie mehrere hundert Datensätze exklusive der Stammdaten
aufnehmen können.
Sind diese Dinge gewährleistet, so eröffnet dies neue Arbeitsabläufe in der mobilen Anwendung, die die Arbeit beschleunigen können. Anstelle eines WebserviceAufrufs zum Holen von Daten können diese einfach der lokalen Datenhaltung
entnommen und so die Aufrufzeit15 eingespart werden.
5.1.4 Die lokale Geschäftslogik
Nachdem der Umfang der lokalen Geschäftslogik festgelegt worden ist sollte die
Server-Geschäftslogik so gut wie möglich nachgebaut werden. Dadurch reduziert
sich das Konfliktpotential gegenüber Varianten, bei denen komplett auf die Prüfungen, ob ein Aufruf ausgeführt werden darf, verzichtet wird. Die Prüfungen
werden zwar im Allgemeinen nicht im vollen Umfang realisierbar sein, da der
lokalen Geschäftslogik nicht alle Daten des BIS zur Verfügung stehen, sorgen
aber dennoch für etwas mehr Sicherheit und somit für eine Reduzierung des
Risikos.
Die „vollständige“ Simulation soll auch dafür sorgen, dass es für den Anwender
der mobilen Anwendung anhand der Daten nicht ersichtlich ist, ob ein Aufruf
lokal oder entfernt ausgeführt worden ist. Simulierte Aufrufe müssen inklusive Angabe des Zeitpunkts in die Warteschlange aufgenommen werden, um sie
später an den Server zu senden. Der Original-Aufrufzeitpunkt kann dann vom
Server, beispielsweise für die Protokollierung, ausgewertet werden.
Die Einführung der lokalen Geschäftslogik ermöglicht zudem neue Arbeitsabläufe auf dem Gerät. Auch wenn es über eine Verbindung verfügt können einzelne
Aufrufe zunächst nur simuliert und später gebündelt an den Server übermittelt
werden. Sinnvoll kann diese Vorgehensweise beispielsweise in Bereichen sein, in
denen schnell verschiedene Änderungen vorgenommen werden müssen oder aus
anderen Gründen Zeit gespart werden soll.15
Durch das spätere Senden eines Aufrufs kann es zu Positiv-Falsch-Konflikten
kommen.
15
Im Durchschnitt dauert ein Aufruf mindestens 1 Sekunde (1 Sekunde Sende- und Empfangszeit plus Verarbeitung (meist kaum von Bedeutung)).
37
Positiv-Falsch-Konflikte bezeichnen Probleme, die dadurch entstehen, dass die lokale Logik einen Aufruf erlaubt und ausführt, die
Server-Logik zu einem späteren Zeitpunkt aber feststellt, dass der
Aufruf nicht zulässig war.
In diesem Fall ist es wieder die Aufgabe des Konfliktmanagements den Fehler
zu erkennen und zu beheben.
Eine weitere Gefahr, wie schon im vorherigen Abschnitt erwähnt, besteht darin,
dass der Nutzer aufgrund veralterter Daten handelt und Aktionen deswegen
nicht vollständig oder fehlerhaft ausgeführt werden. Dies wird hier mit dem
Begriff Alt-Daten-Konflikt bezeichnet.
Alt-Daten-Konflikte treten auf, wenn der Nutzer der mobilen Anwendung aufgrund veralteter Daten, die lokal auf dem mobilen Gerät
sind, Anweisungen falsch oder unvollständig ausführt.
Diese Probleme zu finden und zu lösen ist ebenfalls Aufgabe des Konfliktmanagements.
5.1.5 Die Synchronisation
Die nur teilweise Portierung der Geschäftslogik erlaubt eine recht einfache Synchronisation. Die Server-Geschäftslogik ist nach wie vor im vollen Umfang vorhanden und hat im Zweifelsfall immer Recht. Deswegen ist es ausreichend, wenn
der Abgleich unidirektional vom Server auf den Client mit Server-Priorisierung
erfolgt. Das bedeutet, dass der Client die mitgeteilten Änderungen immer ohne Prüfung übernehmen kann und so gegebenenfalls seine eigenen Änderungen
überschreibt. Dadurch werden Konflikte vermieden, eine Konfliktbehandlung
kann entfallen und falsche Daten auf dem Client, verursacht von einer fehlerhaften lokalen Geschäftslogik, werden hinfällig.
Bei der Implementierung des Synchronisationsverfahren muss berücksichtigt
werden, dass die mobilen Geräte im Allgemeinen technisch wesentlich schlechter ausgerüstet sind als der Datenbank- und der Webservice-Server. Aus diesem
Grund sollte die Verarbeitung auf dem Client möglichst einfach sein und vom
Server so gut wie möglich unterstützt werden – auch wenn das mehr Aufwand
für den Server bedeutet. Das gleiche gilt für die Menge der auszutauschenden
Informationen zwischen Client und Server. Da die Verbindung sehr langsam
ist, sollten sie möglichst klein gehalten werden, auch wenn es dadurch zu einer
höheren Belastung des Servers kommt.
Die Haupteinflussgröße auf die auszutauschende Datenmenge (die Synchronisations-Informationen an die Clients) und das Laufzeitverhalten des Algorithmus
für die Differenzbildung hat die Granularität der Differenz. Diese kann beliebig grob- beziehungsweise feingranular sein. Möglich ist die Übertragung einer
kompletten Tabelle, sobald sich ein Eintrag in ihr geändert hat, bis hin zur
38
Übertragung einzelner Zellen, deren Werte sich geändert haben. Allgemein gilt,
dass je grobgranularer die Differenzbildung, desto besser ist das Laufzeitverhalten und desto größer die zu übertragende Datenmenge. Bei der grobgranularen
Variante kann der Vergleich bereits nach der Feststellung nur einer Änderung
abgebrochen werden. Bei dem anderen Extrem muss immer für jede Zelle geprüft
werden, ob eine Änderung stattgefunden hat oder nicht.
Wenn sich zwischen den Synchronisationen nur vereinzelt Datensätze ändern,
sollten feingranulare Verfahren gewählt werden, damit nicht unnötig viele Daten
übertragen werden müssen, die sich gar nicht geändert haben. Je größer der
Änderungsumfang ist, desto grobgranularer kann auch die Differenzbildung sein.
Gemäß der Maxime, die Ressourcen des mobilen Geräts zu schonen und die Datenmenge möglichst klein zu halten – auch wenn es mehr Aufwand für den Server
bedeutet – sollte ein möglichst feingranulares Verfahren bevorzugt werden, das
nur zellenweise Änderungen überträgt. Viele Änderungen im BIS beziehen sich
nur auf Teile einzelner Spalten. Würden die kompletten Datensätze dieser geänderten Spalten übertragen werden, wären darunter sehr viele Informationen,
über die der Client schon verfügt und damit wertlos für ihn sind.
5.1.6 Aufbau der Synchronisations-Nachrichten
Der Aufbau der Synchronisations-Nachrichten ist eng mit dem eingesetzten Synchronisationsverfahren verzahnt und sollte daran angepasst sein. Generell gibt
es im BIS drei verschiedene Varianten, wie Daten übertragen werden können:
mit einer homogenen Wertetabelle, mit einer inhomogenen Wertetabelle oder
mit einzelnen Datensätzen.
In der homogenen Wertetabelle hat jeder Datensatz/jede Zeile die gleichen Spalten. Vorteil dieser Tabelle ist, dass die Beschreibung (Spaltenname, Typen der
Spalten) pro Tabelle nur einmal übertragen werden müssen. Dafür muss aber
auch für jeden Datensatz jeder Spaltenwert übertragen werden.
In der inhomogenen Variante kann jeder Datensatz über unterschiedliche Spalten verfügen. Für jede Spalten-Kombination muss deswegen eine Beschreibung
übermittelt werden. Im Gegenzug enthält die Tabelle dafür aber auch nur noch
Werte, die auch von Interesse sind.
Verwandt zu dieser Variante ist die Übertragung einzelner Datensätze. Allerdings ist hier für jeden Datensatz eine eigene Beschreibung notwendig und nicht
nur für jede Spaltenkombination. Weil allgemein gilt, dass
|Beschreibungen Datensätze|
≥
|Beschreibungen Spaltenkombinationen|
und
|Informationen Datensätze|
=
|Informationen inhomogene Wertetabelle|
ist für diesen Anwendungsfall eine inhomogene Wertetabelle gegenüber einzelnen
Datensätzen vorzuziehen.
39
S1
...
...
...
...
S2
...
...
...
...
W1
...
...
...
...
W2
...
...
...
...
...
...
...
...
...
Tabelle 1: Homogene Wertetabelle
mit kompletten Daten
S1
...
...
...
...
S2
...
...
...
...
Spalte
...
...
...
...
Wert
...
...
...
...
Tabelle 3: Jede Änderung einzeln
S1
...
...
...
...
S2
...
...
...
...
W1
...
W2
...
...
...
...
...
...
...
Tabelle 2: Homogene Wertetabelle
mit lückenhaften Daten
S1
...
S2
...
W1
...
S1
...
S2
...
W1
...
W2
...
...
...
Tabelle 4: Inhomogene Wertetabelle
Si . . . Schlüsselspalte i
Wj . . . Wertspalte j
Zudem können in einem Container beliebige Wertetabellen und Datensätze aufgenommen und in einer Nachricht übertragen werden. Daraus ergeben sich mehrere Möglichkeiten, wie die Änderungsdaten der Synchronisation an den Client
übermittelt werden können. Die Tabellen 1-4 illustrieren vier grundsätzliche
Möglichkeiten.
Die Übertragung der Daten mittels einer homogenen Wertetabelle, die die kompletten Daten beinhaltet (Tabelle 1), bietet zwar die Vorteile, dass sie sich sehr
einfach auf der Client-Seite verarbeiten lässt und der Schlüssel bei vielen Änderungen nur einmal übertragen werden muss. Der Nachteil ist allerdings, dass
auch bei Änderungen in nur einer Spalte die komplette Zeile übertragen werden
muss. Da die Änderungsinformationen aber zellenweise berechnet werden sollen, ist diese Art der Kodierung nicht praktikabel und würde die aufwendigere
Berechung der Differenz zunichte machen.
Verbessern kann man die Verwendung der homogenen Wertetabelle, indem nur
Werte in Zellen eingetragen werden, die auf dem Client geändert werden sollen, wie Tabelle 2 illustriert. Hierbei werden keine überflüssigen Daten mehr
übertragen. Allerdings kann diese Tabelle nicht mehr so einfach auf dem Client
verarbeitet werden. Dieser muss nun jede Zeile durchlaufen und prüfen, welche
Zelle einen Eintrag hat, der übernommen werden muss. Zusätzlich muss unterschieden werden können, ob ein Eintrag in einer Zelle fehlt, weil es dort keine
Änderung gibt, oder aber, weil der neue Wert Nichts (Leerstring, Null) ist und
er von dem Client übernommen werden muss.
40
Denkbar ist auch eine Lösung, bei der jede Änderung einzeln übertragen wird,
wie Tabelle 3 zeigt. Die Spalte Spalte beinhaltet den Namen von dem Eintrag,
der mit Wert überschrieben werden soll. Für jede einzelne Änderung muss der
zugehörige Schlüssel übertragen werden. Das hat zur Folge, dass bei n Änderungen in einem Datensatz der Schlüssel n-mal in der Tabelle enthalten ist.
Sind mehrere Werte in einer Spalte geändert worden, ist zusätzlich auch die
Spaltenbeschreibung mehrfach vorhanden.
Bei der vierten Variante werden die Daten als inhomogene Wertetabelle (siehe Tabelle 4) übertragen. Allerdings ist auch diese Variante relativ aufwendig
auf dem Client zu verarbeiten, da für jede inhomogene Struktur erst ermittelt
werden muss, welche Spalten darin enthalten sind. Des Weiteren muss für jede einzelne Struktur deren Beschreibung extra übertragen werden. Dafür bietet
diese Möglichkeit eine recht kompakte Darstellungsform.
Von den vier vorgestellten Varianten scheint die zweite den besten Kompromiss
darzustellen. Der Verarbeitungsaufwand für den mobilen Client ist zwar höher
als bei der ersten Variante, aber kleiner als bei der vierten. Dafür enthält sie nur
die wirklich relevanten Informationen, wie auch drei und vier. Möglichkeit drei
kommt wegen des eventuell mehrfachen Auftretens eines Schlüssels oder einer
Spaltenbeschreibung nicht in Frage.
5.1.7 Das Konfliktmanagement
Das Konfliktmanagement muss dafür sorgen, dass möglichst alle auftretenden
Probleme, besonders die Positiv-Negativ-Konflikte und die Alt-Daten-Konflikte,
vor der eigentlichen Ausführung des Aufrufs auf dem Server erkannt und behoben werden. Ein weiteres Problem ist zum Beispiel das mehrfache Empfangen
des gleichen Aufrufs, weil die entsprechende Antwort des Servers nicht beim
Client angekommen ist und dieser daraufhin den Aufruf erneut sendet.
Für die Erkennung von Konflikten muss das Management häufig wissen, auf welcher Datengrundlage der Aufruf vom Anwender des mobilen Geräts überhaupt
ausgeführt worden ist und wie der Datenbestand zur Prüfzeit auf dem Server
ist. Dies kann auf unterschiedliche Art und Weise sichergestellt werden. Entweder werden den Aufrufen zusätzliche Parameter übergeben, die alle relevanten
Client-Daten enthalten oder der Server kennt von sich heraus den Zustand des
Clients zum Aufrufzeitpunkt. Die erste Variante hat den Nachteil, dass durch
die zusätzlichen Parameter eine größere Datenmenge übertragen werden muss,
deswegen ist die zweite Art vorzuziehen.
Aus der Differenz dieser beiden Datenmengen können im Zusammenhang mit
dem Aufruf Konflikte erkannt werden. Fehlt eine der beiden Informationen, ist
eine Erkennung, beispielsweise von Positiv-Negativ- und Alt-Daten-Konflikten,
nicht möglich.
Die Konfliktbehebung muss fachlich fundiert erfolgen und nicht durch Ignoranz
des problemverursachenden Aufrufs. Der Grund dafür ist, dass dieser Aufruf
41
zum Eintreffzeitpunkt auf dem Server bereits durch den Anwender der mobilen
Anwendung in die Realität umgesetzt worden ist. Würde man das ignorieren,
kommt es zu einer Verzerrung des Abbilds der realen Welt im BIS. Zudem sind
auch „falsch“ erbrachte Leistungen Leistungen, die eventuell abgerechnet und
protokolliert werden müssen.
Sollte eine automatische Konfliktlösung nicht möglich sein, sind die stationären
Clients anstelle des mobilen Clients darüber zu informieren. Dieser ist zwar der
eigentliche Konfliktverursacher, aber die stationären Clients verfügen über einen
viel größeren Funktionsumfang und damit auch über mehr Möglichkeiten, den
Konflikt manuell zu lösen.
Die Umsetzung kann in verschiedenen Varianten erfolgen. In der ersten besteht
das Konfliktmanagement aus einem Teil, der die Erkennung und Lösung in einer
Funktion zusammenfasst. Das ist zwar relativ kompakt, kann aber bei komplexen Prüf- oder Lösungsfunktionen schnell unübersichtlich werden.
In der zweiten Variante sind die Erkennung und die Lösung voneinander getrennt. Das ermöglicht ein iteratives Konfliktmanagement, wie es in Algorithmus 1 skizziert ist. Dadurch wird die Wartbarkeit der Anwendung unterstützt.
Weitere Prüffunktionen können ohne Probleme und ohne Rücksicht auf die Behebung übernommen werden und umgekehrt.
Eingabe : Aufruf
iterationsanzahl = 2;
i = 0;
solange i < iterationsanzahl tue
i++;
wenn ! AufrufIstKonfliktfrei(Aufruf ) dann
LöseKonflikt(Aufruf );
wenn AufrufIstKonfliktfrei(Aufruf ) dann
Ergebnis = ”Ok”;
Ende
Ende
Ende
wenn Ergebnis == ”Ok” dann
Ergebnis = StarteAufruf(Aufruf );
Ende
sonst
Ergebnis = ”Konflikt”;
Ende
Ausgabe : Ergebnis
Algorithmus 1 : Ablauf des serverseitigen Konfliktmanagements
42
5.2 Umfang der zu portierenden Geschäftslogik und Daten
Bevor das Konzept umgesetzt werden kann, muss nach Kapitel 4.1.3 noch der
Umfang der zu portierenden Funktionen festgelegt werden. Nicht alle Funktionen sind dafür geeignet oder wichtig. Wie in Kapitel 5 bereits erwähnt erfüllen
die Aufrufe unterschiedliche Funktionen und können deshalb womöglich nicht
alle gleich behandelt werden. Es gibt Aufrufe, die sofort abgesetzt werden müssen, andere können hingegen auch später an den Server gesendet werden. Manche
dienen nur der Informationsbeschaffung, während einige zu Statusänderungen
im BIS führen. Deswegen beschäftigt sich der nachfolgende Unterabschnitt mit
der Untersuchung der einzelnen Aufrufe, um Rückschlüsse ziehen zu können,
welche Funktionen auch offline verfügbar sein sollten.
Beispielsweise kann nicht jeder Aufruf kann durch eine lokale Geschäftslogik
simuliert werden und nicht jedes Datum ist sinnvoll in der lokalen Datenhaltung
aufgehoben.
5.2.1 Analyse der Webservice-Aufrufe und Datenstrukturen
Eine sehr grobe Kategorisierung der Aufrufe ist die Einteilung nach der Auswirkung im BIS. Aufrufe der ersten Kategorie dienen der reinen Informationsbeschaffung. Die zweite Kategorie besteht aus Aufrufen, die Daten im BIS manipulieren. Diese grobe Aufteilung alleine ist aber noch nicht ausreichend, es
müssen noch weitere Eigenschaften bewertet werden.
Die Tabelle 5 listet alle möglichen Aufrufe einzeln auf, sortiert sie in die zwei
Kategorien ein und bewertet deren Charakteristika. Dazu zählen, ob ein Aufruf zeitkritisch ist, ob er wichtig für das BIS oder moBIS ist, wie hoch die
Änderungs- beziehungsweise Aufrufrate ist und ob der Aufruf zu einer Rückfrage führen kann.
Die Spalte Zeitkritisch ist gesetzt, wenn der Aufruf sofort nach Ausführung an
den Server übermittelt werden muss und nicht später gesendet werden darf. Dies
ist bei Aufrufen der Fall, die eine Suchfunktion erfüllen. Hier würde es keinen
Sinn machen, wenn das Ergebnis erst später bei dem Suchenden eintrifft. Das
ist ähnlich wie bei einer Suchmaschine für das Internet, hier soll das Suchergebnis auch möglichst schnell vorliegen. Auch wenn der Aufruf zu wichtigen
Statusänderungen im BIS führt, die sofort bekannt gegeben werden müssen, um
ein effizientes Arbeiten nicht zu gefährden, ist der Aufruf zeitkritisch. Solche
Aufrufe eignen sich demnach nicht für die Portierung auf den mobilen Client.
Ist die Spalte muss BIS gesetzt, nimmt der Aufruf Änderungen an den Daten im
BIS vor. Aus diesem Grund muss der Aufruf an den Server übermittelt werden,
um dort ausgeführt zu werden. Die Ausführung nur der lokalen Logik hat keinen
Einfluss auf die Daten im BIS. Die Spalte gibt aber keine Auskunft über den
Übermittlungszeitpunkt des Aufrufs. Aufrufe dieser Art müssen, sofern sie nicht
sofort gesendet werden können, zu einem späteren Zeitpunkt übertragen werden.
43
Gegenteilig in der Bedeutung ist ein Eintrag in der Spalte muss moBIS. Dieser
gibt an, dass der Aufruf für die Weiterarbeit der mobilen Anwendung wichtig
ist, aber keine Auswirkung auf das BIS hat. Das Holen von Daten, die für
die eigentliche Aufgabenerfüllung wichtig sind, ist ein typisches Beispiel. Ohne
diese Daten kann der Nutzer der mobilen Anwendung nicht arbeiten, weil er
nicht weiß, was er zu tun hat. Hingegen ist es für das BIS-System unwichtig,
wer auf welche Daten lesend zugreift. Damit ist die Spalte muss moBIS ein
guter Indikator für die Wichtigkeit der Daten und dafür, ob diese im OfflineFall verfügbar sein müssen oder nicht.
Ein weiterer wichtiger Indikator ist die Änderungsrate der zugrunde liegenden
Daten. Einige Daten ändern sich im Durchschnitt minütlich, andere hingegen
täglich und manche nie. Daten, die sich nur sehr selten bis gar nicht ändern sind
eher in dem Bereich Stammdaten anzusiedeln, da diese nicht der regelmäßigen
Synchronisation unterliegen.
Für Aufrufe der zweiten Kategorie gibt die Spalte Änderungsrate an, wie häufig dieser Aufruf im Durchschnitt genutzt wird und sich damit die zugrunde
liegenden Daten ändern. Die Häufigkeit der Nutzung ist ein Indiz für deren
Wichtigkeit. Wichtige Funktionen sollten nach Möglichkeit auch im Offline-Fall
zur Verfügung stehen und damit auf den mobilen Client portiert werden.
Für Aufrufe der zweiten Kategorie kann zusätzlich noch die Spalte Rückfrage
gesetzt sein. Diese Aufrufe können bei Problemen oder Unklarheiten den Aufrufenden fragen, wie das Problem gelöst werden soll, anstatt den Aufruf gleich
abzulehnen. Tendenziell sind Aufrufe dieser Art für eine Offline-Tätigkeit eher
ungeeignet, da sonst, wenn der Aufruf erst später an den Server gesendet werden
kann, Rückfragen zu Abläufen gestellt werden können, die der Anwender schon
durchgeführt hat.
44
Aufruf
Kategorie
1
2
3
4
5
6
RA-Liste holen
RA-Positionen holen
Gleise im Bereich
Wagen auf Gleis-Nr.
Wagensuche
Wagendaten
1
1
1
1
1
1
7
Wagendaten Gleis
1
8
9
10
11
Eingangszüge holen
Wagen zu einem EZ
Einsatzbereite Loks
Nutzernamen
1
1
1
1
12
13
Gleisliste
Wartegründe
1
1
14
Gutartenliste
1
15
Dienststelle EZ
1
16
Dienststellengleise
1
Zeitkritisch
muss
BIS
muss
moBIS
√
√
√
√
√
√
√
Änderungsrate
•••
••
◦
•••
••
••
••
√
√
√
√
•
•
•
◦
√
◦
√
√
√
Rückfrage
Bemerkung
Alle Wagen zu einem RA
Sucht aufgrund best. Kriterien
Ermittelt Details zu einem Wagen
Details zu allen Wagen auf dem
Gleis
Ermittelt alle Eingangszüge
Alle Wagen eines Eingangszug
Ermittelt alle Loks, die frei sind
Aller Nutzer, die sich anmelden
dürfen
Liste aller verfügbaren Gleise
Vordefinierte Phrasen für Begründungen
Enthält Übersetzung von Kode
→ Text
Dienststellen, in deren Bereich
Eingangszüge einfahren können
Zu einer Dienststelle zugeordnete Gleise
Fortsetzung nächste Seite
Nr.
45
46
Nr.
Aufruf
Kategorie
Umsetzen angest. Wagen
RAs zusammenfassen
2
2
19
Wagenreihung ändern
2
20
Wagenreihung drehen
2
21
Zielgleis ändern
2
22
Wagen entfernen
2
23
Wagen hinzufügen
2
24
25
26
27
Beginnen RA
Erledigen RA
Teilerledigen RA
Löschen RA
2
2
2
2
28
RA unterbrechen
2
muss
BIS
√
√
√
√
√
√
√
√
√
√
√
/√
/√
/√
/-
√
√
√
√
√
√
/-
muss
moBIS
Änderungsrate
•
•
Rückfrage
√
•
•
•
√
•
•
••
••
••
•
•
√
√
Bemerkung
Zwei Rangieraufträge zusammenfassen
Status des RA muss 6= „Transport“ sein
Ändert Zielgleis eines Wagen im
RA, Status des RA muss 6=
„Transport“ sein
Entfernt eine Wagen aus einem
RA, Status des RA muss 6=
RA wird ein Wagen hinzugefügt, Status des RA muss 6=
Status auf „Transport“
Beendet Rangierauftrag
Einzelne Wagen beenden
Status des RA muss „Transport“
sein
17
18
Zeitkritisch
√
√
Kategorie
Aufruf
29
30
31
RA bilden
Eingangszug teilen
EZ umsetzen
2
2
2
32
Eingangszug geprüft
2
33
Eingangszug zerlegt
2
34
35
36
Ankunftsmeldung erfassen
Sonderzug erfassen
Wagenreihung Sonderzug
2
2
2
Zeitkritisch
√
/√
muss
BIS
√
√
√
√
√
√
√
√
√
muss
moBIS
Änderungsrate
•
•
•
••
••
••
•
•
Rückfrage
√
√
Bemerkung
Bildet neuen Rangierauftrag
Teilt einen Eingangszug
Korrigiert das Standortgleis eines Eingangszug
Status des Eingangszug auf „geprüft“
Status des Eingangszug auf „zerlegt“
Erfassen der Wagen eines Sonderzugs
Tabelle 5: Einordnung der Funktionen des Webservice für den mobilen Client
◦. . . sehr niedrige Änderungsrate, nur selten genutzt
•. . . niedrige Änderungsrate, kaum genutzt
••. . . mittlere Änderungsrate, hin und wieder genutzt (stündlich)
• • •. . . hohe Änderungsrate, oft genutzt (minütlich)
√
. . . Ja, Rückfrage möglich
√
/-. . . Je nach Bereich und Kunde ja oder nein
RA. . . Rangierauftrag
EZ. . . Eingangszug
Nr.
47
5.2.2 Auswertung der Analyse
Viele Aufrufe der ersten Kategorie sind wichtig für die Arbeit des mobilen Clients (siehe Spalte muss moBIS ) und unterscheiden sich nur in der Änderungsrate. Bei den Aufrufen 3 und 11 bis 16 liegt diese bei Null bis sehr klein. Das heißt,
dass man diese Daten dauerhaft auf dem Gerät verfügbar machen kann, ohne
sich um die Synchronisation zu sorgen. Dies ist bei dem derzeit vorliegenden
moBIS auch der Fall und in Kapitel 2.1 als Stammdaten bezeichnet worden.
Die Daten der restlichen Aufrufe sollten in die lokale Datenhaltung aufgenommen und regelmäßig synchronisiert werden. Sinnvollerweise holen diese Aufrufe deswegen nicht mehr direkt die Daten ab, sondern stoßen stattdessen die
Synchronisation an. Diese Aufrufe werden zukünftig als Daten-Offline-Aufruf
bezeichnet. Ausnahmen bilden die Aufrufe 5-7. Diese besitzen eher einen SuchCharakter und müssen demnach sofort ausgeführt werden. Aus diesem Grund ist
eine Aufnahme in die lokale Datenhaltung wenig sinnvoll, sie gehören demnach
der Kategorie Daten-Online-Aufruf an.
Die Aufrufe der zweiten Kategorie müssen etwas genauer untersucht werden.
Generell gilt jedoch für alle, dass jeder Aufruf im BIS ausgeführt werden muss,
somit eine alleinige Ausführung auf dem mobilen Gerät nicht ausreicht.
Große Unterschiede gibt es jedoch in der Spalte Zeitkritisch. Die Aufrufe 17 bis
23, 31 und 35 müssen auf jeden Fall sofort ausgeführt werden. Das heißt, diese
Aufrufe brauchen nicht in die lokale Geschäftslogik mit aufgenommen werden,
da eine Einreihung in die Warteschlange, und damit ein späteres senden, nicht
möglich ist. Im weiteren Verlauf werden diese Aufrufe mit Änderung-Online
bezeichnet.
Gegensätzliche Eigenschaften besitzen die Aufrufe 19, 20, 32 bis 34 und 36. Hier
ist es auch möglich, dass der Aufruf erst auf dem Client simuliert und zu einem
späteren Zeitpunkt an den Server übermittelt wird. Ob diese jedoch im vollen
Umfang portiert werden oder nur einzelne von ihnen, hängt von dem Portierungsaufwand und der Aufrufhäufigkeit ab. Gemäß des Bennenungsschematas
erhalten sie den Namen Änderung-Offline.
Interessant sind die noch nicht näher betrachteten Aufrufe. Hier hängt es von
dem speziellen Einsatzgebiet ab, ob nur Änderung-Online möglich ist oder auch
eine Offline-Ausführung. Erfolgt so ein Aufruf in einem sehr zeitkritischen Bereich, muss dieser sofort erfolgen. In anderen Bereich hingegen ist es nicht so
wichtig, ob ein Aufruf minutengenau oder erst eine halbe Stunden später im
System eintrifft. Deswegen muss im Offline-Fall der Nutzer entscheiden, wie mit
diesem Aufruf zu verfahren ist. Demnach werden sie auch mit Änderung-NutzerEntscheidung bezeichnet.
Zusammengefasst hat die Analyse fünf unterschiedliche Arten von Aufrufen ergeben, die nochmals kurz aufgelistet werden:
• Daten-Online: Aufruf ist sofort auszuführen, keine Statusänderungen im
BIS
48
6 Die Lösung
• Daten-Offline: Aufruf kann später ausgeführt werden, startet die Synchronisation, keine Statusänderungen im BIS
• Änderung-Online: Aufruf ist sofort auszuführen, Statusänderungen im BIS
• Änderung-Offline: Aufruf kann später ausgeführt werden, Simulation durch
die lokale Geschäftslogik, Statusänderungen im BIS
• Änderung-Nutzer-Entscheidung: Der Nutzer muss entscheiden, ob Änderung-Online oder Änderung-Offline
6 Die Lösung
Dieser Abschnitt beschreibt die konkrete Umsetzung der in Kapitel 5 dargelegten
Lösungen unter Berücksichtigung der dort gestellten Anforderungen. Daneben
müssen noch die allgemeinen Anforderungen berücksichtig werden. Die Lösung
muss möglichst flexibel und wartbar sein, um sie leicht an die verschiedenen
Kundenwünsche anpassen zu können. Zudem muss sie möglichst unabhängig
von der Umgebung, in der sie eingesetzt wird, sein. Die Schnittstellen müssen
klar definiert und die einzelnen Komponenten der Lösung möglichst unabhängig voneinander sein. Dabei soll die mobile Anwendung in ihrer jetzigen Form
weitgehend erhalten bleiben, um den Realisierungsaufwand nicht noch weiter zu
erhöhen. Das Ergebnis soll ein Anwendung sein, die auch offline nutzbar ist.
6.1 Die Entwicklungsumgebung
Bei den mobilen Endgeräten handelt es sich um recadized PDAs von Symbol.
Gewöhnlich kommen nicht mehr als zehn bis 15 Geräte pro Kunde parallel zum
Einsatz, so dass die Implementierung den Aspekt der Skalierbarkeit erst einmal
außen vor lassen kann.
Das Client-Betriebssystem ist Windows Mobile 5.0. Die Client-Anwendung ist
in C# mit Visual Studio 2005 und dem OpenNet Compact Framework (weiter)entwickelt worden. Auf der Server-Seite ist der Webservice in Java 5.0 geschrieben. Ausgeführt wird dieser in Apache Tomcat. Als Entwicklungsplattform dient
hier Eclipse. Auf dem mobilen Endgerät kommt die SQL CE-Datenbank von
Microsoft zum Einsatz. Auf der Server-Seite sind entweder Oracle- oder IngresSysteme vorhanden.
6.2 Die Implementierung
Gemäß Kapitel 4.1.2 ist die neue Funktionalität für die Offline-Fähigkeit in
einem extra Modul enthalten, auf das die bisherige Anwendung aufsetzt. Ein
Agent übernimmt die Auswertung der Aufrufe gemäß Kapitel 5.2.2 und handelt
dementsprechend. Dadurch sind die alte Anwendung und die Erweiterung klar
voneinander getrennt und die bisherige Anwendung muss kaum geändert werden.
49
6 Die Lösung
Serverseitig müssen die vorhandenen Webservices um das Konfliktmanagement
erweitert und Funktionen für die Synchronisation realisiert werden. Damit ergibt
sich die Architektur, wie sie in Abbildung 10 und 11 dargestellt ist.
Abbildung 10: Die einzelnen Schichten der Client-Seite (die blauen Schichten
sind neu)
Abbildung 11: Die einzelnen Schichten der Server-Seite (die blauen Schichten
sind neu, die beiden Datenbanken sind nur aus Visualisierungsgründen voneinander getrennt)
Der Agent ist das Kernstück der Erweiterung auf der Client-Seite. Dieser nimmt
alle Aufrufe des Anwenders entgegen und handelt entsprechend ihrer Eigenschaften. Unterstützt wird dieser durch die Warteschlange und die lokale BIS-Logik.
Die Synchronisation wird benötigt, um den Datenbestand auf dem Client aktuell
zu halten. Neben dieser Erweiterung auf dem Server gibt es noch das Konfliktmanagement. Dieses ist nötig, um Probleme zu beheben, die durch das zeitlich
versetzte Senden von Aufrufen an den Server entstehen können.
6.2.1 Die Organisation des Clients
Um die Implementierung so einfach wie möglich zu machen, sind die einzelnen
Aufrufe nochmals näher analysiert worden. Dies hat ergeben, dass es keinen Aufruf gibt, der im Bereich der Eingangszugbehandlung und des Rangierens gleichermaßen zum Einsatz kommt. Folglich unterscheiden sich auch die zugrunde
liegenden Daten dieser beiden Bereiche. Des Weiteren ist es so, dass viele Aufrufe
50
6 Die Lösung
aus einem Bereich immer das gleiche Ergebnis liefern. Im Bereich des Rangierens sind dies entweder eine Liste aus aktuellen Rangieraufträgen oder eine Liste
mit Positionen eines Rangierauftrags. Im Bereich der Eingangszugbehandlung
wird hingen eine Liste von Zügen oder die Wagenliste eines bestimmten Zugs
benötigt.
Das heißt aber auch, dass es für die lokale Geschäftslogik in den meisten Fällen
ausreicht, wenn lediglich diese angesprochenen Daten auf dem mobilen Client
verfügbar gemacht werden. Des Weiteren ist es so, dass die Lokrangierführer
nur sehr selten bis gar nicht den Arbeitsbereich während einer Dienstschicht
wechseln. Zudem ist es so, dass (fast) immer beide Teile der Daten aus einem
Bereich benötigt werden. Nur sehr selten wird die Liste der Rangieraufträge
ohne die Liste der Positionen gebraucht.
Diese Überlegungen führen zu der Einführung sogenannter Prozessmodelle (PM).
Ein Prozessmodell beschreibt einen kompletten Bereich bestehend
aus den drei Teilen:
• Daten
• Webservice-Aufrufe
• Lokale Geschäftslogik
Der Begriff Daten beschreibt die Datenstrukturen, die zu einem bestimmten
Prozessmodell gehören und auch lokal vorgehalten werden müssen, damit die
Offline-Fähigkeit gewährleistet ist. Die Webservice-Aufrufe umfassen alle Aufrufe, die zu einem Prozessmodell gehören und auf den beschriebenen Datenstrukturen arbeiten. Die lokale Geschäftslogik dient der Simulation eines Aufrufs.
Sind alle Bestandteile eines bestimmten Prozessmodells vorhanden, so ist die
zugehörige Anwendung in der Lage auch im Offline-Fall die darin beschriebenen
Funktionen zu gewährleisten. Zunächst reichen zwei Prozessmodelle aus, um ein
Arbeiten im verbindungslosen Fall zu gewährleisten. Dies sind die Prozessmodelle Rangieren und Eingangszugbehandlung.
Neben denen in einem Prozessmodell erfassten Funktionen gibt es noch weitere, die mit anderen Datenstrukturen als denen im Prozessmodell beschriebenen
arbeiten. Hierbei handelt es sich jedoch durchweg um Aufrufe, die lediglich der
Informationsbeschaffung dienen und nur online ausgeführt sinnvoll sind (DatenOnline). Aus diesem Grund muss für diese Aufrufe auch keine lokale Datenhaltung vorhanden sein.
Durch die Schaffung der Prozessmodelle wird die Datenverwaltung vereinfacht.
Wie eingangs schon erwähnt werden in der Regel alle Datenstrukturen eines
Prozessmodells benötigt. Aus diesem Grund werden nicht die einzelne Teile der
Datenstrukturen synchronisiert, sondern immer das gesamte Prozessmodell, in
dem der Nutzer gerade arbeitet.
Im Normalfall wechselt der Lokrangierführer nicht nur selten seinen Arbeitsbereich, sondern auch die Lok, die er nutzt oder die Betriebsstelle, deren Eingangs51
6 Die Lösung
züge er behandelt. Je nach Arbeitsbereich reduziert das die zu synchronisierende
Datenmenge auf alle Daten im Zusammenhang mit einer bestimmten Lok oder
Betriebsstelle.
6.2.2 Der Agent
Der Agent ist die zentrale Komponente der Erweiterung und für das Anstoßen der Synchronisation und der korrekten Verarbeitung der einzelnen Aufrufe
gemäß ihren Eigenschaften verantwortlich. Jeder Aufruf der mobilen Anwendung wird an den Agenten weitergeleitet und dort entsprechend verarbeitet.
Die Eigenschaften eines Aufrufs definiert der AufrufManager. Dieser kennt alle
möglichen Aufrufe und legt für jeden das zugehörige Prozessmodell, die Namen
der Parameter und sofern vorhanden, die entsprechende Funktion in der lokalen
Geschäftslogik fest.
Damit der Agent arbeiten kann, benötigt er noch ein paar Hilfsklassen. Der
OnlineManager stellt fest, ob das Gerät gerade über eine Verbindung verfügt
oder nicht und kann das Leeren der Warteschlange anstoßen (Kapitel 6.2.3).
Die WSSchnittstelle ist die Schnittstelle zum Netzwerk und bietet Funktionen
zum Senden und Empfangen von Nachrichten an. Der AgentSpeicher wird für
die Zwischenspeicherung von Ergebnissen genutzt, um diese zu einem späteren
Zeitpunkt zur Verfügung zu stellen.
Die grobe Arbeitsweise sieht wie folgt aus:
• Daten-Online: Senden des Aufrufs wenn online, sonst Offline-Fehler
• Daten-Offline: Synchronisation des entsprechenden Prozessmodells wenn
online, sonst Offline-Status melden
• Änderung-Online: Senden des Aufrufs, anschließend Synchronisation des
Prozessmodells wenn online, sonst Offline-Fehler
• Änderung-Offline: wie Änderung-Online wenn online, sonst Ausführung
lokale Geschäftslogik, Aufruf einreihen, Offline-Status melden
• Änderung-Nutzer-Entscheidung: je nach Entscheidung Änderung-Online
oder Änderung-Offline
Detailliert stellt das Sequenzdiagramm in Abbildung 12 und das Flussdiagramm
in Abbildung 13 die Verarbeitung in dem Agenten dar.
Aus Gründen der Vereinfachung fehlt auch in diesen Diagrammen die Aufforderung zum Leeren der Warteschlange. Dies geschieht gemäß Beschreibung in
Kapitel 6.2.3 immer vor der Verarbeitung des eigentlichen Aufrufs. Erst nach
einer erfolgreichen Leerung beginnt der Agent mit der Verarbeitung des Aufrufs.
Der Agent selbst gibt keine Daten an den Aufrufenden (die DialogHandler,
siehe Abbildung 10) zurück, sondern nur Status-Kodes. Daraufhin kann dieser
52
6 Die Lösung
53
Abbildung 12: Sequenzdiagramm, welches den Ablauf im Agenten darstellt
6 Die Lösung
Abbildung 13: Flussdiagramm, dass die Verarbeitung eines Aufrufs im Agenten
darstellt
54
6 Die Lösung
entscheiden, ob die Oberfläche neue Daten anzeigen soll. Das Szenario zum
Holen einer Rangierauftragsliste kann so ablaufen:
1. Nutzer löst Aktion zum Holen der RA-Liste aus
2. DialogHandler informiert Agenten
3. OnlineManager meldet, dass das Gerät verbunden ist
4. AufrufManager teilt mit, dass es ein Daten-Offline-Aufruf ist
5. Agent führt die Synchronisation für das Prozessmodell „Rangieren“ aus
6. Agent informiert DialogHandler über die erfolgreiche Ausführung
7. DialogHandler entnimmt die aktuellen Rangieraufträge der lokalen Datenhaltung und übergibt sie der Oberfläche
Über den Status-Kode weis der DialogHandler auch, ob der Aufruf offline oder
online ausgeführt worden ist. Da bei einer Offline-Ausführung immer die Gefahr
durch veraltete Daten besteht, wird der Anwender durch eine gelbe Hintergrundfarbe über einen offline ausgeführten Aufruf informiert.
Die Ergebnisse der Daten-Online-Aufrufe werden nicht wie bei der Synchronisation in die lokale Datenbank geschrieben, sondern im Hauptspeicher gehalten
und vom AgentSpeicher verwaltet. Diese Daten sind nur für den Augenblick
des Aufrufs interessant und müssen deswegen nicht persistent sein. Das erhöht
die Zugriffsgeschwindigkeit auf diese Daten, da auf den Hauptspeicher schneller
zugegriffen werden kann als auf die Datenbank.
Der Agent ist in seinem Verhalten konfigurierbar (siehe Listing 5). Es kann
festgelegt werden, ob bei jedem Daten-Online-Aufruf und/oder nach jedem Änderung-Online-Aufruf die Synchronisation ausgeführt werden soll. Im Zusammenhang mit der automatischen Synchronisation können so die in Kapitel 5.1.3
und 5.1.4 vorgeschlagenen Optimierungen umgesetzt werden.
6.2.3 Die Warteschlange
Die Warteschlange nimmt die Aufrufe auf, die zurzeit nicht an den Server gesendet werden können oder sollen. Dies sind zum einen die Empfangsbestätigung
der Synchronisation, alle Offline-Aufrufe, sowie Aufrufe, die aufgrund einer Nutzerentscheidung offline ausgeführt werden dürfen.
Bei dem Hinzufügen eines Aufrufs zu der Warteschlange merkt sich diese den
Aufruf, dessen Parameter und zusätzlich noch den Zeitpunkt. Über den Zeitpunkt wird beim Auslesen sichergestellt, dass die Reihenfolge der Aufrufe erhalten bleibt, sofern die Uhr des mobilen Geräts immer richtig arbeitet. Zusätzlich
wird neben den eigentlichen Parametern noch der Original-Zeitpunkt des Aufrufs an den Server gesendet, um ihn beispielsweise für die Protokollierung nutzen
zu können.
55
6 Die Lösung
Daneben enthält jeder Aufruf in der Warteschlange noch eine Priorität. Diese
wird genutzt, um eine etwaig einzureihende Synchronisations-Bestätigung hoch
zu priorisieren, damit sichergestellt ist, dass diese auf jeden Fall als erste aus der
Warteschlange entnommen wird. Dies ist wichtig für die korrekte Arbeitsweise
der Synchronisation und des Konfliktmanagements.
Die Warteschlange selbst wird in einer Datenbank verwaltet, um zu gewährleisten, dass ihr Inhalt auch nach einem Neustart der Anwendung noch zur
Verfügung steht.
Die Leerung der Warteschlange erfolgt immer automatisch vor jedem Absetzen
eines Aufrufs an den Webservice und wird durch den Agenten angestoßen. So
ist sichergestellt, dass die zeitlich zuvor erfolgten, eingereihten Aufrufe vor dem
neuen Aufruf an den Server gesendet werden. Kommt es während der Leerung
zu einem Problem wird diese und der auslösende Aufruf abgebrochen.
Abbildung 14: Sequenzdiagramm über das Leeren der Warteschlange mit einem
Element
Wie aus dem Sequenzdiagramm in Abbildung 14 ersichtlich ist, kann das Leeren
auch noch vom OnlineManager (siehe Kapitel 6.2.2) angestoßen werden. Dies ist
immer dann der Fall, wenn sich der Verbindungsstatus des Geräts von Offline
in Online ändert. So wird versucht, die Warteschlange immer möglichst leer zu
halten, um sofort abzusetzende Aufrufe nicht durch eine vorherige Leerung der
Warteschlange zu verzögern.
Problematisch sind Aufrufe, die aufgrund eines Konflikts nicht ausgeführt werden können. Momentan existiert kein Mechanismus, den Anwender über mögliche Fehler zu informieren. Dass bedeutet, wenn ein Aufruf nicht ausgeführt
werden kann, wird dieser nie aus der Warteschlange entfernt und es kann kein
weiterer Aufruf an den Server gesendet werden. Damit befindet sich die Anwendung in einem Deadlock. Deshalb dürfen in die Warteschlange nur Aufrufe
56
6 Die Lösung
eingereiht werden, die unproblematisch in ihrer Ausführung sind.
Über den Zustand der Warteschlange kann sich der Anwender jederzeit über
eine entsprechende Anzeige informieren.
6.2.4 Die lokale Datenhaltung
Der Umfang der lokalen Daten auf den mobilen Geräten wird durch die Prozessmodelle bestimmt (siehe Kapitel 6.2.1). Die Speicherung der Daten erfolgt in
einer Datenbank, womit ein leichter Zugriff auf sie gewährleistet ist. Daneben ergibt sich noch der Vorteil, dass die Daten auch nach einem Neustart des Geräts,
beispielsweise wegen eines Batteriewechsels, verfügbar sind und im möglichen
Offline-Fall eine Weiterarbeit möglich ist.
6.2.5 Die lokale Geschäftslogik/BIS-Logik
Gemäß der Auswertung (siehe Kapitel 5.2.2) muss es für jeden Änderung-OfflineAufruf eine Funktion geben, die die Geschäftslogik simuliert. Zu Demonstrationszwecken sind bisher nur die wichtigsten Funktionen aus dem Rangierbereich
umgesetzt worden.
Die Funktionen arbeiten mit den Daten der Prozessmodelle und manipulieren
diese im vollen Umfang, wie es auch die Server-BIS-Logik tun würde. Sofern
ausreichend Daten auf den mobilen Geräten zur Verfügung stehen, werden auch
die entsprechenden Prüfungen durchgeführt. Im Allgemeinen sind diese aber
längst nicht so umfangreich wie die auf dem Server.
Aufgrund der geringen Anzahl an Daten auf den mobilen Geräten ist die Implementierung der lokalen Logik relativ einfach. Meist besteht sie nur aus eins bis
zwei Operationen und ist damit kaum fehleranfällig und leicht wartbar.
6.2.6 Die Synchronisation
Die Synchronisation ist ein wichtiger Bestandteil der Erweiterung und soll die
lokalen Daten auf den mobilen Geräten möglichst aktuell halten. Wie in Kapitel
4.2 schon angedeutet ist die Synchronisation selbst entwickelt worden – unter
der Prämisse, klar definierte Schnittstellen bereitzustellen. Das erlaubt es, die
verwendeten Algorithmen in zukünftigen Versionen ohne Probleme gegen andere
auszutauschen.
In Kapitel 3.1 sind bereits schon einige Verfahren zur Synchronisation diskutiert und in Kapitel 5.1.5 die Anforderungen (undirektional, Server-priorisiert)
festgelegt worden. Die Änderungsanweisungen sollen nach Kapitel 5.1.6 mittels
lückenhafter homogener Wertetabellen übermittelt werden.
Um den Aufwand für diese Arbeit in einem angemessenen Rahmen zu halten ist
ein relativ einfaches Verfahren zur Bildung der Differenz implementiert worden.
57
6 Die Lösung
Die Berechnung erfolgt nach dem Algorithmus 2. Sie beruht auf dem direkten
Vergleich zweier Datenquellen, indem pro zu vergleichende Tabellen jeweils die
korrespondierenden Tabellen zeilen- und spaltenweise miteinander verglichen
und so die Unterschiede ermittelt werden.
/* Durchlaufe alle zu synchronisierende Tabellen mit den
aktuellen Server-Daten */
für alle tab in Synctabellen-Server tue
/* Jede Zeile in der Tabelle durchlaufen */
für jedes Zeile zl in tab tue
/* Jede Spalte(Zelle) in der Zeile durchlaufen */
für jedes Zelle ze in zl tue
/* Aktuelle Zelle mit der korrespondierenden Zelle
im Datenabbild des Clients (ermittelt über den
Schlüssel von ze plus IMEI) vergleichen */
wenn ze ungleich Clientzelle dann
wenn Clientzelle nicht existiert dann
MerkeNeueZelle(ze);
sonst
MerkeZuÄnderndeZelle(ze);
Ende
MarkiereGeprüfteZeileInClientAbbild(zl );
Ende
/* Alle Zeilen, die nicht markiert sind, müssen auf dem
Client gelöscht werden */
für jedes Zeile zl in GibAlleNichtMarkiertenClAbbZeilen() tue
MerkeZuLöschendeZeile(zl );
Ende
Ende
Ausgabe : GibNeueZes(), GibGeänderteZes(), GibGelöschteZls()
Algorithmus 2 : Bildet die Differenz zwischen den Client- und den
Server-Daten
Damit die Berechnung ohne zusätzlichen Kommunikationsaufwand vollzogen
werden kann, besitzt der Server von jedem mobilen Gerät ein Datenabbild,
welches eine 1:1-Kopie der lokalen Daten der mobilen Geräte ist. Dadurch beschränkt sich der Nachrichtenaufwand nur noch auf das Anstoßen der Synchronisation und die Rückgabe der geänderten Daten. Nachrichten über Datenzustände müssen nicht ausgetauscht werden. Daneben profitiert auch noch das
Konfliktmanagement davon, siehe Kapitel 6.2.7.
58
6 Die Lösung
Das relativ schlechte Laufzeitverhalten des Algorithmus von
n
X
O(
i=1
mi × oi ) mit


 n = Anzahl der Tabellen (in jetzigen PMs n = 2),
m = Anzahl Spalten der Tabelle i und
i

 o = Anzahl Zeilen der Tabelle i
i
durch die doppelte Schleife wirkt sich bei den zu synchronisierenden Datenmengen von maximal 200 Datensätzen noch nicht negativ aus.16
Damit der Vergleich korrekt durchgeführt werden kann, müssen die einzelnen
Datensätze auf Client- wie auf Server-Seite eindeutig identifiziert werden. In
der jetzigen Realisierung gibt es keine Abstraktion der Schlüssel. Auf beiden
Seiten wird der gleiche Schlüssel verwendet, der auch dem Datenbankschlüssel entspricht. Allerdings können auf dem Server mehrere gleiche Datensätze in
den Tabellen der Speicherabbilder der Clients vorhanden sein, da die Daten aller Clients in einer Tabelle pro Client-Tabelle auf dem Server gehalten werden.
Deswegen ist der Schlüssel für den serverseitigen Zugriff auf die Client-Daten zusätzlich mit der eindeutigen Identifikationsnummer des jeweiligen Clients (IMEI)
erweitert worden.
Datensatz d = Clientdaten(Schlüssel s)
= Serverdaten(s + Client-Identifikation id)
Wie in Kapitel 5.1.6 bemerkt worden ist, kann bei eine lückenhaften homogenen
Tabelle per se nicht erkannt werden, ob die Lücke bedeutet, dass sich dieser
entsprechende Eintrag nicht geändert hat oder ob er gelöscht worden ist. Aus
diesem Grund werden die zu löschende Einträge durch eine spezielle Sequenz
markiert, die den Client bei der Übernahme der Synchronisationsdaten veranlasst, den entsprechenden Eintrag bei sich zu löschen.
Gemäß dem Motto, die Verarbeitung der Synchronisationsdaten für den Client
so einfach wie möglich zu machen, wird zu jeder Tabelle mit Änderungsanweisungen zusätzlich noch ein Datensatz übermittelt. Dieser beinhaltet Informationen darüber, ob die zugehörige Tabelle komplett ist, das heißt, ob diese alle
Spalten und Zeilen enthält, wie es beispielsweise bei einem SlowSync der Fall
ist. Dann kann der Client ohne zusätzliche Verarbeitung einfach die komplette
Tabelle übernehmen.
Um das Nachrichtenvolumen zu minimieren können die Synchronisationstabellen zusätzlich noch eine Lösch-Spalte enthalten, die immer dann gesetzt ist,
wenn der komplette Datensatz auf dem Client gelöscht werden soll. Dadurch
muss nicht n-mal (bei n Spalten im Datensatz) die spezielle Lösch-Sequenz übermittelt werden, sondern nur ein Eintrag in der Lösch-Spalte.
Listing 1 und 2 zeigen einen Auszug aus den Nachrichten, die während der Synchronisation zwischen dem Client und dem Server ausgetauscht werden. In der
ersten Nachricht (Listing 1) fordert der Client den Server zur Synchronisation
auf, woraufhin der Server die Änderungsinformationen zurücksendet (Listing 2).
16
Auch bei Testläufen mit mehreren tausend Datensätzen blieb die Berechnungszeit noch
unter 1 Sekunde.
59
6 Die Lösung
<?xml version=" 1 . 0 " e n c o d i n g=" us−a s c i i " ?>
<r p C a l l kn=" de . csc_dd . RPCBibliothekMobil2 .
R p c O b j e k t e _ S y n c h r o n i s a t i o n . Rpc_mSynchronisation "
mn=" r p c _ s y n c B e r e i c h " typ=" c n t ">
<c f g s i d="AD2F7F81E9E0FC6F5607EC92CA742672"
c o n f i g=" neuss_entw2 " us=" " ho=" mobil " />
<ds>
<s n=" p B e r e i c h " w=" R a n g i e r e n " />
<s n="pMandant" w="NE−BIS" />
<s n=" pImei " w=" 50006 F0063006B0065007400500043000000 −00" />
<b n=" pSlowSync " w=" F a l s e " />
<s n="pLok" w=" 01 " />
</ ds>
</ r p C a l l>
Listing 1: XML-kodierte Nachricht an den Webservice zum Starten der Synchronisation für die Lok „01“
<?xml version= ’ 1 . 0 ’ e n c o d i n g= ’UTF−8 ’ ?>
<CscRPCResult kn=" de . csc_dd . RPCBibliothekMobil2 .
mn=" r p c _ s y n c B e r e i c h ">
<c o n t>
<d e s c s l=" 3 ">
<c d s c i=" 0 " l=" 6 ">
<sp n=" abrechnung_nr " t=" s " />
<sp n=" g e s a m t a n z a h l " t=" s " />
<sp n=" ra_nr " t=" s " />
<sp n="datum_ra" t="d" />
<sp n=" p o s i t i o n " t=" s " />
<sp n=" g l e i s _ n r _ s t a n d o r t " t=" s " />
</ c d s c>
<c d s c i=" 1 " l=" 1 ">
<sp n=" k o m p l e t t " t="b" />
</ c d s c>
<c d s c i=" 2 " l=" 3 ">
<sp n="datum_ra" t="d" />
<sp n=" ra_nr " t=" s " />
<sp n=" s t a t u s " t=" s " />
</ c d s c>
</ d e s c s>
< c l s t l=" 4 ">
<ctbh l=" 19 " n=" RA_PosListe ">
<c d s i=" 0 " l=" 6 ">
<sw w=" 000000128436 " />
<sw w=" 55 " />
<sw w="R0031" />
<sw w=" 0 8 . 0 1 . 2 0 0 7 0 0 : 0 0 : 0 0 " />
<sw w=" 52 " />
<sw/>
</ c d s>
60
6 Die Lösung
<c d s i=" 0 " l=" 6 ">
<sw w=" 000000125267 " />
<sw w=" )&( " />
<sw w="R0032" />
<sw w=" 0 8 . 0 1 . 2 0 0 7 0 0 : 0 0 : 0 0 " />
<sw w=" )&( " />
<sw w=" )&( " />
</ c d s>
...
</ ctbh>
<c d s i=" 1 " l=" 1 " n=" RA_PosListeKomplett ">
<sw w=" f a l s e " />
</ c d s>
<ctbh l=" 1 " n="RA_RaListe">
<c d s i=" 2 " l=" 3 ">
<sw w=" 0 8 . 0 1 . 2 0 0 7 0 0 : 0 0 : 0 0 " />
<sw w="R0032" />
<sw w=" T r a n s p o r t " />
</ c d s>
</ ctbh>
<c d s i=" 1 " l=" 1 " n=" RA_RaListeKomplett ">
<sw w=" f a l s e " />
</ c d s>
</ c l s t>
</ c o n t>
</ CscRPCResult>
Listing 2: XML-kodierte Antwort des Servers mit Änderungsanweisungen für
den Client
Da die Ermittlung der Differenz ohne Einbeziehung des Clients stattfindet, muss
gewährleistet sein, dass das Client-Abbild auf dem Server immer den korrekten Zustand des jeweiligen Clients widerspiegelt. Aus diesem Grund nutzt die
Synchronisation das 2-Phasen-Commit-Protokoll zur Absicherung der Kommunikation. Die erste Phase besteht aus dem Austausch der Synchronisationsinformationen. Den korrekten Empfang und die fehlerfreie Einpflegung dieser
Daten muss der Client in der zweiten Phase des Protokolls bestätigen (ClientBestätigung Listing 3, Server-Antwort Listing 4). Erst dann übernimmt auch
der Server die Änderungen in sein Client-Abbild.
<?xml version=" 1 . 0 " e n c o d i n g=" us−a s c i i " ?>
<r p C a l l kn=" de . csc_dd . RPCBibliothekMobil2 .
mn=" r p c _ s y n c B e s t a e t i g e n " typ=" r c ">
<c f g s i d="F4CE76DF4E00C5520CF1239BF6C7E31D"
c o n f i g=" neuss_entw2 " us=" " ho=" mobil " />
<ds>
<s n="pMandant" w="NE−BIS" />
<s n=" pImei " w=" 50006 F0063006B0065007400500043000000 −00" />
<s n=" p B e r e i c h " w=" R a n g i e r e n " />
61
6 Die Lösung
</ ds>
</ r p C a l l>
Listing 3: XML-kodierte Sync-Bestätigung des Clients
<?xml version= ’ 1 . 0 ’ e n c o d i n g= ’UTF−8 ’ ?>
<CscRPCResult kn=" de . csc_dd . RPCBibliothekMobil2 .
mn=" r p c _ s y n c B e s t a e t i g e n ">
<r c e r g e b n i s=" 1 " />
</ CscRPCResult>
Listing 4: XML-kodierte Antwort des Servers auf die Bestätigung
Durch dieses Verfahren ist garantiert, dass der Server sicher sein kann, dass
seine Änderungsanweisungen erfolgreich vom Client verarbeitet worden sind.
Allerdings ist dies für die eigentliche Arbeit auf dem Client nicht erforderlich,
so dass die Bestätigung der Synchronisation im Hintergrund ausgeführt wird
und der Nutzer bereits mit der Anwendung weiterarbeiten kann, obwohl die
Synchronisation noch nicht komplett abgeschlossen ist.
Das Sequenzdiagramm in Abbildung 15 stellt den kompletten Ablauf einer Synchronisation dar. Auf die Vorgehensweise der Warteschlange wird in Kapitel
6.2.3 genauer eingegangen.
Für die Auslösung der Synchronisation gibt es verschiedene Möglichkeiten, welche von der Konfiguration der mobilen Anwendung abhängig ist. Die sicherste
Variante im Bezug auf aktuelle Daten ist, dass die Synchronisation immer angestoßen wird, sobald der Nutzer Daten anfordert – sei es eine reine Datenanforderung oder nach einer Statusänderung im BIS. Zusätzlich gibt es noch die
Möglichkeit, die Synchronisation automatisch und regelmäßig im Hintergrund
ausführen zu lassen. Listing 5 zeigt einen Auszug des entsprechenden Teils aus
der Konfiguration.
#============================================================
# E i n s t e l l u n g e n f ü r den Agenten
#============================================================
a g e n t . SyncVorLesen=t r u e
a g e n t . SyncNachAufruf=t r u e
a g e n t . SyncRangierenLok=t r u e
a g e n t . SyncEingangszugBes=t r u e
a g e n t . AutoSync=t r u e
a g e n t . A u t o S y n c I n t e r v a l l=5
...
Listing 5: Ausschnitt aus der Konfigurationsdatei cfg_moBIS.txt
62
6 Die Lösung
Abbildung 15: Sequenzdiagramm, welches den kompletten Verlauf der Synchronisation darstellt
63
6 Die Lösung
Es kann auch konfiguriert werden, ob die zu synchronisierenden Daten auf eine Lok oder Betriebsstelle beschränkt werden sollen, wie es in Kapitel 6.2.1
beschrieben ist. Falls die automatische Synchronisation genutzt wird, wird der
SyncHandler (siehe Abbildung 10) nach jeder erfolgreichen Durchführung darüber informiert und kann dementsprechend reagieren.
6.2.7 Das Konfliktmanagement
Das Konfliktmanagement muss in der Lage sein, Probleme erkennen und lösen
zu können, die durch die neue Arbeitsweise der mobilen Geräte entstehen. Durch
die Art und Weise der Synchronisation und der Leerung der Warteschlange ist
sichergestellt, dass die Datenabbilder der Clients auf dem Server immer auf dem
Stand des Original-Aufrufszeitpunkts sind. Damit eignen sich die Server-ClientDaten auch für die Konflikterkennung von Aufrufen, die aus Warteschlangen
gesendet werden. Diese Aufrufe benötigen somit keine zusätzlichen Parameter.
Da die Konfliktlösungsstrategien müssen erst noch spezifiziert werden, was nicht
die Aufgabe dieser Arbeit ist. Deshalb existiert das Konfliktmanagement bisher nur in der Spezifikation, gemäß dem Algorithmus 1 in Kapitel 5.1.7. Um
dennoch die Arbeitsweise und Problematik zu verdeutlichen, wird seine mögliche Arbeitsweise an einem Beispielszenario zum Beginnen eines Rangierauftrags
kurz erläutert.
Zu dem Aufrufzeitpunkt des Aufrufs umfasst der auszuführende Rangierauftrag
fünf Positionen. Dementsprechend kuppelt der Lokrangierführer diese fünf Wagen an seine Lok und beginnt den Auftrag. Da das Gerät zurzeit über keine
Verbindung verfügt, wird der Aufruf nur lokal ausgeführt und in die Warteschlange eingereiht.
Zu einem späteren Zeitpunkt fügt ein Disponent diesem Rangierauftrag, ohne
das er weiß, dass dieser bereits in der Ausführung ist, noch drei weitere Wagen hinzu. Im Anschluss daran kann das mobile Gerät wieder eine Verbindung
herstellen und setzt den eingereihten Aufruf ab.
Das Konfliktmanagement prüft diesen Aufruf und stellt einen Konflikt fest. Anhand seines Client-Daten-Abbilds weis es, dass der Client zum Aufrufzeitpunkt
nur die Information über fünf Wagen besessen hat, der Auftrag inzwischen aber
acht Positionen umfasst.
Würde dieser Aufruf jetzt im BIS ausgeführt werden ohne den Konflikt zu lösen,
würde dadurch der Datenbestand des BIS korrumpiert werden. Die Server-Logik
geht von einem Rangierauftrag mit acht Positionen aus, der Lokrangierführer
hat aber nur fünf davon an seine Lok gekuppelt. Das Abbild der Realität würde
dann nicht mehr mit ihr übereinstimmen.
Eine mögliche Lösung des Konflikts könnte sein, dass durch das Konfliktmanagement die drei zusätzlichen Wagen automatisch wieder aus dem Auftrag entfernt
werden und ein neuer Rangierauftrag mit ihnen gebildet wird. Eine erneute Prüfung der Situation würde daraufhin keinen Konflikt mehr feststellen können und
64
der Aufruf kann ausgeführt werden.
Damit das mehrfache Senden des gleichen Aufrufs durch das Konfliktmanagement leicht erkannt werden kann, und die Idempotenz-Eigenschaft eines Aufrufs
erhalten bleibt, wird jeder neu erzeugte Aufruf zusätzlich mit einer eindeutigen
ID und der Identifikationsnummer des Clients versehen. Mit Hilfe dieser Angaben ist es für das Konfliktmanagemant leicht feststellbar, ob der Aufruf zuvor
schon mal empfangen worden ist oder nicht.
Im Gegensatz zu der alten Anwendung ist die im Rahmen dieser Arbeit entstandene Anwendung auch im verbindungslosen Zustand nutzbar. Doch wie wirken
sich die gemachten Änderungen auf das Verhalten der Anwendung aus? Müssen
jetzt mehr Daten übertragen werden? Haben sich die Laufzeiten verlängert oder
sind sie gar kürzer geworden?
7.1 Das Testszenario
Für die Beantwortung dieser Fragen wurde ein realitätsnahes Testszenario entwickelt, welches die alte und die neue Anwendung in verschiedenen Konfigurationen durchgehen musste. Zu Beginn des Tests sind bereits drei Rangieraufträge
auf der Server-Seite vorhanden. Zwei von ihnen bestehen aus drei und einer aus
fünf Positionen, wobei dieser bereits im Status „Transport“ ist. Der Testablauf
gestaltet sich wie folgt:
1. Holen der Liste aller verfügbarer Lokomotiven
2. Eine Lok auswählen und alle Rangieraufträge dieser Lok abholen (3 Stück)
3. Den Rangierauftrag mit fünf Positionen selektieren und die einzelnen Positionen anzeigen lassen
4. Diesen Rangierauftrag beenden
5. Die restlichen Rangieraufträge anzeigen lassen
6. Einen davon auswählen und dessen Positionen holen (während der Anzeige
der einzelnen Positionen werden zwei neue Rangieraufträge mit jeweils 6
Positionen gebildet)
7. Wieder zurück wechseln zur Ansicht der Rangieraufträge (4 Stück)
8. Einen Rangierauftrag mit sechs Positionen wählen und seine Details anzeigen lassen
9. Zurück zur Rangierauftragsliste gehen
65
10. Den anderen Rangierauftrag mit sechs Positionen selektieren und dessen
Positionen holen
11. Diesen Rangierauftrag beginnen
Durchgespielt worden ist der Test mit der alten Version der Anwendung (1: Alte Anwendung) und der neuen Version in drei verschiedenen Konfigurationen.
In der ersten Konfiguration (2: Immer Synchronisation) findet keine automatische Synchronisation statt und die Daten werden nach jedem Webservice-Aufruf
synchronisiert. In der zweiten Variante (3: Nur automatische Synchronisation)
wird die Synchronisation nicht explizit gestartet. Stattdessen wird diese automatisch im Hintergrund ausgeführt. Das heißt, dass bei Daten-Offline-Aufrufen der
Webserver nicht kontaktiert wird, sondern die Daten aus der lokalen Datenbank
ausgelesen werden. Bei Änderung-Offline-Aufrufen wird zwar die Statusänderung an den Webservice gesendet, es findet danach aber keine Synchronisation
statt. Stattdessen werden die lokalen Daten ausgewertet und manipuliert. Die
dritte Konfiguration (4: Immer SlowSync) führt wie die erste immer eine Synchronisation aus, allerdings immer im SlowSync. Dieser Modus ist zwar normal
nicht möglich, soll aber zeigen, ob sich der gesamte Aufwand für die Synchronisation lohnt.
7.2 Die Testumgebung
Die Testumgebung bestand aus einem handelsüblichen PC (Intel Pentium 4
Prozessor mit 2,5 GHz und Hyperthreading, 1024 MB Arbeitsspeicher, Red Hat
8 als Betriebssystem, Apache Tomcat 5 für den Webservice) und einem SymbolPDA MC9090, der über einen GPRS-Zugang von Vodafone (VCDA) mit dem
PC verbunden war.
Gemessen wurde an der Netzwerkschnittstelle des mobilen Geräts die Sendezeit einer Nachricht und die Empfangszeit der Antwort auf diese Nachricht. Die
Differenz ergibt die gesamte Laufzeit eines Aufrufs (Übertragungszeiten plus
Verarbeitungszeit auf dem Server (in der Regel zwischen „0“ und einer Sekunde)). Des Weiteren wurde noch das gesendete und empfangene Datenaufkommen
erfasst.
Vor jedem Testdurchlauf wurde das mobile Gerät zurückgesetzt und damit alle
Daten gelöscht. Das führt bei der ersten Synchronisation automatisch zu einer
Ausführung im SlowSync-Modus.
Die Ergebnisse der Messung können der Tabelle 6 und den Diagrammen in
Abbildung 16 und 17 entnommen werden.
7.3 Die Auswertung und Bewertung
Am auffälligsten verhält sich Fall 3. Hier werden entweder keine, sehr wenige
oder sehr viele (ausgelöst durch die automatische Synchronisation) Daten über66
Abbildung 16: Stellt die Übertragungsvolumen in Byte der einzelnen Aufrufe
der verschiedenen Testläufe gegenüber
Abbildung 17: Vergleicht die verstrichene Zeit zwischen Aufruf- und Antwortzeitpunkt der einzelnen Aufrufe
67
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Lok-Liste
RA-Liste
Pos-Liste
Beenden
RA-Liste
Pos-Liste
RA-Liste
Pos-Liste
RA-Liste
Pos-Liste
Beginnen
P
Aufrufdauer in
Sekunden17
1
2∗
3∗
4∗
4
4∗
4∗
4∗
2
7∗
7∗
7∗
∗
∗
5
3
0
7∗
5
5∗
5∗
5∗
∗
∗
2
5
0
4∗
5
3∗
0∗
4∗
∗
∗
4
6
8
8∗
6
3∗
0∗
8∗
∗
∗
4
3
0
8∗
∗
∗
6
3
0
8∗
3
3∗
3∗
3∗
46∗ 45∗ 27∗ 66∗
Übertragene Bytes18
1
763
1.285
6.052
576
1.113
4.571
1.455
8.349
1.455
8.349
583
34.551
2∗
763∗
6.849∗
1.306∗
576∗
2.291∗
1.306∗
5.013∗
1.306∗
1.306∗
1.306∗
583∗
22.605∗
3∗
763∗
6.849∗
0∗
576∗
0∗
0∗
9.669∗
0∗
0∗
0∗
583∗
18.440∗
4∗
763∗
6.849∗
6.849∗
576∗
4.262∗
4.262∗
10.299∗
10.299∗
10.299∗
10.299∗
583∗
65.340∗
Tabelle 6: Laufzeiten und übertragenes Datenvolumen eines Testszenarios für
verschiedene Konfigurationen
∗ . . . Synchronisation
tragen, wobei das akkumulierte Datenaufkommen am geringsten ist. Dafür ist
bei einigen Aufrufen die Sendezeit maximal.
Bei einem Einsatz dieser Konfiguration kommt es sehr auf das Synchronisationsintervall an. Ist das Intervall zu groß, muss der Anwender häufig mit veralteten
Daten arbeiten. Ist das Intervall zu klein, werden unnötige Synchronisationen
durchgeführt und der Anwender in seiner Arbeit dadurch womöglich behindert.
Darum muss es immer an die jeweilige Arbeitsumgebung angepasst werden.
Fall 1 und Fall 2 verhalten sich bei diesem Testszenario recht ähnlich, wobei bei
Fall 2 wesentlich weniger Daten übertragen werden (≈ -33 %). Auffällig bei dem
ersten Fall ist, dass bei den Aufrufen 7 und 9, sowie 8 und 10 jeweils immer die
gleiche Datenmenge übertragen wird. Dies liegt daran, dass sich die Daten auf
Server-Seite nicht geändert haben und deswegen immer die gleichen Daten übertragen werden (die alte Anwendung verfügt über keine lokale Datenhaltung).
Ähnlich verhält es sich auch bei dem zweiten Fall. Jeder Aufruf 7 bis 10 löst
die Synchronisation aus. Da es aber keine Änderungen gibt, enthalten die Synchronisations-Nachrichten keine Änderungsinformationen und sind damit auch
immer gleich groß. Aber im Vergleich mit Fall 1 werden erheblich weniger Daten
ausgetauscht.
17
Bei Synchronisationsaufrufen ist die Zeit für den Austausch der Bestätigung nicht mit eingerechnet, da diese im Hintergrund ausgeführt wird.
18
Bei Synchronisationsaufrufen: Sync-Anfrage (422 Byte) + Antwort(min. 298 Byte) + SyncBestätigung-Anfrage (388 Byte) + Sync-Bestätigung-Antwort (198 Byte)
68
Beginnt der Anwender mit seiner Arbeit, so liefert Fall 1 gegenüber 2 und 3
wesentlich schneller Ergebnisse, da diese erst die Daten des gesamten Prozessmodells synchronisieren (wegen des ersten Aufrufs mittels SlowSync) müssen
und bei dem ersten Fall nur die Liste der Rangieraufträge abgeholt wird. Dafür
müssen im Anschluss bei Fall 2 und 3, im Gegensatz zu 1, nur noch ein paar
Änderungsinformationen auf die Clients übertragen werden.
Der Fälle 2 und 3 zeigen das Einsparpotential, welches erreicht wird, indem
anstelle des kompletten Prozessmodells nur die Änderungsinformationen ausgetauscht werden, wie es bei Fall 4 immer der Fall ist. Das Gesamtaufkommen
verringert sich dadurch für dieses Testszenario um über 65 %.
Zusammenfassend gibt es keinen eindeutigen Sieger. Die neue Anwendung hat,
egal in welcher Konfiguration, den Vorteil der Offline-Fähigkeit. Zudem werden
die Informationen insgesamt schneller ausgetauscht und es müssen weniger Daten übertragen werden. Ob Konfiguration 2 oder 3 oder eine Kombination aus
beiden zum Einsatz kommt, hängt von der konkreten Realisierungsumgebung
ab (Häufigkeit der Änderungen der Daten, Geschwindigkeit des Zuganges für
das mobile Gerät) und muss deswegen von Fall zu Fall entschieden werden.
Die entstandene Anwendung, beziehungsweise die Erweiterung der alten Anwendung, erfüllt alle an sie gestellten Anforderungen. Die Erweiterung lässt sich
leicht integrieren und ermöglicht die Weiterarbeit des Benutzers auch für den
Fall, dass das Gerät über keine Verbindung verfügt. Erreicht wurde dies durch
die Einführung einer weiteren Schicht als neuen Unterbau für die Anwendung
(siehe Abbildung 10).
Diese erweitert die Anwendung unter anderem um eine lokale Datenhaltung, die
Basis für eine Offline-Fähigkeit ist. Der Umfang wird durch die Prozessmodelle
beschrieben, die daneben auch noch die Daten in Bereiche aufteilen und diesen
einzelne Funktionen zuordnen.
Ein Agent kümmert sich um die korrekte Verarbeitung von Aufrufen gemäß
ihren Eigenschaften. Über die neu eingeführte Synchronisation werden die Clientdaten mit den Serverdaten abgeglichen. Aufrufe können jetzt in eine Warteschlange eingereiht werden, um diese später zu senden.
Die Einführung des Konfliktmanagements auf der Server-Seite und der damit
verbundenen Konflikterkennung und -behebung fördert die bessere Integration
des Clients in das Gesamtsystem BIS. Etwaige Konflikte können so erkannt und
behoben werden, ohne das ein Nutzer des Systems eingreifen muss.
Abbildung 18 zeigt einen Gesamtüberblick über das so entstandene System.
Bereits jetzt steht fest, dass die hier vorgestellten Lösungen in die zukünftigen
Anwendungen mit integriert und von den Kunden eingesetzt werden. Die Idee
des Prozessmodells wird noch tiefer in die Anwendung verankert und der Agent
69
Abbildung 18: Überblick über das (mo)BIS-System inklusive der Erweiterung
bekommt aufgrund von Designänderungen eine noch zentralere Bedeutung und
wird zum festen Bestandteil der Anwendung.
Zukünftig könnte sich die relativ einfache Implementierung der Differenzbildung
bei der Synchronisation als Schwachpunkt herausstellen, wenn die zu synchronisierende Datenmenge stark zunehmen sollte. Letzte kurze Testläufe haben aber
gezeigt, dass die Berechnung der Differenz auch für mehrere tausend Datensätze noch ausreichend schnell ist (innerhalb einer Sekunde), so dass sich eher die
langsame Anbindung der mobilen Geräte über GPRS als problematisch erweist.
Sollte es dennoch zu Änderungen auf Client- oder Server-Seite kommen, können
diese verhältnismäßig leicht vollzogen werden. Die einzelnen Schnittstellen sind
fest definiert und die beiden Seiten arbeiten unabhängig voneinander.
Falls die Verbindungszuverlässigkeit nicht sehr hoch ist, könnte die mobile Anwendung den Nutzer bei seiner Arbeit noch besser unterstützen. Möchte dieser
einen Änderung-Online-Aufruf im verbindungslosen Zustand ausführen, kann er
zwar den Disponenten über Funk darüber in Kenntnis setzen, der dann für ihn
im BIS die entsprechende Funktion ausführt, die mobile Anwendung bietet dem
Nutzer aber keine Möglichkeit, ihr das mitzuteilen.
Um diese Möglichkeit zu schaffen wäre es denkbar, auch für Änderung-OnlineAufrufe eine lokale Geschäftslogik einzuführen, sofern die notwendigen Daten
im entsprechenden Prozessmodell vorhanden sind. Die Verarbeitung durch den
Agenten wäre dann ähnlich zu Änderung-Offline. Die Unterschiede wären, dass
Rücksprache mit einem Disponenten gehalten werden muss, der dann stellvertretend den Aufruf ausführt und weiterhin, dass deswegen die Aufrufe nicht
eingereiht werden müssen.
Eine ähnliche Vorgehensweise ist auch für Änderung-Offline-Aufrufe möglich,
deren Ausführung die lokale Geschäftslogik aufgrund falscher Daten oder Ge70
schäftslogik verweigert wird, obwohl die Server-Geschäftslogik zustimmen würde
(Negativ-Positiv-Konflikt).
Verbesserungen sind unter anderen noch im Bereich der Kommunikation (Nachrichtengröße und damit auch Übertragungsdauer) möglich. Hier könnten noch
für häufig wiederkehrende oder lange Zeichensequenzen Abkürzungen eingeführt
werden.
Die Einführung neuer Schlüssel-IDs, wie es SyncML vorsieht (Kapitel 3.3), könnten zusätzlich die Nachrichtengröße verkleinern, indem die teilweise recht langen
Schlüssel (über mehrere Spalten) nicht mehr übertragen werden müssten.
Auch gibt es noch keine Mechanismen, die es erlauben, eine durch Verbindungsverlust abgebrochene Nachricht fortzusetzen. Besonders im Bereich der Synchronisation, falls die zu übertragenen Datenmengen wesentlich größer werden
sollten, wäre es vorteilhaft, wenn ein abgebrochener Synchronisationsvorgang
fortgesetzt werden könnte und dieser nicht komplett neu gestartet werden muss.
71
Teil II
73
Im vorangegangen Teil ist ein Konzept entwickelt und realisiert worden, mit
dem der vorhandene mobile Client offline-fähig gemacht worden und jetzt besser
in das BIS-System integriert ist. Hierfür wurden die Prozessmodelle und eine
Synchronisation eingeführt. Abbildung 18 gibt nochmals einen Gesamtüberblick
über das so entstandene System.
Als großer Schwachpunkt dieser Architektur erweisen sich der Webservice- und
Datenbank-Server und die strikt vertikale Kommunikation19 . Sollte der Webservice beziehungsweise die Datenbank mal nicht erreichbar sein, können die stationären Clients gar nicht und die mobilen Clients nur stark eingeschränkt weiterarbeiten.20
Eine Lösungsmöglichkeit ist die Einführung einer horizontale Kommunikation21 .
Mit Hilfe dieser können sich ganz neue Kommunikationsabläufe ergeben. Denkbar sind Szenarien, in denen ein Client seinen Nachbarn nach bestimmten Daten
befragen könnte, wenn dieser selbst gerade über keine Verbindung verfügt oder
den Nachbarn als Proxy nutzt, um seine Aufrufe an den Webservice absetzen
zu können.
9.1 Peer-to-Peer: Die neue Architektur für das BIS?
Aus diesen Vorüberlegungen heraus ist eine Architektur wünschenswert, die die
starre Rollenverteilung aufbricht und mehr auf die Kommunikation untereinander setzt. Solche Architekturen werden als Peer-to-Peer bezeichnet und ziehen
wegen der bereits genannten Vorteile in den letzten Jahren immer mehr Aufmerksamkeit auf sich. In der Literatur findet man zahlreiche mehr oder weniger
weitgefasste Definitionen:
„Ein Peer-to-Peer-Netzwerk ist ein Kommunikationsnetzwerk zwischen Rechnern, in dem jeder Teilnehmer sowohl Client- als auch
Server-Aufgaben durchführt.“ [49]
Ein „. . . Peer-to-Peer-System ist ein sich selbst organisierendes System gleichberechtigter, autonomer Einheiten (Peers), das vorzugsweise ohne Nutzung zentraler Dienste auf der Basis eines Rechnernetzes mit dem Ziel der gegenseitigen Nutzung von Ressourcen operiert - kurzum ein System mit vollständig dezentraler Selbstorganisation und Ressourcennutzung.“ [2]
Die Kernaussagen der verschiedenen Definitionen sind jedoch gleich. In einem
Peer-to-Peer-Netzwerk gibt es keine klare Rollenverteilung mehr. Jeder Rechner
19
Vertikale Kommunikation bezeichnet den Nachrichtenaustausch zwischen Client und Server.
Die mobilen Clients verfügen über eine abgespeckte lokale Geschäftslogik um kurze OfflinePhasen zu überbrücken.
21
Horizontale Kommunikation ist die direkte Kommunikation unter den Clients.
20
74
ist in der Lage als Client wie auch als Server zu fungieren und das möglichst
unabhängig von einer zentralen Steuereinheit. Das hat zur Folge, dass auch
jeder Teilnehmer des Netzes mit jedem anderen kommunizieren kann. Dadurch
entsteht ein sehr dynamisches Netzwerk, welches die Ausfälle einzelner Knoten
möglichst durch Selbstorganisation kompensieren und verkraften können muss.
In einer Client-Server-Anwendung spielt es für die einzelnen Clients keine Rolle,
wie viele und welche von ihnen gerade aktiv sind, da diese nicht untereinander
kommunizieren. In einer Peer-to-Peer-Umgebung, in der es keine zentrale Anlaufstelle mehr gibt, ist es für die einzelnen Clients wichtig zu wissen, welche
Clients gerade aktiv sind und wie diese erreicht werden können. So muss zum
Beispiel ein Client, der dem Peer-to-Peer-Netzwerk neu beitritt, wissen, wie
er andere Knoten kontaktieren beziehungsweise kennen lernen kann. Die dafür
notwendigen Tätigkeiten fallen alle in den Bereich der Selbstorganisation.
Diese Art der Architektur scheint also alle zuvor geschilderten Probleme lösen
zu können. Die zentrale Rolle eines (Web-)Servers entfällt, da jeder Rechner
im Netz auch Serverfunktionalitäten übernehmen kann und die Kommunikation
horizontal ausgelegt ist.
9.1.1 Historische Entwicklung von Peer-to-Peer
Die geschichtliche Entwicklung der Peer-to-Peer-Netze zeigt deren Möglichkeiten
auf und weist auf einige Problemstellen hin.
Bekannt und berühmt geworden sind Peer-to-Peer-Netze hauptsächlich durch
Datei-Tauschbörsen wie Napster, eMule und dem Peer-to-Peer-Computing beziehungsweise Grid-Computing-Programm SETI@home der UC Berkeley.
Napster [5] startete 1999 seinen Dienst und ist die erste Tauschbörse, die nach
dem Peer-to-Peer-Prinzip arbeitete, allerdings noch nicht in der reinen Form.
Um Napster nutzen zu können mussten sich die Anwender einen Client herunterladen. Nach dem Start hat dieser die Festplatte nach MP3-Datein durchsucht
und die Liste der gefundenen Dateien mitsamt der IP-Adresse an einen zentralen
Server gemeldet.
Die einzelnen Suchanfragen der Clients wurden ebenfalls an diesen Server gerichtet. Fand dieser einen passenden Eintrag in seiner Liste, sandte er die IPAdresse als Antwort und der Anfragende konnte die Datei daraufhin direkt von
dem Anbieter herunterladen (Peer-to-Peer).
Aufgrund dieser eigentlichen Client-Server-Architektur konnte die Musikindustrie Napster erfolgreich verklagen. 2001 besiegelte ein Gerichtsurteil das Ende
von Napster, das daraufhin seinen Dienst einstellte.
SETI@home [9] arbeitet nach einem ähnlichen Prinzip wie Napster. Hierbei
handelt es sich um ein im Jahr 1999 von der Universität Berkeley [13] ins Leben
gerufene Projekt, mit dem Frequenzbänder nach ausserirdischen Lebenszeichen
analysiert werden. Auch hier gibt es wieder einen zentralen Steuerserver, an
75
den die Clients ihre Anfragen richten. Diese erhalten als Antwort Datenpakete,
die dann auf dem Client nach Auffälligkeiten durchsucht werden. Durch diese
Vorgehensweise stehen dem Projekt enorme Rechenkapazitäen22 zur Verfügung
ohne selbst viel Geld in Hardware investieren zu müssen.
Um die juristische Schwachstelle – der zentrale Server – von Napster zu umgehen begann Gnutella [34] 2000 seinen Dienst als ein rein dezentral organisiertes
Peer-to-Peer-Netzwerk. Suchanfragen eines Teilnehmers werden an einen benachbarten Knoten weitergeleitet. Dieser leitet die Anfrage wiederum an seine
Nachbarn weiter und so fort. Wenn die Datei gefunden ist kann der Sucher
sie direkt herunterladen. Aus diesem Grund muss jeder Knoten seine Nachbarn
kennen. Hierfür gibt es diverse Methoden, zum Beispiel vordefinierte Listen,
Webcache-Seiten im Internet oder der Austausch von Host-Listen über andere Kommunikationsmittel. Durch diesen Aufbau ist das Netz sehr ausfallsicher.
Dem gegenüber stehen die teilweise recht hohe Laufzeit einer Suchanfrage und
eine hohe Netzbelastung durch teils ziellose Weiterleitungen von Suchanfragen.
[16]
Im Laufe der Zeit ist das Protokoll immer weiter entwickelt und 2002 das neu
erdachte Protokoll Gnutella2 veröffentlicht worden. Als große Neuerung arbeitet das Protokoll nach dem Kademlia-Algorithmus und löst sich so von einem
reinem Peer-to-Peer-Netzwerk zu einer hybriden Struktur. Der Algorithmus berechnet für jede denkbare Suchanfrage einen bestimmten Ansprechpartner, der
dann dafür zuständig ist. Auf diese Weise entwickelt sich eine Pseudo-ClientServer-Architektur. Zusätzlich wurden noch Caching-Strategien und verbesserte
Suchanfragen implementiert.
Seit den letzten Jahren spielt die Anonymität der einzelnen Nutzer eine immer
bedeutendere Rolle, so dass es mittlerweile auch Peer-to-Peer-Protokolle gibt,
die die Identität der Nutzer verbergen. Des Weiteren gibt es Entwicklungen,
die die übertragenen Daten zusätzlich noch verschlüsseln. Beispiele hierfür sind
WASTE [14], ANts P2P [1] oder auch Mute [4].
9.2 Die neue Architektur
9.2.1 Die Anforderungen
Hierbei muss unterschieden werden in Anforderungen, die sich aus der Nutzung
des BIS-Systems ergeben und sonstigen Anforderungen, um die notwendigen
Rahmenbedingungen für die neue Architektur sicher zu stellen.
Aus der Sicht des BIS-Systems gibt es die Anforderung, das die komplette Funktionalität dauerhaft zur Verfügung stehen muss, unabhängig von dem Netzwerk.
Dies umfasst die dauerhafte und ständige Verfügbarkeit der Daten, Geschäftslogik und die Verfügbarkeit der Schnittstellen zu Fremdsystemen.
Darüber hinaus sollen die Offline-Fähigkeiten, beziehungsweise die Unabhängig22
Theoretisch alle Computer, die mit dem Internet verbunden sind.
76
keit von den zentralen Servern, noch weiter entwickelt werden mit dem Ziel, das
es für den einzelnen Anwender möglichst keinen Unterschied macht, ob und wie
lange der Client verbindungslos ist. Hintergründig sind erst einmal Aspekte der
Skalierbarkeit.
In diesem Teil der Arbeit wird nur die Architektur betrachtet und davon ausgegangen, dass bereits ein Peer-to-Peer-Netzwerk vorhanden ist. Welche Technologien dabei eingesetzt werden (WLAN, UMTS, . . . ) und wie es realisiert und
organisiert ist spielen dabei keine Rolle. Dafür in Frage kommende Standards
und Protokolle können unter anderem [12], [15], [54] und [56] entnommen werden. Es muss jedoch Multicasts unterstützen. Weiterhin müssen die Uhren der
einzelnen Teilnehmer müssen synchron sein.
9.2.2 Die Architektur
In dem BIS-System weisen die einzelnen Daten eine unterschiedliche Häufigkeit
in ihrer Verwendung auf. Sie können in Operativ- und Protokoll-Daten unterschieden werden.
Operativ-Daten umfassen alle Daten, die für die Erfüllung der originären Aufgaben notwendig sind.
Dazu zählen zum Beispiel die Daten aus dem Rangierbereich, aber auch viele
Teile der Stammdaten fallen darunter.
Protokoll-Daten entstehen im Hintergrund beziehungsweise werden
dort verwaltet und werden für die Ausführungen der eigentlichen
Tätigkeiten nicht benötigt.
Darunter fallen das Logging von Vorgängen, Daten für fremde Schnittstellen,
Archivierung und ähnliches. Diese Daten werden im Allgemeinen nicht auf den
Clients benötigt.
Aus diesem Grund sollen sich die Teilnehmer nicht mit den Protokoll-Daten und
den zugehörigen Funktionalitäten auseinander setzen. Damit diese aber dennoch
zur Verfügung stehen, wird die Geschäftslogik geteilt. Der Dienst- beziehungsweise Webservice-Server übernimmt alle Aufgaben im Bereich der ProtokollDaten. Die restlichen Funktionen werden auf die Clients übertragen. Dadurch
können die Ressourcen auf den Clients geschont werden und das Übertragungsvolumen erhöht sich nicht unnötig. Zur Sicherung der Daten kommt weiterhin
ein Datenbank-Server zum Einsatz. So wird nebenbei die dauerhafte Verfügbarkeit der Daten sichergestellt.
Durch die Beibehaltungen der Server-Strukturen, auch wenn sie stark eingeschränkt worden sind, und der Einführung einer horizontalen Kommunikation,
um dem Peer-to-Peer-Paradigma gerecht zu werden, weist das System eine hybride Struktur auf, wie sie in Abbildung 19 dargestellt ist. Im weiteren Verlauf
wird diese mit nBIS, für „neues BIS“, bezeichnet.
77
10 nBIS im Detail
Abbildung 19: Darstellung eines logisch vollständig vermashtes, hybrides Peerto-Peer-Netzwerk
10 nBIS im Detail
Die erweiterte Client-Geschäftslogik erlaubt es jetzt jedem Teilnehmer die Daten
zu manipulieren. Diese Freiheit in dem Multi-Master-System, dass nach dem
Update-Anywhere-Prinzip arbeitet, führt jedoch zu neuen Problemen. Es kann
leicht zu inkonsistenten Daten kommen, die eine sichere Arbeit mit dem System
gefährden. Aus diesem Grund muss das Netzwerk so organisiert werden, dass
Inkonsistenzen möglichst nicht entstehen können oder zumindest erkannt und
behoben werden.
Obwohl in den letzten Jahren viel Forschung in dem Peer-to-Peer-Bereich betrieben worden ist, gibt es kaum etablierte allgemeine Standards zur Synchronisation von Daten in einem Peer-to-Peer-Netzwerk. Stattdessen kristallisieren sich
spezielle Protokolle für bestimmte Anwendungsgebiete heraus. Genannt werden
kann zum Beispiel die Echtzeit-Synchronisation, wie sie bei vielen verteilten
Computerspielen zum Einsatz kommt (siehe unter anderem [26]). Diese Anwendungen haben teilweise mehrere 10.000 Nutzer, die diese parallel nutzen. Die
78
10 nBIS im Detail
Aufgabe der Synchronisation besteht meist aus dem Austausch von personenbezogenen Daten, wie zum Beispiel die Position eines Spielers in der virtuellen
Welt. Dabei ist das Konfliktpotential in der Regel sehr gering. Verliert ein Spieler die Verbindung zum System, so hat er das Spiel verlassen und kann erst
weiterspielen, wenn er wieder eine Verbindung hat. So entfällt der komplette
Problembereich, der durch das spätere Senden einer Anweisung entstehen kann.
Des Weiteren gibt es noch einige spezielle Realisierungen, die nur auf bestimmte
Produkte ausgelegt sind. Syncing.net [10] kann als Beispiel angeführt werden.
Es erlaubt die Synchronisation von Microsoft Outlook-Daten zwischen verschiedenen Rechnern ohne einen zentralen Server einzubeziehen.
Aus diesem Grund ist das nBIS-Protkoll entwickelt worden und wird in den
folgenden Unterabschnitten vorgestellt.
10.1 Die Client-Architektur
Die neue Architektur der Clients ist in Abbildung 20 dargestellt. Im Einzelnen
besteht sie aus den Schichten:
Abbildung 20: Die einzelnen Schichten der neuen Architektur auf den Clients
Kommunikationsschicht: Diese stellt eine einheitliche Schnittstelle für den Zugriff auf das darunterliegende Netzwerk für die darüberliegenden Schichten
dar. Dadurch wird das Netzwerk gekapselt und die restlichen Schichten
können unabhängig von ihm realisiert werden.
Nachrichtenschicht: Sie übernimmt die Verarbeitung der einzelnen Nachrichten, wenn diese an den jeweiligen Teilnehmer gerichtet ist oder es sich um
79
10 nBIS im Detail
eine Suchanfrage an seine Gruppe handelt. Mit Unterstützung der LogikSchicht können Suchanfragen vorzeitig beantwortet werden, auch wenn
der Teilnehmer nicht das Ziel der Suchanfrage ist.23 Des Weiteren ist sie
zuständig für die Aufbereitung der Nachrichten, so dass diese von der
Logikschicht verarbeitet werden können. Zudem werden hier Nachrichten
generiert, die über die Kommunikationsschicht an die anderen Teilnehmer
des Netzwerks gesendet werden.
Datenschicht: Sie kapselt die lokale Datenbank und ermöglicht Datenbanktypische Zugriffe wie das Lesen, Löschen, Einfügen oder Ändern von Daten.24 Bei den Daten handelt es sich entweder um Operativ- oder um Verwaltungs-Daten. Die Verwaltungsdaten haben mit der eigentlichen Funktionalität nichts zu tun, werden aber benötigt, damit das System korrekt
arbeiten kann. Der Zugriff auf die Datenschicht erfolgt über die Logikschicht.
Logikschicht: Sie ist verantwortlich für die Auswertung der Nutzereingaben und
generiert daraus Suchanfragen, liest Daten aus der Datenschicht aus oder
führt die lokale Geschäftslogik und damit verbundenen Aktionen aus.25
Aus der Datenschicht ausgelesene Daten müssen für die Ansicht eventuell
noch aufbereitet werden. Zudem ist sie verantwortlich für die Beantwortung von Anfragen aus der Nachrichtenschicht und es werden die Antworten von Aufrufen/Anfragen für die Darstellungs- oder Datenschicht
aufbereitet.
Zusätzlich können noch Funktionen für die Erfüllung einer Master-Rolle
hinzukommen.
Darstellungsschicht Diese Sicht präsentiert die Daten und leitet die entgegengenommenen Nutzeraktionen an die Logikschicht weiter.26
10.2 Der Aufbau der Clients
Die Erkennung von Inkonsistenzen beziehungsweise Konflikten kann aus drei
Gründen nicht mehr durch ein zentrales Konfliktmanagement, wie in Teil I eingeführt, erfolgen. Erstens sollen auf die Server-Strukturen weitestgehend verzichtet werden, um die Clients in ihrer Unabhängigkeit zu unterstützen. Zweitens
kann der Server wegen der horizontalen Kommunikation keine Speicherabbilder
der Clients mehr führen. Und drittens können sich durch die „beliebigen“ Kommunikationsströme unter den Clients sehr komplizierte Abläufe ergeben, die die
Komplexität eines zentralen Konfliktmanagements extrem steigern würden und
eigentlich unmöglich macht.
23
Realisierung des Peer-to-Peer-Paradigma
Entspricht dem Model nach MVC (siehe [51]).
25
Entspricht dem Controller nach MVC (siehe [51]).
26
Entspricht der View nach MVC (siehe [51]).
24
80
10 nBIS im Detail
Um dennoch eine gewisse Sicherheit zu gewährleisten und die Clients sich nicht
vollkommen selbst zu überlassen, werden sogenannte Master-Knoten eingeführt,
wie es [35] vorschlägt.27 Diese sind für die Durchführung einer einfachen Konflikterkennung verantwortlich und stellen fest, ob ein Aufruf durchgeführt werden
darf beziehungsweise kann.
Neben der Konfliktbehandlung zur Erkennung und Behebung von Konflikten
kann die Synchronisation der einzelnen Teilnehmer Inkonsistenten vorbeugen. Je
besser die einzelnen Clients über die Vorgänge im Netz informiert sind und damit
auch deren Datenbestand aktueller ist, desto geringer ist die Wahrscheinlichkeit
für einen Konflikt.
Eine einfache Art der Synchronisation ist das verteilte Sperren von Daten, auch
als pessimistische Nebenläufigkeit bezeichnet, die manipuliert werden sollen.
Möchte ein Client Änderungen an seinen Daten vornehmen, so werden diese
Datensätze auf allen Clients gesperrt und erst dann kann die Änderung vorgenommen werden. Dadurch geht das Konfliktpotential gegen Null. Allerdings
gestaltet sich die Umsetzung des Sperrkonzepts in einem Peer-to-Peer-Netzwerk
als äußerst schwierig. Es gibt keine zentrale Instanz, die die Sperrverwaltung
übernehmen kann und durch das beliebige Kommen und Gehen der Teilnehmer
kann es leicht zu Verklemmungen kommen. Nach [24] vertausendfacht sich die
Wahrscheinlichkeit für einen Deadlock, wenn sich die Anzahl der Knoten von
Eins auf Zehn erhöht.
Andere Verfahren erlauben bewusst die parallele Manipulation gleicher Objekte,
auch als optimistische Nebenläufigkeit bezeichnet (siehe [58], und nehmen das
Auftreten von Konflikten in Kauf. Die Aufgabe der Master ist es, diese Konflikte zu erkennen und nach Möglichkeit zu beheben. Der daraus resultierenden
Nachrichtenablauf ist in Abbildung 21 dargestellt.
Um die Laufzeiten von Suchanfragen und Synchronisationsdaten zu verringern,
werden die einzelnen Teilnehmer in Anlehnung an [55] zusätzlich noch in Gruppen aufgeteilt. Die Aufteilung erfolgt dabei nach dem Prozessmodell, mit dem
der Anwender gerade arbeitet. Die Suchanfragen müssen dann nicht mehr an
alle Teilnehmer weitergeleitet werden, sondern nur noch an die Teilnehmer der
Gruppe, die in dem Suchbereich tätig sind. Zudem müssen die Clients nur noch
Synchronisationsdaten verarbeiten, die für sich auch interessant sind.
Durch die Verteilung der Daten und der Selbstständigkeit der Clients kann es
passieren, dass es verschiedenen Versionen eines Datums im Netz gibt. Um zu
erkennen, welches davon die aktuellste Version ist, wird jedes Datum mit einem
Zeitstempel versehen und im Allgemeinen dem jüngsten den Vorrang gelassen.
Hierfür ist es notwendig, dass die Uhren der einzelnen Teilnehmer synchronisiert
sind.
Die Schnittstellen und Funktionen der Clients können den Algorithmen 3 bis 7
entnommen werden. Die Pseudocodes geben einen Überblick über die einzelnen
Funktionen und deren Arbeitsweisen. In Abbildung 22 ist der Kommunikations27
In den Abbildungen 21 und 23 blau dargestellt
81
10 nBIS im Detail
Abbildung 21: Ablauf eines Aufrufs bei dem die Clients über eine Verbindung
zum Server verfügen (die Clients selbst sind untereinander auch
verbunden (siehe Abbildung 19))
fluss zwischen den einzeln Schichten in einem Flussdiagramm visualisiert (zur
besseren Übersicht leicht vereinfacht und ohne Rückgaben).
Die zusätzlichen Funktionen des Masters sind in Abbildung 25 dargestellt. Deren
Umsetzung ist analog zu denen in den zuvor erwähnten Algorithmen beschriebenen verfahren.
In den nachfolgenden Unterabschnitten 10.2.1 bis 10.2.3 sind die Abläufe einer Suchanfrage und eines Aufrufs detailliert beschrieben, um einen Überblick
über die Abhängigkeiten unter den Teilnehmern im Netzwerk zu vermitteln. Die
Erläuterungen stützen sich dabei auf die Abbildungen 21, 23 und 24.
Für einen erfolgreichen Kommunikationsverlauf ist immer der jeweilige Client
selbst verantwortlich. Das heißt, im Fehlerfall ist es die Aufgabe des Clients,
das Problem zu lösen. Entweder indem der Aufruf erneut gesendet wird oder
alternative Strategien zum Einsatz kommen. Die Master prüfen nicht, ob ihre
gesendeten Antworten auch empfangen worden sind.
82
10 nBIS im Detail
/* Einstiegspunkt für die Darstellungsschicht */
AufrufAusführen(aktion) {
wenn aktion == datenLesen dann
HoleDaten(aktion);
sonst
AufrufAusführen(aktion);
}
/* Einstiegspunkt für die Nachrichtenschicht */
NachrichtAuswerten(nachricht) {
unterscheide nachricht tue
Fall PrüfungErfolgt
AufrufPrüfungAuswerten(nachricht.GibAktion(),
nachricht.GibErgebnis());
Fall AufrufAufgenommen
MasterWurdeInformiert(nachricht.GibAktion(),
nachricht.GibErgebnis(), nachricht.GibDaten(),
nachricht.GibZeit());
Fall AufrufGemerkt
ServerWurdeInformiert(nachricht.GibAktion(),
nachricht.GibErgebnis(), nachricht.GibDaten(),
nachricht.GibZeit());
Fall ErgebnisDaten
DatensucheAbgeschlossen(nachricht.GibErgebnis());
Fall SyncDaten
Datenschicht.SchreibeDaten(nachricht.GibDaten());
Fall Suche*Daten
parameter = nachricht.;
daten = Datenschicht.HoleDaten(parameter );
wenn daten != leer dann
Nachrichtenschicht.Senden(ErgebnisDaten, daten);
sonst
/* Wenn keine passenden Daten vorhanden
Suchanfrage weiterleiten */
Nachrichtenschicht.Senden(nachricht);
sonst
MeldeFehler(nachricht);
}
Algorithmus 3 : Die Einstiegsfunktionen der Logikschicht
83
10 nBIS im Detail
/* Liest die Daten aus der lokalen Datenbank aus oder stellt
eine Anfrage an das Netz */
HoleDaten(aktion) {
parameter = aktion.GibParameter();
daten = Datenschicht.HoleDaten(parameter );
wenn daten == leer dann
/* Suchnachricht an das Netz senden */
wenn VerbindungZumNetz() dann
Nachrichtenschicht.Senden(SucheParameterDaten,
Suchradius());
sonst
MeldeFehler(”Das Gerät hat keine Verbindung!”);
sonst
MeldeErgebnis(daten);
}
/* Die Suche nach Daten ist abgeschlossen */
DatensucheAbgeschlossen(ergebnis) {
wenn ergebnis != fehler dann
daten = ergebnis.;
Datenschicht.SchreibeDaten(daten);
sonst
daten = ergebnis.GibFehler();
MeldeErgebnis(daten);
}
/* Führt einen Aufruf aus */
AufrufAusführen(aktion) {
wenn VerbindungZumMaster() dann
/* Aktion prüfen, dann AufrufPrüfungAuswerten() */
Nachrichtenschicht.Senden(PrüfeAufruf, aktion);
sonst
AufrufOfflineAusführen(aktion);
}
/* Aufruf offline ausführen */
AufrufOfflineAusführen(aktion) {
MAufrufInWsEinreihen(PrüfeAufruf, aktion, jetzt);
Logikschicht.LokaleLogikAusführen(aktion);
MeldeErgebnis(”Aufruf erfolgreich offline ausgeführt!”);
}
Algorithmus 4 : Die einzelnen Funktion der Logikschicht Teil 1
84
10 nBIS im Detail
/* Aufruf durch Master geprüft */
AufrufPrüfungAuswerten(aktion, ergebnis) {
wenn ergebnis == ok dann
/* startet lokale G.-Logik und gibt geänderte Daten */
daten = Logikschicht.LokaleLogikAusführen(aktion);
/* Master informieren, danach MasterWurdeInformiert()
*/
Nachrichtenschicht.Senden(AufrufErfolgt, daten, jetzt);
sonst wenn ergebnis == nichtOk dann
daten = ergebnis.GibErgebnisDaten();
wenn daten != leer dann
Datenschicht.SchreibeDaten(daten);
MeldeFehler(”Aufruf nicht erlaubt, neue Daten erhalten!”);
sonst
MeldeFehler(”Aufruf nicht erlaubt: ” ergebnis);
sonst
AufrufOfflineAusführen(aktion);
}
/* Master über Aufruf informiert */
MasterWurdeInformiert(aktion, ergebnis, daten, zeitpunkt) {
wenn VerbindungZumServer dann
/* Server informieren, dann ServerWurdeInformiert()
*/
Nachrichtenschicht.Senden(MerkeAufruf, daten, zeitpunkt);
sonst
/* Aufruf an Master einreihen */
MAufrufInWsEinreihen(AufrufErfolgt, aktion, daten, jetzt);
MeldeErgebnis(”Aufruf erfolgreich ohne Abgleich ausgeführt!”);
}
/* Server über Aufruf informiert */
ServerWurdeInformiert(aktion, ergebnis, daten, zeitpunkt) {
MeldeErgebnis(”Aufruf erfolgreich ausgeführt!”);
sonst
SAufrufInWsEinreihen(MerkeAufruf, aktion, daten, zeitpunkt);
ergebnis = Nachrichtenschicht.Senden(SendeSyncDaten, daten,
zeitpunkt);
MeldeErgebnis(”Aufruf erfolgreich ausgeführt!”);
sonst
MeldeErgebnis(”Aufruf ohne Abgleich ausgeführt!”);
}
Algorithmus 5 : Die einzelnen Funktion der Logikschicht Teil 2
85
10 nBIS im Detail
Abbildung 22: Die Abläufe in den einzelnen Schichten der nBIS-Architektur
86
10 nBIS im Detail
/* Daten in die Datenbank übernehmen, bei SyncDaten prüfen,
ob diese neuer als die eigenen Daten sind */
SchreibeDaten(daten) {
wenn daten == syncDaten dann
wenn daten älter sind als vorhandene Daten dann
zurück ;
SchreibeDatenInDB(daten);
}
/* Daten aus der lokalen Datenbank lesen */
HoleDaten(parameter ) {
zurück LeseDatenAusDB(parameter );
}
Algorithmus 6 : Die einzelnen Funktion der Datenschicht
10.2.1 Abläufe mit Verbindung zum Server
Abbildung 21 veranschaulicht den Ablauf eines Aufrufs28 , wobei die Clients über
eine Verbindung zu dem Server verfügen. Client acht ist dabei der Aufrufende
und Client sechs ein Master der Gruppe A. Im ersten Schritt nimmt Client acht
Kontakt zum Master auf und sendet PrüfeAufruf, um vom Master feststellen
zu lassen, ob der Aufruf zulässig ist. Ist das der Fall, empfängt er in Schritt zwei
PrüfungErfolgt. Client acht nimmt seine Änderungen vor und sendet diese im
dritten Schritt über AufrufErfolgt an den Master, damit dieser die Änderung
übernimmt. Erst wenn der Master das bestätigt hat, kann der nächste Schritt
folgen.
In diesem wird der Dienst-Server mittels MerkeAufruf ebenfalls über die Änderungen informiert, so dass dieser entsprechende Hintergrundprozesse ausführen
kann.29 Diese werden im fünften Schritt zusammen mit den Änderungen des
Clients an die Datenbank weitergegeben und deren korrekte Einpflegung in das
System in Schritt sechs und sieben an den Client zurückgemeldet.
Die Änderung der Daten in der Datenbank löst einen Multicast SyncDaten aus
(Schritt acht) der die Gruppe über die Änderung informiert. Sind diese Änderungen aktueller als die Daten auf den einzelnen Clients, so werden die Daten
vom Server übernommen. Andernfalls werden diese ignoriert.
Suchanfragen werden gezielt an den Server und Master gerichtet. Sie können
aber auch von anderen Clients beantwortet werden, die auf dem Routing-Weg
der Nachricht liegen. Hat ein Client, der die Anfrage beantwortet, die gesuchten
Daten bereits manipuliert, die Änderungen aber noch nicht mit dem Master
28
29
Ein Aufruf hat immer eine Datenmanipulation zur Folge.
Erstellung beziehungsweise Bearbeitung der Protokoll-Daten.
87
10 nBIS im Detail
/* Das Absenden einer Nachricht vorbereiten und diese der
Transportschicht übergeben. */
Senden(nachricht, parameter[] ) {
xmlNachricht = ErstelleNachricht(nachricht, parameter );
kodNachricht = KodiereNachricht(xmlNachricht);
i = 0;
solange i < 3 tue
ergebnis = Transportschicht.Senden(kodNachricht);
wenn kein TimeOut dann
abbruch ;
i++;
wenn i == 3 dann
Logikschicht.NachrichtAuswerten(”Nachricht nicht zustellbar!”);
}
/* Einstiegspunkt für Nachrichtenschicht */
Empfangen(nachricht) {
wenn ( GibEmpfänger() == ich) oder (nachricht == Suche*Daten)
dann
dekodNachricht = DekodiereNachricht(nachricht);
Logikschicht.NachrichtAuswerten(dekodNachricht);
sonst
Transportschicht.Senden(Nachricht);
}
/* Komprimiert die Nachricht für die Datenübertragung */
KodiereNachricht(nachricht)
{
...
}
/* Erzeugt eine Nachricht, die versendet werden soll */
ErstelleNachricht(nachricht,
parameter ) {
...
}
/* Dekodiert eine Nachricht, um sie in der Logikschicht
auswerten zu können */
DekodiereNachricht(nachricht)
{
...
}
Algorithmus 7 : Die einzelnen Funktion der Nachrichtenschicht
88
10 nBIS im Detail
Abbildung 23: Nachrichtenfluss in der neuen Architektur ohne Verbindung zum
Server (orange: Aufruf, grün: allgemeine Suchanfrage)
abgesprochen, werden diese gesondert gekennzeichnet. Ist dieses Verhalten, beispielsweise bei sensiblen Daten, unerwünscht, können die Nachrichten speziell
gekennzeichnet werden um zu signalisieren, dass diese nur vom Server oder Master beantwortet werden dürfen.
10.2.2 Abläufe ohne Verbindung zum Server
In Abbildung 23 sind die Nachrichtenabläufe dargestellt, wenn die Clients über
keine Verbindung zum Server verfügen. Der Ablauf eines Aufrufs ist orange
gezeichnet, der einer Suchanfrage grün.
Abbildung 24 zeigt nochmals den Ablauf in einem Sequenzdiagramm. Der Ablauf unterscheidet sich dabei kaum von dem vorangegangenen. Im ersten Schritt
wird wieder der Master befragt, ob der gewünschte Aufruf durchgeführt werden
darf. Ist dies der Fall, Schritt zwei, führt Client zwei den Aufruf aus und teilt
die Änderungen im dritten Schritt wieder dem Master mit.
89
10 nBIS im Detail
Abbildung 24: Darstellung eines Aufrufs ohne Verbindung zum Server in einem
Sequenzdiagramm
Falls der Client noch nicht über den Verbindungsverlust zum Server informiert
ist, versucht er im vierten Schritt wieder den Dienst-Server zu benachrichtigen. Weil dieser damit aber keinen Erfolg hat, wird daraufhin der Master
über SendeSyncDaten angewiesen, anstelle des Datenbank-Servers die restlichen Gruppenmitglieder über die Änderungen zu informieren. Der Aufruf wird
vom Client in eine Warteschlange aufgenommen, damit dieser zu einem späteren
Zeitpunkt an den Dienst-Server gesendet werden kann.
Auch der Ablauf einer Suchanfrage unterscheidet sich in der Vorgehensweise
kaum von der zuvor vorgestellten Konstellation (siehe Client fünf in Abbildung
23). Der Unterschied besteht nur darin, dass der Suchende keine Antwort mehr
von der Datenbank bekommen kann.
10.2.3 Abläufe ohne Verbindung zum Master
Hat ein Client weder eine Verbindung zu dem Master noch zu den Servern,
so arbeitet dieser bis zu einem erneuten Verbindungsaufbau selbstständig und
autonom mit der Gefahr, dass etwaig durchgeführte Aufrufe nicht erlaubt waren. Durchgeführte Aufrufe mit den zugehörigen Parametern, geänderten Daten
und dem Ausführungszeitpunkt werden dabei in die Warteschlange aufgenom90
10 nBIS im Detail
men, um sie später vom Master prüfen zu lassen und dem Server mitteilen zu
können. Dabei auf dem Master auftretende Konflikte sollten nach Möglichkeit
automatisch behoben werden.
Erreicht solch einen Client eine Suchanfrage, so kann er diese ebenfalls beantworten. Allerdings muss die Antwort speziell gekennzeichnet werden, damit für
den Empfänger der Antwort erkennbar ist, dass die Daten womöglich durch
einen irrtümlich ausgeführten Aufruf veraltet oder falsch sind.
Kann der Client zu einem späteren Zeitpunkt wieder eine Verbindung zum Master herstellen muss der Client erst seine Warteschlange leeren, bevor er erneut
Aufrufe durchführen kann. Seine Daten kann er aktualisieren, indem er den
Master befragt, was sich seit einem bestimmten Zeitpunkt geändert hat.
Das darunterliegende Netzwerk muss in diesem Fall auch dafür sorgen, dass der
„neue“ Netzteilnehmer Informationen darüber erhält, wie er andere Teilnehmer
erreichen kann.
10.2.4 Die Aufgaben des Masters
Die Hauptaufgabe des Masters besteht darin zu prüfen, ob die Aufrufe anderer
Teilnehmer durchgeführt werden dürfen oder nicht. Dazu muss dieser möglichst
immer über einen aktuellen Stand der Daten verfügen. Dies wird dadurch gewährleistet, dass jeder Teilnehmer, der einen Aufruf ausführt, sicherstellt, das
seine Änderungen auch vom Master übernommen werden.
Kann ein Client den Master nicht erreichen, könnte die Prüfung auch von einem
beliebigen anderen Teilnehmer des Netzes durchgeführt werden. Allerdings können seine Daten veraltet oder falsch sein, so dass die Überprüfung ein falsches
Ergebnis liefern würde. So böte die Überprüfung durch eine Gegenstelle keine
Vorteile mehr. Deswegen arbeitet der Client in diesem Fall selbstständig und
lässt seine Aufrufe zu einem späteren Zeitpunkt gegenprüfen, wenn er wieder
eine Verbindung zum Master hat.
Um die Master zu entlasten gibt es pro Gruppe mindestens einen. Dabei kann die
Rolle prinzipiell von jedem Teilnehmer übernommen werden. Aus PerformanceGründen sollte sie aber nur von leistungsstarken Gruppenmitgliedern ausgefüllt werden. Deswegen erfolgt die Benennung zum Master aufgrund technischer
Kenndaten, so dass das stärkste Mitglied der Gruppe diese Funktion übernimmt.
Neben den Prüf-Aufgaben kann der Master für das Senden von SyncDaten zuständig sein, wenn der aufrufende Client keine Verbindung zum Server, auch
nicht über andere Gruppenmitglieder, hat. Zudem hält er eine Liste, in der er
alle Änderungen chronologisch festhält, um einem Client alle gemachten Änderungen seit einem bestimmten Zeitpunkt übermitteln zu können.
Damit die Master möglichst unabhängig von der Datenbank arbeiten können,
laden sie sich während ihrer Initialisierung alle für die Gruppe relevanten Daten
in ihre Datenbank. Sollte es währenddessen zu Problemen kommen, versucht der
91
10 nBIS im Detail
Master dennoch seiner normalen Tätigkeit nachzukommen und die fehlenden
Daten zu einem späteren Zeitpunkt nachzuladen. Sollte ein Aufruf aufgrund
dieser fehlenden Daten nicht komplett geprüft werden können, so teilt er dies
dem Client mit. Dieser behandelt dann den Aufruf so, als wenn er nicht durch
einen Master gegengeprüft wäre.
Diese zusätzlichen Funktionen und deren Zuordnungen in die einzelnen Schichten der Architektur sind in Abbildung 25 veranschaulicht. Sie erweitern die
Logikschicht und sind zustandsunabhängig. Das heißt der Funktionsablauf ist
nicht abhängig von beispielsweise zuvor verarbeiteten Nachrichten. Das hat den
Vorteil, dass im Fehlerfall ein anderer Client die Master-Rolle ohne Probleme
übernehmen kann und macht die Kommunikationsverwaltung für den Master
einfach. Kann zum Beispiel seine Antwort nicht zugestellt werden, ist es die
Aufgabe des Anfragenden dies festzustellen und entsprechend zu reagieren und
nicht die des Masters, die Antwort erneut zu senden. Diese Herangehensweise
ermöglicht es, die Master-Funktionalitäten einfach und zuverlässig zu implementieren.
10.2.5 Die Aufgaben der Server
Die zentrale Position der Server ist wesentlich abgeschwächt worden. Der DienstServer erfüllt nur noch Routine-Aufgaben, um die Clients zu entlasten und das
Übertragungsvolumen zu verringern. Der Datenbank-Server ist weiterhin die
Wissensbasis des Systems, die ständig aktualisiert wird. Jeder Aufruf wird durch
den Dienst-Server verarbeitet und in der Datenbank protokolliert.
Bei der Übernahme der geänderten Daten durch den Datenbank-Server ist darauf zu achten, dass nur Änderungen übernommen werden, die einen jüngeren
Änderungszeitpunkt aufweisen als die zu überschreibenden Daten in der Datenbank. Andernfalls wird der Aufruf nur protokolliert und die Änderungen
verworfen. Kommt es doch zu einer Änderung werden die übrigen Teilnehmer
der Gruppe darüber informiert.
10.2.6 Das Leeren der Warteschlangen
Die in die Warteschlangen eingereihten Nachrichten werden gemäß ihres Einfügezeitpunktes ausgelesen und abgesendet. Alle darauf basierenden Aktionen
steht der Zeitpunkt des eigentlichen Aufrufs zur Verfügung. So können Vorgänge
für den richtigen Zeitpunkt protokolliert und der Abgleich von Daten korrekt
vorgenommen werden.
10.2.7 Bewertung
Durch die Verlagerung der Geschäftslogik auf die Clients können diese unabhängig arbeiten und dank der horizontalen Kommunikation können sie auch dann
an neue Informationen gelangen, wenn der Server nicht erreichbar ist. Dennoch
92
10 nBIS im Detail
Abbildung 25: Darstellung der zusätzlichen Funktionen und deren Einordnung
im Schichtmodell des Masters
93
10 nBIS im Detail
ist das System durch den Einsatz der Master relativ gut gegen fehlerhafte Daten
und den daraus resultierenden Problemen geschützt, ohne auf die Vorteile des
Peer-to-Peer-Paradigmas zu verzichten.
Die Art der Kommunikation ist rein datenorientiert und nicht mehr wie in Teil
I eine Mischung aus daten- und dienstorientierter Kommunikation. Das Aufgabengebiet des Webservice-Server hat sich allerdings komplett gewandelt. Er
bietet keine Dienste zur Erfüllung der eigentlichen Aufgaben mehr an, sondern
erledigt nur noch Aufgaben, die im Hintergrund ausgeführt werden können, um
die Clients zu entlasten.
Tabelle 7 gibt einen kurzen Überblick über die einzelnen Nachrichten, die in
nBIS ausgetauscht werden. Es sind die notwendigen Parameter aufgelistet und
der Verwendungszweck der Nachricht näher erläutert. Tabelle 8 gibt nochmals
eine kurze Übersicht über die einzelnen Aufgaben der Teilnehmer.
Nachricht
Suche*Daten
ErgebnisDaten
PrüfeAufruf
PrüfungErfolgt
MerkeAufruf
Parameter
• Schlüssel
• Gruppe
• Nur Server/MasterAntwort
• Daten
• Sind_OfflineDaten
• Aufruf
• Parameter, Daten
• Ergebnis
•
•
•
•
•
Aufruf
Parameter
Daten
Ist_veraltet
Zeitpunkt
Beschreibung
Suche nach bestimmten Daten,
bspw. die eines Wagens, in einer
bestimmten Gruppe. Der letzte
Parameter gibt an, ob die Anfrage nur vom Server bzw. Master beantwortet werden darf.
Ergebnis einer Suchanfrage,
eventuell mit Angabe, dass
Daten veraltet sein können.
Master wird aufgefordert den
Aufruf mit Hilfe der Daten zu
prüfen.
Antwort des Masters, ob die
Prüfung erfolgreich war. Falls
nicht eventuell auch neue Daten zur Aktualisierung des Clients.
Sendet den Aufruf an den
Dienstserver mit den geänderten Daten und dem Zeitpunkt
der Änderung. Ist veraltet gibt
an, ob der Aufruf aus einer Warteschlange entnommen
wurde. Es darf dann kein Multicast durch die Datenbank erfolgen.
94
10 nBIS im Detail
Nachricht
Parameter
AufrufGemerkt
SendeSyncDaten
• Daten
• Zeitpunkt
SyncDaten
•
•
•
•
•
AufrufErfolgt
Daten
Zeitpunkt
Gruppe
Daten
Zeitpunkt
AufrufAufgenommen
Beschreibung
Antwort des Servers, dass der
zuvor empfangene Aufruf vom
Server verarbeitet worden ist.
Fordert den Master auf, die geänderten Daten mit der Zeitpunkt der Änderung an die
restlichen Teilnehmer des Netzes zu senden.
Informiert Clients einer Gruppe der Änderung inklusive Zeitpunkt.
Informiert Master über eine erfolgreiche Durchführung eines
Aufrufs und teilt diesem geänderten Daten und Zeitpunkt
mit.
Antwort des Masters, dass er
die zuvor mitgeteilten Änderungen übernommen hat.
Tabelle 7: Auflistung der einzelnen Nachrichten in nBIS
Teilnehmer
Master
Client
Dienst-Server
Datenbank-Server
Aufgaben
• Aufrufe anderer Gruppenmitglieder überprüfen
• SyncDaten-Nachricht versenden, wenn Client Server nicht erreichen kann
• „normale“ Client-Aufgaben
• Chronologische Auflistung aller Änderungen führen
• Funktionalität des BIS über lokale Geschäftslogik
bereitstellen
• Verarbeitung von SyncDaten
• Verwaltung von Warteschlangen
• Suchanfragen beantworten
• Hintergrunddienste ausführen
• Datenänderungen an den Datenbank-Server weiterleiten
• Datenänderungen in die Datenbank übernehmen,
sofern diese neuer sind
• Bei Übernahme einen Multicast auslösen und
Gruppe über Änderung informieren
• Suchanfragen beantworten
Tabelle 8: Kurze Zusammenfassung der Aufgaben der Teilnehmer in nBIS
95
Abschließend gibt Abbildung 26 noch einen kurzen Überblick über die verschiedenen Technologien, die zum Einsatz kommen können. Die Entscheidungen für
konkrete Technologien müssen dann jeweils von Realisierung zu Realisierung neu
getroffen werden und hängen von den eingesetzten Geräten und Technologien
zur Vernetzung ab.
Abbildung 26: Kurzer Überblick über mögliche einsetzbare Technologien
Das hier erarbeitete Konzept lässt sich nicht nur im Dispositionsbereich einsetzen. Es kann relativ leicht verallgemeinert und an die Bedürfnisse anderer
Anwendungsgebiete angepasst werden, sofern das darunterliegende Netzwerk
die in Kapitel 9.2.1 beschriebenen Anforderungen erfüllt.
Aus diesem Grund kann das Konzept in allen Systemen zum Einsatz kommen,
in denen ein Peer-to-Peer-Netzwerk eingesetzt wird beziehungsweise werden soll
96
und auf den Einsatz zentraler Serversysteme nicht verzichtet werden kann. Es
muss lediglich festgelegt werden, welche Funktionalitäten auf die Clients übertragen werden sollen. Dies legt also fest, welche Aufgaben die Clients auch ohne
Server-Hilfe selbstständig bewerkstelligen können sollen. Dementsprechend müssen auch die Daten nach Protokoll- und Operativ-Daten aufgeteilt werden.
Die Aufteilung sollte dabei nach dem Prinzip: „So viele Protokoll-Daten (ServerFunktionalität) wie nötig, so wenige Operativ-Daten (Client-Funktionalität) wie
möglich.“ erfolgen. Je allgemeiner eine Funktion ist und umso weniger sie mit
der eigentlichen Erfüllung der Aufgaben zu tun hat, desto mehr ist sie für die
Server-Seite prädestiniert.
Ein weiteres mögliches Anwendungsszenario ist beispielsweise der Einsatz auf
einem großen Messegelände, dass neben der Messe zusätzliche virtuelle Dienste
zur Verfügung stellt, wie zum Beispiel ein Reservierungssystem für Veranstaltungen.
Durch die Einführung von Peer-to-Peer-Strukturen ist das Netz wesentlich flexibler geworden, ohne dabei Verluste bezüglich der Datenhaltung hinnehmen zu
müssen.30 Dank der Trennung zwischen Protokoll- und Operativ-Daten werden
die einzelnen Teilnehmer nicht unnötig durch zusätzliche Daten und Funktionen
belastet und können sich stattdessen auf ihre originären Aufgaben konzentrieren.
Die Einführung des Master-Konzepts bewirkt, dass auch leistungsschwache Teilnehmer des Netzes nicht benachteiligt werden, indem sie nicht durch zusätzliche
Aufgaben wie das Absenden von Multicast-Nachrichten oder der Durchführung
von Konsistenzprüfungen belastet werden. Zudem schränken sie die Wahrscheinlichkeit für einen Fehler aufgrund inkonsistenter Daten stark ein.
Ein Master ist jeweils für eine ganze Gruppe verantwortlich und sollte deswegen
über ausreichende Ressourcen verfügen. Für die richtige Auswahl des Masters
unter den Teilnehmern der Gruppe ist deshalb noch eine hinreichende Funktion
zu entwickeln, die die einzelnen technischen Kenndaten wie Prozessorleistung
und Netzanbindung gewichtet und die Teilnehmer besser vergleichbar macht.
Kann das System auf die Konsistenzprüfungen durch die Master verzichten, weil
beispielsweise nur informative/lesbare Daten ausgetauscht werden, können die
Master auch entfallen.
Im Allgemeinen ist es so, dass die Master über aktuellere Daten verfügen als
die Server. Um diesem vorzubeugen könnte bei Bedarf eine zusätzliche Synchronisation zwischen Server und Master eingeführt werden. Aber auch ohne diese
wird es im Normalfall nicht dazu kommen, dass den Server bestimmte Daten
30
In einem reinen Peer-to-Peer-Netzwerk stehen die Daten der einzelnen Clients nur solange
zur Verfügung, wie diese am Netz teilnehmen.
97
nie erreichen werden.
Wichtig für die Gesamtperformance des Netzes ist es, dass die Nachrichtenverarbeitung möglichst effizient implementiert wird, damit beispielsweise Suchanfragen zügig beantwortet werden können. Hierfür könnte man noch über die
Einführung von Metadaten, die die eigentlichen Daten zusammenfassen und beschreiben, nachdenken. Dadurch kann man ermitteln, ob eine weitere Suche auf
dem Client überhaupt sinnvoll ist und so die Gruppe noch weiter segmentieren,
um den Suchradius weiter einzuschränken.
Nachfolgende Arbeiten sollten sich deshalb mit dem Einsatz verschiedener möglicher Technologien und Implementierungsvarianten näher befassen, um das
Konzept so effizient wie möglich in die Realität umsetzen zu können.
98
Anhang
99
Literaturverzeichnis
[1] ANts P2P.
21.11.2006
http://sourceforge.net/projects/antsp2p,
Abruf:
[2] Gesellschaft für Informatik e.V. http://www.gi-ev.de, Abruf: 20.02.2007
[3] JXTA. http://www.jxta.org, Abruf: 20.02.2007
[4] Mute. http://mute-net.sourceforge.net, Abruf: 21.11.2006
[5] Napster. http://www.napster.de, Abruf: 21.11.2006
[6] OASIS. http://www.oasis-open.org, Abruf: 03.12.2006
[7] Open Mobile Alliance.
29.03.2007
http://www.openmobilealliance.org, Abruf:
[8] SAP. http://www.sap.de, Abruf: 13.11.2006
[9] SETI@home. http://www.setiathome.de, Abruf: 22.12.2006
[10] Syncing.net. http://www.syncing.net, Abruf: 04.03.2007
[11] SyncML.
http://www.openmobilealliance.org/tech/affiliates/
syncml/syncmlindex.html, Abruf: 02.03.2007
[12] UMA Technology. http://www.umatechnology.org, Abruf: 15.03.2007
[13] University of California, Berkeley.
15.11.2006
http://www.berkeley.edu, Abruf:
[14] WASTE. http://waste.sourceforge.net, Abruf: 21.11.2006
[15] Wi-Mesh proposal for IEEE 802.11s. http://www.wi-mesh.org, Abruf:
17.02.2007
[16] Babenhauserheide, A. u. a.: GnuFU: Gnutella für Benutzer / GnuFU. Version: 30. November 2003. http://basis.gnufu.net/gnufu/
index.php/GnuFU_de, Abruf: 29.03.2007. 2003
[17] Bager, J.: Im Gleichtakt. In: c’t 13 (2006), Juni, S. 230–233
[18] Bishop, M. A.: Computer security: art and science. Addison-Wesley, 2003.
– ISBN 0201440997
[19] Dudenredaktion (Hrsg.): Duden: Das Fremdwörterbuch. 9. Auflage.
Mannheim : Bibliographisches Institut, 2006. – ISBN 3411040599
[20] Dumbill, E.: SyncML toolkits: Open source options for implementing
the protocol. In: XML Watch (2003), 6. Juni. http://www-128.ibm.com/
developerworks/xml/library/x-syncml3.html, Abruf: 02.03.2007
i
[21] Eilebrecht, K. und Starke, G.: Patterns kompakt: Entwurfsmuster für
effektive Software-Entwicklung. 2. Auflage. Spektrum Akademischer Verlag,
2006. – ISBN 3827415918
[22] Extended Systems: OneBridge auf der TechEd als beste mobile Lösung
ausgezeichnet. http://resolution.extendedsystems.com/ESIde/Ueber+
uns/Presse/TechEdAward.htm, Abruf: 04.11.2006
[23] Fetzer, C.:
Systems Engineering
/ Fakultät Informatik, TU
Dresden2006. http://wwwse.inf.tu-dresden.de/index.php?language=
English&site=courses&course=ws06vl01, Abruf: 11.11.2006. 2006
[24] Gray, J.; Helland, P.; O‘Neil, P. und Shasha, D.: The dangers of
replication and a solution. In: ACM SIGMOD (1996), S. 173–182
[25] GSM Association: GPRS Platform. http://www.gsmworld.com/
technology/gprs/index.shtml, Abruf: 20.03.2007
[26] Hübsch, C.: Synchronisation von Peer-to-Peer-basierten MultiplayerAnwendungen mit Echtzeitanforderungen in Ad-Hoc-Netzen, Institut für
Telematik, Universität Karlsruhe, Diplomarbeit, 2006. http://www.tm.
uka.de/itm, Abruf: 15.02.2007
[27] Hermann, W.: In zehn Schritten zur Service-Oriented Architecture. In:
Computerwoche.de (2005), Dezember. http://www.computerwoche.de/
produkte_technik/software/569662, Abruf: 07.12.2006
[28] iAnywhere Solutions Inc.: OneBridge. http://www.ianywhere.com/
deutschland/products/onebridge.html, Abruf: 04.11.2006
[29] iAnywhere Solutions Inc.:
OneBridge Mobile Data Suite.
http://www.extendedsystems.de/web/content.aspx?key=
E57CE571BED869691C8C1B02E3B42993, Abruf: 04.11.2006
[30] iAnywhere Solutions Inc.: OneBridge Mobile Groupware Data Sheet
- Deutsch, http://www.extendedsystems.com/web/media/uploads/omg_
d_130206.pdf, Abruf: 04.11.2006
[31] iAnywhere Solutions Inc.:
OneBridge Monitoring Service.
http://www.ianywhere.com/deutschland/datasheets/onebridge_
monitoring.html, Abruf: 04.11.2006
[32] iAnywhere Solutions Inc.: Sybase Completes Acquisition of Extended
Systems. Version: 26. Oktober 2005. http://www.ianywhere.com/press_
releases/extended_systems.html, Abruf: 26.10.2006
[33] ITSD Consulting: iAnywhere. http://www.itsd-consulting.de/
iAnywhere.28.0.html, Abruf: 04.11.2006
[34] Kirk, P.: Gnutella. Version: 2003. http://rfc-gnutella.sourceforge.
net, Abruf: 12.01.2007
ii
[35] Klan, D.: Replikation in Peer-to-Peer Systemen, Fakultät für Informatik und Automatisierung, TU Ilmenau, Diplomarbeit, April 2006. http:
//mordor.prakinf.tu-ilmenau.de/papers/dbis/2006/Witt06.pdf, Abruf: 28.11.2006
[36] Kureshy, A.: Architecting Disconnected Mobile Applications Using
a Service Oriented Architecture. In: MSDN Library (2004), September. http://msdn2.microsoft.com/en-us/library/ms838177.aspx, Abruf: 02.11.2006
[37] Larman, C.: UML 2 und Patterns angewendet: Objektorientierte Softwareentwicklung. 1. Auflage. Bonn : mitp-Verlag, 2005. – ISBN 3826614534
[38] MacKenzie, C. M.; Laskey, K.; McCabe, F.; Brown, P. F.; Metz,
R. und Allen, B.: Reference Model for Service Oriented Architecture
1.0 / OASIS2. August 2006. http://www.oasis-open.org/committees/
download.php/19679/soa-rm-cs.pdf, Abruf: 05.12.2006. 2006
[39] Maymounkov, P. und Mazières, D.: Kademlia: A Peer-to-peer Information System Based on the XOR Metric / New York University. 2002
[40] MSDN Deutschland: .NET Framework: Anwendungsentwicklung mit
der .NET-Klassenbibliothek. http://www.microsoft.com/germany/msdn/
netframework/default.mspx, Abruf: 29.03.2007
[41] MSDN Deutschland: Das .NET Compact Framework. Version: 11.
November 2004. http://www.microsoft.com/germany/msdn/library/
mobility/windowsmobile/pocketpc/DasNETCompactFramework.mspx?
mfr=true, Abruf: 29.03.2007
[42] Network, Sun D.: The Java ME Platform: the Most Ubiquitous Application Platform for Mobile Devices. http://java.sun.com/javame/index.
jsp, Abruf: 29.03.2007
[43] OASIS: OASIS SOA Reference Model TC. http://www.oasis-open.org/
committees/tc_home.php?wg_abbrev=soa-rm, Abruf: 05.12.2006
[44] Parys, D. und Mauerer, J.:
SOA (Service Oriented Architecture).
In: MDSN Library (2004), 14. November.
http:
//www.microsoft.com/germany/msdn/library/enterprise/
SOAServiceOrientedArchitecture.mspx?mfr=true, Abruf: 02.11.2006
[45] Pfitzmann, A.: Professur Datenschutz und Datensicherheit, Fakultät
Informatik, TU Dresden. http://www.inf.tu-dresden.de/index.php?
node_id=442, Abruf: 13.12.2006
[46] Resnick, P.: Internet Message Format. Network Working Group, April
2001. http://www.ietf.org/rfc/rfc2822.txt, Abruf: 18.12.2006
[47] Schill, A.:
Service-Oriented Architectures: Potential and Challenges / Fakultät Informatik, TU DresdenSeptember 2005. http:
iii
Tabellenverzeichnis
//www.rn.inf.tu-dresden.de/scripts/scripts_lsrn/veroeffent_
print/crimico_2005_0.pdf, Abruf: 15.10.2006. 2005
[48] Schiller, J.: Mobilkommunikation. 2. Auflage. Pearson Studium, 2003. –
ISBN 3827370604
[49] Schindelhauer, C.: Mitglied der Fachgruppe Algorithmen und Komplexität, Heinz Nixdorf Institut, Universität Paderborn. 2006
[50] Schwichtenberg, H.: Was ist Microsoft TechEd (TechEd)? http://
www.it-visions.de/glossar/alle/783/Microsoft%20TechEd.aspx, Abruf: 17.11.2006
[51] Shalloway, A. und Trott, J.: Design patterns explained: a new perspective on object-oriented design. 2. Auflage. Addison-Wesley Longman, 2005.
– ISBN 0321247140
[52] Shinder, T. W. und Shimonski, R. J.: Building DMZs for Enterprise
Networks. Syngress Media, 2003. – ISBN 1931836884
[53] Smith, R. E.: Authentication: from passwords to public keys. 1. Auflage.
Addison-Wesley, 2002. – ISBN 0201615991
[54] Steinmetz, R. und Wehrle, K.: Peer-to-Peer Systems and Applications.
1. Auflage. Springer-Verlag GmbH, 2005. – ISBN 354029192X
[55] Stoica, I.; Morris, R.; Karger, D.; Kaashoek, F. und Balakrishnan, H.: Chord: A scalable peer-to-peer lookup service for internet applications. In: SIGCOMM (2001)
[56] Tavli, B. und Heinzelman, W.: Mobile Ad Hoc Networks: EnergyEfficient Real-Time Data Communications. 1. Auflage. Springer-Verlag
GmbH, 2006. – ISBN 1402046324
[57] tecchannel:
WAP Binary XML (WBXML).
Version: 31.
Mai 2000.
http://www.tecchannel.de/netzwerk/networkworld/
technologyupdate/403295, Abruf: 27.10.2006
[58] Wikipedia: Optimistic Concurrency. http://de.wikipedia.org/wiki/
Optimistic_Concurrency, Abruf: 24.10.2006
[59] Wikipedia: Read-One-Write-All. http://de.wikipedia.org/wiki/ROWA,
Abruf: 20.10.2006
Tabellenverzeichnis
1
2
3
4
iv
Homogene Wertetabelle mit kompletten Daten
Homogene Wertetabelle mit lückenhaften Daten
Jede Änderung einzeln . . . . . . . . . . . . . .
Inhomogene Wertetabelle . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
40
40
40
40
Abbildungsverzeichnis
5
6
7
8
Einordnung der Funktionen des Webservice . . . . . . . . . . . .
Laufzeiten und übertragenes Datenvolumen eines Testszenarios
für verschiedene Konfigurationen . . . . . . . . . . . . . . . . . .
Auflistung der einzelnen Nachrichten in nBIS . . . . . . . . . . .
Kurze Zusammenfassung der Aufgaben der Teilnehmer in nBIS .
47
68
95
95
Abbildungsverzeichnis
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Die drei Schichten des MVC-Modells . . . . . . . . . . . . . . . .
Architektur des BIS-Systems inklusive mobiler Clients . . . . . .
Erfolgreicher und nicht erfolgreicher Nachrichtenaustausch mit
dem 2-Phasen-Commit-Protokoll . . . . . . . . . . . . . . . . . .
Funktionsweise der Datenreplikation . . . . . . . . . . . . . . . .
Funktionsweise der Funktionsreplikation . . . . . . . . . . . . . .
Übersicht über Basistechnologien für den Einsatz mit SOA [47] .
Schichten in einer offline-fähigen mobilen Anwendung . . . . . . .
Architektur von SOA . . . . . . . . . . . . . . . . . . . . . . . . .
Infrastruktur der OneBridge Mobile Platform [30] . . . . . . . . .
Die einzelnen Schichten der Client-Seite . . . . . . . . . . . . . .
Die einzelnen Schichten der Server-Seite . . . . . . . . . . . . . .
Sequenzdiagramm, welches den Ablauf im Agenten darstellt . . .
Flussdiagramm, dass die Verarbeitung eines Aufrufs im Agenten
darstellt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sequenzdiagramm über das Leeren der Warteschlange mit einem
Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sequenzdiagramm, welches den kompletten Verlauf der Synchronisation darstellt . . . . . . . . . . . . . . . . . . . . . . . . . . .
Stellt die Übertragungsvolumen in Byte der einzelnen Aufrufe der
verschiedenen Testläufe gegenüber . . . . . . . . . . . . . . . . .
Vergleicht die verstrichene Zeit zwischen Aufruf- und Antwortzeitpunkt der einzelnen Aufrufe . . . . . . . . . . . . . . . . . . .
Überblick über das (mo)BIS-System inklusive der Erweiterung . .
Darstellung eines logisch vollständig vermashtes, hybrides Peerto-Peer-Netzwerk . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die einzelnen Schichten der neuen Architektur auf den Clients . .
Ablauf eines Aufrufs bei dem die Clients über eine Verbindung
zum Server verfügen . . . . . . . . . . . . . . . . . . . . . . . . .
Die Abläufe in den einzelnen Schichten der nBIS-Architektur . .
Nachrichtenfluss in der neuen Architektur ohne Verbindung zum
Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Darstellung eines Aufrufs ohne Verbindung zum Server in einem
Sequenzdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . .
Darstellung der zusätzlichen Funktionen und deren Einordnung
im Schichtmodell des Masters . . . . . . . . . . . . . . . . . . . .
Kurzer Überblick über mögliche einsetzbare Technologien . . . .
Das mobile Gerät mit einem geöffneten Administrator-Dialog . .
15
17
18
20
21
26
30
31
32
50
50
53
54
56
63
67
67
70
78
79
82
86
89
90
93
96
viii
v
Eine kurze Einführung in die Arbeitsabläufe des BIS
28
29
30
31
Dialog
Dialog
Dialog
Dialog
zur
zur
zur
zur
Auswahl einer Lok . . . . . . . . .
Anzeige der Rangieraufträge . . .
Anzeige der Positionen nach einem
Anzeige der Warteschlange . . . .
. . . . . . . .
. . . . . . . .
Offline-Aufruf
. . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
ix
ix
ix
ix
Liste der Algorithmen
1
Ablauf des serverseitigen Konfliktmanagements . . . . . . . . . . . 42
2
Bildet die Differenz zwischen den Client- und den Server-Daten . . 58
3
Die Einstiegsfunktionen der Logikschicht . . . . . . . . . . . . . . 83
4
Die einzelnen Funktion der Logikschicht Teil 1 . . . . . . . . . . . 84
5
Die einzelnen Funktion der Logikschicht Teil 2 . . . . . . . . . . . 85
6
Die einzelnen Funktion der Datenschicht . . . . . . . . . . . . . . . 87
7
Die einzelnen Funktion der Nachrichtenschicht . . . . . . . . . . . 88
Listingverzeichnis
1
2
3
4
5
XML-kodierte Nachricht an den Webservice zum Starten der Synchronisation für die Lok „01“ . . . . . . . . . . . . . . . . . . . . .
XML-kodierte Antwort des Servers mit Änderungsanweisungen
für den Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XML-kodierte Sync-Bestätigung des Clients . . . . . . . . . . . .
XML-kodierte Antwort des Servers auf die Bestätigung . . . . . .
Ausschnitt aus der Konfigurationsdatei cfg_moBIS.txt . . . . . .
60
60
61
62
62
Eine kurze Einführung in die Arbeitsabläufe des BIS
Die für diese Arbeit notwendigen Grundkenntnisse beschränken sich auf die
Bereiche Eingangszugbehandlung und Disposition von Rangieraufträgen.
Im Bereich der Eingangszugbehandlung geht es um alle Aktivitäten, die im
Zusammenhang mit Zügen, die von außerhalb auf dem Werksgelände eintreffen,
durchgeführt werden können oder durchgeführt werden müssen. Ein Zug selbst
besteht aus mehreren Wagen, wobei diese beladen oder leer sein können. Die
Ankunftszeiten der Züge, die Reihung der Wagen, deren Ladezustand und so
weiter sind zwar im Voraus bekannt, aber bevor ein Zug aufgelöst werden kann,
das heißt die einzelnen Wagen über das Werksgelände verteilt werden, müssen
die Angaben überprüft werden.
Hierbei wird unter anderem überprüft, ob die Reihenfolge der Wagen mit den
Solldaten übereinstimmt, ob die Ladungsangaben richtig sind, die Bremseigenvi
Einblicke in die Anwendung moBIS
schaften stimmen. Dies wird im BIS-System erfasst und darin abgebildet. Das
dient zum einen der Erfüllung von Sicherheitsvorschriften, zum anderen verfügt
so das BIS immer über ein korrektes Abbild der Realität, auch wenn die Soll- mit
den Ist-Daten nicht übereinstimmen. Nach Abschluss dieser Arbeiten können die
einzelnen Wagen dem Zug entnommen werden, indem diese in Rangieraufträge
aufgenommen werden, die von Lokrangierführern ausgeführt werden.
Während der Zeit im Werksgelände kann ein Wagen verschiedene Stati besitzen. Die Wichtigsten sind „Bestand“, „disponiert“, „Transport“ und „zugestellt“.
Ist der Wagen im Status Bestand steht dieser auf einem Gleis und kann einem
beliebigen Rangierauftrag zugeordnet werden. Dadurch ändert sich der Status
in disponiert. Sobald der Auftrag begonnen wird wechselt der Wagen in den
Status Transport. Zu diesem Zeitpunkt ist der Wagen in Bewegung und besitzt
unter anderem kein Standortgleis mehr. Ist der Wagen am Zielgleis angekommen, wechselt der Wagen je nach Art des Rangierauftrags und Gleis wieder in
Bestand oder zugestellt.
Ein Rangierauftrag besteht aus ein bis mehreren Wagen, die als Positionen des
Rangierauftrags bezeichnet werden, den Start- und Zielgleisen der einzelnen
Wagen und einigen Informationen mehr. Grundsätzlich gibt es zwei Arten von
Aufträgen: sogenannte Umsetz-Aufträge und Zustell-Aufträge. Beim Umsetzen
wird der Wagen einfach von A nach B gefahren. Hierbei ist das Zielgleis ein
Ladegleis. Normalerweise kann der Wagen von diesem Gleis erst wieder entfernt
werden, wenn die Ladestelle den Wagen be- oder entladen hat.
Die Rangieraufträge werden von den Disponenten31 erstellt. Solange die Aufträge nicht in der Ausführung sind, können sie von den Disponenten beliebig
manipuliert werden. Sie können unter anderem einzelne Positionen entfernen,
neue hinzufügen, Start- oder Zielgleise ändern, mehrere Aufträge zu einem zusammenfassen oder ihnen eine andere Lok zuweisen.
Ein Rangierauftrag kann die Stati „erstellt“, „Transport“ und „unterbrochen“
annehmen. Ein erstellter Rangierauftrag ist ein neuer Auftrag, der noch nicht
begonnen worden ist. Sobald dem BIS gemeldet wird, dass der Rangierauftrag
begonnen worden ist, wird der Status auf Transport gesetzt. Jetzt kann der
Auftrag entweder beendet (alle Position haben ihr Ziel erreicht) oder pausiert
werden. In diesem Fall wechselt der Status nach unterbrochen. Sobald ein Auftrag beendet wird ist er erfüllt worden und die erbrachten Leistungen werden
abgerechnet.
Auf den Abbildungen 27-31 sind einige Screenshots der mobilen Anwendung
moBIS zu sehen. Diese sollen einen kleinen Überblick über den Aufbau und das
Verhalten der Anwendung vermitteln.
31
Mit der Einführung von moBIS können dies teilweise auch die Lokrangierführer selbst
vii
Abbildung 27: Das mobile Gerät mit einem geöffneten Administrator-Dialog
viii
Abbildung 28: Dialog zur Auswahl
einer Lok
Abbildung 29: Dialog zur Anzeige
der Rangieraufträge
der Positionen nach
einem Offline-Aufruf
der Warteschlange
ix
Glossar
Glossar
.NET Implementierung des Common-Language-Infrastructure-Standards für
Windows durch den Softwarehersteller Microsoft. Anwendungsprogramme für .NET liegen nicht in Maschinencode, sondern in einem Zwischencode vor und benötigen die .NET-Laufzeitumgebung, ähnlich wie etwa
Java-Programme eine Java Runtime Environment benötigen. [40]
.NET Compact Framework Teil der .NET-Umgebung von Microsoft, welches speziell auf die Bedürfnisse von ‘kleinen’ mobilen Endgeräten wie
Mobiltelefone und PDAs angepasst ist. [41]
2-Phasen-Commit-Protokoll Erlaubt das Senden von Transaktionen in verteilten System unter Wahrung der ACID-Eigenschaften (s. Abbildung
3).
ACID Das Akronym steht für atomicty (Atomarität), consistency (Konsistenz), isolation (Isoliertheit) und durability (Dauerhaftigkeit) und beschreibt im Allgemeinen die Eigenschaften von Transaktionen in Datenbanken oder verteilten Anwendungen. Diese sollen ‘ganz oder gar
nicht’ (atomar) durchgeführt werden, immer zum gleichen Ergebnis führen (konsistent), durchgeführt werden als wären sie alleine im System
(isoliert) und das Ergebnis soll erhalten bleiben (dauerhaft).
Alt-Daten-Konflikt Dieser Konflikt entsteht, wenn der Anwender der neuen,
mobilen Anwendung aus Teil I aufgrund veralteter auf seinem mobilen
Gerät Anweisungen falsch oder unvollständig ausführt.
BIS
Betriebsinformationssystem
Ist eine von CSC entwickelte verteilte Anwendung zur Disponierung und
Verwaltung von Betriebsdaten einer (Werks-)Eisenbahn.
Client-Server-Architektur Bei dieser Art der Netzwerkorganisation gibt es
einen zentralen Server, der die Ressourcen, wie zum Beispiel Webservices
oder eine Datenbank, zur Verfügung stellt. Diese können von den Clients
für die Verrichtung ihrer Arbeit genutzt werden.
Controller-Pattern Die Super-Klasse legt die Schnittstelle fest und beinhaltet
die grundlegenden Funktionalitäten. Die Kinder legen jeweils das konkrete Verhalten für einen bestimmten Anwendungsfall fest (siehe [37]).
Deadlock siehe Verklemmung
devInf Device Information
Enthält eine Beschreibungsstruktur über ein Gerät mit Name, Hersteller,
Version und eine Liste der unterstützten Dateiformate.
DMZ DeMilitarized Zone
x
Glossar
Besonders geschützter Bereich in einem Netzwerk, um die darin aufgestellten Systeme gegen andere Netze abzuschirmen. Dies erlaubt den Zugriff auf öffentlich erreichbare Dienste und schützt gleichzeitig das interne
LAN vor unberechtigten Zugriffen. [52]
DTO Data Transfer Object
Ist ein Pattern für die Entwicklung von verteilten Anwendungen. Es fasst
zu übertragende Daten in einem Objekt zusammen, um die Anzahl von
entfernten Methodenaufrufen zu reduzieren. [21]
Firewall Die Brandmauer dient dazu, interne Netzwerke, die mit dem Internet
verbunden sind, gegen unerlaubtes Eindringen zu schützen.
FTP File Transfer Protocol
FTP ist ein Protokoll zur Dateiübertragung in TCP/IP-Netzwerken.
GPRS General Packet Radio Service
Erweitert den GSM-Mobilfunk-Standard um eine paketorientierte Datenübertragung, welche auch als 2,5. Generation bekannt geworden ist.
Die Übertragungsgeschwindigkeit deutscher Anbieter von GPRS liegt in
der Regel zwischen 40 kbit/s und 55,6 kbit/s. [25] und [48]
Grid-Computing Hierbei handelt es sich um den Zusammenschluss verteilter und autonomer Ressourcen, meist über das Internet, um durch die
Bündelung ihrer Leistungen gemeinschaftlich ein Problem zu lösen.
HTTP HyperText Transfer Protocol
Ist ein Protokoll zur Übertragung von Daten in einem Netzwerk. Sehr
weite Verbreitung erreichte es durch den Einsatz im Internet zur Übertragung von Webseiten.
HTTPS HyperText Transfer Protocol Secure
Besitzt zusätzlich zu den Schichten des HTTP noch eine Sicherungsschicht, die Authentifizierungsaufgaben und Verschlüsselung durchführen
kann.
Idempotenz Bezeichnet die Eigenschaft einer Funktion. Diese Funktion liefert
mit sich selbst verknüpft das gleiche Ergebnis wie die einmalige Anwendung. Es gilt: f (x) = f (f (x))
IMEI International Mobile Equipment Identity
15-stellige Seriennummer anhand derer jedes GSM- und UMTS-Gerät
eindeutig identifiziert werden kann.
Internet Message Format siehe RFC 2822
Java ME siehe Java Micro Edition
Java Micro Edition Umsetzung der Java-Umgebung speziell für eingebettete
Systeme wie Mobiltelefone oder PDAs. [42]
xi
Glossar
JXTA JuXTApose
Der englischen Begriff ‘juxtapose’ bedeutet soviel wie Nebeneinanderstellung. Hierbei handelt es sich um ein Open-Source-Projekt, welches
Protokolle für die Standardisierung von Peer-to-Peer-Netzen entwickelt.
Näheres dazu siehe [3].
Kademlia-Algorithmus Hierbei handelt es sich um ein Protokoll für den Einsatz in Peer-to-Peer-Netzen. Es legt den Aufbau sowie die Art des Netzes
fest und beschreibt die Kommunikation zum Austausch von Informationen. Grundlage ist hierbei eine Funktion, die indirekt für jede Information einen dafür verantwortlichen Knoten bestimmt. [39]
LAN Local Area Network
Vernetzung mehrerer Rechner über kleine Entfernungen.
moBIS Mobiles BIS
Name für ein um einen mobilen Client erweitertes BIS-System.
Multi-Master-System Verteilte Daten können von mehreren Teilnehmern eines Netzes manipuliert werden.
MVC Model View Controller
Architekturmuster zur Aufteilung einer Anwendung in die drei Schichten Model, View und Controller. Das Model stellt die Datenbasis dar,
die View die Sicht auf die Daten und der Controller verarbeitet die Nutzereingaben. Veranschaulicht wird der Zusammenhang in Abbildung 1.
[51]
nBIS Neues BIS
Name der in Teil 2 entwickelten dezentral organisierten Struktur des
BIS-Systems. Die Grundlage bildet ein hybrides Peer-to-Peer-Netzwerk
anstelle einer Client-Server-Architektur.
OASIS Organization for the Advancement of Structured Information Standards
Hierbei handelt es sich um eine internationale Organisation, die sich mit
der Weiterentwicklung von Web-Services- und E-Business-Standards beschäftigt. Unter anderem war sie auch an der Entwicklung von ebXML
beteiligt. [6]
OBEX OBject EXchange
Verbindungsprotokoll zwischen zwei Geräten, welches nach dem ClientServer-Modell arbeitet.
OMA Open Mobile Alliance
Zusammenschluss bedeutender Dienstleister und Produktanbieter aus
dem Bereich Mobilfunk, um digitale und interoperable Dienste zu entwickeln und als Standard weltweit zu verbreiten. Unter anderem hat es die
Standards SyncML und Device Management geschaffen. [7]
xii
Glossar
OMAAT OneBridge Mobile Application Acceleration Toolkit
Frmework von OneBridge zur Unterstützung bei der Entwicklung einer
verteilten, offline-fähigen Anwendung.
Optimistische Datennebenläufigkeit Alle Nutzer des Netzwerks können jederzeit auf alle Daten lesend zugreifen. Wenn mehrere Nutzer gleichzeitig
schreiben, setzt sich die letzte Änderung durch.
PDA Personal Digital Assistant
Kleiner, tragbarer Computer, der ursprünglich für die Adress- und Terminverwaltung entwickelt worden ist. Dank immer besserer Hardware
haben sie sich inzwischen zu Multimedia-Geräten entwickelt, die auch
die Nutzung von relativ komplexen Anwendungen ermöglichen. Meist
verfügen sie zudem über diverse Schnittstellen, wie WLAN und Bluetooth, für einen flexiblen Netzzugriff.
Peer-to-Peer-Computing Zusammenschluss vieler autonomer und verteilter
Ressourcen, meist über das Internet, um durch die Bündelung ihrer Leistungen gemeinschaftlich Probleme zu lösen.
Pessimistische Datennebenläufigkeit Sobald ein Nutzer lesend oder schreibend auf die Daten zugreift, sind diese für alle anderen Teilnehmer des
Netzwerks gesperrt.
PIM Personal Information Manager
Programm zur Verwaltung von persönlichen Daten wie Aufgaben, Terminen und Kontakten. Darunter fallen aber auch Dokumente wie Faxe,
Briefe und E-Mails.
PM
siehe Prozessmodell
Positiv-Falsch-Konflikt Ein Positiv-Falsch-Konflikt entsteht, wenn die lokale
Geschäftslogik des mobilen Clients aus Teil I einen Aufruf erlaubt, eine
spätere Prüfung auf dem Server aber ergibt, dass der Aufruf hätte nicht
durchgeführt werden dürfen.
Proxy Als Proxy wird ein Stellvertreter bezeichnet, der aus Sicht des Servers
wie ein Client aussieht und aus Client-Sicht wie ein Server.
Prozessmodell Teil der Neuerungen aus Teil I zur einfachen Beschreibung der
Daten und Funktionen in der Erweiterung der mobilen Anwendung für
die Umsetzung der Offline-Fähigkeit. Ein Prozessmodell besteht aus den
drei Teilen Daten, Webservice-Aufrufe und lokale Geschäftslogik.
Prüfsumme Prüfsummen sind das Ergebnis einer Funktion über die zugrunde
liegenden Daten. Sie können eingesetzt werden, um beispielsweise die
Integrität der Daten sicher zu stellen. Hierzu zählen unter anderem HashFunktionen.
Referenzmodell Referenzmodelle können als Vergleichsobjekt herangezogen
werden und bilden oft die Grundlage für die Verbreitung von neuen Standards und Protokollen.
xiii
Glossar
RFC 2822 Request for Comments
Hierbei handelt es sich um technische und organisatorische Dokumente
rund um das Internet. Der Name RFC wird beibehalten, auch wenn sie
sich durch allgemeine Akzeptanz und Gebrauch zum Standard entwickelt
haben. RFC 2822 beschreibt die Syntax für E-Mails. [46]
ROWA Read One Write All
Ist ein synchrones Replikationsverfahren, bei dem die Schreiboperationen auf allen Replikaten durchgeführt werden und das Lesen auf einem
beliebigen Replikat erfolgen kann. [59]
SAP Systeme, Anwendungen und Produkte in der Datenverarbeitung
SAP, korrekterweise seit 2005 SAP AG [8], ist eine im DAX gelistete
Softwarefirma, die sich hauptsächlich im Bereich Geschäftsanwendungen
betätigt.
Service Oriented Architecture Methode, die versucht, die IT-Infrastruktur
an den Geschäftsprozessen im Unternehmen auszurichten, um diese flexibel und kosteneffizient zu gestalten.
SlowSync Synchronisations-Verfahren bei dem anstelle von nur geänderten
Daten die kompletten Daten ausgetauscht werden. Wird in der Regel
zur Initialisierung eingesetzt oder wenn die Gegenseite über falsche Daten verfügt.
SOA siehe Service Oriented Architecture
SOAP ehemals Simple Object Access Protocol
Das Protokoll erlaubt den Austausch von Daten zwischen zwei Systemen
und das Aufrufen von Remote Procedure Calls. Seit der Version 1.2 ist
SOAP kein Akronym mehr für Simple Object Access Protocol, sondern
direkt der Name des Protokolls.
SSH Secure Shell
Dahinter verbirgt sich ein Netzwerkprotokoll und Programm, mit dem
man sich über eine Netzwerkverbindung auf einem entfernten Rechner
einwählen kann, um dort beispielsweise Programme ausführen zu können.
SyncML Beschreibungssprache, die den Nachrichtenverkehr zu Synchronisationszwecken zwischen zwei Geräten, beispielsweise einem PC und einem
Handheld, spezifiziert.
TechEd Jährlich stattfindende Großveranstaltung von Microsoft, die sich an
Softwareentwickler und Infrastrukturexperten richtet. Im Normalfall gibt
es dort nur wenige Neu-Ankündigungen, es werden hauptsächlich vorhandene Technologien vermittelt. [50]
UDDI Universal Description, Discovery and Integration
Ist ein Verzeichnisdienst für dynamische Webservices. Diesen gibt es in
drei Varianten. Als ‘White Pages’, einer Art Telefonbuch, als ‘Yellow
xiv
Glossar
Pages’, was den Gelben Seiten entspricht und als ‘Green Pages’, die Informationen über die Geschäftsmodelle des Unternehmen und die technischen Details zu den Webservices enthält.
UMPC Ultra Mobile PC
UMPCs sind mit einem circa 7 Zoll großen TFT-Display ausgerüstet und
damit kleiner als Subnotebooks. Die Eingaben erfolgen wie bei einem
Tablet-PC über den berührungsempfindlichen Bildschirm.
Update-Anywhere-Prinzip Jeder Teilnehmer eines Netzes kann verteilte Daten manipulieren.
vCard Industriestandard zum Austausch elektronischer Visitenkarten.
VCDA Vodafone-CorporateDataAccess
GPRS-Zugang von Vodafone, der auch Anpassungen an spezielle Kundenwünsche erlaubt, wie feste IP-Adresse, Verschlüsselung und ähnliches.
Verklemmung Ein System ist verklemmt, wenn mindestens zwei Prozesse auf
gegenseitig gehaltene Ressourcen warten. Prozess A benötigt die Ressource α zur Weiterarbeit, die von Prozess B gehalten wird. B wiederum
benötigt Ressource β, die A besitzt.
WAP Wireless Application Protocol
Sammlung von Technologien und Protokollen, um Internetinhalte auch
auf Geräten mit langsamer Übertragungsrate und langen Antwortzeiten,
wie beim Mobilfunk, und kleinen Displays, wie bei Mobiltelefonen, verfügbar zu machen.
WBXML WAP Binary XML
Wird genutzt, um Daten, die im XML-Format vorliegen, so in Binärdaten
umzuwandeln, dass sie von WAP-Clients interpretiert werden können.
[57]
WSDL WebService Description Language
Plattformunabhängige XML-Spezifikation, um Netzwerkdienste (Webvices) zum Austausch von Nachrichten zu beschreiben.
WSP Wireless Session Protocol
Gehört zum Umfang von WAP und dient dem Aufbau von Sitzungen
zwischen dem WAP-Gateway und dem Endgerät.
Zeitstempel Besteht in der Regel aus einem Datum und einer Uhrzeit.
xv
Eigenständigkeitserklärung
Eigenständigkeitserklärung
Hiermit erkläre ich, Philipp Bönisch, dass ich die vorliegende Arbeit selbstständig verfasst, keine anderen als die angegebenen Hilfsmittel verwendet und die
Stellen, die anderen Werken dem Wortlaut nach entnommen sind, mit Quellenangaben kenntlich gemacht habe.
(Philipp Bönisch)
Dresden, den 31. März 2007
xvii

Mobile Erfassung von Dispositionsinformationen einer

Transcription

Similar documents

Midas M32 im Test Midas M32 Put to the Test

- volkswagen-media

Wollte ich schon immer mal

3 Datenbankzugriff in Java

Kurzbeschreibung im PDF