Content Repository - Gibt es den einheitlichen Zugriff auf Content?
Gastbeitrag von Dr. Martin Bartonitz, Product Manager Workflow, SAPERION AG. Berlin
E-Mail: martin.bartonitz@saperion.de
Webseite: www.saperion.de
(Der erste Teil des Artikels erschien im PROJECT CONSULT Newsletter 20090528Newsletter 20090528)
JSR 170 im Detail – Compliance Level
Das Datenmodell ist sehr einfach aufgebaut und gleicht einem n-ary tree. Jedes Repository besitzt mindestens einen Workspace. Ein Workspace besitzt ein oder mehrere Items. Ein Item kann entweder eine Node oder ein Property sein. Eine Node kann wiederum kein Kind oder mehrere Kinder haben, sowie kein Property oder mehrere Properties besitzen, in denen der eigentliche Content gespeichert wird. Ein Property kann kein Kind besitzen.
Eine Node besitzt nur genau einen primären Node-Typ, der seine Charakteristik festlegt, z.B. seine Properties und Kinder, die sie haben darf. Darüber hinaus können Nodes ein oder mehrere Mixin-Typen zugewiesen werden. Diese steuern, ob für eine Node Versionierung unterstützt wird, ob eine Node zeitweise für einen Zugriff gesperrt werden können soll oder ob ihr beim Anlegen eine eindeutige Identifikationsnummer zugewiesen werden soll.
Die Grafik zeigt ein hierarchisch aufgebautes Content Repository mit 3 Workspaces. Die Kreise stellen Nodes dar, Kästchen sind Properties. Im mittleren Workspace besitzen Nodes Kinder.Das Datenmodell erlaubt ein völlig einfaches Ablegen ohne Strukturen, in dem jeder zu speichernde Content in einer Node unterhalb der Root-Node eines Workspaces gespeichert wird. Dies entspricht der „Data First“-Strategie, in dem sich der Repository Designer vorab keine Gedanken um ein Suchen über Strukturen, wie wir es in einem File-System kennen, zu machen braucht. Da Nodes wiederum mit anderen Nodes verlinkt werden können, kann eine Struktur, wie z.B. eine Kundenakte viel später nachgezogen werden. Die Suche erfolgt dann ähnlich, wie wir dies von den Web-Suchmaschinen kennen, über eine Volltextsuche. Übrigens kann im JCR-Modell auch über die Inhalte der vorherigen Versionen von Inhalten gesucht werden. Sind aber im Vorhinein schon die Strukturen des Repository klar und der Content soll auch nur entsprechend diesen Strukturen für ein effizienteres Wiederfinden abgelegt werden, kann entsprechend der „Structure First“-Strategie verfahren werden.
Tabelle mit einer Gegenüberstellung von unterstützten Funktionen (nicht vollständig) für ein Content Repository durch einen Standard.
*1 Erweiterte Spezifikationen durch IETF und IESG
Die für Content Repository interessanten Funktionen sind in der obigen Tabelle für die schon genannten Standards bzgl. ihrer Unterstützung aufgelistet. Zu beachten ist, dass diese Gegenüberstellung beschränkt funktioniert, da der JCR eine API ist und die anderen Standards ein Protokoll festlegen.
Der JCR-Standard unterscheidet für die Implementierung mehrere Compliance Level. Ein Level-1-konformes JCR-System bietet für die Verwendung von gespeicherten Daten neben den Strukturen (siehe nächstes Kapitel) die Funktionen Query und Read, u.a. von hierarchischen Strukturen, aber auch den Export der enthaltenen Daten. Typische Anwendungen für Level 1 sind:
| | | |
| | · | CMS Templates, Content Delivery |
| | · | Anzeige von Portlets |
| | · | Repository Export |
| | · | Generierung von Berichten |
| | · | Federation Repositories |
Im Level 2 kommen die Funktionen zum Schreiben von geänderten Daten, die Volltext-Suche, der Import, als auch die Zugriffskontrolle hinzu. Typische Anwendungen für Level 2 sind:
| | | |
| | · | Entry Level Content Management |
| | · | Entry Level Document Management |
| | · | Workflow |
| | · | Collaboration |
| | · | Content Aggregation (Content Warehouse) |
Optionale Funktionen (advanced) sind die Versionierung, das Sperren von Objekten (Locking), die Beobachtung (Events), die Transaktionen (JTA Support), SQL-Query sowie Funktionen rund um das Thema Aufbewahrungszeiten (Retention & Records Management). Beispiele für einvollständig konformes JCR:
| | | |
| | · | Complete ECM System |
| | · | Transactional Applications |
| | · | Source Control Mangement Systems |
Die folgende Grafik zeigt nochmals im Überblick, dass ein Content Repository deutlich mehr Funktionalität bietet als eine Datenbank und ein File-System zusammen:
Nutzenpotenzial
Firmen wollen nicht mit Problemen beim Hersteller-spezifischen Login konfrontiert werden. Im Allgemeinen haben Firmen mehr als ein Content Repositories im Einsatz, da Abteilungen bisher meist frei in der Wahl ihrer Anwendungen waren, oder weil zugekaufte Firmenteile schon ein anderes im Einsatz hatte. In der Vergangen wurde vie Geld investiert, damit diese Anwendungen interagieren können. Mit JSR 170 kommt Investitionssicherheit, da die gleiche Anwendung mit allen Content Repositories zusammen arbeiten kann.
Entwickler brauchen keine Zeit zu verschwenden, um sämtliche Hersteller-spezifischen API zu erlernen. Sobald sie mit JSR 170 vertraut sind, können sie mit allen JSR-konformen Repositories arbeiten. In der Vergangen mussten sie sich entscheiden zwischen einem sehr guten Repository und einem eher schlechten Entwicklungswerkzeug oder vice versa. Zukünftig können sie sich für jeweils das beste Repository und das beste Tool bzw. die beste Applikation entscheiden.
Hersteller von Content Management Systemen waren bisher gezwungen, ihr eigenes Repository zu entwickeln und zu pflegen, was eine Menge an Coding bedeutete. Nun können sie die Entwicklung von Content Repositories einigen guten Herstellern überlassen und sich mehr auf die Entwicklung der eigenen CMS-Anwendung konzentrieren.
Programmierbeispiele
Die Grafik zeigt am Beispiel eines einfachen Wiki den Aufbau eines Content Repository.
Dieses Kapitel ist vorrangig an die Programmier-Interessierten gerichtet und zeigt die Nutzung einzelner Funktionen der JCR-API am Beispiel einer Anwendung, hier eines einfachen Wiki. Aber lassen sie sich von dem Programmcode nicht abschrecken, und lesen Sie die begleitenden, kurzen Texte, die den jeweiligen Anwendungsfall beschreiben.
Die Root-Node enthält die Node „encyclopedia“, die wiederum 2 Kinder-Nodes besitzt. Die Kinder-Nodes enthalten die einen Wiki-Eintrag beschreibenden Daten wie Titel, Kategorie sowie den eigentlichen Content in Properties (Kästchen). Diese Nodes besitzen keine weiteren Kinder, d.h. die Struktur ist sehr flach gehalten.
Um Operationen auf dem Repository über die API auszuführen, wie zum Beispiel das Anlegen genau der in der Grafik enthaltenen Objekte, muss wie folgt codiert werden:
Nachdem die Objekte Workspace und RootNode für weitere Operationen verfügbar sind, wird noch ein Namespace „wiki“ zur Sicherstellung, dass die Namensgebungen nicht mit anderen Projekten kollidieren, festgelegt.
Schreiben von Content
Nun können die Nodes mit ihrem Content in das Repository geschrieben werden:
Wie oben für die Kategorie zu erkennen ist, können Properties Multi-Value Felder sein.
Browsen von Content
Der Zugriff auf den Content erfolgt entweder direkt über die eindeutige Nummer einer Node (UUID) oder traversierend, welches im folgenden Beispiel gezeigt ist. Das Traversieren kann von jeder Stelle im Baum aus erfolgen, hier erfolgt es von der obersten Node „encyclopedia“ aus.
Im folgenden Beispiel ist noch die Suche nach allen Wiki-Einträgen mit „Rose“ im Titel dargestellt. Die Suche ist in der JCR-Spezifikation mittels XPATH vorgesehen, da die die JCR-Strukturen denen von XML sehr ähnlich sind und damit gut geeignet ist. Gesucht wir mit Hilfe des QueryManager Objekts:
Migration von JCR-Implementierungen
Die JCR-Spezifikation hat auch Funktionen zur Portierbarkeit von JCR-Implementierungen berücksichtigt, so dass der Content von einem kompatiblen System des Herstellers in ein kompatibles System eines anderen Herstellers mit nur wenigen Zeilen Code übertragen werden kann. Auf der einen Seite wird in XML-Dateien exportiert und auf der anderen Seite werden diese XML-Dateien wieder importiert. Der Export sieht wie folgt aus:
Und der Import ist ebenso kurz:
Speichern von binären Daten
Bisher wurde nur Content vom Typ String genutzt. JCR kennt weitere Typen wie Date, Long Integer und Boolean. Es können aber auch binäre Daten gespeichert werden, wie das folgende Beispiel zeigt, das die Datei rose.gif als Property zum vorhandenen Node speichert, sowie Informationen zum Änderungszeitpunkt:
Versionierung
In vielen Anwendungen, speziell in der Pharmazie oder in kritischen, technischen Bereichen wie der Flugzeugindustrie, oder auch dem Qualitätsmanagementhandbuch mit Information wie Arbeitsanweisungen, muss zum zwecke der Nachweisbarkeit sichergestellt werden, dass frühere Versionen von Dokumenten weiterhin zugänglich sind.
Die Grafik zeigt einen Versionierungsbaum beginnenden mit der Version History Node (VH), sowie den einzelnen Versionen.
Die Versionierung erfolgt mittels weiterer Nodes (siehe Grafik). Sobald einer Node der Mixin-Typ „mixin:versionable“ zugewiesen wurde, wird ihr beim Anlegen automatisch die Version History Node (VH) gefolgt von der Version Root Node (Vroot) und der ersten Version Node (Va) angehängt. Wird eine neue Version abgelegt, so wird eine weitere Version Node (Vb, Vc) an die Version History Node gehängt. Die Verion Nodes erhalten eine Referenz, die von der Vorgänger Version Node kommt. D.h. es ist möglich, den Content einer älteren Version zu laden, zu verändern und als neue Version abzuspeichern. Die zu nutzenden Methoden für das Ändern des Contents einer Node „n“ sind z.B.:
Der Versionierungsbaum kann wie folgt gebrowst werden:
Da die Version Root Node keine weiteren Informationen enthält und nur als Vorgänger für die erste Version dient, wird sie geskipt.
JSR 170 Compliance
Ein Content Repository darf sich JSR 170 compliant nennen, wenn es die Testprozeduren (über 1000) für die Level 1 und 2 ohne Fehler besteht. Es darf sich fully compliant nennen, wenn es auch die Tests der optionalen Funktionen besteht.
Die Test-Tools werden von der JSR 170 Expertengruppe zur Verifikation der Compliance zur Verfügung gestellt.
Erweiterungen der JSR 283 Spezifikation
Die kurz vor der Freigabe stehende JSR 283 Spezifikation, die auch als JCR 2.0 bezeichnet wird, führt die Spezifikation der JSR 170 mit einigen weiteren Funktionen fort. Dazu gehört u.a. eine erweiterte Zugriffskontrolle als auch Versionsmanagement, das Journaling von Events, Aktivitäten für Workflows, sowie Funktionen zum Livecycle Management. Es wird allerdings nicht mehr mittels XPATH sonder per SQL2 und JQOM gesucht.
Zusammenfassung
Manche euphorischen Stimmen aus der JCR-Expertengruppe sprechen von einer Revolutionierung zur Erleichterung in der Implementierung von neuen Anwendungen, die Content verwalten sollen. Sicherlich ist der Ansatz für den JCR, die Möglichkeiten von relationalen Datenbanken sowie strukturierten File-Systemen zusammenzulegen und mit einigen weiteren nützlichen Funktionen auszustatten ein wichtiger, weiterer Schritt. Messen lassen muss sich dieser Standard wie alle anderen auch an der Marktakzeptanz, sprich vorrangig an der Implementierung entsprechender Schnittstellen auf den vorhandenen Content Management Systemen der Hersteller.
Wie die nachfolgenden Listen zeigen, scheint der JCR tatsächlich auf einem guten Weg zu sein. Hinzukommt, dass die Mitgliederzahl der JSR Expertengruppe sich von 22 auf 48 für die 283er Spezifikation erhöht, d.h. mehr als verdoppelt hat. (MaB)
Metadata
