ZWISCHEN PORTALEN. Vanda Lehel Studiengang Informatik-Ingenieurwesen Technische Universität Hamburg-Harburg

Transkript

1 DIPLOMARBEIT SYNCHRONISATION VON INFORMATIONSOBJEKTEN ZWISCHEN PORTALEN Vanda Lehel Studiengang Informatik-Ingenieurwesen Technische Universität Hamburg-Harburg Erstbetreuung Prof. Dr. Florian Matthes Arbeitsbereich Softwaresysteme Technische Universität Hamburg-Harburg Zweitbetreuung Prof. Dr. Friedrich H. Vogt Arbeitsbereich Telematik Technische Universität Hamburg-Harburg Hamburg, im September 2002

2 ii

3 Inhaltsverzeichnis 1 Einleitung Ziel der Arbeit Gliederung Motivation Informationsportale Definition und Klassifikation Nutzungsszenarien Synchronisationsbedarf Synchronisation Begriffsklärung Aspekte der Synchronisation Synchronisation von Informationsobjekten Synchronisationsebenen, -techniken und -lösungen Synchronisation auf Dateisystemebene Dateisystemwerkzeuge Build-Werkzeuge Versionskontrollsysteme Synchronisation auf Datenbankebene Single-Master Replikation und Snapshots Multimaster Replikation Synchronisation auf Applikationsebene MS Outlook/Exchange Server Lotus Notes/Domino Mobile Clients Der Synchronisationsstandard SyncML Grundlagen Die Metasprache XML Das SyncML Framework Spezifikation des Repräsentationsprotokolls Spezifikation des Synchronisationsprotokolls Referenzimplementierungen von SyncML iii

4 iv INHALTSVERZEICHNIS 5 Der infoasset Broker Die Architektur des infoasset Broker Portals Das Objektmodell der Broker-Services Technische Anforderungen an das Synchronisationsmodell Das Synchronisationsmodell für das Portal infoasset Broker Anforderungen an das Modell aus Sicht des CSCW Das konzeptuelle Synchronisationsmodell Synchronisationslinks Synchronisationsaufgaben Synchronisationsaktionen und -operationen Der Synchronisationsvorgang Bestimmung der zu synchronisierenden Objektmengen Identifikation von korrespondierenden Objekten Bestimmung der Synchronisationsaktionen Ausführung der Synchronisationsaktionen Kommunikationsphasen zwischen den Portalen Ergänzende Aspekte Semantisches Matching von Informationsobjekten Anwendung von Merging-Strategien Identifikation gelöschter Informationsobjekte Selektierbare Zuweisung von Objektreferenzen Zeitsynchronisation zwischen den Portalen Versionshistorie Berechtigungskonzepte Transaktionssicherheit Umsetzung des Synchronisationsmodells im infoasset Broker Komponenten des Modells im infoasset Broker Implementierung des Synchronisationsvorgangs Ablauf des Synchronisationsvorgangs Die SynchronisationMessages Das Synchronisationsprotokoll Der Synchronisationsclient Umsetzung der prädikativen Filter Handler und Templates Das Web-Interface des Synchronisationsclients Zusammenfassung und Ausblick Zusammenfassung Ausblick

5 INHALTSVERZEICHNIS v Anhang A Konzeptuelles Klassendiagramm des Synchronisationsclients B Packages für die Synchronisation C Operationen der ActionPolicies D Entwicklungsumgebung Literaturverzeichnis

6 vi INHALTSVERZEICHNIS

7 Abbildungsverzeichnis 2.1 Arten von Portalen nach [Hewl02] Ebenen eines Informationsportals nach [JTB00] Taxonomie von Portalen nach [Wegn02] Unternehmensportal mit klassischer Client/Server Architektur Peer-to-peer Architektur zweier Informationsportale Synchronisation zwischen Portalen Objektmodifikationen durch Prozesse Abbilden der Objekte zwischen den Portalen Referenzbeziehungen zwischen Objekten in Objektcontainern Single-Master Replikation [BeNe97] Multimaster Replikation Typisches Groupware-Synchronisationsszenario Synchronisationsszenarien im heterogenen Umfeld Das SyncML Framework [SyML01b] Schematischer Aufbau einer SyncML Package Beispiel einer SyncML Message [Sync02] Kommunikationsphasen zur Initialisierung der Synchronisation [SyML01a] Verwendung des Sync Anchors [SyML01a] Kommunikationsphasen beim Two-way-sync [SyML01a] Architektur-Übersicht des infoasset Brokers [Wegn00] Konzeptuelles Modell der Broker-Services nach [Wegn02] Generisches Objektmodell der Broker-Services Informationsobjekte des Portals im Fokus der Synchronisation Anwendungsfalldiagramm für den Synchronisationsclient Typisches Szenario der Benutzeraktivitäten Konzeptuelles Synchronisationsmodell des Synchronisationsclients Binäre Synchronisation zwischen zwei Portalen Mehrere Synchronisationslinks für ein Server-Portal Attribute und Beziehung der Klassen SynchronisationLink und RemoteConnection Abbilden korrespondierender Objekte durch die Mapping Tabelle Attribute der Klasse AssetSynchronisationState vii

8 viii ABBILDUNGSVERZEICHNIS 6.9 Zeitachse von Synchronisationsvorgängen durch verschiedene Synchronisationslinks L 1 und L 2 mit dem gleichen Server-Portal Synchronisation von Informationsobjekten zwischen typisierten Containern Beispiel - Semantik einer Synchronisationsaufgabe Attribute der Klasse SynchronisationTask Ausschnitt aus dem konzeptuellen Klassendiagramm bezogen auf die Klasse SynchronisationAction Synchronisationsphasen des Synchronisationsvorgangs Venn-Diagramm der Teilmengen E i, A j, R k Venn-Diagramm der Mengen S ER und S EI Mögliche Zustände einer Synchronisationsaktion während des Synchronisationsvorgangs Änderung der Synchronisationsrichtung von Objekten nach Synchronisationsphase I Synchronisationsphase I mit zwei Kommunikationsphasen zwischen den Portalen Synchronisationsphase II mit einer Kommunikationsphase zwischen den Portalen Die Klasse ReferenceMapping Synchronisation mit Versionshistorien Komponenten des Synchronisationsmodells im infoasset Broker Konzeptuelles Klassendiagramm zum Synchronisationsvorgang Zustände einer lokalen SynchronisationEngine während einer Session Art des Informationsaustausches zwischen den beteiligten Komponenten der beiden Portale Interaktionsschritte der beteiligten Klassen für die Synchronisationsphase I (Teil 1) Interaktionsschritte der beteiligten Klassen für die Synchronisationsphase I (Teil 2) Serialisierte SynchronisationMessage in einem SOAP-Envelope DTD-Format der serialisierten SynchronisationMessage Generisches Objektmodell der Assets und Searches Details eines Synchronisationslinks im Dialog synchronisationlinks/default.htm Definition eines prädikativen Filters in der Synchronisationsaufgabe im Dialog synchronisationtasks/default.htm Auswahl der Synchronisationsoperationen im Dialog synchronisationactions/default.htm Navigation in den Dialogen des Synchronisationsclients A.1 Konzeptuelles Klassendiagramm des Synchronisationsclients

9 Tabellenverzeichnis 4.1 SyncML Synchronisationsszenarien nach [SyML01a] Zusammenhang zwischen dem Modus der Synchronisationsaufgabe und dem Synchronisationsmodus Synchronisationsoperationen in Abhängigkeit der betroffenen Objekte Mögliche Synchronisationsoperationen in den einzelnen Modi der ActionPolicies ActionPolicies im Modus Einschluss ActionPolicies im Modus Erzwingen in Richtung Publizieren ActionPolicies im Modus Erzwingen in Richtung Übernehmen Beispiel für vollständige Einträge einer Mapping Tabelle Bestimmung der Zustandsänderung eines Objektes Parameter und Ausführungsort der Synchronisationsoperationen Beispiel für die Einträge einer Referenztabelle Nachrichtentypen in den Kommunikationsphasen Nachrichtentypen und enthaltene Container Sichtbare Handler des Synchronisationsclients Unsichtbare Handler des Synchronisationsclients B.1 Packages für die Synchronisation D.1 Systemeigenschaften der Entwicklungsumgebung D.2 Entwicklungstools für die Implementierung des Synchronisationsmodells ix

10 x TABELLENVERZEICHNIS

11 xi Danksagung Ich möchte Prof. Dr. Florian Matthes für das interessante Thema und die intensive Erstbetreuung der vorliegenden Arbeit herzlich danken. Ferner bedanke ich mich bei Prof. Dr. Friedrich H. Vogt für die Zweitbetreuung. Besonderen Dank an Patrick Hupe für die Betreuung und die hilfreichen Kommentare bei der Durchsicht der Arbeit. Meinem Vater, Dr. Csaba Lehel, danke ich ebenfalls für die Unterstützung. Weiterhin möchte ich an dieser Stelle allen danken, die zum Gelingen dieser Arbeit beigetragen haben.

12 xii

13 Kapitel 1 Einleitung Das Internet hat sich mittlerweile zu einem globalen Kommunikationsmedium entwickelt, über das ein breites Spektrum an Informationen und Diensten auf standardisierte Weise erreichbar ist. Gegenüber der ersten Generation von Web-Anwendungen, basierend auf statischen Seiten, steht gegenwärtig durch die rasante Weiterentwicklung von Web-Technologien eine dynamische Darstellung von Inhalten im Vordergrund. Die Anwendungsmöglichkeiten des Internets konnten dadurch beträchtlich ausgeweitet werden. Aus diesem Grund wird der Alltag sowohl im privaten als auch im öffentlichen Bereich zunehmend durch die Nutzung des Internets dominiert. Zum einen bildet das Internet eine Plattform für Inhalte von kommerziellen Unternehmensinformationen sowie von Inhalten privater Art (Homepages). Andererseits stellen Dienste den Zugang zu Echtzeit-Inhalten wie Nachrichten, Wetterinformationen oder Fluginformationen zur Verfügung. Diese Dienste und Inhalte zielen dabei auf eine breit zugängliche Nutzung ab und bilden die öffentlichen Informationsquellen des Internets. Darüber hinaus zeichnet sich sowohl im privaten und kommerziellen als auch im wissenschaftlichen und öffentlichen Bereich der Trend zur Digitalisierung und elektronischen Verwaltung von Informationen ab. Die Informationen stammen dabei aus den verschiedensten Gebieten, die über digitalisierte oder digitalisierbare Informationen verfügen. Diese können persönliche Dokumente, Bestellinformationen, Projektunterlagen, Anmeldeformulare u. a. sein. Das Internet kann dabei als Basis verwendet werden, um Informationen aller Arten in Informationsbeständen web-basiert zu verwalten und damit auch zur kooperativen Nutzung zur Verfügung zu stellen. Eine Lösung hierfür stellen Informationsportale als web-basierte Softwaresysteme dar, die eine Informations- und Wissensverwaltung vernetzter Inhalte ermöglichen. In persönlichen Informationsportalen umfasst der Informationsbestand private Informationen wie Kontakte, Termine, Notizen, Fotos, Urkunden, Verträge oder eigene Publikationen als digitale Dokumente. Demgegenüber werden in Unternehmensportalen Benutzerprofile, interne Mitarbeiterinformationen, Kundendaten, Projektinformationen und vergleichbare Inhalte 1

14 2 KAPITEL 1. EINLEITUNG verwaltet. Jeder dieser Informationsbestände, der über ein Portal zugreifbar ist, bildet ebenfalls eine Informationsquelle im Internet. Über das Internet wird nun ein Austausch der Daten zwischen Informationsquellen ermöglicht. Die Infrastruktur des Internets führt somit zu einer globalen Vernetzung von Informationsquellen. Das Internet stellt dabei einen Zugriffsmechanismus auf Informationen in einer verteilten Umgebung bereit, in der sowohl standortgebundene als auch mobile Systeme mit eigenen Informationsbeständen miteinander kommunizieren können. Dadurch ergeben sich Nutzungsszenarien, bei denen Inhalte eines Portals auf einem anderen System offline bearbeitet werden. Dies führt dazu, dass Informationen einzelner Informationsquellen in Abhängigkeit stehen. Ein solches Szenario impliziert eine Umgebung, in der logisch zusammengehörige Informationen räumlich verteilt, d. h. auf mehreren Systemen, sowie zeitlich verteilt, also in mehreren Versionen, existieren können. In einer solchen verteilten Umgebung stellt die Sicherstellung der Integrität der Informationen eine qualitativ neue Anforderung an die Systeme gegenüber der zentralen Verwaltung eines Informationsbestandes. Inhaltlich zusammengehörige Informationen müssen zwischen verteilten Systemen abgeglichen und in einen konsistenten Zustand überführt werden. Dies kann durch Synchronisationsmechanismen realisiert werden. 1.1 Ziel der Arbeit In der vorliegenden Arbeit soll ein Modell für die Synchronisation von Informationsobjekten zwischen zwei Portalen entworfen und prototypisch realisiert werden. Beim verwendeten Portal handelt es sich um das Informationsportal infoasset Broker der Firma infoasset. Dies umfasst eine fachliche Anforderungsanalyse von Nutzungsszenarien, um den Synchronisationsmechanismus speziell als unterstützendes Werkzeug für Nutzer eines Portals zu konzipieren. Zudem sollen technische Anforderungen an das Modell für eine Integration in das infoasset Broker Portal berücksichtigt werden. Zum einen werden dafür allgemeine Synchronisationsaspekte sowie spezielle Eigenschaften von Informationsobjekten untersucht, um diese im Synchronisationsmodell miteinander zu verknüpfen. Andererseits fließen auch Konzepte untersuchter Synchronisationstechniken und - lösungen auf einzelnen Synchronisationsebenen eines Systems in das Modell sowie seine Umsetzung mit ein. In diesem Zusammenhang sollen auch Lösungsmöglichkeiten für Erweiterungen des Synchronisationsmodells dargestellt werden. Weiterführendes Ziel ist, eine Basis für die Umsetzung von Synchronisationsszenarien im heterogenen Umfeld zu bieten.

15 3 1.2 Gliederung Kapitel 2 führt zunächst die wesentlichen, zentralen Konzepte für die vorliegende Arbeit, nämlich Informationsportale und Synchronisation, ein und setzt diese in Relation zueinander. Darauf aufbauend werden in Kapitel 3 Synchronisationstechniken und bereits existierende Werkzeuge und Lösungen auf den Ebenen von Dateisystemen, Datenbanken sowie Applikationen betrachtet. Kapitel 4 behandelt den Synchronisationsstandard SyncML. Dabei werden erst die Grundlagen erläutert und anschließend genauer auf die Spezifikation sowie vorhandene Implementierungen eingegangen. In Kapitel 5 werden die Architektur sowie das für die Synchronisation relevante Objektmodell des infoasset Broker Portals dargestellt. Folgend werden technische Anforderungen für die Synchronisation zweier infoasset Broker Portale zusammengestellt. Das entworfene Synchronisationsmodell wird in Kapitel 6 detailliert beschrieben und durch weiterführende Aspekte vervollständigt. Implementierungsdetails der Umsetzung im infoasset Broker Portal finden sich in Kapitel 7. Kapitel 8 gibt abschließend eine Zusammenfassung über die Arbeit sowie einen Ausblick auf Erweiterungsmöglichkeiten des vorgestellten Synchronisationsmodells und komplexere Synchronisationsszenarien.

16 4 KAPITEL 1. EINLEITUNG

17 Kapitel 2 Motivation Dieses Kapitel dient der Einführung sowie Einordnung von Begriffen und Konzepten, auf denen nachfolgende Teile der Arbeit aufbauen. Kapitel 2.1 beschreibt Informationsportale im allgemeinen. Im Rahmen des dabei vorgestellten Kontexts wird in Kapitel 2.2 anschließend der Begriff der Synchronisation eingeführt. 2.1 Informationsportale In diesem Kapitel werden Informationsportale vorgestellt, da sie für die vorliegende Arbeit eine wesentliche Rolle spielen. Die ersten beiden Unterabschnitte sind der Definition und Klassifikation sowie der Erläuterung relevanter Nutzungsszenarien von Informationsportalen gewidmet. Anschließend wird der Bedarf einer Synchronisationsmöglichkeit zwischen Portalen diskutiert Definition und Klassifikation Zunächst wird der Begriff des Informationsportals eingeführt, das eine speziellere Ausprägung eines Web-Portals darstellt. Die Begriffe Web-Portal und Portal werden in diesem Zusammenhang entsprechend [Wegn02] synonym verwendet. Nach [KLT00] lautet die Definition eines Web-Portals wie folgt: 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. 5

18 6 KAPITEL 2. MOTIVATION Es gibt unterschiedliche Arten von Portalen, die nach bestimmten Kriterien klassifiziert werden können. Wie in Abbildung 2.1 dargestellt, ist eine Klassifikation möglich, nach der sich die Portal-Eigenschaften in intern und extern sowie privat und öffentlich gliedern lassen. Hier ordnet sich ein Informationsportal als ein internes Portal für einen ausgewählten, registrierten Benutzerkreis ein, das seinen Nutzern Dienste und Inhalte sowohl privater als auch öffentlicher Art anbietet. Allerdings richtet sich der Fokus auf die Verwaltung privater Informationsbestände. Abbildung 2.1: Arten von Portalen nach [Hewl02] Informationsportale bieten somit einen uniformen, personalisierten Zugang über Internet- Technologien zu Informationen für verschiedene Benutzerkreise an [Wegn02]. Eine wesentliche Funktionalität ist die Unterstützung des Wissensmanagements; unter anderem in den Bereichen inhaltliche Erschließung, thematische Klassifikation, Verteilung und Bewahrung von Wissen. Dabei integrieren Informationsportale strukturierte und unstrukturierte Inhalte unterschiedlicher Informationsquellen. Durch das Portal werden ein transparenter und kontrollierter Zugriff auf die Inhalte sowie eine personalisierte Präsentation ermöglicht. Außerdem stehen Nutzern des Portals verschiedene Dienste und Werkzeuge zum Informationsgewinnung zur Verfügung. Diese Funktionalität wird im allgemeinen durch verschiedene Portal-Ebenen realisiert, die als eine Mehrschichten- Architektur umgesetzt werden, vgl. Abbildung 2.2.

19 7 Front End Middle Tier Back End Abbildung 2.2: Ebenen eines Informationsportals nach [JTB00] Die Inhalte von Portalen werden durch Informationsobjekte repräsentiert, die Entitäten des Systems beschreiben. Wesentliche Portal-übergreifende, also nicht für die Verwendung in einem speziellen Portal beschränkte, Informationsobjekte sind nach [MaLe02b] einerseits Dokumente, die das explizite Wissen beschreiben, sowie Personenprofile zur Repräsentation des impliziten Wissens. Andererseits spielen auch Verzeichnisse und Gruppen eine ergänzende Rolle als generalisierende Mechanismen zur strukturierten Verwaltung von Informationsobjekten sowie für eine rollenbasierte Rechtevergabe zum Zugriff auf Informationsobjekte. Weiterhin werden Begriffe einer im Portal den Inhalten zugrunde liegenden, verbindlichen Taxonomie zur Unterstützung der inhaltlichen Erschließung von wissensrelevanten Informationsobjekten verwendet. Des weiteren lassen sich Portale auch nach dem Gesichtspunkt klassifizieren, ob es sich bei einem Portal um ein horizontales oder ein vertikales Portal handelt, vgl. Abbildung 2.3. Dieser Unterscheidung wird das Merkmal zugrundegelegt, ob die in einem Portal vorhandenen Informationen ein monolithisches Spektrum an Themengebieten abdecken. Trifft dies zu, handelt es sich um ein vertikales, andernfalls um ein horizontales Portal. Abbildung 2.3: Taxonomie von Portalen nach [Wegn02]

20 8 KAPITEL 2. MOTIVATION Nutzungsszenarien Die integrierten Inhalte von Informationsportalen können aus verschiedenen Bereichen stammen, also je nach Verwendung des Portals unterschiedlicher, spezieller Art sein. Beispiele für vertikale Portale sind Unternehmensportale sowie persönliche Informationsportale: Ein Unternehmensportal beinhaltet unternehmensrelevantes Wissen, zusammengefasst aus Internet-Quellen, Datenbanken und anderen unternehmensspezifischen digitalen Quellen, und macht diese den Mitarbeitern und Kunden rollenbasiert und personalisiert zugänglich (siehe [KLT00]). Ein persönliches Informationsportal dient demgegenüber der persönlichen Verwaltung von digital gespeicherten Daten und Informationen aus den verschiedensten Anwendungsbereichen durch einen Privatnutzer, der diese über das Portal auch zur kooperativen Nutzung zur Verfügung stellen kann. Unternehmensportale sind für die Integration der Inhalte im wesentlichen firmenspezifischer Informationsbestände zuständig. Diese können Inhalte aus Dokument-Management-Systemen (DMS), Content-Management-Systemen (CMS), Datenbank-Management-Systemen (DBMS) sowie auch Echtzeit-Inhalte sein. Des weiteren verfügen die Portale über eine Benutzerverwaltung, wobei neben Benutzerinformationen auch Nutzerprofile verwaltet werden, um eine personalisierte Präsentation der vorhandenen Inhalte zu ermöglichen. Aufgabe des Unternehmensportals ist zum einen die effiziente und effektive Werkzeugunterstützung des einzelnen Nutzers beim Informationsmanagement. Zum anderen gibt es auch Dienste und Werkzeuge, die der Unterstützung des CSCW (Computer Supported Cooperative Work) dienen. Nach [Elli91] unterstützen CSCW-Systeme eine Gruppe von Menschen bei ihrer gemeinsamen Aufgabe und stellen eine Schnittstelle zu einer gemeinsamen Umgebung bereit. Für ein Unternehmensportal ist dies eine typische Anforderung, um Nutzer(gruppen) bei der kooperativen Abwicklung von Geschäftsvorgängen zu unterstützen (vgl. [Lehe01]). Da Unternehmensportale gewöhnlich eine klassische Client/Server-Architektur aufweisen, erfolgt die Nutzung eines Unternehmensportals typischerweise durch einen zustandslosen Thin Client. Dadurch ergibt sich ein Modell, bei dem der Privatnutzer mit Hilfe eines HTML-Clients (z. B. Webbrowser auf dem persönlichen Endgerät) durch die web-basierte Benutzeroberfläche des Unternehmensportals, also des Servers, navigiert. Dabei nutzt er Dienste und Werkzeuge zur Informationsverarbeitung. Während der Kommunikation des Clients mit dem Unternehmensportal werden die angeforderten Inhalte vom Server dem Client übermittelt. Die entgegengesetzte Richtung für die Übermittlung von Inhalten (beispielsweise eine Datei vom Client hochzuladen) bildet hier eher die Ausnahme.

21 9 Der Privatnutzer greift somit in diesem Nutzungsszenario unmittelbar auf den zentral verwalteten Informationsbestand des Unternehmensportals zu und arbeitet auf den server-seitig existierenden Informationsobjekten. Nachfolgend stellt Abbildung 2.4 das beschriebene Modell eines Unternehmensportals dar. Persönliches Endgerät Unternehmensserver Privatnutzer Internet DBMS HTML-Client HTTP Unternehmensportal (Server) CMS DMS Nutzerprofile Abbildung 2.4: Unternehmensportal mit klassischer Client/Server - Architektur Ausgehend von diesem Modell können aber auch die Client-Systeme als Portale, in diesem Fall als persönliche Informationsportale, betrachtet werden. Diese sind autonom und verwalten einen eigenen Informationsbestand (siehe Abbildung 2.5). Der Privatnutzer arbeitet in diesem Szenario typischerweise auf den lokalen Informationsobjekten des persönlichen Informationsportals. Dies kann einerseits Objekte betreffen, die nur client-seitig vorhanden sind. Andererseits ist in diesem Modell auch das Offline-Arbeiten an Objekten vorstellbar, die aus dem Informationsbestand des Unternehmensportals stammen und zum Bearbeiten auf das persönliche Informationsportal übertragen wurden. Die Informationsbestände des Unternehmensportals und des persönlichen Informationsportals sind somit voneinander abhängig. Es gibt Informationsobjekte, die auf beiden Portalen existieren, aber inhaltlich nur ein Objekt darstellen. Infolgedessen entsteht eine dezentrale Verwaltung des Informationsbestandes, wobei logisch zusammengehörige Daten sich unabhängig voneinander ändern können. In diesem Fall ist ein bidirektionaler Informationsaustausch zwischen Client und Server erforderlich, um die Unterschiede sich entsprechender Informationsobjekte auszugleichen und diese dadurch wieder auf beiden Portalen in einen konsistenten Zustand zu überführen. Da die Repräsentation der Informationsobjekte auf den beiden Portalen voneinander abweichen kann, müssen sich entsprechende Objekte nicht notwendigerweise identisch sein. Ein konsistenter Zustand der Informationsobjekte tritt ein, wenn ein Ausgleich der Objektzustände nach festgelegten Regeln, die zwischen den Portalen vereinbart sind, erfolgt ist. Das Modell für diese Architektur ist in Abbildung 2.5 dargestellt.

22 10 KAPITEL 2. MOTIVATION Persönliches Endgerät HTTP Internet Unternehmensserver HTTP Privatnutzer HTML- Client Persönliches Informationsportal (Peer) Synchronisationsprotokoll Unternehmensportal (Peer) DBMS CMS DMS Nutzerprofile DBMS CMS DMS Nutzerprofile Abbildung 2.5: Peer-to-peer Architektur zweier Informationsportale Synchronisationsbedarf Aus dem in Abbildung 2.5 vorgestellten Nutzungsszenario ergibt sich die Notwendigkeit einer Synchronisation zwischen den beiden Portalen zum Ausgleich der Zustandsänderungen sich entsprechender und damit korrespondierender Informationsobjekte. Dafür ist also ein Synchronisationsmechanismus erforderlich, der eine Synchronisation von Informationsobjekten zwischen jeweils zwei Portalen ermöglicht. Dies ist in Abbildung 2.6 an den dunkel gefärbten Portalen gezeigt. Die Synchronisationslinks, die die Regeln für die Synchronisation zweier Informationsportale festlegen, sind durch ein (S) in der Abbildung gekennzeichnet. Diese werden von einem der Portale verwaltet, das in der Synchronisationsbeziehung die Rolle des Client-Portals annimmt. Das andere System agiert in der Rolle des Server-Portals. Dabei verwaltet das Client-Portal die Synchronisationslinks. S persönliches Informationsportal S Unternehmens portal Unternehmens portal Unternehmens portal S persönliches Informationsportal S S S S persönliches Informationsportal S Unternehmens portal Unternehmens portal S: Synchronisationslinks Abbildung 2.6: Synchronisation zwischen Portalen Durch die Synchronisationsbeziehungen zwischen je zwei Portalen kann sich ein Netzwerk von mehreren Unternehmensportalen und persönlichen Informationsportalen ergeben, wie Abbildung 2.6 zeigt.

23 11 Diese Synchronisationsszenarien können dabei die Synchronisation zwischen zwei homogenen, aber auch heterogenen Systemen umfassen. In dieser Arbeit wird ein Synchronisationsmodell für zwei Portale des gleichen Typs vorgestellt. 2.2 Synchronisation In den folgenden Abschnitten wird der Begriff der Synchronisation erläutert, wie er im Kontext der vorliegenden Arbeit verwendet wird. Weiterhin werden allgemeine Aspekte der Synchronisation betrachtet sowie speziell die Synchronisation von Informationsobjekten Begriffsklärung Der Zustand eines Objektes wird im Modell eines zentralen Informationsbestandes durch Prozesse geändert, die bei ihrer Ausführung auf bestimmte Informationsobjekte modifizierend zugreifen. Falls ein Objekt nur von einem Prozess auf dem System geändert wird, besteht keine Notwendigkeit einer Synchronisation (vgl. Szenario 1 in Abbildung 2.7). Anders ist dies, wenn mehrere Prozesse gleichzeitig (parallel) dasselbe Objekt benutzen und es (auf verschiedene Arten) modifizieren möchten, siehe Szenario 2 in Abbildung 2.7. Hierbei wirken sich die Aktivitäten zweier Prozesse P 1 und P 2 ändernd auf das gleiche Objekt O aus. Damit es bei der Zustandsänderung des Objektes zu keinen Inkonsistenzen kommt, müssen die Prozesse bzw. einzelne atomare Ausführungsschritte von ihnen, die Änderungsoperationen auf dem Objekt beinhalten, sequentiell in einer beliebigen Reihenfolge ablaufen. Zu einem gegebenen Zeitpunkt darf das Objekt also nur von höchstens einem Prozess modifiziert werden. Es ist somit erforderlich, die Prozesse beim Zugriff auf das Objekt in einer bestimmten Weise zu synchronisieren. Diesen Vorgang nennt man Prozesssynchronisation. Im verteilten Modell der Informationsbestände, wie in Szenario 3 in Abbildung 2.7 dargestellt, sind mehrere Kopien des gleichen Objektes O als die Objekte O 1 und O 2, die sich semantisch entsprechen, auf zwei verschiedenen Systemen vorhanden. Da diese unabhängig voneinander durch einzelne Prozesse wie P 1 und P 2 modifiziert werden können, entstehen unterschiedliche Versionen (auch Replikas) des Objektes. In diesem Fall ändern sich also logisch zusammengehörige, aber physikalisch getrennte (verteilte) Informationsbestände unabhängig voneinander. Es ist somit erforderlich, diese Informationsbestände wieder in einen konsistenten Zustand zu überführen. Der Begriff Datensynchronisation bezeichnet hierbei den Ausgleich von Unterschieden in den Zustandsänderungen von Daten bzw. Objekten.

24 12 KAPITEL 2. MOTIVATION Zentrale Modelle Verteiltes Modell System System System System O O O 1 sync O 2 P P 1 P 2 P 1 P 2 Szenario 1 Szenario 2 Szenario 3 Abbildung 2.7: Objektmodifikationen durch Prozesse Durch die Modelle wird deutlich, dass die Semantiken der Prozesssynchronisation sowie der Datensynchronisation eng miteinander verknüpft sind. Den weiteren Ausführungen wird das dezentrale Modell und somit Szenario 3 zugrunde gelegt, das den Ausgangspunkt für den in Kapitel beschriebenen Synchronisationsbedarf bildet. Vor diesem Hintergrund wird der Begriff Synchronisation als Synonym für Datensynchronisation bzw. spezieller für die Synchronisation von Informationsobjekten verwendet Aspekte der Synchronisation Für die Synchronisation zwischen den Informationsbeständen von Systemen sind bestimmte Aspekte zu berücksichtigen, die dann in den Regeln für den Ausgleich der Zustandsänderungen von Objekten festgelegt werden. Nachfolgend werden diese erläutert: Kardinalität des Synchronisationsmechanismus Die Synchronisation kann zwischen zwei Systemen erfolgen, also durch einen binären Synchronisationsmechanismus realisiert werden (1:1-Synchronisation). Andererseits ist auch eine n-äre Synchronisation von Informationsbeständen gleichzeitig zwischen mehreren Systemen möglich. Hierbei wird von einem System aus derselbe Teil des Informationsbestandes mit mehreren anderen Systemen abgeglichen (1:n-Synchronisation). Rollenverteilung der Systeme Es gibt verschiedene Szenarien für die Rollenverteilung der Systeme. Die Systeme können einerseits in einem asymmetrischen Szenario die Rollen eines Client-Systems sowie eines Server-Systems bezüglich der Synchronisation annehmen. Dabei wird die Synchronisation immer durch eines der Systeme eingeleitet. Dieses bildet das aktive System während der Synchronisation, steuert diese und setzt den Synchronisationsalgorithmus um. Andererseits ist

25 13 auch ein symmetrisches Szenario der Systeme in einer Peer-to-peer Architektur denkbar, bei dem jedes System in derselben Synchronisationsbeziehung, jedoch nicht während der gleichen Synchronisation, beide Rollen annehmen kann. Dabei ist das aktive System wählbar. Steuerung der Synchronisation Ein wesentlicher Aspekt ist die Steuerung der Synchronisation, nämlich wann und wie ein Ausgleich erfolgen soll. Das Scheduling kann manuell geschehen, wobei eine Synchronisation zu beliebigen, gewünschten Zeitpunkten erfolgt. Weiterhin ist eine halbautomatische Synchronisation möglich, deren Durchführung von definierten Ereignissen abhängt. Eine solche ereignisgesteuerte Synchronisation kann zum einen in bestimmten Zeitabständen stattfinden. Zum anderen kann sie auch bei Ereignissen, wie dem Zugriff auf ein Objekt und eine Objektmodifikation, eingeleitet werden. Voraussetzung für letzteres ist ein Notifikationsmechanismus, der Ereignisse identifiziert und an andere Systemkomponenten weiterleitet. Andererseits wird auch entschieden, ob die Synchronisation nach der Push- oder Pull-Methode erfolgt, also ob ein System dem anderen mitteilt, dass in seinem Informationsbestand Zustandsänderungen erfolgt sind (push) oder ob diese Information explizit angefordert werden muss (pull), damit ein Ausgleich durchgeführt werden kann. Strategie der Synchronisation Bei der Synchronisation kann man verschiedene Strategien wählen, um die Unterschiede sich entsprechender Objekte in den Informationsbeständen auszugleichen und sie bezüglich der beteiligten Systeme in einen konsistenten Zustand zu überführen. Zum einen ist es möglich, inkrementell zu synchronisieren, d. h. nur Objekte zu betrachten, die seit der letzten Synchronisation eine Zustandsänderung erfahren haben. Weiterhin ist auch ein vollständiges Update eines Informationsbestandes anhand des anderen realisierbar. Dabei werden alle Objekte auf einem der Systeme entsprechend überschrieben. Diese Synchronisationsstrategie ist richtungsabhängig. Erstere ist die effizientere Methode, die auch die adäquate Synchronisationsrichtung, nämlich Modifikationen vom Client zum Server oder umgekehrt zu propagieren, impliziert. Dazu muss aber ein Mechanismus für die Identifikation der Zustandsänderungen der Objekte auf den beiden Systemen zur Verfügung stehen. Ebene der Synchronisation Eine Synchronisation ist auf unterschiedlichen Ebenen eines Systems möglich. Zum einen kann man in diesem Kontext der Datensynchronisation auf Dateisystemebene als unterster Ebene eine Synchronisation durchführen. Des weiteren gibt es die Synchronisation auf der Datenbankebene,

26 14 KAPITEL 2. MOTIVATION also von Tabellen und Datensätzen sowie weiteren Datenbank-Objekten. Außerdem kann eine Synchronisation auf Applikationsebene zwischen Informationsobjekten stattfinden, die in der vorliegenden Arbeit die zentrale Rolle spielt. Die Synchronisationsebenen und die jeweils angewandten Techniken werden in Kapitel 3 ausführlich behandelt. Es kann nur zwischen äquivalenten Ebenen von Systemen eine Synchronisation durchgeführt werden. Art des Ausgleichs Während einer Synchronisation zwischen Informationsbeständen gibt es die Möglichkeit des vollständigen Ausgleichs, wobei sich alle Objekte auf den Systemen entsprechen müssen. Ferner kann man auch eine selektive Synchronisation durchführen, wobei nur ein spezifizierter Teil des jeweiligen Informationsbestandes in die Synchronisation einbezogen wird. Identifikation korrespondierender Objekte Semantisch äquivalente, zu synchronisierende Objekte können einerseits unmittelbar identifiziert und einander zugeordnet werden, sofern sie global eindeutige Objektidentitäten besitzen, die auf allen Systemen gültig sind. Andernfalls ist ein Mechanismus zum Identifizieren korrespondierender Objekte vor der eigentlichen Synchronisation notwendig. Identifikation von Zustandsänderungen Es werden gewöhnlich Objekte synchronisiert, deren Zustände seit der letzten Synchronisation modifiziert worden sind. Um dies sowie die Art der Zustandsänderung festzustellen, kann man den letzten Modifikationszeitpunkt (Zeitstempel) des Objekts mit dem Zeitpunkt der letzten Synchronisation vergleichen. Des weiteren gibt es auch die Möglichkeit zu bestimmen, welche Teilstrukturen sich geändert haben. Bei strukturierten Metadaten kann es sich hierbei beispielsweise um ein bestimmtes Attribut eines Objektes handeln, das durch assoziative Vergleiche identifiziert werden kann. Für unstrukturierte Daten gibt es ebenfalls spezielle Vergleichswerkzeuge (wie z. B. ExamDiff oder WinDiff für Dateien und Verzeichnisse), die die Stelle, an der eine Änderung erfolgt ist, genau feststellen können. Bei großen Objekten ist dies besonders effizient, da nur die geänderten Teile synchronisiert werden müssen. Die zweite Methode ist auch präziser, denn falls sich Objekte zwar laut Zeitstempel seit der letzten Synchronisation geändert haben, die korrespondierenden Objekte aber inhaltlich identisch sind, brauchen diese nicht synchronisiert zu werden.

27 15 Transformation von Objekten Handelt es sich bei der Synchronisation um Objekte, deren Repräsentation auf beiden Systemen gleich ist, ist keine explizite Transformation erforderlich. Falls in den Informationsbeständen der Systeme Unterschiede in der Repräsentation korrespondierender Objekte bestehen, diese also nicht strukturgleich sind, muss eine logische Transformation vorgegeben sein, nach der die Objekte ineinander überführt werden können. Erkennung und Auflösung von Konfliktsituationen Eine wichtige Aufgabe ist auch, Konfliktsituationen bei der Synchronisation zu identifizieren und Strategien zu deren Auflösung bereitzustellen. Diese entstehen bei unterschiedlichen Modifikationen an verschiedenen Kopien eines Objektes. Es muss hierbei entschieden werden, in welcher Weise solche Änderungen zu einem konsistenten Objektzustand kombiniert werden können. Hierfür spielen Merging-Strategien (vgl. Kapitel 6.4.2) eine wichtige Rolle Synchronisation von Informationsobjekten Die Synchronisation von Informationsobjekten beinhaltet die Synchronisation strukturierter Metadaten sowie unstrukturierter Daten. Dies muss im Synchronisationsalgorithmus berücksichtigt werden. An dieser Stelle wird nun die für diese Arbeit relevante Synchronisation von Informationsobjekten zwischen Portalen detailliert. Zum einen werden die Informationsobjekte in den Portalen von typisierten Objektcontainern verwaltet. Daher ist es notwendig, bei der Synchronisation zu berücksichtigen, aus welchem Container ein Objekt stammt. Korrespondierende Informationsobjekte müssen stets vom gleichen Objekttyp sein. Abbildung 2.8: Abbilden der Objekte zwischen den Portalen

28 16 KAPITEL 2. MOTIVATION Weiterhin wird davon ausgegangen, dass die Portale keine global eindeutigen Objektidentitäten vergeben, sondern dass die ObjektIds jeweils nur lokal Gültigkeit haben. Abbildung 2.8 illustriert, wie sich Person- und Gruppenobjekte auf dem Unternehmensportal und dem persönlichen Informationsportal entsprechen. Solche semantisch äquivalenten Informationsobjekte müssen während der Synchronisation aufeinander abgebildet werden. Zum anderen besitzen Informationsobjekte verschiedene Arten von Attributen. Eine Art bilden Wertattribute. Diese enthalten Werte elementarer Datentypen, wie beispielsweise den Nachnamen einer Person. Andererseits können Attribute auch Referenzen auf andere Informationsobjekte enthalten, wie aus Abbildung 2.8 ersichtlich ist. Es bestehen Referenzbeziehungen zwischen Informationsobjekten innerhalb eines Portals. Im folgenden werden Informationsobjekte nach der Komplexität und Kardinalität ihrer Referenzbeziehungen zu anderen Objekten klassifiziert (vgl. dazu Abbildung 2.9): keine Referenzattribute (o 1 ) Referenzattribute, die sich auf den gleichen Objekt-Container beziehen mit Kardinalität 1:n (o 2 ) Referenzattribute, die sich auf einen anderen Objekt-Container beziehen mit Kardinalität 1:n (o 3 ) Referenzbeziehungen der Kardinalität n:m, die nicht über Referenzattribute definiert sind, sondern als zwei 1:n-Relationen betrachtet werden können Es können hierbei auch zyklische Referenzen innerhalb eines Objekt-Containers oder auch Container-übergreifend auftreten. (o 4 o 5 o 6 o 7 o 8 o 9 o 4 bzw. o 10 ). In Abbildung 2.9 sind die möglichen Beziehungen am Beispiel zweier Objekt-Container illustriert. Container 1 Container 2 o 1 o 9 o 8 o 7 o 10 o 2 o 4 o 5 o 3 o 6 Abbildung 2.9: Referenzbeziehungen zwischen Objekten in Objektcontainern Das Setzen von Referenzattributen während der Synchronisation ist ebenfalls notwendig. Bei der Synchronisation kann dies dadurch ermöglicht werden, dass referenzierte Objekte für ein Informationsobjekt mitsynchronisiert werden. Dies impliziert die Synchronisation eines Objektgraphen. Alternativ können die Referenzen auch zurückgesetzt oder auf andere Objekte gesetzt werden. Die jeweilige Realisierung ist im Synchronisationsalgorithmus festgelegt.

29 Kapitel 3 Synchronisationsebenen, -techniken und -lösungen In diesem Kapitel werden die in Kapitel eingeführten Synchronisationsebenen und dort angewandten Synchronisationstechniken erläutert. Ergänzt werden diese durch die Beschreibung vorhandener Synchronisationslösungen. Kapitel 3.1 beschäftigt sich dabei mit der Synchronisation auf Dateisystemebene. Anschließend werden in den Kapiteln 3.2 bzw. 3.3 Synchronisationstechniken auf der Datenbank- bzw. Applikationsebene dargestellt. 3.1 Synchronisation auf Dateisystemebene In der vorliegenden Arbeit werden Synchronisationstechniken auf Hardware-Ebene nicht betrachtet. Daher wird an dieser Stelle die Synchronisation auf Dateisystemebene als unterster Ebene beschrieben. Es gibt verschiedene Arten von Werkzeugen sowie Applikationen, deren Funktionalitäten eine Synchronisation auf Dateisystemebene beinhalten, wie Dateisystemwerkzeuge Build-Werkzeuge Versionskontrollsysteme Konfigurationsmanagementsysteme. Dabei bauen Build-Werkzeuge und Versionskontrollsysteme als Entwicklungswerkzeuge auf Dateisystemwerkzeugen auf und erweitern diese um spezielle Funktionalitäten. Konfigurationsmanagementsysteme decken die Bereiche der beiden letztgenannten Anwendungen ab. Sie werden im Qualitätsmanagement sowie für administrativen Zwecke eingesetzt. 17

30 18 KAPITEL 3. SYNCHRONISATIONSEBENEN, -TECHNIKEN UND -LÖSUNGEN Daher werden in den folgenden Unterkapiteln die ersten drei Anwendungsbereiche anhand existierender Lösungen näher erläutert Dateisystemwerkzeuge Innerhalb eines lokalen Dateisystems oder zwischen mehreren getrennten Systemen in einer verteilten Umgebung können Teile von Verzeichnisstrukturen mit den enthaltenen Dateien repliziert an mehreren Stellen vorhanden sein (z. B. beim Arbeiten an einem stationären PC oder an einem Notebook). Synchronisationswerkzeuge, die auf Dateisystemen arbeiten, vergleichen Kopien von Verzeichnissen sowie die enthaltenen Dateien miteinander und können sie auf einen abgeglichenen Stand bringen. Die zugrundeliegenden Modelle sind jedoch nur für die Synchronisation von individuellen Dateien anhand ihrer strukturierten Metadaten geeignet. Über die Modifikationszeitpunkte von Dateien wird entschieden, ob eine Synchronisation erforderlich ist, und welche Dateien aktualisiert werden. In der Arbeit [Schu02] wird die Synchronisation von verteilten Verzeichnisstrukturen behandelt. Im folgenden werden ausgewählte Dateisystemwerkzeuge aufgeführt: Unison Unison ist ein Werkzeug zur Dateisynchronisation für Unix und Windows, siehe [Pier01]. Damit können jeweils zwei Kopien einer Verzeichnisstruktur synchronisiert werden. Es ist hierbei möglich, diese lokal oder auf unterschiedlichen Systemen zu verwalten sowie Modifikationen, die auf beiden Seiten stattfinden dürfen, abzugleichen. Rsync Rsync [Rsyn02] ist eine erweiterte Version der Unix Werkzeuge rcp (remote copy) und scp (secure copy) und beinhaltet eine erweiterte Funktionalität mit verschiedenen Optionen für die Synchronisation zwischen verteilten Dateisystemen. Es wird dabei das sog. Rsync Algorithmus verwendet, der einen sehr effizienten Abgleich von Dateien ermöglicht. Es wird dabei jeweils nur die Differenz zwischen zwei Versionen einer Datei übermittelt und keine Kopie der Datei. Backer Speziell für Windows-Systeme gibt es eine Reihe von Software Herstellern, die Produkte zur Datensynchronisation entwickelt haben. Ein Beispiel stellt Backer [Lean02] der Firma Leanware Development GmbH dar. Die Synchronisation erfolgt hierbei nur auf dem lokalen System zwischen Verzeichnissen. Vorteilhaft sind zum einen die Vielzahl an Optionen für eine Auswahl

31 19 der zu synchronisierenden Dateien sowie die mögliche Kontrolle der Synchronisation durch den Benutzer. Das Coda Dateisystem Coda ist ein verteiltes Dateisystem, das in der Gruppe von M. Satyanarayanan an der Carnegie Mellon Universität (CMU) seit 1987 entwickelt wird, siehe [Coda02]. Coda bietet (fast) vollständige Lösungen für die Probleme des Offline-Arbeitens (Disconnected Computing) in einer verteilten Umgebung. Die Verwaltung der Dateien wird auf einem oder mehreren replizierten Fileservern realisiert. Die Client-Systeme sollen dabei überwiegend lesend, können aber auch schreibend auf das Dateisystem der Server zugreifen. Diese stellen Mechanismen zur Konfliktauflösung bereit Build-Werkzeuge Build-Werkzeuge werden in der Softwareentwicklung eingesetzt, um die Erstellung komplexer Softwareprodukte und komponenten zu handhaben. Hierbei wird ein Softwareprojekt/- komponente aus einer großen Anzahl von Quellen zusammengesetzt, zwischen denen komplexe Abhängigkeitsbeziehungen bestehen. Mit Hilfe dieser Werkzeuge ist es möglich, Abhängigkeiten zwischen den Quellen zu definieren und so die aus den Quellen erzeugten Komponenten Projekt-übergreifend in konsistenten Zuständen zu halten. Die Funktionsweise von Build-Werkzeugen erweitert eine gewöhnliche Dateisynchronisation durch Anwendung neuer Strategien: wenn der Zustand einer erzeugten Datei von mehreren Quelldateien abhängt, und eine dieser Dateien aktueller ist als die betrachtete Datei, wird letztere neu erzeugt. Durch welche Aktion die Datei neu erzeugt wird (z.b. Kompilierung), muss ebenfalls festgelegt werden. Make/Nmake Make wurde als erstes Build-Werkzeug, wie in [Make95] beschrieben, für die Softwareentwicklung unter UNIX entwickelt. Inzwischen gibt es verschiedene Versionen dieses Tools, die auch unter MS-DOS und Windows angeboten werden, wie z.b. das make von Borland oder das nmake von Microsoft. Make ist eine Applikation, die für die Beschreibung von Dateiabhängigkeiten sowie die jeweils auszuführenden Aktionen in der Build-Datei (.mak) ein eigenes Format definiert. Ant Das Build-Werkzeug Ant, siehe [Jaka02], ist eine Entwicklung im Apache Jakarta Projekt. Es basiert auf Java und XML. Ant Build-Dateien liegen im XML-Format vor. Eine Build-Datei besteht aus Targets (Zielen), Tasks (Arbeitsschritten) und Properties (Eigenschaften). Ziele