Datenbanksynchronisation

Transcription

Master Thesis 2006
1007_MASIT
Autoren:
Angelo Lo Iudice, Isidoro Lo Iudice
Examinator:
Bernhard Wyss
Co-Examinator:
Marc Löwenthal
Brugg-Windisch, 31. März 2009
Zusammenfassung
Aufgabe
Unsere Arbeit beschäftigt sich mit der Datenbanksynchronisation. Die Hauptaufgabe besteht
darin, Daten von einer Datenbank auf dem Client wie zum Beispiel PDA, Notebook oder
Desktop mit der Hauptdatenbank auf dem Server zu synchronisieren. Dabei müssen die
Daten in beider Richtung ausgeglichen werden. Das heisst, die Synchronisation muss
bidirektional sein. Als Austauschdaten sollen Koordinaten (Punkten) aus dem Vermessungswesen verwendet werden. Für die Datenverwaltung kommt ein einfaches und zweckmässiges Datenbank-Design zum Zuge. Die Daten werden mit Hilfe unseres Java Prototyps
GUI „survey“ erfasst, gelöscht und geändert. Der Prototyp GUI ist für diverse Datenbankmanagementsysteme einsetzbar und kann später mit Berechnungsfunktionen ausgebaut
werden. Diese Funktionen sind nicht Bestandteil dieser Arbeit.
Systemwahl
Drei Systeme haben wir evaluiert. Bei der Auswahl und Aufsetzung dieser Systeme haben
wir uns folgende Bedingungen festgelegt: Es soll ein homogenes und ein heterogenes
System dabei sein. Beim homogenen System soll der Hersteller alle nötigen Komponenten
wie die lokale Datenbank, die Hauptdatenbank und das Synchronisationswerkzeug liefern.
Beim heterogenen System sollen die verschiedenen Komponenten aus verschiedenen
Herstellern in einem Verbund miteinander arbeiten können. Unsere Recherchen führten zu
den drei Synchronisierungssystemen: Oracle Database Lite (homogenes System), Funambol
(heterogenes System) und Microsoft Synchronization Services for ADO.NET
(eingeschränktes heterogenes System). Die Microsoft Lösung verlangt MS SQL Server
Compact 3.5 als Client-Datenbank. Als Back-End-Datenbank kann eine beliebige Datenbank
eingesetzt werden, für die ein ADO.NET Provider existiert.
System I
Das erste System ist ein reines Oracle Produkt, das auf Windows, Linux und Unix Version
laufen kann. Oracle Database Lite ist eine Middleware „Mobile Server“, die mit einer Oracle
Back-End-Datanbank kommuniziert. Auf dem Client wird eine kleine „footprint“ Oracle
Datenbank installiert. Oracle Database Lite ist für unseren Einsatz eine „out of the box“Lösung. Es sind keine Programmieraufgaben notwendig. Aber die Konfiguration
beziehungsweise die Installation kann durchaus viel Zeit in Anspruch nehmen, denn die
Dokumentation von Oracle ist sehr umfangreich. Oracle Database Lite beinhaltet auch ein
Deployment- und ein Package-Management. Mit dem Package-Management kann unser
Prototyp GUI zu einem Software-Paket verarbeitet werden. Das Software-Paket kann nun via
Deployment-Management auf die Clients sehr einfach verteilt und installiert werden. Diese
lassen sich mit dem webbasierten Management-Tool verwalten. Das Besondere an Oracle
Database Lite ist, dass der Mobile Client nicht auf der Middleware „Mobile Server“ installiert
werden darf und zudem kann pro Gerät nur ein Benutzer zugewiesen werden.
Die Synchronisation beim Oracle Database Lite wird über drei Warteschlangen (IN-, OUTund ERROR-Queue) geregelt. Der Mobile Client schickt seine modifizierten Datensätze an
den Mobile Server, die in der IN-Queue ankommen. Anschliessend nimmt er von der OUTQueue vorhandene Datensätze in Empfang. Der Message Generator and Processor (MGP),
ist das Bindeglied zwischen den verschiedenen Queues und der Hauptdatenbank. Bei
Konflikten legt der MGP die Daten in der ERROR-Queue ab. Der Administrator muss später
entscheiden, wie die Konflikte gelöst werden sollen. Ausserdem kann zwischen eine
manuelle und eine automatische Synchronisation gewählt werden.
II
System II
Funambol ist eine OpenSource Lösung, die in Java programmiert ist. Die Applikation stützt
sich auf die SyncML Technologie ab, um die Daten zwischen zwei Anwendungsgeräte
auszutauschen. Wie auch Oracle Database Lite ist der Funambol Server als Windows und
Linux Version erhältlich. Als Basis des Funambol DS Servers dient entweder der
Applikations-Server Tomcat oder der Applikations-Server JBoss. Im Installationsbundle, der
von der Website gratis heruntergeladen werden kann, ist bereits Apache Tomcat enthalten.
Um Komplikationen zu vermeiden, empfehlen wir den Installationsbundle zu verwenden und
nicht die einzelnen Komponenten des Bundles manuell und getrennt zu installieren.
Bei der Synchronisation werden vier Komponenten durchlaufen; Sync Adaptor, Pipeline
Manager, Sync Engine und Sync Source. Der Sync Adaptor nimmt die XML-basierte
SyncML-Nachrichten des Clients entgegen, wandelt sie um und übergibt sie dem Pipeline
Manager und/oder der umgekehrte Vorgang, um die Daten zum Client zu senden. Der
Pipeline Manager besteht aus zwei Teilen: In- und Out-Pipeline. Diese dienen zur Filterung
und Protokollierung der Daten. Die Sync Engine ist das Herz des Funambol DS Servers und
befasst sich mit den Funktionen des SyncML Protokolls. Sie wickelt drei Phasen ab:
Initialisierung, Datenaustausch und Finalisierung. Der Sync Source bildet die Schnittstelle
zur Back-End-Datenbank und greift auf die von einem mobilen Gerät zu synchronisierenden
Daten zu.
Die Firma Funambol stellt mehrere Clients (sogenannte PIM-Clients) zur Verfügung, um die
Daten wie Kalender-, E-Mailsdaten, Dateien zu synchronisieren. Zu unserem Bedauern gibt
es kein Client, um die Daten aus einem beliebigen Datenbankschema zu aktualisieren.
Funambol hat aber ein API (Application Programming Interface), mit dem wir einen eigenen
Synchronisierungs-Client und Connector programmieren können. Auch hier gibt es
Dokumente, die uns bei der Programmierung unterstützt haben. Der SynchronisierungsClient kommuniziert zwischen der lokalen Datenbank und dem Funambol-Server. Der
Connector baut die Verbindung zwischen dem Funambol-Server und der Haupdatenbank
auf. Der Connector entspricht dem oben erwähnten Sync Source.
Zurzeit unterstützt Funambol die drei Datenbankmanagement-Systeme MySQL, HSQLDB
und PostgreSQL. In unserer Umgebung haben wir MySQL als Back-End-Datenbank und
HSQLDB als lokale Datenbank verwendet. Um die korrekte Synchronisation zu ermöglichen,
mussten wir unser Datenbankschema erweitern. Zwei weitere Spalten „fmbstatus“ und
„fmbtimestamp“ sind in unsere Tabelle „tabkoord“ hinzugefügt worden. Dank dieser Spalten
lassen sich der Zeitstempel und die Statusart der manipulierten Datensätze eruieren, die an
der Synchronisation teilnehmen müssen. Es ist wichtig, dass in der Hauptdatenbank keine
Datensätze gelöscht werden, sondern dass sie als gelöscht markiert sind (Statusart = D).
Das Funambol Administration Tool dient zur Verwaltung von Servereigenschaften,
Benutzern, Geräten und Module. Geübte Administratoren können die mit dem Administration
Tool eingestellten Parameter auch direkt in den XML-basierten Dateien anpassen. Funambol
erlaubt, dass ein Benutzer mehrere Geräte verwenden kann und/oder ein Gerät kann von
mehreren Benutzern benutzt werden. Leider unterstützt Funambol nur die manuelle
Synchronisation.
System III
Als letztes System haben wir Microsoft Synchronization Services for ADO.NET unter die
Lupe genommen. Microsoft Synchronization Services for ADO.NET ist eine Komponente des
Microsoft Sync Frameworks, die nur auf den Microsoft Betriebssystemen läuft und basiert auf
die ADO.NET-Architektur. Das Framework unterstützt im Wesentlichen zwei Szenarien:
offline- und Zusammenarbeits-Szenario. Das offline-Szenario deckt unsere Anforderungen
III
ab. Der Synchronisations-Client steht in Form eines API zur Verfügung. Wir haben uns mit
Hilfe der Microsoft online-Dokumentation und Code-Beispiele (http://msdn.microsoft.com)
das Wissen angeeignet, um den Synchronisations-Client zu entwickeln. Als lokale
Datenbank muss der kostenlose MS SQL Server Compact 3.5 eingesetzt werden. Als
Hauptdatenbank wird in unserem Fall MS SQL Server 2005 Express Edition verwendet.
Grund für diesen Entscheid ist, dass für diese ebenfalls kostenlose Datenbank Version ein
Verwaltungswerkzeug „Microsoft SQL Server Management Studio Express“ installiert werden
kann, das uns erlaubt die Datenbank einfach zu verwalten. Als Back-End-Datenbank können
beliebige Datenbanken verwendet werden, für die ein ADO.NET Provider zur Verfügung
steht. Ähnlich wie bei Funambol müssen wir auch bei diesem System unser Datenbankschema anpassen. Unsere Tabelle „tabkoord“ muss mit vier zusätzlichen Spalten erweitert
werden. Zudem benötigt der Microsoft Synchronization Services eine weitere Tabelle, die als
Tombstone in unserem Fall „tabkoord_Tombstone“ bezeichnet wird. Diese Tabelle verwaltet
die gelöschten Datensätze. Nebst diesen Anpassungen benötigen wir einen Trigger für die
„tabkoord“ Tabelle in der Hauptdatenbank, die die gelöschten Datensätzen aus dieser
Tabelle in ihre Tombstone-Tabelle einträgt. Dank dieser Datenbankmodifikation kann die
Datenänderungsnachverfolgung (Change Tracking) gewährleistet werden. Zu sagen ist, dass
beim Verwenden des MS SQL Server 2008 als Back-End-Datenbank das Schema nicht
erweitert werden muss. MS SQL Server 2008 besitzt die Funktion „Change Tracking“, die
aktiviert werden kann, um die Datenänderungsnachverfolgung automatisch zu verwalten. Wir
wollten uns flexibel halten, deshalb setzten wir die aufwendigere Lösung um.
Wegen MS SQL Server Compact 3.5 können wir unser Prototyp GUI „survey“ nicht
einsetzen. Diese SQL Server Version unterstützt die Schnittstellen JDBC und ODBC nicht.
Und die Java Programmiersprache, mit der wir unseren Prototyp GUI geschrieben haben,
unterstützt seinerseits kein ADO.NET. Schliesslich blieb uns nicht anderes übrig als einen
neuen Prototyp GUI in C# (CSharp) zu programmieren. Zudem haben wir beschlossen, den
Synchronisierungs-Client und den neuen Prototyp GUI als eine Applikation zu entwickeln.
Auch bei diesem System wird nur die manuelle Synchronisation unterstützt.
Testumgebung, -phase und -resultat
Wir haben uns dafür entschieden, die Test-Umgebung zu virtualisieren. Für die
Virtualisierung verwenden wir die Software „ESX3i Update 2“ der Firma VMware. Sie kann
gratis vom Internet heruntergeladen werden. Zu beachten ist, dass diese Software nicht auf
allen Server installiert werden kann. Der Server „Dell PowerEdge 2900 III“ ist für diesen
Zweck zum Einsatz gekommen. Jedes zu analysierende Testsystem haben wir auf einem
eigenen virtuellen Rechner implementiert. Somit vermeiden wir, dass zwischen den
Systemen irgendwelche betrieblichen Konflikte entstehen können. Als Betriebssystem setzen
wir MS Windows 2003 (EN) ein. Datenbankserver und Synchronisations-Middleware sind auf
derselben Maschine installiert, um die Computer-Landschaft übersichtlicher zu halten. In der
realen Welt kann somit an Kosten eingespart werden, falls Software sich auf die gleichen
Maschinen installieren lassen. Zu jedem System haben wir je zwei virtuelle Rechner mit MS
Windows XP zugewiesen. Diese PCs dienen als Client, die wir während unseren Tests
verwendet haben.
Um die drei Synchronisierungssysteme zu testen, haben wir uns eine Testreihe mit acht
Aufgaben (Fällen) ausgedacht. Pro System haben wir die Tests dreimal durchgespielt. Die
Testergebnisse entsprachen unserer Vorstellung. Bei den Aufgaben 3 und 4 sind bei jedem
System die Datenkonflikte aufgetreten. Jedes System verwaltet die Konflikte anders. Die
übrigen Testfälle sind glimpflich durchgelaufen. Die offline-Fälle 7 und 8 machen nur bei
einer automatischen Synchronisation Sinn. Aufgabe 8 entspricht bei einer manuellen
Synchronisation der Aufgabe 6.
IV
Vorwort
Im Juni 2008 haben wir gemeinsam eine Grundstücksvermessung für einen Bekannten
durchgeführt. Nebst dem technischen Messinstrument verwendete Isidoro Lo Iudice auch ein
Vermessungsprogramm für Berechnungen und Messkontrollen, das auf seinem alten
Taschenrechner Hewlett Packard 48SX installiert ist. Dieses Programm wurde in den 90er
Jahre von zwei Diplomanden an der damaligen Ingenieurschule beider Basel in Muttenz für
kommerzielle Zwecke und als Hilfsmittel zum Studium entwickelt. Die Vermessungsstudenten konnten das Programm zu einem günstigen Preis während ihrem Studium von der
Schule beziehen. Da der Taschenrechner zwischendurch Probleme beschaffte und Isidoro
mit dem Gedanke spielte, ihn zu ersetzen, fragte er vorgängig an der heutigen
Fachhochschule nach, ob eine neuere Version der Software gebe. Leider teilte man ihm mit,
dass dieses Taschenrechner-Programm seit ein paar Jahren durch eine neue kostspielige
Software für PCs ersetzt wurde.
Diese Nachricht brachte uns zu der Idee, ein solches Programm für portable Geräte selber
zu schreiben. Das Programm soll eine Datenbank besitzen, um die erfassten Daten zu
speichern. Da auf jedes mobile Gerät eine eigene lokale Datenbank installiert werden muss,
tauchte die Frage der zentralen Datenverwaltung auf. Dabei kamen wir zum Schluss, dass
wir zur Lösung von redundanten Daten und Inkonsistenz zu all diesen lokalen Datenbanken
eine Hauptdatenbank als Drehscheibe benötigen. Diese Hauptdatenbank steht nicht nur den
Anwendern als zentraler Datenspeicherort und -austauschplattform, sondern auch
Drittsysteme wie z. B. einem GIS-System (Geografisches Informations-System) zur
Verfügung. Diese Überlegungen haben wir unserem Abteilungsleiter, Herrn Bernhard Wyss
vorgetragen. Gemeinsam haben wir dann das Thema der Master Thesis erarbeitet. Als
Thema kam die Datenbanksynchronisation heraus.
Ein kleiner Informatikbestandteil wie die Datenbanksynchronisation gewinnt heutzutage
durch den Einsatz von mobilen Geräten für die immer schnell wachsende Kommunikationsgesellschaft an Bedeutung. Während früher der Datenzugriff auf die Datenbankserver aus
wirtschaftlichen und technologischen Aspekten stets vor Ort erfolgte (online) und den Alltag
entsprach, neigt sich die derzeitige Gesellschaft dank diesen mobilen und raffinierten
Geräten auf den offline-Modus zu, denn gerade dieser Modus erlaubt ihr Ortsunabhängigkeit
und vermehrte Arbeitsflexibilität. Diejenigen Leute, die ihre Tätigkeit vor allem draussen
errichten, sollten sich davon angesprochen fühlen. Damit das alles durchgeführt werden
kann, muss der gewünschte Bestandteil des zentralen Datenbestandes (lokal) auf dem
mobilen Gerät abgelegt sein. Bei dieser Arbeitsgattung dürfen wir aber eins nicht ausser
Acht lassen, dass die Forderungen nach Verfügbarkeit, Datenkonsistenz und Performanz
nicht gleichzeitig erreicht werden kann. Auf welche Forderungen mehr Gewicht gelegt wird,
hängt von der bestehenden Arbeit jedes Unternehmens ab. Und entsprechend muss dann
das Synchronisations- und/oder Replikationsverfahren für sie individuell erschafft werden.
Unsere Master Thesis will sich mit dem Synchronisationsverfahren mindestens zweier
Systeme befassen. Dabei wollen wir dieses Verfahren analysieren, installieren, testen und
miteinander vergleichen. Die Datenbanksynchronisation bietet uns für die Master Thesis eine
interessante und anspruchsvolle Arbeit an. Ausserdem waren wir in der Gruppe über das
Thema sofort einig und Herr Wyss erklärte sich bereit, die Arbeit zu betreuen.
V
An dieser Stelle möchten wir uns beim Examinator Bernhard Wyss für seine Ratschläge
betreffend der Arbeit und für seine Begleitung während der Arbeit bedanken. Ferner wollen
wir uns auch bei Herrn Marc Löwenthal bedanken, der sich als Co-Examinator
freundlicherweise zur Verfügung gestellt hat. Dem Sekretariat der Fachhochschule
Nordwestschweiz, Frau Doris Senn bedanken wir uns für die Zustellung des FHNW-Logos.
Diese Master Thesis möchten wir von ganzem Herzen unserem Vater widmen. Er legte
grossen Wert auf Weiterbildung, wie ein Sprichwort besagt: „Man lernt nie aus“. Leider
verstarb er, kurz bevor wir mit der Arbeit beginnen konnten.
Zum Schluss möge uns die Leserin die Verwendung der rein männlichen Form in dieser
Master Thesis verzeihen, aber aus Gründen der einfacheren Lesbarkeit wird im Folgenden
auf die Erwähnung der weiblichen Form bewusst verzichtet, was die Stellung der weiblichen
Personen aber in keiner Weise abwerten soll.
Villmergen, den 31. März 2009
Angelo Lo Iudice
Isidoro Lo Iudice
VI
Inhaltsverzeichnis
1 Einleitung.............................................................................1
2 Pflichtenheft ........................................................................2
2.1
2.2
2.3
2.4
Zielbestimmung ....................................................................2
2.1.1
Muss Kriterien.................................................................................................... 2
2.1.2
Kann Kriterien .................................................................................................... 3
Produkteinsatz ......................................................................3
2.2.1
Anwendungsbereiche ....................................................................................... 3
2.2.2
Zielgruppen ........................................................................................................ 3
2.2.3
Betriebsbedingungen........................................................................................ 4
Produktumgebung ................................................................4
2.3.1
Software.............................................................................................................. 4
2.3.2
Hardware ............................................................................................................ 4
2.3.3
Produktschnittstellen ........................................................................................ 4
Produktfunktionen ................................................................5
2.4.1
Datenbanksynchronisation .............................................................................. 5
2.4.2
Übersicht Use Cases (Datenbanksynchronisation) ....................................... 5
2.4.3
Beschreibungen mit Schablone Use Cases (Datenbanksynchronisation) . 6
2.4.4
Prototyp GUI....................................................................................................... 7
2.4.5
Übersicht Use Cases (Prototyp GUI) ............................................................... 8
2.4.6
Beschreibungen mit Schablone Use Cases (Prototyp GUI).......................... 8
2.5
Produktdaten....................................................................... 10
2.6
Produktleistungen .............................................................. 10
2.7
Benutzungsoberfläche ....................................................... 10
2.8
Qualitäts-Zielbestimmungen .............................................. 11
2.9
Globale Testszenarien und Testfälle ................................. 12
2.10 Entwicklungsumgebung..................................................... 13
2.10.1 Software............................................................................................................ 13
2.10.2 Hardware .......................................................................................................... 13
2.10.3 Entwicklungsschnittstellen ............................................................................ 13
VII
2.11 Ergänzungen ....................................................................... 13
3 Prototyp GUI ......................................................................14
3.1
OOA ..................................................................................... 14
3.1.1
Einleitung ......................................................................................................... 14
3.1.2
Klassendiagramme.......................................................................................... 14
3.1.3
Klassendiagramm GUI-Schicht ...................................................................... 14
3.1.4
Beschreibung GUI-Schicht ............................................................................. 15
3.1.5
Klassendiagramm Business-Schicht ............................................................ 15
3.1.6
Beschreibung Business-Schicht ................................................................... 15
3.1.7
Klassendiagramm Datenbank-Schicht.......................................................... 16
3.1.8
Beschreibung Datenbank-Schicht ................................................................. 16
3.1.9
Sequenzdiagramm........................................................................................... 17
3.1.10 Prototyp GUI..................................................................................................... 18
3.1.11 Testplan ............................................................................................................ 18
3.2
OOD ..................................................................................... 18
3.2.1
Einleitung ......................................................................................................... 18
3.2.2
Übersicht Use Cases (Prototyp GUI) ............................................................. 18
3.2.3
Beschreibungen mit Schablone Use Cases (Prototyp GUI)........................ 19
3.2.4
Gesamtübersicht Klassendiagramme ........................................................... 20
3.2.5
GUI Klassen...................................................................................................... 21
3.2.6
Business Klasse .............................................................................................. 23
3.2.7
Datenbank Klasse............................................................................................ 24
3.2.8
Sequenzdiagramm........................................................................................... 25
3.2.9
Programm......................................................................................................... 26
3.2.10 Test ................................................................................................................... 29
3.2.11 Installation GUI auf dem Rechner .................................................................. 29
4 Systemkonzept..................................................................30
4.1
Einleitung ............................................................................ 30
4.2
Vorgehen ............................................................................. 30
4.3
Systemeigenschaften ......................................................... 30
4.4
Zeitbedarf ............................................................................ 30
4.5
Infrastruktur ........................................................................ 31
4.5.1
Hardware .......................................................................................................... 31
VIII
4.5.2
Software............................................................................................................ 31
4.5.3
Lizenzfragen..................................................................................................... 31
5 Test-Umgebung.................................................................32
5.1
Einleitung ............................................................................ 32
5.2
Vorgehen ............................................................................. 32
5.3
Netzwerk .............................................................................. 33
5.4
Arbeitsgruppe ..................................................................... 34
5.5
Gesamtübersicht der Test-Umgebung .............................. 34
5.6
5.5.1
Netzplan............................................................................................................ 34
5.5.2
Auflistung der Testmaschinen ....................................................................... 35
Hardware und Softwarelizenzen ........................................ 35
6 System I .............................................................................36
6.1
Einleitung ............................................................................ 36
6.2
Aufbau ................................................................................. 36
6.2.1
Übersicht unserer Test-Umgebung ............................................................... 37
6.3
Funktion des Oracle Database Lites.................................. 37
6.4
Funktion der Synchronisation ........................................... 38
6.5
6.6
6.4.1
Manuelle Synchronisation .............................................................................. 39
6.4.2
Automatische Synchronisation...................................................................... 40
Installationsablauf des Systems I ...................................... 41
6.5.1
Installation auf dem Server............................................................................. 41
6.5.2
Einbindung unseres Software-Pakets (Prototyp GUI) im Server-Projekt .. 42
6.5.3
Verwaltung unseres Software Pakets „Mobile Survey“ .............................. 42
6.5.4
Installation auf dem Client.............................................................................. 43
Systemtest I......................................................................... 43
6.6.1
Ausgangslage .................................................................................................. 44
6.6.2
Testfälle ............................................................................................................ 46
6.6.3
Quintesenz der Testfälle beim System I........................................................ 71
7 System II ............................................................................72
7.1
Einleitung ............................................................................ 72
7.2
Aufbau ................................................................................. 72
IX
7.2.1
7.3
SyncML Technologie .......................................................... 73
7.3.1
7.4
7.5
7.6
7.7
7.8
7.9
Übersicht unserer Test-Umgebung ............................................................... 73
SyncML Protokoll ............................................................................................ 74
Funambol DS Server Architektur ....................................... 75
7.4.1
Sync Adaptor (Protocol Transport Mapper) ................................................. 76
7.4.2
Pipeline Manager ............................................................................................. 76
7.4.3
Sync Engine ..................................................................................................... 76
7.4.4
Sync Source ..................................................................................................... 77
Installationsablauf des Systems II ..................................... 77
7.5.1
Installation auf dem Server............................................................................. 77
7.5.2
Starten und Stoppen des Funambol DS Servers ......................................... 80
7.5.3
Installation auf dem Client.............................................................................. 81
Funambol Administration Tool .......................................... 81
7.6.1
Benutzerverwaltung ........................................................................................ 83
7.6.2
Geräteverwaltung ............................................................................................ 85
7.6.3
Principal Verwaltung ....................................................................................... 86
7.6.4
Modulverwaltung ............................................................................................. 90
Der Synchronisationsprozess............................................ 91
7.7.1
Phase Vorbereitung (Preparation) ................................................................. 93
7.7.2
Phase Synchronisation (Synchronization) ................................................... 93
7.7.3
Phase Beendigung (Finalization) ................................................................... 93
Entwicklungsumgebung Connector .................................. 94
7.8.1
Anforderung der Entwicklungsumgebung ................................................... 94
7.8.2
Erstellung des Connector-Projektes „acmeconnector“ .............................. 94
7.8.3
Die wichtigsten Projektdateien im Detail ...................................................... 96
7.8.4
Erstellen des Connector Pakets "acmeconnector" ................................... 105
7.8.5
Installation des Connector Pakets "acmeconnector" ............................... 106
Entwicklungsumgebung SyncML Client ......................... 107
7.9.1
Anforderung der Entwicklungsumgebung ................................................. 107
7.9.2
Erstellung des SyncML Client-Projektes „VermSyncClient“ .................... 107
7.9.3
Die wichtigsten Projektdateien im Detail .................................................... 108
7.9.4
Installation des SyncML Clients „VermSyncClient” .................................. 111
7.10 Systemtest II...................................................................... 111
7.10.1 Ausgangslage ................................................................................................ 111
X
7.10.2 Testfälle .......................................................................................................... 114
7.10.3 Quintesenz der Testfälle beim System II..................................................... 141
8 System III .........................................................................142
8.1
Einleitung .......................................................................... 142
8.2
Aufbau ............................................................................... 142
8.2.1
8.3
8.4
8.5
8.6
8.7
8.8
ADO.NET............................................................................ 143
8.3.1
Dataprovider................................................................................................... 144
8.3.2
DataSet ........................................................................................................... 144
Microsoft Sync Framework .............................................. 145
8.4.1
Übersicht Zusammenarbeitsszenario (collaboration) ............................... 145
8.4.2
Übersicht offline-Szenario (offline access)................................................. 146
Architektur des offline-Szenarios .................................... 147
8.5.1
Die Architektur-Komponenten des Sync Services..................................... 147
8.5.2
Synchronisierungsarten ............................................................................... 149
Installationsablauf des Systems III .................................. 150
8.6.1
Installation auf dem Server........................................................................... 150
8.6.2
Installation auf dem Client............................................................................ 150
Entwicklungsumgebung Synchronisierungs-Client....... 151
8.7.1
Anforderung der Entwicklungsumgebung ................................................. 151
8.7.2
C#-Projekt für den Synchronisations-Client erstellen ............................... 152
8.7.3
Klassendiagramme........................................................................................ 156
Prototyp GUI in C# ............................................................ 170
8.8.1
8.9
Übersicht unserer Test-Umgebung ............................................................. 142
Programm Prototyp GUI ............................................................................... 171
Systemtest III..................................................................... 172
8.9.1
Ausgangslage ................................................................................................ 172
8.9.2
Testfälle .......................................................................................................... 175
8.9.3
Quintesenz der Testfälle beim System III.................................................... 194
9 Datenbanken....................................................................195
9.1
Einleitung .......................................................................... 195
9.2
MS-Access......................................................................... 195
9.3
MySQL ............................................................................... 197
XI
9.4
HSQLDB............................................................................. 199
9.5
Oracle ................................................................................ 202
9.6
Oracle Database Lite......................................................... 203
9.7
Microsoft SQL Server 2005 Express Edition................... 205
9.8
Microsoft SQL Server 2005 Compact Edition ................. 211
10 Schlussdiskussion .........................................................212
10.1 Vergleichen der Systeme ................................................. 212
10.1.1 System I .......................................................................................................... 212
10.1.2 System II ......................................................................................................... 212
10.1.3 System III ........................................................................................................ 213
10.1.4 Übersicht der Systeme.................................................................................. 214
10.1.5 Beurteilung der Systeme .............................................................................. 216
10.2 Vergleich mit Pflichtenheft ............................................... 216
10.2.1 Zielbestimmung ............................................................................................. 217
10.2.2 Produktumgebung......................................................................................... 219
10.3 Zukunftsaussicht .............................................................. 220
10.3.1 Allgemein........................................................................................................ 220
10.3.2 System I .......................................................................................................... 220
10.3.3 System II ......................................................................................................... 220
10.3.4 System III ........................................................................................................ 220
10.3.5 Prototyp GUI................................................................................................... 220
10.4 Ehrlichkeitserklärung ....................................................... 221
11 Literaturverzeichnis ........................................................222
11.1 Literaturangaben für Bücher............................................ 222
11.2 Literaturangaben für Internetseiten................................. 222
12 Glossar.............................................................................223
13 Anhang.............................................................................226
13.1 Abbildungsverzeichnis..................................................... 226
13.2 Projektplan ........................................................................ 232
13.3 Arbeitsjournal Angelo Lo Iudice ...................................... 236
XII
13.4 Arbeitsjournal Isidoro Lo Iudice ...................................... 240
13.5 Sitzungsprotokolle............................................................ 245
13.5.1 Protokoll Nr. 01 / 08 ....................................................................................... 245
13.5.2 Protokoll Nr. 02 / 08 ....................................................................................... 246
13.5.3 Protokoll Nr. 01 / 09 ....................................................................................... 248
13.5.4 Protokoll Nr. 02 / 09 ....................................................................................... 250
XIII
Fachhochschule Nordwestschweiz
Master Thesis (1007_MASIT)
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
1 Einleitung
Im Rahmen der Master Thesis geht es um die Analyse, das Aufsetzen, das Testen und das
Vergleichen der Datenbanksynchronisation von drei Systemen. Mit der Analyse wollen wir
den Aufbau und Ablauf der Datenbanksynchronisation eruieren. Für die Testphasen sollen
die Systeme aufgesetzt werden und lauffähig sein. Mit dem Testen wird das Verhalten der
Synchronisation verfolgt. Und zum Schluss wollen wir die Verfahren miteinander vergleichen.
Für die Bearbeitung der Thesis steht uns ein leistungsstarker Rechner als Werkzeug zur
Verfügung. Auf diesem Rechner werden wir pro Synchronisierungssystem eine virtuelle
Testumgebung aufsetzen. Für jede Testumgebung gibt es einen virtuellen Datenbankserver
mit der Synchronisierungs-Software und zwei virtuelle Client-Maschinen. Jede ClientMaschine wird Remote von einem Laptop aus angesprochen. Die Diplomanden stellen ihre
Laptops zur Verfügung. Die virtuellen Rechner werden mit der Software VMware erstellt. Für
ein einfaches Handling der Datenabfrage und -erfassung soll uns ein Prototyp GUI zur Seite
stehen, welcher wir zu Beginn entwickeln werden. Dieser Prototyp wird auf alle ClientMaschinen verteilt. Parallel zur Prototyp-Entwicklung wird die Testumgebung mit dem ersten
Synchronisierungssystem bereits aufgebaut. Nachdem der Prototyp bereit steht, wird das
erste System getestet und analysiert. Der Reihe nach werden wir die weiteren Systeme nach
derselben Prozedur angehen, das heisst, Testumgebung mit der SynchronisierungsSoftware aufsetzen, Prototyp GUI auf den Client-Maschinen installieren und Testphase
starten. Pro System rechnen wir mit einem Zeitbedarf von sieben Wochen. Nebst unserem
Pflichtenheft wird uns ein Zeitplan beim Abwickeln der gesamten Thesis-Arbeit begleiten.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 1
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
2 Pflichtenheft
Unsere Thesis befasst sich mit dem Thema der Datenbanksynchronisation. Wir benötigen für
unsere Arbeit eine Hauptdatenbank (kurz HDB genannt) auf dem Server und lokale
Datenbanken (auch LDB genannt) auf den mobilen Geräten, die wir selber erstellen werden.
Die Datenbanken werden raumbezogene Daten enthalten. In den Datenbanken kommen
folgende Attribute vor: Punktnummer, Y-Koordinate, X-Koordinate. Der Zugriff auf die lokalen
Daten soll über eine grafische Oberfläche erfolgen. Dabei ist ein kleiner Prototyp GUI in
Java-Sprache zu erstellen, welcher auf einem Laptop, PC oder sogar Handheld läuft. Ferner
sind in unserer Thesis folgende Punkte zu berücksichtigen:
•
Bekannte raumbezogene Daten sollen einerseits aus der Datenbank abgefragt werden,
andererseits sollen neue aufgenommene Daten in die Datenbank gespeichert werden.
•
Die Datenbankabfrage muss auch bei einer netzwerklosen Verbindung (offline)
gewährleistet sein. Folglich muss auf dem Client eine zweite Datenbank existieren, die
sich mit der Hauptdatenbank regelmässig synchronisiert.
•
Das Schwergewicht der Arbeit liegt in der Lösungssuche der Datensynchronisation
zwischen den mobilen Geräten und der Back-End-Datenbank (Hauptdatenbank). Es
sollen mindestens zwei, eventuell drei Evaluationen von verschiedenen
Datenbankherstellern aufgebaut und durchgetestet werden.
•
Hersteller von Datenbanksynchronisations-Applikationen sind nicht vorgegeben. Die
Auswahl steht somit frei.
2.1 Zielbestimmung
2.1.1
Muss Kriterien
•
Client:
- mit grafischer Benutzungsoberfläche (Prototyp GUI) ausrüsten
- lokale Datenbank (offline-Modus) installieren
- automatische und manuelle Synchronisation
•
Middleware:
- Bereitstellen von Eingangs- und Ausgangswarteschlange
- Verbindung zur Hauptdatenbank
- Verbindung zum Client
- bidirektional
•
Datenbankserver:
- Datenbanksoftware installieren
- Hauptdatenbank mit Stammdaten
•
Prototyp GUI:
- Der Benutzer kann sich an der lokalen Datenbank an- und abmelden
- Der Benutzer kann die Daten einsehen und ändern
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 2
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
2.1.2
Kann Kriterien
•
Softwareverteilung Prototyp GUI
•
Heterogene Architektur
•
Eigene Synchronisationssoftware entwickeln
•
Direkte Verbindung und Datenmodifikation auf der Back-End-Datenbank via Prototyp GUI
2.2 Produkteinsatz
2.2.1
Anwendungsbereiche
An folgende Fälle soll der Anwendungsbereich der Datenbanksynchronisation erklärt
werden:
Fall 1: Der Vermesser
Auf der Baustelle nimmt der Vermesser raumbezogene Daten mit seinem Messinstrument
auf und speichert sie in der lokalen Datenbank seines Rechners ab. Zurück im Büro wird
seine lokale Datenbank mit der Hauptdatenbank abgeglichen (Synchronisation). Dieser Fall
soll uns in unserer Arbeit als Grundlage dienen.
Fall 2: Der Aussendienstmitarbeiter
Ein Aussendienstmitarbeiter geht auf Kundenbesuch, um neue Bestellungen aufzunehmen.
Vorgängig lädt er die Kundendaten von der Hauptdatenbank lokal auf seinem portablen
Gerät herunter. Nach seinem Besuch synchronisiert er seine neuen Daten mit der
Hauptdatenbank.
Fall 3: Der Produktionsleiter
In der Produktionsstätte nimmt der Produktionsleiter stichprobenweise Qualitätsmesswerte in
seiner lokalen Datenbank auf, welche er nach seinem Rundgang in die Hauptdatenbank
übermittelt (Synchronisation).
Fall 4: Messestand
Während einer Messe werden die Adressen (und weitere Infos) von möglichen Neukunden
auf dem Laptop gespeichert. Einst in der Firma zurück können die neu erfassten Daten in
der Hauptdatenbank gespeichert werden (Synchronisation), sodass sie für die weitere
Bearbeitung dem Customer Service zur Verfügung stehen.
2.2.2
Zielgruppen
Personengruppen, die auch bei einer netzwerklosen Verbindung wichtige Geschäftsdaten
effizient und sicher erfassen müssen. Das heisst überall dort, wo eine online-Verbindung zur
Hauptdatenbank nicht immer möglich ist. Davon sind folgende Zielgruppen betroffen (ohne
Anspruch auf Vollständigkeit):
•
Mitarbeiter im Aussendienst
•
Mobile Client
•
Aussenstellen (Datenabgleich)
•
Heimarbeiter
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 3
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Als Zielgruppe wählen wir für unsere Arbeit den Vermesser (ein Mitarbeiter im Aussendienst)
aus. Die Zielgruppe soll Basiskenntnisse im Umgang mit dem PC respektive mobilen Gerät
besitzen.
2.2.3
Betriebsbedingungen
Hardwarekomponenten der Server und Middleware dürfen nicht zum Flaschenhals werden.
Dies gilt auch für die Netzwerktopologie. Einsatz redundanter Hardwarekomponenten, um
Betriebsausfälle minimal zu halten.
Die Hauptdatenbanksicherung wird vom Administrator manuell durchgeführt.
Für den Prototyp GUI sind keine besonderen Betriebsbedingungen verlangt.
2.3 Produktumgebung
2.3.1
Software
Generell können alle gängigsten Betriebssysteme wie Windows 2000/2003, XP, Vista, Linux
und Sun Solaris zum Einsatz kommen. Wir beschränken uns mit den Betriebssystemen
Windows 2003 für Datenbankserver und Middleware und XP für Client. Optional soll Linux
als Ergänzung in Betracht gezogen werden.
In unserer Arbeit werden zum Aufsetzen der vorgesehenen Betriebssysteme die
Virtualisierungssoftware der Firma VMware (entweder VMware Workstation oder VMware
ESXi) eingesetzt.
2.3.2
Hardware
Für die Realisierung unserer Produktumgebung bestehen keine Hardwareeinschränkungen.
Im Prinzip genügen für diese Arbeit übliche Rechner wie Desktop und Notebook. In unsere
Testumgebung werden alle notwendigen Maschinen auf einem physischen und
leistungsstarken Rechner virtualisiert. Zudem können auch die eigenen Notebooks als Client
benutzt werden.
Pro Testsystem soll aus Kostengründen sofern möglich die Datenbank- und MiddlewareSoftware auf derselben Maschine installiert werden.
2.3.3
Produktschnittstellen
Passende Schnittstellen zwischen Client - Middleware und Middleware - Datenbankserver
werden im Verlauf der Arbeit eruiert.
Prototyp GUI
Es gibt keine Schnittstelle zu anderen Produkten.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 4
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
2.4 Produktfunktionen
2.4.1
•
Über die Benutzungsoberfläche werden Daten erfasst (siehe unter anderem Kapitel
2.4.3).
•
Der Benutzer kann jederzeit eine manuelle Datensynchronisation auslösen.
•
Die automatische Datensynchronisation wird über das System gesteuert.
•
Über die Synchronisation werden die Daten von der Hauptdatenbank in die lokale
Datenbank transferiert und umgekehrt.
•
Das ausgewählte System soll
Funktionen zur Verfügung stellen.
Verwaltungsaufgaben-
und
Konfliktmanagement-
Optional:
• Die Daten können (eventuell via Prototyp GUI) direkt auf die Back-End-Datenbank
modifiziert werden.
•
Das ausgewählte System soll auch ein Softwareverteilungsmanagement anbieten.
2.4.2
Übersicht Use Cases (Datenbanksynchronisation)
Das folgende Diagramm gibt eine Übersicht der Anwendungsfälle (Use Cases) für die
Systemevaluation:
Abbildung 1: Systemkonzept Use Cases Diagramm
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 5
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
2.4.3
Beschreibungen mit Schablone Use Cases (Datenbanksynchronisation)
Use Case 100: Lokale Manipulation LDB
Nummer:
100
Name:
Lokale Manipulation LDB
Kurzbeschreibung:
DB-User erfasst, ändert und löscht Einträge in der lokalen
Datenbank
Vorbedingung:
Verbindung zur Datenbank muss bestehen
Nachbedingung:
keine
Akteure:
DB-User
Auslösendes Ereignis:
DB-User manipuliert Daten anhand des GUI
Ablaufbeschreibung:
1. Punkt in der Tabelle auswählen
2. Punkt manipulieren
3. Punkt speichern, löschen -> entsprechende Schaltfläche
betätigen
Auswirkungen:
Veränderte Daten auf der lokalen Datenbank
Use Case 200: Synchronisation
Nummer:
200
Name:
Synchronisation
Kurzbeschreibung:
DB-User löst die Datensynchronisation zwischen den
Datenbanken manuell aus. Die automatische Synchronisation
läuft über eine Maschine.
Vorbedingung:
Daten müssen entweder in der lokalen Datenbank oder in der
Hauptdatenbank geändert sein
Nachbedingung:
fehlerfrei
Akteure:
DB-User, Maschine
Synchronisation wird durch DB-User manuell gestartet oder die
automatische Synchronisation ist aktiviert
Ablaufbeschreibung:
1. DB-User startet Synchronisation manuell oder die
automatische Synchronisation ist aktiviert
Auswirkungen:
Daten werden in den Datenbanken aktualisiert.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 6
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Use Case 300: Datentransfer
Nummer:
300
Name:
Datentransfer
Kurzbeschreibung:
Daten werden von der lokalen Datenbank in die Hauptdatenbank
übertragen und umgekehrt
Vorbedingung:
Synchronisation muss bestehen
Nachbedingung:
keine
Akteure:
DB-User, Maschine
Synchronisation wird gestartet oder läuft
Ablaufbeschreibung:
1. Automatische Datenübertragung
Auswirkungen:
Abgleichung der Daten zwischen den Datenbanken
Use Case 400: Remote Manipulation HDB
Nummer:
400
Name:
Remote Manipulation HDB
Kurzbeschreibung:
Einträge in der Hauptdatenbank erfassen, ändern und
löschen
Vorbedingung:
Verbindung zur Datenbank muss bestehen
Nachbedingung:
keine
Akteure:
DB-User
Daten werden in der Hauptdatenbank manipuliert
Ablaufbeschreibung:
1. Punkt manipulieren
2. Commit auslösen
Auswirkungen:
2.4.4
Veränderte Daten auf der Hauptdatenbank
Prototyp GUI
Der Prototyp muss folgende Funktionen erfüllen:
•
Der Benutzer muss sich mit verschiedenen Datenbankmanagementsystemen kurz DBMS
genannt via Benutzername und Passwort verbinden können. Die DBMS werden im
Verlauf der Arbeit eruiert.
•
Der Benutzer muss Daten erfassen, ändern und löschen können. Die Daten sollen
tabellarisch auf dem GUI angezeigt werden.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 7
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
2.4.5
Übersicht Use Cases (Prototyp GUI)
Das folgende Diagramm zeigt eine Übersicht der eintreffenden Anwendungsfälle (Use
Cases):
Abbildung 2: Use Cases Diagramm
2.4.6
Beschreibungen mit Schablone Use Cases (Prototyp GUI)
Use Case 100: Datenbankmanagementsystem auswählen
Nummer:
100
Name:
Datenbankmanagementsystem auswählen
Kurzbeschreibung:
Anhand der Auswahlbox das entsprechende DBMS auswählen
Vorbedingung:
keine
Nachbedingung:
keine
Akteure:
DB-User
Auswahlbox
Ablaufbeschreibung:
1. Über die Auswahlbox wählt der User das DBMS aus
2. Anmeldepanel wird geöffnet
Auswirkungen:
Parameter für DB-Verbindung werden verlangt
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 8
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Use Case 200: Daten erfassen
Nummer:
200
Name:
Daten erfassen
Kurzbeschreibung:
Mit dem ListGUI kann ein neuer Datensatz
(Punktnummer, Y- und X-Koordinate) in der Datenbank
erfasst werden. Dank Observer wird der neue Punkt
in der Tabelle gleich aufgelistet und ist in der DB abgespeichert.
Vorbedingung:
keine
Nachbedingung:
keine
Akteure:
DB-User
Enter-Button
Ablaufbeschreibung:
1. Punktnummer eingeben
2. Y-Koordinate eingeben
3. X-Koordinate eingeben
4. Button Enter drücken
5. Erfasster Punkt erscheint in der Tabelle
Auswirkungen:
Neuer Punkt wird in der DB gespeichert
Use Case 300: Daten ändern
Nummer:
300
Name:
Daten ändern
Kurzbeschreibung:
Mit dem ListGUI kann ein bestehender Datensatz (Punktnummer,
Y- und X-Koordinate) in der Datenbank geändert werden. Dank
Observer wird der geänderte Punkt in der Tabelle gleich aufgelistet
und in der DB abgespeichert.
Vorbedingung:
keine
Nachbedingung:
keine
Akteure:
DB-User
Enter-Button
Ablaufbeschreibung:
2. Daten ändern (Punktnummer, Y- und X-Koordinate)
Auswirkungen:
Veränderter Punkt wird in der DB gespeichert
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 9
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Use Case 400: Daten löschen
Nummer:
400
Name:
Daten löschen
Kurzbeschreibung:
Zu löschender Punkt in der Tabelle des ListGUI auswählen
und mit dem Delete-Button löschen
Vorbedingung:
keine
Nachbedingung:
keine
Akteure:
DB-User
Delete-Button
Ablaufbeschreibung:
2. Delete-Button betätigen
Auswirkungen:
Punkt wird in der DB gelöscht
2.5 Produktdaten
Unsere Produktdaten befinden sich in der Datenbank namens „vermdb“. Die Datenbank
besteht zurzeit aus einer Tabelle mit den drei Attributen Punktnummer (PktNr), Y-Koordinate
(YKoord) und X-Koordinate (XKoord). Die Tabelle heisst „tabkoord“. Weitere Tabellen
können während der Arbeit noch folgen.
2.6 Produktleistungen
Die Produktleistungen der Komponenten werden von den Angaben des Produktherstellers
entnommen. Unsere eigene Bedingung ist, dass es zu keinen Engpässe kommen darf.
2.7 Benutzungsoberfläche
Für die Datenbanksynchronisation ist kein GUI erforderlich. Eine Benutzungsoberfläche für
Verwaltungsaufgaben (Benutzer, Passwort usw.) soll die ausgewählte SynchronisationsApplikation zur Verfügung stellen.
Prototyp GUI
Für die Erfassung und Abruf der Daten in der Datenbank ist ein GUI vorgesehen. Die
objektorientierte Oberfläche wird zweidimensional erstellt.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 10
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
DatenEingabefelder
DatenAnzeigetabelle
AuslöserButtons
Abbildung 3: Benutzungsoberfläche
2.8 Qualitäts-Zielbestimmungen
•
Einfaches Synchronisations-Handling
•
Einfaches Aufsetzen der Infrastruktur
•
Klares Error-Handling
•
Synchronisationskollisionen minimal halten
Prototyp GUI
•
Robustheit
•
Zuverlässigkeit
•
Korrektheit
•
Benutzungsfreundlichkeit
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 11
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
2.9 Globale Testszenarien und Testfälle
Die Testumgebung besteht aus dem System und zwei Clients.
Abbildung 4: Testumgebung
Bei unseren Testfällen gehen wir immer von diesen Bedingungen aus:
•
Die noch zu erfassenden Stammdaten befinden sich in der Hauptdatenbank
•
Client X und Y sind online für die Fälle 1-6
•
Client X und Y sind offline für die Fälle 7-8
Fall 1:
TestclientX fügt einen neuen Punkt ein.
Fall 2:
TestclientY modifiziert einen bestehenden Punkt.
Fall 3:
Beide Clients fügen „gleichzeitig“ denselben Punkt aber mit diversen Werten ein.
Fall 4:
TestclientX löscht einen Punkt und TestclientY ändert unmittelbar danach die Koordinaten
dessen Punkts.
Fall 5:
Lösche einen Punkt direkt aus der Hauptdatenbank
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 12
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Fall 6:
Modifiziere die Koordinatenwerte eines Punkts direkt in der Hauptdatenbank
Fall 7:
Bedingung: Client X & Y sind offline und nur die originalen Stammdaten befinden sich in der
Hauptdatenbank
TestclientX und TestclientY fügen je zwei neue Punkte mit unterschiedlichen Punktnummern
ein. Anschliessend werden die Clients online gesetzt.
Fall 8:
Die Clients sind offline und in der Hauptdatenbank soll direkt ein Punkt modifiziert werden.
Anschliessend werden die Clients online gesetzt.
Prototyp GUI
Für das Testen des Prototyps GUI wird kein Testplan benötigt. Das eigentliche Testen soll
während der objektorientierten Designphase stattfinden. Verschiedene Testwerkzeuge wie
Issue-Tracking- und JUnit-Tool werden für dieses Programm nicht eingesetzt.
2.10 Entwicklungsumgebung
2.10.1 Software
Eine Entwicklungsumgebung für die Datenbanksynchronisation ist nicht vorgesehen.
Prototyp GUI
Das GUI-Programm wird in Java-Sprache geschrieben. Als Werkzeug steht uns eclipse,
Version 3.2 zur Verfügung.
2.10.2 Hardware
Der eigene Rechner ist für das Entwickeln des GUI ausreichend.
2.10.3 Entwicklungsschnittstellen
Es sind keine besonderen Schnittstellen erforderlich.
2.11 Ergänzungen
Anderweitige Vereinbarungen sind schriftlich festzuhalten.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 13
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
3 Prototyp GUI
3.1 OOA
3.1.1
Einleitung
Mit der objektorientierten Analyse werden erste Ideen und Skizzen über den zu
entwickelnden Prototyp entworfen. Die Ideen und Skizzen werden in groben Zügen anhand
von Schreibschablonen (Use Cases siehe Kapitel 2.4.3 des Pflichtenhefts) und Diagrammen
(Klassen, Sequenz, usw.) auf Papier festgehalten und dargestellt. Die Entwürfe sollen das
Problem beschreiben, für einen Nichtfachmann (Auftraggeber) verständlich und
nachvollziehbar sein und im Moment noch keine technischen Lösungen bieten. Für die
Beschreibung der Use Cases und Erstellung des Sequenzdiagramms stand uns das
„Lehrbuch der Objektmodellierung“ von Heide Balzert zur Seite.
3.1.2
Klassendiagramme
Für die Realisierung des Prototyps GUI haben wir beschlossen, das Drei-SchichtenArchitekturmodell anzuwenden. Das Modell sieht die drei Pakete GUI, Business und
Datenbank vor.
3.1.3
Klassendiagramm GUI-Schicht
Abbildung 5: OOA Klassendiagramm GUI-Schicht
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 14
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
3.1.4
Beschreibung GUI-Schicht
Die Klasse GUI stellt unsere Benutzungsoberfläche dar. Mit dieser Benutzungsoberfläche
können wir folgende Funktionen ausführen:
•
Datenbankmanagementsystem auswählen -> Verbindung mit der gewünschten
Datenbank
•
Datenmanipulation, d. h. erfassen, ändern und löschen direkt auf der
Benutzungsoberfläche -> Datentabelle anzeigen
3.1.5
Klassendiagramm Business-Schicht
Abbildung 6: OOA Klassendiagramm Business-Schicht
3.1.6
Beschreibung Business-Schicht
Die Klasse Business ist das Bindeglied zwischen unsere Benutzungsoberfläche und
Datenbank. In ihr befinden sich die Setter- und Gettermethoden, die wichtigsten Methoden
für die Datenmanipulation und Datenbankverbindungen.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 15
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
3.1.7
Klassendiagramm Datenbank-Schicht
Abbildung 7: OOA Klassendiagramm Datenbank-Schicht
3.1.8
Beschreibung Datenbank-Schicht
Die Klasse Datenbank enthält die Verbindungen zu den verschiedenen Datenbanksystemen
und SQL-Statements. Beim erstmaligen Testen der Benutzungsoberfläche werden wir eine
Access-Datenbank via JDBC-ODBC-Bridge anbinden. Die Datenbank soll Daten von
folgenden Attributen Punktnummer, Y-Koordinate und X-Koordinate enthalten.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 16
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
3.1.9
Sequenzdiagramm
Das folgende Diagramm gibt eine Gesamtübersicht über Sinn und Zweck der Applikation:
Abbildung 8: OOA Sequenzdiagramm
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 17
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
3.1.10 Prototyp GUI
Unser Prototyp sieht eine Benutzungsoberfläche vor. Darin sind eine Datentabelle, die
nötigen Schaltflächen (Buttons) für die Datenmanipulation und ein Datenbankmanagementsystem-Auswahlkästchen implementiert (siehe Kapitel 2.7).
3.1.11 Testplan
Wie im Pflichtenheft festgehalten wurde auf einen Testplan verzichtet, da es sich um einen
kleinen Prototyp handelt (siehe Kapitel 2.9).
3.2 OOD
3.2.1
Einleitung
Die in der OOA definierten Entwürfe werden in dieser Phase verfeinert. Wir befinden uns
jetzt in der Phase des objektorientierten Designs. Die in diesem Kapitel beschriebenen Use
Cases, Klassen- und Sequenzdiagramme fliessen erst jetzt in den zu entwickelnden Prototyp
ein.
3.2.2
Übersicht Use Cases (Prototyp GUI)
Abbildung 9: OOD Use Cases Diagramm
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 18
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Für die Realisierung des Prototyps benötigen wir sechs Use Cases. Im Gegensatz zu OOA
sind neu zwei weitere Use Cases dazugekommen. Je nach Datenbank werden bestimmte
Parameter für eine korrekte Verbindung benötigt. Dieser Umstand wird in einem eigenen
Anwendungsfall behandelt. Eine Aktualisierung der Daten aus der Hauptdatenbank wird
ebenfalls in einem eigenen Anwendungsfall beschrieben. Für unsere Use Cases kommt nur
ein Akteur (DB-User) vor, der mit dem System kommuniziert.
3.2.3
Beschreibungen mit Schablone Use Cases (Prototyp GUI)
Use Case 500: Datentabelle im GUI aktualisieren
Nummer:
500
Name:
Datentabelle im GUI aktualisieren
Kurzbeschreibung:
Handänderungen in der Datenbank können über den RefreshButton im ListGUI angezeigt werden.
Vorbedingung:
Daten werden in der Datenbank direkt durch Dritte manipuliert.
Nachbedingung:
keine
Akteure:
DB-User
Refresh-Button
Ablaufbeschreibung:
1. DB-User klickt Refresh-Button.
Auswirkungen:
Aktuelle Daten werden im GUI angezeigt.
Use Case 600: Parameter eingeben
Nummer:
600
Name:
Parameter eingeben
Kurzbeschreibung:
Je nach DBMS werden für die DB-Verbindung einige Parameter
benötigt wie Host, Port, DB-Name, Username und Passwort.
Vorbedingung:
DBMS muss ausgewählt sein -> Use Case 100, DB-User muss
Parameter kennen.
Nachbedingung:
Datenbank und DB-Verbindung müssen existieren.
Akteure:
DB-User
DB-User füllt die eingeblendeten Parameterfelder ein.
Ablaufbeschreibung:
1. DB-User gibt alle nötigen Parameter an.
2. DB-User schliesst die Eingaben mit dem OK-Button ab.
Auswirkungen:
DB-Verbindung wird erstellt, Daten werden im GUI angezeigt.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 19
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
3.2.4
Gesamtübersicht Klassendiagramme
Abbildung 10: OOD Klassenübersichts-Diagramm
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 20
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Unser Programm baut auf das Drei-Schichten-Architekturmodell auf. Es enthält die drei
Pakete vermGUI (GUI), verm (Business) und vermDB (Datenbank). Die Pakete werden im
Projekt namens „survey“ verwaltet. Jedem Paket entspricht genau eine Schicht des Modells.
Zu oberst haben wir den GUI, in der Mitte unser Business und unten die Datenbank. Diese
Schichten können nur im Top-Down oder Bottom-Up miteinander kommunizieren. Der
grosse Vorteil schliesslich ist, dass jede Schicht einzeln ausgewechselt werden kann, ohne
das ganze Programm auf den Kopf zustellen.
Das GUI-Paket besitzt vier Klassen: ListGUI, DialogLogin, DialogLoeschen und
DialogWarning, während die anderen Pakete je eine Klasse Point (Business) und VermDb
(Datenbank) haben.
3.2.5
GUI Klassen
ListGUI
Abbildung 11: OOD Klasse ListGUI
Die Klasse ListGUI ist unsere Hauptklasse. Sie stellt das Hauptfenster unserer Applikation
dar. In ihr werden die Datenbanksysteme ausgewählt, die Daten von der Datenbank
angezeigt und die Daten durch Eingabefelder und Knöpfe manipuliert. Sie ist für die
Systemevaluationen unser Ausgangspunkt.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 21
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
DialogLogin
Abbildung 12: OOD Klasse DialogLogin
Je nach DBMS-Anwendung sind einige Parameter wie Host, Port, Datenbankname,
Benutzer und Passwort anzugeben. Aus diesem Grund haben wir ein Anmeldefenster
kreiert, welches geöffnet wird, sobald das gewünschte DBMS im Auswahlkästchen des
ListGUI gewählt wurde.
DialogLoeschen
Abbildung 13: OOD Klasse DialogLoeschen
Beim Löschen eines Datensatzes werden wir gefragt, ob wir ihn tatsächlich löschen
möchten. Mit dem OK-Button bestätigen wir den Löschvorgang. Mit dem Abbrechen-Button
wird der Löschvorgang gestoppt.
DialogWarning
Abbildung 14: OOD Klasse DialogWarning
Wird ein nicht existierender Datensatz mit dem Delete-Button des ListGUI gelöscht, dann
erscheint eine Fehlermeldung.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 22
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
3.2.6
Business Klasse
Point
Abbildung 15: OOD Klasse Point
Die Klasse Point ist unsere Geschäftslogikklasse. Sie steuert den eigentlichen Datenprozess
zwischen den Schichten. Sie holt sich die Daten aus der Datenbank und übergibt sie dem
ListGUI. Umgekehrt nimmt sie Daten vom ListGUI entgegen und händigt sie der Datenbank
aus. Für die Kommunikation zwischen der Business Klasse und GUI Klassen ist der
Observer besorgt.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 23
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
3.2.7
Datenbank Klasse
VermDb
Abbildung 16: OOD Klasse VermDb
Die Klasse VermDb ist als Singleton-Klasse implementiert. Sie kommuniziert mit der
Datenbanktabelle tabkoord mit den verschiedenen Datenbanksystemen und verwaltet die
Punktdaten (Punktnummer, Y-Koordinate, X-Koordinate). Über diese Klasse kann ein neuer
Punkt erfasst, ein bestehender Punkt geändert oder gelöscht werden. Zu GUI-Testzwecken
stellt sie unter anderem zu Beginn die Schnittstelle zur Access-Datenbank her.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 24
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
3.2.8
Sequenzdiagramm
Das folgende Diagramm zeigt das Zusammenspiel aller vorkommenden Klassen aus Sicht
der Applikation:
Abbildung 17: OOD Sequenzdiagramm
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 25
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
3.2.9
Programm
Dieses Kapitel kann auch als User-Manual benutzt werden.
Hauptfenster ListGUI
DBMS
Auswahlbox
DatenEingabefelder
DatenAnzeigetabelle
AuslöserButtons
Abbildung 18: Hauptfenster mit Beschreibung
DBMS Auswahlbox
In der Box stehen sechs Datenbankmanagementsysteme zur Auswahl:
Abbildung 19: Panel DBMS Auswahlbox
Daten-Eingabefelder
Bei der Datenerfassung und -änderung müssen alle drei Felder ausgefüllt sein, ansonsten
bleibt der Enter-Button inaktiv. Bei einer Änderung ist auch möglich den zu mutierenden
Datensatz in der Anzeigetabelle durch Mausklick auszuwählen und das oder die
entsprechenden Textfelder zu ändern.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 26
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 20: Panel Daten-Eingabefelder
Auslöser-Buttons
Datenerfassung und -änderung werden mit dem Enter-Button beendet. Ein Datensatz kann
mit der Punktnummereingabe oder durch Auswahl in der Anzeigetabelle und
anschliessendem Delete-Button-Betätigung gelöscht werden. Der Refresh-Button dient zum
Aktualisieren der Anzeigetabelle, wenn Daten in der Datenbank direkt manipuliert werden. Er
wird bei Datenänderungen mit unserem ListGUI nicht benötigt, da der Observer-Pattern
implementiert ist. Statt die Schaltfläche über Mausklick zu betätigen, kann jede aktive
Schaltfläche mit der Enter-Tastaturtaste bedient werden.
Abbildung 21: Panel Auslöser-Buttons
Daten-Anzeigetabelle
Die Tabelle wird mit den Daten der ausgewählten Datenbank ausgefüllt, sobald die
Verbindung da ist.
Abbildung 22: Panel Daten-Anzeigetabelle
Nebenfenster DialogLogin
Bei der Auswahl eines DBMS im ListGUI wird das Anmeldefenster geöffnet. Je nach DBMS
sind die benötigten Eingabefelder aktiv. Bei richtiger Eingabe wird mit dem OK-Button eine
Datenbankverbindung hergestellt. Das Fenster schliesst sich und die Daten werden im
Hauptfenster „ListGUI“ angezeigt.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 27
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 23: Nebenfenster DialogLogin
Die nachfolgende Tabelle zeigt eine Übersicht der aktiven (= x) Eingabefelder der DBMS:
MS-Access*
Host
DB-Name
MySQL*
Oracle DB
Lite
x
x
x
x
Port
Oracle
Funambol
DS MySQL
Funambol
DS HSQL
x
x
x
x
x
x
x
Benutzer
x
system
x
x
x
Passwort
x
x
x
x
x
* Diese Datenbanken standen nur zu Testzwecken für den Prototyp GUI.
Bei Oracle Database Lite ist der Benutzer „system“ standardmässig bereits im Eingabefeld
eingetragen.
Nebenfenster DialogLoeschen
Beim Löschen eines Punkts mit dem Delete-Button erscheint dieses Fenster. Mit „OK“ wird
der Löschvorgang bestätigt. Mit „Abbrechen“ kehrt man zum Hauptfenster „ListGUI“ zurück.
Abbildung 24: Nebenfenster DialogLoeschen
Nebenfenster DialogWarning
Dieses Warnfenster erscheint unmittelbar, wenn mit dem OK-Button des Fensters
DialogLoeschen ein nicht existierender Punkt gelöscht werden soll.
Abbildung 25: Nebenfenster DialogWarning
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 28
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
3.2.10 Test
Mit wenig und einfachen Tests gaben wir uns beim Programmieren des Prototyps GUI
zufrieden. Die korrekte Funktionalität des Programms testeten wir anhand von
System.out.print-Anweisungen auf der Konsole unserer Entwicklungsplattform eclipse.
Abwechslungsweise kodierten wir ein wenig und testeten anschliessend gleich. Somit
wussten wir rasch, wo wir standen und was zu verbessern war. Nach einigen kleinen
Anpassungen und Datenbankschnittstellenerweiterungen nahm das Programm Schritt für
Schritt Gestalt an.
3.2.11 Installation GUI auf dem Rechner
1.) Erstelle aus der Entwicklungssoftware Eclipse eine jar-Datei (Java-Archive) des GUI.
jar-Datei erstellen
1. Projekt „survey“ auswählen
2. Menü File -> Export auswählen
3. Im Fenster Export (Select) JAR file unter Java auswählen und Button Next klicken
4. Im Fenster JAR Export (JAR File Specification) Pfad und jar-Dateiname angeben
Select the export destination:
JAR file: D:\IT-Studium\MasterThesisLoIudice\survey.jar
Button Next zweimal klicken
5. Im Fenster JAR Export (JAR Manifest Specification) Main class: „vermGUI.ListGUI“ im
Browser auswählen und Button Finish klicken
2.) Gemäss jar-Datei-Erstellung ist unsere Datei „survey.jar“ bereits im korrekten Verzeichnis
abgelegt. Nun muss noch Java im C:\Program Files installiert sein. Zumindest benötigen
wir dort das Ausführungsprogramm jre6 (Java Runtime Environment, jre-6u11-windowsi586-p.exe) im Java-Verzeichnis (siehe Abb. 26). Das Ausführungsprogramm (virtuelle
Maschine von Java) ist von der Versionierung der jar-Datei abhängig. Damit unser
Prototyp GUI richtig läuft, müssen die entsprechenden Datenbank-Treiber im jre6\lib\extVerzeichnis abgelegt werden (siehe Abb. 27).
Abbildung 26: Strukturbaum des JRE
Abbildung 27: Ablageort der DB-Treiber
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 29
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
4 Systemkonzept
4.1 Einleitung
In diesem Kapitel geht es, um die Erarbeitung eines Konzepts für die Systemevaluation. Da
wir vorhaben, zwei bis drei nicht vorgegebene Synchronisationssysteme zu evaluieren, ist es
zum jetzigen Zeitpunkt schwierig, ein bereits ausgereiftes Konzeptmodell zu erstellen,
welches für alle Systeme gilt. Aus diesem Grund haben wir uns grundsätzlich mit den zwei
Themen Systemeigenschaften und Vorgehen befasst, welche in den nachfolgenden
Unterkapiteln beschrieben sind. Die im Pflichtenheft beschriebenen Anwendungsfälle (Use
Cases, Kapitel 2.4.2) sind Bestandteil unseres Systemkonzepts.
4.2 Vorgehen
1.) Als erstes benötigen wir einen leistungsstarken physischen Rechner für unsere TestUmgebung. Auf diesem Rechner werden für jedes System die dazugehörigen virtuellen
Maschinen aufgebaut. Zu jedem System soll mindestens ein Server für die Datenbank
und für das Synchronisation-Middleware und zwei Workstations für die Client-Umgebung
dienen.
2.) Durch Recherchieren im Internet und Fragen an Informatikleute (z. B. Mitarbeiter,
Dozenten, etc.) werden wir die Systeme auswählen.
3.) Der Reihe nach werden die Systeme evaluiert.
4.) Am Schluss werden wir die Systeme miteinander vergleichen.
4.3 Systemeigenschaften
Wir haben vor zwei bis drei Systeme innerhalb der festgelegten Thesis-Zeit zu evaluieren.
Bei der Auswahl der Systeme wollen wir uns an folgende Rahmenbedingungen festhalten:
•
Es muss mindestens ein homogenes und ein heterogenes System dabei sein.
•
Es muss ein kommerzielles
berücksichtigt werden.
•
Im Weiteren muss es eine kostengünstige Lösung sein. Eine sogenannte „out of the
box”-Applikation wäre wünschenswert. Wenn möglich sollen die Systeme mit wenigen
Anpassungen realisiert werden können.
•
Wohlgemerkt muss es die Muss-Kriterien gemäss Pflichtenheft erfüllen (Kapitel 2.1.1)
und
nicht-kommerzielles
System
(Open
Source)
4.4 Zeitbedarf
Für jedes System rechnen wir mit einem Zeitbedarf von sieben Wochen. Darin enthalten sind
das Einarbeiten (Recherchieren), das Aufsetzen und Aufbauen des Systems, eventuelle
Programmierarbeiten von Interfaces, das analytische Testen und die Dokumentation.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 30
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
4.5 Infrastruktur
4.5.1
Hardware
Zum Einsatz kommen Server-seitig ein leistungsstarker Rechner und Client-seitig zwei
Laptops. Der Server-Rechner (Hersteller offen) muss eingekauft werden. Ferner muss er
mindestens folgende Eigenschaften (Prozessor > 2.0 GHz, Arbeitsspeicher 4GB, Festplatte
1TB) aufweisen. Die Laptops stellen die beiden Diplomanden zur Verfügung.
4.5.2
Software
Als Betriebssysteme werden Microsoft-Produkte (optional Linux) eingesetzt. Für die
Virtualisierung wird VMware verwendet.
4.5.3
Lizenzfragen
Für die Systemevaluation eines kommerziellen Herstellers werden wir die Lizenzen vorerst
über die Fachhochschule allenfalls über die Firma LO iUDiCE besorgen.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 31
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
5 Test-Umgebung
5.1 Einleitung
Für die Evaluierung der Systeme braucht es diverse Computer. Zu dieser Erkenntnis sind wir
in der Gruppe recht schnell darauf gekommen. Jedes zu analysierende Testsystem soll auf
einem eigenen Rechner implementiert werden, somit vermeiden wir, dass zwischen den
Systemen irgendwelche betrieblichen Konflikte entstehen können. Der uns erhoffte Vorteil
ist, dass nicht alle Systeme auf einmal zerstört werden und all diese aufwendig wieder neu
aufgesetzt werden müssen. Zudem drängt sich aus finanziellen Gründen eine Virtualisierung
der Test-Umgebung auf. Als Virtualisierungssoftware haben wir uns für die der Firma
VMware entschieden, die wir während des Studiums kennen gelernt haben.
5.2 Vorgehen
Am Anfang hatten wir als physischen Rechner einen Dell Inspiron 530 für unsere
Testumgebung eingesetzt. Dieser ist mit folgenden Hardware-Komponenten ausgestattet:
•
Intel Core 2 Quad-Core Prozessor (2.5GHz)
•
4GB Arbeitsspeicher
•
2 x 500GB (im RAID 1) Festplatten.
Dem Rechner haben wir folgende Software installiert:
•
Windows Server 2003 als Betriebssystem
•
VMware Workstation 6.5 (30Tage Evaluationsversion) für die Virtualisierung
Windows Server 2003 wird als Betriebssystem eingesetzt, da dieses gleichzeitig zwei
unabhängige Sitzungen via Remote Desktop Protokoll (RDP) zulässt. Und somit arbeitet
jedes Gruppenmitglied in getrennter Umgebung für sich.
Nachdem die physische Maschine fertig aufgesetzt war, wurden anschliessend auch die
nötigen virtuellen Rechner auf dieser Maschine eingerichtet. Als erstes wurden zwei virtuelle
Maschinen mit Windows 2003 Server und Windows XP Workstation installiert, die uns als
Basisrechner und Vorlage für weitere Tests dienen. Von diesen Basisrechnern ausgehend
können mit wenig Aufwand weitere Maschinen unproblematisch geklont und Zeit gespart
werden. Bei diesem Verfahren muss lediglich der Rechnername und die Netzwerkkonfiguration angepasst werden. In der beigelegten DVD befindet sich ein Beschrieb
„MT_Installation_Win2k3.pdf“ im Verzeichnis „OperatingSystem\Windows\Install_Docs“, wie
unsere Betriebssysteme aufgesetzt und konfiguriert sind.
In der Inbetriebnahme unserer Testumgebung stellten wir frühzeitig fest, dass unser
physischer Rechner ziemlich rasch am Limit seiner Leistung stand. Die Endstation erreichte
der Rechner bereits beim gleichzeitigen Betrieb von drei virtuellen Maschinen. Die
Performanz litt stark darunter und ein effizientes Arbeiten war nicht mehr garantiert. Nun
standen wir vor der Wahl einen zweiten identischen oder einen neuen leistungsstärkeren
Rechner zu beschaffen. Nach diverse Pro und Kontra haben wir uns für die zweite Variante
entschieden. Entscheidend waren folgende Kriterien:
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 32
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
•
VMware stellt die Software „ESX3i Update 2“ gratis zur Verfügung
•
ESX3i ist ein eigenes Betriebssystem (-> eine eigene Linux-Distribution) und benötigt
kein Basisbetriebssystem wie bei VMware Workstation
•
Keine Zusatzlizenz für das Betriebssystem des physischen Rechners
•
Nur 32 MB disk footprint
•
Da kein zusätzliches Basisbetriebssystem benötigt wird, steigt die Performanz der
virtuellen Maschinen
Ein Nachteil des ESX3i ist, dass nicht alle Hardware (folglich alle Computer) unterstützt
werden. Zur Beschaffung des neuen Rechners mussten wir vorgängig das „Systems
Compatibility Guide“ von VMware konsultieren.
(http://www.vmware.com/resources/compatibility/docs/vi35_io_guide.pdf).
Aus diesem Dokument haben wir uns dann für folgende Maschine entschieden:
• Dell PowerEdge 2900 III
Mit Hilfe des Dokumentes „ESX Server 3i Installable Setup Guide“ konnte die Applikation
problemlos installiert werden.
(http://www.vmware.com/pdf/vi3_35/esx_3i_i/r35u2/vi3_35_25_u2_3i_i_setup.pdf)
Die bereits erstellten virtuellen Maschinen auf dem ursprünglichen Rechner Dell Inspiron 530
konnten einfach und sicher auf dem neuen Testrechner migriert werden. Dazu stellt VMware
gratis den Konverter „VMware Converter 3.0.3 (Starter Edition)“ zur Verfügung, der nicht nur
die Fähigkeit hat, virtuelle Maschinen von VMware Workstation zu migrieren, sondern auch
aus physischen Rechner einen virtuellen Image erstellen kann. (Für weitere Info siehe
http://www.vmware.com/pdf/VMware_Converter_manual302.pdf)
Die virtuellen Maschinen auf unserem Testrechner können nicht direkt von der Konsole aus
verwaltet werden. Für die Verwaltungsaufgaben dient der Client „VMware Infrastructure
Client“, der von unserem Testrechner heruntergeladen werden kann. (Diese Software wird
vom der ESX3i Installation mitgeliefert.)
Auf den Arbeitsrechnern „Angelo3“ und „Isidoro“ ist die Applikation installiert worden, damit
jeder autonom seine Aufgaben abwickeln kann. Via dem „Remote Desktop Connection“ von
Microsoft, der Bestandteil von Windows XP ist, kann man sich leicht auf die virtuellen
Maschinen anmelden.
5.3 Netzwerk
Die physischen Maschinen sind in einem TCP/IP 100Mbit/s Netzwerk untereinander
verbunden. Der ADSL-Router (Linksys ADSL Gateway), der uns als Internet-Zugang dient,
fungiert zugleich als DHCP Server.
Um bei unserer Präsentation Unvorhergesehenes zu vermeiden, haben wir beschlossen, die
IP-Adressen der Maschinen fest zu vergeben. Von dieser Regel sind die zwei
Arbeitsstationen „Angelo3“ und „Isidoro“ ausgeschlossen.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 33
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
5.4 Arbeitsgruppe
Unsere Windows-Rechner sind einfachshalber nicht in einer Domäne vereint, sondern sie
gehören der Arbeitsgruppe namens „MASTERTHESIS“ an. Daher muss kein DomainController mit dem Active Directory aufgesetzt werden. Jedoch müssen alle notwendigen
Benutzer auf jedem Rechner angelegt werden. Da es zurzeit um wenige Benutzer handelt,
fällt dieser Aufwand wenig ins Gewicht.
5.5 Gesamtübersicht der Test-Umgebung
5.5.1
Netzplan
Mit dem vorliegenden Netzplan werden die physischen und virtuellen Maschinen abgebildet:
Abbildung 28: Netzplanübersicht der Test-Umgebung
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 34
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
5.5.2
Auflistung der Testmaschinen
Der Inhalt des Netzplans wird hier als Tabelle aufgelistet:
Rechner- /
Gerätename
Virtuelle
Maschinenname
Betriebssystem
IP-Adresse
Arbeitsgruppe
Funktion
Linksys
AG041
-
-
192.168.1.1
-
Internet-Zugang (Default Gateway)
DHCP
DNS (nur externe Adressen)
VMwareSRV
-
ESX3i
Upgrade 2
192.168.1.2
localdoma VMware Host
in
Alle virtuellen Maschinen werden
auf diesem Rechner verwaltet
Angelo3
-
Windows
2000 (EN)
DHCP
LOIUDICE
Arbeitsstationen:
VMware Infrastructure Client
Remote Desktop Connection
Eclipse 3.4
Isidoro
-
Windows XP
(EN)
DHCP
LOIUDICE
Arbeitsstationen:
VMware Infrastructure Client
Remote Desktop Connection
Eclipse 3.2
Server_Templ WindowsServ Windows
ate
er2003Standa 2003 (EN)
rd_MyBasic
DHCP
-
Nur Windows 2003 installiert
-> Dient als Vorlage. Falls einen
weiteren Windows Server benötigt
wird, kann er von dieser Vorlage
dupliziert werden.
WIN2K3ORA
10g
WIN2K3ORA
10g
Windows
2003 (EN)
192.168.1.12
(fix)
MASTER
THESIS
Oracle 10g
Oracle Database Lite 10g
- Mobile Server (SSL konfiguriert)
- Mobile Development Kit
MTDBSERVERTMP
MTDBSERVERTMP
Windows
2003 (EN)
192.168.1.21
(fix)
MASTER
THESIS
Oracle 10g
Oracle Database Lite 10g
- Mobile Server (ohne SSL
konfiguriert)
- Mobile Development Kit
WinXP_Temp WindowsXP_
late
MyBasic
Windows XP
(EN)
DHCP
-
Nur Windows XP installiert
-> Dient als Vorlage. Falls einen
weiteren Client benötigt wird, kann
er von dieser Vorlage dupliziert
werden.
TestclientA
TestclientA
Windows XP
(EN)
192.168.1.63
(fix)
MASTER
THESIS
Testmaschine für Oracle Database
Lite 10g
TestclientB
TestclientB
Windows XP
(EN)
192.168.1.62
(fix)
MASTER
THESIS
Testmaschine für Oracle Database
Lite 10g
TestclientC
TestclientC
Windows XP
(EN)
192.168.1.64
(fix)
MASTER
THESIS
Testmaschine für Funambol
TestclientD
TestclientD
Windows XP
(EN)
192.168.1.65
(fix)
MASTER
THESIS
Testmaschine für Funambol
TestclientE
TestclientE
Windows XP
(EN)
192.168.1.66
(fix)
MASTER
THESIS
Testmaschine für MS Sync
Services for ADO.NET
TestclientF
TestclientF
Windows XP
(EN)
192.168.1.67
(fix)
MASTER
THESIS
Testmaschine für MS Sync
Services for ADO.NET
5.6 Hardware und Softwarelizenzen
Die Firma LO iUDiCE hat sowohl beide physische Testrechner wie auch alle notwendigen
Microsoft-Softwarelizenzen zur Verfügung gestellt.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 35
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
6 System I
6.1 Einleitung
Nach den ersten Recherchen im Internet haben wir beschlossen den Oracle Database Lite
zu evaluieren. Schon beim Durchlesen der Kurzbeschreibung und der Eigenschaften haben
wir festgestellt, dass die Applikation unseren Anforderungen entspricht. Sie ist eine
Schnittstelle zwischen unsere Hauptdatenbank und den lokalen Datenbanken auf den
mobilen Geräten und fähig eine bidirektionale Synchronisation zu verwalten, das heisst,
Änderungen auf der lokalen Datenbank werden erkannt und in der Hauptdatenbank
nachgetragen und umgekehrt. Ein weiteres Plus dieser Applikation ist auch die integrierte
Software-Paketisierung. Unter anderem kann die Applikation auf verschiedenen Plattformen
(Windows, Unix und Linux) laufen und unterstützt auch diverse Client-Betriebssysteme.
Zu ihrem Nachteil muss allerdings erwähnt werden, dass die Oracle Database Lite vorläufig
mit Oracle Back-End-Datenbanken eingesetzt werden kann. Oracle Database Lite stellt unter
anderem für den Client einen ADO.NET Provider zur Verfügung, mit dem man auf
Datenbanken von anderen Herstellern zugreifen kann.
6.2 Aufbau
Vorgängig muss eine Oracle Datenbank als Back-End-Datenbank (Oracle9.2, Oracle10g
oder Oracle11g) zur Verfügung stehen. Auf einem zweiten Rechner (kann aber auch auf
demselben Datenbankserver sein) wird die Applikation Oracle Database Lite bestehend aus
den Komponenten Mobile Server und Mobile Development Kit installiert. Auf den mobilen
Geräten (wie Notebook, Desktop und Handhelds) wird hingegen den Oracle Database Lite
Client, den Prototyp GUI „survey“ und unter anderem auch eine kleine „footprint“ SQL
Datenbank installiert, die als lokale Datenbank dient.
In unserer Test-Umgebung haben wir beschlossen, die Hauptdatenbank (Back-EndDatenbank) und die Oracle Database Lite auf der gleichen Maschine zu installieren. Wir
verwenden Oracle 10g mit Patch 3 als Back-End-Datenbank. Da die Oracle Software auf
diverse Betriebssysteme läuft, entschieden wir uns für die Windows Server 2003 Umgebung.
Zwei Windows XP Computer dienen als Testclient.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 36
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
6.2.1
Übersicht unserer Test-Umgebung
Das nachfolgende Bild zeigt eine Übersicht unserer Test-Umgebung:
Abbildung 29: Systemübersicht I der Test-Umgebung
6.3 Funktion des Oracle Database Lites
Der Oracle Database Lite Mobile Server hat folgende Funktionen:
•
Schaltet Benutzer und Geräte frei, die mit der Oracle Database Lite Umgebung arbeiten
•
Bietet Kundenapplikationen an und verwaltet sie
•
Verwaltet den Zugriff auf der Hauptdatenbank
Mit der Mobile Database Workbench werden Projekte und deren Elemente erstellt, um den
Zugriff auf der Hauptdatenbank zu steuern.
Hier wird Folgendes definiert:
•
Datenbankinformationen: DB-Name, DB-Server, Port
•
Anwendungsschema: Benutzername und Passwort des Datenbankschemas
•
Tabellen: Welche Tabellen zur lokalen Datenbank veröffentlicht werden
•
Veröffentlichung der Elemente
Mit Hilfe des Packaging Wizards können die Kundenapplikationen verpackt und die
dazugehörige Plattform definiert werden. Die Softwarepakete können anschliessend an
Oracle Database Lite Benutzern zugewiesen werden und somit steht die Applikation zur
Installation bereit. Sobald auf dem Mobilgerät der Oracle Database Lite Client (Mobile Client)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 37
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
aufgesetzt ist, wird beim Aktualisieren des Clients die veröffentliche Applikation
heruntergeladen und installiert.
6.4 Funktion der Synchronisation
Abbildung 30: Funktion der Synchronisation
Quelle Oracle Database Lite Developer's Guide 10g (10.3.0.2) E12089-01
Die Synchronisation via Oracle Database Lite ist bidirektional. Änderungen auf der ClientDatenbank werden zur Hauptdatenbank transferiert und umgekehrt. Das Ganze spielt sich
auf dem Mobile Server ab. Der Mobile Server besitzt drei Warteschlangen; die IN-, die OUTund die ERROR-Queue.
Abbildung 31: MGP-Status
Beim Synchronisieren (ob manuell oder automatisch) werden die Modifikationen vom Client
in die IN-Queue abgelegt. Anschliessend überprüft der Mechanismus, ob in der OUT-Queue
irgendwelche Änderungen für den Client zur Verfügung stehen. Falls ja, werden die Daten
heruntergeladen. Ansonsten endet hier die Aktion. Für den Datentransfer sind zwei in
Partnerschaft arbeitende Synchronisations-Werkzeuge Sync Client und Sync Server
zuständig. Sync Client befindet sich auf dem Client und Sync Server ist auf dem Mobile
Server installiert.
Ferner besitzt der Mobile Server noch einen wichtigen Dienst, der sogenannte Message
Generator and Processor (MGP). Dieser Dienst sammelt von Zeit zu Zeit die in der IN-Queue
hochgeladenen Informationen und leitet sie zur Back-End-Datenbank weiter. Anschliessend
richtet er die Änderungen für alle Oracle Database Lite Benutzer her und stellt sie in der
OUT-Queue bereit. Bei der nächsten Client-Synchronisation werden die angepassten Daten
zum Client heruntergeladen.
Tritt beim Abarbeiten der Transaktionen durch den MGP einen Konflikt oder einen Fehler
auf, so wandern diese in der ERROR-Queue.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 38
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 32: Synchronisationsprozess
Quelle Oracle Database Lite Developer's Guide 10g (10.3.0.2) E12089-01
6.4.1
Manuelle Synchronisation
Die manuelle Synchronisation kann vom Benutzer auf dem Client jederzeit ausgeführt
werden, sobald eine Verbindung zur Hauptdatenbank besteht. Dazu muss die Applikation
msync.exe (im Verzeichnis C:\mobileclient\bin) gestartet werden.
Abbildung 33: Panel msync
Benutzername, Passwort sowie der Name des Mobile Servers müssen angegeben werden,
um die Synchronisation über die Schaltfläche „Sync“ starten zu können. Mit „Apply“ können
die Einstellungen gespeichert werden. Mit „Exit“ verlässt man die Applikation. Beim
Abschluss der Synchronisation erscheint das unten abgebildete Dialog-Fenster:
Abbildung 34: Sync Result Dialog
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 39
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Mit der Schaltfläche „Show Log“ kann die History der Synchronisation angezeigt werden.
Abbildung 35: Panel Show Log
6.4.2
Automatische Synchronisation
Beim Erstellen oder Modifizieren des Software-Projekts, das mit der Mobile Database
Workbench (MDW) erstellt wird, kann die automatische Synchronisation ein- respektive
ausgeschaltet werden.
Abbildung 36: Synchronisationsoption ein- und ausschalten
Mit der aktivierten Option führt der Mobile Server eine Synchronisation automatisch durch,
sobald die definierten Ereigniswerte überschritten werden. Der Mobile Server unterstützt
zwei Ereignisse, die die Synchronisation auslösen können:
•
Wenn die Anzahl der geänderten Datensätze in der Client-Datenbank den Schwellenwert
überschreiten.
•
Wenn die Anzahl von geänderten Datensätze in der OUT-Queue auf dem Server den
Schwellenwert überschreiten.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 40
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 37: Synchronisationsereignisse ein- und ausschalten
Mittels MDW können im Deployment-Projekt die zwei Ereignisse aktiviert und ihre
Schwellenwerte definiert werden. Für das Auslösen der automatischen Synchronisation
haben wir beschlossen, die Schwellenwerte auf 1 zu setzen, damit jede Änderung gleich
ausgeglichen wird.
6.5 Installationsablauf des Systems I
6.5.1
Installation auf dem Server
Vorbedingung: Der Datenbankserver MT-DBServer-TMP (Windows Server 2003) steht als
virtuelle Maschine bereit.
1.) Installiere die Oracle 10g Software auf dem Server. (siehe Dokument
„MT_Installation_Oracle10g.pdf“ im Verzeichnis „OracleDatabaseLite\Install_Docs“ auf
der beigelegten DVD)
2.) Installiere den TNS-Listener und verwende den Standard-Port 1521 (siehe Dokument
„MT_Installation_Oracle10g.pdf“ im Verzeichnis „OracleDatabaseLite\Install_Docs“ auf
3.) Erstelle eine neue Datenbank mit dem Namen „vermdb“ (siehe Dokument
„MT_Create_Database_Vermdb.pdf“ im Verzeichnis „OracleDatabaseLite\Install_Docs“
auf der beigelegten DVD)
Verwende dazu die eigenen sql-Skripten, die im Verzeichnis
„OracleDatabaseLite\ORAscripts2CreateDB\scripts“ auf der beigelegten DVD sind. (Es
besteht die Möglichkeit die Datenbank auch mit dem Konfigurations-Assistenten zu
erstellen.)
4.) Erstelle den Dienstnamen in die TNSNAMENS.ORA Datei. (siehe Dokument
„MT_Configure_TNSNAMENS.pdf“ im Verzeichnis „OracleDatabaseLite\Install_Docs“ auf
5.) Erstelle den Datenbankbenutzer „VERMSYS“ (siehe Dokument
„MT_Create_User_vermsys.pdf“ im Verzeichnis „OracleDatabaseLite\Install_Docs“ auf
6.) Erstelle die Tabelle „tabkoord“ in das Schema „vermsys“ (siehe Dokument „MT_
Create_Table_tabkoord.pdf“ im Verzeichnis „OracleDatabaseLite\Install_Docs“ auf der
beigelegten DVD)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 41
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
7.) Installiere den „Mobile Development Kit“ (siehe Dokument „MT_Installation_OLite.pdf“ im
Verzeichnis „OracleDatabaseLite\Install_Docs“ auf der beigelegten DVD)
8.) Installiere den „Mobile Server“ (siehe Dokument „MT_Installation_OLite.pdf“ im
Verzeichnis „OracleDatabaseLite\Install_Docs“ auf der beigelegten DVD)
6.5.2
Einbindung unseres Software-Pakets (Prototyp GUI) im Server-Projekt
Vorbedingung: Die survey.jar ist erstellt und ist auf dem Datenbankserver MT-DBServerTMP kopiert.
Alle notwendigen Schritte sind im Dokument „MT_Start_Mobile_Database_Workbench.pdf“
im Verzeichnis „OracleDatabaseLite\Install_Docs“ auf der beigelegten DVD beschrieben.
1.) Erstelle ein neues „Mobile Database Workbench Projekt“ namens „survey“
2.) Erstelle ein Publikationselement namens „tabkoord“
3.) Erstelle die Publikation namens „SURVEY“ und definiere den Namen der ClientDatenbank „localvermdb“
4.) Erstelle das Software-Paket „Mobile Survey“, wähle die Publikation „SURVEY“ aus, die
unter dem Punkt 3 kreiert wurde, und schliesse unsere Applikation „survey.jar“ in das
Paket ein.
Wichtiger Hinweis: Falls bei der Installation des Mobile Servers das Kommunikationsprotokoll
"Secure Sockets Layer" (SSL) aktiviert wurde, kann die Erstellung des Pakets nicht
erfolgreich durchgeführt werden. Die Anmeldung mit dem Mobile Server schlägt fehl.
Fazit: Wir haben diese Erfahrung gemacht. Da wir das SSL nicht mehr ausschalten und kein
Hinweis zum Problem finden konnten, haben wir den Mobile Server nochmals neu
aufgesetzt. Später aber fanden wir im Dokument „Oracle Database Lite Administration and
Deployment Guide 10g“ Kap. 12.4.3, S. 12-9 folgende Oracle-Bemerkung:
…If you enable the Mobile Server to be SSL-Enabled, then you have to change the
configuration on the host where the Packaging Wizard is located in order for it to successfully
communicate with the Mobile Server.
In order for Packaging Wizard to be SSL-Enabled, set the SSL parameter to TRUE in the
webtogo.ora file located on the host where the MDK is installed...
6.5.3
Verwaltung unseres Software Pakets „Mobile Survey“
1.) Starte das Mobile Server Manager. Öffne dafür einen Internet-Browser und trage die
Adresse ein: „http://mt-dbserver-tmp/webtogo
2.) Editiere die Applikation „Mobile Survey“
3.) Definiere die korrekten Datenbankverbindungsinformationen
4.) Erstelle die Applikationsbenutzer (falls nicht schon vorhanden)
5.) Weise die Applikation den Benutzern zu
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 42
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
6.5.4
Installation auf dem Client
Installiere unsere Applikation „Mobile Survey“ auf dem Client
Vorbedingung: Die Testrechner TestclientA (Windows XP) und TestclientB (Windows XP)
stehen als virtuellen Maschinen bereit.
1.) Installiere den Oracle Database Lite Client auf der Maschine „TestclientA“. Öffne dafür
einen Internet-Browser und trage die Adresse ein: „http://mt-dbserver-tmp/webtogo/setup
2.) Wähle die richtige Plattform aus (-> Oracle Lite WIN32, EN)
3.) Trage den Oracle Database Lite Benutzer und sein Passwort ein.
4.) Installiere die Applikation auf dem mobilen Gerät.
5.) Starte das Werkzeug „sync“ auf dem Client, um die Daten zu synchronisieren respektive
um die Applikation zu aktualisieren.
6.) Installiere die Applikation „Mobile Survey“ auf dem Client.
7.) Überprüfe, ob die lokale DB exisitert und ob der ODBC-Eintrag erstellt wurde
8.) Wiederhole Schritt 1-7 für den TestclientB. -> Verwende einen anderen Benutzernamen!
Achtung! Oracle verweist auf Folgendes gemäss Dokument „Oracle Database Lite
Developer's Guide 10g“ Kap. 9.5.1, S.9-19:
…You have to install the Mobile Client on a machine which does not host the Mobile Server
installation. You can configure only one device for a particular platform per user…
6.6 Systemtest I
Oracle Database Lite bietet sowohl eine automatische wie auch eine manuelle
Synchronisierung an. Wir haben zuerst die Testfälle mit der automatischen Synchronisation
durchgeführt. Mit der Wahl der Automatisierung konnten die Prozesse der Aufgaben nicht
eindeutig analysiert werden. Die Prozesse waren für uns nicht transparent. Die erwarteten
Konfliktsituationen wie zum Beispiel Aufgaben 3 und 4 kamen nicht zum Vorschein. Das
Resultat der automatischen Synchronisation „MT_OLite_autom_Testverfahren.pdf“ befindet
sich im Verzeichnis „OracleDatabaseLite\Testfälle“ auf der beigelegten DVD.
Wir haben die Tests mit der manuellen Synchronisation dreimal wiederholt und sind zu
folgendem Ergebnis gekommen, wie nachfolgend in den Unterkapiteln beschrieben.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 43
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
6.6.1
Ausgangslage
Bei unseren Testfällen gehen wir gemäss Pflichtenheft von diesen Bedingungen aus:
•
Die Stammdaten befinden sich in der Hauptdatenbank
•
Client A und B sind online für die Fälle 1-6
•
Client A und B sind offline für die Fälle 7-8
Anhand folgendes Skriptinhalts (siehe Dokument „Stammdaten.sql“ im Verzeichnis „SQLSkripte“ auf der beigelegten DVD) werden die Stammdaten in der Hauptdatenbank
importiert:
DELETE FROM tabkoord;
COMMIT;
SELECT * FROM tabkoord;
INSERT INTO tabkoord (pktnr, ykoord, xkoord) VALUES (1, 660634.772, 244641.123);
COMMIT;
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 44
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Auf die Bildschirme des Servers und der Clients sehen die Startsituationen folgendermassen
aus.
Startsituation in der Hauptdatenbank:
Abbildung 38: Startsituation in der Hauptdatenbank (Ausgangslage)
Startsituation auf dem TestclientA:
Abbildung 39: Startsituation TestclientA (Ausgangslage)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 45
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Startsituation auf dem TestclientB:
Abbildung 40: Startsituation TestclientB (Ausgangslage)
6.6.2
Testfälle
Fall 1:
TestclientA:
Fügt einen neuen Punkt 6 mit den Koordinaten 10.0 und 11.0 ein:
Abbildung 41: Punkt einfügen TestclientA (Fall 1)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 46
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 42: Neuer Punkt TestclientA (Fall 1)
Manuelle Synchronisation starten
(verwende die Applikation C:\mobileclient\bin\msync.exe)
Abbildung 43: Start msync.exe bei TestclientA (Fall 1)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 47
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Situation in der Hauptdatenbank:
Abbildung 44: Situation in der Oracle Hauptdatenbank (Fall 1)
Situation TestclientB:
Abbildung 45: Start msync.exe bei TestclientB (Fall 1)
Refresh-Button auf dem GUI klicken
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 48
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 46: Neuer Punkt TestclientB (Fall 1)
Fall 2:
TestclientB:
Modifiziere den bestehenden Punkt 3 mit folgenden Werten:
Y-Koordinaten = 10.0 und X-Koordinaten = 110.0
Selektiere Punkt 3
Abbildung 47: Punkt 3 modifizieren TestclientB (Fall 2)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 49
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Ändere Koordinatenwerte von Punkt 3
Abbildung 48: Situation TestclientB (Fall 2)
Punkt 3 ist lokal gespeichert. Manuelle Synchronisation wird gestartet.
Abbildung 49: Start msync.exe bei TestclientB (Fall 2)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 50
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Situation in der Hauptdatenbank
Situation TestclientA:
Abbildung 51: Start msync.exe bei TestclientA (Fall 2)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 51
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 52: Situation TestclientA (Fall 2)
Fall 3:
Beide Clients fügen „gleichzeitig“ denselben Punkt 7 aber mit diversen Werten ein:
TestclientA:
Abbildung 53: Situation TestclientA (Fall 3)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 52
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
TestclientB:
Abbildung 54: Situation TestclientB (Fall 3)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 53
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Beim gleichzeitigen Synchronisieren entsteht ein Konflikt. Die Daten des Clients B sind
permanent gespeichert worden, da er ein bisschen schneller war. Die Daten des Clients A
hingegen befinden sich in der ERROR-Queue.
Abbildung 56: Fehler-Queue-Datensätze bearbeiten (Fall 3)
Nun ist es Aufgabe des Administrators zu entscheiden, welche Daten korrekt sind und in der
Datenbank gespeichert werden müssen. Die ERROR-Queue bietet die Möglichkeit die
Information entweder zu löschen, zu aktualisieren oder in der Datenbank als weiterer Punkt
hinzuzufügen. Wir spielen die Rolle des Administrators und betrachten die Werte des Clients
A als korrekt. Um die Werte des Clients A in der Hauptdatenbank zu speichern, geht man
wie folgt vor:
Wähle „Aktualisieren“ (1), da der Punkt bereits in der Hauptdatenbank mit falschen Werten
existiert und speichere (2) die Einstellung.
2
1
Abbildung 57: Fehler-Queue-Datensatz-Detail (Fall 3)
Anschliessend klickt man auf „Ausführen“ im Fenster „Fehler-Queue-Transaktionen“. Die
Werte des Clients B werden von denen des Clients A in der Hauptdatenbank überschrieben.
Abbildung 58: Fehler-Queue-Transaktion (Fall 3)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 54
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Führe jetzt die manuelle Synchronisation beim Client B aus und klicke auf den
Refresh-Button des GUI. Das GUI zeigt die Werte von A an!
Abbildung 59: Refresh-Situation TestclientA (Fall 3)
Um den eigentlichen MGP-Prozess der Konfliktbehebung besser zu verstehen, haben wir die
Aufgabe mehrmals wiederholt. Dabei sind wir für unser Testszenarium zu folgendem Fazit
gekommen.
Fazit: Bei der Erfassung neuer Datensätze durch diverse Clients muss sichergestellt werden,
dass die Clients unterschiedliche Punktnummer verwenden. Das entspricht auch die Praxis
im Vermessungswesen.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 55
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Fall 4:
TestclientA:
Löscht den Punkt 3
Abbildung 60: Startsituation TestclientA (Fall 4)
Abbildung 61: Endsituation TestclientA (Fall 4)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 56
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Punkt 3 existiert nicht mehr!
In der OUT-Queue steht die Information des gelöschten Punkts 3 für den Client B (Benutzer
ANGELO) zur Verfügung.
Abbildung 63: Out Queue-Publikationen
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 57
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Detail der Information
Abbildung 64: Out Queue-Detailinformation (Fall 4)
TestclientB:
Unmittelbar danach ändert die Koordinaten des Punkts 3 (Y=1234; X=4321)
Selektiere Punkt 3
Abbildung 65: Startsituation TestclientB (Fall 4)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 58
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 66: Punkt 3 modifizieren TestclientB (Fall 4)
Abbildung 67: Endsituation TestclientB (Fall 4)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 59
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Der aktualisierte Punkt 3 vom Client B erscheint nicht in der Hauptdatenbank, weil er einen
Konflikt ausgelöst hat. Im OUT-Queue stand die Information des gelöschten Punkts 3 (vom
Client A) für ihn bereit. Gleichzeitig setzt der Client B den Punkt 3 in der IN-Queue. Daraus
erfolgt der Konflikt!
Abbildung 69: Fehler-Queue Info (Fall 4)
Abbildung 70: Fehler-Queue-Datensatz-Detail (Fall 4)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 60
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Fazit: Ähnlich wie bei der Aufgabe 3 muss nun der Administrator entscheiden, wie der
Konflikt zu lösen ist. Wir beschliessen den Punkt 3 des Clients B in die Datenbank zu
speichern.
Wähle im Feld „DML aktualisieren“ diesmal „Einfügen“ (1), da der Punkt in der Hauptdatenbank nicht mehr existiert und speichere (2) die Einstellung.
1
2
Abbildung 71: Fehler-Queue-Datensatz „Einfügen“ (Fall 4)
Anschliessend klickt man auf „Ausführen“ im Fenster „Fehler-Queue-Transaktionen“ (für
Ausführungsdetails siehe Aufgabe 3).
Abbildung 72: In Queue Info (Fall 4)
Der MGP-Prozess bearbeitet die IN-Queue und stellt die Modifikation in der OUT-Queue für
den betroffenen Client bereit. Dann synchronisiert der Client A erneut. Und er besitzt wieder
den Punkt 3 in seiner lokalen Datenbank.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 61
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Fall 5:
Lösche den Punkt 3 direkt aus der Hauptdatenbank
Abbildung 73: Verbindung mit der Oracle Hauptdatenbank (Fall 5)
Abbildung 74: Punkt 3 in der Oracle Hauptdatenbank löschen (Fall 5)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 62
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Situation TestclientA & B:
Abbildung 75: Situationen TestclientA & B (Fall 5)
Fall 6:
Modifiziere die Koordinatenwerte des Punkts 6 direkt in der Hauptdatenbank
Y = 1234 und X = 4321
Abbildung 76: Verbindung mit der Oracle Hauptdatenbank (Fall 6)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 63
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 77: Punkt 6 in der Oracle Hauptdatenbank modifizieren (Fall 6)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 64
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 79: Situationen TestclientA & B (Fall 6)
Fall 7:
Bemerkung: Die Clients müssen bei einer manuellen Synchronisation nicht offline gesetzt
werden, denn die Synchronisierung findet erst beim Starten der Applikation msync statt.
Bedingung: Vorgängig wird die ursprüngliche Ausgangslage wiederhergestellt.
Skript „Stammdaten.sql“ in die Hauptdatenbank importieren
TestclientA:
Füge 2 neue Punkte ein
Punkt 6 (Y = 1234; X = 4321) und Punkt 7 (Y = 9876; X = 6789)
TestclientB:
Füge 2 weitere Punkte ein
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 65
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 81: Situationen TestclientA und TestclientB (Fall 7)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 66
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Trage die entsprechenden Punkte in den jeweiligen Client ein.
TestclientA:
Abbildung 82: Punkte 6 und 7 einfügen TestclientA (Fall 7)
TestclientB:
Abbildung 83: Punkte 8 und 9 einfügen TestclientB (Fall 7)
Manuelle Synchronisation auf beide Clients gleichzeitig starten
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 67
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Situation in der IN-Queue:
Abbildung 84: Situation in der In Queue (Fall 7)
Situation in der Hauptdatenbank „vermdb“ nach dem der MGP-Prozess beendet ist:
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 68
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Situation in der OUT-Queue nach dem der MGP-Prozess beendet ist:
OUT-Queue für TestclientB (User ANGELO)
Abbildung 86: Situation in der Out Queue für TestclientB (Fall 7)
OUT-Queue für TestclientA (User ISIDORO)
Abbildung 87: Situation in der Out Queue für TestclientA (Fall 7)
Manuelle Synchronisation auf beide Clients gleichzeitig starten
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 69
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Situation TestclientA:
Nach dem Klicken des „Refresh“-Buttons auf unserem GUI erscheinen nun auch die Punkte
des TestclientB.
Punkte, die vom
Client B stammen
Abbildung 88: Refresh-Situation TestclientA (Fall 7)
des TestclientA.
Punkte, die vom
Client A stammen
Abbildung 89: Refresh-Situation TestclientB (Fall 7)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 70
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Fall 8:
Aufgabenstellung
Änderung: Punkt 3 mit Koordinaten Y = 7654.321 und X = 1234.567
werden, denn die Synchronisierung findet erst beim Starten der Applikation msync statt.
Fazit: Die Aufgabe 8 entspricht der obigen Aufgabe 6 und endet somit hier.
6.6.3
Quintesenz der Testfälle beim System I
Die gesamte Testprozedur wurde mindestens dreimal durchlaufen. Am Anfang haben wir
unsere Tests mit der automatischen Synchronisation durchgeführt. Und die Tests liefen alle
glimplfich ab. Es gab überhaupt keine Konflikte. Dies entsprach nicht unsere Erwartung.
Deshalb untersuchten wir den Fall näher. Mit den von uns festgelegten Schwellenwerten
wurde nach jeder Änderung eine automatische Synchronisation gestartet. Somit kam es nie
zu Konflikten. Erst bei der Durchführung der manuellen Synchronisation traten bei den Fällen
3 und 4 die erwarteten Konflikte auf. Zum Nachteil für die Clients, werden sie darüber vom
System gar nicht informiert. Aber mit Hilfe der ERROR-Queue kann der Administrator diese
Konflikte leicht ermitteln und auch einfach beheben. In einem kleinen Benutzerumfeld sollten
die Konfliktfälle sehr selten auftreten. Die Wahrscheinlichkeit, dass zwei Clients den gleichen
Datensatz gleichzeitig ändern und synchronisieren, ist klein. Ausserdem muss bei der
Erfassung neuer Datensätze durch diverse Clients sichergestellt werden, dass die Clients
unterschiedliche Punktnummer verwenden. Das entspricht auch die Praxis im
Vermessungswesen. Mit regelmässigem Synchronisieren in kurzen Zeitabständen können
zusätzlich Konflikte vermieden werden. Ein gleichzeitiges Synchronisieren ist zu vermeiden!
Sollten dennoch Konflikte entstehen, löst diese schliesslich der Administrator nach
Rücksprache mit den Anwendern auf. Die offline-Fälle 7 und 8 machen nur bei einer
automatischen Synchronisation Sinn. Aufgabe 8 entspricht bei einer manuellen
Synchronisation der Aufgabe 6.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 71
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
7 System II
7.1 Einleitung
Als nächstes System haben wir beschlossen ein Open Source-System zu evaluieren. Bei der
Suche dieses Systems haben wir uns zu Beginn folgende Bedingungen festgelegt:
•
Das System muss eine analoge Testumgebung respektive Aufbau wie Oracle Database
Lite anbieten, aber gegenüber Oracle Database Lite ein heterogenes System sein.
•
Es soll kosten- und lizenzfrei sein.
Während unserem Studium lernten wir nebst der Datenbank Oracle auch MySQL kennen.
Aus diesem Grund nahmen wir als erstes MySQL als Open Source-System unter Betracht.
Wir wollten wissen, ob MySQL eine analoge Systemumgebung wie Oracle bot. Leider
stellten wir rasch fest, dass MySQL eine Umgebung mit Drittanbieter und bidirektionale
Synchronisation zur Verfügung stellt, welche aber mit Kosten verbunden ist. Standardmässig
sind die MySQL-Funktionen für Replikationen von einem MySQL-Datenbankserver (Master)
zu einem oder mehreren MySQL-Datenbankserver (Slave) nur auf einer EinwegSynchronisation (asynchron) eingestellt. Da MySQL keine bidirektionale Synchronisation
unterstützt, suchten wir im Internet nach einem geeigneten System weiter. Bei den Firmen
Synthesis AG und Funambol sind wir dann auf Produkten gestossen, welche unseren
Anforderungen am Nächsten entsprachen. Obwohl die Produkte beider Firmen sich sehr
ähneln, fiel die Wahl auf Funambol aus. Es war auch eine schnell beschlossene Sache, da
die Produkte von der Firma Synthesis kostenpflichtig sind. Bei einem Gespräch konnte
zudem unser Examinator Herr Wyss einige Input über Funambol liefern. Dies machte uns
auch die Auswahl leichter. Funambol bietet die Schnittstelle zwischen eine Hauptdatenbank
und den lokalen Datenbanken auf den mobilen Geräten und die bidirektionale
Synchronisation an, läuft ebenfalls auf die Plattformen (Windows und Linux), ist 100prozentig auf Java entwickelt worden und unterstützt die Datenbanken MySQL, HSQLDB
und PostgreSQL. Ferner stellt sie mehrere PIM-Clients (Personal Information Manager) für
die Synchronisation von Kalender-, E-Mailsdaten usw. standardmässig zur Verfügung. Zu
ihrem Nachteil besteht aber kein Client für unsere Aufgabe. Wir entwickelten daher aus den
Funambol-Dokumentationen einen eigenen Client und Connector.
7.2 Aufbau
Auf dem physischen Rechner wird ein VMware-Rechner mit Windows Server 2003
Betriebssystem aufgesetzt. Dort wird der Funambol Server (Server Bundles) samt
Komponenten (unter anderem unser eigen entwickelte Connector) installiert. Ebenfalls auf
dieser virtuellen Maschine befindet sich unsere Back-End-Datenbank. Als Back-EndDatenbank wird MySQL über XAMPP verwendet. XAMPP ist eine Ansammlung von Open
Source-Software, welche verschiedene Server (Apache Webserver, FTP-, FileZilla-,
Mercury-Server), MySQL Datenbank und Verwaltungsfunktionen bietet. Auf dem mobilen
Gerät wie Notebook und Desktop wird unser entwickelte Funambol-Client mit der HSQL
Datenbank, die als lokale Datenbank dient und unser Prototyp GUI „survey“ installiert.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 72
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
7.2.1
Abbildung 90: Systemübersicht II der Test-Umgebung
7.3 SyncML Technologie
Die SyncML Technologie ermöglicht den Datenaustausch zwischen zwei Anwendungsgeräten. Veränderte Daten werden zwischen zwei Datenbanken abgeglichen beziehungsweise eine lokale Datenbank wird von der Hauptdatenbank aktualisiert oder umgekehrt. Das
bekannteste Beispiel ist die Synchronisierung von PIM-Daten zwischen einem Desktop und
einem Handheld-Gerät. PIM steht für Personal Information Manager und ist eine Software,
die persönliche Daten wie Kontakte, Termine, Aufgaben, Notizen und E-Mails verwaltet.
SyncML geht sogar noch weiter und synchronisiert jede Art von Daten. Allerdings ist der
häufigste Einsatz somit verbunden, dass jedes Gerät seine Änderungen einem Server in
unserem Fall dem Funambol DS Server (DS steht für Data Synchronization) mitteilt. Die
Back-End-Datenbank enthält immer die neuesten up-to-date Datensätze, damit andere
Clients ihren Datenbestand aktualisieren können. Durch diese einfache SynchronisierungsTechnologie muss jedes Gerät nur einen Server kennen. Die untere Abbildung gibt einen
Überblick über SyncML. Auf der linken Seite sind die verschiedenen Geräte vom HandheldGerät bis zum Desktop-PC zu sehen. Diese kommunizieren mit dem SyncML-Protokoll über
das Internet und/oder über mobile Netze mit dem Funambol DS Server. Alle Geräte
synchronisieren mit dem Server über eine 1:1-Synchronisierung.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 73
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 91: SyncML Technologie
Quelle Funambol Data Synchronization Server Overview
7.3.1
SyncML Protokoll
Das SyncML Protokoll basiert auf XML. Das Transport-Protokoll kann HTTP-oder OBEX
(Object Exchange Protocol) sein. Eine SyncML-Sitzung besteht aus vier Phasen:
1.) Die Server-Benachrichtigungs-Phase (Server Alert Phase) ist optional und kann als PreInitialisierungs-Phase betrachtet werden. Sein Hauptzweck ist es, einen Client zu
informieren, dass der Server zur Synchronisierung bereit steht.
2.) Die Initialisierungs-Phase (Initialization Phase) wird vom Client (mobiles Gerät) gestartet.
Eine SyncML-Sitzung wird aufgebaut, um die Clientdaten mit dem Server zu
synchronisieren. In dieser Phase werden die Benutzer-Authentifizierung, die
Datenbankzugriff-Autorisierung, die Austauschfähigkeit, der Synchronisierungsinhalt und
-art und eine Übereinstimmungsprüfung behandelt.
3.) Die Datenaustausch-Phase (Data Exchange Phase) führt die eigentliche
Datenübertragung aus. Als erster startet der Client und übergibt seine Änderungen dem
Server. Der Server seinerseits nimmt die Daten entgegen und überprüft sie auf
Widersprüche (Konflikt). Anschliessend schickt der Server seine Änderungen dem Client
zu.
4.) Bei der Abschluss-Phase (Completion Phase) wird dem Server mitgeteilt, welches Abbild
(Mapping) abgefertigt wurde. Der Server stimmt mit dem Acknowledge zu und schliesst
somit die Sitzung ab.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 74
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 92: SyncML Protokoll
Das obige Abbild stellt eine zeitlich basierte Anordnung der vier Phasen.
7.4 Funambol DS Server Architektur
Der Funambol DS Server läuft entweder mit den Applikations-Servern Tomcat oder JBoss.
Der Applikations-Server bildet die Basis. Auf diesem Applikations-Server wird der Funambol
DS Server aufgesetzt. Im Bundle ist bereits Apache Tomcat enthalten. Weiter enthält der
Bundle folgende Komponenten:
•
Java Runtime Environment (JRE)
•
Hypersonic (JDBC-compliant) Database (HSQLDB)
•
Funambol Administration Tool
•
Software-Zubehör für Anwendung von Datensynchronisation
Der Funambol DS Server unterstützt neben der Standarddatenbank HSQLDB auch noch
MySQL und PostgreSQL als Back-End-Datenbanken. Bei der Anwendung von MySQL oder
PostgreSQL muss sowohl die Datenbank-Software wie auch den notwendigen JDBC-Treiber
installiert werden. Der Funambol DS Server besteht aus folgenden Komponenten:
•
Sync Adaptor
•
Input- und Output Pipeline Manager
•
Sync Engine
•
Sync Source
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 75
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Die untenstehende Grafik zeigt die Zusammenhänge sowie den Datenaustausch der
Synchronisation.
Abbildung 93: Funambol DS Server Architektur
7.4.1
Sync Adaptor (Protocol Transport Mapper)
Der Sync Adaptor nimmt XML-basierte SyncML-Nachrichten aus der HTTP-TransportSchicht entgegen, wandelt sie um und übergibt sie dem Input Pipeline Manager. Auf der
anderen Seite nimmt der Sync Adaptor vom Output Pipeline Manager ausgehende
Nachrichten entgegen, wandelt sie zu SyncML-Nachrichten um und sendet sie via HTTP
zum Gerät.
7.4.2 Pipeline Manager
Der In- und Output Pipeline Manager ist im Prinzip gleich. Ihr einzige Unterschied besteht
darin, dass ein für eingehende Nachrichten und der andere für ausgehende Nachrichten
zuständig ist. Ferner verrichten sie folgende Arbeiten:
•
Fehlerhafte Nachrichten werden detektiert
•
Eingehende Nachrichten werden blockiert, die man nicht bearbeiten möchte
•
Die Prozesse werden protokolliert
7.4.3
Sync Engine
Die Sync Engine ist das Herz des Funambol DS Servers und befasst sich mit den
Funktionen des SyncML Protokolls. Sie wickelt drei Phasen ab: Initialisierung,
Datenaustausch und Finalisierung und weist die Funktionen wie Autorisierung, Erkennung,
Konfliktlösung, und ID-Mapping auf. Der Benutzer kann die Zugriffs- und Konfliktlösungsfunktionen ändern.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 76
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
7.4.4
Sync Source
Der Sync Source (auch als Connector bezeichnet) bildet die Schnittstelle zur Back-EndDatenbank und greift auf die von einem mobilen Gerät zu synchronisierenden Daten zu. Eine
Sync Engine kann mehrere Sync Sources haben. Auch können mehrere Sync Sources auf
die gleichen Daten eingesetzt werden. Dies kann nützlich sein, wenn die abgerufenen Daten
in der Sync Source zusätzlich verarbeiten werden müssen.
Für einen sicheren Zugriff auf die Datenspeicherung muss der Connector auf die jeweilige
Anwendung erweitert respektive angepasst werden. Seine Hauptaufgabe ist die SyncML
relevanten Protokollausgaben zu maskieren und mit den bekannten Methoden
get/create/update/delete zu operieren. Der Connector wird als Modul im Funambol DS
Server implementiert.
7.5 Installationsablauf des Systems II
7.5.1
Vorbedingung: Der Funambol Server MT-FUNAMBOL (Windows Server 2003) steht als
virtuelle Maschine bereit.
1.) Installiere die Funambol DS auf dem Server (siehe Dokument „MT_
Installation_Funambol.pdf“ im Verzeichnis „Funambol\Install_Docs“ auf der beigelegten
DVD).
2.) Installiere die Software-Zusammenstellung XAMPP auf dem Server, damit die MySQL
Datenbank zur Verfügung steht (siehe Dokument „MT_Installation_XAMPP.pdf“ im
Verzeichnis „Funambol\Install_Docs“ auf der beigelegten DVD).
3.) Starte mit Hilfe des XAMPP-Control-GUI den Apache Web-Server und die MySQL
Datenbank
Abbildung 94: XAMPP Control-GUI Panel
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 77
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
4.) Erstelle eine neue Datenbank mit dem Namen „vermdb“ entweder mit dem XAMPP Portal
(http://localhost), siehe 4.a) oder über die Kommando-Konsole, siehe 4.b).
a.) Das Portal bietet das Werkzeug „phpMyAdmin“, um die Datenbanken zu verwalten.
Abbildung 95: XAMPP phpMyAdmin Tool
Abbildung 96: XAMPP Create new database Ausschnitt
b.) Um die Datenbank zu erstellen, muss man sich zuerst mit der MySQL Datenbank
verbinden:
mysql -uroot
Anschliessend erzeuge die neue Datenbank “vermdb” mit dem Befehl:
CREATE DATABASE vermdb;
Abbildung 97: Kommando-Konsole create database vermdb
5.) Erstelle die Tabelle „tabkoord“ in das Schema „vermsys“. Es gibt dabei zwei
Möglichkeiten entweder über das XAMPP-Portal, siehe 5.a) oder über die KommandoKonsole, siehe 5.b).
Verwende für beide Fälle den SQL Statement:
CREATE TABLE tabkoord
(pktnr VARCHAR(4) NOT NULL,
ykoord VARCHAR(9) NOT NULL,
xkoord VARCHAR(9) NOT NULL,
fmbstatus CHAR(1) NOT NULL,
fmbtimestamp TIMESTAMP NOT NULL,
PRIMARY KEY (pktnr));
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 78
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
a.) Via XAMPP-Portal:
Abbildung 98: XAMPP phpMyAdmin SQL query
b.) via Kommando-Konsole:
Verbinden mit der neuen Datenbank „vermdb“
mysql -uroot
use vermdb;
Abbildung 99: Kommando-Konsole create table tabkoord
6.) Erstelle den Datenbankbenutzer „VERMSYS“ mit Passwort
Verwende dafür die SQL Statements:
CREATE USER vermsys;
SET PASSWORD FOR vermsys = PASSWORD('vermsys');
GRANT all ON vermdb.* TO vermsys;
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 79
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Auch diese Statements können entweder mit dem XAMPP Portal oder mit der
Kommando-Konsole ausgeführt werden. (siehe Vorgehen im Punkt 5.))
7.) Konfiguriere den Funambol-Zugriff auf die MySQL Datenbank. Dabei muss die Datei
„Funambol\ds-server\install.properties“ editiert werden. Eine Kopie der Datei befindet sich
im Verzeichnis „Funambol\Config-Files“ auf der beigelegten DVD.
Folgende Anpassung ist in den Zeilen notwendig:
dbms=mysql
jdbc.classpath=../tools/jre-1.5.0/jre/lib/ext/mysql-connector-java-5.0.3-bin.jar
jdbc.driver=com.mysql.jdbc.Driver
jdbc.url=jdbc:mysql://localhost/vermdb?characterEncoding=UTF-8
jdbc.user=vermsys
jdbc.password=vermsys
Tipp: Wir schlagen vor, die zu ändernden Zeilen zu kopieren und die Originalzeilen mit
dem Hash-Zeichen(‚#’) auszukommentieren.
Hier ein Beispiel:
# dbms=hypersonic
dbms=mysql
8.) Kopiere den JDBC-Treiber für MySQL „mysql-connector-java-5.0.3-bin.jar“ im Verzeichnis
„Funambol\tools\jre-1.5.0\jre\lib\ext“.
9.) Erzeuge das notwendige Funambol-Schema in die MySQL Datenbank. Starte aus der
Kommando-Konsole die cmd-Datei „Funambol\bin\install.cmd“. Bestätige mit „y“ (für yes)
die Installation jedes Moduls.
7.5.2
Starten und Stoppen des Funambol DS Servers
Bedingung: Die Back-End-Datenbank muss hochgefahren sein.
Auf dem Windows-Server kann die Applikation über die Verknüpfung gestartet und gestoppt
werden:
Abbildung 100: Funambol DS Server starten und stoppen
Oder es besteht die Möglichkeit den Funambol DS Server via Kommando-Zeile zu starten
respektive zu stoppen.
...\Funambol\bin\restartall.cmd
...\Funambol\bin\stopall.cmd
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 80
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
7.5.3
Vorbedingung: Die Testrechner TestclientC (Windows XP) und TestClientD (Windows XP)
stehen als virtuelle Maschinen bereit. Java Runtime Environment (JRE) 6 (jre-6u11-windowsi586-p.exe) muss auf den Testclient installiert sein.
1.) HSQLDB Datenbank: Entpacke die Datei „hsqldb_1_8_0_10.zip“ und kopiere das
Verzeichnis hsqldb direkt auf der C:\ Partition des Testclients.
Um die Datenbank hochzufahren, muss unser bat-File „Start_HSQLDB_Server.bat“
gestartet werden, welche man im Verzeichnis C:\hsqldb kopiert. Das bat-File startet
HSQLDB im Server Modus.
Inhalt des Files „Start_HSQLDB_Server.bat“:
set JAVA_HOME=C:\Program Files\Java\jre6
set HSQLDB_HOME=C:\hsqldb
cd C:\hsqldb
java -cp %HSQLDB_HOME%\lib\hsqldb.jar org.hsqldb.Server -database.0 file:localvermdb dbname.0 localvermdb
Eine Kopie der Datei befindet sich im Verzeichnis „Tools\Databases\hsqldb“ auf der
beigelegten DVD.
2.) Prototyp GUI: Erstelle ein neues Verzeichnis namens „survey“ direkt auf der C:\ Partition
und kopiere unser survey.jar hinein. Eine Kopie der Datei befindet sich im Verzeichnis
„PrototypGUI_Java\Client\survey“ auf der beigelegten DVD.
3.) SyncML Client: Erstelle ein neues Verzeichnis „C:\VermSyncClient“ und kopiere den
Inhalt vom Verzeichnis „target“ aus unserem „VermSyncMLClient“ Projektverzeichnis.
Das Verzeichnis „target“ wurde durch die Build-Prozedur von ANT erstellt. Eine Kopie von
unserem Synchronisierungs-Client befindet sich im Verzeichnis
„Funambol\VermSyncClient“ auf der beigelegten DVD.
4.) Editiere die Datei C:\VermSyncClient\config\spds\syncml.properties und passe die
Variablen username, password und device-id je nach Bedürfnissen an.
Als Beispiel für den TestclientD:
username=test1
password=test1
device-id=Sync4jVerm1
7.6 Funambol Administration Tool
Um den Funambol DS Server zu verwalten, kann das Funambol Administration Tool
eingesetzt werden. Mit seiner Hilfe können sehr einfach die Servereigenschaften, die
Benutzer, die mobilen Geräte, die Principals (Kombination aus Benutzer und Gerät) und die
Module verwaltet werden. Während unserer Master Thesis haben wir uns nur ein bisschen
mit den Aufgaben der Benutzer-, Geräte- und Modulverwaltung befasst.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 81
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 101: Funambol Administration Tool GUI
Das Hauptfenster besteht links aus dem Navigations-, rechts aus dem Konfigurations- und
unten aus dem Nachrichtenbereich.
Navigationsbereich
Sobald man mit dem Funambol-Server angemeldet ist, wird er im Navigationsbereich
angezeigt. Die zu konfigurierenden Aufgaben werden in einer baumförmigen Struktur
darunter angezeigt.
Konfigurationsbereich
Die Eigenschaften der im Navigationsbereich selektierten Aufgabe werden angezeigt. Hier
können ihre Werte angepasst werden. Nebst der Modifikation der Werte können auch
Benutzer und Geräte hinzugefügt oder gelöscht werden.
Nachrichtenbereich
Die Statusnachrichten des Administration Tools werden hier angezeigt.
Um sich mit dem Funambol DS Server zu verbinden, wählt man das Menü „File | Login“ aus:
Abbildung 102: Anmelden an Funambol Administration Tool
Das Anmelde-Fenster wird gestartet. Man gibt den Namen und das Passwort eines
Administrators (Standard: Admin/sa) an, um die Verbindung zu erlauben.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 82
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 103: Anmeldepanel Funambol Administration Tool
7.6.1
Benutzerverwaltung
Mit einem Doppelklick auf das Menü „Users“ im Navigationsbereich wird das Suchfenster der
Benutzer geöffnet. Mit Hilfe von Filtereinstellungen können nach bestimmten Benutzern
gesucht und angezeigt werden. Zudem besteht die Möglichkeit weitere Benutzer anzulegen
(„Add“), bestehende Benutzer zu modifizieren („Edit“) oder sie zu löschen („Delete“).
Abbildung 104: Administration Tool - Search Users
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 83
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Mit „Add“ kann ein Benutzer hinzugefügt werden. Alle Felder (Username, Password,
Lastname usw.) im neu öffnenden Fenster „Add User“ müssen ausgefüllt werden, ansonsten
wird der neue Benutzer nicht angelegt. Dem Anwender muss eine der zwei Rollen
zugewiesen werden (selektiere die entsprechende Rolle).
Abbildung 105: Administration Tool - Add User
Ein Benutzer mit der Rolle „User“ ist berechtigt, die Synchronisation mit dem Server
abzuwickeln. Ein Benutzer mit der Rolle „Administration“ besitzt die Rechte, sich mit dem
Funambol Administration Tool am Server zu verbinden und ihn zu verwalten.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 84
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 106: Add User mit selektierter Rolle
7.6.2
Geräteverwaltung
Mit einem Doppelklick auf das Menü „Devices“ im Navigationsbereich wird das Suchfenster
der Geräte geöffnet. Auch hier kann mit den Filtereinstellungen nach Geräten gesucht
werden. Bestehende Geräte können geändert („Edit“) oder gelöscht („Delete“) werden. Neue
Geräte können hinzugefügt werden („Add“). Wir raten ab, es manuell zu tun, denn bei der
ersten Synchronisierung wird das Gerät automatisch erfasst. Die Eigenschaften der Datei
„syncml.properties“ des SyncML Clients dienen als Info zur Erstellung des Eintrags. Mit
„Capabilities“ wird nur die Fähigkeit des Geräts angezeigt.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 85
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 107: Administration Tool - Search Devices
7.6.3
Principal Verwaltung
Funambol verwendet beim Synchronisieren das “Principal“-Verfahren. Mit diesem Verfahren
werden die zu synchronisierenden Daten nicht am falschen Gerät übergeben. Principal ist
eine Kombination aus dem Funambol-Benutzer und dem mobilen Gerät. Jede Kombination
ist eindeutig im System hinterlegt. Dieses Verfahren erlaubt, dass ein Benutzer mehrere
Geräte verwenden kann oder dass ein Gerät von mehreren Benutzern verwendet wird.
Mit einem Doppelklick auf dem Menü „Principal“ im Navigationsbereich wird das Suchfenster
geöffnet, wie unteres Abbild zeigt.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 86
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 108: Administration Tool - Search Principals
Mit Hilfe der Filtereinstellung können nach bestimmten Benutzer/Gerät-Kombinationen
gesucht und angezeigt werden. Ohne Einstellung und Sucheingabe können alle Daten
angezeigt werden. Funambol erstellt automatisch bei der ersten Synchronisierung den
Principal. Die manuelle Erstellung des Principals soll nur bei Ausnahmen durchgeführt
werden.
Add
Wie nachfolgendes Bild zeigt, kann mit „Add“ manuell ein Principal hinzugefügt werden.
Abbildung 109: Administration Tool - Add Principals
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 87
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Auch hier kann mit der Filtereinstellung gearbeitet werden. Links werden die Benutzer und
rechts werden die mobilen Geräte angezeigt, die bereits im System erfasst sind. Um einen
neuen Principal zu erzeugen, selektiert man den Benutzer und das Gerät und klickt zum
Schluss auf die Schaltfläche „Add Principal“.
Abbildung 110: Selektierter Benutzer und Gerät
Der soeben erstellte Principal erhält eine eindeutige ID-Nummer.
Abbildung 111: Neuer Principal hinzugefügt
Delete
Mit „Delete“ können Principals gelöscht werden. Das Löschen eines „Principal“-Eintrags
zwingt den Funambol Server bei der nächsten Synchronisation zu einer sogenannten „Slow“Synchronisation (auch als „Full“ Synchronisation bezeichnet). Alle Daten des Servers und
des Clients nehmen an der Synchronisation teil. Dieser Prozess wird auch automatisch
ausgeführt, sobald ein Gerät die allererste Synchronisation zum Server startet.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 88
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Details
Mit „Details“ werden die Informationen der letzten Synchronisation angezeigt.
Abbildung 112: Administration Tool - Last Synchronization Timestamps
Jede Spalte wird hier in der unteren Tabelle kurz erklärt:
Spaltenname
Beschreibung
Database
Gibt den vom Principal verwendeten SyncSource an.
In unserem Fall heisst er acme1.
Sync Type
Zeigt die Art der Synchronisation an:
- TWO_WAY
- SLOW
- ONE_WAY_FROM_CLIENT
- REFRESH_FROM_CLIENT
- ONE_WAY_FROM_SERVER
- REFRESH_FROM_SERVER
Status
Zeigt den Synchronisationsstatus-Code an:
- 200 -> TWO_WAY
- 201 -> SLOW
- 202 -> ONE_WAY_FROM_CLIENT
- 203 -> REFRESH_FROM_CLIENT
- 204 -> ONE_WAY_FROM_SERVER
- 205 -> REFRESH_FROM_SERVER
Client anchor
Zeigt den zuletzt verwendeten Client anchor
(Verankerung) an.
Server anchor
Zeigt den zuletzt verwendeten Server anchor
(Verankerung) an.
Start
Zeigt die Startzeit der letzten Synchronisation an.
End
Zeigt die Endzeit der letzten Synchronisation an.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 89
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Refresh
Mit „Refresh“ kann die Information aktualisiert werden.
Reset
Mit „Reset“ wird die Synchronisationsinformation gelöscht und zwingt den Client bei der
nächsten Synchronisation alle Elemente zu aktualisieren (Full-Synchronisation).
7.6.4
Modulverwaltung
Die Baumstruktur der Module im Navigationsbereich wird beim Installieren des Moduls
erstellt. Dabei dient die Information aus der Datei „init_schema.sql“.
Rechter Mausklick auf dem Sync Source Typ um einen neuen Modulverwaltungs-Fenster zu
erzeugen.
Abbildung 113: Administration Tool - Add SyncSource
Und fülle die entsprechende Werte aus und klicke auf „Add“:
Abbildung 114: Administration Tool - Edit My SyncSource
Mit einem Doppelklick auf dem Connector im Navigationsbereich wird das Eigenschaftsfenster des Connectors geöffnet.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 90
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 115: Selektiere SyncSource
Abbildung 116: Speichern der Anpassung
Die Eigenschaften des Moduls werden in der XML-basierte Datei „Funambol\config\<modulName>\<Connector-Name>\<SyncSourceType>\<sourceURL>.xml auf dem Funambol
Server festgehalten. In unserem Fall befindet sich die Datei „acme1.xml“ im Verzeichnis
„C:\Funambol\config\acme\acmeconnector\mymergeablesyncsource“.
Wir haben unsere Konfigurationen direkt in der Datei „acme1.xml“ durchgeführt und haben
somit das Administration Tool fast nicht verwendet. Wir haben auch zusätzliche Variablen
händisch hinzugefügt. Eine Kopie der Datei befindet sich im Verzeichnis „Funambol\ConfigFiles“ auf der beigelegten DVD.
7.7 Der Synchronisationsprozess
Der Synchronisationsprozess besteht aus drei Phasen, die von Funambol der Reihe nach
verarbeitet und koordiniert ausgeführt werden.
Hier die drei Phasen:
1. Vorbereitung (Preparation)
2. Synchronisation (Synchronization)
3. Beendigung (Finalization)
Es gibt verschiedene Synchronisationsarten. Die für uns wichtigen Arten sind die „Slow“
Synchronisation (auch als „Full“ Synchronisation bekannt) und die „Fast“ Synchronisation.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 91
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Die „Fast“ Synchronisation berücksichtigt nur die Elemente, die seit der letzten
Synchronisation modifiziert respektive erstellt wurden. Hingegen nehmen bei der „Full“
Synchronisation (unabhängig von vorherigen Synchronisationen) alle Elemente an dem
Datenausgleich teil. Beide Synchronisationen können folgendes Verhalten aufweisen:
•
Client zum Server:
- Der Server aktualisiert seine Daten mit der des Clients. Er sendet aber seine
Änderungen nicht an den Client.
•
Server zum Client:
- Der Server sendet seine Änderungen an den
Datenänderungen des Clients hingegen nicht.
•
Client
und
bekommt
die
TWO_WAY:
- Beide (Server und Client) tauschen ihre Änderungen aus.
Hier die Synchronisierungsarten, die vom SyncML Protokoll verwendet werden:
Synchronisierungsarten
Beschreibung
TWO_WAY sync (fast)
Client und Server tauschen die Information der
modifizierten Daten aus, die seit der letzten
Synchronisation entstanden ist. Zuerst sendet der
Client seine Änderung.
SLOW sync
SLOW sync ist ebenfalls eine TWO_WAY sync, bei
denen alle Daten beteiligt sind. Die Daten werden im
sogenannten Field-by-Field-Verfahren analysiert.
Das heisst, der Client sendet alle seine Daten an
den Server. Dieser vergleicht sie Feld für Feld mit
seiner Daten.
ONE_WAY sync nur vom Client
Der Client sendet seine Änderung an den Server,
aber der Server sendet seine Änderung nicht zurück.
REFRESH sync nur vom Client
Der Client sendet alle seine Daten an den Server.
Der Server aktualisiert seine Daten mit denjenigen
des Clients.
ONE_WAY sync nur vom Server
Der Client erhält die Änderung vom Server. Der
Client sendet aber seine geänderten Daten nicht an
den Server zurück.
REFRESH sync nur vom Server
Der Server sendet alle seine Daten an den Client.
Der Client aktualisiert seine Daten mit denjenigen
des Servers.
Server Alerted sync
Der Server benachrichtigt den Client, um eine
spezifizierte Synchronisation mit ihm zu starten.
Wie schon oben erwähnt, sind die TWO_WAY Synchronisationen die wichtigsten Arten. Die
übrigen sind von ihnen abgeleitet.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 92
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
7.7.1
Phase Vorbereitung (Preparation)
Die Vorbereitungsphase analysiert die Differenz zwischen zwei oder mehrere Datenquellen
(auch als SyncSources bezeichnet), um eine Liste der Synchronisationsoperationen zu
erhalten. Diese Funktionen kommen während der Synchronisation gezielt zum Einsatz.
Abbildung 117: Phase Vorbereitung (Preparation)
Quelle Funambol Developer's Guide funambol-developers-guide.pdf
7.7.2
Phase Synchronisation (Synchronization)
In der Synchronisationsphase werden die Operationen ausgeführt, die während der Vorbereitungsphase ermittelt wurden. Das Ausführen der Funktion bestätigt die erforderliche
Änderung in der beteiligten Datenquelle. Diese Aktion wird von der Synchronisationsmaschine (sync engine) abgewickelt.
7.7.3
Phase Beendigung (Finalization)
Diese Phase ist der letzte Schritt, der den Synchronisierungsprozess durchläuft. Während
dieser Phase sind Säuberungsaktionen vorgesehen. Weiter sendet der Client die LUID-GUID
mapping der soeben durchgeführten Synchronisation.
ID Verwaltung
Die Daten sind in einer zentralen Datenbank abgelegt und stehen allen Beteiligten zur
Verfügung. Jedes Element ist vom System mit einer ID eindeutig identifizierbar. Client und
Server generieren ihre eigenen IDs. Client-seitig werden die IDs als Local Unique IDentifiers
(LUID) und auf dem Server als Global Unique IDentifiers (GUID) bezeichnet. Ein Abbild von
beiden Systemen wird aufrechterhaltet. Das Abbild zwischen den Local Unique IDentifiers
und den Global Unique IDentifiers (GUID) wird als LUID-GUID mapping bezeichnet.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 93
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
7.8 Entwicklungsumgebung Connector
Da Funambol kein geeigneter Connector für unsere Bedürfnisse besitzt, müssen wir ihn
selber entwickeln. Dazu stellt Funambol die Dokumente (Funambol Developer's Guide und
Funambol DS Server SyncSource API) zur Verfügung.
7.8.1
Anforderung der Entwicklungsumgebung
Bevor wir unser Connector erstellen, müssen die folgenden Applikationen aufgesetzt und
lauffähig sein.
•
Funambol DS Server 7.x
•
Funambol Software Development Kit 7.0.x
•
Java 2 SDK Version 1.5.x oder neuer
•
Apache Maven
7.8.2
Erstellung des Connector-Projektes „acmeconnector“
Funambol schlägt vor, das Connector-Projekt mit Hilfe von Maven zu erstellen. Wir sind
diesem Vorschlag gefolgt und haben Apache Maven und Java 2 SDK auf unserem
Arbeitsrechner installiert. Anschliessend haben wir das Connector-Projekt eingerichtet,
indem wir in der Kommando-Konsole folgenden Befehl eingegeben haben:
mvn archetype:create
-DarchetypeGroupId=funambol
-DarchetypeArtifactId=funambol-module-archetype
-DarchetypeVersion=7.0.0
-DgroupId=acme
-DartifactId=acmeconnector
-DarchetypeRepository=http://m2.funambol.org/repositories/artefacts
-Dversion=1.0.0
Achtung: Der obige Befehl muss in einer Zeile eingegeben werden und die Argumente sind
mit einem Leerschlag zu trennen.
Maven erzeugt das Projekt im Verzeichnis namens „acmeconnector“ und im aktuellen
Verzeichnis. Das Projekt besteht aus:
•
eine normale SyncSource
•
eine "mergeable" SyncSource
•
einem input/output synclet
•
alle Konfigurations- und SQL-Dateien
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 94
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 118: Projektstruktur acmeconnector
Im Ursprungsprojekt existiert das Verzeichnis „acmeconnector/src/main/sql/mysql“ nicht. Da
wir beschlossen haben, MySQL als Back-End-Datenbank zu verwenden, kann zum Beispiel
das Verzeichnis „hypersonic“ kopiert und als „mysql“ umbenannt werden.
Die untenstehende Tabelle erklärt die Funktion jeder Projektdatei:
File
Beschreibung
LICENSE.txt
AGPL Lizenzdatei
pom.xml
Maven-Projekt Datei für den Connector
acmeconnector/src/main/config/co
m/funambol/server/engine/pipeline/i
nput/000.000.mysynclet.xml
Einfache Input Synclet-Konfiguration
acmeconnector/src/main/config/co
m/funambol/server/engine/pipeline/
output/000.000.mysynclet.xml
Einfache Output Synclet-Konfiguration
acmeconnector/src/main/external/r
eadme.txt
Readme für den Verzeichnisinhalt
acmeconnector/src/main/install/inst
all.xml
Modulinstallationsfile
acmeconnector/src/main/java/acme
/MyMergeableSyncSource.java
Einfache "mergeable" SyncSource
/MySynclet.java
Einfache synclet
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 95
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
/MySyncSource.java
Einfache SyncSource
/MySyncSourceAdminPanel.java
Einfache Administrationspanel für MySyncSource
und MyMergeableSyncSource
acmeconnector/src/main/sql/*/sche
ma.sql
SQL Skript zur Erstellung der Datenbanktabellen.
acmeconnector/src/main/sql/*/drop
_schema.sql
SQL Skript zur Löschung der Datenbanktabellen.
acmeconnector/src/main/sql/*/init_s
chema.sql
SQL Skript zur Initialisierung der Datenbanktabellen.
Ist für das Modul erforderlich.
Alle Projektdateien befinden sich auf der beigelegten DVD im Verzeichnis
„Funambol\Code\Connector\acmeconnector“.
7.8.3
Die wichtigsten Projektdateien im Detail
MySyncSource.java
Der MySyncSource Typ ist die wichtigste Komponente des Connectors. Der Quellcode, der
durch das Artefakt erstellt wird, ist sehr schlicht aufgebaut. Der Inhalt besteht aus den
wichtigsten Methoden, die von den Funambol-Funktionen verwendet werden. Weiter besitzt
jede Methode bereits wenige Logging-Informationen, damit ihre Ausführung einfacher
verfolgt werden kann.
Der Kern der SyncSource-Architektur ist das Interface
com.funambol.framework.engine.source.SyncSource.
Dieses Interface kann für beliebige Datentypen (File, E-Mail, Kontakte, Termine und andere
Datensätze) eingesetzt werden. Folglich sind seine Implementierungen für den Zugriff auf die
darunterliegende Datenspeicherung völlig offen.
Eine SyncSource wird aus dem eindeutigen Namen und dem eindeutigen sourceURI
identifiziert. Der sourceURI ist der URI (Uniform Resource Identifier), der ein SyncML Client
angeben muss, um die Synchronisation mit der SyncSource durchführen zu können. Ferner
ist die SyncSource mit einem MIME Typ verknüpft, der den Datentyp behandelt.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 96
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 119: Klasse SyncSource << interface >>
Quelle Funambol DS Server SyncSource API
Das
SyncSource
Interface
erbt
von
zwei
weiteren
Interfaces
namens
„MergeableSyncSource“ und „FilterableSyncSource“ und wird aus der abstrakten Klasse
„AbstractSyncSource“ implementiert.
Hier tabellarisch die wichtigsten Methoden aufgelistet:
Methode
Beschreibung
beginSync()
Diese ist die erste SyncSource Methode, die die
Sync Engine aufruft. Sie spezifiziert, wer
synchronisiert und welche Synchronisierungsart
angewendet wird.
endSync()
Diese ist die letzte SyncSource Methode, die die
Sync Engine aufruft und wird verwendet, um
Abschlussarbeiten zu verrichten.
commitSync()
Wird von der Engine aufgerufen, um die Änderung,
die während der Synchronisierungssitzung
durchgeführt wurde, zu bestätigen.
getUpdatedSyncItems()
Wird von der Engine aufgerufen, um die
aktualisierten SyncItems von einem Gerät und seit
einem bestimmten Zeitpunkt zu ermitteln.
getUpdatedSyncItemKeys()
Wird von der Engine aufgerufen, um den
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 97
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
SyncItemKey (Schlüssel) des aktualisierten
Datensatzes (Item) von einem Gerät und seit einem
bestimmten Zeitpunkt zu ermitteln.
getNewSyncItems()
Wird von der Engine aufgerufen, um die neuen
SyncItems von einem Gerät und seit einem
getNewSyncItemKeys()
SyncItemKey (Schlüssel) des neuen Datensatzes
(Item) von einem Gerät und seit einem bestimmten
Zeitpunkt zu ermitteln.
getDeletedSyncItems()
Wird von der Engine aufgerufen, um die gelöschten
getDeletedSyncItemKeys()
SyncItemKey (Schlüssel) des gelöschten
Datensatzes (Item) von einem Gerät und seit einem
getAllSyncItems()
Wird von der Engine aufgerufen, um alle SyncItems
von einem Gerät und seit einem bestimmten
addSyncItem()
Wird von der Engine aufgerufen, um neue
Datensätze einzufügen.
setSyncItem()
angegebenen Datensatz einzufügen oder zu
aktualisieren.
setSyncItems()
Wird von der Engine aufgerufen, um angegebene
Datensätze einzufügen oder zu aktualisieren.
removeSyncItem()
angegebenen Datensatz zu löschen.
removeSyncItems()
angegebenen Datensätze zu löschen.
getSyncItemFromTwin()
Wird von der Engine aufgerufen, um die Datensätze
zu ermitteln, die die gleichen Informationen wie der
angegebene Datensatz haben. Sie wird bei einer
Konfliktermittlung verwendet, die während einer
"SLOW" Synchronisation stattfindet.
Die SyncSource kann Attribute wie zum Beispiel der Name des Connectors, der sourceURI ,
der MIME-Typ, der JDBC-Driver, die JDBC-URL und die Datenbank-Login-Informationen aus
der XML-Konfigurationsdatei lesen. Somit müssen solche Attribute nicht fest im Code
integriert sein. Stattdessen benötigt der Quellcode die entsprechenden Getter/Setter
Methoden. Die Datei muss im config-Verzeichnis des Funambol DS Servers abgelegt sein.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 98
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Wir mussten den Quellcode gemäss unseren Anforderungen erweitern, damit die
Synchronisierungsprozedur die Daten korrekt in der Back-End-Datenbank ablegt.
SyncItem
Die Elemente (Items), die von der SyncSource zurückgegeben werden, sind Objekten, die
aus der Funambol-Klasse com.funambol.framework.engine.source.SyncItem stammen. Ein
SyncItem ist die unteilbare Einheit, die während einer Synchronisierung ausgetauscht wird.
Er wird durch einen eindeutigen Schlüssel (SyncItemKey) identifiziert und mit einem Status
(state) verknüpft. Ein SyncItem hat die folgenden Eigenschaften:
•
state
•
content
•
type
•
format
•
timestamp
Funambol bietet dazu eine Standard-Implementierung des SyncItem Interfaces an, das sich
in der Klasse com.funambol.framework.engine.SyncItemImpl befindet.
Abbildung 120: Klasse SyncItem << interface >>
Quelle Funambol DS Server SyncSource API
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 99
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
In der untenstehenden Tabelle sind die Methoden des Interfaces aufgelistet:
Methode
Beschreibung
getKey()
Gibt den Schlüssel des Items zurück
getParentKey()
Gibt den Schlüssel des „Vater“-Objektes ->
Hierarchie-Aufbau (Parent/Child)
getState()
Gibt den Status des Items an.
setState()
Setzt den Status des Items.
getContent()
Gibt den Inhalt des Items an.
setContent()
Setzt den Inhalt des Items.
getFormat()
Gibt das Format des Items an.
setFormat()
Setzt das Format des Items.
getType()
Gibt den Typ des Items an.
setType()
Setzt den Typ des Items.
getTimestamp()
Gibt den Zeitstempel des Items an.
setTimestamp()
Setzt den Zeitstempel des Items.
GetSyncSource()
Gibt die SyncSource an, an welche der Item gehört.
Die
Eigenschaften
„Key“
und
„ParentKey“
sind
Objekte
der
Klasse
com.funambol.framework.engine.SyncItemKey und identifizieren das Element (Item) oder
das „Vater“-Element (ParentItem). Das ParentItem wird bei einer hierarchischen
Synchronisation verwendet, um die Parent/Child Struktur zu aktualisieren.
Die Eigenschaft „State“ bestimmt den Status des Elementes und kann folgende Werte
besitzen:
Statuswert
Beschreibung
SyncItemState.NEW
Das Objekt wurde neu erstellt.
SyncItemState.UPDATED
Das Objekt wurde aktualisiert.
SyncItemState.DELETED
Das Objekt wurde gelöscht.
SyncItemState.SYNCHRONIZED
Das Objekt wurde bereits synchronisiert.
SyncItemState.UNKNOWN
Das Objekt befindet sich in einem unbekannten
Status.
SyncItemState.NOT_EXISTING
Das Objekt existiert zurzeit nicht.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 100
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
SyncItemState.CONFLICT
Das Objekt befindet sich in einem Konfliktstatus.
SyncItemState.PARTIAL
Das Objekt besitzt nur ein Teil des Inhalts.
SyncSource verwendet nur den Status NEW, UPDATED und DELETED. Die übrigen Statusbezeichnungen werden vom Synchronisierungsmechanismus (Sync Engine) verwendet.
Die Eigenschaft „Timestamp“ ist der Zeitstempel der letzten Änderung.
Die Eigenschaft „Content“ ist der Inhalt des Items, der in einem Objekt verkapselt
zurückgegeben wird.
Die Eigenschaft „Type“ entspricht dem MIME-Typ (Multipurpose Internet Mail Extensions)
des Inhalts.
SyncContext
Eine neue Synchronisation ruft als erstes die Methode beginSync auf und verwendet
SyncContext als Input-Parameter. Der SyncContext beinhaltet folgende Information:
•
principal (of type com.funambol.framework.security.Principal)
•
syncMode (of type int)
•
filter (of type com.funambol.framework.filter.Filter)
•
conflictResolution
•
sourceQuery
Principal: Ist eine Zusammensetzung aus dem Geräte- und Benutzernamen, aus der die
Synchronisierung ausgelöst wird. Der Grund für diese Zusammenstellung ist, ein Benutzer
kann diverse Geräte verwenden oder dasselbe Gerät kann von verschiedenen Benutzern
bedient werden.
SyncMode: Der Modus gibt an wie die Synchronisierung ausgeführt werden soll. Dabei
stehen die folgenden Synchronisierungstypen zur Verfügung:
syncMode
Synchronisierungstyp
200
TWO_WAY
201
SLOW
202
ONE_WAY_FROM_CLIENT
203
REFRESH_FROM_CLIENT
204
ONE_WAY_FROM_SERVER
205
REFRESH_FROM_SERVER
Filter: Der Filter entspricht die Filtereinstellung des Clients. Er verhält sich wie folgt, falls
beide Bedingungen zutreffen. Beim Client ist der Filter gesetzt und die SyncSource ist vom
Typ FilterableSyncSource:
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 101
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
•
Die Methoden getAllSyncItemKeys, getDeletedSyncItemKeys, getNewSyncItemKeys und
getUpdatedSyncItemKeys geben nur die Elemente zurück, die dem Filterkriterium
entsprechen.
•
Die Methoden getSyncItemsFromId und getSyncItemsFromTwin berücksichtigen den
Filter nicht.
ConflictResolution: Das Konfliktverhalten bei der Synchronisation kann Server-seitig definiert
werden. Dabei gilt:
•
SyncContext.CONFLICT_RESOLUTION_SERVER_WINS – Konfliktauflösung mit
Serverdaten.
•
SyncContext.CONFLICT_RESOLUTION_CLIENT_WINS – Konfliktauflösung mit ClientDaten.
•
SyncContext.CONFLICT_RESOLUTION_MERGE_DATA – Konfliktauflösung, indem die
Daten aus dem Server und dem Client vereinigt werden. Dabei muss die SyncSource
vom Typ MergeableSyncSource sein.
MyMergeableSyncSource.java
Funambol stellt zwei Sub-Typen von SyncSource
MergeableSyncSource und FilterableSyncSource.
Interfaces
Das
MergeableSyncSource
Interface
ist
ein
Bestandteil
com.funambol.framework.engine.source.MergeableSyncSource.
zur
des
Verfügung:
Pakets
Das Interface soll verwendet werden, um Konfliktdaten miteinander zu vereinigen. Die
Vereinigung wird ausgeführt, sobald ein Konflikt ermittelt wird. Das Resultat wird auf dem
Server abgelegt und dann zum Client zurückgesendet.
Methode
Beschreibung
mergeSyncItem()
Wird aufgerufen, wenn ein Konflikt entsteht. Die
Konfliktdaten werden vereinigt. Auf dem Server wird
die Änderung in der Back-End-Datenbank
gespeichert. Falls die Daten auf dem Client
aktualisiert werden müssen, gibt die Methode „true“
zurück und schreibt den neuen Inhalt in dem ClientElement (Item).
MySynclet.java
MySynclet implementiert eine Eingangs- und eine Ausgangs-Synclet. Die Synclet wird
sowohl bei eingehenden als auch ausgehenden Nachrichten aufgerufen. Sie ist sehr einfach
aufgebaut und sie protokolliert die Nachrichten in den funambol.myconnector Logger.
Diese Synclet können dann in jeder beliebigen Position der Pipeline eingebaut werden, um
zu ermitteln, wie sich während der Pipeline-Prozesse eine Nachricht verändert hat.
MySyncSourceAdminPanel.java
Funambol bietet die Möglichkeit unsere MySyncSource via dem Funambol Administration
Tool zu konfigurieren. Dies ist dank der Klasse MySyncSourceAdminPanel möglich.
MySyncSourceAdminPanel erbt von SourceManagementPanel, die eine Klasse von
Funambol Admin Framework ist. SourceManagementPanel ist ein JPanel und besitzt daher
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 102
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
alle Swing Panel Methoden. Zusätzlich besitzt es einen JButton, um neue SyncSources
hinzuzufügen oder um die geänderten Werten einer existierenden SyncSource zu speichern.
Abbildung 121: Panel Funambol Administration Tool
Die Attribute und ihre Werte werden in die Konfigurationsdatei auf dem Funambol DS Server
gespeichert. In unserem Fall heisst die Konfigurationsdatei mit Pfadangabe:
Funambol\config\acme\acmeconnector\mymergeablesyncsource\acme1.xml
Das File enthält die Attribute wie Name des Connectors, der sourceURI (entspricht den
Uniform Resource Identifier), der MIME-Typ. Weitere Attribute wie zum Beispiel der JDBCDriver, die JDBC-URL, Login-Informationen (User/Passwort), Datenbanktabelleninformationen (Tabellennamen, Spaltennamen, Primary Key, ...) können ebenfalls in der
Konfigurationsdatei gespeichert werden. Spricht ein SyncML Client einen Connector an, so
liest die SyncSource die Attribute mit ihren Werten aus diesem Konfigurationsfile heraus.
Daher müssen in unsere Klasse MySyncSource die entsprechenden Getter/Setter Methoden
geschrieben werden.
Nicht alle obigen Attribute werden mit dem Standard-AdminPanel angezeigt. Durch eine
Erweiterung der Klasse MySyncSourceAdminPanel können auch diese Attribute sichtbar und
editierbar gemacht.
Diese Datei namens „acme1.xml“ kann auch manuell und nicht unbedingt via Funambol
Administration Tool bearbeitet werden (siehe beigelegte DVD im Verzeichnis
„Funambol\Config-Files“).
SQL Skripte
Da wir beschlossen haben, MySQL als Back-End-Datenbank zu verwenden, haben wir das
Verzeichnis „hypersonic“ kopiert und als „mysql“ umbenannt. Im Verzeichnis befinden sich
folgende Dateien:
•
acmeconnector/src/main/sql/mysql/schema.sql
•
acmeconnector/src/main/sql/mysql/drop_schema.sql
•
acmeconnector/src/main/sql/mysql/init_schema.sql
Wir benötigen die Skripte schema.sql und drop_schema.sql momentan nicht, da unser
Datenbankschema manuell gepflegt wird. Folglich sind diese Dateien noch leer.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 103
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Das dritte File „init_schema.sql“ wird verwendet, um den Connector in der Back-EndDatenbank zu registrieren. Dabei werden folgende Datenbanktabellen ausgefüllt:
•
fnbl_module -> für die Modulinformation
•
fnbl_connector -> für die Connector Information
•
fnbl_sync_source_type -> für die SyncSource-Typ Information
•
fnbl_connector_source_type -> Für den Connector-SyncSource Typ Zuweisung
•
fnbl_module_connector -> Für Modul-Connector Zuweisung
Die zwei letztere Tabellen dienen für die Erstellung der hierarchischen Struktur des
Connector-SyncSource Typs im Funambol Administration Tool.
Abbildung 122: hierarchische Modulstruktur des Connectors
Mit den folgenden SQL-Befehlen erhält man die Hierarchie:
1.) Modul-Registrierung
delete from fnbl_module where id='acme';
insert into fnbl_module (id, name, description) values ('acme','acme','acme Module');
2.) SyncConnector-Registrierung
delete from fnbl_connector where id='acmeconnector';
insert into fnbl_connector (id, name, description) values
('acmeconnector','acmeconnector','acmeconnector Connector');
3.) Der Connector “acmeconnector” gehört dem Modul “acme“ an.
delete from fnbl_module_connector where module='acme' and connector='acmeconnector';
insert into fnbl_module_connector (module, connector) values ('acme','acmeconnector');
4.) SyncSource Typ Registrierung
delete from fnbl_sync_source_type where id='mysyncsource';
insert into fnbl_sync_source_type (id, description, class, admin_class) values
('mysyncsource','MySyncSource','acme.MySyncSource','acme.MySyncSourceAdminPanel');
delete from fnbl_sync_source_type where id='mymergeablesyncsource';
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 104
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
insert into fnbl_sync_source_type(id, description, class, admin_class) values
('mymergeablesyncsource','MyMergeableSyncSource','acme.MyMergeableSyncSource','acme.
MySyncSourceAdminPanel');
5.) Der SyncSource Typ gehört dem Connector “acmeconnector” an.
delete from fnbl_connector_source_type where connector='acmeconnector' and
sourcetype='mysyncsource';
insert into fnbl_connector_source_type (connector, sourcetype) values
('acmeconnector','mysyncsource');
delete from fnbl_connector_source_type where connector='acmeconnector' and
sourcetype='mymergeablesyncsource';
insert into fnbl_connector_source_type (connector, sourcetype) values
('acmeconnector','mymergeablesyncsource');
pom.xml
Maven ist ein Projektmanagement-Werkzeug und basiert auf dem Konzept eines Project
Object Model (POM).
Um einen Build-Prozess eines Projekts auszuführen, nimmt Maven die notwendigen
Angaben aus der XML-Datei pom.xml heraus.
Die unter dem Kapitel 7.8.2 erstellte pom.xml-Datei muss für unsere Bedürfnisse erweitert
werden. Wir benötigen noch das SyncClient-Paket „jse-sdk“ von Funambol und müssen
daher ein weiteres dependency-Element einfügen:
<dependency>
<artifactId>jse-sdk</artifactId>
<groupId>funambol</groupId>
<version>7.0.5</version>
</dependency>
7.8.4
Erstellen des Connector Pakets "acmeconnector"
Man öffnet eine Shell-Konsole und wechselt in das Projektverzeichnis „acmeconnector“.
Als nächstes gibt man den Maven-Befehl ein, um den Build-Prozess zu starten:
•
mvn package
Nachdem die Erstellungsprozedur erfolgreich abgeschlossen ist, existiert im
Projektverzeichnis ein neues Unterverzeichnis namens „target“, das das kompilierte Modul
„acmeconnector-1.0.0.s4j“ enthält.
Funambol Modul
Ein Funambol Modul ist ein zip-Paket mit der folgenden Namenkonvention:
•
<module-name>-<major-version>.<minor-version>.s4j
Erklärungen:
•
<module-name> entspricht dem Namen des Moduls und darf keine Leerzeichen
enthalten.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 105
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
•
<major-version> entspricht der Major Versionsnummer
•
<minor-version> entspricht der Minor Versionsnummer
Bei einer neuen Versionsnummer mit der Minor Nummernbezeichnung sollen die
Änderungen rückwärts kompatibel sein. Hingegen Änderungen in einer Major Version deuten
eventuell auf eine Migration hin.
7.8.5
Installation des Connector Pakets "acmeconnector"
Bedingung: Der Funambol DS Server muss gestartet sein.
1.) Das soeben erstellte Modul „acmeconnector-1.0.0.s4j“ muss im Modul-Verzeichnis
„C:\Funambol\ds-server\modules“ auf dem Funambol DS Server kopiert werden.
2.) Auf dem Funambol DS Server muss die Datei „C:\Funambol\ds-server\install.properties“
editiert und mit dem neuen Modulnamen ergänzt werden. Trage den Namen des Moduls
an der Zeile modules-to-install ein.
#
# Modules definitions
#
modules-to-install=content-provider-7.0.3,email-connector-7.0.6,foundation-7.0.6,phonessupport-7.0.4,webdemo-7.0.6,acmeconnector-1.0.0
Hinweis: Die Module werden dazwischen mit Kommas und ohne Leerzeichen getrennt.
Die Dateierweiterung .s4j darf nicht angegeben werden.
3.) Speichere die Änderung ab und schliesse die Datei „install.properties“.
4.) Öffne die Kommando-Konsole und gebe folgenden Befehl ein:
C:\Funambol\bin\install-modules.cmd
5.) Während der Installation wird man gefragt, ob die Module installiert werden sollen. Gebe
„y“ (für yes) für die Installation des Moduls "acmeconnector" ein. Für die übrigen Module
gebe „n“ (für no) ein.
Automatisierung der Installation
Da bei jedem Test unseres Connectors das Modul neu verpackt (s4j-File) und auf dem
Funambol DS Server neu installiert werden muss, haben wir beschlossen ein kleines Skript
zu schreiben, um die Installationsphase zu beschleunigen.
Unser bat-Skript:
@echo on
set JAVA_HOME=C:\Sun\SDK\jdk
set FUNAMBOL_HOME=C:\Funambol\ds-server
set FUNAMBOL_BIN=C:\Funambol\bin
cd C:\maven-projects\acmeconnector
start /wait mvn package
copy .\target\acmeconnector-1.0.0.s4j %FUNAMBOL_HOME%\modules
start /wait %FUNAMBOL_BIN%\install-modules.cmd
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 106
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Eine Kopie der Datei „compile_acme_module.bat“ befindet sich auf der beigelegten DVD im
Verzeichnis „Funambol\Scripts“.
7.9 Entwicklungsumgebung SyncML Client
Da Funambol kein geeigneter SyncML Client für unsere Bedürfnisse besitzt, müssen wir ihn
auch selber entwickeln. Dazu stehen wiederum dieselben Dokumente (Funambol
Developer's Guide und Funambol DS Server SyncSource API) wie beim Connector zur
Verfügung.
7.9.1
Bevor wir unser SyncML Client erstellen, müssen die folgenden Applikationen aufgesetzt und
lauffähig sein.
•
Funambol DS Server 7.x
•
Apache ANT oder eine bevorzugte integrierte Entwicklungsumgebung (IDE) z. B. Eclipse
7.9.2
Erstellung des SyncML Client-Projektes „VermSyncClient“
Mit Hilfe von Eclipse entwickeln wir den SyncML Client auf dem eigenen Laptop und testen
ihn anschliessend auf einem Testrechner. Damit die Compilierung stets identisch und schnell
durchläuft, erstellen wir das Software-Paket mit ANT.
Abbildung 123: Projektstruktur VermSyncClient
Die untenstehende Tabelle erklärt die Funktion jeder Projektdatei:
File
Beschreibung
VermSyncClient\build.bat
bat-File, um das ANT Buildprozess zu
starten
VermSyncClient\build\build.properties
Apache ANT Konfigurationsdatei, zur
Definition von zusätzlichen Variablen, die
in der Konfigurationsdatei (sogenannte
Build-Datei) verwendet werden.
VermSyncClient\build\build.xml
Apache ANT Konfigurationsdatei
(sogenannte Build-Datei)
VermSyncClient\build\vermsync.bat
bat-File, um den SyncML Client
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 107
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
“VermSyncClient“ zu starten
VermSyncClient\config\application.properties
Konfigurationsdatei des SyncML Clients
VermSyncClient\config\spds\syncml.properties
VermSyncClient\config\spds\sources\vermsync.
properties
VermSyncClient\lib\core-framework-7.0.0.jar
Bibliothek: Funambol Framework
VermSyncClient\lib\hsqldb.jar
Bibliothek: JDBC-Treiber für HSQLDB
VermSyncClient\lib\jse-sdk-7.0.5.jar
Bibliothek: Funambol SyncClient
VermSyncClient\lib\sync4j-clientframework2.3.jar
Bibliothek: Funambol SyncClient
VermSyncClient\lib\mysql-connector-java-5.0.3bin.jar
Bibliothek: JDBC-Treiber für MySQL
VermSyncClient\src\verm\syncclient\VermClient.
java
Main-Klasse
VermSyncClient\src\verm\syncclient\VermClient
SyncSource.java
SyncSource-Klasse
Alle Projektdateien befinden sich auf der
„Funambol\Code\Sync_Client\VermSyncClient“.
7.9.3
beigelegten
DVD
im
Verzeichnis
Die wichtigsten Projektdateien im Detail
VermClient.java
Die VermClient-Klasse enthält die main() Methode und die Verbindung zum Funambol DS
Server für die Synchronisation. Das Konfigurationsstammverzeichnis „config“ wird als
Eigenschaft (Property) gesetzt, damit die notwendigen XML-basierten Konfigurationsdateien
(application.properties, syncml.properties und vermsync.properties) gefunden werden. Mit
Hilfe der Dateien wird die Verbindung zum Funambol DS Server oder zur lokalen Datenbank
konfiguriert.
VermClientSyncSource.java
Der SyncSource Typ ist die wichtigste Komponente des SyncML Clients. Der Kern der
SyncSource-Architektur ist das Interface com.funambol.syncclient.spds.engine.SyncSource.
Wie beim SyncSource-Interface des Connectors kann auch dieses Interface für beliebige
Datentypen (File, E-Mail, Kontakte, Termine und andere Datensätze) eingesetzt werden.
Folglich sind seine Implementierungen für den Zugriff auf die darunterliegende
Datenspeicherung völlig offen.
Die SyncSource des SyncML Clients ist identisch aufgebaut wie die SyncSource des
Connectors, die im Kapitel 7.8.3 ausführlich beschrieben ist. Ebenfalls das Verhalten der
SyncItems und SyncContext ist gleich. Daher wird auf eine wiederholte Beschreibung
verzichtet.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 108
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Hier tabellarisch die wichtigsten Methoden aufgelistet:
Methode
Beschreibung
beginSync()
Diese ist die erste SyncSource Methode, die die
Sync Engine aufruft. Sie spezifiziert, wer
synchronisiert und welche Synchronisierungsart
angewendet wird.
endSync()
Diese ist die letzte SyncSource Methode, die die
Sync Engine aufruft und wird verwendet, um
Abschlussarbeiten zu verrichten.
commitSync()
Wird von der Engine aufgerufen, um die Änderung,
die während der Synchronisierungssitzung
durchgeführt wurde, zu bestätigen.
getUpdatedSyncItems()
aktualisierten SyncItems von einem Gerät und seit
einem bestimmten Zeitpunkt zu ermitteln.
getNewSyncItems()
Wird von der Engine aufgerufen, um die neuen
getDeletedSyncItems()
Wird von der Engine aufgerufen, um die gelöschten
getAllSyncItems()
Wird von der Engine aufgerufen, um alle SyncItems
von einem Gerät und seit einem bestimmten
addSyncItem()
Wird von der Engine aufgerufen, um neue
Datensätze einzufügen.
setSyncItem()
angegebenen Datensatz einzufügen oder zu
aktualisieren.
setSyncItems()
Wird von der Engine aufgerufen, um angegebene
Datensätze einzufügen oder zu aktualisieren.
removeSyncItem()
angegebenen Datensatz zu löschen.
getSyncItemFromTwin()
Wird von der Engine aufgerufen, um die Datensätze
zu ermitteln, die die gleichen Informationen wie der
angegebene Datensatz haben. Sie wird bei einer
Konfliktermittlung verwendet, die während einer
"SLOW" Synchronisation stattfindet.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 109
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Die Attribute wie zum Beispiel der Name und der sourceURI des zu verwendenden
Connectors, der MIME-Typ, der JDBC-Driver, die JDBC-URL und die Datenbank-LoginInformationen werden aus der XML-Konfigurationsdatei „VermSyncClient\config\spds\
sources\vermsync.properties“ gelesen. Und müssen nicht fest im Code integriert sein. Der
Quellcode muss lediglich die entsprechenden Setter/Getter-Methoden besitzen.
application.properties
Die XML-basierte Konfigurationsdatei application.properties befindet sich im Verzeichnis
VermSyncClient\config und enthält die Information zum erstellten Client:
applicationAuthor=LO IUDICE
applicationDisplayName=VermSyncClient
applicationSupportMail=
applicationSupportUrl=
syncml.properties
Die XML-basierte Konfigurationsdatei syncml.properties befindet sich im Verzeichnis
VermSyncClient\config\spds und enthält die erforderliche Information, damit sich der SyncML
Client mit dem Funambol DS Server verbinden kann. Eigentlich ist der SyncManager für die
korrekte Verbindung zuständig. Er liest die Information aus der Konfigurationsdatei heraus
und stellt die Verbindung her. Der Sync Manager wird von der main()-Methode in der Klasse
VermClient erzeugt.
Folgende Variablen müssen für unsere Verbindung angepasst werden, wobei username,
password und device-id pro Installation verschieden sein sollen:
syncml-url=http://mt-funambol:8080/funambol/ds
target-local-uri=http://mt-funambol:8080/funambol/ds
username=test
password=test
device-id=Sync4jVerm
first-time-sync-mode=two-way
vermsync.properties
Die XML-basierte Konfigurationsdatei vermsync.properties befindet sich im Verzeichnis
VermSyncClient\config\spds\sources und enthält die erforderliche Information, um die
Verbindug zur lokalen Datenbank aufzubauen. Hier wird der Name der SyncSource-Klasse
(in unserem Fall die Klasse verm.syncclient.VermClientSyncSource) mitgegeben, damit die
Synchronisationsprozedur, die erforderlichen Methoden aufrufen kann. Der SyncManager
entnimmt die Information aus dieser Datei und baut die Verbindung zur lokalen Datenbank
auf. Nebst den Verbindungsinformationen befinden sich noch die Angaben des JDBCTreibers und -URL, über den Namen und sourceURI des Connectors, über den MIME-Typ
und über den Aufbau der Datenbanktabelle „tabkoord“:
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 110
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
sourceClass=verm.syncclient.VermClientSyncSource
type=text/plain
sourceURI=vermdb
name=vermdb
jndiName=
jdbcDriver=org.hsqldb.jdbcDriver
urlConnection=jdbc:hsqldb:hsql://localhost/localvermdb
userConnection=vermsys
passwordConnection=vermsys
tableName=tabkoord
keyColumnName=pktnr
timestampColumnName=fmbstatus
stateColumnName=fmbtimestamp
moreColumnNames=ykoord,xkoord
encode=true
build.xml
Zum Testen unseres SyncML Client haben wir immer wieder eine neue jar-Datei erstellt und
diese Datei mit den notwendigen Konfigurationsdateien auf dem TestclientC kopiert.
Um Zeit zu sparen, haben wir beschlossen, das Projekt mit ANT zu kompilieren. Wir haben
die Build-Datei und ihre Property-Datei gemäss unseren Anforderungen erstellt und beide
Dateien im Verzeichnis „build“ abgelegt.
Mit Hilfe der build.bat-Datei wird Apache ANT aufgerufen und das Paket erzeugt. ANT legt
ein neues Verzeichnis namens „target“ an. Und alle notwendigen Dateien werden dort hinein
kopiert respektive erstellt.
7.9.4
Installation des SyncML Clients „VermSyncClient”
Das mit ANT erstellte Verzeichnis „target“ kann auf die Testmaschine kopiert werden.
Mit einem Doppelklick auf die Datei vermsync.bat kann es gestartet werden.
Bedingung: Auf dem Testclient muss die Java Runtime (JRE 1.5 oder höher) installiert sein.
7.10 Systemtest II
7.10.1 Ausgangslage
•
•
Client C und D sind online für die Fälle 1-6
•
Client C und D sind offline für die Fälle 7-8
Bedingung: Skript „Stammdaten_Funambol.sql“ (siehe im Verzeichnis „SQL-Skripte“ auf der
beigelegten DVD) in die Hauptdatenbank einspielen. Auf den Clients muss die lokale
Datenbank „localvermdb“ mit der Tabelle „tabkoord“ vorhanden sein. Der Datenbankbenutzer
„vermsys“ mit der entsprechenden Berechtigung muss ebenfalls angelegt sein.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 111
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Anhand folgendes Skriptinhalts „Stammdaten_Funambol.sql“ werden die Stammdaten in der
Hauptdatenbank importiert:
DELETE FROM tabkoord;
COMMIT;
INSERT INTO tabkoord (pktnr, ykoord, xkoord, fmbstatus)
VALUES (1, 660634.772, 244641.123, 'N');
VALUES (2, 660617.409, 244653.457, 'N');
VALUES (3, 660675.128, 244607.968, 'N');
VALUES (4, 660661.096, 244653.276, 'N');
VALUES (5, 660660.782, 244601.123, 'N');
COMMIT;
aus.
Abbildung 124: Startsituation in der MySQL Hauptdatenbank
Der Inhalt der Back-End-Datenbank wird mit dem Webinterface von XAMPP angezeigt.
Startsituation auf den TestclientC & D
Um die Daten in der lokalen Datenbank anzuzeigen, verwenden wir auch das VerwaltungsTool von HSQLDB (C:\hsqldb\demo\runManager.bat).
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 112
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 125: Verwaltungs-Tool HSQL Database Manager (runManager)
Im Moment sind die Datenbanken auf den Clients leer. Also holen wir uns die Daten aus der
Hauptdatenbank mit der manuellen Synchronisation auf unsere Client-Datenbanken:
Starte C:\VermSyncClient\vermsync.bat
Startsituation auf dem TestclientC
Abbildung 126: Startsituation TestclientC (Ausgangslage)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 113
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Startsituation auf dem TestclientD
Abbildung 127: Startsituation TestclientD (Ausgangslage)
7.10.2 Testfälle
Fall 1:
TestclientC:
Abbildung 128: Punkt einfügen TestclientC (Fall 1)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 114
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 129: Neuer Punkt TestclientC (Fall 1)
Manuelle Synchronisation auf dem TestclientC auslösen:
Abbildung 130: Situation in der MySQL Hauptdatenbank (Fall 1)
Situation TestclientD:
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 115
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 131: Neuer Punkt TestclientD (Fall 1)
Fall 2:
TestclientD:
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 116
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Selektiere Punkt 3
Abbildung 132: Punkt 3 modifizieren TestclientD (Fall 2)
Abbildung 133: Situation TestclientD (Fall 2)
Punkt 3 ist lokal gespeichert. Manuelle Synchronisation auf dem TestclientC
auslösen:
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 117
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Bemerkung: Wie erwartet wurde der Status des Punkts 3 auf U (Update) gesetzt.
Situation TestclientC:
Abbildung 135: Situation TestclientC (Fall 2)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 118
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Fall 3:
TestclientC:
Abbildung 136: Situation TestclientC (Fall 3)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 119
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
TestclientD:
Abbildung 137: Situation TestclientD (Fall 3)
Manuelle Synchronisation auf beide Testclients auslösen:
In der Hauptdatenbank sind die Daten des Clients D gespeichert. Siehe Begründung am
Schluss dieser Aufgabe.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 120
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 139: Refresh-Situation TestclientC (Fall 3)
Nach dem Refresh sind die Daten unverändert! Siehe Begründung am Schluss dieser
Aufgabe.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 121
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 140: Unveränderte Situation TestclientD (Fall 3)
Die Daten sind unverändert, da seine Werte in der Hauptdatenbank permanent gespeichert
sind.
Begründung: Wenn zwei Client gleichzeitig synchronisieren, übernimmt Funambol die
Steuerung der Synchronisierung. Ein externer Einfluss ist ausgeschlossen. Somit ist der
Synchronisierungsprozess zufällig und kann beim erneuten gleichzeitigen Synchronisieren
variieren. Diese Aufgabe wurde von uns mehrmals wiederholt. Durch die Wiederholung
stellten wir fest, dass die Synchronisation unter anderem auch Client dominant ist. Das
heisst, der Server akzeptiert stillschweigend die Änderungen des Clients.
Anhand des Log-Files des Servers konnten wir den Synchronisierungsablauf analysieren.
Der zeitliche Ablauf ist grafisch unten abgebildet. Das Bild erklärt zudem das Resultat dieser
Aufgabe.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 122
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
TestclientC
TestclientD
(test/Sync4jTest)
(test1/Sync4jverm1)
MT-Funambol
1
Client C angemeldet
t = 2009-01-12 10:41:10,859
2
Client D angemeldet
t = 2009-01-12 10:41:11,015
Synchronisation mit Client D gestartet
t = 2009-01-12 10:41:11,015
letzte sync: 2009-01-12 10:34:37.25
neue sync: 2009-01-12 10:41:10.843
3
Synchronisation mit Client C gestartet
t = 2009-01-12 10:41:11,062
letzte sync: 2009-01-12 10:37:25.671
neue sync: 2009-01-12 10:41:10.796
4
Synchronisation mit Client D
abgeschlossen
t = 2009-01-12 10:41:11,125
5
Synchronisation mit Client C
abgeschlossen
t = 2009-01-12 10:41:11,187
6
7
Zeit t
Zeit t
Zeit t
Abbildung 141: Zeitlicher Ablauf der Synchronisation (Fall 3)
1.) TestclientC (Principal: test/Sync4jTest) meldet sich am Funambol Server an.
Anmeldezeit um: 2009-01-12 10:41:10,812
2.) TestclientD (Principal: test1/Sync4jverm1) meldet sich am Funambol Server an.
Anmeldezeit um: 2009-01-12 10:41:10,859
3.) TestclientD beginnt mit dem Server zu synchronisieren.
t = 2009-01-12 10:41:11,015
Dabei werden die Elemente synchronisiert, die sich während der Zeitspanne 2009-01-12
10:34:37.25 und 2009-01-12 10:41:10.843 verändert haben. In unserem Fall wird der
Punkt 3 des Clients D in der Hauptdatenbank aktualisiert. Die Aktualisierung setzt auf
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 123
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
dem Punkt 3 in der Hauptdatenbank einen neuen Zeitstempel (fmbtimestamp,
Tabellenfeld von „tabkoord“), der etwas grösser als 2009-01-12 10:41:11,015 ist.
4.) TestclientC beginnt mit dem Server zu synchronisieren.
t = 2009-01-12 10:41:11,062
Dabei werden die Elemente synchronisiert, die sich während der Zeitspanne 2009-01-12
10:37:25.671 und 2009-01-12 10:41:10.796 verändert haben. Der neue Punkt 3 in der
Hauptdatenbank besitzt nun einen Zeitstempel (fmbtimestamp), der höher liegt als die
von der Synchronisierung involvierte Zeitspanne. Folglich wird der Punkt aus der
Synchronisation ausgeschlossen und wird nicht aktualisiert.
5.) Die Synchronisation mit dem Client D wird abgeschlossen.
t = 2009-01-12 10:41:11,125
Zudem wird die Zeit t = 2009-01-12 10:41:11,125 als letzte Synchronisierung mit dem
Client D gesetzt.
Zur Erinnerung: Der Zeitstempel des Punkts 3 (fmbtimestamp) ist unterhalb der
markierten letzten Synchronisation.
fmbtimestamp < t = 2009-01-12 10:41:11,125
6.) Die Synchronisation mit dem Client C wird abgeschlossen.
t = 2009-01-12 10:41:11,187
Zudem wird die Zeit t = 2009-01-12 10:41:11,187 als letzte Synchronisierung mit dem
Client C gesetzt.
7.) Eine erneute Synchronisation wird den Punkt 3 ebenfalls nicht mehr aktualisieren, da der
Zeitstempel des Punkts (fmbtimestamp) unterhalb des Zeitpunkts der zuletzt
ausgeführten Synchronisation ist.
Auszug aus dem Server Log-File „ds-server.log“:
…
[2009-01-12 10:41:10,812] [funambol.handler] [INFO] [A6B79048FCAFF2332B2FB13EF80BB699]
[Sync4jTest] [test] [] test/Sync4jTest logged in.
....
[2009-01-12 10:41:10,859] [funambol.handler] [INFO] [7C76E127DCC32A4284DB9DFE26730059]
[Sync4jverm1] [test1] [] test1/Sync4jverm1 logged in.
[2009-01-12 10:41:11,015] [funambol.engine] [INFO] [7C76E127DCC32A4284DB9DFE26730059]
[Sync4jverm1] [test1] [] Starting synchronization
...
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 124
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
[2009-01-12 10:41:11,015] [funambol.ourConnector] [INFO]
[7C76E127DCC32A4284DB9DFE26730059] [Sync4jverm1] [test1] [acme1] since: 2009-01-12
10:34:37.25
[7C76E127DCC32A4284DB9DFE26730059] [Sync4jverm1] [test1] [acme1] to: 2009-01-12
10:41:10.843
....
[2009-01-12 10:41:11,062] [funambol.engine] [INFO] [A6B79048FCAFF2332B2FB13EF80BB699]
[Sync4jTest] [test] [] Starting synchronization
...
[A6B79048FCAFF2332B2FB13EF80BB699] [Sync4jTest] [test] [acme1] since: 2009-01-12
10:37:25.671
[A6B79048FCAFF2332B2FB13EF80BB699] [Sync4jTest] [test] [acme1] to: 2009-01-12 10:41:10.796
....
[2009-01-12 10:41:11,125] [funambol.engine] [INFO] [7C76E127DCC32A4284DB9DFE26730059]
[Sync4jverm1] [test1] [] Sync4jverm1/test1: synchronization completed
[2009-01-12 10:41:11,187] [funambol.engine] [INFO] [A6B79048FCAFF2332B2FB13EF80BB699]
[Sync4jTest] [test] [] Sync4jTest/test: synchronization completed
Aufgrund unserer Analyse und Feststellung kommen wir zu folgendem Fazit: Ein
gleichzeitiges Synchronisieren ist zu vermeiden!
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 125
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Fall 4:
TestclientC:
Löscht den Punkt 3
Abbildung 142: Startsituation TestclientC (Fall 4)
Abbildung 143: Endsituation TestclientC (Fall 4)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 126
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
TestclientD:
Selektiere Punkt 3
Abbildung 144: Startsituation TestclientD (Fall 4)
Abbildung 145: Punkt 3 modifizieren TestclientD (Fall 4)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 127
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 146: Endsituation TestclientD Fall 4
Der Punkt 3 ist in der Hauptdatenbank mit den geänderten Werten des TestclientD
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 128
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 148: Unveränderte Situation TestclientC (Fall 4)
Der Punkt 3 ist weiterhin nicht in der lokalen Datenbank vorhanden und verleitet vom
Standpunkt des TestclientC zu einer korrekten Annahme. Im Bezug zur Hauptdatenbank hat
die lokale Datenbank aber einen Datenunterschied.
Achtung: Was passiert bei der nächsten Synchronisation? Starte erneut die Synchronisation.
Abbildung 149: Neue Situation TestclientC (Fall 4)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 129
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Punkt 3 wurde mit den aktuellen Werten aus der Back-End-Datenbank wiederhergestellt.
Nun ist die Datendifferenz wieder aufgehoben.
Die Situation auf dem TestclientD bleibt unverändert.
Fall 5:
Achtung: In der Back-End-Datenbank von Funambol dürfen keine Datensätze gelöscht
werden. Ansonsten werden sie von der nächsten Synchronisation nicht erfasst und können
somit auf den Clients nicht entfernt werden. Fazit: Datenleichen! Ein gelöschter Datensatz
wird mit dem Status „D“ für Delete vermerkt. Zugleich wird in der Spalte „fmbtimestamp“ die
Zeit der Änderung (CURRENT_TIMESTAMP) registriert. Diese Eigenschaft spielt eine
wesentliche Rolle beim Synchronisieren von verschiedenen lokalen Datenbanken zur
Hauptdatenbank.
Folglich muss der Punkt 3 mit dem Status D (Delete) versehen werden!
Abbildung 150: Update-Statement auf Kommandokonsole (Fall 5)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 130
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Situation TestclientC & D:
Abbildung 152: Situationen TestclientC & D (Fall 5)
Auf dem Client wird der Punkt 3 definitiv aus der lokalen Datenbank localvermdb gelöscht.
Da die Information als „gelöscht“ zur Client transferiert wurde, besteht kein Grund diesen
Punkt weiter in der Client-Datenbank zu speichern. Unser Synchronisierungs-Client bereinigt
in der Methode commitSync(), die als gelöscht markierten Datensätze (fmbstatus = D) aus
der lokalen Datenbank. Weiter versehen wir die bereits synchronisierenden Daten mit dem
Status „synchronized“ (fmbstatus = S).
Abbildung 153: Neue Status-Situation auf den Clients (Fall 5)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 131
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Fall 6:
Y = 1234 und X = 4321
Befehl:
Abbildung 154: Update-Statement auf Kommandokonsole (Fall 6)
Resultat in der Hauptdatenbank vermdb:
Abbildung 156: Startsituationen TestclientC & D (Fall 6)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 132
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 157: Endsituationen TestclientC & D (Fall 6)
Situation in der lokalen Datenbank localvermdb:
Der soeben aktualisierte Punkt wird unter anderem auch mit dem Status U versehen.
Abbildung 158: Neue Status-Situation auf den Clients (Fall 6)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 133
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Fall 7:
Unser Synchronisierungs-Client läuft als manuelle Synchronisation. Für eine automatische
Synchronisation wird unser bat-File mit Hilfe des Betriebssystems in den „geplanten Jobs“ (> Start | All programs | Accessories | System Tools | Scheduled Tasks) eingetragen. Um eine
automatische Synchronisation auszulösen, kann periodisch die Synchronisierung gestartet
werden. Weiter kann schon beim Anmelden die Synchronisation auch gestartet werden,
indem man unser bat-File in den sogenannten „Autostart“ verlinkt.
Bedingung: Gegenüber dem Pflichtenheft müssen die Client nicht offline gesetzt werden, da
die Synchronisation zurzeit manuell ausgelöst wird. Wir haben in unsere Testclients keine
Einträge in den „geplanten Jobs“ erstellt. Folglich werden keine Daten transferiert, bevor der
Synchronisationsprozess händisch gestartet wird. Praktisch unterscheidet sich der Ablauf
dieser Aufgabe nicht mit den vorherigen Aufgaben 1 bis 6.
Ausgangslage:
Lösche alle Daten in den lokalen Datenbanken.
Skript „Stammdaten_Funambol.sql“ in die Hauptdatenbank einspielen.
Starte die manuelle Synchronisation auf beide Testclients
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 134
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Situation auf beiden Clients:
Abbildung 160: Situationen TestclientC & D (Fall 7)
TestclientC:
TestclientD:
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 135
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 161: Punkte 6 und 7 einfügen TestclientC (Fall7)
Abbildung 162: Punkte 8 und 9 einfügen TestclientD (Fall 7)
Client D startet die manuelle Synchronisation:
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 136
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 163: Situation in der MySQL Hauptdatenbank nach D (Fall 7)
Client C startet die manuelle Synchronisation:
Abbildung 164: Situation in der MySQL Hauptdatenbank nach C (Fall 7)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 137
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Punkte, die vom
Client D stammen
Abbildung 165: Refresh-Situation TestclientC (Fall 7)
In der lokalen Datenbank „localvermdb“ auf dem Client C sind die Punkte gespeichert.
Abbildung 166: Situation TestclientC mit runManager betrachten (Fall 7)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 138
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 167: Unveränderte Situation TestclientD (Fall 7)
bleibt unverändert!
Client D startet erneut die manuelle Synchronisation, um die zugeführten Punkten
des Clients C zu erhalten:
des Clients C.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 139
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Punkte, die vom Client
C stammen
Abbildung 168: Refresh-Situation TestclientD (Fall 7)
In der lokalen Datenbank „localvermdb“ auf dem Client D sind die Punkte gespeichert.
Abbildung 169: Situation TestclientD mit runManager betrachten (Fall 7)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 140
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Fall 8:
Da die Synchronisierung manuell gestartet wird, verhält sich diese Aufgabe gleich wie die
Aufgabe 6. Somit kann die Aufgabe hier beendet werden.
7.10.3 Quintesenz der Testfälle beim System II
Die Testreihe wurde auch bei diesem System dreimal wiederholt. Diesmal stimmten die
Tests mit unseren Erwartungen überein. Es trat ein Konflikt beim Fall 3 auf. Beim Fall 4 trat
kein Konflikt auf, da der Punkt 3 in der Hauptdatenbank permanent vorhanden ist. Zur
Erinnerung: In der Hauptdatenbank werden keine Datensätze gelöscht, sondern sie werden
mit dem Status „D“ für Delete gekennzeichnet. Funambol stellt für die Konfliktanalyse leider
kein passendes Werkzeug wie Oracle zur Verfügung. Mühsam mussten wir selber den
Datenaustausch anhand des Log-Files aufzeichnen. Unsere detaillierte Analyse ist in den
Fällen ausführlich beschrieben. Wir sind der Meinung, dass diese Arbeit nicht dem Benutzer
alleine überlassen werden kann und dass Funambol hier noch Entwicklungspotenzial hätte.
Zudem ist eine solche Auswertung in einer produktiven Umgebung zu aufwendig.
Genauso wie beim System I ist Folgendes zu sagen, dass in einem kleinen Benutzerumfeld
die Konfliktfälle sehr selten auftreten sollten. Die Wahrscheinlichkeit, dass zwei Clients den
gleichen Datensatz gleichzeitig ändern und synchronisieren, ist klein. Ausserdem muss bei
der Erfassung neuer Datensätze durch diverse Clients sichergestellt werden, dass die
Clients unterschiedliche Punktnummer verwenden. Das entspricht auch die Praxis im
Vermessungswesen. Mit regelmässigem Synchronisieren in kurzen Zeitabständen können
zusätzlich Konflikte vermieden werden. Ein gleichzeitiges Synchronisieren ist zu vermeiden!
Die Clients werden vom System auf keiner Weise über die Konflikte informiert. Ferner bietet
Funambol keine automatische Synchronisation an. Aber mit Hilfe des Betriebssystems
(Scheduled Tasks = geplante Jobs) kann eine automatische Synchronisierung erzielt werden
(siehe unter anderem Fall 7).
Erwartungsgemäss macht die Aufgabe 8 nur bei einer automatischen Synchronisation Sinn,
denn bei einer manuellen Synchronisation entspricht dieser Fall die Aufgabe 6.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 141
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
8 System III
8.1 Einleitung
Ausgehend aus der Diskussionsrunde mit unserem Examinator Herr Wyss haben wir
beschlossen, ein weiteres Synchronisationssystem basierend auf ADO.NET unter die Lupe
zu nehmen.
8.2 Aufbau
Auf dem physischen Rechner wird ein VMware-Rechner mit Windows Server 2003
Betriebssystem aufgesetzt. Auf diesem Server installieren wir nur die Back-End-Datenbank
(MS SQL 2005 Express Edition). Es ist uns bewusst, dass Windows XP auch als
Betriebssystem in unserem System III eingesetzt werden konnte. Um eine Einheit über alle
Systeme zu haben, kommt Windows XP nicht in Frage. Auf den virtuellen Workstation
installieren wir den SQL Server Compact 3.5 SP1. Diese Datenbankserver-Version
beinhaltet schon das Microsoft Sync Framework. Anschliessend wird unser Prototyp GUI
„survey“, den wir neu in C# programmiert haben, auf den Clients kopiert.
8.2.1
Abbildung 170: Systemübersicht III der Test-Umgebung
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 142
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
8.3 ADO.NET
ADO.NET ist praktisch eine Weiterentwicklung des ActiveX Data Objects (ADO) und ist
heute Bestandteil des Microsoft .NET Framework 2.0.
Abbildung 171: Die Struktur des .NET Frameworks
Quelle Software Architecture .NET Framework, Version 1.0, Ronald Tanner
Im Wesentlich besteht es aus einer Ansammlung von Programmklassen, die den Zugriff auf
relationalen Datenbanken ermöglicht. Seine Hauptkomponente sind Dataprovider und
DataSet.
Abbildung 172: ADO.NET Architektur
Quelle http://msdn.microsoft.com/en-us/library/aa719511.aspx
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 143
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
8.3.1
Dataprovider
Der Dataprovider ist das Interface zur Datenbank und kennt die Eigenschaft von ihr. Es gibt
unterschiedliche Dataprovider zu den jeweiligen Datanbanken. Standardmässig sind die
Provider für MS SQL Server und OLE DB im .NET Framework integriert. Es gibt auch noch
weitere Dataprovider wie zum Beispiel für Oracle und für MySQL. Diese müssen aber
zusätzlich installiert werden.
Der Dataprovider besitzt vier Komponenten:
Komponente
Beschreibung
Connection
Baut die Verbindung zur Datenbank auf.
Command
Führt Anweisungen zur Datenbank; SELECT,
INSERT, UPDATE und DELETE
DataAdapter
Dient als Brücke zwischen der Datenbank und dem
DataSet. Das heisst, der Adapter füttert den DataSet
mit den Daten aus der Datenbank.
DataReader
Erlaubt nur einen Lesezugriff auf die Daten.
Navigieren durch die Datensätze ist nicht möglich,
da der Lesevorgang sequenziell abgearbeitet wird.
8.3.2
DataSet
Der DataSet ist ein Speicherabbild der Datenbank. Mit Hilfe des DataAdapters werden die
Datenbankeinträge im DataSet gespeichert und stehen der eigentlichen Applikation für die
weitere Verarbeitung zur Verfügung. Hier die wichtigsten Klassen des DataSets:
Klasse
Beschreibung
DataSet
Entspricht dem Schema.
DataTable
Entspricht einer Tabelle (single table).
DataView
Dient zur Sortierung und Filterung der Daten.
DataColumn
Entspricht der Tabellenspalte mit dem Spaltennamen und -typ.
DataRow
Entspricht der Tabellenzeile und erlaubt das Lesen
und das Ändern der Werte aus der Zeile.
DataRowView
Entspricht einer einzige Zeile aus dem DataView
DataRelation
Ist eine Beziehung zwischen den Tabellen (->
Primary-Key und Foreign-Key).
Constraint
Beschreibt die Eigenschaft von Datenbanken;
Primary-Key, NOT NULL, usw.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 144
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
8.4 Microsoft Sync Framework
Während unserer Einarbeitung im ADO.NET sind wir auf die Synchronisationsplattform von
Microsoft gestossen, das sogenannte Microsoft Sync Framework. Beim Einlesen in dem
MSDN-Forum stellten wir fest, dass dieses Framework eine solide Basis für unser drittes
System bietet. Desweiteren steht das Sync Framework auch kostenlos und franko zur
Verfügung.
Die Plattform unterstützt zwei Szenarien: offline access (offline-Zugriff) und collaboration
(Zusammenarbeit), die in Applikationen oder Diensten integriert werden können. Die
Beschreibung der zwei Szenarien wird in den nachfolgenden Kapiteln näher gebracht.
Die Microsoft Sync Framework stützt sich auf die fünf Technologien ab:
Technologie
Beschreibung
Kernkomponenten von Sync
Framework
Dient zum Erstellen von Synchronisierungsanwendungen, die einen beliebigen
Datenspeichertyp verwendet.
Microsoft Sync Services for
ADO.NET
Dient zur Synchronisierung von Datenbanken.
Metadatenspeicherdienst
Dient zur Speicherung von Synchronisierungsmetadaten in einem Lightweight-Datenspeicher
(LDAP).
Sync Services for File Systems
Dient zur Synchronisierung von Dateien und Ordner
in einem Filesystem.
Sync Services for FeedSync
Dient zur Synchronisierung von RSS- und AtomFeeds mit Daten in einem lokalen Speicher.
Für unsere Arbeit kommt die Technologie „Microsoft Sync Services for ADO.NET“ in Frage.
8.4.1
Übersicht Zusammenarbeitsszenario (collaboration)
Sync Services for ADO.NET synchronisiert die Daten zwischen beliebigen Geräten (Peers),
ohne die Änderungen über einen zentralen Server umzuleiten. Die Daten können direkt von
einem Peer zum anderen Peer (peer-to-peer) aktualisiert werden. Deshalb kann bei dem
Zusammenarbeitsszenario ebenfalls von einer Peer-to-Peer-Synchronisation gesprochen
werden. Während der Synchronisation können jeweils nur ein Paar von Peers gemeinsam
die Daten austauschen. Bei einer Verknüpfung mit vielen Geräten kann die
Gesamtsynchronisation länger dauern als bei einer Client/Server-Synchronisation.
Als Peerdatenbank kann ein beliebiges Datenbanksystem verwendet werden, für den ein
ADO.NET Provider existiert.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 145
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 173: Übersicht Zusammenarbeitsszenario (collaboration)
Quelle http://msdn.microsoft.com/en-us/library/bb902818.aspx
Im Augenblick kommt dieses Szenario für unsere Arbeit nicht zum Zuge.
8.4.2
Übersicht offline-Szenario (offline access)
Das offline-Szenario ist nicht anderes als ein Client/Server-Gebilde. Da die Clients nicht
immer mit dem zentralen Server verbunden sind, müssen sie eine Kopie der Serverdaten auf
dem Client besitzen. Zudem kann die lokale Kopie der Daten mit dem zentralen Server
synchronisiert werden, sobald eine Verbindung mit dem Server aufrecht steht. Die Clients
tauschen ihre Änderungen nicht direkt miteinander aus. Sie synchronisieren stets nur mit
dem Server (das gleiche Vorgehen wie bei den Systemen I und II).
Der Microsoft Sync Services for ADO.NET benötigt Client-seitig ein SQL Server Compact 3.5
SP1 als lokale Datenbank. Server-seitig kann ein beliebiges Datenbanksystem verwendet
werden, für das ein ADO.NET Provider zur Verfügung steht.
Abbildung 174: Übersicht Offlineszenario (offline access)
Das offline-Szenario entspricht unserer Vorstellung, und wir verfolgen diese Lösung für unser
drittes System.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 146
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
8.5 Architektur des offline-Szenarios
Sync Services for ADO.NET synchronisiert die Daten zwischen einer lokalen Datenbank
(SQL Server Compact 3.5 SP1) auf dem Client und der Back-End-Datenbank auf dem
Server, die eine beliebige Datenbank sein kann, die über einen ADO.NET Provider
angesprochen werden kann. Sync Services unterstützt für die Synchronisation entweder eine
2-Ebene- (two-tier) oder eine n-Ebene- (n-tier) Architektur. Wir verwenden für unser
Synchronisierungssystem die 2-Ebene-Architektur.
Abbildung 175: 2-Ebene-Architektur mit Client- und Back-End-Datenbank
Die oben abgebildeten Komponenten sind Sync Services Klassen, die in den folgenden DLLDateien gespeichert sind:
DLL-Datei
Komponenten
Microsoft.Synchronization.Data.dll
- Synchronization Agent
- Synchronization Tables
- Synchronization Groups
Microsoft. Synchronization.Data.SqlServerCe.dll
- Client Synchronization Provider
Microsoft. Synchronization.Data.Server.dll
- Server Synchronization Provider
- Synchronization Adapters
Die aufgelisteten DLL-Dateien benötigen auch die Dateien System.dll und System.Data.dll
aus dem .NET Framework 2.0.
8.5.1
Die Architektur-Komponenten des Sync Services
Die Architekur des Sync Services besteht aus fünf Komponenten. Nachfolgend werden diese
einzeln erklärt.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 147
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Synchronization Agent (Synchronisierungs-Agent)
Der Synchronisierungs-Agent steuert die Synchronisation, indem er wie folgt vorgeht:
•
Zuerst durchläuft er in einer Schlaufe jede Tabelle, die synchronisiert werden soll.
•
Anschliessend ruft er den Client Synchronization Provider auf, um die Änderungen in der
Client-Datenbank zu ermitteln respektive zu speichern.
•
Als letztes ruft er den Server Synchronization Provider auf, um die Änderungen in der
Back-End-Datenbank zu ermitteln respektive zu speichern.
•
Zudem verwaltet der Synchronization Agent sitzungsspezifische Informationen für die
Synchronisation und teilt der Anwendung Informationen wie Fehler-, Erfolgsmeldungen
und Statistiken mit.
Client Synchronization Provider (Clientsynchronisierungsanbieter)
Der Client Synchronization Provider baut die Verbindung zur Client-Datenbank auf. Der Sync
Services besitzt bereits einen Provider für den SQL Server Compact 3.5 SP1. Seine
Aufgaben sind:
•
Auf dem Client speichert er die Informationen der Tabellen, die in der Synchronisation
beteiligt sind.
•
Er ermittelt die Änderungen in der Client-Datenbank, die seit der letzten Synchronisation
entstanden sind.
•
Er erkennt auch Konflikte.
Server Synchronization Provider (Serversynchronisierungsanbieter)
Der Server Synchronization Provider baut die Verbindung zur Server-Datenbank auf. Es
kann eine beliebige Server-Datenbank verwendet werden, für die ein ADO.NET Provider zur
Verfügung steht. Der Server Synchronization Provider führt die gleichen Aufgaben wie der
Client Synchronization Provider aus.
Synchronization Table and Synchronization Group (Synchronisierungstabelle und
Synchronisierungsgruppe)
Eine Synchronisierungstabelle wird für jede Tabelle definiert, die synchronisiert wird. Die
Synchronisierungstabelle dient für die Speicherung der Synchronisationsrichtung (nur
download, nur upload oder bidirektional) und andere Einstellungen. Die definierten
Synchronisierungstabellen können in Synchronisierungsgruppen erfasst werden. Die
Synchronisierungsgruppe ist ein Kontrollmechanismus, das die Änderungsübertragung für
einen Satz Tabellen übernimmt. Das heisst, Änderungen an den Tabellen werden als Einheit
transferiert und als Einzeltransaktion übernommen. Zum Beispiel schlägt der
Änderungstransfer in der Gruppe fehl, dann wird bei der nächsten Synchronisation die
Änderung der gesamten Gruppe erneut gesendet.
Synchronization Adapter (Synchronisierungsadapter)
Für jede zu synchronisierende Tabelle wird ein Synchronisierungsadapter definiert, der die
spezifischen Kommandos (DeleteCommand, InsertCommand, SelectCommand und
UpdateCommand) zur Verfügung stellt, um mit der Datenbank zu interagieren. Der
Synchronisierungsadapter basiert auf dem Datenadapter des ADO.NET und kann jede von
ADO.NET unterstützte Befehlsstruktur verwenden.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 148
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
8.5.2
Synchronisierungsarten
Sync Services for ADO.NET unterstützt vier Synchronisierungsarten: snapshot, download,
upload und bidirectional. Sync Services erlaubt unterschiedliche Tabellen mit
unterschiedlichen Synchronisierungsarten festzulegen, somit erhöht sich seine Flexibilität.
Snapshot-Synchronisierung
Bei jeder vom Client angefordeten Synchronisation werden immer alle Daten vom Server
zum Client übertragen.
Download-Synchronisierung
Änderungen, die in der Back-End-Datenbank durchgeführt wurden, werden nur zur ClientDatenbank transferiert. Beim Synchronisieren werden nur die Daten übertragen, die sich seit
der letzten Synchronisation geändert haben. (Vergleichbar mit der one-way_from_server
Synchronisierungsart bei Funambol).
Upload-Synchronisierung
Änderungen, die in der Client-Datenbank durchgeführt wurden, werden nur zur Back-EndDatenbank transferiert. Beim Synchronisieren werden nur die Daten übertragen, die sich seit
der letzten Synchronisation geändert haben. (Vergleichbar mit der one-way_from_client
Synchronisierungsart bei Funambol)
Bidirektionale Synchronisierung
Die Daten, die sowohl auf dem Client wie auch auf dem Server geändert wurden, werden
aktualisiert. (Vergleichbar mit der two-way Synchronisierungsart bei Funambol)
Die Synchronisierungsrichtung kann mit Hilfe der SyncDirection-Eigenschaft definiert
werden. Dazu stehen die folgenden Werten:
Wert
Synchronisierungsart
Snapshot
Snapshot-Synchronisierung
DownloadOnly
Download-Synchronisierung
UploadOnly
Upload-Synchronisierung
Bidirectional
Bidirektionale Synchronisierung
Beispiel für C#- Code:
SyncTable customerSyncTable = new SyncTable("tabkoord");
// Download the data only from the server
// customerSyncTable.SyncDirection = SyncDirection.DownloadOnly;
// Upload the data only to the server
// customerSyncTable.SyncDirection = SyncDirection.UploadOnly;
// Upload and Download the data to/from the server
customerSyncTable.SyncDirection = SyncDirection.Bidirectional;
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 149
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
8.6 Installationsablauf des Systems III
8.6.1
Vorbedingung: Der Datenbankserver MT-MSSQL (Windows Server 2003) steht als virtuelle
Maschine bereit. Die Softwareplattform .NET Framework 2.0 muss auf dem Server installiert
sein.
Alle notwendigen Schritte sind im Dokument „MT_Installation_MSSQL2005Express.pdf“
beschrieben (siehe DVD, Verzeichnis „MS_SyncServices\Install_Docs“).
1.) Installiere den MS SQL Server 2005 Express Edition auf dem Server
2.) Installiere den Microsoft SQL Server Management Studio Express
3.) Erstelle die Datenbank, das Datenbankschema, die Tabellen, die Trigger und die
Prozeduren
Verwende dazu das eigene sql-Skript
„MSSQL_CreateDB_Tables_Triggers_Stammdaten.sql“ (unsere Skriptdatei befindet sich
im Verzeichnis „SQL-Skripte“ auf der beigelegten DVD)
4.) Konfiguriere den Zugang zum SQL Server
5.) Erstelle den Datenbankbenutzer „vermsys“
6.) Konfiguriere den Dienst „SQLBrowser“
7.) Öffne die Ports 1121 und 1434
8.6.2
Vorbedingung: Die Testrechner TestclientE (Windows XP) und TestclientF (Windows XP)
stehen als virtuelle Maschinen bereit. Die Softwareplattform .NET Framework 2.0 muss auf
den Clients installiert sein.
Alle notwendigen Schritte sind im Dokument „MT_Installation_Survey_Client _csharp.pdf“
beschrieben (siehe DVD, Verzeichnis „MS_SyncServices\Install_Docs“).
1.) Installiere den MS SQL Server 2005 Compact Edition auf dem Client
2.) Prototyp GUI: Erstelle ein neues Verzeichnis namens „survey“ direkt auf der C:\ Partition
und kopiere den Inhalt aus unserem Verzeichnis „Survey_Client_csharp“ hinein. (Das
Verzeichnis befindet sich auch auf der DVD - „PrototypGUI_CSharp\Client“).
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 150
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 176: Clientstrukturverzeichnis „Survey“
3.) Falls nötig konfiguriere die Server-Datenbankzugriffsdaten -> Editiere die Datei
„Survey.exe.config“.
<add name="MASIT.MasterThesis.Synchronization.Properties.Settings.ServerConnString"
connectionString="Data Source=MT-MSSQL\SQLExpress;Initial Catalog=vermdb;User
ID=vermsys;Password=vermsys"
providerName="System.Data.SqlClient" />
8.7 Entwicklungsumgebung Synchronisierungs-Client
8.7.1
Bevor wir mit dem Programmieren des Synchronisierungs-Clients beginnen konnten, haben
wir auf dem Notebook „Isidoro“ und auf der virtuellen Maschine „DevClientADO“ die
Programmier-Plattform MS Visual C# 2008 Express Edition installiert. Diese Plattform kann
kostenfrei von der Microsoft-Website heruntergeladen werden
(http://www.microsoft.com/express/vcsharp/Default.aspx).
Bei der Installation der Plattform MS Visual C# 2008 Express Edition wird der SQL Server
2008 Express Edition mitinstalliert. Leider besitzt zurzeit der SQL Server 2008 Express
Edition kein benutzerfreundliches Grafikinterface, um mit der Datenbank zu kommunizieren
respektive um Verwaltungsaufgaben durchzuführen. Aufgaben wie Skript einspielen oder
SQL-Statements absetzen, können mit Hilfe des komplizierten „line-command“ Werkzeugs
SQLCMD abgewickelt werden. Die Vorgängerversion SQL Server 2005 Express Edition
besitzt seit April 2006 ein zusätzliches Verwaltungs-Tool „Microsoft SQL Server Management
Studio Express“ (SSMSE), mit dem man SQL-Statements, Skripte, Benutzer- und
Berechtigungsverwaltung einfach und schnell verrichten kann. Das SSMSE ist kostenlos und
muss zusätzlich installiert werden. Wegen der vereinfachten Datenbankverwaltung haben wir
beschlossen, den SQL Server 2005 Express Edition mit dem Microsoft SQL Server
Management Studio Express als Back-End-Datenbank zu verwenden. Um Schwierigkeiten
zu vermeiden, sind wir der Meinung, dass auch die Entwicklung unseres SynchronisierungsClients mit einer SQL Server 2005 Datenbank zu erfolgen hat. Deshalb installieren wir
zusätzlich auch den SQL Server 2005 Express Edition mit dem Microsoft SQL Server
Management Studio Express auf unsere Entwickler-Maschinen.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 151
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
•
Installation Visual Studio 2008 (siehe DVD, Verzeichnis „MS_SyncServices\Install_Docs\
MT_Installation_MSVisualCSharp.pdf“)
•
Installation MS SQL 2005 (siehe DVD, Verzeichnis „MS_SyncServices\Install_Docs\
MT_Installation_MSSQL2005Express.pdf“)
Anschliessend soll die Datenbank „vermdb“ mit der Tabelle „tabkoord“ und dem
Datenbankbenutzer „vermsys“ in der Entwicklungsinstanz kreiert werden.
8.7.2
C#-Projekt für den Synchronisations-Client erstellen
Nach der Installation des Visual Studios 2008 setzten wir uns geradewegs mit dieser
Programmier-Plattform auseinander. Wir errichteten als erstes ein kleines Test-Projekt, weil
wir keine praktische Erfahrung auf Visual Studios 2008 hatten. In diesem Test-Projekt
führten wir einige Funktionen und Code-Beispiele aus. Nachdem wir erste Erfahrungen
sammeln konnten und uns mit der Plattform einigermassen vertraut machten, richteten wir
unser definitives Projekt namens „Survey“ ein.
Über das Menü File | New | Project legten wir unser Projekt auf der Partition C:\ an:
Abbildung 177: Projekt „Survey“ anlegen
Da wir zum Synchronisierungs-Client zusätzlich auch den Synchronisierungs-Provider
benötigten, erweiterten wir die Projektstruktur wie folgt:
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 152
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 178: Projektstrukturerweiterung
Den Synchronisierungs-Provider bezeichneten wir „VermServerSyncProvider“.
Abbildung 179: Synchronisierungs-Provider „VermServerSyncProvider“
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 153
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Unser Projekt besteht nun aus zwei Teilprojekten. Das untere Abbild zeigt die Projektstruktur
an:
Abbildung 180: Projektstruktur „Survey“ und „VermServerSyncProvider“
Die erforderlichen .NET Framework Bibliotheken können dem Projekt einfach hinzugefügt
werden. Dazu klickt man auf dem Struktur-Menü „References“ mit der rechten Maustaste
und wählt „Add Reference...“ aus.
Abbildung 181: Bibliotheken anlegen
Aus dem unten abgebildeten Bibliotheksfenster kann jeweils nur eine Bibliothek ausgewählt
werden. Deshalb wiederholt man diesen Schritt, bis alle nötigen Bibliotheken im Teilprojekt
eingefügt sind.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 154
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 182: Bibliotheksfenster „Add Reference“
Die nachfolgenden Bilder zeigen alle Bibliotheken unter References beider Teilprojekten
„Survey“ und „VermServerSyncProvider“:
Abbildung 183: Alle Bibliotheken „Survey“
Abbildung 184: Alle Bibliotheken
„VermServerSyncProvider“
Mit rechtem Mausklick auf dem Projektnamen können jederzeit die notwendigen Elemente
wie Klassen, DataSet, Windows Form u.s.w. in das Teilprojekt einfach erzeugt werden.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 155
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 185: Elemente anlegen
8.7.3
Klassendiagramme
Wir haben unser namespace als „MASIT.MasterThesis.Synchronization“ bezeichnet. Die
zwei Teilprojekte heissen „Survey“ und „VermServerSyncProvider“. Das Teilprojekt
„VermServerSyncProvider“ ist von „Survey“ abhängig.
Abbildung 186: Projektabhängigkeit festlegen
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 156
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Unten ist die Übersicht der Klassen dargestellt.
namespace = MASIT.MasterThesis.Synchronization
Survey
VermServerSyncProvider
Abbildung 187: Klassendiagramm
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 157
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Klasse Settings
Abbildung 188: Klasse Settings
Nachdem das Teilprojekt errichtet ist, können unter Eigenschaften (Properties) die
Einstellungen (Settings) definiert werden. In den Settings sind die Zugriffsdaten auf die
jeweiligen Datenbanken (Back-End-Datenbank und lokale Client-Datenbank) definiert.
Abbildung 189: Einstellungen im Teilprojekt
Name
Typ
Wert
ServerConnString
Connection
String
Data Source=localhost\SQLExpress;
Initial Catalog=vermdb;
User ID=vermsys;
Password=vermsys
LocalvermdbConnectionString
Connection
String
Data
Source=|DataDirectory|\localvermdb.sdf;
Password=vermsys
Diese Einstellungen werden beim Kompilieren in die XML-basierte Datei „Survey.exe.config“
geschrieben. Mit Hilfe dieser Datei kann der Zugriff auf den Datenbanken sehr flexibel
gehalten werden.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 158
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Klasse Program
Abbildung 190: Klasse Program
Die Klasse Program besitzt die Main-Methode, die die grafische Oberfläche aufruft.
Klasse MainForm
Abbildung 191: Klasse MainForm
Für eine bessere Übersicht sind die Felder im Abbild zusammengeklappt.
Mit Hilfe der Funktion „Add | New Item...“ kann die Klasse einfach erstellt werden.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 159
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 192: Funktion New Item… (1)
Anschliessend wird die Art des Elementes ausgewählt und man vergibt den Namen der CSDatei „MainForm“, dieser Name entspricht auch dem Klassennamen.
Abbildung 193: Erstellen der Klasse MainForm
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 160
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Die Klasse MainForm erbt von der Klasse Form und enthält die Elemente der grafischen
Oberfläche. Dank dem grafischen Werkzeug und seine Toolbox kann das Layout des neuen
GUI einfach erstellt werden.
Klasse VermSyncAgent
Abbildung 194: Klasse VermSyncAgent
Die Klasse VermSyncAgent erbt seine Eigenschaften von der abstrakten Klasse SyncAgent
(Microsoft.Synchronization.Data.Client.SyncAgent). Sie instanziert folgende Objekte:
•
Client Synchronisationsprovider
•
Server Synchronisationsprovider
•
SyncTable mit ihrer Erstellungsoption und ihrer Synchronisierungsrichtung
•
sowie die Getter-Methode, um die Statistik abzurufen.
Die Methode clientSyncProvider_ChangesApplied wird für die Statistikermittlung benötigt.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 161
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Klasse VermSyncDbDataSet
Abbildung 195: Klasse VermSyncDbDataSet
Aus der ADO.NET Architektur haben wir gelernt, dass sie aus zwei Hauptkomponente
besteht; dem DataProvider und dem DataSet. Diese Klasse dient dazu, der DataSet mit der
DataTable zu definieren. Weiter wird hier auch der DataAdapter mit seinen SQL-Statements
festgelegt.
Mit Hilfe der Funktion „Add | New Item...“ kann auch diese Klasse einfach erstellt werden.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 162
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 196: Funktion New Item… (2)
Die Vorlage DataSet muss selektiert werden. Anschliessend soll der Name für unser DataSet
angegeben werden.
Abbildung 197: Erstellen der Klasse VermSyncDbDataSet
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 163
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Sobald der DataSet angelegt ist, kann mit Hilfe des Wizards die TableAdapter für die BackEnd-Datenbank und für die lokale Client-Datenbank erstellt werden. Dabei muss auf der
Arbeitsfläche mit dem rechten Mausklick das Kontentmenü aktiviert werden.
Abbildung 198: TableAdapter erstellen
Der Wizard wird geöffnet.
Abbildung 199: TableAdapter Configuration Wizard
Die Verbindung zur Datenbank muss selektiert werden. Die Verbindungsarten entsprechen
derjenigen die in den Settings definierten Verbindungen (siehe Klasse Settings). Folge die
Anweisung des Wizards.
Die obige Aktion wird für den TableAdapter „local_tabkoordTableAdapter mit dem DataTable
“tabkoord“ ausgeführt. Dies dient für den Zugriff auf die Tabelle „tabkoord“ in der lokalen
Client-Datenbank. Analog wiederholt man die Prozedur um den TableAdapter
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 164
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
„tabkoordTableAdapter“ mit der DataTable local_tabkoord. Dieses Element dient für den
Zugriff auf die Tabelle „tabkoord“ in der Back-End-Datenbank.
Abbildung 200: TableAdapter tabkoord & local_tabkoord
Dabei wird auch die Klasse TableAdapterManager automatisch erstellt.
Abbildung 201: Klasse TableAdapterManager
Diese Klasse dient zur Verwaltung der erstellten TableAdapter.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 165
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Klasse tabkoordTableAdapter
Abbildung 202: Klasse tabkoordTableAdapter
Diese Klasse dient für die Anzeige der Datensätze von der Back-End-Datenbank auf dem
GUI.
Wie in der Klasse VermSyncDbDataSet gezeigt, kann mit Hilfe des Wizards die Komponente
„tabkoordTableAdapter“ erstellt werden. Diese entspricht der Klasse tabkoordTableAdapter.
Abbildung 203: tabkoordTableAdapter
Die SQL-Statements können unter Eigenschaften (Properties) des Elements definiert
werden.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 166
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 204: Eigenschaften des tabkoordTableAdapters
Command
CommandText
DeleteCommand
DELETE FROM vermsys.tabkoord
WHERE (xkoord = @Original_xkoord)
AND (ykoord = @Original_ykoord)
AND (pktnr = @Original_pktnr)
InsertCommand
INSERT INTO vermsys.tabkoord (pktnr, ykoord, xkoord)
VALUES (@pktnr,@ykoord,@xkoord)
SelectCommand
SELECT pktnr, ykoord, xkoord
FROM vermsys.tabkoord
UpdateCommand
UPDATE vermsys.tabkoord
SET pktnr = @pktnr, ykoord = @ykoord, xkoord = @xkoord
WHERE (pktnr = @Original_pktnr)
AND (ykoord = @Original_ykoord)
AND (xkoord = @Original_xkoord)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 167
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Klasse local_tabkoordTableAdapter
Abbildung 205: Klasse local_tabkoordTableAdapter
Analog der Klasse tabkoordTableAdapter dient diese Klasse für die Anzeige der Datensätze
von der Client-Datenbank auf dem GUI. Auch diese Klasse ist mit dem Wizard der Klasse
VermSyncDbDataSet erstellt worden.
Abbildung 206: local_tabkoordTableAdapter
Unter Properties des Elements können die SQL-Statements definiert werden.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 168
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 207: Eigenschaften des local_tabkoordTableAdapters
Command
CommandText
DeleteCommand
DELETE FROM tabkoord
WHERE (pktnr = @pktnr)
InsertCommand
INSERT INTO tabkoord (pktnr, ykoord, xkoord)
VALUES (@pktnr,@ykoord,@xkoord)
SelectCommand
SELECT pktnr, ykoord, xkoord
FROM tabkoord
UpdateCommand
UPDATE tabkoord
SET pktnr = @pktnr, ykoord = @ykoord, xkoord = @xkoord
WHERE (pktnr = @Original_pktnr) AND (ykoord = @Original_ykoord)
AND (xkoord = @Original_xkoord)
Klasse VermServerSyncProvider
Abbildung 208: Klasse VermServerSyncProvider
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 169
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Die Klasse VermServerSyncProvider erbt die Eigenschaften der abstrakten Klasse
DbServerSyncProvider (Microsoft.Synchronization.Server. DbServerSyncProvider). Sie baut
die Verbindung zur Hauptdatenbank auf. Weiter wird Folgendes durchgeführt:
•
Der Synchronisierungsadapter-Builder wird instanziert.
•
Fügt die Tabellen und ihre „Tombstone“-Tabellen.
•
Definiert die Synchronisationsrichtung.
•
Definiert die Spalten, die synchronisiert werden sollen.
•
Definiert die Spalten, die beim Änderungsnachverfolgung (Change Tracking) verwendet
werden.
8.8 Prototyp GUI in C#
Wie bereits mit den zwei vorherigen Systemen wollten wir ursprünglich unser Java Prototyp
GUI als Eingabe-Client verwenden. Gemäss unseren Recherchen betreffend der ClientDatenbank haben wir herausgefunden, dass MS SQL Server 2005 Compact Edition die
Schnittstellen JDBC und ODBC nicht unterstützt. Und leider stellt Java kein ADO.NET API
(Application Programming Interface) zur Verfügung. Nun standen wir vor zwei Wahlen.
Entweder verwenden wir einen anderen Client Synchronization Provider, der uns erlaubt via
JDBC oder ODBC die Datenbank wie zum Beispiel MS Access anzusprechen oder wir
programmieren einen neuen Prototyp GUI in C# (C-Sharp).
Unter Berücksichtigung einiger Kriterien wie Zeit und Aufwand - unsere Einschätzung
inbegriffen - haben wir uns entschieden, einen anderen Provider zu verwenden. Dabei
fanden wir heraus, dass der MS SQL Server 2005 Compact Edition Provider
(SqlCeClientSyncProvider) eine Vererbung der abstrakten Klasse DbSyncProvider ist. So
begannen wir einen eigenen Provider basierend auf dieser abstrakten Klasse zu entwickeln.
Beim Erstellen unseres Providers stellten wir leider fest, dass das Programmieren des
Providers alleine nicht genügt. Der gesamte Change Tracking (Änderungsnachverfolgung)
muss auch neu geschrieben werden. An dieser Stelle haben wir kurzerhand beschlossen,
die Entwicklungsarbeit abzubrechen. Die nicht durchschaubaren Abhängigkeiten und
Komplexität des Synchronisierungsmechanismus führten massgeblich zu diesem Entscheid.
Nun blieb uns nicht anderes übrig als einen neuen Prototyp GUI in C# zu programmieren.
Dieser haben wir in unserer Synchronisierungs-Client-Applikation implementiert.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 170
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
8.8.1
Programm Prototyp GUI
Das nachfolgende Bild zeigt unsere Synchronisierungs-Client-Applikation, welche zugleich
die Rolle unseres Prototyps GUI einnimmt:
Abbildung 209: Programm mit Beschreibung
Navigations-Felder
Im Navigations-Feld befinden sich alle Funktionen für die Datenmanipulation. Die
nachfolgende Tabelle beschreibt die Funktionen:
Funktionen
Beschreibung
Springt zum ersten Datensatz hin.
Springt einen Datensatz zurück.
Zeigt Position des Datensatzes und Anzahl Datensätze an.
Springt zum nächsten Datensatz hin.
Springt zum letzten Datensatz hin.
Fügt einen neuen Datensatz.
Löscht einen Datensatz.
Beim Hinzufügen, Ändern und Löschen eines Datensatzes muss die
Speicherfunktion betätigt werden, damit die Ausführung in der
jeweiligen Datenbank wirksam wird.
Aktualisiert die Anzeige-Tabelle.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 171
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Daten-Anzeigetabelle
Die obere Tabelle zeigt die Daten der Hauptdatenbank an. Die Daten werden aufgelistet,
falls die Verbindung zur Hauptdatenbank da ist und die Hauptdatenbank besteht. Die untere
Tabelle zeigt die Daten der lokalen Datenbank an, insofern Daten vorhanden sind. Falls nicht
erhält die lokale Datenbank durch Auslösung der Synchronisation die Daten aus der
Hauptdatenbank. Erst dann wird auch die untere Tabelle eingeblendet.
Auslöser-Buttons
Mit der Schaltfläche „Delete Client Database“ kann die lokale Datenbank gelöscht werden.
Dabei wird die gesamte Datenbank gelöscht. Die Datenbankdatei „localvermdb.sdf“ wird von
der Festplatte entfernt. Mit der Schaltfläche „Synchronize“ wird die Synchronisation zwischen
beiden Datenbanken ausgelöst. Unter anderem wird die lokale Datenbank neu angelegt, falls
sie nicht existiert respektive die Datenbankdatei „localvermdb.sdf“ wird im Client-Verzeichnis
erzeugt. Die Schaltfläche „Synchronize“ ist inaktiv, falls keine Verbindung zur
Hauptdatenbank vorhanden ist.
Statistik-Angaben
In unserem Programm werden nützliche Informationen dargestellt. Diese sind die Start- und
Endzeit der Synchronisation und die Anzahl manipulierter Datensätze. Zudem können wir
lesen, um was für eine Manipulation (Insert, Update und Delete) es sich handelt.
8.9 Systemtest III
8.9.1
Ausgangslage
•
•
Client E und F sind online für die Fälle 1-6
•
Client E und F sind offline für die Fälle 7-8
Bedingung: Skript „Stammdaten_MSSync.sql“ (siehe im Verzeichnis „SQL-Skripte“ auf der
beigelegten DVD) in die Hauptdatenbank einspielen. Auf den Clients muss die lokale
Datenbank „localvermdb“ mit der Tabelle „tabkoord“ nicht zwingend vorhanden sein. Falls die
lokale Datenbank nicht existiert, erstellt sie unser GUI bei der ersten Synchronisation mit der
Hauptdatenbank.
Anhand folgendes Skriptinhalts „Stammdaten_MSSync.sql“ werden die Stammdaten in der
Hauptdatenbank importiert:
USE vermdb
GO
DELETE FROM vermsys.tabkoord
DELETE FROM vermsys.tabkoord_Tombstone
GO
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 172
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
INSERT INTO vermdb.vermsys.tabkoord (pktnr, ykoord, xkoord)
VALUES ('1', '660634.772', '244641.123')
VALUES ('2', '660617.409', '244653.457')
VALUES ('3', '660675.128', '244607.968')
VALUES ('4', '660661.096', '244653.276')
VALUES ('5', '660660.782', '244601.123')
GO
aus.
Abbildung 210: Startsituation in der MSSQL Hauptdatenbank (Ausgangslage)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 173
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Startsituation auf dem TestclientE
Abbildung 211: Startsituation TestclientE (Ausgangslage)
Startsituation auf dem TestclientF
Abbildung 212: Startsituation TestclientE (Ausgangslage)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 174
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
8.9.2
Testfälle
Fall 1:
TestclientE:
Klicke auf dem Icon „Add new“
Abbildung 213: Icon „Add new“
Trage die Werte des Punkts 6 ein
Abbildung 214: Punkt einfügen TestclientE (Fall 1)
Speichere den Eintrag
Abbildung 215: Icon „Save“ (Fall 1)
Achtung: Jede Änderung muss gespeichert werden, da der Eintrag in der Tabelle nicht
automatisch gespeichert wird.
Manuelle Synchronisation auf dem TestclientE auslösen:
Abbildung 216: Synchronisation auslösen TestclientE (Fall 1)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 175
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 217: Situation in der MSSQL Hauptdatenbank (Fall 1)
Situation TestclientF:
Manuelle Synchronisation auf dem TestclientF auslösen:
Abbildung 219: Neuer Punkt TestclientF
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 176
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Fall 2:
TestclientF:
Abbildung 220: Punkt 3 modifizieren TestclientF (Fall 2)
Speichere den Eintrag
Abbildung 221: Icon „Save“ (Fall 2)
Abbildung 222: Synchronisation auslösen TestclientF (Fall 2)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 177
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Situation TestclientE:
Resultat:
Abbildung 225: Situation TestclientE (Fall 2)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 178
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Fall 3:
TestclientE:
Wichtig: Speichern nicht vergessen!
TestclientF:
Abbildung 227: Situation TestclientF (Fall 3)
Abbildung 228: Synchronisation gleichzeitig auslösen TestclientE & F (Fall 3)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 179
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Bemerkung: Bei gleichzeitigem Synchronisieren wurden die Werte des TestclientE
übernommen. Die Werte des TestclientF sind gemäss Infostand (Sync Statistics) auf dem
GUI des Clients zur Hauptdatenbank gesendet worden.
Abbildung 230: Situation TestclientF nach der Synchronisation (Fall 3)
Jedoch können wir anhand des Systems nicht herausfinden, was mit ihnen passiert ist. Das
System bietet uns auch keinen Dienst an, um den Prozessablauf analysieren und das Ganze
besser nachvollziehen zu können. Bei Oracle haben wir die Möglichkeit in der ERRORQueue und bei Funambol in den Log-Files nachzuschauen. Unsere Tombstone-Tabelle kann
uns leider auch nicht Aufschluss geben, wie nachfolgendes Bild zeigt.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 180
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 231: Situation in der Tombstone-Tabelle (Fall 3)
Eine erneute Synchronisation auf dem TestclientF führt zu keiner neuen Erkenntnis. Es bleibt
alles beim Alten. Ein Fehler in der Systemumgebung kann ausgeschlossen werden.
Demzufolge können wir von einer Dateninkonsistenz zwischen der Hauptdatenbank und der
lokalen Datenbank vom TestclientF sprechen.
Dieser Vorgang wurde dreimal wiederholt und wir bekommen immer das gleiche Ergebnis.
Fall 4:
TestclientE:
Löscht den Punkt 3
Selektiere den Punkt 3 und lösche ihn
Abbildung 232: Startsituation TestclientE (Fall 4)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 181
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 234: Situation in der MSSQL Hauptdatenbank Fall 4
Der Punkt 3 existiert nicht mehr in der Tabelle tabkoord. Sein Datensatz wurde mit Hilfe des
Triggers in der Tabelle der gelöschten Daten (tabkoord_Tombstone) verschoben.
Abbildung 235: Situation in der Tombstone-Tabelle (Fall 4)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 182
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
TestclientF:
Abbildung 236: Punkt 3 modifizieren TestclientF (Fall 4)
Abbildung 237: Synchronisation auslösen TestclientF (Fall 4)
Resultat:
Abbildung 238: Endsituation TestclientF (Fall 4)
Bemerkung: Die aktualisierten Werte des Punkts 3 sind nicht zur Back-End-Datenbank
transferiert worden, sondern der Punkt 3 ist aus der lokalen Datenbank gelöscht worden
(Server-Wins!).
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 183
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Fazit: Der Zustand der Back-End-Datenbank wird zuerst zum Client transferiert. Folglich wird
der Punkt 3 auf dem Client F gelöscht. Seine geänderten Werte werden nicht berücksichtigt.
Somit haben wir herausgefunden, dass unser System Server-dominant ist.
Fall 5:
Da der Punkt 3 nicht mehr in der Datenbank vorhanden ist (siehe Fall 4), haben wir
beschlossen, die Aufgabe mit dem Punkt 2 durchzuführen.
Abbildung 241: Synchronisation auf beide TestclientE & F auslösen (Fall 5)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 184
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 242: Situationen TestclientE (Fall 5)
Abbildung 243: Situationen TestclientF (Fall 5)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 185
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Fall 6:
Y = 1234 und X = 4321
Bei einem Update kommt unser Trigger „tabkoord_UpdateTrigger“ zum Zuge. Dieser Trigger
nimmt den zu ändernden Datensatz, in unserem Fall der Punkt 6, von der Tabelle heraus
und fügt ihn neu in der Tombstone-Tabelle ein. In der Tabelle tabkoord wird ein neuer
Datensatz mit der Punktnummer 6 und den aktualisierten Werten erstellt. Für nähere
Angaben zum Update mit unserem Triggerverfahren siehe Datenbankkapitel 9.7.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 186
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 246: Situationen TestclientE (Fall 6)
Abbildung 247: Situationen TestclientF (Fall 6)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 187
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Fall 7:
werden, denn die Synchronisierung findet erst beim Auslösen des Buttons „Synchronize“
statt.
Ausgangslage:
Lösche alle Daten in den lokalen Datenbanken.
Skript „Stammdaten_MSSync.sql“ in die Hauptdatenbank einspielen
Starte die manuelle Synchronisation auf beide Testclients
TestclientE:
TestclientF:
Auf den Clients lösche die bestehende lokale Datenbank mit dem Button „Delete Client
Database“.
Abbildung 249: Lokale DB auf beide TestclientE & F löschen (Fall 7)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 188
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Anschliessend synchronisiere wieder mit der Hauptdatenbank.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 189
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Trage die entsprechenden Punkte in den jeweiligen Client ein.
TestclientE:
Abbildung 253: Punkte 6 und 7 einfügen TestclientE (Fall7)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 190
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
TestclientF:
Abbildung 254: Punkte 8 und 9 einfügen TestclientF (Fall 7)
Client F startet die manuelle Synchronisation:
Abbildung 255: Synchronisation auf TestclientF auslösen (Fall 7)
Situation in der Haupdatenbank:
Abbildung 256: Situation in der MSSQL Hauptdatenbank nach F (Fall 7)
Client E startet die manuelle Synchronisation:
Abbildung 257: Synchronisation auf TestclientE auslösen (Fall 7)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 191
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Situation in der Haupdatenbank:
Abbildung 258: Situation in der MSSQL Hauptdatenbank nach E (Fall 7)
Nach der Synchronisation erscheinen auch die Punkte des Clients F.
Punkte, die vom Client F
stammen
Abbildung 259: Situation TestclientE nach Synchronisation Fall 7
(4 Inserts = 2 Punkte vom Client E und 2 Punkte vom Client F)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 192
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Client F startet erneut die manuelle Synchronisation, um die zugeführten Punkten
des Clients E zu erhalten.
Abbildung 261: Synchronisation auf TestclientF auslösen (Fall 7)
Punkte, die vom Client E
stammen
Abbildung 262: Situation TestclientF nach Synchronisation (Fall 7)
Fall 8:
Da die Synchronisierung manuell gestartet wird, verhält sich diese Aufgabe gleich wie die
Aufgabe 6. Somit kann die Aufgabe hier beendet werden.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 193
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
8.9.3
Quintesenz der Testfälle beim System III
Auch bei diesem System haben wir die Testreihe dreimal wiederholt. Das Ergebnis weicht
nicht von den zwei anderen Systemen ab. Gegenüber den beiden anderen Systemen ist es
in diesem System nicht einfach Konflikte wie die Fälle 3 und 4 zu ermitteln. Es war auch
nicht zu erwarten, dass ein kostenloses Produkt ein Werkzeug für die Konfliktanalyse
standardmässig zur Verfügung stellen würde. Hier wird vieles dem Entwickler überlassen.
Anhand der beiden Anzeigetabellen im neuen Prototyp GUI können einige Konflikte
festgestellt werden. Die obere Anzeigetabelle zeigt die Daten auf dem Server, die untere die
Daten auf dem Client. Diese beiden Tabellen können unser Erachtens dem Benutzer beim
Ermitteln von Konflikten behilflich sein. Auch wir nahmen für die Konfliktanalyse Bezug auf
die beiden Anzeigetabellen, welches sich bewährt hat.
Die Konfliktfälle sollten mit diesem System in einem kleinen Benutzerumfeld ebenfalls sehr
selten auftreten. Die Wahrscheinlichkeit, dass zwei Clients den gleichen Datensatz
gleichzeitig ändern und synchronisieren, ist klein. Ausserdem muss bei der Erfassung neuer
Datensätze durch diverse Clients sichergestellt werden, dass die Clients unterschiedliche
Punktnummer verwenden. Das entspricht auch die Praxis im Vermessungswesen. Mit
regelmässigem Synchronisieren in kurzen Zeitabständen können zusätzlich Konflikte
vermieden werden. Ein gleichzeitiges Synchronisieren ist zu vermeiden!
Wie bei Funambol bietet Microsoft keine automatische Synchronisation an. Aber mit Hilfe
des Betriebssystems (Scheduled Tasks = geplante Jobs) kann eine automatische
Synchronisierung erzielt werden. Dabei muss unsere Applikation erweitert werden, um die
Synchronisation mit Eingabeparameter von der Kommando-Zeile aus zu starten.
Die offline-Fälle 7 und 8 machen nur bei einer automatischen Synchronisation Sinn. Aufgabe
8 entspricht bei einer manuellen Synchronisation der Aufgabe 6.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 194
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
9 Datenbanken
9.1 Einleitung
Für unsere Arbeit haben wir verschiedene Datenbanken eingesetzt. MS-Access und MySQL
haben wir für Testzwecken des Prototyps GUI gebraucht. Die Datenbank HSQLDB wurde als
lokale Datenbank bei Funambol benutzt. Da Funambol beim Synchronisieren die Spalten
„Status“ und „Timestamp“ benötigt, musste die Datentabelle der HSQLDB und Back-EndDatenbank (MySQL) um diese zwei Attribute erweitert werden. Entsprechend musste auch
der Code im Prototyp GUI angepasst werden. Oracle Database Lite ist unser erstes
Synchronisierungssystem, das wir näher betrachtet haben. Als Back-End-Datenbank setzten
wir die Oracle 10g ein. Auf den Clients wird beim Verteilen des Synchronisations-Clients
(Mobile Client) eine Oracle „footprint“-Datenbank installiert. In unserem dritten System haben
wir auf dem Server MS SQL Server 2005 Express Edition als Back-End-Datenbank
eingesetzt. Dabei zwang uns das Synchronisierungssystem „Microsoft Synchronization
Services for ADO.NET“ auf die Clients die MS SQL Server 2005 Compact Edition als lokale
Datenbank zu verwenden. Auch bei diesem System musste eine DatenbankschemaErweiterung vorgenommen werden. All diese Datenbanken haben die gleiche Ausgangslage.
Der Datenbankname „vermdb“ heisst bei allen Back-End-Datenbanken gleich. Bei den
lokalen Datenbanken wird der Name „localvermdb“ verwendet. Jede enthält eine Tabelle
namens „tabkoord“ und die gleichen Daten. Es kommen fünf Punktdatensätze mit den drei
wichtigen Attributen (Punktnummer, Y-Koordinate und X-Koordinate) vor. Die Daten wurden
bei fast allen Datenbanken über ein Skript importiert. Die Punktnummer ist der eindeutige
Identifikator (primärer Schlüssel).
9.2 MS-Access
Für das Testen der Benutzungsoberfläche unseres Prototyps GUI haben wir eine AccessDatenbank „vermdb.mdb“ verwendet. Wie bereits in der Einleitung erwähnt, besitzt die
Datenbank nur eine Tabelle „tabkoord“ mit den fünf Stammdatensätzen. Sie besteht aus drei
Attributen:
Abbildung 263: Attribute in MS-Access
Die Punktnummer (Zeile PktNr) dient als primärer Schlüssel. Ihr Zahlwert kann in der Tabelle
nur einmal vorkommen. Alle Zeilen müssen Daten (NOT NULL) enthalten.
Abbildung 264: Spaltenbeschreibung in MS-Access
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 195
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Die Werte der Tabelle wurden vorgängig händisch eingetragen.
Abbildung 265: Stammdaten in MS-Access
Der Zugriff auf die Datenbank läuft über die ODBC-Schnittstelle von Microsoft.
Abbildung 266: ODBC-Einstellung Microsoft für MS-Access
Codeausschnitt des Prototyps GUI für die Datenbankverbindung
Für die Datenbankverbindung müssen in der Java Klasse „VermDb“ der entsprechende
JDBC-Treiber und -URL verwendet werden:
if (dbmsType.equals("MS Access")){
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
con = DriverManager.getConnection(url);
…
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 196
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
9.3 MySQL
Für unseren Prototyp GUI haben wir zu Testzwecken auch eine MySQL-Datenbank
angelegt. Das Besondere an MySQL ist, dass der Zugriff auf die Datenbank via einen Server
läuft, den uns XAMPP als Open Source zur Verfügung stellt. Zudem haben wir einen
Benutzer „vermsys“ erstellt, der mit Passwort auf die Datenbank zugreifen kann. Diese
Eigenschaften kommen uns beim Testen der „ListGUI“- und „DialogLogin“-Oberfläche
respektive der Verbindung zur Datenbank sehr gelegen.
Hier ein Ausschnitt unseres Testusers mit Zugriffsrechten:
Abbildung 267: Benutzer mit Zugriff in MySQL
Aus dem nachfolgenden Ausschnitt ist ersichtlich, dass die „vermdb“ aus einer Tabelle
besteht:
Abbildung 268: Tabellenbestand in MySQL
Die Daten und ihre Struktur werden hier folgendermassen dargestellt:
Abbildung 269: Stammdaten in MySQL
Abbildung 270: Spaltenbeschreibung in MySQL
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 197
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
if (dbmsType.equals("MySQL")){
Class.forName("com.mysql.jdbc.Driver").newInstance();
con = DriverManager.getConnection(url, strUser, strPassword);
…
Bei Funambol kam MySQL als Back-End-Datenbank zum Einsatz. Die Tabelle „tabkoord“
wurde wegen des Funambol-Systems um die Spalten „fmbstatus“ und „fmbtimestamp“
erweitert, welche die NOT NULL Constraint besitzen.
Mit dem Funambol-System werden auf der Hauptdatenbank keine Datensätze physisch
gelöscht. Ein gelöschter Datensatz wird mit dem Status „D“ für Delete vermerkt. Es gibt noch
die Statusarten „N“ für New und „U“ für Update. Je nach Datenmanipulation wird in der
Spalte „fmbstatus“ das entsprechende Zeichen eingetragen. Zugleich wird in der Spalte
„fmbtimestamp“ die Zeit der Änderung (CURRENT_TIMESTAMP) registriert. Diese
Eigenschaft spielt eine wesentliche Rolle beim Synchronisieren von verschiedenen lokalen
Datenbanken zur Hauptdatenbank. Am folgenden Beispiel wird der Sinn beider Spalten und
weshalb ein Datensatz in der Hauptdatenbank physisch nicht gelöscht werden kann, näher
erklärt.
Ein Datensatz befindet sich identisch sowohl auf der Hauptdatenbank wie auch auf der
lokalen Datenbank. Beide Datensätze sind mit Zeitstempel der Erstellung oder Änderung
versehen. Würde man diesen Datensatz in der Hauptdatenbank physisch löschen, dann
würde dieser bei der nächsten Synchronisierung in der lokalen Datenbank nicht gelöscht,
weil die Synchronisierung nur bestehende Datensätze mit Zeitstempel ab Abschlusszeit der
letzten Synchronisation berücksichtigt. Somit wird der Datensatz der lokalen Datenbank von
der Synchronisierung nicht mehr erfasst und dies würde also zu einer Dateninkonsistenz
(Datenleiche) führen.
Bei der lokalen Datenbank sieht es ganz anders aus. Ein gelöschter Datensatz wird mit dem
Status „D“ solange geführt bis eine Synchronisierung mit der Hauptdatenbank stattgefunden
hat. Erst danach wird der Datensatz physisch in der lokalen Datenbank gelöscht. Der
SyncClient merkt sich jeweils den Zeitpunkt der letzten Synchronisierung.
if (dbmsType.equals("Funambol DS MySQL")){
Class.forName("com.mysql.jdbc.Driver").newInstance();
…
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 198
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
9.4 HSQLDB
Wie bereits in der Einleitung erwähnt, verwenden wir in unserem Funambol-System
HSQLDB als lokale Datenbank. HSQLDB kann unter www.hsqldb.org heruntergeladen
werden. Am besten geht man in der Website auf „latest stable version“ und lädt sich die
hsqldb_1_8_0_10.zip herunter. Diese zip-Datei soll auf das Verzeichnis C:\ des Clients
entpackt werden. Folgende Verzeichnisstruktur erhält man:
Abbildung 271: hsqldb-Verzeichnisstruktur
Unter dem Verzeichnis hsqldb\doc\guide befindet sich das Benutzer-Handbuch guide.pdf
(Hsqldb User Guide). Dort wird unter anderem beschrieben, wie die Datenbank gestartet
werden kann. Es gibt da verschiedene Wege. Wir haben uns entschieden, die Datenbank in
Server Modus zu starten. Um die Datenbank hochzufahren, haben wir zur Vereinfachung ein
Skript „Start_HSQLDB_Server.bat“ erstellt. Die Datei muss bei uns im Verzeichnis C:\hsqldb
abgelegt werden. Eine Kopie der Datei befindet sich auch auf der beigelegten DVD im
Verzeichnis „Tools\Database\hsqldb“.
Inhalt des Files Start_HSQLDB_Server.bat:
set JAVA_HOME=C:\Program Files\Java\jre6
set HSQLDB_HOME=C:\hsqldb
cd C:\hsqldb
java -cp %HSQLDB_HOME%\lib\hsqldb.jar org.hsqldb.Server -database.0 file:localvermdb dbname.0 localvermdb
Der Server wird gestartet und man erhält folgendes Bild in der Kommando-Konsole:
Abbildung 272: HSQLDB Server gestartet
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 199
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Danach muss das Benutzer-GUI mit der runManager.bat-Datei gestartet werden, welche sich
im Verzeichnis „C:\hsqldb\demo“ befindet. Das Anmeldepanel des HSQL Database
Managers wird geöffnet, wie nachfolgendes Bild zeigt:
Abbildung 273: Anmeldepanel HSQLDB Manager
Im Anmeldepanel werden unter Type der HSQL Database Engine Server ausgewählt und
unter URL der Datenbankname „localvermdb“ noch angegeben. Der standardmässige
Username „sa“ ohne Passwort bleibt bestehen. Mit Ok erhält man das folgende GUI:
Abbildung 274: Verwaltungspanel HSQLDB
Die Tabelle „tabkoord“ ist im Abbild bereits ersichtlich. Diese müsste natürlich als nächster
Schritt mit folgendem Skriptinhalt erzeugt werden:
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 200
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
DROP TABLE tabkoord;
CREATE TABLE tabkoord
(pktnr VARCHAR(4) NOT NULL,
ykoord VARCHAR(9) NOT NULL,
xkoord VARCHAR(9) NOT NULL,
fmbstatus CHAR(1) NOT NULL,
fmbtimestamp TIMESTAMP NOT NULL,
PRIMARY KEY (pktnr));
Die Tabelle weist folgende Struktur auf:
Abbildung 275: Strukturbeschreibung in HSQLDB
Nullable: false bedeutet, dass die Daten NOT NULL sein müssen. Im Indices ist der
Primärschlüssel „pktNr“ eingetragen.
Die Daten können über folgende Statement-Anweisung „select * from tabkoord;“ angezeigt
werden, welche vorgängig über das Skript „Stammdaten_Funambol.sql“ importiert wurden:
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 201
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 276: Stammdaten in HSQLDB
if (dbmsType.equals("Funambol DS HSQL")){
Class.forName("org.hsqldb.jdbcDriver").newInstance();
…
9.5 Oracle
Bei der ersten Systemevaluation haben wir Oracle als Back-End-Datenbank eingesetzt. In
Oracle werden anhand der Applikation Oracle SQLDeveloper die Daten und ihre Struktur
folgendermassen dargestellt:
Abbildung 277: Stammdaten in Oracle
Die Werte der Tabelle wurden vorgängig über das Skript „Stammdaten.sql“ importiert.
Abbildung 278: Spaltenbeschreibung in Oracle
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 202
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
if (dbmsType.equals("Oracle")){
Class.forName("oracle.jdbc.driver.OracleDriver");
…
9.6 Oracle Database Lite
Oracle Database Lite ist unser erstes System, das wir evaluierten. Als lokale Datenbank
wurde eine kleine sogenannte „footprint“ Oracle-Datenbank und Oracle 10g als Back-EndDatenbank installiert. Somit haben wir eine homogene Systemumgebung. Der Zugriff auf die
lokale Datenbank läuft über die ODBC-Schnittstelle von Oracle Lite (Oracle Lite 40 ODBC
Driver). Die ODBC-Schnittstelle wird durch den Deployment unseres Pakets automatisch im
System DSN (Data Source Name) erstellt und konfiguriert. Die nachfolgenden Bilder zeigen
die automatisch erstellte ODBC-Schnittstelle „ANGELO_localvermdb“ und die
Konfigurationseinstellung des TestclientB:
Abbildung 279: ODBC-Schnittstelle von Oracle Lite
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 203
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 280: ODBC-Konfigurationseinstellung
Analog zum TestclientB heisst die ODBC-Schnittstelle „ISIDORO_localvermdb“ für den
TestclientA. Der Name des DSN setzt sich aus dem Namen des Gerätebenutzers, der
während der Installation des Oracle Lite Clients (Mobile Client) angegeben werden muss,
und aus dem Namen der lokalen Datenbank zusammen.
Mit der msql.exe können die Daten über folgende Statement-Anweisung „select * from
tabkoord;“ in der Kommando-Konsole angezeigt werden. Die msql.exe ist Bestandteil des
Mobile Clients und befindet sich bei uns im Verzeichnis „C:\mobileclient\bin“:
Abbildung 281: Stammdaten in Oracle Lite DB via msql anzeigen
Mit der folgenden Statement-Anweisung „desc tabkoord“ wird die Tabellenstruktur angezeigt:
Abbildung 282: Tabellenstruktur in Oracle Lite DB via msql anzeigen
if (dbmsType.equals("Oracle Lite DB")){
Class.forName("oracle.lite.poljdbc.POLJDBCDriver");
System.out.println(url + "," + strUser + "," + strPassword);
…
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 204
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
9.7 Microsoft SQL Server 2005 Express Edition
Bei der dritten Systemevaluation „Microsoft Synchronization Services for ADO.NET“ haben
wir MSSQL 2005 Express Edition als Back-End-Datenbank eingesetzt. MSSQL 2005
Express Edition ist ein kostenloses Datenverwaltungsprodukt. Zusammen mit dem zusätzlich
zu installierenden Verwaltungs-Tool „MSSQL Server Management Studio Express“ (SSMSE)
kann die Administration der Datenbank einfach und schnell verrichtet werden. SSMSE steht
zurzeit für die neuere Version MSSQL 2008 Express Edition nicht zur Verfügung. Daher
haben wir uns für MSSQL 2005 Express Edition entschieden. Das Synchronisierungs-Tool
erlaubt auch andere Datenbanksysteme als Back-End-Datenbank zu verwenden, sofern
diese auch einen ADO.NET Provider zur Verfügung stellen.
Analog zu Funambol mussten wir wegen des Change Trackings (Datenänderungsnachverfolgung) vom Microsoft Synchronization Services die Tabelle „tabkoord“ auch um die
Spalten „UpdateTimestamp“, „InsertTimestamp“, „UpdateId“ und „InsertId“ erweitern.
Die Tabellenstruktur sieht folgendermassen aus:
Abbildung 283: Tabellenstruktur „tabkoord“ in MSSQL
Ferner musste das Datenbankschema um die Tabelle „tabkoord_tombstone“ erweitert
werden. Diese wird für die gelöschten Datensätze benötigt. Sie besitzt fünf Spalten „pktNr“,
„ykoord“, „xkoord“, „DeleteId“ und „DeleteTimestamp“.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 205
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Die Tabellenstruktur sieht folgendermassen aus:
Abbildung 284: Tabellenstruktur „tabkoord_tombstone“ in MSSQL
Die gelöschten Datensätze der Tabelle „tabkoord“ werden anhand unseres Triggers
„tabkoord_DeleteTrigger“ in die Tabelle „tabkoord_tombstone“ transferiert.
Unser tabkoord_DeleteTrigger sieht folgendermassen aus:
Abbildung 285: Trigger „tabkoord_DeleteTrigger“ in MSSQL
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 206
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Die Punktnummer ist bei uns auch der Primärschlüssel (Primary Key). Wenn wir die
Punktnummer eines Datensatzes ändern, wird die Änderung problemlos vollzogen. Beim
Synchronisieren stellten wir aber fest, dass bei der synchronisierenden Datenbank der
veränderte Datensatz als neuer Datensatz hinzugefügt wird. Der alte Datensatz bleibt in der
Datenbank unverändert bestehen, wie nachfolgendes Beispiel zeigt:
Beispiel „Punktnummer ändern“
Das folgende Abbild zeigt unser neue Prototyp GUI. Oben wird die Tabelle der
Hauptdatenbank und unten die Tabelle der lokalen Datenbank dargestellt. Beide Tabellen
können über unserem Prototyp GUI manipuliert werden.
Abbildung 286: Ausgangslage (Beispiel)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 207
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Nun soll der Datensatz mit der pktNr 1 zu pktNr 11 in der Hauptdatenbank geändert werden.
Abbildung 287: Punktnummer ändern (Beispiel)
Nachdem der Punkt in der oberen Tabelle geändert und gespeichert wurde, startet man die
Synchronisation.
Abbildung 288: Endstand (Beispiel)
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 208
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Wie man in der unteren Tabelle sehen kann, bleibt der Datensatz mit der Punktnummer 1
bestehen. Der Datensatz mit der Punktnummer 11 von der Hauptdatenbank wird als neuer
Datensatz hinzugefügt. Das gleiche Resultat erhält man umgekehrt, wenn man das Beispiel
von der lokalen Datenbank ausführt. Ändert man einen Wert in der ykoord oder xkoord, läuft
der Update bei der Synchronisation fehlerfrei.
Zur Abhilfe dieses Update-Problems haben wir den Trigger „tabkoord_UpdateTrigger“
geschrieben, wie nachfolgend dargestellt:
Abbildung 289: Trigger „tabkoord_UpdateTrigger“
Microsoft Synchronization Services braucht zur Konfliktbehebung drei Datenbankprozeduren
(Procedures) für Insert, Update und Delete. Für nähere Angaben verweisen wir auf das SQLSkript „MSSQL_CreateDB_Tables_Triggers_Stammdaten.sql“ im Verzeichnis „SQL-Skripte“
auf der beigelegten DVD.
Die Prozeduren sind im Stored Procedures der Datenbank abgelegt, wie nachfolgendes Bild
zeigt:
Abbildung 290: Stored Procedures in MSSQL
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 209
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Info:
Gemäss Microsoft Developer Network kurz MSDN besitzt Microsoft SQL
Server 2008 neu die Funktion „Change Tracking“, die aktiviert werden kann.
Somit fallen die obigen Anpassungen wie Datenbankschemaänderung,
Tabellenerweiterung und Triggererstellung aus.
Für die Aktivierung des Change Trackings sind folgende Einstellungen
vorzunehmen:
CREATE TABLE vermdb.vermsys.tabkoord(
pktnr nvarchar(4) NOT NULL PRIMARY KEY,
ykoord nvarchar(10) NOT NULL,
xkoord nvarchar(10) NOT NULL)
ALTER DATABASE vermdb SET ALLOW_SNAPSHOT_ISOLATION ON
ALTER DATABASE vermdb
SET CHANGE_TRACKING = ON
(CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON)
ALTER TABLE vermdb.vermsys.tabkoord
ENABLE CHANGE_TRACKING
Kommentar: Wir haben uns nicht für Microsoft SQL Server 2008 entschieden, weil wir das
Change Tracking Verhalten näher kennenlernen wollten und falls eine andere
Back-End-Datenbank (Oracle, MySQL, etc.) später zur Anwendung kommen
sollte.
Zugriffdefinition für die Datenbankverbindung von unserem neuen Prototyp GUI
Die Zugriffsinformation auf die Back-End-Datenbank befindet sich in der Datei
Datenbankbenutzer (SQL Server Authentication)
connectionString="Data Source=MT-MSSQL\SQLExpress;Initial Catalog=vermdb;User
ID=vermsys;Password=vermsys"
Windows Authentication Mode
connectionString="Data Source=MT-MSSQL\SQLExpress; Initial Catalog=vermdb;Integrated
Security=True"
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 210
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
9.8 Microsoft SQL Server 2005 Compact Edition
Das Synchronisierungs-Tool „Microsoft Synchronization Services for ADO.NET“ verlangt auf
die Clients die MS SQL Server 2005 Compact Edition als lokale Datenbank. Die lokale
Datenbank namens „localvermdb“ wird automatisch durch unser csharp-GUI erzeugt. Die
Datenbankdatei „localvermdb.sdf“ befindet sich im Verzeichnis von unserem GUI.
Abbildung 291: Ablageverzeichnis der lokalen Datenbankdatei „localvermdb.sdf“
Zugriffdefinition für die Datenbankverbindung von unserem GUI
Die Zugriffsinformation auf die lokale Datenbank befindet
sich
in
der
Datei
<add name="MASIT.MasterThesis.Synchronization.Properties.Settings.localvermdbConnectionString"
connectionString="Data Source=|DataDirectory|\localvermdb.sdf;Password=vermsys"
providerName="Microsoft.SqlServerCe.Client.3.5" />
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 211
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
10 Schlussdiskussion
10.1 Vergleichen der Systeme
10.1.1 System I
Oracle Database Lite ist ein Synchronisierungssystem der Firma Oracle. Es lässt sich auf die
gängigsten Betriebssysteme wie MS Windows, Linux und UNIX installieren. Die Installation
des Systems auf MS Windows 2003 verlief bei uns problemlos. Die einzelnen Komponenten
werden installiert und anschliessend konfiguriert. Je nach Verwendungszweck kann die
Konfiguration ziemlich zeitintensiv sein. Die umfangreiche Dokumentation von Oracle
erleichtert die Konfigurationsarbeit auch nicht. Das Sprichwort „Aus lauter Bäumen den Wald
nicht sehen“ passt gerade dazu. Zum Glück ist das System schon Einsatz bereit, sobald die
Konfiguration abgeschlossen wird. Und es sind auch keine Programmierschritte nötig. Oracle
Database Lite stellt einen webbasierten Manager für die Konfigruation und Verwaltung zur
Verfügung. Dieser erwies sich bei der Konfigurationsarbeit als Vorteil. Ein weiteres Plus von
Oracle Database Lite ist das Software-Paketisierungswerkzeug und das SoftwareVerteilungswerkzeug (Deployment-Management). Mit diesen Werkzeugen können
Applikationen zu Software-Pakete zusammengeschnürrt und auf dem Client einfach
installiert werden. Damit können grosse Betriebe viel Zeit und Verwaltungsaufwand
einsparen. Beim Einsatz der Software-Paketisierung ist Folgendes zu beachten: Die SSLVerschlüsselung darf während der Installation nicht aktiviert sein, denn sonst lassen sich die
Software-Pakete nicht erstellen. Ferner können das Synchronisierungssystem und die BackEnd-Datenbank auch auf derselben Maschine installiert werden. Das Synchronisierungssystem lässt PDA, Notebook oder Desktop als Client zu. Leider ist ein solches System
kostenpflichtig. Nebst den Kosten für das Synchronisierungssystem kommen auch die
Oracle Datenbank-Lizenzgebühren hinzu. Seit der Datenbankversion Oracle 10g erhält man
von der Firma Oracle auch eine kostenlose Express Edition, die als Back-End-Datenbank
verwendet werden kann. Mit dieser kostenlosen Software können zum Beispiel Firmen Geld
sparen. Weitere Nachteile von Oracle Database Lite sind: Die Client-Software darf nicht auf
derselben Maschine wie Oracle Database Lite installiert sein, pro Benutzer darf nur ein Client
zugewiesen werden, ein Gerät kann nur von einen Benutzer verwendet werden. Ausserdem
erhalten die Benutzer keine Rückmeldung bei Synchronisationskonflikten. Davon abgesehen
werden die Synchronisationskonflikte vom System erkannt, abgefangen und in die ERRORQueue abgelegt. Der Administrator kann sie dort besichtigen und bereinigen. Die
Datensynchronisierung verlief bei unseren Tests einwandfrei. Generell hat sich dieses
System in unserer Testumgebung bezogen auf Funktionalität und Robustheit bewährt. Auch
die automatische Synchronisation hinterliess einen positiven Eindruck. Die automatische
Synchronisation kann unerfahrenen Anwendern von Nutzen sein. Unser Prototyp GUI
funktioniert in diesem Verbund ebenfalls makellos.
10.1.2 System II
Funambol ist eine kostenlose Java-Applikation, die sich auf den Betriebssystemen MS
Windows und Linux installieren lässt. Wie beim ersten System lief auch die Installation
dieses System auf MS Windows 2003 problemlos ab. Die Installationsdokumentation ist
schlicht und übersichtlich. Auf der gleichen Maschine können der Funambol DS Server und
die Back-End-Datenbank installiert werden. Als Back-End- und Client-Datenbanken stehen
momentan MySQL, HSQLDB und PostgreSQL zur Verfügung. Diese kostenlosen
Datenbanken können auf diverse Betriebssysteme installiert werden. Funambol verwendet
Client-seitig PDA, Notebook oder Desktop. Aber er besitzt leider kein Deployment______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 212
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Management. Die Synchronisations-Clients und die Benutzer-Applikationen müssen manuell
verteilt und installiert werden. Deployment-Systeme von Drittanbieter können zur
Softwareverteilung eingesetzt werden. Von Hause aus hat Funambol mehrere PIM-Clients.
Leider ist kein Synchronisations-Client für unsere Arbeit dabei. Nichtsdestotrotz hat
Funambol ein API, mit dem man die Synchronisations-Clients (Schnittstelle Client-Datenbank
zu Funambol DS Server) und Connectoren (Schnittstelle Funambol DS Server zur
Hauptdatenbank) selber programmieren kann. Obwohl eine bescheidene Dokumentation zu
diesem API existiert, ist dadurch die Programmierung sehr aufwendig, kostspielig und zum
Teil schwierig. Dementsprechend wird ein vertieftes Wissen im Java-Programmieren
vorausgesetzt. Mit Hilfe der Entwicklungs-Literatur von Funambol kann die Entwicklungsumgebung via Maven eingerichtet werden. Dabei mussten wir feststellen, dass diverse
fehlerbehaftete Dokumenten auf der Website veröffentlicht sind. Wir empfehlen daher das
Dokument „Funambol Developer’s Guide“ vom 31. Juli 2008 zu verwenden. Zusätzlich muss
das Datenbankschema für eine reibungslose Synchronisierung erweitert werden. In jede zu
synchronisierenden Tabellen kommen zwei neue Spalten hinzu, welche die neuen,
geänderten oder gelöschten Datensätze mit Zeitstempel und Status markiert. Sobald die
Schnittstellen ausprogrammiert sind, funktioniert auch dieses System tadellos. Zudem
bestätigen unsere Testfälle die einwandfreie Synchronisierung. Bei Funambol vermissen wir
ein Werkzeug für die Konfliktanalyse. Zurzeit erfolgt zumindest auf unserem System die
Konfliktanalyse via Log-Datei. Beim Funambol-System gibt es in diesem Fall aus unserer
Sicht noch Entwicklungspotenzial. Ausserdem werden die End-User bei diesem System nicht
über Synchronisierungskonflikte benachrichtigt. Auch in diesem Bereich könnte Funambol
verbessert werden. Weiter betrachten wir als Nachteil, dass Funambol keine automatische
Synchronisation anbietet. Jedoch kann mit Hilfe der „geplanten Jobs“ (bei Windows) oder „at“
bei Linux die Startup-Datei so eingebunden werden, dass die Synchronisation regelmässig
automatisch gestartet wird. Positiv fällt bei diesem System auf, dass die Client-Applikation
auf einem Gerät von mehreren Benutzern verwendet werden kann. Ähnlich wie Oracle
Database Lite besitzt Funambol eine Applikation „Administration Tool“, um die Benutzer, die
Clients und die Applikationen zu verwalten. Unser Prototyp GUI funktioniert in diesem
Verbund ebenfalls fehlerfrei.
10.1.3 System III
Das dritte System „Microsoft Synchronisation Services for ADO.NET“ ist ein kostenloses
Framework, das nur auf die Microsoft Betriebssysteme läuft. Auch hier kommen PDA,
Notebook oder Desktop als Client zum Einsatz. Als Client-Datenbank kann nur der Microsoft
SQL Server Compact 3.5 eingesetzt werden und als Back-End-Datenbank darf jedes
beliebige Datenbankmanagement-System verwendet werden, für das einen ADO.NET
Provider existiert. Wir konnten feststellen, dass die gängigsten DatenbankmanagementSysteme wie MS SQL Server, MySQL und Oracle einen solchen Provider zur Verfügung
stellen. Zu erwähnen ist, dass selbst unser erstes System „Oracle Database Lite“ einen
ADO.NET Provider API (SQLDriverConnect) für die Client-Datenbank besitzt. Um Kosten zu
sparen, schlagen wir die kostenfreien Datenbanken wie zum Beispiel die diversen MS SQL
Server Express Editionen vor. Gleich wie beim Funambol-System müssen wir bei diesem
System unser Datenbankschema anpassen. Jede zu synchronisierende Tabelle muss mit
vier zusätzlichen Spalten erweitert werden. Zudem benötigt das System zwingend zu jeder
Tabelle eine Tombstone-Tabelle. Diese Tombstone-Tabelle verwaltet die gelöschten
Datensätze. Nebst diesen Anpassungen benötigen wir einen Trigger, der die gelöschten
Datensätzen aus der Hauptdatenbank-Tabelle in ihre Tombstone-Tabelle einträgt. Ohne
diese Datenbankmodifikation läuft die Datenänderungsnachverfolgung (Change Tracking)
nicht. Das Aufsetzen des Systems ist einigermassen einfach. Es muss lediglich die BackEnd-Datenbank aufgesetzt und eingerichtet werden. Anschliessend muss auf den Clients die
selbst programmierte Synchronisations-Applikation installiert werden. Wie bei Funambol
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 213
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
kann die Verteilung der Client-Software entweder manuell oder mit einer kostenpflichtigen
Deployment-Software von einem Drittanbieter erfolgen. Auch bei diesem System gibt es
keinen fertigen Synchronisations-Client. Wir mussten für unsere Bedürfnisse einen eigenen
Synchronisations-Client entwickeln. Dazu steht die online-Dokumentation von Microsoft mit
den diversen Code-Beispielen zur Hilfe. Für die Programmierung des Clients sind geforderte
Programmierkenntnisse in C# oder Visual Basic von grossen Vorteil. Das System „Microsoft
Synchronisation Services for ADO.NET“ unterstützt zwei Szenarien: offline- und
Zusammenarbeits-Szenario. Im Zusammenarbeits-Szenario spielt sich eine Peer-to-PeerSynchronisation ab. Beim offline-Szenario handelt es sich um eine Server-Client
Synchronisation, die bereits bei den anderen Systemen zum Einsatz kommt. Die Architektur
des Clients kann entweder in einer 2-Tier oder n-Tier aufgebaut werden. Die n-Tier ist
definitiv die komplizierteste Architektur. Deshalb empfehlen wir die 2-Tier-Architektur
aufzusetzen. Wie bei den vorgängigen Systemen funktioniert auch dieses System tadellos.
Unsere durchgeführten Tests zeigen das korrekte Systemverhalten natürlich auf. Leider ist
das Konflikt-Handling nicht genau ersichtlich. Und bei Konfliktproblemen werden die
Anwender auch nicht darüber informiert. Sicher kann man analog zu Funambol mit
zusätzlichem Programmieraufwand ein geeignetes Konflikt-Tool erstellen. Dabei kann man
auch die Konflikt-Benachrichtigung an den End-User berücksichtigen. Ferner besitzt dieses
System kein Management-Tool, um die Applikation, die Benutzer und die Geräte zu
verwalten. Ähnlich wie Funambol kann die Client-Applikation auf einem Gerät von mehreren
Benutzern verwendet werden. Der Synchronisation-Zugriff wird über den Datenbankbenutzer
gesteuert. Da das System auf Microsoft-Produkte und schliesslich auf die .NETEntwicklungsplattform eingeschränkt ist, funktioniert unglücklicherweise unser Javageschriebene Prototyp GUI nicht auf diesem System. Ein neuer Prototyp GUI haben wir
demzufolge für unsere Arbeit in C# geschrieben.
10.1.4 Übersicht der Systeme
Eigenschaften
Oracle Database
Lite
(System I)
Funambol
(System II)
MS Sync
Services
(System III)
Open Source
nein
ja
nein
Kostenpflichtig
ja
nein
nein
Installationsaufwand
mässig
mässig
gering
Konfigurationsaufwand
je nach
Verwendungszweck gross
mässig
gering
Programmieraufwand
kein
gross
(Synchronisations
-Client und
Connector)
gross
(Synchronisations
-Client)
Betriebssystem
MS Windows,
Linux und UNIX
MS Windows und
Linux
MS Windows
Back-End-Datenbank
ab Oracle 9i
MySQL, HSQLDB
und PostgreSQL
beliebige
Datenbanken, für
die ein ADO.NET
Provider zur
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 214
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Verfügung steht
Client-Datenbank
“footprint”-Oracle
Datenbank
MySQL, HSQLDB
und PostgreSQL
nur Microsoft SQL
Server Compact
3.5
Verwaltungssystem
webbasiert
Java-Applikation
keine
Paketisierungsmanagement
ja
nein
nein
Deploymentmanagement
ja
nein
nein
Dokumentation
zu ausführlich
genügend
genügend
Synchronisierung
funktioniert
einwandfrei
funktioniert
einwandfrei
funktioniert
einwandfrei
Synchronisationsarten
automatisch und
manuell
manuell
manuell
Synchronisationsrichtung
bidirektional
bidirektional
bidirektional
Konflikterkennung
wird erkannt
wird erkannt
wird erkannt
Konfliktanalyse
webbasiertes
Management
Log-File
keine
Konfliktbehebung
webbasiertes
Management
(ERROR-Queue)
keine
keine
Konfliktbenachrichtigung
nein
nein
nein
DB-Tabellenerweiterung
nein
ja
ja*
Zusätzliche DB-Tabellen
nein
nein
ja*
Eigene DB-Trigger
nein
nein
ja*
Anzahl Benutzer pro Gerät
1
mehrere
mehrere
Anzahl Gerät pro Benutzer
1
mehrere
mehrere
Mobile Geräte
PDA, Desktop,
Notebook,…
PDA, Desktop,
Notebook,…
PDA, Desktop,
Notebook,…
Systemszenario
Server-Client
Server-Client
Server-Client oder
Peer-to-Peer
Einsatz Java Prototyp GUI
ja
ja
nein**
* Mit MS SQL Server 2008 kann DB-Schemaanpassung vermieden werden.
** Neuer Prototyp GUI in C# entwickeln.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 215
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
10.1.5 Beurteilung der Systeme
Bei allen Systemen funktioniert die Synchronisation korrekt, sobald die Systeme fertig
aufgesetzt und konfiguriert sind. Die Synchronisierung verhält sich bei allen gleich. Alle drei
Systeme können eine bidirektionale Synchronisation anbieten und Synchronisierungskonflikte erkennen. Oracle Database Lite besitzt gegenüber den anderen Systemen das
bessere Werkzeug, um Konflikte zu beheben. Weiter vermissen wir bei allen Systemen die
Konfliktbenachrichtigung an den Endbenutzer. Oracle Database Lite stellt nebst dem
Synchronisationsmodul auch zwei weitere Applikationen (Software-Packaging und
Deployment-Management) zur Verfügung. Damit kann die eigene Anwendung verpackt und
veröffentlicht werden. Aber leider ist Oracle Database Lite kostenpflichtig. Die zwei anderen
Systeme (Funambol und MS Sync Services) sind zwar kostenlos, bieten weder die zwei
vorher genannten Applikationen noch einen Synchronisierungs-Client für unsere Bedürfnisse
an. Den Synchronisierungs-Client müssen wir selber programmieren. Dies ist eine
zeitaufwendige Aufgabe. Zudem muss bei beiden Systemen das Datenbankschema
erweitert werden. Von allen drei Systemen lässt sich am einfachsten das MS Sync ServicesSystem aufsetzen. Die beiden anderen Systeme benötigen einen grösseren Aufwand, aber
sie können dafür auch auf diverse Betriebssysteme installiert werden. Das MS Sync
Services-System ist leider nur auf die MS Windows Betriebssysteme eingeschränkt.
Fazit: Wir sind der Meinung, dass hier eine Bewertungsrangliste der Systeme nicht
angebracht wäre. Wie einleitend erwähnt, führen alle Systeme eine korrekte
Synchronisierung durch. Und alle Systeme haben die Testfälle erwartungsgemäss gelöst.
Die wichtigsten Kriterien unsererseits sind der Preis und der zeitliche Programmieraufwand.
Oracle
Database
Lite
ist
kostenpflichtig
und
verlangt
keine
aufwendige
Programmieraufgaben. Die beiden anderen Systeme sind kostenlos und mit ziemlichem
Programmieraufwand verbunden. Nicht zu vergessen ist die Integration unseres Prototyps
GUI im System. Bei den Systemen Oracle Database Lite und Funambol kann unser
ursprüngliche Prototyp GUI eingesetzt werden.
10.2 Vergleich mit Pflichtenheft
In diesem Kapitel vergleichen wir unsere Arbeit mit dem Inhalt des Pflichtenhefts. Unsere
erzielten Resultate werden tabellarisch mit den Kriterien im Pflichtenheft gegenübergestellt.
Ursprünglich stand eine weitere Aufgabe im Pflichtenheft und zwar das Installieren und
Testen unseres Prototyps auf einem PDA. Nachdem wir unseren Prototyp GUI für
Notebook/Desktop entwickelt hatten, stellten wir fest, dass ein PDA für den Prototyp GUI aus
folgenden Überlegungen und Erkenntnis nicht mehr in Frage kommt:
•
Der jetzige Prototyp GUI hat seine minimale Layoutgrösse erreicht, um die Bedienbarkeit
gewährleisten zu können. Folglich ist diese Grösse für einen PDA ungeeignet.
•
Bei einer weiteren Entwicklung unseres Prototyps GUI für Berechnungsfunktionen im
Vermessungswesen wäre ein PDA nicht die geeignete Hardwarelösung in bezug auf
Benutzerfreundlichkeit,
Performanz
und
Speichergrösse
(lokale
Datenbank
eingeschränkt). Die beste Hardwarelösung bietet unseres Erachtens die neuen
kostengleichwertigen leichten Notebooks mit 10-Zollbildschirm, welche sich bei einem
Einsatz draussen bestens auszeichnen werden.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 216
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
10.2.1 Zielbestimmung
Muss Kriterien Client
Kriterium
Resultat
mit grafischer Benutzungsoberfläche
(Prototyp GUI) ausrüsten
Prototyp GUI wurde bei allen Client
installiert. Beim System III musste ein neuer
Prototyp GUI in C# realisiert werden.
-> Kriterium erfüllt
lokale Datenbank (Offline-Modus)
installieren
Jeder Client hat eine lokale Datenbank.
automatische und manuelle
Synchronisation
System I bietet beide Synchronisationsarten
an. Die zwei anderen Systeme besitzen nur
die manuelle Synchronisation.
-> Kriterium teilweise erfüllt
Muss Kriterien Middleware
Kriterium
Resultat
Bereitstellen von Eingangs- und
Ausgangswarteschlange
Systeme I und II haben Ein- und
Ausgangskanäle. Die Architektur des dritten
Systems benötigt keine Middleware.
Verbindung zur Hauptdatenbank
Middleware hat eine direkte Verbindung zur
Hauptdatenbank.
Verbindung zum Client
Middleware hat eine direkte Verbindung zur
lokalen Datenbank.
bidirektional
Alle bieten eine bidirektionale
Synchronisierungsrichtung an.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 217
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Muss Kriterien Datenbankserver
Kriterium
Resultat
Datenbanksoftware installieren
Die DBMS-Software wurde in allen
Systemen auf je einem Server installiert.
Hauptdatenbank mit Stammdaten
Die Stammdaten wurden erstellt und mit
eigenen Skripten in die Hauptdatenbank
eingespielt
Muss Kriterien Prototyp GUI
Kriterium
Resultat
Der Benutzer kann sich an der lokalen
Datenbank an- und abmelden
Der Benutzer kann sich sowohl an der
lokalen Datenbank wie auch an der
Hauptdatenbank anmelden. Er kann aber
keine Abmeldung durchführen. Die
Abmeldung erfolgt Code-mässig.
-> Kriterium grossteils erfüllt
Der Benutzer kann die Daten einsehen und
ändern
Der Benutzer kann die Manipulation sowohl
an der lokalen Datenbank wie auch an der
Hauptdatenbank durchführen.
Der Benutzer muss sich mit verschiedenen
DBMS mit Benutzername und Passwort
verbinden können.
Robustheit, Zuverlässigkeit, Korrektheit und
Benutzungsfreundlichkeit
-> Kriterien erfüllt
Kann Kriterien
Kriterium
Resultat
Softwareverteilung Prototyp GUI
Nur das erste System bietet eine Software
für unseren Prototyp GUI an.
-> Kriterium teilweise erfüllt
Heterogene Architektur
Systeme II und III unterstützen heterogene
Umgebung. System II basiert auf eine reine
heterogene Umgebung.
Eigene Synchronisationssoftware
Bei den Systemen II und III müssen
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 218
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
entwickeln
Synchronisierungs-Clients für unsere
Bedürfnisse entwickelt werden.
Direkte Verbindung und Datenmodifikation
auf der Back-End-Datenbank via Prototyp
GUI
System soll Verwaltungsaufgaben- und
Konfliktmanagement-Funktionen zur
Verfügung stellen
Systeme I und II stellen ein
Verwaltungswerkzeug zur Verfügung.
Zudem bietet System I ein
Konfliktmanagementwerkzeug.
Die Daten sollen tabellarisch auf dem GUI
angezeigt werden.
10.2.2 Produktumgebung
Muss Kriterien Software
Kriterium
Resultat
Betriebssystem Windows 2003 für
Datenbankserver und Middleware
Betriebssystem Windows XP für Client
Virtualisierung der Systeme mit VMware
Kann Kriterium Software
Kriterium
Resultat
Betriebssystem Linux für Datenbankserver,
Middleware und Client
-> Kriterium nicht erfüllt
Muss Kriterien Hardware
Kriterium
Resultat
Einsatz eines physischen und
leistungsstarken Rechners für die
Virtualisierung
Datenbank und Middleware auf derselben
Maschine installieren
Kann Kriterium Hardware
Kriterium
Resultat
Eigene Notebooks als Client benutzen
Die eigenen Notebooks mussten nicht
eingesetzt werden.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 219
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
10.3 Zukunftsaussicht
Während unserer Arbeit sind wir auf interessante Bereiche gestossen, die weiter verfolgt und
entwickelt werden könnten. Die nachfolgenden Unterkapitel sollen einen Einblick darüber
geben.
10.3.1 Allgemein
Bei allen Systemen vermissen wir, dass der Benutzer nicht über Synchronisierungskonflikte
benachrichtigt wird. Die Benachrichtigungsfunktion sollte in allen Produkten implementiert
werden.
Bei den Systemen II und III lohnt sich ein Konfliktmanagement zu entwickeln.
10.3.2 System I
Seit der Datenbankversion Oracle 10g erhält man von der Firma Oracle auch eine
kostenlose Express Edition. Um Kosten zu sparen, kann man diese Gratisversion als BackEnd-Datenbank einsetzen. Diese ist eine Alternative, die in unserem System umgesetzt
werden könnte.
Oracle Database Lite kann mit SSL-Verschlüsselung installiert werden. Wir konnten mit der
SSL-Verschlüsselung das Software-Paket gar nicht erstellen. Folglich haben wir das System
ohne Verschlüsselung neu aufgesetzt. Später fanden wir den Hinweis betreffend SSLVerschlüsselung und Paketisierung (siehe Kapitel 6.5.2). Dieser Tipp lohnt sich zu
überprüfen.
10.3.3 System II
Weitere Tätigkeiten wurden bereits im Kapitel 10.3.1 erwähnt.
10.3.4 System III
Es besteht die Möglichkeit unseren Synchronisierungs-Client zu erweitern, um die
Synchronisierung über Eingabeparameter von der Kommando-Zeile aus zu starten. Mit
dieser Erweiterung kann der Workaround für die automatische Synchronisierung realisiert
werden (wie bereits im Kapitel 8.9.3 erwähnt).
MS SQL Server 2008 bietet die Change Tracking-Funktion an. Mit Hilfe dieser Funktionalität
ist keine Anpassung des Datenbankschemas nötig. Wir empfehlen diesen Server
aufzusetzen, um die Change Tracking-Funktion auszutesten. Weiter empfehlen wir auch die
schwierige n-Tier-Architektur zu entwickeln und aufzubauen.
10.3.5 Prototyp GUI
Der Prototyp GUI diente zurzeit für Datenabfrage und -erfassung in den Datenbanken. Er soll
später für Berechnungsfunktionen im Vermessungswesen erweitert werden.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 220
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
10.4 Ehrlichkeitserklärung
Hiermit bestätigen wir, die vorliegende Master Thesis selbständig erarbeitet und geschrieben
zu haben.
Villmergen, den 31. März 2009
Angelo Lo Iudice
Isidoro Lo Iudice
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 221
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
11 Literaturverzeichnis
11.1 Literaturangaben für Bücher
•
Balzert, Heide (2005): Lehrbuch der Objektmodellierung, Analyse und Entwurf mit der
UML 2, Spektrum Akademischer Verlag, 2. Auflage
•
Balzert, Heide (2005): UML2 kompakt, mit Checklisten, Spektrum Akademischer Verlag,
2. Auflage
•
Krüger, Guido (2006): Handbuch der Java Programmierung, Addison-Wesley
•
Firma Infrasoft (2004): Anleitung zum Pflichtenheft
•
Tanner, Ronald (2008): Manuskript: Software Architecture .NET Framework, Version 1.0
11.2 Literaturangaben für Internetseiten
•
Wikipedia
•
I/O Compatibility Guide For ESX Server 3.5 and ESX Server 3i, vi35_io_guide.pdf,
VMware, Inc. 3401 Hillview Avenue Palo Alto, CA 94304 www.vmware.com, Last
Updated: 19. November 2008
•
ESX Server 3i Installable Setup Guide, vi3_35_25_u2_3i_i_setup.pdf, VMware, Inc. 3401
Hillview Avenue Palo Alto, CA 94304 www.vmware.com, Last Updated: 17. Oktober 2008
•
VMware Converter User’s Manual, VMware_Converter_manual302.pdf, Inc. 3401
Hillview Avenue Palo Alto, CA 94304 www.vmware.com, Version: 3.0.2, Last Updated:
18. Oktober 2007
•
Oracle Database Lite Administration and Deployment Guide 10g (10.3.0.2) E12089-01,
June 2008
•
Oracle Database Lite Getting Started Guide 10g (10.3.0.2) E12080-01, June 2008
•
Oracle Database Lite Developer's Guide 10g (10.3.0.2) E12090-01, June 2008
•
Funambol Data Synchronization Server Overview, Funambol 643 Bair Island Road, Suite
305 Redwood City, CA 94063 USA, www.funambol.com, 2006
•
Funambol Developer's Guide, Last revised: July 31, 2008, v1.0.8 (funambol-developersguide.pdf)
•
Funambol DS Server SyncSource API, Version 3.0, May 2006
(funambol_ds_server_syncsource_api.pdf)
•
Funambol DS Server, Administration Guide, Version 3.0, September 2006
(funambol_ds_server_administration_guide.pdf)
•
msdn.microsoft.com/en-us/sync/default.aspx
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 222
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
12 Glossar
ADO.NET
ADO steht für ActiveX Data Object und besteht aus einer Ansammlung von
Programmklassen, die den Zugriff auf relationalen Datenbanken
ermöglicht. Es ist heute Bestandteil des Microsoft .NET Framework 2.0.
ANT
Apache Ant (Ant englisch für Ameise) ist ein in Java geschriebenes
Werkzeug zum automatisierten Erzeugen von Programmen aus Quelltext.
API
API steht für Application Programming Interface (dt. Programmierschnittstelle) in der Informatik
C#
Ausgesprochen C Sharp ist eine objektorientierte Programmiersprache von
Microsoft. Sie ist eine Weiterentwicklung von den Programmiersprachen C
und C++.
DB
Datenbank enthält Informationsdaten
DBMS
Datenbankmanagementsystem von verschiedenen Herstellern
DS
Data Synchronization engl. für Datensynchronisierung
DSN
Der Data Source Name (DSN) ist eine Datenstruktur und beschreibt die
Zugangsdaten (ODBC, JDBC oder ADOdb), die ein Treiber benötigt, um
eine Verbindung zu einer bestimmten Datenbank herzustellen.
GIS
Das Geografische Informations-System kurz GIS befasst sich mit
raumbezogenen Daten. Es verwaltet geometrische und thematische Daten.
GUI
Grafisches User Interface ist eine grafische Benutzungsoberfläche.
GUID
Jedes Synchronisationselement erhält vom System eine eindeutige
Identifikationsbezeichnung (ID). Client und Server generieren ihre eigenen
IDs. Auf dem Server werden sie als Global Unique IDentifiers (GUID)
bezeichnet.
HTTP
Das Hypertext Transfer Protocol (HTTP, dt. HypertextÜbertragungsprotokoll) ist ein Protokoll zur Übertragung von Daten über ein
Netzwerk. Es wird hauptsächlich eingesetzt, um Webseiten und andere
Daten aus dem World Wide Web (WWW) in einen Webbrowser zu laden.
IDE
Integrated Development Environment (IDE, dt. „integrierte
Entwicklungsumgebung“) ist eine Software-Plattform zur Entwicklung von
Applikationen und besitzt integrierte Komponenten wie Texteditor, Compiler
beziehungsweise Interpreter, Debugger und
Quelltextformatierungsfunktion.
JAR
Ein Java Archive (kurz JAR) ist eine ZIP-Datei, die zusätzliche Metadaten
in einer Datei „META-INF/MANIFEST.MF“ enthalten kann. JARs werden
vor allem zur Verteilung von Java-Klassenbibliotheken und -Programmen
eingesetzt.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 223
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
JRE
Java Runtime Environment (kurz JRE) wird die Laufzeitumgebung für die
Java-Plattform des US-Unternehmens Sun Microsystems genannt. Diese
liefert unter anderem die Java Virtual Machine und wird benötigt, um JavaAnwendungen auszuführen.
LDAP
Das Lightweight Directory Access Protocol (LDAP) erlaubt die Abfrage und
die Modifikation von Informationen eines Verzeichnisdienstes
(hierarchische Datenbank).
LUID
Jedes Synchronisationselement erhält vom System eine eindeutige
Identifikationsbezeichnung (ID). Client und Server generieren ihre eigenen
IDs. Auf dem Client werden sie als Local Unique IDentifiers (LUID)
bezeichnet.
MGP
Message Generator and Processor ist für den bidirektionalen Datentransfer
zwischen dem Client System und dem Database Server zuständig.
Verarbeitung der IN-, OUT- und ERROR-Queue
MIME
Multipurpose Internet Mail Extensions (MIME) ist ein Kodierstandard, der
die Struktur und den Aufbau von E-Mails und anderen Internetnachrichten
festlegt. Ferner findet MIME Anwendung bei der Deklaration von Inhalten in
verschiedenen Internetprotokollen, so zum Beispiel in HTTP. MIME
ermöglicht die Übertragung von Daten in beliebigen Formaten.
MDK
Mobile Development Kit (MDK) ist die Entwicklungssoftware von Oracle
Database Lite. Sie beinhaltet folgende Komponente: Oracle Database Lite
RDBMS, Mobile Database Workbench (MDW), Packaging Wizard, Mobile
Sync (msync.exe) und Mobile SQL (= mSQL.exe, ein Werkzeug um die
Oracle Database Lite auf dem mobilen Gerät zu manipulieren)
MDW
Mobile Database Workbench (MDW) ist eine Applikation, um die Software
mit Oracle Database Lite zu veröffentlichen. Die publizierte Software wird in
Projekten gespeichert. Die Publikation auf dem Mobile Server erfolgt via
Packaging Wizard.
MSDN
Microsoft Developer Network ist die Informationsplattform im Internet für
Entwickler. Hier findet man jegliche Informationen, Beschreibungen und
Code-Beispiele für die Microsoft-Produkte.
OBEX
Das Object Exchange Protocol ist ein serielles Kommunikationsprotokoll
(Bluetooth, Infrarot oder auch Cradle) und dient der Datenübertragung
zwischen zwei Geräten. Es wird überwiegend bei mobilen Endgeräten wie
PDA, IPAQ, Smartphone eingesetzt.
ODBC
Open Database Connectivity ist eine standardisierte Schnittstelle für den
Zugriff auf relationale Datenbanksysteme
OOA
Objektorientierte Analyse, fachliche Lösung des zu realisierenden Systems
OOD
Objektorientiertes Design, technische Lösung des zu realisierenden
Systems
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 224
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
PIM
PIM steht für Personal Information Manager und ist eine Software, die
persönliche Daten wie Kontakte, Termine, Aufgaben, Notizen und E-Mails
verwaltet.
URI
Uniform Resource Identifier (URI, dt. „einheitlicher Bezeichner für
Ressourcen“) ist ein Identifikator und besteht aus einer Zeichenfolge, die
zur Identifizierung einer abstrakten oder physischen Ressource dient.
URL
Uniform Resource Locator (URL, dt. „einheitlicher Quellenanzeiger“) ist
eine Unterart von Uniform Resource Identifiern (URIs). URLs identifizieren
und lokalisieren eine Ressource über das verwendete Netzwerkprotokoll
(beispielsweise http oder ftp) und den Ort (engl. location) der Ressource in
Computernetzwerken.
XAMPP
XAMPP ist eine Ansammlung von Open Source-Software, welche
verschiedene Server (Apache Webserver, FTP-, FileZilla-, Mercury-Server),
MySQL Datenbank und Verwaltungsfunktionen bietet. Das X steht für
verschiedene Betriebssysteme (Microsoft Windows, Linux, Mac OS X,
Solaris und andere Unix-Varianten)
XML
XML steht für Extensible Markup Language (dt „erweiterbare
Auszeichnungssprache“) und ist eine Datenbeschreibungssprache zur
Darstellung hierarchisch strukturierter Daten in Form von Textdaten. XML
wird unter anderem für den Austausch von Daten zwischen
Computersystemen eingesetzt, speziell über das Internet.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 225
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
13 Anhang
13.1 Abbildungsverzeichnis
Abbildung 1: Systemkonzept Use Cases Diagramm.............................................................. 5
Abbildung 2: Use Cases Diagramm....................................................................................... 8
Abbildung 3: Benutzungsoberfläche .....................................................................................11
Abbildung 4: Testumgebung.................................................................................................12
Abbildung 5: OOA Klassendiagramm GUI-Schicht ...............................................................14
Abbildung 6: OOA Klassendiagramm Business-Schicht .......................................................15
Abbildung 7: OOA Klassendiagramm Datenbank-Schicht ....................................................16
Abbildung 8: OOA Sequenzdiagramm..................................................................................17
Abbildung 9: OOD Use Cases Diagramm.............................................................................18
Abbildung 10: OOD Klassenübersichts-Diagramm ...............................................................20
Abbildung 11: OOD Klasse ListGUI ......................................................................................21
Abbildung 12: OOD Klasse DialogLogin ...............................................................................22
Abbildung 13: OOD Klasse DialogLoeschen ........................................................................22
Abbildung 14: OOD Klasse DialogWarning...........................................................................22
Abbildung 15: OOD Klasse Point..........................................................................................23
Abbildung 16: OOD Klasse VermDb.....................................................................................24
Abbildung 17: OOD Sequenzdiagramm................................................................................25
Abbildung 18: Hauptfenster mit Beschreibung......................................................................26
Abbildung 19: Panel DBMS Auswahlbox ..............................................................................26
Abbildung 20: Panel Daten-Eingabefelder ............................................................................27
Abbildung 21: Panel Auslöser-Buttons .................................................................................27
Abbildung 22: Panel Daten-Anzeigetabelle...........................................................................27
Abbildung 23: Nebenfenster DialogLogin .............................................................................28
Abbildung 24: Nebenfenster DialogLoeschen.......................................................................28
Abbildung 25: Nebenfenster DialogWarning .........................................................................28
Abbildung 26: Strukturbaum des JRE...................................................................................29
Abbildung 27: Ablageort der DB-Treiber...............................................................................29
Abbildung 28: Netzplanübersicht der Test-Umgebung..........................................................34
Abbildung 29: Systemübersicht I der Test-Umgebung..........................................................37
Abbildung 30: Funktion der Synchronisation.........................................................................38
Abbildung 31: MGP-Status ...................................................................................................38
Abbildung 32: Synchronisationsprozess ...............................................................................39
Abbildung 33: Panel msync ..................................................................................................39
Abbildung 34: Sync Result Dialog ........................................................................................39
Abbildung 35: Panel Show Log.............................................................................................40
Abbildung 36: Synchronisationsoption ein- und ausschalten ................................................40
Abbildung 37: Synchronisationsereignisse ein- und ausschalten..........................................41
Abbildung 38: Startsituation in der Hauptdatenbank (Ausgangslage) ...................................45
Abbildung 39: Startsituation TestclientA (Ausgangslage)......................................................45
Abbildung 40: Startsituation TestclientB (Ausgangslage)......................................................46
Abbildung 41: Punkt einfügen TestclientA (Fall 1) ................................................................46
Abbildung 42: Neuer Punkt TestclientA (Fall 1) ....................................................................47
Abbildung 43: Start msync.exe bei TestclientA (Fall 1) .........................................................47
Abbildung 44: Situation in der Oracle Hauptdatenbank (Fall 1).............................................48
Abbildung 45: Start msync.exe bei TestclientB (Fall 1) .........................................................48
Abbildung 46: Neuer Punkt TestclientB (Fall 1) ....................................................................49
Abbildung 47: Punkt 3 modifizieren TestclientB (Fall 2) ........................................................49
Abbildung 48: Situation TestclientB (Fall 2) ..........................................................................50
Abbildung 49: Start msync.exe bei TestclientB (Fall 2) .........................................................50
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 226
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 51: Start msync.exe bei TestclientA (Fall 2) .........................................................51
Abbildung 52: Situation TestclientA (Fall 2) ..........................................................................52
Abbildung 53: Situation TestclientA (Fall 3) ..........................................................................52
Abbildung 54: Situation TestclientB (Fall 3) ..........................................................................53
Abbildung 56: Fehler-Queue-Datensätze bearbeiten (Fall 3)................................................54
Abbildung 57: Fehler-Queue-Datensatz-Detail (Fall 3) .........................................................54
Abbildung 58: Fehler-Queue-Transaktion (Fall 3) .................................................................54
Abbildung 59: Refresh-Situation TestclientA (Fall 3).............................................................55
Abbildung 60: Startsituation TestclientA (Fall 4) ...................................................................56
Abbildung 61: Endsituation TestclientA (Fall 4) ....................................................................56
Abbildung 63: Out Queue-Publikationen...............................................................................57
Abbildung 64: Out Queue-Detailinformation (Fall 4) .............................................................58
Abbildung 65: Startsituation TestclientB (Fall 4) ...................................................................58
Abbildung 66: Punkt 3 modifizieren TestclientB (Fall 4) ........................................................59
Abbildung 67: Endsituation TestclientB (Fall 4) ....................................................................59
Abbildung 69: Fehler-Queue Info (Fall 4)..............................................................................60
Abbildung 70: Fehler-Queue-Datensatz-Detail (Fall 4) .........................................................60
Abbildung 71: Fehler-Queue-Datensatz „Einfügen“ (Fall 4) ..................................................61
Abbildung 72: In Queue Info (Fall 4) .....................................................................................61
Abbildung 73: Verbindung mit der Oracle Hauptdatenbank (Fall 5) ......................................62
Abbildung 74: Punkt 3 in der Oracle Hauptdatenbank löschen (Fall 5) .................................62
Abbildung 75: Situationen TestclientA & B (Fall 5)................................................................63
Abbildung 76: Verbindung mit der Oracle Hauptdatenbank (Fall 6) ......................................63
Abbildung 77: Punkt 6 in der Oracle Hauptdatenbank modifizieren (Fall 6) ..........................64
Abbildung 79: Situationen TestclientA & B (Fall 6)................................................................65
Abbildung 81: Situationen TestclientA und TestclientB (Fall 7) .............................................66
Abbildung 82: Punkte 6 und 7 einfügen TestclientA (Fall 7)..................................................67
Abbildung 83: Punkte 8 und 9 einfügen TestclientB (Fall 7)..................................................67
Abbildung 84: Situation in der In Queue (Fall 7) ...................................................................68
Abbildung 86: Situation in der Out Queue für TestclientB (Fall 7) .........................................69
Abbildung 87: Situation in der Out Queue für TestclientA (Fall 7) .........................................69
Abbildung 88: Refresh-Situation TestclientA (Fall 7).............................................................70
Abbildung 89: Refresh-Situation TestclientB (Fall 7).............................................................70
Abbildung 90: Systemübersicht II der Test-Umgebung .........................................................73
Abbildung 91: SyncML Technologie .....................................................................................74
Abbildung 92: SyncML Protokoll...........................................................................................75
Abbildung 93: Funambol DS Server Architektur....................................................................76
Abbildung 94: XAMPP Control-GUI Panel ............................................................................77
Abbildung 95: XAMPP phpMyAdmin Tool ............................................................................78
Abbildung 96: XAMPP Create new database Ausschnitt ......................................................78
Abbildung 97: Kommando-Konsole create database vermdb ...............................................78
Abbildung 98: XAMPP phpMyAdmin SQL query ..................................................................79
Abbildung 99: Kommando-Konsole create table tabkoord ....................................................79
Abbildung 100: Funambol DS Server starten und stoppen ...................................................80
Abbildung 101: Funambol Administration Tool GUI ..............................................................82
Abbildung 102: Anmelden an Funambol Administration Tool................................................82
Abbildung 103: Anmeldepanel Funambol Administration Tool ..............................................83
Abbildung 104: Administration Tool - Search Users..............................................................83
Abbildung 105: Administration Tool - Add User ....................................................................84
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 227
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 106: Add User mit selektierter Rolle.....................................................................85
Abbildung 107: Administration Tool - Search Devices ..........................................................86
Abbildung 108: Administration Tool - Search Principals........................................................87
Abbildung 109: Administration Tool - Add Principals ............................................................87
Abbildung 110: Selektierter Benutzer und Gerät...................................................................88
Abbildung 111: Neuer Principal hinzugefügt .........................................................................88
Abbildung 112: Administration Tool - Last Synchronization Timestamps ..............................89
Abbildung 113: Administration Tool - Add SyncSource.........................................................90
Abbildung 114: Administration Tool - Edit My SyncSource ...................................................90
Abbildung 115: Selektiere SyncSource.................................................................................91
Abbildung 116: Speichern der Anpassung............................................................................91
Abbildung 117: Phase Vorbereitung (Preparation)................................................................93
Abbildung 118: Projektstruktur acmeconnector ....................................................................95
Abbildung 119: Klasse SyncSource << interface >> .............................................................97
Abbildung 120: Klasse SyncItem << interface >> .................................................................99
Abbildung 121: Panel Funambol Administration Tool .........................................................103
Abbildung 122: hierarchische Modulstruktur des Connectors .............................................104
Abbildung 123: Projektstruktur VermSyncClient .................................................................107
Abbildung 124: Startsituation in der MySQL Hauptdatenbank ............................................112
Abbildung 125: Verwaltungs-Tool HSQL Database Manager (runManager) .......................113
Abbildung 126: Startsituation TestclientC (Ausgangslage) .................................................113
Abbildung 127: Startsituation TestclientD (Ausgangslage) .................................................114
Abbildung 128: Punkt einfügen TestclientC (Fall 1) ............................................................114
Abbildung 129: Neuer Punkt TestclientC (Fall 1) ................................................................115
Abbildung 130: Situation in der MySQL Hauptdatenbank (Fall 1) .......................................115
Abbildung 131: Neuer Punkt TestclientD (Fall 1) ................................................................116
Abbildung 132: Punkt 3 modifizieren TestclientD (Fall 2)....................................................117
Abbildung 133: Situation TestclientD (Fall 2) ......................................................................117
Abbildung 135: Situation TestclientC (Fall 2) ......................................................................118
Abbildung 136: Situation TestclientC (Fall 3) ......................................................................119
Abbildung 137: Situation TestclientD (Fall 3) ......................................................................120
Abbildung 139: Refresh-Situation TestclientC (Fall 3) ........................................................121
Abbildung 140: Unveränderte Situation TestclientD (Fall 3)................................................122
Abbildung 141: Zeitlicher Ablauf der Synchronisation (Fall 3) .............................................123
Abbildung 142: Startsituation TestclientC (Fall 4) ...............................................................126
Abbildung 143: Endsituation TestclientC (Fall 4) ................................................................126
Abbildung 144: Startsituation TestclientD (Fall 4) ...............................................................127
Abbildung 145: Punkt 3 modifizieren TestclientD (Fall 4)....................................................127
Abbildung 146: Endsituation TestclientD Fall 4...................................................................128
Abbildung 148: Unveränderte Situation TestclientC (Fall 4)................................................129
Abbildung 149: Neue Situation TestclientC (Fall 4).............................................................129
Abbildung 150: Update-Statement auf Kommandokonsole (Fall 5).....................................130
Abbildung 152: Situationen TestclientC & D (Fall 5) ...........................................................131
Abbildung 153: Neue Status-Situation auf den Clients (Fall 5)............................................131
Abbildung 154: Update-Statement auf Kommandokonsole (Fall 6).....................................132
Abbildung 156: Startsituationen TestclientC & D (Fall 6) ....................................................132
Abbildung 157: Endsituationen TestclientC & D (Fall 6)......................................................133
Abbildung 158: Neue Status-Situation auf den Clients (Fall 6)............................................133
Abbildung 160: Situationen TestclientC & D (Fall 7) ...........................................................135
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 228
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 161: Punkte 6 und 7 einfügen TestclientC (Fall7) ..............................................136
Abbildung 162: Punkte 8 und 9 einfügen TestclientD (Fall 7)..............................................136
Abbildung 163: Situation in der MySQL Hauptdatenbank nach D (Fall 7) ...........................137
Abbildung 164: Situation in der MySQL Hauptdatenbank nach C (Fall 7) ...........................137
Abbildung 165: Refresh-Situation TestclientC (Fall 7) ........................................................138
Abbildung 166: Situation TestclientC mit runManager betrachten (Fall 7)...........................138
Abbildung 167: Unveränderte Situation TestclientD (Fall 7)................................................139
Abbildung 168: Refresh-Situation TestclientD (Fall 7) ........................................................140
Abbildung 169: Situation TestclientD mit runManager betrachten (Fall 7)...........................140
Abbildung 170: Systemübersicht III der Test-Umgebung ....................................................142
Abbildung 171: Die Struktur des .NET Frameworks............................................................143
Abbildung 172: ADO.NET Architektur.................................................................................143
Abbildung 173: Übersicht Zusammenarbeitsszenario (collaboration)..................................146
Abbildung 174: Übersicht Offlineszenario (offline access) ..................................................146
Abbildung 175: 2-Ebene-Architektur mit Client- und Back-End-Datenbank.........................147
Abbildung 176: Clientstrukturverzeichnis „Survey“..............................................................151
Abbildung 177: Projekt „Survey“ anlegen ...........................................................................152
Abbildung 178: Projektstrukturerweiterung .........................................................................153
Abbildung 179: Synchronisierungs-Provider „VermServerSyncProvider“ ............................153
Abbildung 180: Projektstruktur „Survey“ und „VermServerSyncProvider“ ...........................154
Abbildung 181: Bibliotheken anlegen..................................................................................154
Abbildung 182: Bibliotheksfenster „Add Reference“............................................................155
Abbildung 183: Alle Bibliotheken „Survey“ ..........................................................................155
Abbildung 184: Alle Bibliotheken „VermServerSyncProvider“ .............................................155
Abbildung 185: Elemente anlegen......................................................................................156
Abbildung 186: Projektabhängigkeit festlegen ....................................................................156
Abbildung 187: Klassendiagramm ......................................................................................157
Abbildung 188: Klasse Settings ..........................................................................................158
Abbildung 189: Einstellungen im Teilprojekt .......................................................................158
Abbildung 190: Klasse Program .........................................................................................159
Abbildung 191: Klasse MainForm.......................................................................................159
Abbildung 192: Funktion New Item… (1) ............................................................................160
Abbildung 193: Erstellen der Klasse MainForm ..................................................................160
Abbildung 194: Klasse VermSyncAgent .............................................................................161
Abbildung 195: Klasse VermSyncDbDataSet .....................................................................162
Abbildung 196: Funktion New Item… (2) ............................................................................163
Abbildung 197: Erstellen der Klasse VermSyncDbDataSet ................................................163
Abbildung 198: TableAdapter erstellen...............................................................................164
Abbildung 199: TableAdapter Configuration Wizard ...........................................................164
Abbildung 200: TableAdapter tabkoord & local_tabkoord ...................................................165
Abbildung 201: Klasse TableAdapterManager....................................................................165
Abbildung 202: Klasse tabkoordTableAdapter....................................................................166
Abbildung 203: tabkoordTableAdapter ...............................................................................166
Abbildung 204: Eigenschaften des tabkoordTableAdapters................................................167
Abbildung 205: Klasse local_tabkoordTableAdapter...........................................................168
Abbildung 206: local_tabkoordTableAdapter ......................................................................168
Abbildung 207: Eigenschaften des local_tabkoordTableAdapters ......................................169
Abbildung 208: Klasse VermServerSyncProvider ...............................................................169
Abbildung 209: Programm mit Beschreibung......................................................................171
Abbildung 210: Startsituation in der MSSQL Hauptdatenbank (Ausgangslage) ..................173
Abbildung 211: Startsituation TestclientE (Ausgangslage)..................................................174
Abbildung 212: Startsituation TestclientE (Ausgangslage)..................................................174
Abbildung 213: Icon „Add new“...........................................................................................175
Abbildung 214: Punkt einfügen TestclientE (Fall 1) ............................................................175
Abbildung 215: Icon „Save“ (Fall 1) ....................................................................................175
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 229
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 216: Synchronisation auslösen TestclientE (Fall 1)............................................175
Abbildung 217: Situation in der MSSQL Hauptdatenbank (Fall 1).......................................176
Abbildung 219: Neuer Punkt TestclientF ............................................................................176
Abbildung 220: Punkt 3 modifizieren TestclientF (Fall 2) ....................................................177
Abbildung 221: Icon „Save“ (Fall 2) ....................................................................................177
Abbildung 222: Synchronisation auslösen TestclientF (Fall 2) ............................................177
Abbildung 225: Situation TestclientE (Fall 2) ......................................................................178
Abbildung 227: Situation TestclientF (Fall 3) ......................................................................179
Abbildung 228: Synchronisation gleichzeitig auslösen TestclientE & F (Fall 3)...................179
Abbildung 230: Situation TestclientF nach der Synchronisation (Fall 3)..............................180
Abbildung 231: Situation in der Tombstone-Tabelle (Fall 3) ...............................................181
Abbildung 232: Startsituation TestclientE (Fall 4) ...............................................................181
Abbildung 234: Situation in der MSSQL Hauptdatenbank Fall 4 .........................................182
Abbildung 235: Situation in der Tombstone-Tabelle (Fall 4) ...............................................182
Abbildung 236: Punkt 3 modifizieren TestclientF (Fall 4) ....................................................183
Abbildung 237: Synchronisation auslösen TestclientF (Fall 4) ............................................183
Abbildung 238: Endsituation TestclientF (Fall 4).................................................................183
Abbildung 241: Synchronisation auf beide TestclientE & F auslösen (Fall 5)......................184
Abbildung 242: Situationen TestclientE (Fall 5) ..................................................................185
Abbildung 243: Situationen TestclientF (Fall 5) ..................................................................185
Abbildung 246: Situationen TestclientE (Fall 6) ..................................................................187
Abbildung 247: Situationen TestclientF (Fall 6) ..................................................................187
Abbildung 249: Lokale DB auf beide TestclientE & F löschen (Fall 7).................................188
Abbildung 253: Punkte 6 und 7 einfügen TestclientE (Fall7)...............................................190
Abbildung 254: Punkte 8 und 9 einfügen TestclientF (Fall 7) ..............................................191
Abbildung 255: Synchronisation auf TestclientF auslösen (Fall 7) ......................................191
Abbildung 256: Situation in der MSSQL Hauptdatenbank nach F (Fall 7) ...........................191
Abbildung 257: Synchronisation auf TestclientE auslösen (Fall 7)......................................191
Abbildung 258: Situation in der MSSQL Hauptdatenbank nach E (Fall 7)...........................192
Abbildung 259: Situation TestclientE nach Synchronisation Fall 7......................................192
Abbildung 261: Synchronisation auf TestclientF auslösen (Fall 7) ......................................193
Abbildung 262: Situation TestclientF nach Synchronisation (Fall 7)....................................193
Abbildung 263: Attribute in MS-Access...............................................................................195
Abbildung 264: Spaltenbeschreibung in MS-Access...........................................................195
Abbildung 265: Stammdaten in MS-Access........................................................................196
Abbildung 266: ODBC-Einstellung Microsoft für MS-Access ..............................................196
Abbildung 267: Benutzer mit Zugriff in MySQL ...................................................................197
Abbildung 268: Tabellenbestand in MySQL........................................................................197
Abbildung 269: Stammdaten in MySQL..............................................................................197
Abbildung 270: Spaltenbeschreibung in MySQL.................................................................197
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 230
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Abbildung 271: hsqldb-Verzeichnisstruktur.........................................................................199
Abbildung 272: HSQLDB Server gestartet..........................................................................199
Abbildung 273: Anmeldepanel HSQLDB Manager .............................................................200
Abbildung 274: Verwaltungspanel HSQLDB.......................................................................200
Abbildung 275: Strukturbeschreibung in HSQLDB..............................................................201
Abbildung 276: Stammdaten in HSQLDB ...........................................................................202
Abbildung 277: Stammdaten in Oracle ...............................................................................202
Abbildung 278: Spaltenbeschreibung in Oracle ..................................................................202
Abbildung 279: ODBC-Schnittstelle von Oracle Lite ...........................................................203
Abbildung 280: ODBC-Konfigurationseinstellung................................................................204
Abbildung 281: Stammdaten in Oracle Lite DB via msql anzeigen.....................................204
Abbildung 282: Tabellenstruktur in Oracle Lite DB via msql anzeigen ................................204
Abbildung 283: Tabellenstruktur „tabkoord“ in MSSQL.......................................................205
Abbildung 284: Tabellenstruktur „tabkoord_tombstone“ in MSSQL ....................................206
Abbildung 285: Trigger „tabkoord_DeleteTrigger“ in MSSQL..............................................206
Abbildung 286: Ausgangslage (Beispiel) ............................................................................207
Abbildung 287: Punktnummer ändern (Beispiel).................................................................208
Abbildung 288: Endstand (Beispiel)....................................................................................208
Abbildung 289: Trigger „tabkoord_UpdateTrigger“..............................................................209
Abbildung 290: Stored Procedures in MSSQL....................................................................209
Abbildung 291: Ablageverzeichnis der lokalen Datenbankdatei „localvermdb.sdf“..............211
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 231
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
13.2 Projektplan
Die Arbeit dauerte vom 22. September 2008 bis 31. März 2009. Weitere Informationen sind
vom Plan zu entnehmen. Der Plan ist ebenfalls elektronisch auf der DVD beigelegt.
Legende
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 232
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 233
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 234
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 235
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
13.3 Arbeitsjournal Angelo Lo Iudice
Datum
Wochentag
24.09.2008 Mittwoch
Aufwand [h]
1.5
Tätigkeit
Task
- Kickoff-Sitzung mit B. Wyss
Termine:
Kickoff-Sitzung mit
Examinator
29.09.2008 Montag
1
- Newsletter Fokus Report durchlesen
Allgemein:
Literartur beschaffen und
studieren
02.10.2008 Donnerstag
2
- Rechner auswählen
Systemrealisierung:
- Rechner beschaffen
03.10.2008 Freitag
1
- Rechner auswählen / bestellen
Systemrealisierung:
- leistungsstarker Rechner
beschaffen
06.10.2008 Montag
8.5
- Dokumentationsbeschaffung 1.
Systems
- Einarbeitung & Duchlesen von
Oracle Database Lite
- Software beschaffen (Oracle)
Systemevaluation:
- System I
Systemrealisierung:
- Software (VMware,
Oracle) beschaffen
10.10.2008 Freitag
10
- Neuer Rechner zusammengesetzt
- Windows 2003 Server installiert
(Host)
- VMware installiert
- Virtuelle Maschinen erstellt
Systemevaluation:
- System I
Systemrealisierung:
- Rechner aufsetzen
13.10.2008 Montag
8.5
- Oracle 10g (10.2.0.3) installiert
- Konfigurieren von Oracle (TNSListener)
- Skripte zur Erstellung der
Hauptdatenbank geschrieben
- Hauptdatenbank "vermdb" erstellt
Systemevaluation:
- System I
Systemrealisierung:
- Rechner aufsetzen
17.10.2008 Freitag
5
- Oracle Datebase Lite installiert
- Oracle Datebase Lite konfigurieren
Systemevaluation:
- System I
Systemrealisierung:
- Rechner aufsetzen
20.10.2008 Montag
8.5
- Oracle Datebase Lite konfigurieren
- Erste Erfahrung mit Demo-Daten
gesammelt
- Problem mit Performance der
virtuellen Maschinen
- Rechner auswählen
Systemevaluation:
- System I
Systemrealisierung:
- Rechner aufsetzen
22.10.2008 Dienstag
1
- Rechner auswählen / bestellen
Systemrealisierung:
- Rechner aufsetzen
24.10.2008 Freitag
4
- Mobile Server & Mobile Database
Workbench
Systemevaluation:
- System I
26.10.2008 Sonntag
4
- Optimierung & Troubleshooting
Prototyp GUI:
- DB + Business + GUI
Klassen
27.10.2008 Montag
9.5
- Oracle / Wissentransfer
- Sitzungsvorbereitung
- 1. Sitzung mit B. Wyss
Systemevaluation:
- System I
Termine:
- Sitzung mit Examinator
Dokumentation:
- Pflichtenheft erstellen
2
31.10.2008 Freitag
7
- Pflichtenheft erstellen und bereinigen Dokumentation:
- Erste erfahrung mit Oracle Datase
Pflichtenheft erstellen
Lite Client
Systemevaluation:
- System I
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 236
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
03.11.2008 Montag
7
- Einarbeiten beim Erstellen von JARFile
- Oracle Datase Lite Client
- Packaging & Deploy (Trouble!)
Systemevaluation:
- System I
07.11.2008 Freitag
4
- Oracle Datase Lite Client
- Packaging & Deploy (Trouble!)
Systemevaluation:
- System I
10.11.2008 Montag
10
- Neuer Rechner zusammengesetzt
- ESX3i Update 2 installiert &
Konfiguriert (Host)
- Kennenlernen des neuen Systems
- Oracle 10g & Oracle Database Lite
(ohne SSL) installiert
- Screenshots für Dokumentation
Systemevaluation:
- System I
Systemrealisierung:
- Rechner aufsetzen
11.11.2008 Dienstag
1
- Packaging & Deploy (Erforlgreich!)
Systemevaluation:
- System I
2
- Einarbeitung in VMware Converter
- Virtuelle Maschinen von vorherigen
Rechner migriert (konvertiert)
Systemevaluation:
- System I
14.11.2008 Freitag
5
- Client Oracle Lite DB aufsetzen
- Synchronisation unseres Prototyps
mit 2 Client testen (-> Trouble mit
Daten-Refresh &
Datensynchronisation via GUI)
Systemevaluation:
- System I
Systemtest:
- Testszenarien
16.11.2008 Sonntag
3
- Zeitplan erstellen
Dokumentation:
17.11.2008 Montag
8.5
mit 2 Client testen (-> Problem gelöst;
Autocommit im URL)
- Testszenarien dokumentiert
Systemtest:
- Testszenarien
21.11.2008 Freitag
8.5
- Dokumentation der Testumgebung
Systemtest:
- Testfälle erstellen
Dokumentation:
- Bericht schreiben
23.11.2008 Sonntag
4
- Dokumentation der Testumgebung
Dokumentation:
- Bericht schreiben
24.11.2008 Montag
10
- Dokumentation des Systemes I
- Zusatz-Doku: Installation Win2K3
erstellt
Dokumentation:
- Bericht schreiben
28.11.2008 Freitag
7
- Dokumentation des Systemes I
- Einarbeiten im System II
Dokumentation:
- Bericht schreiben
Systemevaluation:
- System II
01.12.2008 Montag
7
Systemevaluation:
- System II
05.12.2008 Freitag
7
- Umsetzung des System II
(Funambol) -> Funambol, XAMPP
- Konfiguration: Zugriff auf MySQL
- Tests
Systemevaluation:
- System II
07.12.2008 Sonntag
6
- Doku: funambol-v7-developersguide.pdf
- Aufsetzen der
Entwicklungsumgebung
- Maven Projekt -> s4j-File erstellt
Systemevaluation:
- System II
08.12.2008 Montag
8.5
- Doku: funambol-v7-developersguide.pdf
- Aufsetzen der
Entwicklungsumgebung
- Maven Projekt -> s4j-File erstellt
Systemevaluation:
- System II
Termine:
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 237
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
12.12.2008 Freitag
7.5
- Eigener Connector "vermconnector"
Systemevaluation:
- System II
13.12.2008 Samstag
3.5
Systemevaluation:
- System II
14.12.2008 Sonntag
6.5
- Doku: Kapitel "Pflichtenheft"
bereinigen und ergänzt
Systemevaluation:
- System II
Dokumentation:
15.12.2008 Montag
7
Systemevaluation:
- System II
19.12.2008 Freitag
7
- Wissenstransfer
Systemevaluation:
- System II
21.12.2008 Sonntag
4
- Einarbeiten in HSQL
Systemevaluation:
- System II
22.12.2008 Montag
7.5
- Wissenstransfer
- Testclient C aufgesetzt (HSQLDB +
testsyncclient)
- Eigener Sync Client
Systemevaluation:
- System II
23.12.2008 Dienstag
8
Systemevaluation:
- System II
24.12.2008 Mittwoch
7
Systemevaluation:
- System II
26.12.2008 Freitag
7
Systemevaluation:
- System II
27.12.2008 Samstag
7
Systemevaluation:
- System II
28.12.2008 Sonntag
6
- Troubleshooting
Systemevaluation:
- System II
29.12.2008 Montag
7.5
- Troubleshooting
Systemevaluation:
- System II
30.12.2008 Dienstag
7
- Troubleshooting
Systemevaluation:
- System II
31.12.2008 Mittwoch
7
- Dokumentation des Systemes II
Dokumentation:
- Bericht schreiben
02.01.2009 Freitag
7
Dokumentation:
- Bericht schreiben
04.01.2009 Sonntag
7
Dokumentation:
- Bericht schreiben
05.01.2009 Montag
5
- Wissenstransfer
Dokumentation:
- Bericht schreiben
2.5
- Wissenstransfer
Dokumentation:
- Bericht schreiben
09.01.2009 Freitag
8.5
- Test-Umgebung -> Big Trouble
Dokumentation:
- Bericht schreiben
Testfälle durchführen
11.01.2009 Sonntag
5.5
beheben
Dokumentation:
- Bericht schreiben
12.01.2009 Montag
8
Dokumentation:
- Bericht schreiben
Termine:
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 238
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
13.01.2009 Dienstag
1
Dokumentation:
- Bericht schreiben
16.01.2009 Freitag
5
Dokumentation:
- Bericht schreiben
18.01.2009 Sonntag
3
Dokumentation:
- Bericht schreiben
19.01.2009 Montag
8
(Testsystem I + II)
Dokumentation:
- Bericht schreiben
2.5
(Testsystem II)
Dokumentation:
- Bericht schreiben
23.01.2009 Freitag
5.5
- Einarbeiten im System III (-> MS
Synchronization Services for
ADO.NET)
Systemevaluation:
- System III
25.01.2009 Sonntag
2
(Testsystem I)
Dokumentation:
- Bericht schreiben
26.01.2009 Montag
10
ADO.NET)
Systemevaluation:
- System III
28.01.2009 Mittwoch
2.5
ADO.NET)
Systemevaluation:
- System III
1
ADO.NET)
Systemevaluation:
- System III
30.01.2009 Freitag
7
ADO.NET)
ohne SqlCe
Systemevaluation:
- System III
01.02.2009 Sonntag
4.5
ADO.NET)
ohne SqlCe
Systemevaluation:
- System III
02.02.2009 Montag
7
ADO.NET)
ohne SqlCe
Systemevaluation:
- System III
06.02.2009 Freitag
10.5
- Eigener Sync mit Client Feature
Systemevaluation:
- System III
08.02.2009 Sonntag
5.5
Systemevaluation:
- System III
09.02.2009 Montag
8.5
- Aufbau der Testumgebung
Systemevaluation:
- System III
13.02.2009 Freitag
6
- Aufbau der Testumgebung
- Dokumentation des Systemes III
Systemevaluation:
- System III
Dokumentation:
- Bericht schreiben
14.02.2009 Samstag
1
Dokumentation:
- Bericht schreiben
15.02.2009 Sonntag
7
Dokumentation:
- Bericht schreiben
16.02.2009 Montag
4
Dokumentation:
- Bericht schreiben
17.02.2009 Dienstag
1
Systemevaluation:
- System III
18.02.2009 Mittwoch
2
Systemevaluation:
- System III
22.02.2009 Sonntag
5
Dokumentation:
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 239
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
- Bericht schreiben
23.02.2009 Montag
7
Dokumentation:
- Bericht schreiben
27.02.2009 Freitag
5.5
Systemevaluation:
- System III
Dokumentation:
- Bericht schreiben
01.03.2009 Sonntag
5
Dokumentation:
- Bericht schreiben
02.03.2009 Montag
7
Dokumentation:
- Bericht schreiben
06.03.2009 Freitag
4
- Dokumentation Bericht
Dokumentation:
- Bericht schreiben
08.03.2009 Sonntag
5.5
Dokumentation:
- Bericht schreiben
09.03.2009 Montag
9
Dokumentation:
- Bericht schreiben
Termine:
13.03.2009 Freitag
7
Dokumentation:
- Bericht schreiben
15.03.2009 Sonntag
6
Dokumentation:
- Bericht schreiben
16.03.2009 Montag
9.5
Dokumentation:
- Bericht schreiben
5.5
Dokumentation:
- Bericht schreiben
20.03.2009 Freitag
3.5
Dokumentation:
- Bericht schreiben
22.03.2009 Sonntag
4
Dokumentation:
- Bericht schreiben
23.03.2009 Montag
6.5
Dokumentation:
- Bericht schreiben
25.03.2009 Mittwoch
2.5
Dokumentation:
- Bericht schreiben
8.5
Dokumentation:
- Bericht schreiben
7
Dokumentation:
- Bericht schreiben
27.03.2009 Freitag
Total
527.5
13.4 Arbeitsjournal Isidoro Lo Iudice
Datum
Wochentag
24.09.2008 Mittwoch
Aufwand [h]
0
Tätigkeit
Task
- Kickoff-Sitzung aus gesundheitlichen Termine:
Gründen abwesend
Kickoff-Sitzung mit
Examinator
29.09.2008 Montag
0.5
- Newsletter Fokus Report durchlesen
Allgemein:
Literartur beschaffen und
studieren
06.10.2008 Montag
8.5
- Softwarearchitektur DB, Business,
GUI skizzenmässig festlegen
(Brainstorming)
- Programmierung GUI-Prototyp
Allgemein:
Prototyp GUI: Business
Klasse
- Programmierung Business
07.10.2008 Dienstag
1
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 240
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Klasse
08.10.2008 Mittwoch
1
- Programmierung Business
Klasse
11.10.2008 Samstag
8.5
- Programmierung Business und DB
Prototyp GUI: Business +
DB Klasse
13.10.2008 Montag
8.5
- Programmierung Business und DB
- Access-Datenbank erstellen
- JDBC-Treiber installieren
- Access in DB-Programm verbinden
und Zugriff testen
DB Klasse
18.10.2008 Samstag
8.5
- Programmierung GUI
- ListGUI
- Einbau Observer: Business, GUI
- Access Zugriff testen, Update testen
Prototyp GUI: GUI
Klassen
19.10.2008 Sonntag
8.5
Prototyp GUI: GUI
Klassen
- Dialog Loeschen
- ListGUI (ComboBox implementieren)
20.10.2008 Montag
8.5
- ListGUI
- Einbau Observer: Business, GUI
- Access Zugriff testen, Update testen
GUI Klassen
21.10.2008 Dienstag
1
- Dialog Warning
Prototyp GUI: GUI
Klassen
22.10.2008 Mittwoch
1
- DialogLogin
Prototyp GUI: GUI
Klassen
1
- DialogLogin
Prototyp GUI: GUI
Klassen
24.10.2008 Freitag
0.5
- DialogLogin
Prototyp GUI: GUI
Klassen
25.10.2008 Samstag
8.5
- MySQL Datenbank erstellen (xampp) Prototyp GUI: GUI
Klassen
- MySQL Zugriff testen, Testuser
definieren
27.10.2008 Montag
28.10.2008 Dienstag
9
1.5
- Oracle / Wissenstransfer
Termine:
Sitzung mit Examinator
- Dokumentenvorlage erstellen
Dokumentation:
Dokumentation:
2
31.10.2008 Freitag
3
- Pflichtenheft erstellen und bereinigen Dokumentation:
01.11.2008 Samstag
2
- Protokoll erstellen
Dokumentation:
Protokolle schreiben
03.11.2008 Montag
6
- Klassendiagramm erstellen
- jar vom GUI-Prototyp erstellen und
testen
- Protokoll und Pflichtenheft an
Teilnehmer versenden
Prototyp GUI: OOA
Klassendiagramm
Testen
14.11.2008 Freitag
8
- Client Oracle DB Lite aufsetzen
mit zwei Client testen
(-> Trouble mit Daten-Refresh &
Datensynchronisation via GUI)
Systemevaluation: System
I
Systemtest: Testfälle
erstellen
15.11.2008 Samstag
2
- Ergänzungen
Prototyp GUI: GUI,
Business + DB
16.11.2008 Sonntag
6
Dokumentation:
Zeitplan erstellen
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 241
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
17.11.2008 Montag
6
(-> Problem gelöst, Autocommit im
URL)
- Implementation KeyListener und
Refresh-Button
erstellen
Prototyp GUI: GUI
Klassen
19.11.2008 Mittwoch
8
- Dokumentenerstellung
- OOA
Dokumentation:
Bericht schreiben
8
- OOA und OOD
Dokumentation:
Bericht schreiben
21.11.2008 Freitag
8
- Oracle DB Lite Synchronisation mit
zwei Client testen
erstellen, Testphase
22.11.2008 Samstag
3
- OOD
Dokumentation:
Bericht schreiben
24.11.2008 Montag
8
- Pflichtenheft, OOA mit Bilder im
Hauptdokument implementieren
Dokumentation:
Bericht schreiben
25.11.2008 Dienstag
4
- OOD mit Bilder im Hauptdokument
implementieren
Dokumentation:
Bericht schreiben
26.11.2008 Mittwoch
8
- Systemevaluationskonzept erstellen
Dokumentation:
Bericht schreiben
28.11.2008 Freitag
8
- Test-Umgebung Doku im
Hauptdokument einbinden, ergänzen
Dokumentation:
Bericht schreiben
01.12.2008 Montag
6
- Zeitplan, Arbeitsjournale und
Traktandenliste versenden
Systemevaluation:
System II
07.12.2008 Sonntag
4
- Doku: funambol-v7-developersSystemevaluation:
System II
guide.pdf
- Problem Maven Projekt -> Lösungen
im Internet suchen (alte DokuVersion)
08.12.2008 Montag
3
Termine:
Sitzung mit Examinator
13.12.2008 Samstag
2
Dokumentation:
14.12.2008 Sonntag
7
- Doku: Kapitel "Pflichtenheft"
bereinigen und ergänzt
Dokumentation:
19.12.2008 Freitag
5
- Wissenstransfer "vermconnector"
- Einarbeiten in HSQLDB
Systemevaluation:
System II
22.12.2008 Montag
7
- Wissenstransfer
- Testclient C aufgesetzt (HSQLDB +
testsyncclient) -> Fehleranalyse
Systemevaluation:
System II
27.12.2008 Samstag
8
Systemevaluation:
System II
29.12.2008 Montag
8.5
- Doku: System II beschreiben
Fehleranalyse
II
Dokumentation: Bericht
schreiben
30.12.2008 Dienstag
8.5
Dokumentation:
Bericht schreiben
05.01.2009 Montag
8.5
- Traktandenliste, Protokoll und
Pflichtenheft versenden
- Ergänzungen in GUI zu Funambol
- GUI-Test MySQL, HSQLDB
- Wissenstransfer
Prototyp GUI: GUI,
Business + DB
II
06.01.2009 Dienstag
8.5
- GUI-Test MySQL, HSQLDB
Dokumentation:
Bericht schreiben
07.01.2009 Mittwoch
8
Dokumentation:
Bericht schreiben
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 242
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
09.01.2009 Freitag
8
8.5
11.01.2009 Sonntag
4
12.01.2009 Montag
8.5
- Doku: Diverse Kapitel
Dokumentation:
Bericht schreiben
Dokumentation:
Bericht schreiben
- Doku: Kapitel Datenbanken
Dokumentation:
Bericht schreiben
- Funambol Synchronisation mit zwei
Client testen
Systemtest: Testphase
Termine: Sitzung mit
Examinator
13.01.2009 Dienstag
2
Dokumentation:
14.01.2009 Mittwoch
2
- Doku: System I beschreiben,
ergänzen
Dokumentation:
Bericht schreiben
2
ergänzen
Dokumentation:
Bericht schreiben
17.01.2009 Samstag
8
ergänzen
Dokumentation:
Bericht schreiben
18.01.2009 Sonntag
6
Client testen
- Testfälle dokumentieren
schreiben
19.01.2009 Montag
8
Client testen
schreiben
2.5
- Oracle DB Lite Synchronisation mit
zwei Client testen (manuell)
schreiben
24.01.2009 Samstag
8
- Doku: Testfälle System I (man.
Synchronisation) beschreiben,
ergänzen
Dokumentation:
Bericht schreiben
26.01.2009 Montag
8
- Einarbeiten im System III
- Wissenstransfer
Systemevaluation:
System III
27.01.2009 Dienstag
2
Systemevaluation:
System III
28.01.2009 Mittwoch
2
Systemevaluation:
System III
31.01.2009 Samstag
5
Systemevaluation:
System III
- Einbindung, Bearbeitung Testfälle
System II ins Hauptdokument
Dokumentation:
Bericht schreiben
02.02.2009 Montag
8.5
06.02.2009 Freitag
5
- System III: eigener VermSyncClient
entwickeln
Systemevaluation:
System III
09.02.2009 Montag
8.5
entwickeln
- Testclient E und F erstellen
- allg. Systemumgebung aufbauen
Systemevaluation:
System III
14.02.2009 Samstag
8.5
installieren
- Einbindung Systemkonzept und
Testumgebung ins Hauptdokument
III
schreiben
15.02.2009 Sonntag
7
- MSSQL Synchronisation mit zwei
Client testen
schreiben
16.02.2009 Montag
8.5
- MSSQL ADO.NET Synchronisation
schreiben
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 243
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
18.02.2009 Mittwoch
3
- Traktandenliste und Protokoll
versenden
Dokumentation:
Bericht schreiben
21.02.2009 Samstag
5
- Doku: System III beschreiben
Dokumentation:
Bericht schreiben
4.5
Dokumentation:
Bericht schreiben
28.02.2009 Samstag
2
Dokumentation:
Bericht schreiben
01.03.2009 Sonntag
5
Dokumentation:
Bericht schreiben
02.03.2009 Montag
8.5
Dokumentation:
Bericht schreiben
23.02.2009 Montag
07.03.2009 Samstag
4
- Hauptdokument ausdrucken, Bericht
schreiben
Dokumentation:
Bericht schreiben
08.03.2009 Sonntag
2
- Bericht schreiben
Dokumentation:
Bericht schreiben
09.03.2009 Montag
8.5
- Bericht schreiben
Dokumentation:
Bericht schreiben
14.03.2009 Samstag
8
- Bericht schreiben
Dokumentation:
Bericht schreiben
15.03.2009 Sonntag
6
- Bericht schreiben
Dokumentation:
Bericht schreiben
16.03.2009 Montag
7
- Bericht schreiben
Dokumentation:
Bericht schreiben
17.03.2009 Dienstag
8
- Bericht schreiben
Dokumentation:
Bericht, Protokoll
schreiben
18.03.2009 Mittwoch
7
- Bericht schreiben
Dokumentation:
Bericht, Protokoll
schreiben
5
- Bericht schreiben
Dokumentation:
Bericht schreiben
20.03.2009 Freitag
5
- Bericht schreiben
Dokumentation:
Bericht schreiben
21.03.2009 Samstag
8
- Bericht schreiben
Dokumentation:
Bericht schreiben
22.03.2009 Sonntag
7
- Bericht schreiben
Dokumentation:
Bericht schreiben
23.03.2009 Montag
7
- Bericht schreiben
Dokumentation:
Bericht schreiben
24.03.2009 Dienstag
5
- Bericht schreiben
- Protokoll versenden,
Terminvorschläge
Dokumentation:
Bericht schreiben
25.03.2009 Mittwoch
5
- Bericht schreiben
Dokumentation:
Bericht schreiben
6
- Bericht schreiben
Dokumentation:
Bericht schreiben
27.03.2009 Freitag
8
- Bericht schreiben
Dokumentation:
Bericht schreiben
Total
515
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 244
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
13.5 Sitzungsprotokolle
13.5.1 Protokoll Nr. 01 / 08
Sitzung
Master Thesis
Objekt
Datum/Zeit
Montag, 27. Oktober 2008, 17.30 Uhr
Ort
Brugg-Windisch
Traktanden
1.
2.
3.
4.
5.
Vorsitz
A. Lo Iudice
Protokoll
I. Lo Iudice
Anwesend
A. Lo Iudice, IT-MAS Student
I. Lo Iudice, IT-MAS Student
B. Wyss, Dozent (Examinator)
Stand der Arbeit
Personelles
Weiteres Vorgehen
Varia
Nächste Sitzung
Entschuldigt
Verhandlungen und Beschlüsse
Termine/Aufträge
1. Stand der Arbeit
A. Lo Iudice berichtet den Stand der Arbeit. Die Thesis wird anhand
eines physischen und leistungsstarken Rechners mit virtuellen VMware
Maschinen erarbeitet. Zurzeit ist I. Lo Iudice mit dem Entwickeln einer
GUI für die Erfassung und Abruf der Daten tätig, während A. Lo Iudice
sich mit dem Aufsetzen der VMware Maschinen und Oracle Database
Lite beschäftigte. A. Lo Iudice weist darauf hin, dass MSSQL keine
eigene Datensynchronisation anbietet und aus diesem Grund eine
eigene Lösung zu suchen ist. Ferner sind auch Lizenzfragen und
Kosten abzuklären. B. Wyss gibt einige Hinweise zur Lösung des
Problems, die verfolgt werden können, z. B.:
- Compact SQL in Zusammenhang mit .NET Framework ADO
- Funambol mit SyncML Protokoll
- HSQLDB Datenbanksystem für Client (Server- wie auch
Standalone-Modus) in Java geschrieben
- Datenbank „Apache Derby“ als Open Source zu Vergleichen mit
Java DB von SUN
2. Personelles
Aus gesundheitlichen Gründen fällt wiederum I. Lo Iudice fast den
ganzen Monat November aus. In dieser Zeit kann I. Lo Iudice kaum an
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 245
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
der Thesis arbeiten. Die Gruppe sieht den Abgabetermin, 31. März
2009 als realistisch vor, erwägt aber auf eine mögliche
Fristverlängerung als Sicherheit.
3. Weiteres Vorgehen
In Anbetracht des vorgehenden Traktandums beschliessen die
Anwesenden Folgendes:
- Anfangs November werden dem Examinator B. Wyss das
Protokoll und das Pflichtenheft als pdf-Datei per e-mail
zugestellt.
- Arbeitsjournale und der Zeitplan werden voraussichtlich Ende
November mit Rücksicht auf die Genesung von I. Lo Iudice
erstellt.
- Die nächste Sitzung in drei Wochen fällt aus.
IL, LA
04.11.08
IL, LA
30.11.08
4. Varia
Keine
5. Nächste Sitzung
Das Datum der nächsten Sitzung bleibt gemäss Traktandum 3 offen.
offen
Der Protokollführer:
I. Lo Iudice
Beilage
- Pflichtenheft
Geht an
Teilnehmende/Entschuldigte
13.5.2 Protokoll Nr. 02 / 08
Sitzung
Master Thesis
Objekt
Datum/Zeit
Montag, 08. Dezember 2008, 17.30 Uhr
Ort
Brugg-Windisch
Traktanden
1. Protokoll 01 / 08 über Master Thesis vom 27. Oktober 2008
1.1 Ergänzung zum Pflichtenheft
2. Stand der Arbeit
4. Varia
5. Nächste Sitzung
Vorsitz
I. Lo Iudice
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 246
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Protokoll
I. Lo Iudice
Anwesend
Entschuldigt
Termine/Aufträge
1. Protokoll 01 / 08 über Master Thesis vom 27. Oktober 2008
Das Protokoll wird in der vorliegenden Fassung genehmigt und
verdankt.
1.1 Ergänzung zum Pflichtenheft
Herr Wyss empfiehlt der Gruppe, die Use Cases in das Pflichtenheft
IL, LA
aufzunehmen und nicht nur als Bestandteile der zu bearbeitenden
12.01.09
Themen zu erfassen. Ferner soll im Pflichtenheft inhaltlich wo
angebracht die Ziele, der Nutzer und der Ablauf dieser Thesis näher
beschrieben werden, damit der Auftraggeber die Arbeit am Schluss
nachvollziehen und verifizieren kann. Entspricht das Endprodukt die
Vorstellung des Auftraggebers? Die Gruppe weist darauf hin, dass sie
sich an die einzigen Vorgaben (Semesterarbeit in der SoftwareEngineering beim Dozent Kurt Scherrer), die ihnen die FHNW zur
Verfügung gestellt hat und an das Buch von Heide Balzert gehalten hat.
Daraufhin zeigt Herr Wyss einige Pflichtenheftmuster auf seinem
Laptop, z. B. ein Muster aus dem Bachelor-Informatikstudium.
2. Stand der Arbeit
Eine Benutzungsoberfläche (Prototyp GUI) für die
Datenbankverbindung, Datenanzeige und -manipulation wurde von I.
Lo Iudice fertig entwickelt und eine Systemumgebung mit Oracle
Database Lite für das Testen der Datensynchronisation wurde von A.
Lo Iudice aufgesetzt. Die Evaluation eines Systems konnte bereits
durchgeführt werden.
Als nächste Systemevaluation sieht die Gruppe eine Systemumgebung
mit Funambol und MySQL vor. Die Schwierigkeit dieser Evaluation ist,
dass die Gruppe einige Komponenten selber entwickeln muss, da
Funambol prinzipiell Lösungen zur Synchronisation von Kalender,
Kontakte und E-mail-Adressen und keine allgemeine Daten bietet. In
der Sitzung wird über die Eigenschaften von Funambol und
Komponenten (Connectoren, Device Management und
Entwicklungshandbuch) diskutiert. Aus zeitlichen und infrastrukturellen
Gründen wird das Testen der Benutzungsoberfläche auf einem PDA
nicht weiterverfolgt bzw. rückt in den Hintergrund -> Emulation von PDA
auf PC. Die Gruppe will in ihrer Thesis gemäss Aufgabenstellung sich
primär mit der Synchronisation beschäftigen. Diese steht zurzeit im
Vordergrund (Schwergewicht).
4. Varia
Keine
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 247
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
5. Nächste Sitzung
Die nächste Sitzung findet wie folgt statt:
- Montag, 12 Januar 2008, 17.30 Uhr, FHNW
I. Lo Iudice
Beilage
- Pflichtenheft (neu)
Geht an
13.5.3 Protokoll Nr. 01 / 09
Sitzung
Master Thesis
Objekt
Datum/Zeit
Montag, 12. Januar 2009, 17.30 Uhr
Ort
Brugg-Windisch
Traktanden
1.
2.
3.
4.
5.
Vorsitz
I. Lo Iudice
Protokoll
I. Lo Iudice
Anwesend
Protokoll 02 / 08 über Master Thesis vom 8. Dezember 2008
Stand der Arbeit
Weiteres Vorgehen
Varia
Nächste Sitzung
Entschuldigt
Termine/Aufträge
1. Protokoll 02 / 08 über Master Thesis vom 8. Dezeber 2008
verdankt.
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 248
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
2. Stand der Arbeit
Die Gruppe evaluierte als zweites System MySQL, aber aus folgende
Gründen konnte MySQL nicht berücksichtigt werden:
- MySQL kann nur Einweg synchronisieren
- MySQL bietet kein vollständiges System wie Oracle an
- MySQL eignet sich besser für Replikationsverfahren
Daraufhin beschloss die Gruppe Funambol als zweites System zu
wählen. Server-seitig wird MySQL und Client-seitig HSQL als
Datenbank verwendet.
Der jetzige Arbeitsstand sieht folgendermassen aus:
- Die Systemumgebung ist fertig aufgesetzt und betriebsbereit.
- Die Arbeiten der Testfälle sind noch offen (Anfangsstatus).
- Die Gesamtarbeit zur zweiten Systemevaluation ist noch nicht
abgeschlossen.
- Gemäss unserem Terminplan sind wir mindestens um eine
Woche in Verzug!
Während der Besprechung sind Fragen (Unklarheiten) gestellt worden:
− Testfall 3: Bei Oracle ist Funktion threadsafe eingestellt?
-> ist zu überprüfen
− Lizenz Oracle: -> Campus Lizenz FHNW steht zur Verfügung
Im Weiteren wurde über beide Systeme (Oracle und Funambol) Pro
und Contra respektive die Themen: Device Management, Branch-Office
und Konfliktbehandlung diskutiert.
Aus der zeitlichen und Problem-Erfahrung mit der zweiten
Systemevaluation, die die Gruppe gemacht hat, wird entschieden, das
dritte System auf die restliche Zeit (Abgabetermin) so weit wie möglich
zu bearbeiten. Als drittes System wird Framework ADO.NET von
Microsoft vorgesehen. Voran müssen aber einige Tests des Systems I
nochmals nach den Erkenntnissen dieser Sitzung (threadsafe /
manuelle Synchronisation) durchgeführt werden, bevor mit dem dritten
System begonnen werden kann.
4. Varia
Keine
5. Nächste Sitzung
Die nächste Sitzung findet wie folgt statt:
- Montag, 9. März 2009, 17.30 Uhr, FHNW
I. Lo Iudice
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 249
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
Beilage
Geht an
13.5.4 Protokoll Nr. 02 / 09
Sitzung
Master Thesis
Objekt
Datum/Zeit
Montag, 9. März 2009, 17.30 Uhr
Ort
Brugg-Windisch
Traktanden
1.
2.
3.
4.
5.
Vorsitz
I. Lo Iudice
Protokoll
I. Lo Iudice
Anwesend
Protokoll 01 / 09 über Master Thesis vom 12. Januar 2009
Stand der Arbeit
Weiteres Vorgehen
Varia
Nächste Sitzung
Entschuldigt
Termine/Aufträge
1. Protokoll 01 / 09 über Master Thesis vom 12. Januar 2009
verdankt.
2. Stand der Arbeit
Bevor wir mit der Evaluation des dritten und letzten Systems „Microsoft
Synchronization Services for ADO.NET“ beginnen konnten, mussten
vorgängig folgende Arbeiten abgeschlossen werden:
- System I: Testfälle mit der manuellen Synchronisation
durchführen und dokumentieren
- System II: Ebenfalls Testfälle durchführen und dokumentieren
Der Arbeitsstand beim letzten System sieht folgendermassen aus:
- Die Systemumgebung ist fertig aufgesetzt und betriebsbereit.
- Die Testfälle sind durchgeführt und dokumentiert worden.
- Gemäss unserem Terminplan sind wir wieder auf Kurs.
Folgende Arbeiten sind offen:
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 250
MAS-IT 2006
____________________________________________________________________________________________________________________________________________________________
-
System III Beschrieb, Schlussdiskussion
Diverse Kapitel (Vorwort, Zusammenfassung, Literatur, …)
Anhänge
Während der Besprechung sind Fragen (Unklarheiten) gestellt worden:
- Aufbau und Layout des Berichts (Corporate Design); es steht
eine Vorlage von der Schule als Hilfe zur Verfügung
- Termine: Abgabe und Verteidigung (Präsentation)
- Was und Wie wird abgegeben?
Bis spätestens am 31. März 2009 soll die Arbeit an der FHNW
abgegeben werden. Dem Examinator, Herr Wyss werden zwei
Farbexemplare des Berichts auf Papier mit je einer DVD mit unseren
Zusatzdokumenten und Programm-Code überreicht. Der CoExaminator, Herr Löwenthal erhält den Bericht in PDF-Form per E-Mail
zugestellt. Für die Präsentation (Verteidigung) der Arbeit muss
demnächst einen Termin im April festgelegt werden. Terminvorschlag
an beiden Examinatoren via E-Mail verschicken.
4. Varia
Keine
5. Nächste Sitzung
Keine
I. Lo Iudice
Beilage
Geht an
______________________________________________________________________________________________________________________________________________________________________________________________________________________________________
31. März 2009
Seite 251

Datenbanksynchronisation

Transcription

Similar documents

Geometrische Bestimmung der horizontalen und vertikalen

New Users Installation Guide