Synchronisation von Informationsobjekten zwischen heterogenen …€¦ · Diplomarbeit Synchronisation von Informationsobjekten zwischen heterogenen Systemen Frank Schultz Studiengang

Diplomarbeit

Synchronisation von Informationsobjekten zwischen

heterogenen Systemen

Frank SchultzStudiengang Informatik-Ingenieurwesen

Technische Universität Hamburg-Harburg

BetreuungProf. Dr. Florian Matthes

Lehrstuhl für Software Engineering betrieblicher Informationssysteme Fakultät für Informatik

Technische Universität München

Hamburg, im Oktober 2003

III

III

Erklärung

Hiermit versichere ich, die vorliegende Diplomarbeit selbstständig verfasst und keine an-deren als die angegebenen Quellen verwendet zu haben.

Hamburg, den 29. Oktober 2003

IV V

IV V

Inhaltsverzeichnis

1 Einleitung ...................................................................................................................... 11.1 Ziel der Arbeit...................................................................................................... 21.2 Gliederung der Arbeit ......................................................................................... 2

2 Motivation...................................................................................................................... 52.1 Groupware ........................................................................................................... 5

2.1.1 Definition von Groupware....................................................................... 52.1.2 Kerndisziplinen von Groupware............................................................. 62.1.3 Integrierte Groupwaresysteme................................................................. 8

2.2 Informationsportale............................................................................................. 92.2.1 Definition von Informationsportalen...................................................... 92.2.2 Klassifikation von Informationsportalen ................................................ 9

2.3 Synchronisation................................................................................................. 102.3.1 Synchronisationsbedarf .......................................................................... 102.3.2 Definition von Synchronisation ............................................................ 112.3.3 Aspekte der Synchronisation.................................................................. 132.3.4 Synchronisationsprotokoll ..................................................................... 17

3 Der Synchronisationsstandard SyncML................................................................... 193.1 Entstehung und Zielsetzung............................................................................ 193.2 Grundlagen........................................................................................................ 20

3.2.1 Client- und Server-Systeme................................................................... 213.2.2 Identifikation von Änderungen ............................................................. 21

VI VII

3.2.3 Verwendung von Sync-Anchors ............................................................ 22

3.2.4 Mapping von Identitäten........................................................................ 23

3.2.5 Auflösen von Synchronisationskonflikten ............................................ 23

3.2.6 Austausch von Geräteinformationen .................................................... 24

3.2.7 Authentifikation ...................................................................................... 24

3.3 SyncML-Repräsentationsprotokoll.................................................................. 25

3.3.1 Aufbau einer Synchronisationsnachricht.............................................. 25

3.3.2 Synchronisationsoperationen................................................................. 27

3.4 SyncML-Synchronisationsprotokoll................................................................ 32

3.4.1 Initialisierungsphase............................................................................... 33

3.4.2 Synchronisationsphase ........................................................................... 34

3.4.3 Mappingphase......................................................................................... 35

4 Synchronisationsmodell ............................................................................................. 37

4.1 Funktionale Anforderungen an das Synchronisationsmodell....................... 37

4.1.1 Funktionale Anforderungen des Client- und des Server-Systems ..... 38

4.1.2 Funktionale Anforderungen des Server-Systems................................. 39

4.1.3 Funktionale Anforderungen des Client-Systems................................. 39

4.2 Konzeptuelles Synchronisationsmodell .......................................................... 40

4.3 Implementierung des Synchronisationsmodells ............................................ 43

4.3.1 Repräsentation von Nachrichten........................................................... 43

4.3.2 Verarbeitung von Nachrichten............................................................... 45

4.3.3 Erkennen von Änderungen ................................................................... 47

4.3.4 Synchronisationsoperationen................................................................. 52

4.3.5 Synchronisationskonflikte...................................................................... 53

4.3.6 Verarbeitung unterschiedlicher Objektrepräsentationen..................... 56

4.4 Synchronisationsvorgang.................................................................................. 57

4.4.1 Konfiguration und Start der Synchronisation...................................... 57

4.4.2 Initialisierungsphase............................................................................... 58

4.4.3 Synchronisationsphase ........................................................................... 60

4.4.4 Mappingphase......................................................................................... 61

4.5 Zusammenfassung ............................................................................................ 62

VI VII

5 Integration des Synchronisationsmodells in das Informationsportal infoAsset Broker und in die Groupware Microsoft Exchange ................................................ 655.1 infoAsset Broker ................................................................................................ 65

5.1.1 Architektur............................................................................................... 665.1.2 Integration des Synchronisationsmodells als Server ........................... 68

5.2 Microsoft Exchange........................................................................................... 715.2.1 Programmierschnittstellen ..................................................................... 725.2.2 Integration des Synchronisationsmodells als Client............................ 74

5.3 Zusammenfassung ............................................................................................ 75

6 Zusammenfassung und Ausblick.............................................................................. 776.1 Zusammenfassung ............................................................................................ 776.2 Ausblick .............................................................................................................. 78

Literaturverzeichnis.............................................................................................................. 80

VIII IX

VIII IX

Abbildungsverzeichnis

2.1 Disziplinen von Groupware [Wagn94] ....................................................................... 72.2 Prozess- und Datensynchronisation nach [Lehe02] ................................................ 12

3.1 Beispiel für die Verwendung von Sync-Anchors [SyncML02a].............................. 223.2 Mapping-Tabellen zur Verknüpfung von Identitäten .............................................. 233.3 Initialisierungsphase der Synchronisation nach [SyML02a] .................................. 333.4 Synchronisations- und Mappingphase [SyML02a] ................................................. 35

4.1 Anwendungsfalldiagramm des Client-Systems ........................................................ 404.2 Konzeptuelles Klassendiagramm des Synchronisationsmodells............................. 414.3 Klassendiagramm des Nachrichtenmodells.............................................................. 444.4 Klassen SyncEngine und SyncTask ........................................................................... 464.5 Sequenzdiagramm zur Nachrichtenverarbeitung.................................................... 484.6 Klassen LocalDatastore und SyncSnapshot.............................................................. 494.7 Venn-Diagramm zur Identifikation von Änderungen ............................................. 504.9 Klassendiagramm ContentType ................................................................................. 564.10 Synchronisationsvorgang ............................................................................................ 58

5.1 Schichtenarchitektur des infoAsset Brokers [Wegn02] ............................................ 665.2 Konzeptuelles Modell der Broker-Services nach [Wegn02] .................................... 675.3 Integration des Synchronisationsmodells in den infoAsset Broker......................... 695.4 Datenzugriff über ADO und CDO [Micr03] ........................................................... 725.5 Verwendung von WebDAV durch einen Web-Browser [Micr03]............................ 735.6 Synchronisationsszenario ........................................................................................... 75

X XI

X XI

Tabellenverzeichnis

3.1 Kategorien von Response-Status-Codes.................................................................... 283.2 Synchronisationstypen nach [SyML02a] .................................................................. 32

4.1 Synchronisationsoperationen und Konfliktsituationen ........................................... 534.2 Response-Status-Codes zur Konfliktauflösung ........................................................ 544.3 Konfliktlösungsstrategien und daraus resultierende Operationen.......................... 554.4 Response-Status-Codes zur Konfliktauflösung ........................................................ 59

XII 1

XII 1

Kapitel 1

Einleitung

Innerhalb von Organisationen, z.B. Firmen oder Universitäten, werden heutzutage oft mehrere unterschiedliche Informationssysteme unabhängig voneinander eingesetzt. Vielen dieser Systeme ist gemein, dass sie unter anderem über Funktionalitäten zum Verwalten von Informationen über Personen verfügen. Dabei kann es sich um stationäre Systeme wie Groupware- oder Informationsportalsysteme sowie um mobile Systeme wie Personal Digital Assistants (PDA) oder Mobiltelefone handeln. Häufig tritt der Fall ein, dass Informationen einer Person unabhängig voneinander auf mehreren Systemen exis-tieren und auf diesen verändert werden können.

Diese sowohl räumlich als auch zeitlich verteilte Verwaltung und Bearbeitung von se-mantisch zusammengehörenden Informationseinheiten ist aus mehreren Gründen pro-blematisch: Zum einen ist bei der Erstellung und Pflege des Informationsbestands ein Mehraufwand unvermeidbar, da dieselben Daten mehrfach auf verschiedenen Systemen eingegeben bzw. geändert werden müssen. Zum anderen besteht die Gefahr, dass inner-halb des Informationsbestands Inkonsistenzen auftreten. Dies ist der Fall, wenn auf ver-schiedenen Systemen unterschiedliche, semantisch zusammengehörige Versionen eines Informationsobjekts existieren.

Gegenüber der zentralen Verwaltung eines Informationsbestands stellt in einer verteilten Umgebung die Sicherstellung der Integrität von zusammengehörenden Informationsbe-ständen eine neue qualitative Anforderung an die beteiligten Systeme dar: Um diesen

2

zu entsprechen, müssen semantisch identische Informationsobjekte auf allen Systemen abgeglichen und in einen konsistenten Zustand überführt werden. Dieser Vorgang kann durch Synchronisation automatisiert werden.

1.1 Ziel der Arbeit

In der vorliegenden Arbeit soll ein Modell für die Synchronisation von Informationen zwischen heterogenen Systemen entworfen und prototypisch implementiert werden. Dabei soll der Schwerpunkt auf der Spezifikation und Umsetzung eines Synchronisa-tionsprotokolls liegen, durch das die Synchronisation von Kontaktinformationen zwi-schen dem Groupwaresystem Microsoft Exchange und dem Informationsportalsystem infoAsset Broker ermöglicht wird.

1.2 Gliederung der Arbeit

In Kapitel 2 werden zunächst die für die vorliegende Arbeit relevanten Begriffe erklärt. Aus den Konzepten Groupware und Informationsportal wird die Notwendigkeit der Syn-chronisation hergeleitet und erläutert.

Kapitel 3 dient der Vorstellung des Synchronisationsstandards SyncML. In einem ersten Schritt werden die Grundlagen von SyncML eingeführt und anschließend durch die detaillierte Beschreibung der für die Synchronisation wesentlichen Spezifikationen er-gänzt.

Im vierten Kapitel wird auf der Basis von SyncML ein Synchronisationsmodell entwickelt und im weiteren Verlauf dargelegt.

In Kapitel 5 wird dargestellt, auf welche Weise das Synchronisationsmodell in Microsoft Exchange und im infoAsset Broker umgesetzt wird.

Abschließend gibt Kapitel 6 eine Zusammenfassung über die Arbeit sowie einen Ausblick auf Erweiterungsmöglichkeiten und eventuelle Anschlussarbeiten.

1 Einleitung

2

5

5

Kapitel 2

Motivation

Im folgenden Kapitel werden Begriffe und Konzepte eingeführt, die für nachfolgen-de Teile der Arbeit von Bedeutung sind. Zuerst werden die Begriffe Groupware und Informationsportal definiert und darauf aufbauend der Bedarf des Abgleichens von Informationen zwischen derartigen Systemen erläutert. Der anschließenden Definition von Synchronisation folgt eine Erläuterung verschiedener Aspekte im Hinblick auf die Synchronisation zwischen Groupware- und Informationsportalsystemen. Abschließend wird das Synchronisationsprotokoll eingeführt.

2.1 Groupware

In diesem Kapitel wird zuerst der Begriff Groupware allgemein definiert und daraus resultierend seine unterschiedlichen Aufgabengebiete mitsamt den ihn unterstützenden Systemen vorgestellt.

2.1.1 Definition von Groupware

Unter dem Begriff Groupware werden verschiedene Systeme verstanden, durch die ein kooperatives Arbeiten im Sinne des Computer Supported Cooperative Work (CSCW) ermöglicht wird. Neben einer logisch konsistenten Verteilung von Informationen sollen

6 7

Arbeitsprozesse von Personen, Personengruppen und komplexen Organisationen unter-stützt werden. Durch die Möglichkeit zur Koordination von Arbeitsabläufen sowie zur Kontrolle des Arbeitsfortschritts sollen die Effizienz und Effektivität der Bearbeitung ge-meinsamer Aufgaben gesteigert werden. Dies kann sowohl innerhalb von Organisationen als auch organisationsübergreifend geschehen. Groupware dient damit einer durchgängi-gen Unterstützung von Geschäftsprozessen mittels der Informationstechnologie.

Zu diesem Zweck der Unterstützung umfasst Groupware eine Vielzahl unterschiedlicher Systeme, die jeweils einzelne Aspekte der Arbeit in Gruppen berücksichtigen. Abbildung 2.1 liefert einen Überblick über die verschiedenen Systeme und Disziplinen in diesem Bereich. Eine nähere Beschreibung sowie Klassifizierung werden im anschließenden Kapitel vorgenommen.

2.1.2 Kerndisziplinen von Groupware

Nach [Wagn94] und [Stei96] lassen sich die durch Groupware unterstützten Disziplinen in die Bereiche Kommunikation, Koordination, Kooperation und Informationsmanage-ment einteilen und werden unter Einbeziehung der sie unterstützenden Systeme im Folgenden erläutert.

Unterstützung der Kommunikation

Die Unterstützung der Kommunikation ermöglicht den Austausch von Nachrichten zwi-schen einem Absender und einem oder mehreren Empfängern. Die Nachrichtenübertra-gung kann synchron oder asynchron erfolgen.

Synchrone Kommunikationssysteme unterstützen räumlich verteilte Konferenzen. Dies reicht von einfachen textbasierten Werkzeugen für verteilte Gesprächsrunden bis zu komplexen Audio- und Videokonferenzsystemen. Screen-Sharing-Werkzeuge bieten da-bei Funktionalitäten, die Bildschirminhalte auf anderen Bildschirmen anzeigen können. Shared-Whiteboard-Systeme stellen darüber hinaus eine Art „gemeinsame Notiztafel“ zur Verfügung, auf der Benutzer zusätzlich Eintragungen vornehmen können.

In den Bereich der asynchronen Kommunikationssysteme fallen E-Mail- und Message-Systeme sowie Systeme des Electronic Data Interchange (EDI), welche den Austausch von Papierdokumenten durch elektronische ersetzen. Asynchrone Konferenzsysteme wie Bulletin-Boards speichern Informationen öffentlich, so dass sie permanent für eine orts- und zeitunabhängige Teilnahme an Diskussionen zugänglich sind.

2 Motivation

6 7

Unterstützung der Koordination

Die Koordination von einfachen Arbeitsprozessen kann durch Systeme für das Zeit- und Aufgabenmanagement erleichtert werden. Hierzu zählen neben gruppenübergreifenden Termin- und Aufgabenplanern auch Systeme zur Raum- und Ressourcenverwaltung.

Komplexere Projektplanungssysteme übernehmen eine Teilautomatisierung von Routi-neaufgaben. Zusätzlich zur Planung helfen sie, verknüpfte Prozessteile zu koordinieren und deren Fortschritt zu verfolgen.

Den höchsten Grad der Unterstützung leisten Workflowsysteme, die neben der Verwal-tung von Tätigkeiten auch für die Weiterleitung von begleitenden Informationen sorgen. Mit ihnen werden standardisierte Arbeitsprozesse modelliert, und dadurch wird eine de-finierte Steuerung des Informationsflusses in Organisationen ermöglicht.

Unterstützung der Kooperation

In das Gebiet der Kooperationsunterstützung fallen Systeme, die eine synchrone oder asynchrone Bearbeitung von Dokumenten durch mehrere Personen erlauben. Zu den

��

��

��

��

��

��

��

��

��

��

��

Abbildung 2.1: Disziplinen von Groupware [Wagn94]

2.1.2 Kerndisziplinen von Groupware

8 9

synchronen Systemen sind verteilte Editoren zu zählen, die das gleichzeitige Bearbeiten eines Dokuments ermöglichen, wohingegen asynchrone Autorensysteme erfolgte Ände-rungen an Dokumenten benutzerabhängig darstellen.

Darüber hinaus beinhaltet diese Gruppe Systeme, die der Ideen- und Entscheidungs-findung dienen: Electronic-Meeting-Systeme bieten Funktionalitäten, um Ideenfin-dungs- und Entscheidungsprozesse computergestützt durchzuführen. Electronic-Brainstorming- und Decision-Support-Systeme sind Beispiele hierfür.

Unterstützung des Informationsmanagements

Ziel des Informationsmanagements ist, allen Beteiligten einen identischen Informati-onsbestand sowie dessen effiziente Nuzungsbasis zur Verfügung zu stellen. Neben der einfachen Verteilung von Daten fungieren Dokumentenmanagement-und Wissensma-nagement-Systeme zusammen mit Information-Retrieval-Werkzeugen als schnelle und zielgerichtete Zugangsmöglichkeit zu Informationen. Diese werden häufig durch Sys-teme ergänzt, die eine automatische Klassifikation und systematische Einordnung von Informationen realisieren.

2.1.3 Integrierte Groupwaresysteme

Die gängigen integrierten Groupwaresysteme decken zur Zeit nur einen geringen Teil der oben genannten Funktionalitäten ab. Sie unterstützen im Wesentlichen die E-Mail-Kommunikation, die gruppenübergreifende Termin- und Aufgabenplanung sowie die Verwaltung von persönlichen und öffentlichen Kontaktinformationen. Darüber hinaus gewähren sie zum einen Zugriff auf strukturierte Informationen in integrierten und externen Datenbanken, zum anderen auf unstrukturierte Informationen in verteilten Dateisystemen.

Die verbreitetsten Produkte aus diesem Bereich sind Lotus Domino und Microsoft Exchange. Beide Systeme weisen eine typische Client-Server Architektur auf, wobei sie mit Lotus Notes und Microsoft Outlook über spezialisierte Client-Applikationen verfü-gen. Im Zusammenspiel mit integrierten oder externen Web-Servern sind sie in der Lage, einen Großteil ihres Informationsbestands über Internet-Technologien auszuliefern und in normalen Web-Browsern darzustellen. Damit erschließen sie den Bereich der Infor-mationsportale.

2 Motivation

8 9

2.2 Informationsportale

Dieses Kapitel dient der Vorstellung des Begriffs Informationsportal und dessen Klassifi-kation anhand verschiedener Nutzungsszenarien.

2.2.1 Definition von Informationsportalen

Informationsportale, auch als Portale oder Web-Portale bezeichnet, werden in [KLT00] folgendermaßen definiert:

„Ein Web-Portal ist eine Website im World-Wide-Web, die Informationen aus verschiedenen, ausgewählten Quellen zusammenfasst und ihren Nutzern über einen Standard-Web-Browser einen (personalisierten) Zugang mittels Suche und/oder Navigation von Verzeichnisstrukturen bietet, gegebenenfalls ergänzt um redaktionellen Inhalt, Funktionalität zur Kommunikation und/oder Informationsverarbeitung.“

Demnach bieten Informationsportale einen uniformen und häufig personalisierten Zu-gang zu Informationen aus unterschiedlichen Quellen [Wegn02]. Die Auslieferung der Informationen erfolgt aufgrund von standardisierten Internet-Technologien plattformu-nabhängig. Informationsportale können anhand der sie verwendenden Benutzerkreise klassifiziert werden.

2.2.2 Klassifikation von Informationsportalen

Nach [Hewl02] können Portale für interne und externe sowie für private und öffentliche Benutzerkreise ausgerichtet sein. Interne Portale sind nur geschlossenen, registrierten Nutzergruppen zugänglich, während externe keiner Zugangsbeschränkung unterlie-gen. Private Portale stellen Informationen gezielt einem oder wenigen Mitgliedern einer Gruppierung zur Verfügung, wohingegen Informationen öffentlicher Portale von allen Mitgliedern eines Benutzerkreises abrufbar sind. Durch die Verwaltung von Benutzer-profilen kann ein Portal selektiv verschiedene Benutzerkreise ansprechen.

Darüber hinaus können Portale nach dem Kriterium der von ihnen abgedeckten Themen-gebiete klassifiziert werden. Bei dieser Form der Einordnung decken horizontale Portale ein breites Spektrum unterschiedlichen Themengebiete ab, während die Informationen

2.2 Informationsportale

10 11

vertikaler Portale aus einem oder wenigen verwandten Themengebieten stammen. Eine wichtige Rolle im Bereich der vertikalen Portale füllen Unternehmensportale aus.

Letztere stellen den Mitarbeitern unternehmensrelevante Informationen aus unter-schiedlichen Quellen zur Verfügung. Dabei kann es sich beispielsweise um Datenbank-, Content- oder Dokumenten-Managementsysteme handeln.

In diesem Sinne stellen Unternehmensportale ein wichtiges Werkzeug für das Informa-tions- und Wissensmanagement innerhalb von Organisationen dar und bilden aufgrund der Integration von Inhalten aus verschiedenen Quellen und der Zugänglichkeit über allgemein verfügbare Internet-Technologien einen universellen Zugangspunkt zu vielen unternehmensrelevanten Informationen. Erweitert um Werkzeuge und Dienste, die der Unterstützung von Kommunikation, Kooperation und Koordination dienen, können In-formationsportale zur Vereinheitlichung und Integration unterschiedlicher Systeme des CSCW beitragen.

In einem solchen Szenario ist es häufig notwendig, einen bestimmten Teil an Informa-tionen auf allen beteiligten Systemen parallel zu verwalten und in einem konsistenten Zustand zu halten. Dies wird im folgenden Kapitel erläutert.

2.3 Synchronisation

In diesem Kapitel wird zuerst der Bedarf der Synchronisation von Informationen zwi-schen heterogenen Systemen erläutert. Darauf aufbauend wird der Begriff Synchronisati-on definiert und damit verbundene Aspekte beschrieben.

2.3.1 Synchronisationsbedarf

Der parallele Einsatz mehrerer Informationssysteme aus den Bereichen Groupware oder Informationsportale innerhalb einer Organisation bedingt, dass ein Teil des Informati-onsbestands auf einigen oder allen Systemen unabhängig voneinander mehrfach verwal-tet wird. Ein häufig auftretendes Beispiel hierfür sind Benutzerprofile.

Benutzerprofile ermöglichen Personen, sich an Systemen als Benutzer zu authentifizie-ren. Dies geschieht meistens durch eine eindeutige Benutzerkennung und ein Passwort. Aufwendigere technische Verfahren wie Smartcards oder Fingerabdruckscanner können die Sicherheit der Authentifizierung erhöhen. Registrierte Benutzer verfügen über fest-

2 Motivation

10 11

gelegte Rechte innerhalb des Systems, die häufig über Gruppenzugehörigkeiten und konkrete Rollen innerhalb dieser Gruppen definiert sind. Das System autorisiert den Benutzer, bestimmte Funktionen einzusetzten und auf bestimmte Informationen zuzu-greifen. Häufig werden Benutzerprofile um persönliche Informationen wie Kontakt- und Adressdaten, Bankverbindungen und ähnliches ergänzt.

Die maximale Anzahl an Benutzerprofilen einer Person ist identisch mit der Anzahl unterschiedlicher eingesetzter Systeme. Ändern sich Personendaten in einem System, müssen diese entsprechend auch in allen Profilen angepasst werden, da sonst der Fall eintreten könnte, dass ein Benutzer über verschiedene, inkonsistente Benutzerprofile auf den eingesetzten Systemen verfügt. Da ein manuelles Abgleichen nicht nur aufwendig, sondern in erster Linie auch fehleranfällig ist, ist eine Automatisierung sinnvoll.

Diese kann durch Synchronisationsmechanismen erreicht werden. In dieser Arbeit wird ein Synchronisationsmodell für heterogene Systeme am Beispiel der Synchronisation von Benutzer- bzw. Kontaktinformationen zwischen einem Groupwaresystem und einem In-formationsportalsystem vorgestellt. Ein Synchronisationsmodell für homogene Systeme wird in [Lehe02] am Beispiel eines Informationsportalsystems behandelt.

In den folgenden Abschnitten wird der Begriff Synchronisation definiert und seine Ver-wendung in dieser Arbeit erläutert. Zusätzlich werden die Synchronisation begleitende Aspekte betrachtet und im Hinblick auf ihre Relevanz beschrieben.

2.3.2 Definition von Synchronisation

Der Begriff Synchronisation wird in der Informationstechnologie in verschiedenen Zu-sammenhängen verwendet. Allgemein bezeichnet er die „Abstimmung nebenläufiger Vorgänge aufeinander. Die Synchronisation der Vorgänge kann durch gegenseitige Be-obachtung erfolgen oder durch einen speziellen mit der Synchronisation beauftragten Überwacher“ [Dude93]. Diese Definition wird in [Lehe02] durch eine Unterscheidung zwischen Prozesssynchronisation und Datensynchronisation spezifiziert.

Prozesssynchronisation ist dann notwendig, wenn unabhängige Prozesse A und B in-nerhalb eines Systems gleichzeitig auf ein Objekt O zugreifen und seinen Zustand auf unterschiedliche Arten verändern wollen. Damit das Objekt infolge dieser unabhängigen Zustandsänderungen nicht in einen inkonsistenten Zustand überführt wird, müssen die Prozesse sequentiell in beliebiger Reihenfolge ausgeführt werden. Der Zugriff der Prozes-se auf das Objekt wird synchronisiert.

2.3.2 Definition von Synchronisation

12 13

Datensynchronisation ist dann notwendig, wenn semantisch zusammengehörende Ob-

jekte O1 und O2 unabhängig voneinander auf verschiedenen Systemen existieren. Werden

diese Objekte durch verschiedene Prozesse A und B modifiziert, können auf den einzel-

nen Systemen unterschiedliche Versionen entstehen. Einzeln betrachtet sind die beiden

Datenbestände konsistent, als Ganzes betrachtet jedoch inkonsistent. Um diese auch als

„lose Konsistenz“ [Syba00] bezeichnete Inkonsistenz auszugleichen, müssen die Daten

der Objekte abgeglichen werden. Bei diesem Vorgang werden die an den Objekten erfolg-

ten Zustandsänderungen synchronisiert.

Die oben beschriebene Unterscheidung zwischen Prozesssynchronisation und Daten-

synchronisation im Hinblick auf die Modifikation von Objekten durch Prozesse ist in

Abbildung 2.2 dargestellt.

In der vorliegenden Arbeit wird die Thematik der Datensynchronisation zwischen hete-

rogenen Systemen behandelt. Unter dem Begriff Synchronisation wird dementsprechend

der Vorgang verstanden, unabhängig voneinander verwaltete Informationsbestände, die

über semantisch identische Informationsobjekte verfügen, abzugleichen. Das Ziel dieses

Abgleichens ist, dass erstens alle Informationsbestände über die gleichen Informationsob-

jekte verfügen und dass sich zweitens die jeweils semantisch identischen Informationsob-

jekte in einem konsistenten Zustand befinden.

��

�

� �

��

� �

��

��

Abbildung 2.2: Prozess- und Datensynchronisation nach [Lehe02]

2 Motivation

12 13

2.3.3 Aspekte der Synchronisation

Zur Erreichung dieses Ziels sind verschiedene Aspekte zu berücksichtigen, die im Fol-

genden vorgestellt und im Hinblick auf die Synchronisation zwischen heterogenen Sys-

teme beschrieben werden.

Synchronisationsebenen

Eine Synchronisation kann auf unterschiedlichen Ebenen eines Systems stattfinden. Im

Bereich der Datensynchronisation sind dies im Wesentlichen die Dateisystemebene, die

Datenbankebene und die Applikationsebene.

Eine Synchronisation auf Dateisystemebene hat zum Ziel, Verzeichnisstrukturen und

Dateien an mehreren Stellen eines Systems oder zwischen getrennten Systemen abge-

glichen vorzuhalten. Die hierzu notwendigen Funktionen werden zum Teil durch Be-

triebssysteme zur Verfügung gestellt; spezielle Dateisystemwerkzeuge bieten jedoch meist

wesentlich spezialisiertere Funktionalitäten an.

Im Fall einer Synchronisation auf Datenbankebene werden Datenbanken, die auf iden-

tischen Datenbank-Management-Systemen verteilt verwaltet werden, abgeglichen. Dies

beinhaltet neben Datensätzen und Tabellen auch einen Abgleich von Datenbankstruk-

turen und anderen Datenbankobjekten wie gespeicherten Prozeduren, Sichten oder

Triggern. In diesem Zusammenhang wird häufig auch der Begriff Datenbankreplikation

verwendet.

Findet eine Synchronisation auf Applikationsebene statt, werden semantisch zusammen-

gehörende Informationsobjekte zwischen Applikationen abgeglichen. In einem homoge-

nen Szenario findet dies zwischen mehreren identischen Applikationen statt, in einem

heterogenen Szenario zwischen unterschiedlichen Applikationen. Die Synchronisation

zwischen mobilen und stationären Systemen sowie die in dieser Arbeit behandelte Syn-

chronisation zwischen einem Groupwaresystem und einem Informationsportalsystem

finden auf dieser Ebene statt.

Eine Synchronisation kann nur zwischen äquivalenten Ebenen eines Systems durchge-

führt werden. In [Lehe02] findet sich eine ausführliche Beschreibung der Synchronisati-

onsebenen und der auf ihnen agierenden Systeme.


14 15

Kardinalität der Synchronisation

Die Kardinalität der Synchronisation legt fest, mit wievielen anderen Systemen ein Sys-tem gleichzeitig synchronisieren kann. Dabei kann zwischen binärer Synchronisation (1:1-Synchronisation) und zwischen n-närer Synchronisation (1:n-Synchronisation) mit beliebig vielen Synchronisationspartnern unterschieden werden.

Rollen der Synchronisationspartner

Die an der Synchronisation beteiligten Systeme können in unterschiedlichen Rollen zu-einander stehen. Im symmetrischen Fall liegt eine Gleichberechtigung vor, man spricht von einer Peer-to-peer-Architektur. Im asymmetrischen Fall agiert eines der Systeme in der Rolle eines Clients, während das andere die Rolle eines Servers übernimmt. Es han-delt sich dann um eine Client-Server-Architektur.

Das System, welches die Synchronisation einleitet, bildet das aktive System. Im asymme-trischen Fall ist dies das Client-System, im symmetrischen Fall kann diese Funktion von beiden Systemen ausgeführt werden.

Steuerung der Synchronisation

Die Einleitung einer Synchronisation kann manuell oder halbautomatisch erfolgen. Eine manuell gesteuerte Synchronisation kann jederzeit, meist durch einen Benutzer initiiert, durchgeführt werden. Im Fall der halbautomatischen Synchronisation erfolgt die Durch-führung ereignisgesteuert.

Ereignisse, die den Start der Synchronisation auslösen, können definierte Zeitpunkte oder erfolgte Änderungen an Informationsobjekten sein. In letzterem Beispiel ist ein No-tifikations- oder Überwachungsmechanismus notwendig, der den beteiligten Systemen die erfolgten Änderungen signalisiert und den Synchronisationsvorgang initiert.

Pessimistische und optimistische Synchronisationsverfahren

Im Fall pessimistischer Synchronisationsverfahren werden Konflikte, die durch eine pa-rallele Bearbeitung von semantisch zusammengehörenden Informationsobjekten entste-hen können, vermieden. Dies kann, sofern die Synchronisationspartner über eine perma-nente Verbindung verfügen, durch übliche Sperrverfahren erfolgen. Um eine permanente Verbindung überflüssig zu machen, kann das Sperren von Informationsobjekten nach dem Check-In-Check-Out-Prinzip erfolgen. Dies bedeuted jedoch einen drastischen

2 Motivation

14 15

Rückgang in der Verfügbarkeit von Informationsobjekten, weil derartige Sperren meist sehr lange aufrecht erhalten werden.

Optimistische Synchronisationsverfahren hingegen gestatten die parallele Bearbeitung von verteilten Informationsobjekten. Dadurch kann es jedoch zu Änderungskonflikten kommen, die während der Synchronisation erkannt und nach definierten Regeln aufge-löst werden müssen.

Erkennen und Auflösen von Änderungskonflikten

Änderungskonflikte liegen dann vor, wenn semantisch identische Informationsobjekte auf verschiedenen Systemen unterschiedlich verändert wurden. Um diese in einen kon-sistenten Zustand zu überführen, müssen diese Konflikte aufgelöst werden. Dieser Pro-zess kann nach unterschiedlichen Strategien erfolgen.

Einfache Strategien können beispielsweise festlegen, dass ausschließlich die Änderungen eines bestimmten Systems auf allen anderen übernommen werden. Eine weitere Strategie kann im Konfliktfall die einzelnen Informationsobjekte duplizieren und die Entschei-dung zur Übernahme einem Benutzer überlassen.

Aufwendigere Strategien können anhand von Modifikationszeitpunkten das aktuellere Objekt identifizieren und übernehmen. Komplexe Merging-Strategien führen Informa-tionsobjekte auf der Ebene ihrer Attribute zusammen: Dabei sollen Modifikationen an beiden Objekten berücksichtigt werden und durch ein kontrolliertes Zusammenführen ein gemeinsamer konsistenter Zustand entstehen [Lehe02].

Identifikation zusammengehörender Objekte

Um semantisch identische Informationsobjekte zwischen unterschiedlichen Systemen zu synchronisieren, müssen korrespondierende Objekte einander zugeordnet werden können.

Dies kann über global eindeutige Objektidentitäten geschehen, die auf allen an der Syn-chronisation beteiligten Systemen für jedes Informationsobjekt verwaltet werden müssen. Verfügen die Informationsobjekte nicht über derartige Kennzeichen, besteht die Möglich-keit, die semantische Zusammengehörigkeit aufgrund definierter Regeln zu bestimmen. Diese Problemstellung wird in [Ried03] bearbeitet.

Häufig sind die beteiligten Systeme jedoch nicht in der Lage, eine globale Kennzeich-nung vorzunehmen. In diesem Fall muss der Synchronisationsmechanismus fähig sein,


16 17

eine Zuordnung von bereits synchronisierten Informationsobjekten anhand lokaler Iden-titäskennzeichnungen durchzuführen.

Identifikation von Zustandsänderungen

Der Synchronisationsmechanismus muss die Informationsobjekte identifizieren, deren Zustand sich seit der letzten erfolgten Synchronisation verändert hat, um die durchge-führten Zustandsänderungen auf alle korrespondierende Informationsobjekte zu trans-ferieren.

Die Identifikation von Zustandsänderungen kann dabei nach verschiedenen Verfahren erfolgen. Gängige Mechanismen sind beispielsweise ein Änderungsprotokoll, in dem fest-gehalten wird, welche Objekte verändert wurden, oder ein Vergleich des Zeitpunkts der letzten Änderung mit dem Zeitpunkt der letzten Synchronisation.

Darüber hinaus besteht die Möglichkeit, Änderungen aufgrund von Inhaltsvergleichen festzustellen. Dies könnte beispielsweise durch Vergleichen von Prüfwerten geschehen, die einen weitestgehend eindeutigen Wert für den Zustand eines Informationsobjekts lie-fern. Diese Art der Identifikation von Zustandsänderungen hat zudem den Vorteil, dass nur wirklich erfolgte Änderungen als solche identifiziert werden. Außerdem bietet sie die Möglichkeit, nur die Attribute von Informationsobjekten zu synchronisieren, die sich seit der letzten Synchronisation verändert haben.

Transformieren von Objektrepräsentationen

In heterogenen Umgebungen liegen Informationsobjekte in der Regel in unterschiedli-chen Repräsentationen vor. Um diese zu synchronisieren, muss der Synchronisationsme-chanismus in der Lage sein, unterschiedliche Objekterepräsentationen aufeinander abzu-bilden. Als Unterscheidungskriterien kommen Inhaltsidentität und -differenz in Frage.

Inhaltsidentische Objektrepräsentation sind durch denselben Inhaltsumfang in unter-schiedlichen Repräsentationen gekennzeichnet. Sie lassen sich daher vollständig aufein-ander abbilden und können verlustfrei in beiden Richtungen transformiert werden.

Inhaltsdifferente Objektrepräsentationen stimmen nur in Teilmengen ihres Inhaltsum-fangs überein. Aus diesem Grund können nur Teilstrukturen aufeinander abgebildet wer-den. Bei der Tranformation gehen Informationen verloren. Es besteht die Möglichkeit, die Transformation nur unidirektional vornehmen zu können.

2 Motivation

16 17

2.3.4 Synchronisationsprotokoll

Ein Synchronisationsmechanismus muss die im vorhergehenden Abschnitt beschriebe-nen Aspekte berücksichtigen und Regeln zu deren Durchführung spezifizieren, die im Rahmen des Synchronisationsvorgangs angewendet werden. Dies kann in einem Proto-koll definiert werden.

Ein Protokoll ist nach [Dude93] eine „Vereinbarung über den geordneten Ablauf einer Kommunikation, wobei die Vereinbarung in der Informatik diktatorischen Charakter besitzt: Wer sich nicht an sie hält, wird von der Kommunikation ausgeschlossen“. Ein Synchronisationsprotokoll stellt demnach die Vereinbarung über den geordneten Ablauf einer Synchronisation dar.

Gängige Synchronisationsmechanismen sind meistens nur für die Synchronisation zwi-schen identischen oder wenigen ausgewählten Systemen vorhanden. Die verwendeten Synchronisationsprotokolle sind in der Regel proprietär und von den Herstellern der Sys-teme nicht veröffentlicht. Folglich können nur bestimmte Systeme miteinander synchro-nisiert werden. Eine Anwendung auf beliebige Systeme, die über semantisch identische Informationsobjekte verfügen, ist heute nur eingeschränkt möglich.

Um dieses Problem zu lösen, haben sich verschiedene Hersteller mobiler und stationärer Systeme zu einem Konsortium zusammengeschlossen, dessen Ziel die Spezifikation ei-nes offenen Synchronisationsprotokolls zur Synchronisation beliebiger Systeme ist. Die-ses SyncML genannte Protokoll wird im folgenden Kapitel vorgestellt.

2.3.4 Synchronisationsprotokoll

19

19

Kapitel 3

Der Synchronisationsstandard SyncML

In diesem Kapitel wird der Synchronisationsstandard SyncML vorgestellt, der die Basis des in dieser Arbeit entwickelten Synchronisationsmodells bildet. In Kapitel 3.1 werden zunächst die Entstehung und die Aufgaben der SyncML-Spezifikationen beschrieben. Kapitel 3.2 dient der Vorstellung von Grundlagen, auf denen das Protokoll basiert. Diese werden in den Kapiteln 3.3 und 3.4 durch die Beschreibung der Spezifikationen des Re-

präsentationsprotokolls und des Synchronisationsprotokolls vertieft.

3.1 Entstehung und Zielsetzung

Die Entwicklung von SyncML wurde im Februar 2000 auf Initiative führender Herstel-ler von mobilen und stationären Informationssystemen begonnen. Das Ziel war und ist es, einen offenen und systemübergreifenden Standard zum Abgleichen von Daten zwi-schen unterschiedlichen Systemen zu schaffen. Dabei soll es keine Rolle spielen, ob ein Abgleich zwischen gleichartigen Systemen wie z. B. zwei Mobiltelefonen oder zwischen unterschiedlichen Systemen wie Personal Computern und Mobiltelefonen erfolgt.

Die erste Version von SyncML wurde im Dezember 2000 veröffentlicht und hat seitdem stetig Einzug in eine Reihe verschiedenartiger Systeme gehalten. Im Februar 2002 erfolgte die Veröffentlichung der Version 1.1, die die Basis der folgenden Beschreibung bildet.

20 21

Der Synchronisationsstandard SyncML enthält eine Reihe von Spezifikationen, durch

die eine Synchronisation von Daten zwischen Applikationen beschrieben wird:

• Das SyncML-Repräsentationsprotokoll definiert ein auf der Extensible Mar-

kup Language (XML) basierendes Datenformat für den Austausch von Syn-

chronisationsnachrichten. Es stützt sich auf drei Document Type Definitions

(DTDs), in denen der Aufbau einer Synchronisationsnachricht [SyML02b],

die Verwendung von Meta-Informationen [SyML02e] sowie Geräteinforma-

tionen [SyML02f], die beide an verschiedenen Stellen einer Synchronisati-

onsnachricht auftreten, festgelegt sind.

• Das SyncML-Synchronisationsprotokoll [SyML02a] legt den Kommunikati-

onsablauf während eines Synchronisationsvorgangs fest. Es definiert, wie der

protokollkonforme Austausch von Synchronisationsnachrichten zu erfolgen

hat und wie das Repräsentationsprotokoll im Rahmen der Datensynchroni-

sation anzuwenden ist [SyML02c].

• Darüber hinaus wird definiert, wie Synchronisationsnachrichten an gängige

Transportprotokolle gebunden werden müssen. Dabei handelt es sich um das

Hypertext Transport Protocol (HTTP) [SyML02d], das Object Exchange

Protocol (OBEX) und das Wireless Session Protocol (WSP).

Neben der Spezifikation des Protokolls zur Synchronisation von Daten wurde SyncML

um Mechanismen zur Fernwartung mobiler und stationärer Systeme unter Verwendung

von auf dem SyncML-Repräsentationsprotokoll basierenden Nachrichten erweitert. Die-

ses sogenannte SyncML-Device-Management wird in dieser Arbeit nicht weiter betrach-

tet.

3.2 Grundlagen

Die Spezifikationen zur Synchronisation von Daten mittels SyncML stellen eine Reihe

von Anforderungen an die Systeme, welche diesen Standard unterstützen. Sie werden

zusammen mit den Grundlagen, auf denen das Protokoll basiert, im folgenden Abschnitt

vorgestellt.

3 Der Synchronisationsstandard SyncML

20 21

3.2.1 Client- und Server-Systeme

Durch SyncML wird ein asymmetrisches Synchronisationsmodell spezifiziert, in dem

ein System in der Rolle eines Client- und das andere in der Rolle eines Server-Systems

auftritt.

Der SyncML-Client ist das aktive System. Er leitet den Synchronisationsvorgang ein,

indem er die erste Synchronisationsnachricht an den SyncML-Server sendet. Letzterer

erwartet als passives System Synchronisationsanfragen. Die Initiierung kann optional

auch durch das Server-System erfolgen. Hierbei fordert es das Client-System auf, die

einleitende Synchronisationsnachricht zu generieren. Die beschriebene Rollenverteilung

wird dadurch jedoch nicht getauscht.

In einem SyncML-Szenario ist der Server für den eigentlichen Synchronisationsvorgang

verantwortlich, indem er analysiert, welche Informationsobjekte auf den einzelnen Sys-

temen modifiziert werden müssen, um beide Systeme in einen konsistenten Zustand zu

überführen. In diesem Sinne bestimmt er, wie korrespondierende Daten abgeglichen

werden.

Client-Systeme sind typischerweise ressourcenarme Geräte wie Mobiltelefone oder Per-

sonal Digital Assistants, Server-Systeme in der Regel Desktop- oder Server-Computer.

3.2.2 Identifikation von Änderungen

Eine wesentliche Anforderung an SyncML-fähige Client- und Server-Systeme ist, in der

Lage zu sein, alle Änderungen an den von ihnen verwalteten Informationsobjekten, die

seit dem vorherigen Synchronisationsvorgang erfolgt sind, zu erkennen. Dies betrifft In-

formationsobjekte, die einem System neu hinzugefügt, die modifiziert und die gelöscht

wurden. Wie die Identifikation der einzelnen Änderungen durchgeführt werden soll, ist

durch das Protokoll nicht definiert und wird der jeweiligen Implementierung des Systems

überlassen.

Um Synchronisationen mit mehr als einem anderen Systemen vorzunehmen, ist es not-

wendig, die Identifikation von Änderungen immer relativ zum vorherigen Synchronisati-

onsvorgang und dem jeweiligen Synchronisationspartner durchzuführen.

3.2.1 Client- und Server-Systeme

22 23

3.2.3 Verwendung von Sync-Anchors

Um eine Überprüfung vornehmen zu können, ob eine Synchronisation zwischen zwei Systemen protokollkonform durchgeführt werden kann, verwendet SyncML sogenannte Sync-Anchors. Es handelt sich dabei um Prüfwerte, anhand derer die Synchronisations-partner feststellen können, ob sich der aktuelle Synchronisationsvorgang für beide Syste-me auf denselben vorherigen Synchronisationsvorgang bezieht. Ist das der Fall, befinden sich beide Systeme in Kenntnis des letzten konsistenten Informationsbestands und kön-nen die in der Zwischenzeit erfolgten Änderungen korrekt identifizieren.

Die Überprüfung der Sync-Anchors erfolgt in der Initialisierungsphase der Synchro-nisation. Dazu übertragen beide Synchronisationspartner je zwei Sync-Anchors an das andere System. Der Anchor-Last kennzeichnet den vorherigen Synchronisationsvorgang, der Anchor-Next den aktuellen. Nach einer erfolgreichen Synchronisation speichert jedes System seinen versendeten und den vom anderen System empfangenen Anchor-Next. Bei dem nächsten Synchronisationsvorgang wird der eigene gespeicherte Anchor-Next als Anchor-Last an das andere System übertragen. Stimmt der empfangene Anchor-Last mit dem beim vorherigen Synchronisationsvorgang gespeicherten Anchor-Next des an-

SyncML Client SyncML Server

Pkg #1: Last (20010909T090909Z), Next(20011010T101010Z)

Pkg #2: OK

Sync Session #1

The Sync Serverhas stored the clientsync event(09:09:09 AM,9/9/2001).

…

Sync Session #1 completed, the sync server updates the sync anchor.

The Sync Serverhas stored the clientsync event(10:10:10 AM,10/10/2001).

The persistent storage of the client is reset.

Sync Session #2

Pkg #1: Last (00000000T000000Z), Next(20011111T111111Z)

Pkg #2: Refresh required ('508')

…

The sent and thestored anchorsdo not match.

Abbildung 3.1: Beispiel für die Verwendung von Sync-Anchors [SyncML02a]


22 23

deren Systems überein, bezieht sich der aktuelle Synchronisationsvorgang direkt auf den vorherigen. Fällt dieser Vergleich für beide Systeme positiv aus, kann die Synchronisation normal fortgesetzt werden. Anderenfalls erfordert das Protokoll die Durchführung eines vollständigen Abgleichs aller Informationsobjekte beider Systeme. In Abbildung 3.1 ist die Verwendung der Sync-Anchors beispielhaft dargestellt.

3.2.4 Mapping von Identitäten

Das Protokoll erlaubt, dass jedes System eigene und unabhängige Identitätskennwerte (Ids) für seine Informationsobjekte verwalten kann. Da diese auf den einzelnen Systemen in der Regel divergent sind, ist zur Identifikation korrespondierender Informationsobjekte eine Verknüpfung der zusammengehörenden Ids notwendig, das so genannte Mapping.

Die Verwaltung dieses Mappings erfolgt durch das Server-System und ist in Abbildung 3.2 beispielhaft in Form von Mapping-Tabellen dargestellt.

3.2.5 Auflösen von Synchronisationskonflikten

Allgemeine Strategien zur Lösung von Änderungskonflikten, die durch unterschiedliche Modifikationen auf beiden Systemen entstanden sind, wurden bereits in Kapitel 2.3.3 erwähnt. In einem SyncML basierten Synchronisationsprozess vergleicht der SyncML-Server seine modifizierten Informationsobjekte mit denen des Clients und leitet daraus

Abbildung 3.2: Mapping-Tabellen zur Verknüpfung von Identitäten

3.2.4 Mapping von Identitäten

24 25

das Auftreten von Konflikten ab. SyncML spezifiziert keine Regeln zu Konfliktauflösung, sondern bietet lediglich fünf allgemeine Status-Codes, mit denen das Server- dem Client-System mitteilen kann, dass ein Konflikt aufgetreten ist und ob es diesen gelöst hat. Eine tiefergehenden Betrachtung der Konfliklösung wird in Kapitel 4.3.5 vorgenommen.

3.2.6 Austausch von Geräteinformationen

Zur Durchführung eines Synchronisationsvorgangs muss ein System die wesentlichen Fähigkeiten des anderen kennen. Diese können während der Initialisierungsphase der Synchronisation in Form von Geräteinformationen ausgetauscht werden.

Zu den darin enthaltenen relevanten Eigenschaften zählen insbesondere Informatio-nen über Datencontainer sowie über die Art von Informationsobjekten, die von ihnen verwaltet werden können. Dies umfasst zum einen alle Formate, in denen Objekte von einem System ausgetauscht werden können, zum anderen alle Attribute, über die ein In-formationsobjekt in diesem Datencontainer verfügt. Die unterstützten Formate werden in den Geräteinformationen durch die Multipurpose Internet Mail Extensions (MIME) definiert. Zu den Standardformaten gehören hierbei vCard (text/vcard bzw. text/x-vcard) für Kontaktinformationen und vCalendar (text/vcalendar bzw. text/x-vcalendar) für Ter-mininformationen.

Darüber hinaus werden zusätzliche Informationen, die den Status eines Systems wieder-geben, übermittelt. Hierzu zählen beispielsweise die Größe des Speichers, der einem Da-tencontainer zur Verfügung steht, die Anzahl von Ids, die von einem System unterstützt werden sowie Versionsnummern der verwendeten Soft- und Hardware.

3.2.7 Authentifikation

SyncML definiert Mechanismen, durch die sich ein Synchronisationspartner bei dem anderen authentifizieren kann. Der Authentifikationsvorgang erfolgt nach einem Challenge-Response-Protokoll: In der Authentication-Challenge fordert ein System die Authentifikationsinformationen des anderen Systems an und teilt diesem mit, mit welchem Hash-Algorithmus sie zu verschlüsseln sind. Das andere System übermittelt daraufhin die Benutzerkennung und das Passwort in der geforderten Form. Als Hash-Algorithmen werden ein einfaches 64-bit-Hashing (Basic) sowie das Message-Digest-5 (MD 5), ein spezieller One-Way-Hash-Algorithmus, unterstützt.


24 25

Die Authentifikation kann sowohl vom Client- als auch vom Server-System angefordert werden und wird auf zwei Ebenen unterstützt: Zum Ersten authentifizieren sich die Synchronisationspartner gegenseitig (Systemebene). Zum Zweiten kann eine Authentifi-kation auf der Ebene einzelner Datencontainer erfolgen.

3.3 SyncML-Repräsentationsprotokoll

Das SyncML-Repräsentationsprotokoll spezifiziert das Format der während der Synchro-nisation auszutauschenden Informationen. Dieser wechselseitigte Transfer erfolgt mittels Nachrichten in Form von wohlgeformten XML-Dokumenten. Der Aufbau einer Nach-richt und die zugrundeliegende XML-Sprache sind Gegenstand dieses Kapitels.

3.3.1 Aufbau einer Synchronisationsnachricht

Konzeptuell betrachtet besteht eine Synchronisationsnachricht aus einem Header und einem Body. Der Header wird durch ein SyncHdr-Element gebildet. Im SyncBody-Ele-ment wird eine Folge von Synchronisationsoperationen aggregiert. Den Ausgangspunkt einer Synchronisationsnachricht bildet ein SyncML-Element, dem sowohl das SyncHdr- als auch das SyncBody-Element untergeordnet sind.

Header einer Synchronisationsnachricht

Der Header einer Nachricht enthält neben Informationen über die der Nachricht zu-grundeliegende Version des Synchronisationsprotokolls Kennzeichen, anhand derer ein Synchronisationsvorgang und eine Nachricht in diesem Kontext identifiziert werden können. Das SessionID-Element kennzeichnet den Synchronisationsvorgang und ist in allen zugehörigen Nachrichten identisch; das MsgID-Element kennzeichnet die Nach-richt innerhalb des Synchronisationsvorgangs.

Ferner weist der Header einer Nachricht Informationen darüber auf, von welchem System und an welches System die Nachricht gesendet wird. Diesen dienen die Elemente Source und Target, die auch innerhalb von Synchronisationsoperationen in vergleichbarer Be-deutung auftreten. Die Adressierung findet in Form eines Uniform Ressource Identifiers (URI) und optional durch eine einfache textbasierte Identifikationsmöglichkeit statt. Als URI fungieren sowohl gültige Internetadressen als auch gerätespezifische Kennzeich-

3.3.1 Aufbau einer Synchronisationsnachricht

26 27

nungen wie International Mobile Equipment Identities (IMEI) oder Electronic Serial Numbers (ESN).

Die Informationen zur Authentifikation auf Systemebene werden, sofern sie gefordert werden, ebenfalls im Header einer Nachricht durch ein Cred-Element übermittelt . Opti-onal kann er zusätzliche Elemente enthalten: Während das RespURI-Element eine vom Source-Element differente Antwortadresse mitführt, verhindert das NoResp-Element das Versenden einer Status-Operation für den empfangenen Header. Ein Meta-Element kann im Header die maximale Größe von Nachrichten mitteilen, die das sendende Sys-tem verarbeiten kann.

Im Folgenden ist der Aufbau einer Nachricht mit vollständigem Header und einigen zu-sätzlichen Elementen dargestellt:

<SyncML> <SyncHdr> <VerDTD>1.1</VerDTD> <VerProto>SyncML/1.1</VerProto> <SessionID>1</SessionID> <MsgID>2</MsgID> <Target> <LocURI>http://www.syncml.org/sync-server</LocURI></Target> <LocName>Sync-Server</LocName> <Source> <LocURI>IMEI:493005100592800</LocURI> </Source> <Cred> <Meta><Type xmlns=‘syncml:metinf‘>syncml:auth-basic</Type></Meta> <Data>QnJ1Y2UyOk9oQmVoYXZl</Data> </Cred> <Meta><MaxMsgSize xmlns=‘syncml:metinf‘>5000</MaxMsgSize></Meta> </SyncHdr> <SyncBody>...</SyncBody></SyncML>

Body einer Synchronisationsnachricht

Der Body einer Synchronisationsnachricht enthält Synchronisationsoperationen, die ent-weder auf dem empfangenden System ausgeführt werden sollen oder den Status über die Ausführung einer Operation zurückliefern.

Jede Synchronisationsoperation ist innerhalb der Nachricht eindeutig durch eine CommandId in Form des CmdID-Elements gekennzeichnet. Einige Operationen ent-


26 27

halten wie der Header ein Source- und ein Target-Element, in denen in diesem Fall Quell- und Zielcontainer angegeben werden. Die Adressierung durch URIs kann dabei absolut oder relativ zu den URIs der übergeordneten Elemente sein.

Informationsobjekte werden den Synchronisationsoperationen als Parameter in Form von Item-Elementen beigefügt. Letztere beinhalten ebenfalls Source- und Target-Elemente, in denen die lokale oder entfernte Id eines Informationsobjekts angegeben ist. Das dem Item-Element untergeordnete Data-Element enthält das Informationsobjekt in einem beliebigen serialisierten Datenformat, dessen MIME-Typ im Meta-Element des Item-Elements festgehalten ist.

Verschiedene Operationen enthalten weitere Elemente mit unterschiedlichen Bedeu-tungen, die im Rahmen der Synchronisation notwendig sind. Diese werden im Zusam-menhang mit den übergeordneten Synchronisationsoperationen im folgenden Kapitel vorgestellt.

3.3.2 Synchronisationsoperationen

Die durch SyncML spezifizierten Synchronisationsoperationen lassen sich in Request- und Response-Operationen klassifizieren. Auf der einen Seite weisen Request-Operatio-nen das empfangende System an, die Operation im Rahmen eines Synchronisationsvor-gangs auszuführen. Auf der anderen Seite werden Response-Operationen verwendet, um die Resultate einer Request-Operation zu übermitteln oder das sendende System über den Status der Ausführung einer solchen zu informieren.

Response-Operationen

Die Response-Operationen, d.h. Status und Results, werden durch gleichnamige Ele-mente gebildet. Beide Operationen referenzieren den Befehl, auf den sie sich beziehen, eindeutig durch Angabe seiner CommandId im CmdRef- und der MessageId, der ihn enthaltenden Nachricht, im MsgRef-Element. Während Status-Elemente sowohl für den Header als auch für jede Request-Operation dem sendenden System zurückgeschickt werden und dieses über den Erfolg der Ausführung informieren, dienen Results-Elemen-te der Übertragung von Informationen, die als Ergebnis einer Get- oder Search-Opera-tion ermittelt wurden und in der Regel Informationsobjekte oder vergleichbare Daten enthalten.


28 29

Status-Operationen verwenden Response-Status-Codes, um detailliert über Erfolg oder Mißerfolgt von Request-Operationen zu infomieren. Dies sind dreistellige, numerische Werte, die anhand ihrer ersten Ziffer in fünf Kategorien eingeteilt und in Tabelle 3.1 auf-geführt sind.

Request-Operationen

Durch die Alert-Operation teilt ein System dem anderen mit, dass es eine Synchroni-sation zweier Datenbanken durchführen und welchen Synchronisationstyp es dabei verwenden möchte. Dazu verfügt das Alert-Element über ein Item-Element, in dessen Source- und Target-Elementen die zu synchronisierenden Datencontainer festgelegt sind und dessen Meta-Element die zu diesem Paar gehörenden Sync-Anchors Last und Next enthält. Ist eine Authentifikation auf Datenbankebene notwendig, wird das zugehörige Cred-Element im Meta-Element des Alert-Elements übermittelt. Des Weiteren kann die Alert-Operation dazu verwendet werden, das empfangende System über das Auftreten von Ereignissen zu informieren oder es zu veranlassen, dem Benutzer eine Nachricht anzuzeigen.

Die Operationen Get und Search dienen dem Anfordern von Informationsobjekten oder vergleichbaren Daten. Durch die Get-Operation können Informationen abgerufen wer-den, die über eine absolute URI adressierbar sind. Dies wird beispielsweise dann verwen-det, wenn vom anderen System Geräteinformationen abzufragen sind. Die Search-Ope-

1xx Teilen dem sendenden System mit, dass eine Operation noch ausgeführt wird.

2xx Teilen dem sendenden System mit, dass eine Operation erfolgreich ausgeführt wurde und wie sie ausgeführt wurde

3xx Teilen dem sendenden System mit, dass ein angegebenes Ziel nicht erreicht werden kann und warum es nicht erreicht werden kann.

4xx Teilen dem sendenden System mit, dass eine Operation aufgrund eines Fehlers des Absenders nicht ausgeführt werden kann. Die Ursache hierfür kann beispielsweise in fehlerhaften Operationen oder fehlenden Berechtigungen liegen.

5xx Teilen dem sendenden System mit, dass eine Operation aufgrund eines Fehlers des Emp-fängers nicht ausgeführt werden kann.

Tabelle 3.1: Kategorien von Response-Status-Codes


28 29

ration ermöglicht inhaltsbezogene Abfragen, die eine Menge von Informationsobjekten

zurückliefern. Die zugrundeliegende Abfragesprache wird dabei als Meta-Information

mitgeführt.

Im Gegensatz zu Search- und Get-Operationen steht die Put-Operation. Durch sie

übermittelt ein sendendes System dem empfangenden Informationen, ohne zuvor durch

Get- oder Search-Operationen dazu aufgefordert worden zu sein. Häufig verwendet das

Client-System eine Put-Operation, um seine Geräteinformationen bereits in der ersten

Nachricht des Synchronisationsvorgangs mitzuteilen.

Neben diesen Operationen zur ausschließlichen Übermittlung von Informationen neh-

men die Änderungsoperationen Add, Delete und Replace eine wesentliche Rolle im Zu-

sammenhang der Synchronisation ein.

• Die Add-Operation fordert das empfangende System auf, das in seinem Item-

Element auftretende Informationsobjekt zu einem Datencontainer hinzuzu-

fügen.

• Die Replace-Operation dient dem Modifizieren bzw. Überschreiben von In-

formationsobjekten. Existiert ein Informationsobjekt in einem Zielcontainer

nicht, wird die Replace-Operation als Add-Operation interpretiert und ent-

sprechend ausgeführt.

• Durch die Delete-Operation können Informationsobjekte aus einer Zielda-

tenbank gelöscht werden. Die untergeordneten Elemente Archive und SftDel

geben dabei an, ob ein zu löschendes Objekt vorher archiviert werden und

ob ein entgültiges Hard-Delete oder ein reversibles Soft-Delete durchgeführt

werden soll.

Ebenfalls zur Kategorie der Änderungsoperationen gehört die Copy-Operation. Sie weist

den Empfänger an, Informationsobjekte innerhalb eines Containers zu kopieren. Im

Rahmen eines einfachen Synchronisationsvorgangs findet sie im Gegensatz zu den oben

genannten Operationen keine Anwendung.

Die Container-Operationen Atomic, Sequence und Sync fassen andere Operationen zu-

sammen, die in einer durch sie definierten Art ausgeführt werden müssen. Eine Contai-

ner-Operation kann die jeweils anderen Container-Operationen enthalten:


30 31

• Die Atomic-Operation veranlasst das Zielsystem, die enthaltenen Operatio-

nen transaktional auszuführen. Das bedeuted, dass entweder alle Operatio-

nen erfolgreich beendet werden oder keine von ihnen Anwendung findet.

• Die Sequence-Operation definiert für die enthaltenen Operationen eine kon-

krete Ausführungsreihenfolge.

• Die wichtigste Container-Operation ist die Sync-Operation. Sie legt fest, dass

die enthaltenen Operationen im Kontext eines Synchronisationsvorgangs zu

interpretieren sind.

Neben den zuvor dargestellten Operationen füllt die Map-Operation eine für die Syn-

chronisation grundlegende Funktion aus: Sie dient der Übermittlung von Verknüpfungen

zwischen den unterschiedlichen Identitätskennungen der Informationsobjekte auf den

beteiligten Systemen. Dazu aggregiert sie eine Menge von MapItem-Elementen, in deren

Source- und Target-Element die jeweilige Id des sendenden und des empfangenden Sys-

tems übermittelt wird.

Der letzten im Repräsentationsprotokoll definierten Operation kommt eine Sonderrolle

zu, da sie nicht der Informationsübertragung dient: Durch die Exec-Operation kann das

empfangende Systeme zur Ausführung eines Prozesses aufgefordert werden. Dies kann

beispielsweise genutzt werden, um Remote Procedure Calls (RPCs) auf einem Server

anzustoßen.

Im Folgenden ist beispielhaft eine Nachricht dargestellt, deren Body einige, für die Syn-

chronisation wichtige Operationen enthält:

<SyncML> <SyncHdr> ...</SyncHdr> <SyncBody> <Status> <CmdID>1</CmdID> <MsgRef>1</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd> <TargetRef>http://www.syncml.org/sync-server</TargetRef> <SourceRef>IMEI:493005100592800</SourceRef> <Data>212</Data> </Status>


30 31

<Alert> <CmdID>1</CmdID> <Data>201</Data> <Item> <Target><LocURI>./contacts</LocURI></Target> <Source><LocURI>./dev-contacts</LocURI></Source> <Meta> <Anchor xmlns=‘syncml:metinf‘> <Next>276</Next> </Anchor> </Meta> </Item> </Alert> <Get> <CmdID>3</CmdID> <Item> <Target><LocURI>./devinf11</LocURI></Target> </Item> </Get> <Sync> <CmdID>4</CmdID> <Target><LocURI>./dev-contacts</LocURI></Target> <Source><LocURI>./contacts</LocURI></Source> <Replace> <CmdID>5</CmdID> <Meta><Type xmlns=‘syncml:metinf‘>text/x-vcard</type></Meta> <Item> <Target><LocURI>1023</LocURI></Target> <Data>...</Data> </Item> </Replace> <Add> <CmdID>6</CmdID> <Meta><Type xmlns=‘syncml:metinf‘>text/x-vcard</type></Meta> <Item> <Source><LocURI>10536681</LocURI></Source> <Data>...</Data> </Item> </Add> </Sync> <Final/> </SyncBody></SyncML>

Das folgende Kapitel befasst sich mit einer genauen Beschreibung der Verwendung von Nachrichten im Rahmen eines Synchronisationsvorgangs. Besondere Beachtung findet dabei der Gebrauch der oben beschriebenen Synchronisationsoperationen.

3.4 SyncML-Synchronisationsprotokoll

32 33

3.4 SyncML-Synchronisationsprotokoll

Das SyncML-Synchronisationsprotokoll legt den Kommunikationsablauf zum Abglei-

chen von Datencontainern zwischen Client- und Server-Systemen fest. Aus dieser Defi-

nition resultiert die konforme Art der Verwendung des Repräsentationsprotokolls.

Das Synchronisationsprotokoll spezifiziert den Kommunikationsablauf für eine Vielzahl

unterschiedlicher Synchronisationstypen, die in Tabelle 3.2 aufgeführt sind. Für die zwei

erstgenannten Typen, den TwoWay-Sync und den Slow-Sync gilt, dass sie von SyncML

Two-way sync Normaler Synchronisationsvorgang, bei dem Client- und Server-System nur die Informationsobjekte austauschen, die seit dem letzten Synchronisati-onsvorgang verändert wurden.

Slow sync Synchronisationsvorgang, bei dem Client- und Server-System alle Informa-tionsobjekte austauschen. Er wird verwendet, wenn zuvor keine Synchroni-sation zwischen zwei Datencontainern stattgefunden hat.

One-way sync from client only Synchronisationsvorgang, bei dem nur die Modifikationen des Client-Sys-tems an das Server-System gesendet werden. Das Client-System selbst wird nicht aktualisiert.

Refresh sync from client only Synchronisationsvorgang, bei dem alle Informationsobjekte des Client-Sys-tems an das Server-System gesendet werden. Das Client-System selbst wird nicht aktualisiert.

One-way sync from server only Synchronisationsvorgang, bei dem nur die Modifikationen des Server-Sys-tems an das Client-System gesendet werden. Das Server-System selbst wird nicht aktualisiert.

Refresh sync from server only Synchronisationsvorgang, bei dem alle Informationsobjekte des Server-Systems an das Client-System gesendet werden. Das Server-System selbst wird nicht aktualisiert.

Server alerted sync Das Server-System veranlasst das Client-System, eine Synchronisation nach einem oben genannten Synchronisationstyp durchzuführen. Das Cli-ent-System startet daraufhin einen Synchronisationsvorgang so, wie dieser durch eine Benutzerinitiierung eingeleitet worden wäre.

Tabelle 3.2: Synchronisationstypen nach [SyML02a]


32 33

konformen Systemen unterstützt werden müssen. Bei den anderen Typen ist eine Unter-stützung optional.

Ein auf SyncML basierender Synchronisationsvorgang lässt sich in drei Phasen einteilen: in eine Initialisierungs-, eine Synchronisations- und eine Mappingphase. In jeder die-ser Phasen werden zwei SyncML-Packages verschickt. Das erste wird vom Client zum Server geschickt, das zweite vom Server zum Client. Ein Package besteht aus einer oder mehreren zusammengehörenden Nachrichten, die aus Kapazitätsgründen nacheinander gesendet werden.

Anschließend werden die drei Phasen der Synchronisationstypen Two-Way-Sync und Slow-Sync erläutert.

3.4.1 Initialisierungsphase

Die Initialisierungsphase dient der Vorbereitung der Synchronisation: Die Systeme teilen sich gegenseitig mit, welche Datencontainer miteinander synchronisiert werden sollen und welcher Synchronisationstyp jeweils anzuwenden ist. Sie tauschen ebenso Geräte-informationen aus und führen, wenn es notwendig ist, Authentifizierungsprozesse auf System- und Datencontainerebene durch. Der Kommunikationsverlauf in der Initialisie-rungsphase ist in Abbildung 3.3 in einem Message-Sequence-Chart dargestellt.


Client and server configured properly to enable communication with each other

User

Sync order

Pkg #1: Client Initialization package to server

Pkg #2: Server Initialization package to client

Sync will continue according for the sync type(s) defined in the Alert commands.

Pkg #3: Sync package including the completition of the Syncinitialization.

Abbildung 3.3: Initialisierungsphase der Synchronisation nach [SyML02a]


34 35

Bei der Initialisierung sendet zunächst das Client-System sein Initialisierungspackage an das Server-System. Es enthält für jedes zu synchronisierende Datenbankpaar eine Alert-Operation, welche den gewünschten Synchronisationstyp, die vorhandenen Sync-Anchors und optional Informationen zur Authentifizierung auf Datenbankebene beinhaltet. Ist der Austausch von Geräteinformationen notwendig, transferiert das Client-System seine durch eine Put-Operation und fordert mittels einer Get-Operation die des Server-Systems an.

Letzteres verarbeitet die empfangenen Operationen und beantwortet sie durch Status- und Results-Operationen. Außerdem übermittelt es für jede empfangene Alert-Operation eine eigene Alert-Operation, in der es seine Sync-Anchors und eventuell Authentifikati-onsinformationen mitteilt. Der Synchronisationstyp, den das Server-System kommuni-ziert, hängt vom Vergleich der empfangenen mit den beim letzten Synchronisationsvor-gang gespeicherten Sync-Anchors ab: Sind diese identisch, kann die Synchronisation der Anforderung des Client-Systems entsprechend fortgesetzt werden. Andernfalls erzwingt das Server-System ihre Durchführung nach den Vorgaben eines Slow-Sync.

Nachdem das Client-System die empfangenen Alert-Operationen verarbeitet hat und den durchzuführenden Synchronisationstyp angepasst hat, beginnt die Synchronisationspha-se.

3.4.2 Synchronisationsphase

In diser Phase werden die abzugleichenden Informationsobjekte zwischen den Synchro-nisationspartnern ausgetauscht. Die einzelnen Schritte werden im Folgenden erörtert.

Zuerst schickt das Client-System für jedes zu synchronisierende Paar von Datencontai-nern eine Sync-Operation. Diese verfügt über Add-, Delete- und Replace-Operationen für alle neuen, gelöschten und modifizierten Informationsobjekte. Im Fall eines Slow-Sync-Szenarios enthält die Sync-Operation für jedes Objekt des Client-Containers eine Replace-Operation.

Beim Eintreffen auf dem Server-System werden die empfangenen Operationen analysiert und mit den eigenen Änderungen verglichen. Daraus generiert das Server-System die Operationen, die effektiv auf beiden Systemen auszuführen sind und schickt zu diesem Zweck die auf dem Client-System anzuwendenden an dieses zurück. Handelt es sich um ein Slow-Sync-Szenario, vergleicht das Server-System alle Informationsobjekte auf Attri-butebene und führt ein Merging korrespondierender Objekte durch.


34 35

Das Client-System empfängt die Änderungsoperationen und aktualisiert seine Daten-container. Abbildung 3.4 zeigt das Message-Sequence-Chart der Synchronisations- und Mappingphase.

3.4.3 Mappingphase

In der Mappingphase erfolgt eine Verknüpfung der unterschiedlichen Identitätskenn-zeichnern auf den Synchronisationspartnern. Aus diesem Grund schickt das Client-System eine Map-Operation, die für jedes Objekt, das dem Client in der Synchronisa-tionsphase neu hinzugefügt wurde, ein MapItem-Element enthält. In diesem wird die bestehende Id des Servers mit der erzeugten Id des Clients verknüpft.

Das Server-System aktualisiert daraufhin seine Mapping-Tabellen, bestätigt diese dem Client-System und schließt damit den Synchronisationsvorgang ab.


Client and server have processed the sync initialization for two-way sync.

User

Client device prepares the data needed to be sent to the server.

Pkg #3: Sync package from client to server

Server processes sync analysis.

Pkg #4: Status and Sync package

Sync result

Client makes data update for its databases.

Pkg #5: Data Update Status package to server

Pkg #6: Map Acknowledgement to client

Abbildung 3.4: Synchronisations- und Mappingphase [SyML02a]

3.4.3 Mappingphase

37

37

Kapitel 4

Synchronisationsmodell

In diesem Kapitel wird ein Synchronisationsmodell vorgestellt, das die Synchronisation von Informationsobjekten zwischen heterogenen Systemen nach dem Synchronisations-standard SyncML ermöglicht. In Kapitel 4.1 werden zunächst die funktionalen Anfor-derungen an das Modell beschrieben, aus denen in Kapitel 4.2 ein konzeptuelles Modell entwickelt wird. Einer detaillierten Beschreibung der Umsetzung der Anforderungen in Kapitel 4.3 folgt abschließend eine Darstellung der Durchführung des Synchronisations-vorgangs in Kapitel 4.4.

4.1 Funktionale Anforderungen an das Synchronisationsmodell

Die Aufgabe des zu entwerfenden Synchronisationsmodells ist, eine Synchronisation von Personen- bzw. Benutzerinformationen zwischen dem Groupwaresystem Microsoft Exchange und dem Informationsportalsystem infoAsset Broker zu ermöglichen. Zur Er-reichung dieses Ziels sind eine Reihe von speziellen Anforderungen zu berücksichtigen.

Die funktionalen Anforderungen an das zu entwerfende Synchronisationmodell resultie-ren primär aus den in Kapitel 3 vorgestellten Spezifikationen des Synchronisationsstan-dards SyncML. Zusätzlich ist auf die spezifischen Gegebenheiten der zu synchronisieren-den Informationssysteme, vor allem auf den Aspekt des Datenzugriffs in den Systemen Microsoft Exchange und infoAsset Broker zu achten.

38 39

Die funktionalen Anforderungen an Client- und Server-System, sowie die jeweiligen Anforderungen der einzelnen Systeme werden im Folgenden vorgestellt.

4.1.1 Funktionale Anforderungen des Client- und des Server-Systems

Der Synchronisationsvorgang basiert auf dem Austausch und der Verarbeitung von Nachrichten, deren Struktur durch das SyncML-Repräsentationsprotokoll [SyML02b] spezifiziert ist. Beide Systeme müssen in der Lage sein, eingehende Nachrichten zu empfangen und zu verarbeiten sowie ausgehende Nachrichten zu erstellen und zu ver-senden. Das Empfangen und Versenden soll dabei über das Transportprotokoll HTTP erfolgen; die Bindung der Nachrichten an das Protokoll erfolgt entsprechend der Spezifi-kation in [SyML02d]. Die Analyse und Verarbeitung eingehender Nachrichten sowie die Erzeugung ausgehender Nachrichten hat entsprechend den in Kapitel 3 beschriebenen Spezifikationen des SyncML-Synchronisationsprotokolls [SyML02a] und des SyncML-Repräsentationsprotokolls für die Datensynchronisation [SyML02c] zu erfolgen. Die Verarbeitung von Nachrichten variiert in Abhängigkeit von verschiedenen Synchronisa-tionstypen.

Das Synchronisationsmodell muss Funktionalitäten enthalten, die einen Zugriff auf die Datencontainer unterschiedlicher Informationssysteme sowohl lesend als auch schrei-bend gewährleisten. Darüber hinaus erfordert das Synchronisationsprotokoll, dass sowohl das Client-System als auch das Server-System in der Lage sind, alle Informationsobjekte zu identifizieren, an denen seit dem letzten Synchronisationsvorgang Änderungen erfolgt sind. Hierbei ist zu berücksichtigen, dass die zu synchronisierenden Systeme Microsoft Exchange und der infoAsset Broker über unterschiedliche Schnittstellen verfügen, über die auf ihre Informationsobjekte zugegriffen werden kann. Da sie nicht über integrierte Funktionalitäten, anhand derer Änderungen an Synchronisationsobjekten in Bezug auf die Synchronisation identifiziert werden können, verfügen, muss das Synchronisations-modell Mechanismen unterstützen, die eine Erkennung von Änderungen unabhängig von den beteiligten Systemen ermöglicht.

SyncML ermöglicht eine von den internen Repräsentationen von Informationsobjekten unabhängige Synchronisation. Dazu werden in der Initialisierungsphase Geräteinforma-tionen zwischen den Systemen ausgetauscht, in denen aufgelistet ist, welche serialisierten Formate von den einzelnen Systemen versendet und empfangen werden können. Das Synchronisationsmodell muss deshalb Mechanismen bereitstellen, die es ermöglichen,

4 Synchronisationsmodell

38 39

Informationsobjekte in einem beliebigen serialisierten Format auszutauschen, das sowohl vom Client-System als auch vom Server-System verarbeitet werden kann.

In diesem Zusammenhang ist es notwendig, ein existierendes Standardformat zu wählen oder ein neues Format zu spezifizieren, das die Repräsentation von Kontaktinformatio-nen in Microsoft Exchange und im infoAsset Broker zu größt möglichen Teilen wider-spiegelt.

4.1.2 Funktionale Anforderungen des Server-Systems

Das Server-System führt nach dem SyncML-Synchronisationsprotokoll die eigentliche Synchronisation durch, d.h. es vergleicht die Änderungen an seinen Informationsobjek-ten mit den Änderungen des Client-Systems und entscheidet, welche Informationsobjek-te auf den einzelnen Systemen aktualisiert werden müssen. Treten dabei Synchronisati-onskonflikte auf, muss das Server-System diese erkennen und nach definierten Regeln auflösen.

Um überhaupt eine Synchronisation durchführen zu können, müssen semantisch identi-sche Informationsobjekte einander zugeordnet werden können. Hierzu ist es notwendig, unabhängig voneinander verwaltete Identitäten auf den einzelnen Systemen miteinander zu verknüpfen. Dies geschieht sowohl auf dem Client-System als auch auf dem Server-System. Die Verwaltung der Verknüpfungen obliegt dabei jedoch vollständig dem Server-System.

4.1.3 Funktionale Anforderungen des Client-Systems

Das Client-System bildet in einem auf SyncML basierenden Synchronisationsszenario das aktive System, in dem der Benutzer festlegen kann, mit welchem Server-System und welche Datenbank des Clients mit welcher Datenbank des Servers synchronisiert wer-den soll. Die Synchronisation wird hier vom Benutzer gestartet. Die daraus resultieren Anwendungsfälle sind in Abbildung 4.1 als UML-Anwendungsfalldiagramm [FoSc00] dargestellt und werden im Folgenden beschrieben.

Anwendungsfall „Synchronisation konfigurieren“

Der Benutzer kann festlegen, mit welchem Server-System eine Synchronisation aus-geführt werden soll. Er benötigt dazu den Uniform Resource Locator (URL) oder die

4.1.2 Funktionale Anforderungen des Server-Systems

40 41

IP-Adresse, über die das Server-System via HTTP erreicht werden kann. Zudem wählt er einen Datencontainer des Client-Systems aus und legt den Datencontainer des Server-Systems, mit dem ein Abgleichen erfolgen soll, fest. Darüber hinaus kann an dieser Stelle für jedes Containerpaar eingestellt werden, welcher Synchronisationstyp angewendet werden soll.

Anwendungsfall „Synchronisation starten“

Nachdem der Benutzer die Synchronisation vollständig konfiguriert hat, kann er diese starten. Die Datenbanken des Client-Systems werden dann mit den Datenbanken des Server-Systems abgeglichen.

4.2 Konzeptuelles Synchronisationsmodell

Das vorliegende Synchronisationsmodell wurde so entworfen, dass es sowohl auf das Client- als auch auf das Server-System anwendbar ist. Die wesentlichen Unterschiede zwischen den Systemen bestehen nur in unterschiedlichen Implementierungen einzel-ner Klassen. Aus diesem Grund werden im Folgenden die Begriffe Client-System und Server-System durch die Begriffe lokales System und entferntes System ersetzt. Wird das lokale System als Client-System verstanden, handelt es sich bei dem entfernten System um das Server-System und umgekehrt.

Benutzer

Client-System

Synchronisationstarten

Synchronisationkonfigurieren

Abbildung 4.1: Anwendungsfalldiagramm des Client-Systems


40 41

Abbildung 4.2 zeigt das konzeptuelle Klassendiagramm des Synchronisationsmodells.

Um ein besseres Verständnis der Zusammenhänge zwischen den einzelnen Klassen zu

erreichen, wurde an dieser Stelle auf die Darstellung von Attributen und Methoden ver-

zichtet.

Den Ausgangspunkt des Synchronisationsmodells bildet ein lokales System, das mit

einem entfernten System synchronisiert wird. Präzisiert bedeutet dies, dass Datenban-

ken des lokalen Systems mit Datenbanken des entfernten Systems in Übereinstimmung

gebracht werden. Das lokale System wird durch die Klasse LocalSystem repräsentiert,

seine Datenbanken durch die Klasse LocalDatastore. In Analogie dazu repräsentieren die

Klassen RemoteSystem und RemoteDatastore die entsprechenden Elemente des entfern-

ten Systems.

Die letztgenannten Klassen verwalten ausschließlich Informationen über das entfernte

System und seine Datenbanken, die das lokale System zur korrekten Durchführung der

Connection

SyncEngine

SyncTask

SyncSnapshot

ContentType

LocalSystem

LocalDatastore

RemoteSystem

RemoteDatastore

1

1..*

1

*

1 1 1 11

1

1

1..* 1..*

1

1

1..*

1 1 1 1

1

1

Abbildung 4.2: Konzeptuelles Klassendiagramm des Synchronisationsmodells

4.2 Konzeptuelles Synchronisationsmodell

42 43

Synchronisation benötigt. Diese werden als Geräteinformationen während der Initialisie-rungsphase der Synchronisatin vom entfernten zum lokalen System gesendet.

Die Klasse LocalDatastore stellt eine Schnittstelle dar, über die auf Informationsob-jekte aus Datenbanken unterschiedlicher Informationssysteme einheitlich lesend und schreibend zugegriffen werden kann. Die Anbindung eines LocalDatastores an kon-krete Informationssysteme erfolgt dabei durch Spezialisierungen der abstrakten Klasse LocalDatastore. Weiterhin identifiziert ein LocalDatastore alle seit der letzten Synchro-nisation veränderten Informationsobjekte. Allgemein erfolgt die Übergabe von Informa-tionsobjekten von einem und an ein LocalDatastore in Form von Objekten der Klasse ContentType.

Ein ContentType repräsentiert ein Informationsobjekt eines bestimmten Datenformats, in dem es zwischen Synchronisationspartnern ausgetauscht wird. Welche Datenforma-te ein System unterstützt, wird innerhalb von Geräteinformationen durch Angabe von MIME-Typen übermittelt. Ein konkreter ContentType kann Methoden bereitstellen, über die auf die Attribute des Informationsobjekts zuzugreifen ist. Gleichzeitg übernimmt er die Serialisierung und Deserialisierung von Informationsobjekten zur Darstellung in Nachrichten.

Die Durchführung des Synchronisationsvorgangs basiert auf dem Austausch von Nach-richten. Dabei wird die Verarbeitung eingehender und die Erstellung ausgehender Nachrichten durch die Klassen SyncEngine und SyncTask gesteuert. Während eine SyncEngine das lokale System mit dem entfernten System verbindet und den Synchroni-sationsvorgang auf Ebene der beteiligten Systeme steuert, verknüpft eine SyncTask eine zu synchronisierende Datenbank des lokalen Systems mit einer Datenbank des entfern-ten, und lenkt auf diese Weise die Synchronisation auf der Ebene von Datenbanken.

Die SyncEngine führt eine erste Verarbeitung der eingehenden Nachrichten durch. Dabei werden alle Befehle der Nachricht verarbeitet, die sich auf die Synchronisation zwischen den Systemen beziehen. Befehle, die sich direkt auf die Synchronisation zweier Daten-banken beziehen, werden an eine SyncTask weitergeleitet.

Letztere führt somit den eigentlichen Synchronisationsvorgang aus, indem sie Methoden zum Einfügen, Ändern und Löschen in einem LocalDatastore aufruft. Im Fall des Server-Systems analysiert eine SyncTask die Änderungen auf beiden Systemen und bestimmt, welche Informationsobjekte auf den einzelnen Systemen verändert werden müssen. Sie identifiziert zudem Synchronisationskonflikte und löst diese auf.


42 43

Jeder SyncTask ist ein SyncSnapshot zugeordnet, das die Informationen persistent verwal-tet, die zur Durchführung von aufeinanderfolgenden Synchronisationen zwischen einer lokalen und einer entfernten Datenbank notwendig sind. Mithilfe eines SyncSnapshots kann ein LocalDatastore herausfinden, welche Informationsobjekte seit dem letzten Synchronisationsvorgang verändert wurden. Im Fall eines Server-Systems übernimmt das SyncSnapshot zusätzlich die Zuordnung von Ids des lokalen Systems zu denen des entfernten Systems.

Zum Empfangen und Versenden von Nachrichten und der Bindung von Nachrichten an ein Transportprotokoll dient die Klasse Connection. Sie übergibt empfangene Nachrich-ten an eine SyncEngine bzw. erhält zu versendende von dieser.

Nachrichten werden in diesem Synchronisationsmodell nicht in Form von XML-Doku-menten verarbeitet, sondern durch ein objektorientiertes Modell repräsentiert. Die detail-lierte Beschreibung der Erstellung und Verarbeitung von Nachrichten bildet den Beginn des folgenden Kapitels.

4.3 Implementierung des Synchronisationsmodells

In diesem Abschnitt werden die zuvor beschriebenen konzeptuellen Aspekte des Synchro-nisationsmodells im Detail vorgestellt und beschrieben. Zuerst wird auf die Darstellung und Verarbeitung von Synchronisationsnachrichten eingegegangen. Anschließend wird erläutert, wie Änderungen an Informationsobjekten identifiziert werden, welche Syn-chronisationsoperationen daraus resultieren und wie Synchronisationskonflikte aufgelöst werden. Die Unterstützung verschiedener serialisierter Formate von Informationsobjek-ten erfolgt im Anschluss daran.

4.3.1 Repräsentation von Nachrichten

Nachrichten werden in diesem auf SyncML basierenden Synchronisationsmodell in Form von XML-Dokumenten ausgetauscht, deren Struktur in Kapitel 3.3 beschrieben ist. Um die Verarbeitung und Erstellung in den Klassen SyncEngine und SyncTask nicht auf der Ebene ihrer XML-Repräsentation durchzuführen, wird ein objektorientiertes Modell verwendet, dessen Struktur in Abbildung 4.3 dargestellt ist. Aus Gründen der Übersichtlichkeit wird nur ein Teil der auftretenden Klassen gezeigt. Da alle weiteren

4.3.1 Repräsentation von Nachrichten

44 45

Klassen nach demselben Prinzip aufgebaut sind, kann auf ihre vollständige Darstellung

an dieser Stellt verzichtet werden.

Konzeptuell betrachtet besteht eine Nachricht aus einem SyncHdr-Element und einer

Folge von Befehlselementen, die in einem SyncBody-Element zusammengefasst werden.

Diese Elemente wiederum enthalten weitere Elemente, die an unterschiedlichen Stellen

und in unterschiedlicher Bedeutung auftreten können. Die Elemente der untersten Ebe-

ne enthalten in der Regel Werte, die den Inhalt des Elements darstellen.

Jede konkrete Klasse des Nachrichtenmodells repräsentiert ein Element, das in einer

Nachricht auftreten kann. Die Attribute der Klasse enthalten den Inhalt des entsprechen-

den Elements. Um nicht für jedes mögliche Element eine eigene Klasse zu verwenden,

werden einfach strukturierte Elemente als Attribute der Klasse des sie enthaltenden Ele-

ments realisiert. Beispielsweise sind alle Elemente, die das SyncHdr-Element enthält, als

Attribute der Klasse Message umgesetzt. Die Schachtelung komplexerer Elemente sowie

+toString() : String+toXml() : XmlElement

AbstractElement

+Message()+Message(in Message : String)+Message(in Message : XmlElement)+addCommand(in Command : AbstractCommand)

+SessionID : String+MsgID : String+SourceLocURI : String+TargetLocURI : String

Message

+Sync()+Sync(in Sync : XmlElement)

+SourceLocURI : String+TargetLocURI : String

Sync

+CmdID : StringAbstractCommand

+Replace()+Replace(in Sync : XmlElement)

Replace

+Item()+Item(in Item :XmlElement)

+SourceLocURI : String+TargetLocURI : String+Data : String

Item

+Meta()+Meta(in Meta : XmlElement)

+Type : String+AnchorLast : String+AnchorNext : String

Meta

Abbildung 4.3: Klassendiagramm des Nachrichtenmodells


44 45

die Wiederverwendung mehrfach auftretender Elemente erfolgt durch Aggregation der entsprechenden Klassen.

Um Nachrichten zwischen den Synchronisationspartnern austauschen zu können, müs-sen diese in serialisierter Form vorliegen. Jede Klasse kann aus diesem Grund über den Zwischenschritt ihrer XML-Repräsentation eine Zeichenfolge des durch sie repräsen-tierten Elements liefern. Durch eine iterative Umwandlung aller Elemente kann so die objektorientierte Repräsentation einer Nachricht serialisiert werden.

Analog dazu muss aus einer serialisierten Nachricht ihre objektorientierte Repräsentation erzeugt werden. Dies wird in der Klasse Message, die das Wurzelelement der Nachricht bildet, realisiert. Hierzu wird aus der serialisierten Zeichenfolge einer Nachricht zuerst ihre XML-Repräsentation erzeugt. Aus den darin enthaltenen XML-Elementen werden dann die zugehörigen Objekte initialisiert, die zusammen die objektorientierte Repräsen-tation der Nachricht bilden.

4.3.2 Verarbeitung von Nachrichten

Wesentlich für das Synchronisationsmodell sind die protokollkonforme Verarbeitung ein-gehender und Erstellung ausgehender Nachrichten. Diese Aufgaben werden durch die Klassen SyncEngine und SyncTask ausgeführt, die in Abbildung 4.4 dargestellt sind.

Die Klasse SyncEngine verarbeitet und erstellt dabei die Elemente von Nachrichten, die sich auf die Synchronisation zwischen zwei Systemen als Ganzes beziehen. Dies sind unter anderen das SyncHdr-Element sowie Get- und Put-Elemente im Befehlsteil einer Nachricht, die dem Austausch von Geräteinformationen dienen. Results- und Status-Ele-mente, die als Ergebnis des SyncHdr-Elements und der oben genannten Put- und Get-Elemente in einer Nachricht auftreten, gehören ebenfalls in diese Kategorie.

Die Klasse SyncTask führt diese Aufgaben demzufolge für die Befehle von Nachrichten aus, die sich speziell auf die Synchronisation eines lokalen mit einem entfernten Daten-container beziehen. Dies sind im Wesentlichen das Alert-Element zur Initialisierung der Synchronisation, das Sync-Element mit den eingebetteten Elementen Add, Delete und Replace zur Durchführung der eigentlichen Datensynchronisation sowie das Map-Ele-ment zum Verknüpfen von lokalen und entfernten Ids der Informationsobjekte. Die als Ergebnis dieser Operationen zurückgelieferten Status-Elemente werden ebenfalls durch die Klasse SyncTask entgegengenommen. Die Interaktion der beiden Klassen zur Verar-


46 47

beitung einer Nachricht ist Gegenstand der folgenden Ablaufbeschreibung, die in Abbil-

dung 4.5 exemplarisch skizziert ist.

Die Verarbeitung einer Nachricht erfolgt in der Reihenfolge des Auftretens der einem Be-

fehl entsprechenden Elemente. Eine eingegangene Nachricht wird zur Verarbeitung an

die SyncEngine übergeben (Methode ProcessMessage). Diese analysiert zuerst das Syn-

cHdr-Element der Nachricht (Methode ProcessSyncHdr), erstellt für dieses ein Status-

Element und stellt es in eine Liste von Befehlen, die an das entfernte System zu versenden

sind (Methode AddOutgoingCommand). Danach werden die Befehle der Nachricht suk-

zessive abgearbeitet. Bezieht sich der Befehl auf die Synchronisation der beiden Systeme

als Ganzes, wird er analog zum Header in der SyncEngine verarbeitet.

+AddSyncTask(in SyncTask : SyncTask)+Run()-Initialize()-Synchronize()-Map()+AddOutgoingCommand(in Command : AbstractCommand)+ProcessMessage(in Message :Message)-ProcessSyncHdr(in Message :Message)-ProcessAlert(in Alert : Alert, in Message :Message)-ProcessGet(in Get :Get, in Message :Message)-ProcessMap(in Map :Map, in Message :Message)-ProcessSync(in Sync : Sync, in Message :Message)-CreateMessage() :Message-CreateGetDevInf()-CreatePutDevInf()

-OutgoingCommandsSyncEngine

+Initialize()+Synchronize()-SynchronizeSlowSync()-SynchronizeTwoWaySync()+Map()+ProcessCommand(in Command : AbstractCommand, in Message :Message)-ProcessAlert(in Alert : Alert, in Message :Message)-ProcessStatus(in Status : Status, in Message :Message)-ProcessSync(in Sync : Sync, in Message :Message)-ProcessAdd(in Add : Add, in Message :Message)-ProcessDelete(in Delete : Delete, in Message :Message)-ProcessReplace(in Replace :Replace, in Message :Message)

SyncTask

1

1..*

Abbildung 4.4: Klassen SyncEngine und SyncTask


46 47

Bezieht sich der Befehl auf die Synchronisation zweier Datenbanken, wird er zusammen mit der ihn enthaltenden Nachricht von der SyncEngine an eine SyncTask übergeben (Methode ProcessCommand). Die Nachricht wird mitgeführt, damit die SyncTask die Operation im Kontext der Nachricht ausführen kann.

Welchem SyncTask-Objekt ein Befehl übergeben wird, ist durch die im Source- und Target-Element des Befehls festgelegten Datencontainer definiert. Die SyncTask ana-lysiert den Befehl und führt die in ihm enthaltenen Operationen in Abhängigkeit des Synchronisationsfortschritts aus. Als Antwort generiert sie ein Status- und gegebenenfalls ein Results-Element, die and die SyncEngine übergeben und dort in die Liste der zu ver-sendenden Befehle gestellt werden.

Nachdem eine Nachricht auf diese Art und Weise vollständig abgearbeitet wurde, wird die Liste der zu versendenden Befehle um die Operationen ergänzt, welche als nächstes im entfernten System ausgeführt werden müssen.

Im Anschluss daran wird durch die SyncEngine ein Message-Objekt erzeugt (Methode CreateMessage), durch die Klasse Connection serialisiert und an das entfernte System ge-schickt. Abbildung 4.5 zeigt die Verarbeitung eines SyncHdr- und eines Sync-Elements, welches wiederum ein Add- und ein Delete-Element enthält. Im Diagramm wird der entsprechende Add-Befehl an ein LocalDatastore weitergeleitet und dort ausgeführt, während der Delete-Befehl aufgrund eines Änderungskonflikts nicht an den LocalData-store weitergeleitet.

Wie das Synchronisationsmodell während des Synchronisationsvorgangs Änderungen identifiziert wird im Folgenden beschrieben.

4.3.3 Erkennen von Änderungen

Eine Kernforderung des Synchronisationsstandards SyncML ist, dass sowohl das Client-System als auch das Server-System selbstständig alle Informationsobjekte identifizieren, die sich seit dem letzten Synchronisationsvorgang verändert haben. Dies betrifft Objekte, die dem System hinzugefügt, deren Attribute geändert und die gelöscht wurden.

Die Identifikation von Änderungen wird in diesem Synchronisationsmodell durch die Klassen LocalDatastore und SyncSnapshot durchgeführt, die in Abbildung 4.6 dargestellt sind.


48 49

In einem SyncSnapshot werden alle Informationen verwaltet, die zwischen zwei Syn-

chronisationsvorgängen persistent verwaltet werden müssen. Dies sind zum einen die

Sync-Anchor-Next des lokalen und des entfernten Systems, zum anderen Informationen

über ein Objekt, anhand derer Modifikationen identifiziert werden können. Im Fall des

Server-Systems dient das SyncSnapshot zusätzlich der Verwaltung von Zuordnungen

zwischen lokalen und entfernten Ids.

Die Informationen eines SyncSnapshots werden unmittelbar nach Beendigung eines

Synchronisationsvorgangs gespeichert und spiegeln den Zustand eines LocalDatastore

nach erfolgter Synchronisation wider. Zur Identifikation von Änderungen wird der ak-

tuelle Zustand eines LocalDatastore mit dem im SyncSnapshot verwalteten Zustand

verglichen. Dabei können folgende Fälle auftreten:

LocalSystem SyncEngine SyncTask LocalDatastore

ProcessMessage(Message)

ProcessSyncHdr(Message)

AddOutgoingCommand(Status)

ProcessSync(Sync,Message)

ProcessSync(Sync,Message)


ProcessAdd(Add,Message)

AddItem(ContentType)


ProcessDelete(Delete,Message)AddOutgoingCommand(Status)

AddOutgoingCommand(Replace)

CreateMessage()

Abbildung 4.5: Sequenzdiagramm zur Nachrichtenverarbeitung


48 49

• Ein Informationsobjekt ist im SyncSnapshot vorhanden und nicht im

LocalDatastore: Das Objekt wurde bei der letzten Synchronisation abgegli-

chen und ist für die aktuelle Synchronisation nicht verfügbar. Es wurde in

der Zwischenzeit aus dem System gelöscht. Die Methode GetDeletedItemIds

eines LocalDatastore liefert eine Liste mit Ids, die seit dem letzten Synchro-

nisationsvorgang gelöscht wurden.

• Ein Informationsobjekt ist im LocalDatastore vorhanden und nicht im

SyncSnapshot: Das Objekt wurde bei der letzten Synchronisation nicht

abgeglichen. Es wurde dem System in der Zwischenzeit hinzugefügt. Die

Methode GetAddedItemIds eines LocalDatastore liefert eine Liste mit Ids,

die seit dem letzten Synchronisationsvorgang hinzugefügt wurden.

• Ein Informationsobjekt ist sowohl im SyncSnapshot als auch im

LocalDatastore vorhanden: Das Objekt ist entweder unverändert oder mo-

difiziert. Die Methode GetUpdatedItemIds eines LocalDatastore liefert eine

Liste von Ids, die seit dem letzten Synchronisationsvorgang geändert wur-

den.

Das Venn-Diagramm in Abbildung 4.7 zeigt die oben beschriebenen Mengenrelationen:

Dabei stellt A die Menge der aktuell vorhandenen Informationsobjekte und B die Menge

der nach dem letzten Synchronisationsvorgang vorhandenen dar. Die Differenz A \ B

kennzeichnet die gelöschten Informationsobjekte, die Differenz B \ A die neu hinzuge-

fügten. Die Schnittmenge A ∩ B enthält alle modifizierten sowie unveränderten Infor-

mationsobjekte.

+GetItem() : ContentType+AddItem(in Item :ContentType)+DeleteItem(in Id : String)+UpdateItem(in Id : String, in Item :ContentType)+GetAllItemIds() : List+GetAddedItemIds(in Snapshot : SyncSnapshot) : List+GetDeletedItemIds(in Snapshot : SyncSnapshot) : List+GetUpdatedItemIds(in Snapshot : SyncSnapshot) : List+UpdateSnapshot(in Snapshot : SyncSnapshot) : SyncSnapshot

-LocURI : String-LocName :String

LocalDatastore

+Load()+Save()+ContainsItem(in Id : String) : Boolean+ClearItem(in Id : String)+ClearTimestamps()+GetItemIds() : List+GetTimestamp(in Id : String) : String+SetTimestamp(in Id : String)+GetRemoteId(in Id : String) : String+SetRemoteId(in Id : String)

+LocalAnchor : String+RemoteAnchor : String

SyncSnapshot

1 1

Abbildung 4.6: Klassen LocalDatastore und SyncSnapshot


50 51

Um Veränderungen auf Attributebene zu identifizieren, verwendet das Synchronisati-

onsmodell Prüfwerte, die den Zustand eines Informationsobjekts repräsentieren. Stimmt

ein im SyncSnapshot verwalteter Prüfwert mit dem entsprechenden aktuellen des Lo-

calDatastore überein, wurde das zugehörige Objekt in der Zwischenzeit nicht verändert.

Stimmen die beiden Prüfwerte nicht überein, hat eine Veränderung des Informationsob-

jekts stattgefunden. Dabei kann zwischen inhaltsunabhängigen und inhaltsabhängigen

Prüfwerten unterschieden werden.

Inhaltsunabhängige Prüfwerte

Inhaltsunabhängige Prüfwerte kennzeichnen eine Version eines Informationsobjekts un-

abhängig von seinem Inhalt. Wird das Objekt verändert, ändert sich der Prüfwert ohne

dabei Bezug auf die konkrete Veränderung des Inhalts zu nehmen. Derartige Prüfwerte

ermöglichen, lediglich das Auftreten von Veränderungen zu identifizieren.

In die Klasse der inhaltsunabhängigen Prüfwerte gehören z.B. Zeitstempel und Ver-

sionsnummern. Der Zeitstempel eines Informationsobjekts enthält in der Regel den

Zeitpunkt, an dem das Objekt zuletzt verändert wurde. Die Versionsnummer wird bei

jeder Änderung des Objekts inkrementiert und stellt damit ein Maß für die Anzahl der

erfolgten Änderungen dar. Stimmt der im SyncSnapshot verwaltete Zeitstempel oder die

Versionsnummer mit dem aktuellen Wert des LocalDatastore überein, ist das Informati-

onsobjekt unverändert. Andernfalls hat eine Veränderung stattgefunden.

Abbildung 4.7: Venn-Diagramm zur Identifikation von Änderungen


� �

��

50 51

Die in dieser Arbeit betrachteten Systeme Microsoft Exchange und der infoAsset Broker

verwalten derartige Informationen in Form von Zeitstempeln, die in der Implementie-

rung des Modells verwendet werden.

Inhaltsabhängige Prüfwerte

Verwendet ein System keine Zeitstempel oder vergleichbare Prüfwerte, muss das Syn-

chronisationsmodell selbst den Zustand eines Informationsobjekts ermitteln und diesen

durch einen möglichst eindeutigen Prüfwert darstellen. Dieser muss aus den zugängli-

chen Informationen ermittelt werden. Da es sich dabei um den zu synchronisierenden

Inhalt eines Objekts handelt, lassen sich diese Prüfwerte als inhaltsabhängig bezeichnen.

Im einfachen Fall kann das gesamte Informationsobjekt als Prüfwert im SyncSnapshot

verwaltet werden. Stimmen alle Attribute eines aktuellen Objekts mit den im SyncS-

napshot verwalteten überein, wurde das Objekt nicht verändert.

Um die Verwaltung kompletter Informationsobjekte im SyncSnapshot zu vermeiden,

besteht die Möglichkeit, Funktionen einzusetzen, deren Ergebnis vom Zustand eines

Objekts abhängt und diesen weitestgehend eindeutig ausdrückt. Hierfür eignen sich

beispielsweise Cyclic-Redundancy-Check-Algorithmen (CRC), die u.a. zur Überprüfung

der Korrektheit von Datenübertragungen oder zur Sicherstellung der Konsistenz von

ZIP-Archiven verwendet werden.

Die Verwendung von inhaltsabhängigen Prüfwerten ist in zweierlei Hinsicht vorteilhaft:

Zum einen werden durch sie nur wirklich am Inhalt erfolgte Änderungen identifiziert.

Zum anderen kann auf diese Art nicht nur allgemein eine Veränderung festgestellt wer-

den, sondern darüber hinaus können auch einzelne veränderte Attribute identifiziert und

separat synchronisiert werden. Dadurch kann die zu übertragende Datenmenge reduziert

werden.

Die Speicherung der Informationen eines SyncSnapshots erfolgt in der Implementierung

dieses Synchronisationmodells in Form von XML-Dokumenten. Anhand eines Beispiel-

dokuments wird im Folgenden die Zuordnung von lokalen Ids zu Zeitstempeln und

entfernten Ids gezeigt:


52 53

<?xml version=“1.0“ encoding=“UTF-8“?><SyncSnapshot> <LocalAnchor>Mon Jul 07 20:20:10 CEST 2003</LocalAnchor> <RemoteAnchor>20030707T082009Z</RemoteAnchor> <Items> <Item LocalId=“fnambwlf8fj7“> <RemoteId>AQEAAAAAAB9OAQAAAAAAqXsAAAAA</RemoteId> <Timestamp>Mon Jul 07 19:52:31 CEST 2003</Timestamp> </Item> <Item LocalId=“k1rg5ckt9eoq“>...</Item> </Items></SyncSnapshot>

Aus den Änderungen, die ein Informationsobjekt in dem Zeitraum zwischen zwei Syn-

chronisationsvorgängen erfahren hat, werden die auf dem entfernten System auszufüh-

renden Operationen ermittelt und im nächsten Abschnitt aufgezeigt.


Ein Informationsobjekt kann bei einem Synchronisationsvorgang in Bezug auf den vor-

herigen Synchronisationsvorgang vier Zustände einnehmen: Es kann unverändert, modi-

fiziert, gelöscht oder dem System neu hinzugefügt worden sein. Aus den Zuständen, die

ein Informationsobjekt auf beiden an der Synchronisation beteiligten System einnimmt,

ergeben sich die durchzuführenden Synchronisationsoperationen Add, Delete und

Replace sowie Situationen, in denen ein Konflikt aufgelöst werden muss. Tabelle 4.1 zeigt

die möglichen Zustände und die daraus resultierenden Synchronisationsoperationen auf

dem jeweiligen System. Diese werden im Folgenden detailliert beschrieben.

Synchronisationsoperation Add

Die Synchronisationsoperation Add wird ausgeführt, wenn ein Informationsobjekt auf

dem entfernten System hinzugefügt werden muss. Wurden Objekte noch nicht synchro-

nisiert, kann die Zusammengehörigkeit zweier semantisch identischer Informations-

objekte, die auf je einem Systemen vorhanden sind, nicht erkannt werden. Aus diesem

Grund wird ein Hinzufügen auf beiden Systemen angefordert, so dass daraus die doppel-

te Existenz eines semantisch identischen Objekts auf beiden Systemen resultiert.


52 53

Synchronisationsoperation Delete

Die Synchronisationsoperation Delete wird ausgeführt, wenn ein Informationsobjekt auf

dem entfernten System gelöscht werden muss. Dieser Fall tritt ein, wenn ein Objekt von

einem System gelöscht wurde und auf dem anderen System unverändert blieb.

Synchronisationsoperation Replace

Die Synchronisationsoperation Replace wird ausgeführt, wenn eine Änderung eines In-

formationsobjekts an dem korrespondierenden Objekt des entfernten Systems durchge-

führt werden soll. Dies ist der Fall, wenn ein Objekt auf einem System modifiziert wurde,

während es auf dem anderen System unverändert blieb.

Haben zwischen zwei Synchronisationsvorgängen Änderungen an einem Informations-

objekt auf beiden Systemen stattgefunden, liegt ein Synchronisationskonflikt vor.

4.3.5 Synchronisationskonflikte

Die Identifikation von Konflikten erfolgt durch die SyncTask des Server-Systems beim

Vergleich der auszuführenden Operationen. Konflikte können dabei in folgenden Fällen

auftreten:

• Ein Informationsobjekt wurde sowohl auf dem Client-System als auch auf

dem Server-System modifiziert. Das Server-System hat eine Ersetzen-Ope-

System A

unverändert modifiziert gelöscht neu /nicht vorhanden

Syste

m B

unverändert keine Operation B: Ersetzen B: Löschen nicht möglichmodifiziert A: Ersetzen Konflikt Konflikt nicht möglichgelöscht A: Löschen Konflikt keine Operation nicht möglich

nicht vorhanden /neu nicht möglich nicht möglich nicht möglich B: Hinzufügen /

A: Hinzufügen

Tabelle 4.1: Synchronisationsoperationen und Konfliktsituationen


54 55

ration für ein Objekt empfangen, für das es eine Ersetzen-Operation an das

Client-System schicken müsste.

• Ein Informationsobjekt wurde auf dem Client-System gelöscht und auf dem

Server-System modifiziert. Das Server-System hat eine Löschen-Operation

für ein Objekt empfangen, für das es eine Ersetzen-Operation an das Client-

System schicken müsste.

• Ein Informationsobjekt wurde auf dem Client-System modifiziert und auf

dem Server-System gelöscht. Das Server-System hat eine Ersetzen-Opera-

tion für ein Objekt empfangen, für das es eine Löschen-Operation an das

Client-System schicken müsste.

Wie diese Konflikte aufzulösen sind, ist in der Spezifikation von SyncML nicht festgelegt.

Dort sind lediglich fünf Statusmeldungen definiert, durch die das Server-System dem

Client-System mitteilen kann, wie es aufgetretene Konflikte gelöst hat. Diese sind in Ta-

belle 4.2 aufgezeigt.


Status-Code Bedeutung207 Der Konflikt wurde durch Merging gelöst. Das Server-System hat dabei beide Informati-

onsobjekte auf Attributebene kontrolliert zusammengeführt. Wie und nach welchen Regeln dieses Merging zu erfolgen hat, ist nicht definiert.

208 Der Konflikt wurde gelöst, indem die Änderung des Client-Systems übernommen wurde. Die Änderung des Server-Systems wird verworfen und durch die Client-Version des Infor-mationsobjekts ersetzt.

209 Der Konflikt wurde gelöst, indem die Änderungen dupliziert wurden. Beide Systeme verfü-gen in diesem Fall über je zwei semantisch zusammengehörende Informationsobjekte, die in unterschiedlichen Versionen vorliegen.

409 Die Synchronisationsoperation wurde aufgrund eines Konflikts nicht ausgeführt. Das Ser-ver-System verfügt in diesem Fall über keine anzuwendende Konfliktlösungsstrategie.

419 Der Konflikt wurde gelöst, indem die Änderung des Server-Systems übernommen wurde. Die Änderung des Client-Systems wird verworfen und durch die Server-Version des Infor-mationsobjekts ersetzt.

Tabelle 4.2: Response-Status-Codes zur Konfliktauflösung

54 55

Aus den Statusmeldungen 208, 209 und 419 resultieren drei einfache Konfliktlösungsstra-

tegien, von denen die folgende erstgenannte in der prototypischen Implementierung des

Synchronisationsmodells realisiert wurde:

1. Bei Synchronisationskonflikten werden immer die Änderungen des Server-

Systems übernommen (Statusmeldung 419).

2. Bei Synchronisationskonflikten werden immer die Änderungen des Client-

Systems übernommen (Statusmeldung 208).

3. Bei Synchronisationskonflikten werden die Änderungen des Server-Sys-

tems auf dem Client-System und die Änderungen des Client-Systems auf

dem Server-System übernommen. Wurde das Informationsobjekt auf einem

System gelöscht und auf dem anderen modifiziert, wird nur das modifizierte

Objekt auf dem anderen System hinzugefügt (Statusmeldung 209).

In Abhängigkeit von der Konfliktlösungsstrategie werden im Konfliktfall Synchronisati-

onsoperationen in der SyncTask ermittelt, die auf dem Server- bzw. auf dem Client-Sys-

tem auszuführen sind. Diese sind in Tabelle 4.3 aufgeführt.

4.3.5 Synchronisationskonflikte

Client-System

modifiziert gelöscht

Serve

r-Sys

tem

modifiziert C: Ersetzen C: Hinzufügen Strategie 1:Die Änderungen des Server-Systems werden übernommengelöscht C: Löschen kein Konflikt

modifiziert S: Ersetzen S: Löschen Strategie 2: Die Änderungen des Client-Systems werden übernommengelöscht S: Hinzufügen kein Konflikt

modifiziert C: HinzufügenS: Hinzufügen C: Hinzufügen Stategie 3:

Die Änderungen von Client- und Server-System werden übernommengelöscht S: Hinzufügen kein Konflikt

Tabelle 4.3: Konfliktlösungsstrategien und daraus resultierende Operationen

56 57

4.3.6 Verarbeitung unterschiedlicher Objektrepräsentationen

Um eine Synchronisation zwischen heterogenen Systemen zu ermöglichen, müssen In-formationsobjekte in den Synchronisationsnachrichten, die zwischen Client- und Server-System ausgetauscht werden, in einem Datenformat vorliegen, das von beiden Systemen verarbeitet werden kann. Dies bedeutet im Kontext dieses Synchronisationsmodells, dass die LocalDatastores der jeweiligen Systeme das verwendete Datenformat analysieren und daraus Informationsobjekte in durch sie vertretene Datenbanken schreiben können. Außerdem müssen sie aus Datenbanken gelesene Informationsobjekte in das verwendete Datenformat konvertieren können.

Die Unterstützung unterschiedlicher Datenformate wird im vorliegenden Modell durch Objekte der Klasse ContentType realisiert. Ein ContentType repräsentiert ein Informati-onsobjekt in einem bestimmten Datenformat. Es verfügt über Methoden, um die in den Synchronisationsnachrichten verwendete serialisierte Darstellung zu liefern (Methode Write) und um aus der serialisierten Form ein entsprechendes ContentType-Objekt zu generieren (Methode Read). Spezialisierungen der Klasse ContentType können zusätz-lich über Attribute verfügen, die die einzelnen Felder eines Informationsobjekts repräsen-tieren.

Die Umwandlung von serialisierten Informationsobjekten aus Synchronisationsnach-richten in ContentType-Objekte erfolgt beim Verarbeiten von Nachrichten in einer Sync-Task. Dabei wird die serialisierte Form eines Informationsobjekts einem dem Datenfor-

+GetItem(in Id : String) : ContentType+AddItem(in Item :ContentType)+DeleteItem(in Id : String)+UpdateItem(in Id : String, in Item :ContentType)+GetAllItemIds() : List+GetAddedItemIds(in Snapshot : SyncSnapshot) : List+GetDeletedItemIds(in Snapshot : SyncSnapshot) : List+GetUpdatedItemIds(in Snapshot : SyncSnapshot) : List+UpdateSnapshot(in Snapshot : SyncSnapshot) : SyncSnapshot

-LocURI : String-LocName :String

LocalDatastore

+Read(in Item :String)+Write() : String

ContentType

1 1..*

+FirstName :String+LastName :String+Phone : String+Fax : String+EMail : String

VCard

Abbildung 4.9: Klassendiagramm ContentType


56 57

mat entsprechenden ContentType-Objekt übergeben. Letzteres wird dem LocalDatastore zugeführt, um das Objekt dem Datencontainer hinzuzufügen (Methode AddItem) oder es zu ersetzen (Methode UpdateItem).

Informationsobjekte, die an das entfernte System geschickt werden sollen, werden vom LocalDatastore in Form eines ContentType-Objekts an eine SyncTask übergeben (Me-thode GetItem). Die Umwandlung in das entsprechende serialisierte Datenformat führt das ContentType-Objekt selbst aus.

Abbildung 4.9 zeigt die Klasse ContentType mit einer Spezialisierung in Zusammenhang mit einem LocalDatastore.

Die bis hier vorgestellten Konzepte werden während des Synchronisationsvorgangs im Client- und Server-System an unterschiedlichen Stellen verwendet. Die Beschreibung des Synchronisationsvorgangs und die damit verbundenen Abläufe in den unterschiedli-chen Systemen bilden den Abschluss dieses Kapitels.

4.4 Synchronisationsvorgang

In diesem Kapitel wird die Durchführung eines Synchronisationsvorgangs detailliert beschrieben. Dazu wird zuerst auf die Konfiguration und den Start der Synchronisation durch einen Benutzer eingegangen. Anschließend werden sukzessive die Synchronisati-onsnachrichten und die mit ihrer Erstellung und Verarbeitung verbundenen Operationen im Client- sowie im Server-System beschrieben. Abbildung 4.10 skizziert den Ablauf eines Synchronisationsvorgangs und die in den einzelnen Synchronisationsnachrichten enthaltenen Informationen.

Die in Kapitel 3.4 erläuterten Synchronisationsphasen werden an dieser Stelle im Hin-blick auf ihre Umsetzung im Synchronisationsmodell ergänzt. Dabei wird auch vorge-stellt, an welchen Punkten des Synchronisationsvorgangs die in Kapitel 4.3 erläuterten Aspekte eingesetzt werden.

4.4.1 Konfiguration und Start der Synchronisation

Die Synchronisation wird konfiguriert, indem der SyncEngine des Client-Systems Syn-chronisationsaufgaben in Form von SyncTask-Objekten hinzugefügt werden (Methode AddSyncTask, siehe Abbildung 4.4). Eine SyncTask enthält dabei eine Referenz auf ein

4.3.6 Verarbeitung unterschiedlicher Objektrepräsentationen

58 59

LocalDatastore-Objekt und auf ein RemoteDatastore-Objekt, zwischen denen ein Ab-gleich durchgeführt werden soll. Ferner wird in der SyncTask der Synchronisationstyp festgelegt, welcher bei der Synchronisation dieser beiden Datenbanken angewendet wer-den soll. Nachdem die SyncEngine mit allen durchzuführenden Synchronisationsaufga-ben konfiguriert wurde, wird die Synchronisation gestartet (Methode Run).


Da das Client-System als aktives System für die Einleitung des Synchronisationsvorgangs verantwortlich ist, beginnt es die Durchführung der Initialisierungsphase.

Client-System

Jedes für diesen Synchronisationsvorgang im Client-System konfigurierte SyncTask-Objekt erzeugt seine Synchronisationsanfrage als Alert-Operation. Der darin enthaltene

Client-System Server-SystemUser

Synchronisation konfigurierenund starten

Synchronisationsanfragen, Anforderung und

Übermittlung von Geräteinformationen

Synchronisations

anfragen, Übermit

tlung von

Geräteinformatione

n

Synchronisationoperationen die sich aus den

Änderungen auf demClient-System ergeben

Mappinginformationen für auf dem Client-

System hinzugefügt Informationsobjekte

I. Initialisierungsphase

II. Synchronisationsphase

III.Mappingphase

Synchronisations

operationen die au

f dem

Client-System aus

geführt werden mü

ssen

Bestätigung des M

apping, Abschluss

der

Synchronisation

Abbildung 4.10: Synchronisationsvorgang


58 59

Client-Anchor-Last wird aus den zu diesem Datenbankpaar gehörenden SyncSnapshot-Informationen entnommen. Existieren diese nicht, bedeutet dies, dass aus Sicht des Cli-ent-Systems noch keine Synchronisation zwischen diesem Datenbankpaar stattgefunden hat. In diesem Fall wird nur der generierte Client-Anchor-Next mitgeführt. Die SyncTask ändert ihren Synchronisationstyp auf SlowSync.

Die Put- und Get-Operationen zum Austausch von Geräteinformationen werden von der SyncEngine erzeugt. Die Klasse LocalSystem besitzt dazu die Methode GetDeviceInformation. Diese wiederum verwendet die GetDatastoreInformation-Me-thode der Klasse LocalDatastore und baut die Geräteinformationen durch iteratives Ab-fragen aller im System enthaltenen LocalDatastores auf.

Die auf diese Art zusammengesetzte Initialisierungsnachricht wird an das Server-System gesendet.

Server-System

Die empfangene Nachricht wird vom Server-System wie in Kapitel 4.3.2 beschrieben verarbeitet. Sind die im Header der Nachricht enthaltenen Informationen korrekt und ist das Server-System in der Lage, eine Synchronisation durchzuführen, wird dies dem Client bestätigt. Andernfalls teilt das Server-System mit, dass und warum es keine Syn-chronisation durchführen kann. Die positiven sowie negativen Response-Status-Codes sind Tabelle 4.4 zu entnehmen.

4.4.1 Konfiguration und Start der Synchronisation

Status-Code Bedeutung101 Die Operation konnte nicht ausgeführt werden, weil der Server zur Zeit beschäftigt ist.

200 Die Operation wurde erfolgreich ausgeführt.

212 Die Operation wurde erfolgreich ausgeführt und die enthaltenen Authentifikationsinformati-onen sind korrekt.

401 Die Operation wurde nicht ausgeführt, weil die enthaltenen Authentifikationsinformationen falsch sind.

404 Die Operation wurde nicht ausgeführt, weil die enthaltene Zieladresse falsch ist407 Die Operation wurde nicht ausgeführt, weil sie keine Authentifikationsinformationen enthält.

Tabelle 4.4: Response-Status-Codes zur Konfliktauflösung

60 61

Im positiven Fall erzeugt die SyncEngine aus jeder empfangenen Synchronisationsanfra-ge ein SyncTask-Objekt und übergibt diesem die zugehörige Alert-Operation zur Verar-beitung. Die SyncTask vergleicht den empfangenen Client-Anchor-Last mit dem korres-pondierenden Server-Anchor-Last. Stimmen die Werte überein, wird die Synchronisation als Two-Way-Sync fortgesetzt, andernfalls ändert die SyncTask den Synchronisationstyp in SlowSync und informiert den Client durch senden des Response-Status-Codes „508“. Die konfigurierte SyncTask erzeugt daraufhin ihre Synchronisationsanfrage.

Nach Verarbeitung letzterer setzt die SyncEngine des Server-Systems den Austausch von Geräteinformationen fort. Sie bestätigt die erhaltenen Geräteinformationen des Clients und liefert ihre innerhalb einer Results-Operation.

Die SyncEngine generiert ihre Initialisierungsnachricht und versendet sie an das Client-System. Die Verarbeitung der Synchronisationsanfragen und Geräteinformationen erfolgt analog zum Server-System. Der entgültig durchzuführende Synchronisationstyp wird in den SyncTask-Objekten des Clients eingestellt und dem Server in der ersten Nachricht der Synchronisationsphase bestätigt.


In Abhängigkeit des Synchronisationstyps werden nun die Datencontainerpaare abgegli-chen.

Client-System

Jedes SyncTask-Objekt ermittelt die Synchronisationsoperationen, die aus seiner Sicht auf dem Server ausgeführt werden müssen. Hierzu übergibt es dem LocalDatastore das entsprechende SyncSnapshot. Durch den in Kapitel 4.3.3 beschriebenen Vergleich zum Erkennen von Änderungen, gibt der LocalDatastore die Ids von neuen, modifi-zierten und gelöschten Informationsobjekten zurück (Methoden GetAddedItemIds, GetUpdatedItemIds, GetDeletedItemIds). Die SyncTask generiert daraus zusammen mit den ContentType-Objekten von neuen und geänderten Informationsobjekten die zugehörigen Änderungsoperationen und parametrisiert sie mit den Client-Ids der ent-sprechenden Informationsobjekte.

Handelt es sich bei dem angewendeten Synchronisationstyp um einen SlowSync, erzeugt das SyncTask-Objekt für jedes im LocalDatastore enthaltene Informationsobjekt eine Replace-Operation.


60 61

Die Operationen werden in einer Sync-Operation eingebettet und der zu versendenden

Nachricht beigefügt. Ist dieser Vorgang mit allen SyncTask-Objekten durchgeführt, wird

die Nachricht an das Server-System geschickt.

Server-System

Nachdem der Header der Nachricht durch die SyncEngine verarbeitet wurde, werden die

empfangenen Sync-Operationen durch das jeweilige SyncTask-Objekt in Abhängigkeit

vom Synchronisationstyp verarbeitet.

Handelt es sich um einen TwoWay-Sync, werden die Änderungen, die vom Client-Sys-

tem übermittelt wurden, mit den eigenen Änderungen des Server-Systems verglichen

und daraus die Synchronisationsoperationen generiert, die auf beiden Systemen effektiv

auszuführen sind (vgl. hierzu Kapitel 4.3.4 und 4.3.5). Die Operationen, die auf dem

Server-System auszuführen sind, veranlassen den Aufruf der Methoden AddItem, Dele-

teItem und UpdateItem der Klasse LocalDatastore. Die auf dem Client auszuführenden

Operationen, werden vom Server-System analog zum Client-System generiert. Die Para-

metrisierung von Delete- und Replace-Operationen erfolgt mit den im SyncSnapshot des

Servers verwalteten Client-Ids; Add-Operationen enthalten konträr dazu die Server-Id

des Informationsobjekts.

Bei einem Slow-Sync-Szenario werden der Server-Datenbank alle empfangenen Infor-

mationsobjekte hinzugefügt und im Gegenzug alle Objekte des Servers in Form von

Replace-Operationen an den Client geschickt. Die in diesen Operationen übermittelten

Identitätskennzeichner sind die des Server-Systems.

Das Client-System führt die empfangenen Synchronisationsoperationen analog zum Ser-

ver-System in seinen Datencontainern aus. Für jedes Objekt, das einer Client-Datenbank

neu hinzugefügt wurde, erstellt die SyncTask eine Verknüpfung der neu erstellten Client-

Id mit der in der Synchronisationsoperation enthaltenen Server-Id. Diese Verknüpfungen

werden dem Server durch eine Map-Operation mitgeteilt.

4.4.4 Mappingphase

Diese Phase dient der Aktualisierung der Zuordnung von Informationsobjekten, die den

Systemen hinzugefügt wurden.


62

Client-System

Nachdem das Client-System die Mappingnachricht an das Server-System geschickt hat, aktualisiert es seine SyncSnapshot-Informationen. Zu diesem Zweck ruft es die aktuellen Prüfwerte zur Identifikation von Objektänderungen aus den LocalDatastore-Objekten ab und verknüpft sie mit den Ids der entsprechenden Informationsobjekte (Methode UpdateSnapshot). Darüber hinaus werden die in der Initialisierungsphase transferierten Sync-Anchor-Next zusammen mit dem aktualisierten SyncSnapshot persistent gemacht.

Server-System

Die SyncTask-Objekte des Servers veranlassen die Aktualisierung ihres SyncSnapshots analog zum Client. Zusätzlich komplettieren sie es um die in der Mappingnachricht gelieferten Id-Zuordnungen von auf dem Client hinzugefügten Objekten. Abschließend bestätigt das Server-System dem Client-System die erfolgreiche Durchführung des Map-pings.

Damit ist die Synchronisation aus Sicht des Server-Systems beendet. Das Client-System schließt sie nach Verarbeitung der letzten Nachricht des Server-Systems ab und teilt dies dem Benutzer mit.

4.5 Zusammenfassung

Das in diesem Kapitel vorgestellte, auf SyncML basierende Synchronisationsmodell ist so entworfen, dass sein Konzept sowohl für Client- als auch für Server-Systeme anwendbar ist. Darüber hinaus ist es durch Verwendung eines abstrakten LocalDatastore von Da-tencontainern bestehender Systeme unabhängig und kann flexibel mit unterschiedlichen Systemen genutzt werden.

Im folgenden Kapitel wird exemplifiziert, wie das Synchronisationsmodell zum Abgleich von Kontaktinformationen zwischen den Systemen Microsoft Exchange und infoAsset Broker eingesetzt wurde.


62

65

65

Kapitel 5

Integration des Synchronisationsmodells in das Informationsportal infoAsset Broker und in die Groupware Microsoft Exchange

In diesem Kapitel wird beschrieben, wie das im letzten Kapitel vorgestellte Synchronisa-

tionsmodell in das Informationsportal infoAsset Broker und in die Groupware Microsoft

Exchange integriert wurde. Zunächst wird der infoAsset Broker mitsamt seiner Architek-

tur vorgestellt und die Integration des Synchronisationsmodells erläutert. Analog dazu

wird Microsoft Exchange eingeführt und dessen Verwendung im Rahmen der Synchro-

nisation beschrieben.

5.1 infoAsset Broker

Der infoAsset Broker ist eine Standardsoftware für das Wissensmanagement. Im einem

Portal erschließt und vernetzt er strukturierte und unstrukturierte Informationen aus he-

terogenen Quellen und integriert Dokumentenmanagement-, Skill-Management-, Com-

munity- und Taxonomiefunktionen, um eine Verteilung von Wissen und eine effektive

Zusammenarbeit in Organisationen zu ermöglichen [info03].

66 67

Die Realisierung als Server-Software und die Implementierung in der Programmierspra-che Java sowie die Nutzung von Internettechnologien zur Informationsdarstellung und zur Kommunikation zwischen Client und Server ermöglichen einen plattformunabhän-gigen Einsatz in Internet und Intranet.

5.1.1 Architektur

Der infoAsset Broker ist ein mehrschichtiges Server-System, dessen Architektur in Abbil-dung 5.1 zu sehen ist. Die Informationsdarstellung erfolgt außerhalb des Brokers in einer Client-Schicht, üblicherweise durch Web-Browser. Andere Clients, z.B. WAP-fähige Mobiltelefone oder Personal Digital Assistents, können unterstützt oder, wie im Fall von E-Mail-Anwendungen, für bestimmte Aufgaben benötigt werden. Die Kommunikation der Client-Schicht mit der Server-Schicht des infoAsset Brokers erfolgt über Internet-Pro-

HTTP-Server

Web-Browser

SessionsHandlerTemplates

Assets

DirectoriesConcepts ...Documents Persons

ContentManager

Queries

ContentTypes

Server

Services

Store

Container

...

Interaction

Persistence

ClienteMail-Tools ...

Mail-Server

Internet / Intranet / Extranet

...

Abbildung 5.1: Schichtenarchitektur des infoAsset Brokers [Wegn02]

5 Integration des Synchronisationsmodells

66 67

tokolle (HTTP, FTP, POP, SMTP etc.). Die zentrale Komponente dieser Schicht ist ein Web-Server. Er empfängt Requests der Clients und liefert ihnen die geforderten Daten in einem durch den Client nutzbaren Format.

Die medien- und benutzerabhängige Aufbereitung der auszuliefernden Daten erfolgt in der Interaction-Schicht. Dazu existiert als grundlegender Mechanismus der Handler: Er bearbeitet die Anfragen von Clients und erzeugt die zu versendenden Daten. Um eine eindeutige Trennung von Funktion, Inhalt und Layout zu erreichen, nutzen Handler Templates, d.h. Gestaltungsvorlagen, die, durch die Handler mit den aktuell benötigten Inhalten gefüllt, über die Server-Schicht zurückgeliefert werden. Für die Darstellung von Inhalten durch Web-Browser stehen Templates im Format HTML zur Verfügung; alter-nativ können jedoch auch WAP-Browser durch die Wireless Markup Language (WML) bedient werden.

Die eigentliche Anwendungslogik des Systems befindet sich in der Services-Schicht: Dort sind die semantischen Informationsobjekte wie Personen, Begriffe, Dokumente, Ver-zeichnisse etc. realisiert, die von den Handlern der darüberliegenden Schicht in Anspruch genommen und in Abbildung 5.2 gezeigt werden. Um eine Vereinheitlichung dieser Ob-jekte zu erreichen und ihnen alle generischen Funktionen des Systems zur Verfügung zu stellen, werden sämtliche Informationsobjekte einheitlich als Assets geführt. Die im

Dokument * Person

Mitgliedschaft

Gruppe

* 1

*

*

Verzeichnis

*

*

Begriff* *

Thema Autor

Unterordnung

Spezialisierung

Querverweis

1 * * ** *

Unterverzeichnis

LeserSchreiber

Administrator

* 3

Sammelmappe

1

Besitzer

Asset

*

*

Annotation

Feedback

Experte*

*

Ähnlichkeit

**

KategorieKategorisierung

*

Verlauf

Bewertung

*

*

* *

Stichwort *

*

...

Klassifikation

Aktor

{ordered}

*

{ordered}

Abbildung 5.2: Konzeptuelles Modell der Broker-Services nach [Wegn02]

5.1.1 Architektur

68 69

Hinblick auf das Synchronisationsmodell wesentlichen Eigenschaften eines Assets sind

sein im Portalsystem eindeutiger Identitätskennwert (AssetId) sowie der Zeitpunkt der

letzten Modifikation (LastModifikation); des Weiteren verfügt jedes Asset über eine frei

wählbare Bezeichnung. In Abhängigkeit ihrer Art besitzen Assets weitere Attribute, bei

denen es sich einerseits um Wertattribute verschiedenen Typs (z.B. String oder Integer),

andererseits um auf andere Assets verweisende Referenzattribute handeln kann.

Die Verwaltung von Assets gleicher Art erfolgt mengenoriertiert in einem Objektcontai-

ner. Dieser AssetContainer ist verantwortlich für den Lebenszyklus seiner Inhaltsobjekte,

also das Erstellen und Löschen von sowie die Suche nach Assets mit vorgegebenen Ei-

genschaften.

Die Sicherstellung der Persistenz der erzeugten Assets ist Aufgabe der darunterliegenden

Store-Schicht, wo die transparente Nutzung unterschiedlicher Persistenzmechanismen

ermöglicht wird.

Die wirklichen Persistenzdienste, die üblicherweise von Drittherstellern stammen, be-

finden sich in der Persistence-Schicht. Dabei handelt es sich meist um Datenbank- und

Dateisysteme, jedoch sind auch Content-Management-Systeme, externe Web-Server oder

andere Systeme denkbar. Eine detaillierte Beschreibung der Architektur des infoAsset

Brokers befindet sich in [Wegn02].

Der folgende Abschnitt ist der Erweiterung dieser Architektur um das im vorherigen Ka-

pitel vorgestellte Synchronisationsmodell gewidmet. Der infoAsset Broker soll dabei in

der Rolle eines SyncML-Servers agieren.

5.1.2 Integration des Synchronisationsmodells als Server

Die Integration des Synchronisationsmodells in den infoAsset Broker erfolgt in der Ser-

ver- und der Services-Schicht. Erstgenannte wird um Mechanismen erweitert, die einen

Austausch von SyncML konformen Nachrichten via HTTP ermöglichen. Der Schwer-

punkt des Synchronisationsmodells mit seinen Kernkonzepten LocalDatastore, SyncEn-

gine, SyncTask und SyncSnapshot ist in der Services-Schicht angeordnet. Abbildung 5.3

zeigt die im Folgenden beschriebene Integration.


68 69

Server-Schicht

Die Aufgaben der Server-Schicht im Fokus des serverseitigen Synchronisationsmodells sind das Empfangen und Versenden von SyncML-Nachrichten enthaltenden HTTP-Requests und -Responses sowie die Umwandlung der Nachrichten in ihre objektorien-tierte Repräsentation und umgekehrt (vgl. Kapitel 4.3.1 und 4.3.2).

Zur Lösung dieser Aufgaben stehen zwei Alternativen zur Verfügung: Einerseits kann der bestehende Web-Server des infoAsset Brokers um Methoden zur Verarbeitung und Weiterleitung von SyncML-Requests erweitert werden. Andererseits kann ein zweiter HTTP-Server mit einem vom Web-Server abweichenden HTTP-Port integriert werden, dessen Aufgabe ausschließlich im Bereich der Synchronisation liegt.

Im Rahmen dieser Arbeit wurde aus folgenden Gründen die zweite Variante gewählt: Zum einen sollte das Synchronisationsmodell möglichst „lose“ in den infoAsset Broker integriert werden, um die bestehenden Module so geringfügig wie möglich zu verän-dern. Zum anderen ist es auf diesem Weg möglich, die Ausführung eines unabhängigen SyncML-HTTP-Servers explizit über die Konfigurationseinstellungen des Brokers zu steuern.

Die Server-Schicht des infoAsset Brokers wurde um die Klassen HttpServer und HttpConnection erweitert. Erstere empfängt HTTP-Requests und antwortet mit ent-sprechenden Responses. Handelt es sich um einen SyncML-Request, wird er an die

Abbildung 5.3: Integration des Synchronisationsmodells in den infoAsset Broker

5.1.2 Integration des Synchronisationsmodells als Server

HTTP-Server

Web-Browser

SessionsHandlerTemplates

Assets

DirectoriesDocuments Persons

Server

Services

Interaction

ClienteMail-Tools

Mail-Server

Internet / Intranet / Extranet

SyncML-Client

PersonsDatastore

LocalSystem SyncEngine

SyncTask

SyncMLHTTP-Server

70 71

HttpConnection-Klasse übergeben und die Nachricht in ihre objektorientierte Repräsen-

tation transformiert. Selbige Klasse übergibt die umgewandelte Nachricht an die Klasse

LocalSystem der Services-Schicht, wo ihre Verarbeitung nach Kapitel 4.3.2 beginnt. Die

durch das Synchronisationsmodell generierte Antwort-Nachricht wird über die Http-

Connection-Klasse der HttpServer-Klasse übergeben und von dieser an den Client zu-

rückgeschickt.

Services-Schicht

Der Kern des in Kapitel 4 vorgestellten Synchronisationsmodells ist in der Services-

Schicht des infoAsset Brokers angeordnet. Hier wird, wie im Folgenden beschrieben, der

Zugriff des Synchronisationsmodells auf die Informationsobjekte des Brokers ermög-

licht.

Einer konkreten Realisierung der abstrakten Klasse LocalDatastore wird bei ihrer Initi-

alisierung eine Referenz auf einen AssetContainer übergeben; in der vorliegenden Imp-

lementierung erhält die Klasse PersonsDatastore eine Referenz auf den AssetContainer

Persons. Über die Schnittstelle des AssetContainers materialisiert das LocalDatastore-

Objekt neue sowie bestehende Assets zum Hinzufügen bzw. Ändern von Attributen oder

löscht sie. Die Adressierung bestehender Assets wird durch die in den SyncSnapshot-

Informationen gespeicherten AssetIds vorgenommen. Die Modifikation von Attributen

eines Assets wird über die Schnittstelle des Assets ausgeführt; im Fall von Kontaktinfor-

mationen wird dazu das Asset Person verwendet.

Die persistente Verwaltung der die Synchronisation betreffenden Informationen wurde

unabhängig von den Persistenzdiensten des infoAsset Brokers realisiert; die davon betrof-

fenen Informationen eines SyncSnapshots werden als XML-Dokument gespeichert.

Im Gegensatz zum infoAsset Broker ist eine vollständige Integration des Synchronisati-

onsmodells in Microsoft Exchange aufgrund dessen geschlossener Architektur sehr auf-

wendig. Deshalb erfolgt die Implementierung des Synchronisationsmodells als SyncML-

Client in einer unabhängigen Anwendung, die die Application Programming Interfaces

(APIs) von Exchange verwendet. Diese werden im Folgenden beschrieben.


70 71

5.2 Microsoft Exchange

Microsoft Exchange ist ein Groupware-Server für die Betriebssystemplattform Microsoft

Windows, der u.a. Funktionalitäten zur E-Mail-Kommunikation, zur zentralen Verwal-

tung und Nutzung von Informationen oder zum Instant-Messaging bietet. Neben der

spezialisierten Client-Anwendung Microsoft Outlook können auch Web-Browser und

Instant-Messaging-Applikationen zum Zugriff verwendet werden. Die folgenden Be-

trachtungen beziehen sich auf die Produktversion Microsoft Exchange 2000.

Das Exchange-System nutzt eine Vielzahl von Technologien, die das Betriebssystem Mi-

crosoft Windows 2000 Server zur Verfügung stellt. Hervorzuheben ist in diesem Zusam-

menhang die vollständige Integration in den Verzeichnisdienst ActiveDirectory (AD) und

die Nutzung des Internet-Information-Servers (IIS) zur Bereitstellung von auf TCP/IP

basierenden Kommunikationsprotokollen.

Den Mittelpunkt von Exchange bildet ein zentrales Datenbanksystem, in dem Inhalte

persönlicher Postfächer und öffentlicher Ordner getrennt gespeichert werden. Jedes im

sogenannten Exchange Store abgelegte Informationsobjekt gehört zu einer Inhaltsklasse,

welche die Attribute des Objekts festlegt. Neben den vordefinierten, z.B. Ordner, Kon-

taktordner oder Kontakte, können durch Schemadefinitionen zusätzliche Inhaltsklassen

erstellt werden.

Die Adressierung einzelner Informationsobjekte bzw. der sie enthaltenden Ordner er-

folgt über URLs. Um komplexe Abfragen innerhalb des Datenspeichers zu ermöglichen,

steht mit der Exchange Store Structured Query Language (Exchange Store SQL) eine

komplexe Abfragesprache zur Verfügung, deren Syntax auf der Datenbankabfragesprache

SQL basiert und zur Verwendung mit dem Exchange Store angepasst ist. Im Gegensatz

zu Standard SQL werden jedoch keine Änderungs-, Einfüge- oder Löschoperationen

unterstützt.

Microsoft Exchange stellt eine Vielzahl von Programmierschnittstellen bereit, die einen

Zugriff auf Ressourcen des Exchange Stores ermöglichen. Diese werden im Folgenden

vorgestellt und im Hinblick auf ihre Verwendbarkeit durch das Synchronisationsmodell

betrachtet.

5.2 Microsoft Exchange

72 73

5.2.1 Programmierschnittstellen

Die Kommunikation von spezialisierten Client-Anwendungen wie Microsoft Outlook oder anderen E-Mail-Applikationen erfolgt über das Messaging API (MAPI). Es handelt sich dabei um eine Messaging-Architektur, die verschiedenen Clients einen plattform-übergreifenden Zugriff auf mehrere unterschiedliche E-Mail-Systeme ermöglicht. Die Kommunikation zwischen einem MAPI-Client und -Server findet über Remote Proce-dure Calls (RPCs) statt.

Eine Abstraktion der MAPI-Schnittstelle bilden die auf dem Component Object Model (COM) basierenden Collaboration Data Objects (CDO), d.h. Komponenten zur Er-stellung von kollaborativen Anwendungen, die auf in Microsoft Exchange verwaltete Informationen zugreifen. Die Komponente CDO for Exchange Server (CDOEX) of-feriert Standardobjekte des Exchange Stores: u.a. Ordner-, Kontakteordner-, Kontakte-, Aufgaben- oder Nachrichtenobjekte. Während die Komponente CDO for Workflow (CDOWF) der Erstellung und Verwaltung von Arbeitsprozessen dient, unterstützt CDO for Exchange Management (CDOEXM) die Administration von Exchange Systemen.

Neben den spezifischen Collaboration Data Objects ist auch ein Zugriff über die soge-nannten ActiveX Data Objects (ADO) möglich. Diese Komponente stellt allgemeine Schnittstellen bereit, die einen einheitlichen Zugriff auf unterschiedlich geartete Da-tencontainer heterogener Systeme ermöglichen. Ihre wesentlichen Objekte sind das Connection-Objekt zur Herstellung von Verbindungen zu Datenbanken sowie die

Abbildung 5.4: Datenzugriff über ADO und CDO [Micr03]


72 73

Objekte Record und Recordset, die einen Datensatz oder eine Menge von Datensätzen repräsentieren. Ein Zugriff auf Attribute eines Datensatzes realisieren die Objekte Field bzw. Fields. Der Verwaltung von Datenströmen dient das Objekt Stream.

Die Komponenten ADO und CDO benötigen zum Zugriff auf Datenbanksysteme so-genannte OLE DB Provider, die als Adapter zwischen einem Datenbanksystem und den oben genannten Programmierschnittstellen fungieren. Abbildung 5.4 zeigt die Architek-tur des Datenzugriffs auf Microsoft Exchange über ADO oder CDO und die Rolle von OLE DB.

Neben den vorgestellten proprietären Schnittstellen von Microsoft kann der Exchange Store auch über das Web Distributed Authoring and Versioning Protokoll (WebDAV) an-gesprochen werden. Dabei handelt es sich um eine Erweiterung des HTTP 1.1 Standards um zusätzliche HTTP-Methoden, die eine verteilte Dokumentbearbeitung und Versio-nierung ermöglichen. Informationen in WebDAV-Requests und -Responses werden in Form von XML-Dokumenten übermittelt. Abbildung 5.5 visualisiert die Verwendung von WebDAV in Microsoft Exchange durch einen Web-Browser.

Während die WebDAV-Methoden MOVE, COPY und DELETE dem Verschieben, Ko-pieren und Löschen vollständiger Informationsobjekte dienen, lassen PROPFIND und PROPPATCH das Auslesen und Aktualisieren von Attributen einzelner Informations-objekte zu. Eine Unterstützung zum Sperren von Objekten zwecks Konfliktvermeidung durch gleichzeitige Bearbeitung bieten die Methoden LOCK und UNLOCK. Die Me-thode SEARCH dient dem Durchsuchen der Datenbank und kann zur Übermittlung von Abfragen in Exchange Store SQL genutzt werden.

5.2.2 Integration des Synchronisationsmodells als Client

Abbildung 5.5: Verwendung von WebDAV durch einen Web-Browser [Micr03]

74 75

Das in der vorliegenden Arbeit realisierte Synchronisationsmodell benutzt zum Zugriff

auf in Microsoft Exchange gespeicherte Informationsobjekte die Technologien ADO und

CDO sowie WebDAV, deren Verwendung im Folgenden beschrieben wird.

5.2.2 Integration des Synchronisationsmodells als Client

Im Gegensatz zu der vollständigen Integration des Synchronisationsmodells in den

infoAsset Broker wurde es zur Verwendung mit Microsoft Exchange als unabhängige

SyncML-Client-Applikation implementiert.

Der Zugriff auf den Exchange Store über WebDAV wird von einem LocalDatastore an

zwei Stellen genutzt: Einerseits werden auf diese Weise die Id, der Zeitpunkt der letzten

Änderung und die URL aller aktuell vorhandenen Informationsobjekte eines Kontak-

teordners abgefragt. Hierzu wird ein SEARCH-Request verwendet, der mit folgender

Exchange Store SQL-Abfrage parametrisiert wird:

<?xml version=‘1.0‘?><d:searchrequest xmlns:d =‘DAV:‘> <d:sql> SELECT ‘DAV:id‘, ‘DAV:getlastmodified‘, ‘DAV:href‘ FROM ‘http://ExchangeStore/Contacts‘ WHERE „DAV:ishidden“ = false AND „DAV:isfolder“ = false </d:sql></d:searchrequest>

Andererseits findet ein DELETE-Request Anwendung, um einzelne Informationsobjek-

te aus dem Exchange Store zu löschen. Das Objekt wird dabei lediglich über seine URL

adressiert, da der Request keine weiteren Parameter benötigt.

Das Hinzufügen und Ändern von Informationsobjekten erfolgt durch Erstellen und

Modifizieren von CDO-Objekten, auf die über ein ADO-Connection-Objekt zugegriffen

wird. Die Adressierung der Objekte erfolgt durch die im oben beschriebenen SEARCH-

Request ermittelte URL eines Informationsobjekts.


74 75

5.3 Zusammenfassung

Abbildung 5.6 zeigt das in dieser Arbeit entwickelte Synchronisationsszenario zur Syn-chronisation von Informationsobjekten zwischen Microsoft Exchange und dem infoAsset Broker.

Der um das in Kapitel 4 vorgestellte Synchronisationsmodell erweiterte infoAsset Broker bildet den SyncML-Server, seine Umsetzung als unabhängige Client-Anwendung zu-sammen mit Microsoft Exchange den SyncML-Client. Der Nachrichtenaustausch erfolgt dabei durch das Protokoll HTTP; die Implementierung nutzt zur Übertragung von In-formationsobjekten das MIME-Format vCard [ietf98].

SyncML ClientSyncML Server

infoAssetBroker

MicrosoftExchange

SyncServer HTTP

WebDAV

ADO/CDO

WebDAV

ADO/CDOSyncClient

Abbildung 5.6: Synchronisationsszenario

5.3 Zusammenfassung

77

77

Kapitel 6

Zusammenfassung und Ausblick

In diesem Kapitel wird zunächst eine Zusammenfassung der Arbeit gegeben, die ab-schließend durch einen Ausblick über Erweiterungsmöglichkeiten und eventuelle Folge-arbeiten komplettiert wird.

6.1 Zusammenfassung

Im Rahmen dieser Arbeit wurde ein Synchronisationmodell für die Synchronisation von Informationsobjekten zwischen dem Informationsportal infoAsset Broker und dem Groupwaresystem Microsoft Exchange entwickelt und exemplarisch zur Synchronisation von Kontaktinformationen implementiert.

Zunächst wurde auf Grundlage der gleichzeitigen Nutzung heterogener Systeme inner-halb einer Organisation der Bedarf des Abgleichens von semantisch identischen Inform-tionsobjekten analysiert und der Begriff der Synchronisation in diesem Zusammenhang eingeführt. Es wurden Aspekte betrachtet, die für die Synchronisation im Allgemeinen und im Speziellen für die Synchronisation von heterogenen Systemen von Bedeutung sind.

Des Weiteren wurde der auf XML basierende Synchronisationsstandard SyncML erar-beitet und dessen wesentliche Spezifikationen detailliert beschrieben. Obwohl SyncML

78 79

initial zur Synchronisation von Daten zwischen mobilen und stationären Systemen ent-wickelt wurde, eignen sich seine Mechanismen ebenso zum Abgleichen von komplexen Systemen.

Auf der Basis von SyncML wurde ein allgemeines Synchronisationsmodell entworfen, dessen Konzeption gleichermaßen als SyncML-Client und -Server verwendet werden kann. Die Kernaspekte dieses Modells sind:

• die Erstellung und Verarbeitung von SyncML-konformen Nachrichten, die zwischen Client- und Server-System ausgetauscht werden;

• das systemunabhängige Erkennen von Änderungen einzelner Informations-objekte, die zwischen zwei Synchronisationsvorgängen erfolgt sind;

• das Abgleichen von Informationsobjekten, die über unterschiedliche Daten-repräsentationen auf den einzelnen Systemen verfügen.

Das Synchronisationsmodell wurde als SyncML-Server in das Informationsportal infoAs-set Broker integriert. Außerdem wurde eine unabhängige SyncML-Client-Applikation realisiert, die über unterschiedliche Schnittstellen auf in Microsoft Exchange verwaltete Informationsobjekte zugreift.

6.2 Ausblick

Der Fokus des in dieser Arbeit betrachteten Synchronisationsszenarios lag in der Reali-sierung eines grundsätzlichen Synchronisationsmechanismus zwischen dem infoAsset Broker und Microsoft Exchange. Der verwendete Synchronisationstandart SyncML wur-de dabei nur in essenziellen Teilen implementiert, so dass sich in folgenden Bereichen Erweiterungsmöglichkeiten bieten:

• In der vorliegenden Implementierung wurden lediglich die Synchronisations-typen Two-Way-Sync und Slow-Sync umgesetzt. Die Vervollständigung des Synchronisationsmodells um die weiteren unidirektionalen Synchronisati-onstypen ist wünschenswert.

• Eine vollständige Auswertung von Geräteinformationen sollte realisiert werden, um einen effizienten Datenaustausch zwischen den Systemen zu ermöglichen. In diesem Zusammenhang ist auch die Erweiterung des Kon-zepts ContentType um eine Beschreibung verwendeter Attribute zu nennen.

6 Zusammenfassung und Ausblick

78 79

• Die Einführung komplexer Konfliktlösungsstrategien sowie die Implemen-tierung von Merging-Strategien können durch Mechanismen zur Identifi-kation von semantisch zusammengehörenden Informationsobjekten unter-stützt werden.

Die Ausweitungsmöglichkeiten demonstrieren einen expliziten Bedarf weiterer Untersu-chungen. Das vorliegende Modell kann als Ausgangspunkt gezielter Überlegungen ver-wendet und in den genannten Bereichen durch weiterführende Arbeiten vervollständigt werden.

6.2 Ausblick

80 81

Literaturverzeichnis

[Buch02] Buchmann, David: SyncML (Synchronization Markup Language) and its Java Implementation sync4j. Diploma Thesis, University of Fribourg, 2002.

[Dude93] Duden «Informatik»: ein Sachlexikon für Studium und Praxis. Mannheim, Leipzig, Wien, Zürich: Dudenverlag, 1993. ISBN 3-411-05232-5.

[FoSc00] Fowler, Martin; Scott, Kendall: UML konzentriert. Eine Einführung in die Standard-Objektmodellierungssprache. 2. Auflage. Addison-Wesley Verlag, 2000, ISBN 3-8273-1617-0.

[Hewl02] Hewlett-Packard Company: Portal Typologie, 2002.http://www.hewlett-packard.de/solution/portale/b2e_typ.html

[KLT00] Koenemann, Jürgen; Lindner, Hans-Günther; Thomas, Christoph: Unter-nehmensportale: Von Suchmaschinen zum Wissensmanagement. In: nfd Information - Wissenschaft und Praxis 51 (2000), September, Nr. 6, S. 325-334.

[ietf98] Internet Engineering Task Force: vCard MIME Directory Profile. Septem-ber 1998.http://www.ietf.org/rfc/rfc2426.txt

[info03] infoAsset AG: Website, Oktober 2003.http://www.infoasset.de

[Inse01] Inselkammer, Frank: Seminar aus Informationsmanagement: SyncML. Universität Wien, 2001.

80 81

[Lehe02] Lehel, Vanda: Synchronisation von Informationsobjekten zwischen Porta-len. Diplomarbeit, Technische Universität Hamburg-Harburg, 2002.

[Micr03] Microsoft Corporation: Microsoft Exchange Software Development Kit. März 2003.

[Mrow01] Mrowczynski, Mirko: Synchronisation von Terminplaner mittels XML. Diplomarbeit, Technische Universität Chemnitz, 2001.

[Ried03] Riedel, Sebastian: Entwicklung eines Modells, Verfahrens und softwaretech-nischen Rahmenwerks für Record Linkage in semantischen Netzen. Diplo-marbeit, Technische Universität Hamburg-Harburg, 2003.

[Stei96] Stein, Dominik: Definition und Klassifikation der Begriffswelt um CSCW, Workgroup Computing, Groupware, Workflow Management. Seminarar-beit, Universität Gesamthochschule Essen, 1996.

[Syba00] Sybase Inc.: Replikation und Synchronisierung. 2000.http://download.sybase.com/pdfdocs/awg0702g/dbrsde7.pdf

[SyML02a] SyncML Synchronization Protocol, version 1.1.1.http://www.openmobilealliance.org/syncml/docs/syncml_sync_protocol_v11_20020215.pdf

[SyML02b] SyncML Representation Protocol, version 1.1.1.http://www.openmobilealliance.org/syncml/docs/syncml_represent_v11_20020215.pdf

[SyML02c] SyncML Representation Protocol, Data Synchronization Usage, version 1.1.1.http://www.openmobilealliance.org/syncml/docs/syncml_sync_represent_v11_20020215.pdf

[SyML02d] SyncML HTTP Binding, version 1.1.1.http://www.openmobilealliance.org/syncml/docs/syncml_http_v11_20020215.pdf

[SyML02e] SyncML Meta-Information DTD, version 1.1.1.http://www.openmobilealliance.org/syncml/docs/syncml_metinf_v11_20020215.pdf

82

[SyML02f] SyncML Device Information DTD, version 1.1.1.http://www.openmobilealliance.org/syncml/docs/syncml_devinf_v11_20020215.pdf

[Wagn94] Wagner, Michael P.: Elektronische Debatte: Von EMail bis Workflow Ma-nagement - Groupware heute. In: iX, Multiuser Multitasking Magazin, 1994, Februar, S. 112ff.

[Wegn02] Wegner, Holm: Analyse und objektorientierter Entwurf eines integrierten Portalsystems für das Wissensmanagement. Technische Universität Hamburg-Harburg, Arbeitsbereich Softwaresysteme, Dissertation, 2002.