Der Java Content Repository Standard im Portrait: Content für alle
Trotz erheblicher Konsolidierungstendenzen ist der Markt im Bereich von Systemen, die den Content-Lifecycle unterstützen, äußerst unübersichtlich und heterogen. Entstanden aus dem Bedarf, Websites oder Dokumente in einfacher Weise zu bewirtschaften, sind Content Management Systeme immer weiter gewachsen und dringen nun verstärkt in strategische Unternehmensbereiche vor. Inzwischen benötigen Unternehmen eine tragfähige Content-Infrastruktur, auf deren Basis sie die vielfältigen, auch geschäftskritischen Webanwendungen aufsetzen können. Zurzeit sind in diesem Bereich allerdings keine hinreichenden Industriestandards vorhanden, auf denen aufgebaut werden kann. Vielmehr gibt es eine Vielzahl proprietärer Systeme, die nur schwer miteinander verbunden werden können. Vergleicht man dies etwa mit Datenbanken oder Application-Servern – Systemen, die als Infrastruktur für eine Vielzahl von Anwendungen dienen – wird der Unterschied augenfällig. Hier setzt der Standard „Content Repository API for Java Technology“ (JCR) an, der im Rahmen des JSR-170 spezifiziert und in der Version 1.0 im Juni 2005 veröffentlicht wurde. Er stellt eine standardisierte API für den Zugriff auf Content-Repositories zur Verfügung.
Content Repositories
Eine Webanwendung, etwa ein Mitarbeiterportal im Intranet, lebt von den Inhalten, die dem Benutzer für die von ihm zu erledigenden Aufgaben zur Verfügung gestellt werden. Der Nutzer muss Zugriffsberechtigungen haben, um Content nutzen und verändern zu dürfen, er möchte gezielt nach Inhalten suchen können oder über die aktuellen Neuigkeiten auf seinem Gebiet informiert werden. Dies macht deutlich, dass es hier nicht um die reine Bereitstellung von Daten geht, sondern diese Daten mit bestimmten Services zu versehen sind. Zu ihnen gehören beispielsweise eine Zugriffskontrolle, eine Möglichkeit zur Suche und eine Versionierung. Es sind relativ wenige, aber äußerst wichtige Services, die in den Content-nutzenden Anwendungen immer wieder benötigt werden. Diese von den Anwendungen zu trennen und über eine standardisierte API zur Verfügung zu stellen, ist die Idee des JCR. Somit müssen diese Funktionalitäten nicht immer und immer wieder aufs Neue in der Anwendung implementiert werden, sondern werden einfach über die Repository-API abgerufen. Eine solche standardisierte API steigert nicht nur die Effizienz in der Anwendungsentwicklung, sie erleichtert den Kunden auch den Umstieg auf andere Systeme, sei es ein neues Repository (mit Standard-API), seien es entsprechende Anwendungen.
Die Content Repository API
Im Folgenden werden die Grundzüge des Content-Repository-Standards vorgestellt. Dieser Überblick lässt natürlich viele Details der Spezifikation außer Acht. Hierfür sei auf die Spezifikation selbst verwiesen [1]. Einige Randbedingungen wurden bei der Ausarbeitung der Spezifikation als wesentlich betrachtet und entsprechend als besondere Ziele formuliert:
Unabhängigkeit von zu Grunde liegenden Architekturen, Datenquellen und Protokollen: Hier gilt es insbesondere, hierarchische und nicht-hierarchische Repository-Modelle zu ermöglichen. Dem wird entsprochen, indem sowohl pfadbasierte, hierarchische als auch direkte, ID-basierte Zugriffe ermöglicht werden. |
Einfache Verwendung durch Programmierer: Dies wird durch ein einfaches Objektmodell und die Konzentration auf die wesentlichen Kernfunktionalitäten erreicht. |
Möglichst einfache Implementierung auf einem weiten Spektrum vorhandener Content-Repositories: Im Spezifikationsprozess wurde darauf geachtet, dass wesentliche Funktionalitäten einfach umgesetzt werden können. |
Standardisierung auch von komplexeren Funktionalitäten, die von anspruchsvollen Anwendungen benötigt werden: Dies steht in gewissem Widerspruch zu dem vorgenannten Punkt. Deshalb hat man sich entschieden, die API in mehrere Level zu unterteilen. Level 1 stellt wesentliche Grundfunktionalitäten zum lesenden Zugriff zur Verfügung. Level 2 definiert Funktionalitäten, die insbesondere auf das Verändern der Repository-Inhalte abzielen. Ferner gibt es noch eine Reihe von Funktionalitäten, die als optional spezifiziert sind. |
Mit diesem Hintergrund wird eine API, bestehend aus einer Reihe von Java-Interfaces, spezifiziert. Das gesamte Repository wird durch ein Objekt repräsentiert. Es besteht aus einem oder mehreren so genannten „Workspaces“.
Jeder Workspace enthält eine Baumstruktur aus „Nodes“ und „Properties“, deren Eigenschaften in der Spezifikation beschrieben sind. Sie spezialisieren beide das Interface „Item“. Nodes können in unterschiedlichen Typen vorliegen und hierarchisch untergeordnete Objekte („Kinder“, d. h. wiederum Nodes und Properties) haben. Properties hingegen sind als die Blätter des Baums zu betrachten, die also keine untergeordneten Elemente haben. Eine Property hat einen Inhalt, der über das „Value“-Interface zur Verfügung gestellt wird.
Wie bereits erwähnt, sind die Funktionalitäten, die vom Content-Repository bereitgestellt werden, in zwei Level unterteilt. Level 1 der Spezifikation stellt folgende Funktionen bereit:
- Lesender Zugriff
- Unterschiedliche Granularität
- Hierarchie
- Strukturiert (Typisierung)
- Property Types
- Node Types (Introspection komplexer Content-Strukturen)
- XPath-Suche
- XML-Export
XPath-Suche und XML-Export verwenden die im Standard beschriebene XML-Darstellung des Content-Repositories.
Level 2 erweitert die Funktionalitäten mit:
- Schreibendem Zugriff
- Import
- Referenzieller Integrität
- Zugriffskontrolle
Schließlich sind folgende optionale Funktionalitäten spezifiziert:
- Versionierung
- Transaktionen
- Observation
- Locking
- Query Language (SQL)
Apache Jackrabbit
Die Referenzimplementierung für diesen Java-Standard wurde von der Firma Day an die Apache Software Foundation übergeben. Hier wird sie als Open-Source-Projekt „Apache Jackrabbit“ weitergeführt [2]. Innerhalb kurzer Zeit hat sich eine sehr aktive Community entwickelt, die das Projekt vorantreibt. Das Jackrabbit-Repository ist eine vollständige Implementierung des Standards mit allen Funktionalitäten der Level 1 und 2 und optional. Ferner bietet Jackrabbit eine Reihe weiterer Features, wie etwa die Möglichkeit, einen Repository-Cluster aufzubauen oder den Zugriff per RMI.
Weiterentwicklung des Standards – JSR 283
Die Version 2 des Standards ist zurzeit als JSR 283 in Arbeit und wird einige Erweiterungen bringen. Ein Schwerpunkt sind hier Funktionalitäten für Administration und Management des Repositories. In Level 1 ist ein vereinfachter Zugriff auf Items über Workspace-Grenzen hinweg geplant. Level 2 soll Funktionen zur Workspace-Verwaltung, zur Archivierung und zur Erhaltung der Repository-Konsistenz bekommen. Bei den optionalen Funktionalitäten sollen Erweiterungen zu Access Control, Node-Type-Verwaltung und Lifecycle-Management hinzukommen. Dies gibt den momentanen Stand der Diskussion wieder. Näheres kann im „Early Draft“ nachgeschaut werden [3].
Ausblick
Welche Auswirkungen wird der neue Standard haben? Durch die Standardisierung einer Content Repository API könnte eine Entwicklung, ähnlich wie sie bei Datenbanken stattgefunden hat, eingeleitet werden. Ein erster Schritt ist schon gelungen. So wie von „Datenbanken“ die Rede ist, wenn eigentlich „relationale SQL-basierte Datenbanken“ gemeint sind, wird der Begriff „Content Repository“ schon jetzt zu einem großen Teil mit JCR gleichgesetzt [4]. Ein Content-Repository wird als Infrastruktur eingesetzt, für den Anwender ist letztlich nur die darauf aufsetzende Anwendung von Interesse. Für eine Anwendung, etwa ein CMS, ist es dann ohne großen Aufwand möglich, auf die unterschiedlichsten Content-Repositories zuzugreifen. Somit könnte ein neuer Markt für Content-Repositories entstehen.
Diese Flexibilität und Vereinheitlichung wird für alle, die Content innerhalb ihrer Anwendungen benötigen, eine große Erleichterung darstellen. Die Notwendigkeit zur Verwendung immer neuer Zugriffsmethoden und APIs und der damit verbundene erhebliche Trainingsaufwand entfallen. Auch die Abhängigkeit von einem einmal gewählten Hersteller wird verschwinden, da sowohl auf Seiten des Content-Repositories als auch auf Seiten der Anwendung eine einfache Migration ohne immensen Anpassungsaufwand stattfinden kann.