Identifizierung und Rekonstruktion eines allgemeinen Schemas für Web-Content-Management-Systeme
©2002
Diplomarbeit
79 Seiten
Zusammenfassung
Inhaltsangabe:Zusammenfassung:
Heute existiert eine Klasse von Softwaresystemen zur Unterstützung einer effizienten Verwaltung und Strukturierung großer Informationsmengen für das Internet (Web-Content-Managementsysteme). Diese Systeme unterscheiden sich teilweise grundlegend in ihrer Funktionalität. Ausgehend von einer klaren Abgrenzung der Aufgaben eines solchen Systems können einige wesentliche Aspekte in den Mittelpunkt gerückt werden.
Die Art der Datenhaltung ist von grundlegendem Interesse. Im Vergleich der verschiedenen verfügbaren Datenbanktechnologien zeigt sich, dass eine XML-fähige objektrelationale Datenbank die Belange des Web-Content-Managements optimal unterstützt. Aus pragmatischer Sicht hat aber die Verwendung einer rein relationalen Datenbank trotzdem Vorteile. Das Digital Asset Management ist für eine zentrale Speicherung der einzelnen Bestandteile des Web-Contents zuständig. Eine Unterstützung für die Verwaltung von Versionen und Varianten ist dabei wichtig. Die nutzerindividuelle Aufbereitung von Inhalten (Personalisierung) ist ein aufwendiges Thema und sollte deshalb in Form einer Komponente austauschbar sein. Trotz der damit verbundenen Unabhängigkeit des Web-Content-Managementsystems von speziellen Belangen der Personalisierung muss eine grundsätzliche technische Unterstützung für eine solche Komponente vorhanden sein. Dadurch ergeben sich einige Anforderungen an das zugrunde liegende Datenbankschema.
Alle genannten Themenbereiche sind stark von der Handhabung der einzelnen Inhaltsbestandteile der Assets abhängig. In diesem Zusammenhang kommt dem Ansatz der strikten Trennung von Struktur, Inhalt, Darstellung und Programmlogik besondere Bedeutung zu. Er ermöglicht nicht nur eine arbeitsteilige Erstellung und Pflege der Assets, sondern erweitert auch die Flexibilität bei der Personalisierung. Auf Basis der XML kann eine orthogonale Verarbeitung der vier Bestandteile realisiert werden, welche auch das Cross-Media Publishing optimal unterstützt. Durch die orthogonale Einbringung von Programmlogik kann der Web-Content auch nachträglich in bestehende Web-Applikationen integriert werden. Existierende Web-Content-Managementsysteme unterstützen dieses Konzept nur unzureichend.
In dieser Arbeit werden die technischen Grundkonzepte der genannten Themenbereiche genauer betrachtet. Insbesondere ein allgemeines Datenbankschema wird eingeführt, welches die Anforderungen an ein Web-Content-Managementsystem umfassend berücksichtigt. […]
Heute existiert eine Klasse von Softwaresystemen zur Unterstützung einer effizienten Verwaltung und Strukturierung großer Informationsmengen für das Internet (Web-Content-Managementsysteme). Diese Systeme unterscheiden sich teilweise grundlegend in ihrer Funktionalität. Ausgehend von einer klaren Abgrenzung der Aufgaben eines solchen Systems können einige wesentliche Aspekte in den Mittelpunkt gerückt werden.
Die Art der Datenhaltung ist von grundlegendem Interesse. Im Vergleich der verschiedenen verfügbaren Datenbanktechnologien zeigt sich, dass eine XML-fähige objektrelationale Datenbank die Belange des Web-Content-Managements optimal unterstützt. Aus pragmatischer Sicht hat aber die Verwendung einer rein relationalen Datenbank trotzdem Vorteile. Das Digital Asset Management ist für eine zentrale Speicherung der einzelnen Bestandteile des Web-Contents zuständig. Eine Unterstützung für die Verwaltung von Versionen und Varianten ist dabei wichtig. Die nutzerindividuelle Aufbereitung von Inhalten (Personalisierung) ist ein aufwendiges Thema und sollte deshalb in Form einer Komponente austauschbar sein. Trotz der damit verbundenen Unabhängigkeit des Web-Content-Managementsystems von speziellen Belangen der Personalisierung muss eine grundsätzliche technische Unterstützung für eine solche Komponente vorhanden sein. Dadurch ergeben sich einige Anforderungen an das zugrunde liegende Datenbankschema.
Alle genannten Themenbereiche sind stark von der Handhabung der einzelnen Inhaltsbestandteile der Assets abhängig. In diesem Zusammenhang kommt dem Ansatz der strikten Trennung von Struktur, Inhalt, Darstellung und Programmlogik besondere Bedeutung zu. Er ermöglicht nicht nur eine arbeitsteilige Erstellung und Pflege der Assets, sondern erweitert auch die Flexibilität bei der Personalisierung. Auf Basis der XML kann eine orthogonale Verarbeitung der vier Bestandteile realisiert werden, welche auch das Cross-Media Publishing optimal unterstützt. Durch die orthogonale Einbringung von Programmlogik kann der Web-Content auch nachträglich in bestehende Web-Applikationen integriert werden. Existierende Web-Content-Managementsysteme unterstützen dieses Konzept nur unzureichend.
In dieser Arbeit werden die technischen Grundkonzepte der genannten Themenbereiche genauer betrachtet. Insbesondere ein allgemeines Datenbankschema wird eingeführt, welches die Anforderungen an ein Web-Content-Managementsystem umfassend berücksichtigt. […]
Leseprobe
Inhaltsverzeichnis
ID 6437
Goßler, Thomas: Identifizierung und Rekonstruktion eines allgemeinen Schemas für Web-
Content-Management-Systeme
Hamburg: Diplomica GmbH, 2003
Zugl.: Erlangen, Universität, Diplomarbeit, 2002
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2003
Printed in Germany
K
URZFASSUNG
iv
Kurzfassung
Heute existiert eine Klasse von Softwaresystemen zur Unterstützung einer effizienten
Verwaltung und Strukturierung großer Informationsmengen für das Internet (Web-Content-
Managementsysteme). Diese Systeme unterscheiden sich teilweise grundlegend in ihrer
Funktionalität. Ausgehend von einer klaren Abgrenzung der Aufgaben eines solchen Systems
können einige wesentliche Aspekte in den Mittelpunkt gerückt werden.
Die Art der Datenhaltung ist von grundlegendem Interesse. Im Vergleich der
verschiedenen verfügbaren Datenbanktechnologien zeigt sich, dass eine XML-fähige
objektrelationale Datenbank die Belange des Web-Content-Managements optimal unterstützt.
Aus pragmatischer Sicht hat aber die Verwendung einer rein relationalen Datenbank
trotzdem Vorteile. Das Digital Asset Management ist für eine zentrale Speicherung der
einzelnen Bestandteile des Web-Contents zuständig. Eine Unterstützung für die Verwaltung
von Versionen und Varianten ist dabei wichtig. Die nutzerindividuelle Aufbereitung von
Inhalten (Personalisierung) ist ein aufwendiges Thema und sollte deshalb in Form einer
Komponente austauschbar sein. Trotz der damit verbundenen Unabhängigkeit des Web-
Content-Managementsystems von speziellen Belangen der Personalisierung muss eine
grundsätzliche technische Unterstützung für eine solche Komponente vorhanden sein.
Dadurch ergeben sich einige Anforderungen an das zugrunde liegende Datenbankschema.
Alle genannten Themenbereiche sind stark von der Handhabung der einzelnen
Inhaltsbestandteile der Assets abhängig. In diesem Zusammenhang kommt dem Ansatz
der strikten Trennung von Struktur, Inhalt, Darstellung und Programmlogik besondere
Bedeutung zu. Er ermöglicht nicht nur eine arbeitsteilige Erstellung und Pflege der Assets,
sondern erweitert auch die Flexibilität bei der Personalisierung. Auf Basis der XML kann
eine orthogonale Verarbeitung der vier Bestandteile realisiert werden, welche auch das
Cross-Media Publishing optimal unterstützt. Durch die orthogonale Einbringung von
Programmlogik kann der Web-Content auch nachträglich in bestehende Web-Applikationen
integriert werden. Existierende Web-Content-Managementsysteme unterstützen dieses
Konzept nur unzureichend.
In dieser Arbeit werden die technischen Grundkonzepte der genannten Themen-
bereiche genauer betrachtet. Insbesondere ein allgemeines Datenbankschema wird
eingeführt, welches die Anforderungen an ein Web-Content-Managementsystem umfassend
berücksichtigt. Die Seitenverwaltung hat dabei besondere Bedeutung, da sie die Trennung
der oben beschriebenen vier Aspekte des Web-Contents abbildet. Der Zugriff auf den
Datenbestand und die Steuerung des Publizierungsprozesses ermöglicht ein Application
Programming Interface (API), dessen Objektmodell durch UML-Klassendiagramme
visualisiert wird. Eine Implementierung des API in Java und eine Beispiel-Webseite belegen
die Einsatzfähigkeit der vorgestellten Konzepte.
I
NHALTSVERZEICHNIS
vi
Inhaltsverzeichnis
1 Einleitung ...1
1.1
Motivation und Zielsetzung...1
1.2
Aufbau der Arbeit...2
2 Anforderungsanalyse...5
2.1 Datenhaltung...5
2.1.1 Relationale
Datenbanksysteme...5
2.1.2 Objektorientierte
Datenbanksysteme...6
2.1.3 XML-Datenbanksysteme...7
2.1.4
Bewertung im Kontext des Web-Content-Managements...8
2.2 Funktionale
Aspekte...9
2.2.1 Asset-Management ...10
2.2.2
Trennung von Struktur, Inhalt, Darstellung und Programmlogik ...12
2.2.3
Publizierung: Staging- vs. Live-Server-Konzept ...14
2.2.4
Personalisierung des Web-Contents ...15
2.2.5
Unterstützung von Semantic Web-Konzepten ...16
2.2.6 Weitere
Aspekte ...17
3
Datenmodell und verarbeitung ...19
3.1
Speicherung der Assets...21
3.2 Seitenverwaltung ...23
3.3
Struktur, Inhalt und Darstellung...25
3.3.1
Zusammenführung von Struktur und Inhalt ...25
3.3.2
Transformation ins Ausgabeformat...27
3.4
Programmlogik als separater Bestandteil ...29
3.5
Vorbereitung für die Personalisierung des Web-Contents ...31
3.6
Kontextverwaltung zur Strukturierung des Web-Contents ...35
3.7 Link-Management ...36
3.8
Integration von Semantic Web-Konzepten ...37
4 Application
Programming
Interfaces ...43
4.1 Administrations-API...43
4.1.1 Anforderungen...44
4.1.2
Modell und Verwendung...45
4.1.3 Dateneditor
als
Beispielanwendung ...47
4.2 Publizierungs-API ...48
4.2.1 Anforderungen...50
4.2.2 Modell...51
4.2.3 Verwendung ...54
I
NHALTSVERZEICHNIS
vii
5 Evaluierung
der
Einsatzfähigkeit... 57
5.1
Anforderungen an eine Beispielanwendung ... 57
5.2
Verwendung von C
OCOON
als Publizierungskomponente... 58
5.3 Eine
Beispiel-Webseite... 60
5.4 Bewertung... 65
6
Zusammenfassung und Ausblick ... 67
Literatur und Web-Referenzen ... 69
Anhang... 73
A. Ausgewählte
Quelltexte... 73
B. Einrichtung der Softwareumgebung ... 74
A
BBILDUNGSVERZEICHNIS
viii
Abbildungsverzeichnis
Abbildung 1: Architektur eines Web-Content-Managementsystems ([JM02]) ...1
Abbildung 2: Markierung einer konsistenten Assetmenge in Anlehnung an [Voig01] ...11
Abbildung 3: Versionen vs. Varianten ...12
Abbildung 4: Trennung von Struktur, Inhalt, Darstellung und Programmlogik ...13
Abbildung 5: Publizierungsprozess mit (Pre-)Staging...15
Abbildung 6: RDF-Tripel (Subjekt, Prädikat, Objekt)...16
Abbildung 7: Beispiel für ein RDF-Tripel ...17
Abbildung 8: Content-Life-Cycle in Anlehnung an [JM02] ...18
Abbildung 9: Vereinfachte Darstellung des ER-Diagramms aus Abbildung 10...19
Abbildung 10: ER-Diagramm des vollständigen WCMS-Datenschemas...20
Abbildung 11: Auf die Seitenverwaltung reduziertes ER-Diagramm des Datenschemas ...24
Abbildung 13: XSL-Stylesheet für das Mapping der Transformation aus Abbildung 14...26
Abbildung 14: Zusammenführen von Struktur und Inhalt ...27
Abbildung 15: XSL-Template mit Darstellungsregeln in (X)HTML ...28
Abbildung 16: Prozesskette für die Erzeugung eines Dokuments ...28
Abbildung 17: Orthogonale Einbettung von Logik in ein XML-Dokument mittels XSP ...30
Abbildung 18: Prozesskette der Verarbeitungsschritte ...31
Abbildung 19: Zuordnungen: Gruppe Person Rolle Rechte...32
Abbildung 20: Mögliches Metaschema zu dem Schema aus Abbildung 10 ...34
Abbildung 21: Teilschema zur Speicherung dynamischer Attribute ...34
Abbildung 22: Vereinfachung der Aktualisierung von Verweisen durch Indirektion ...36
Abbildung 23: Einfache Semantic Web-Beschreibung von ganzen Webseiten ...38
Abbildung 24: Einfache Semantic Web-Beschreibung des Inhalts von Webseiten ...38
Abbildung 25: Generierung einer Semantic Web-Aussage aus einem Fremdschlüssel ...39
Abbildung 26: Generierung einer Semantic Web-Aussage über dynamische Attribute...40
Abbildung 27: Einbettung von Inhalten in eine Struktur (alternative Darstellung) ...40
Abbildung 28: Anwendungsfalldiagramm für das Administrations-API...44
Abbildung 29: Klassendiagramm des Administrations-API ...45
Abbildung 30: Quelltext zur Verwendung des Administrations-API ...46
Abbildung 31: Rückgabewert der Methode getAllDatasetsAsXML für die Entität Person ...47
Abbildung 32: Ein Dateneditor als Beispielanwendung für das Administrations-API...48
Abbildung 33: Verarbeitungsreihenfolge von Publizierungs- und Administrations-API ...49
A
BBILDUNGSVERZEICHNIS
/
T
ABELLENVERZEICHNIS
iv
Abbildung 34: Anwendungsfalldiagramm für das Publizierungs-API ...51
Abbildung 35: Klassendiagramm des Publizierungs-API...52
Abbildung 36: Klassendiagramm der Schnittstellendefinitionen für das Publizierungs-API.53
Abbildung 37: Quelltext zur Verwendung des Publizierungs-API ...55
Abbildung 38: Definition einer Prozesskette in der Datei ,,sitemap.xmap" von C
OCOON
2..59
Abbildung 39: Standard-Stylesheet zur Beibehaltung ,,restlicher" XML-Elemente...59
Abbildung 40: MainServlet.java ...74
Tabellenverzeichnis
Tabelle 1: Anforderungen an das Administrations-API...44
Tabelle 2: Anforderungen an das Publizierungs-API...50
Tabelle 3: Entstehung der Beispiel-Webseite in zwei Versionen ...65
K
APITEL
1
E
INLEITUNG
1
1 Einleitung
Nach neuesten Statistiken hat heute in Deutschland fast jeder zweite mündige Bürger Zugang
zum Internet ([Hei02]). Die rasante Verbreitung dieses Mediums in den letzten Jahren hat zu
einem Zwang praktisch aller Unternehmen geführt, eine Präsenz im World Wide Web
einzurichten. Als wichtige Informationsquelle für Kunden ist das Web ein strategischer
Faktor im Wettbewerb gegen die Konkurrenz geworden. Der Nutzer möchte stets von
aktuellem Inhalt mit höchstem Informationsgehalt und Unterhaltungswert profitieren. Das
führt zu enormen Datenbeständen mit hohem Erstellungs- und Wartungsaufwand bei den
Anbietern. Dadurch sind diese gezwungen, effiziente und leistungsfähige Verwaltungs-
methoden einzusetzen, um dem so genannten Web-Content Herr zu werden. Die Integration
der reinen Verwaltung der inhaltlichen Daten mit speziellen Funktionalitäten zur
Verarbeitung derselben (z.B. Shop-Systeme mit Warenkorb) stellt die Unternehmen dabei
vor besondere Herausforderungen.
1.1 Motivation und Zielsetzung
Genau an dieser Stelle setzen so genannte Web-Content-Managementsysteme (WCMS) an.
Sie versuchen, die Datenhaltung und -verarbeitung aus Sicht des Unternehmens zu
vereinfachen und zu vereinheitlichen, wobei sich unter dem Ziel höchster Flexibilität und
Leistungsfähigkeit einige wesentliche Kernkonzepte solcher Systeme herauskristallisiert
haben. Und genau jene stehen im Mittelpunkt der folgenden Betrachtungen. Abbildung 1
zeigt die prinzipielle Architektur eines WCMS.
Abbildung 1: Architektur eines Web-Content-Managementsystems ([JM02])
E
INLEITUNG
K
APITEL
1
2
In dieser Arbeit werden in Bezug auf Abbildung 1 das ,,Asset
1
-Management" und die
,,Datenhaltung" erschöpfend behandelt. Dabei werden Themen wie die effiziente Verwaltung
des Datenbestands durch Arbeitsteilung, umfassende Versionsverwaltung und grundlegende
Techniken für eine möglichst flexible nutzerindividuelle Aufbereitung der zu publizierenden
Inhalte (Personalisierung) berücksichtigt. In diesem Zusammenhang ist das Konzept der
konsequenten Trennung von Struktur, Inhalt, Darstellung und ausführbaren Bestandteilen
(Programmlogik) des Web-Contents von zentraler Bedeutung, welches in existierenden
Systemen nur unzureichend berücksichtigt ist. Andere wichtige Themen wie zum Beispiel
die ,,Workflow-Managementkomponente", die ,,Benutzer- und Zugriffsverwaltung", und die
,,Personalisierung" können im Rahmen dieser Arbeit nur am Rande berücksichtigt werden.
Ein ausführlicher Überblick der in Abbildung 1 dargestellten Komponenten findet sich in
[JM02].
Ziel dieser Arbeit ist die Analyse wichtiger Kernkonzepte von Web-Content-
Managementsystemen aus technischer Sicht. Es werden Lösungsansätze erarbeitet, die auf
maximale Flexibilität und Erweiterbarkeit abzielen. Ein Schwerpunkt liegt auf der
Entwicklung eines Schemas für das so genannte Content Repository, in dem die Daten
gehalten werden. Letztendlich sollen die dargestellten Ergebnisse Entwurfsentscheidungen
bei der Entwicklung innovativer Web-Content-Managementsysteme erleichtern.
1.2 Aufbau der Arbeit
In Abschnitt 2 werden zunächst grundsätzliche technische Anforderungen an ein Web-
Content-Managementsystem herausgearbeitet. Neben der Datenhaltung werden dabei
insbesondere wichtige funktionale Aspekte betrachtet. Das Asset-Management und der
Publizierungsprozess stehen dabei im Mittelpunkt. Darauf aufbauend führt Abschnitt 3 ein
Datenschema ein, welches als allgemeine Grundlage für Web-Content-Managementsysteme
gelten soll. Es versucht alle erforderlichen Konzepte zu vereinigen und dabei höchste
Flexibilität sicherzustellen. Insbesondere die technische Umsetzung einer strikten Trennung
von Struktur, Inhalt, Darstellung und Programmlogik wird an dieser Stelle genauer
beleuchtet. Diese ist nicht nur für die arbeitsteilige Erstellung und Pflege des Web-Contents
erforderlich, sondern auch für die Personalisierung der Inhalte entscheidend. Auf Basis der
XML wird eine Möglichkeit zur orthogonalen Verarbeitung der vier Aspekte gezeigt, welche
auch das Cross-Media Publishing optimal unterstützt. Speziell die orthogonale Einbettung
von Programmlogik ist an dieser Stelle interessant. Sie ermöglicht eine kontextspezifische
und aspektorientierte [AOP02] nachträgliche Einbringung von Funktionalitäten und somit
auch eine spontane Integration des Web-Contents in existierende Web-Applikationen.
Ergänzend werden verschiedene Ansätze für eine Unterstützung von Semantic Web-
Konzepten (Abschnitt 2.2.5) vorgestellt. Abschnitt 4 vertieft die vorangehenden
Ausführungen durch Erläuterung zweier Application Programming Interfaces (APIs), welche
1
Wegen der weiten Verbreitung werden Anglizismen wie Asset (engl. ,,Vermögen") im Text verwendet.
K
APITEL
1
E
INLEITUNG
3
speziell für die Bearbeitung und die Publizierung des Web-Contents entwickelt wurden.
Anhand von UML-Diagrammen werden die verwendeten Entwurfsmuster und
Klassenstrukturen visualisiert. Abschließend wird Abschnitt 5 eine Beispielimplementierung
als Beleg für die Einsatzfähigkeit der vorgestellten Konzepte präsentieren. Die einzelnen
Verarbeitungsschritte des Publizierungsprozesses werden detailliert betrachtet und für den
Leser dadurch transparent und nachvollziehbar gemacht. Abschnitt 6 fasst die Ergebnisse
dieser Arbeit zusammen.
K
APITEL
2
A
NFORDERUNGSANALYSE
5
2 Anforderungsanalyse
Zunächst muss erörtert werden, welche technischen Anforderungen an ein Web-Content-
Managementsystem nach [JM02] zu stellen sind. Dies erfolgt im Hinblick auf die
Zielsetzung, dass sich Investitionen für eine Implementierung eines WCMS über hohe
Effizienz und gute Skalierbarkeit langfristig rentieren (vgl. [ZTZ01]). Die folgenden
Abschnitte arbeiten empfehlenswerte Technologien und Ansätze für eine Realisierung der zu
betrachtenden Komponenten eines WCMS heraus. In Abschnitt 3 werden dann für einige
dieser Ansätze konkrete Realisierungsvorschläge präsentiert.
2.1 Datenhaltung
Eine zentrale Komponente in WCMS ist das verwendete System zur Speicherung der Daten
1
.
Prinzipiell sind natürlich beliebige Speicherungsstrukturen denkbar (z.B. auch einfache
Textdateien). Meist werden jedoch aus Gründen der Leistungsfähigkeit bezüglich der
Verwaltung großer Informationsmengen Datenbanksysteme (DBS) eingesetzt. Dabei stehen
verschiedene Arten von DBS zur Verfügung. Diese sollen jetzt genauer betrachtet und die
Vorteile und Nachteile in Bezug auf die Belange des Web-Content-Managements
gegenübergestellt werden.
2.1.1 Relationale Datenbanksysteme
Die relationale Ablage von Daten ist unter den hier betrachteten das am längsten bekannte
Konzept zur Informationsspeicherung. Durch seine Einfachheit und die Existenz einer
soliden mathematischen Grundlage ist es weit verbreitet und hat sich vielfach bewährt (vgl.
z.B. [CDG02]).
Die Daten werden in Relationen (Tabellen) abgelegt, welche in den Zeilen die
einzelnen Datensätze (Tupel) und in den Spalten deren Attribute enthalten. Der Zugriff auf
einzelne Datensätze kann durch Indizes sehr schnell erfolgen. Mittels wertbasierter
Referenzen auf andere Relationen können Zusammenhänge zwischen verschiedenartigen
Datensätzen abgebildet werden ([KeEi99]).
Die Einfachheit des Modells begründet auch die hohe Performanz, mit der Daten
verarbeitet werden können. Gerade im Bereich Web-Content-Management ist es
entscheidend, dass angefragte Informationen schnellstmöglich bereitgestellt werden können.
Die technisch bedingten Antwortzeiten beim Zugriff auf Webinhalte über das Internet sind
ohnehin vorhanden. Weitere unnötige Verzögerungen durch langsame Datenzugriffe können
somit vermieden werden. Zusammen mit der Verfügbarkeit systematischer Schemaentwurfs-
methodiken und einer standardisierten Anfragesprache (Structured Query Language, SQL)
haben diese Eigenschaften zu hoher Akzeptanz und einer stabilen Position relationaler DBS
bei Unternehmen geführt.
1
Externe Datenbanken, auf die aus dem WCMS zugegriffen wird, bleiben an dieser Stelle unberücksichtigt.
A
NFORDERUNGSANALYSE
K
APITEL
2
6
Moderne Anwendungen sind meist objektorientiert aufgebaut. Es existiert also ein
konzeptioneller Bruch zwischen Anwendung und Datenbanksystem (im Englischen als
impedance mismatch bezeichnet). Ambler beschäftigt sich ausführlich in [Amb00] mit
diesem Thema. Das bedeutet insbesondere, dass die relationalen Daten in objektorientierter
Form verfügbar gemacht werden müssen. Ein möglicher Ansatz ist die Implementierung
eines anwendungsspezifischen Objektgenerators (Object Factory), der die benötigten
Objektinstanzen zur Laufzeit erzeugt und mit den entsprechenden Daten aus der Datenbank
füllt. Eine automatische Rückkopplung ist dabei nicht gewährleistet. Es müssen explizit
Methoden zur Verfügung gestellt werden, um die Daten in der Datenbank zu aktualisieren.
Neuere Ansätze decken den Bereich von einer Abbildungsbeschreibung (z.B. in
XML) der programmiersprachlichen Objekte auf Relationen (Object-Relational (OR)-
Mapping) (eXtensible Markup Language, [XML02]) bis zur vollautomatischen
Persistenzbereitstellung aus Sicht der Anwendung ab, wobei die relevanten Daten der
Objektinstanzen transparent in eine Datenbank abgebildet werden. Eine Festlegung des
Datenbankschemas ist im letzten Fall nicht mehr möglich und nötig. Hier ist eine sehr starke
Annäherung an die Konzepte objektorientierter Datenbanken zu erkennen, welche im
nächsten Abschnitt genauer betrachtet werden.
Objektrelationale Erweiterungen
Aufgrund der fehlenden breiten Akzeptanz objektorientierter Datenbanksysteme (vgl.
Abschnitt 2.1.2) und der enormen existierenden Datenbestände in relationalen Datenbanken
versuchen einige Hersteller von RDBS, nützliche objektorientierte Konzepte zu integrieren
([SBM99]). So werden z.B. komplexe Datenstrukturen (Klassen) inklusive Methoden und
Objektreferenzen eingeführt. Dadurch wird die hohe Performanz relationaler DBS mit der
Flexibilität objektorientierter DBS gekoppelt, wobei die Abwärtskompatibilität gewährleistet
ist. Der Zugriff auf die Daten erfolgt dann häufig über eine erweiterte Form von SQL (SQL3
bzw. SQL99, [MS01]). Allerdings werden existierende Standards in diesem Bereich noch
nicht von allen DBS-Herstellern gleichermaßen berücksichtigt. Unvollständige oder
abweichende Implementierungen erschweren häufig eine einheitliche Verwendung
objektorientierter Erweiterungen.
2.1.2 Objektorientierte Datenbanksysteme
Objektorientierte DBS (OODBS) überwinden die Kluft zwischen den Objekten der
Anwendung und der Struktur der Datenablage (vgl. Abschnitt 2.1.1), in dem die Daten
objektorientiert gespeichert werden ([MeWü00]). Das wirkt sich normalerweise so aus, dass
der Anwendungsentwickler über eine spezielle Anfragesprache (z.B. Object Query
Language, OQL, [CBB+00]) direkt die benötigten Objektinstanzen als Resultat erhält. Dabei
ist jedem Objekt ein eindeutiger Object Identifier (OID) zugeordnet, anhand dessen das
Objekt systemweit referenziert werden kann. Es lassen sich beliebig komplexe Objekttypen
(Klassen) und Datenstrukturen inklusive Methoden verwenden, wobei das OODBS diese
K
APITEL
2
A
NFORDERUNGSANALYSE
7
Datentypen kennen muss. Die Definition des ,,Datenbankschemas" in OODBS erfolgt daher
implizit bei der Modellierung des Objektschemas der Anwendung.
Die aus einer entsprechenden Anfrage erhaltenen Objektinstanzen haben meist eine
direkte Bindung zur Datenbank, so dass Änderungen sofort im Datenbestand wirksam
werden
1
. Die Notwendigkeit eines Objektgenerators oder eine explizite Beschreibung der
Abbildung zwischen Objekten und Datenstruktur wie in Abschnitt 2.1.1 beschrieben entfällt
somit.
Ein WCMS sollte eine direkte Zugriffsmöglichkeit auf interne Vorgänge und den
Datenbestand ermöglichen, um eine bedarfsgerechte Verwendbarkeit des Systems
gewährleisten zu können. Dies wird in modernen Anwendungssystemen häufig über ein
offen gelegtes objektorientiertes Application Programming Interface (API) erreicht. OODBS
haben in diesem Zusammenhang den Vorteil, dass die Objekte des ,,Datenbankschemas"
direkt über das API verfügbar gemacht werden können. Eine zusätzliche Zwischenschicht
kann somit entfallen.
Wesentliche Nachteile von OODBS sind der erst seit kurzem existierende Standard
für eine Anfragesprache und das Fehlen einer bewährten systematischen Methodik für den
Schemaentwurf. Aufgrund der heterogenen und komplexeren Datenstrukturen und dem damit
verbundenen größeren Verwaltungsaufwand ist auch die Performanz von OODBS in vielen
Anwendungsfällen geringer als bei RDBS. Zusammen mit den fehlenden Erfahrungswerten
im dauerhaften Einsatz der noch als neu zu bezeichnenden Technologie erscheint diese
Systemfamilie für viele Anwendungsbereiche momentan ungeeignet.
2.1.3 XML-Datenbanksysteme
Die Einsatzgebiete der XML weiten sich kontinuierlich aus. Mittlerweile hat sie sich als
universelles Datenaustauschformat in so verschiedenen Bereichen wie medienübergreifendes
Publizieren (Cross-Media Publishing), RPC-Protokolle, Konfigurationsdaten oder
Workflow-Sprachen als unverzichtbar etabliert. Mit der steigenden Nutzung wächst auch der
Bedarf an einer persistenten Speicherung von XML-Daten. An dieser Stelle setzt die noch
relativ neue Klasse der XML-Datenbanksysteme an.
Man kann verschiedene Arten der Speicherung von XML-Daten unterscheiden. Mit
einer nativen XML-Datenbank (XML-DB) verbindet man die unveränderte Speicherung im
XML-Format, wobei Indexstrukturen ergänzt werden, um den effizienten Zugriff auf die
Daten zu ermöglichen. Eine weitergehende Unterscheidung ist möglich nach der Ablage im
Textformat oder als serialisierte Baumstruktur im Binärformat (vgl. Document Object Model,
DOM, [DOM02]).
Eine andere Art von XML-Datenbanken nennt man ,,XML enabled" (XED). Hier
erfolgt die Interaktion mit der Außenwelt zwar auch ausschließlich im XML-Format, intern
werden die eigentlichen Nutzdaten aber aus der XML-Struktur extrahiert. Die Ablage erfolgt
dann z.B. in einem relationalen oder objektorientierten DBS. Bei dieser Art der
1
Eine Transaktionsverwaltung ist unabhängig von dieser automatischen Persistenz natürlich trotzdem möglich.
A
NFORDERUNGSANALYSE
K
APITEL
2
8
Datenspeicherung ist nicht gewährleistet, dass die Struktur gespeicherter XML-Dokumente
original erhalten bleibt. Die Strukturinformationen werden teilweise nicht mit gespeichert.
Zum Beispiel kann bei erneuter Abfrage eines Dokuments die Reihenfolge von Elementen
anders sein.
Bei Anwendungen muss darüber hinaus zwischen datenzentrierten und dokument-
zentrierten unterschieden werden. XED sind eher für datenzentrierte Anwendungen geeignet,
da es hier nur auf die Nutzdaten ankommt, die Strukturinformationen dagegen nur
untergeordnete Bedeutung haben. Im Gegensatz dazu ist es bei dokumentzentrierten
Anwendungen wichtig, dass die XML-Dokumente unverändert erhalten bleiben. Ist diese
Voraussetzung gegeben, so muss eine native XML-DB eingesetzt werden.
Allen XML-Datenbanksystemen ist gemeinsam, dass sie spezielle XML-basierte
Anfragesprachen unterstützen, die für die Adressierung von Informationen innerhalb eines
XML-Datenbestands optimiert sind (z.B. XQuery, [XQU02]). Auch hier besteht aber das
Problem, dass noch keine anerkannten Standards existieren. Es wird allerdings intensiv an
einer solchen Standardisierung gearbeitet.
Aus Sicht des Web-Content-Managements sind XML-DBS besonders interessant.
Das übliche HTML-Format von Webseiten kann leicht in die XML-konforme Variante
(XHTML, [XHT02]) umgeformt werden. Somit ist eine Speicherung in einer XML-
Datenbank problemlos möglich.
2.1.4 Bewertung im Kontext des Web-Content-Managements
Alle oben genannten Arten von DBS sind grundsätzlich geeignet, um als Datenspeicher für
ein WCMS zu dienen. Allerdings können die Stärken von objektorientierten bzw. XML-DBS
in diesem Zusammenhang nur schlecht ausgenutzt werden, weshalb der zusätzliche
Verwaltungsaufwand nicht gerechtfertigt erscheint.
In späteren Abschnitten wird sich z.B. zeigen, dass gerade beim Web-Content-
Management Webseiten nicht mehr vollständig im (X)HTML-Format gespeichert, sondern
vorher in ihre Bestandteile (Assets) zerlegt werden. Diese Assets (z.B. Textabschnitte,
Bilder) sind darüber hinaus sehr einfach, so dass eine Abbildung durch komplexe
Objekttypen oder eine Speicherung als XML-Dokumente keine Vorteile bringt. Auch alle
anderen Objekte, wie etwa das Objekt Seite, lassen sich leicht ohne komplexe Objekttypen
abbilden. Somit ist eine Verwendung rein objektorientierter DBS oder nativer XML-DBS
nicht unbedingt zu empfehlen.
Unter Umständen kann es notwendig sein, sehr spezielle Integritätsbedingungen und
Benutzerrechte zu verwenden, z.B. wenn man auf Ebene der Assets arbeitet. In diesem Fall
könnte trotz obiger Ausführungen eine Verwendung von komplexen Datentypen hilfreich
sein, da hier durch Kapselung und Verwendung von Methoden beliebiger Zugriffschutz
realisiert werden kann. Es sind dabei aber nur wenige einfache objektorientierte Konzepte
notwendig, so dass der Einsatz eines objektrelationalen DBS ausreicht. Der Performanz-
vorteil relationaler DBS bleibt weitgehend erhalten.
K
APITEL
2
A
NFORDERUNGSANALYSE
9
Die einzelnen Assets sind im Normalfall sehr fein granuliert, um eine möglichst hohe
Wiederverwendbarkeit sicher zu stellen. Deshalb ist es auch selten notwendig, Suchaktionen
innerhalb der Assets durchzuführen. Sollte diese Funktionalität dennoch wichtig sein, würde
das für die Verwendung von XML-DBS sprechen, da hier bis zu einem gewissen Grad auch
,,Feldinhalte" für eine schnelle Suche indiziert werden können.
Bei voller Ausnutzung aller denkbaren Funktionalitäten eines WCMS wäre also nach
obigen Betrachtungen ein XML-fähiges objektrelationales Datenbanksystem zu bevorzugen,
da hier praktisch keine Einschränkungen bzgl. der Performanz existieren und alle
möglicherweise benötigten Datenstrukturen in einfacher Form nutzbar sind. Aus
pragmatischer Sicht müssen allerdings die Existenz von etablierten Standards und der
Verbreitungsgrad der Datenbanktechnologie berücksichtigt werden. Unter diesen
Gesichtspunkten scheint die Verwendung eines rein relationalen DBS sinnvoll. Es gibt eine
Vielzahl von bewährten (O)RDBS (Oracle, MS SQL Server, IBM DB2, MySql, u. a.) mit
breiter Unterstützung wichtiger Standards (SQL-92, BLOBs). Durch eine Beschränkung auf
rein relationale Konzepte ohne Nutzung objektrelationaler Erweiterungen kann maximale
Unabhängigkeit und Flexibilität sichergestellt werden.
Als Folgerung aus den obigen Ausführungen wurde in dieser Arbeit Oracle 9i als
relationales Datenbanksystem ausgewählt. Das entwickelte Datenschema wurde in Form
eines Entity-Relationship-Diagramms modelliert und auch die Beispielimplementierungen
wurden entsprechend ausgerichtet. Eine Umsetzung auf Basis eines alternativen DBS-Typs
sollte jedoch ohne Probleme möglich sein.
2.2 Funktionale Aspekte
Neben der reinen Datenhaltung in einem Web-Content-Managementsystem sind
insbesondere funktionale Aspekte von Interesse, d.h. alle Bereiche oder Komponenten des
Systems, welche für die entscheidende Funktionsweise wesentliche Bedeutung haben. Meiler
und Jablonski beschreiben den zentralen Gedanken eines WCMS in [JM02] folgendermaßen:
,,Web-Content-Management ist Content-Management, das sich in erster Linie auf Web-
Content beschränkt, also Informationen, Dokumente und Daten, die durch HTML-Seiten
dargestellt oder zumindest durch HTML-Dokumente referenziert werden". Moderne
Einsatzgebiete von WCMS legen eine Erweiterung dieser Charakterisierung nahe, wobei das
zitierte HTML-Format verallgemeinert wird und beliebige Ausgabeformate eingeräumt
werden. So ist eine Möglichkeit zur Publizierung von ,,Web"-Content nach dem Motto
single-source-multiple-media z.B. auch im WML-Format für WAP-fähige Endgeräte oder als
PDF-Datei erforderlich. An anderer Stelle wird dieser Gedanke auch in [JM02]
angesprochen. Hier soll er allerdings noch mehr in den Mittelpunkt gerückt werden. Eine
genauere Begründung wird in Abschnitt 2.2.2 geliefert.
A
NFORDERUNGSANALYSE
K
APITEL
2
10
Die wohl wichtigste Funktionalität im Rahmen eines WCMS stellt das Asset-
Management dar. Es bildet die zentrale Sammelstelle für jegliche Bestandteile des Web-
Contents. Deshalb soll diese Komponente auch als erste genauer betrachtet werden.
2.2.1 Asset-Management
Wie bereits in Abschnitt 2.1.4 erwähnt versteht man unter digitalen Assets ganz allgemein
die Bestandteile eines digitalen Dokuments. Im Zusammenhang mit Web-Content sind hier
insbesondere Text, Bilder und beliebige darin referenzierte Dateien oder URLs (Uniform
Resource Locators) gemeint. In Unternehmen existiert häufig keine Vereinbarung über die
einheitliche Handhabung von digitalen Assets. So sind wichtige Bilder oder Dokumente
irgendwo im Netzwerk auf irgendeinem Rechner in irgendeinem Unterverzeichnis
gespeichert. Bestenfalls der Ersteller dieser Assets weiß noch, wie und wo er sie später
wieder finden kann. Dabei könnte diese Datei von Mitarbeitern gewinnbringend auch an
anderer Stelle genutzt werden.
Ziel des Asset-Managements ist es deshalb, ein zentrales Repositorium für alle
wichtigen Informationsbestandteile des Unternehmens bereitzustellen. Durch entsprechende
so genannte inhaltliche Metadaten werden die einzelnen Assets genau klassifiziert, so dass
eine effiziente Suche nach unterschiedlichsten Kriterien möglich ist. ,,Das Asset-
Management umfasst alle Funktionen, um den ... zu publizierenden Content zu verwalten, zu
strukturieren und darzustellen" ([Bü00]). Die Archivierung des Contents in der gleichen oder
einer externen Datenablage ist ein separates Themengebiet und wird hier nicht näher
betrachtet.
Ein wichtiger Gesichtspunkt bei der Verwaltung der Assets ist die Dokumentation
von Änderungen. Es soll zu jeder Zeit nachvollziehbar sein, wann und von wem bestimmte
Informationen erstellt, modifiziert oder gelöscht wurden. Es ist deshalb sinnvoll, eine
umfassende Funktionalität zur Versionierung bereitzustellen. Dabei werden alle Assets mit
Versionsnummern versehen. Soll eine bestimmte Version eines Assets geändert werden, so
wird zuerst eine Kopie unter einer neuen Versionsnummer erstellt und diese dann zur
Veränderung freigegeben. Die vorhergehende Version des Assets bleibt dadurch weiterhin
verfügbar. Dies ist auch wichtig, damit Verweise auf Assets und deren Inhalt auch nach
Änderungen gültig und sinnvoll bleiben.
Es ist zwischen zeitbehafteter und zeitfreier Sichtweise zu unterscheiden (vgl.
[MSW83]). Im ersten Fall ist es möglich, eine Version eines Assets zu referenzieren, ohne
die genaue Versionsnummer zu kennen. Die Identifizierung erfolgt dann über den Zeitpunkt
der Gültigkeit dieses Assets. Es wird also untersucht, welche Version zu dem angegeben
Zeitpunkt die aktuellste war. Damit würde es zum Beispiel auch leicht möglich, einen
zurückliegenden konsistenten Gesamtzustand des Inhalts anhand des Zeitpunkts wieder
herzustellen. Im anderen Fall der zeitfreien Sichtweise muss zur Identifizierung eines Assets
explizit die Versionsnummer bekannt sein. Um auch in diesem Fall die Möglichkeit zu
haben, einen zurückliegenden konsistenten Gesamtzustand wiederherzustellen, ist es
K
APITEL
2
A
NFORDERUNGSANALYSE
11
notwendig, eine Markierung (engl. label) einzuführen. In dem gewünschten reaktivierbaren
Zustand werden zum Beispiel alle innerhalb des ,,Live"-Contents referenzierten Assets mit
der gleichen Markierungsnummer versehen (vgl. Abbildung 2). Dadurch ist gewährleistet,
dass nach beliebigen Änderungen die markierte zusammengehörende Assetmenge ermittelt
und reaktiviert werden kann.
Version 1
Version 2
Version 3
Version 4
Version 1
Version 2
Version 3
Version 1
Version 2
Version 3
Version 4
Version 5
Asset 1
Asset 2
Asset 3
Markierung 1
Abbildung 2: Markierung einer konsistenten Assetmenge in Anlehnung an [Voig01]
Weiterhin muss überlegt werden, wie die Handhabung verschiedener Versionen erfolgen soll.
Es könnte zum Beispiel wünschenswert sein, dass nach der Änderung eines Assets alle
Verweise auf die bisherige Version durch die neue Version ersetzt werden, d.h. es wird
immer automatisch die aktuellste Version verwendet. Dies würde verlangen, dass
Modifikationen inhaltlich nur von geringer Bedeutung sein dürfen, da sonst unter Umständen
an einigen Stellen der inhaltliche Zusammenhang verletzt wird. Zum Beispiel könnte in
jedem Dokument ein Bild des zuständigen Ansprechpartners vorhanden sein. Ändert sich der
Ansprechpartner, so wäre es wünschenswert, durch Ersetzen des Bildes mit einem Foto des
neuen Ansprechpartners alle betroffenen Dokumente automatisch zu aktualisieren. Wird
dieses Bild allerdings auch auf der persönlichen Informationsseite des alten Ansprechpartners
verwendet, so ergäbe das neue Bild an dieser Stelle keinen Sinn.
Eine andere Möglichkeit besteht in der Einbeziehung der Versionsnummer in die
Identifikation eines Assets. Das bedeutet, dass ein Verweis auf ein bestimmtes Asset immer
auch die entsprechende Versionsnummer umfassen muss. Dies stellt sicher, dass auch nach
Änderungen die korrekte Version des Assets verwendet wird. Allerdings ist es dabei
notwendig, etwaige Änderungen in allen referenzierenden Dokumenten explizit zu
aktualisieren. Unter Umständen kann dies mit einem hohen Aufwand verbunden sein. Dieser
Ansatz wirkt jedoch stabilisierend auf die Qualität des Datenbestands, da unnötige
Fehlerquellen vermieden werden.
Zusätzlich zu verschiedenen Versionen eines Assets kann es auch Bedarf an
verschiedenen Varianten geben. Eine Variante stellt sozusagen eine ,,Abzweigung der
Versionskette" eines Assets auf der Basis einer bestimmten Version dar (vgl. [WM81]). Eine
Variante wird dabei unabhängig von anderen Varianten des gleichen Assets versioniert. So
ist es zum Beispiel möglich, mehrere unterschiedliche Varianten eines Dokuments zu
verwalten und die Änderungen jeder Variante extra zu protokollieren. Es ist somit
A
NFORDERUNGSANALYSE
K
APITEL
2
12
gewährleistet, dass der Zusammenhang der Varianten als ,,gleiches" Asset erhalten bleibt
(vgl. Abbildung 3).
Um ein Asset eindeutig identifizieren zu können, ist neben der Versionsnummer nun
auch die Variantennummer zu berücksichtigen. Im Gegensatz zu der in [WM81]
vorgeschlagenen Vorgehensweise kann hier auf eine getrennte Speicherung von
variantenübergreifenden und variantenspezifischen Informationen aus Gründen des
geringeren Verwaltungsaufwands verzichtet und in dem zugrunde liegenden DBS
ausreichend Speicherplatz unterstellt werden.
Version 1
Variante 1
Version 2
Variante 1
Version 1
Variante 2
Version 3
Variante 1
Version 4
Variante 1
Version 2
Variante 2
Variante 2
Variante 1
Versions- /
Variantenverlauf
eines Assets
Gleiche Version als Basis
Abbildung 3: Versionen vs. Varianten
Wie weiter oben ausgeführt können beliebige Texte und Dateien als Assets behandelt
werden. In Abschnitt 2.2.2 wird erläutert, warum eine Möglichkeit zur orthogonalen
Behandlung von Struktur, Inhalt und Darstellung eines Dokuments wichtig ist und dann das
Prinzip auf eine separate Betrachtung von Programmlogik erweitert. Ausgehend von der
Möglichkeit, diese vier Aspekte eines Dokuments getrennt voneinander beschreiben zu
können, erscheint es logisch, diese Beschreibungen jeweils wieder als eigenes Asset zu
speichern. Es gibt also inhaltliche Assets (z.B. Textabschnitte, Bilder, usw.), strukturelle
Assets (Beschreibungen der Struktur von Dokumenten), darstellende Assets (Beschreibungen
der Darstellungsweise von Dokumenten) und Assets, welche die Einbettung von
Programmlogik in Dokumente beschreiben. In den folgenden Ausführungen wird einfach
von Struktur, Inhalt, Darstellung (engl. layout) und Logik gesprochen.
2.2.2 Trennung von Struktur, Inhalt, Darstellung und Programmlogik
Das Erstellen von Internetpublikationen ist ein arbeitsteiliger Prozess, an dem unter anderem
Redakteure, Grafiker, Lektoren, Softwareentwickler und viele andere mehr beteiligt sein
können. Ein grundlegendes Entwurfsprinzip von Web-Content-Managementsystemen ist
deshalb die Trennung von Struktur, Inhalt und Darstellung (vgl. [Bü00], [JM02], [RoRi01],
[Su01], [SW00]), welche eine Arbeitsteilung erst ermöglicht. Abschnitt 3.3 zeigt, wie eine
Details
- Seiten
- Erscheinungsform
- Originalausgabe
- Jahr
- 2002
- ISBN (eBook)
- 9783832464370
- ISBN (Paperback)
- 9783838664378
- DOI
- 10.3239/9783832464370
- Dateigröße
- 1.9 MB
- Sprache
- Deutsch
- Institution / Hochschule
- Friedrich-Alexander-Universität Erlangen-Nürnberg – unbekannt, Informatik
- Erscheinungsdatum
- 2003 (Februar)
- Note
- 1,0
- Schlagworte
- entity relationship-diagramm wcms java asset management
