Content Repository for Java Technology API

Content Repository for Java Technology API (JCR) ist eine Spezifikation für eine Java-Plattform-API, um auf Content in einer einheitlichen Methode zuzugreifen.^[1][2] Content Repositories werden von den unterschiedlichsten Informationssystemen genutzt, die beliebige Dokumente zusammen mit ihren Metadaten verwalten, z. B. Web Content Management Systeme (WCM), Enterprise Content Management Systeme (ECMS), Source Control Management Systeme, oder auch Directory Services und E-Mail-Systeme. Ziel der API ist es, die vielen Content-Inseln mit den jeweils eigenen, proprietären Schnittstellen über eine zukünftig gemeinsame zu vereinen. So kann eine Anwendung, die die JCR-API nutzt, den in ihr verwendeten Content in beliebig andere, JCR-konforme Content Repositories speichern. So werden Anwendungen als auch die Anwender selbst unabhängiger von einem Content-Repository-Hersteller. Programmierer, die einmal die API gelernt haben, können so direkt Anwendungen für beliebige Content Repositories entwickeln. Die Spezifikation wurde und wird seit 2002 unter dem Java Community Process entwickelt als freigegebene JSR-170 (JCR Version 1.0)^[3][4] und als kurz vor der Freigabe stehende Nachfolgeversion JSR-283 (JCR Version 2.0).^[5]

Überblick

Ein JCR-basiertes Content Repository ist eine Art objektorientierte Datenbank, die die Vorteile einer relationalen Datenbank mit Datenstrukturen, Suchen, Transaktionen und referentielle Integrität, sowie einem Dateisystem mit Hierarchien, Zugriffskontrolle, Streaming und Locking vereint. Des Weiteren werden weitere nützliche Funktionen wie das Speichern von unstrukturierten Daten (Dokumente), Volltextsuche, Mehrfachfelder, Sortierreihenfolgen, Versionierung und Beobachtung von Änderungen (Event Observation) unterstützt. Ein wichtiger Aspekt zur Unterstützung der genannten Unabhängigkeit ist die Migration der Inhalte eines Content Repository mittels Import und Export der Daten in einem standardisierten XML-Format.

Datenmodell

Das Datenmodell ist sehr einfach aufgebaut und gleicht einem Baum. 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 keine oder mehrere Kinder haben, sowie keine oder mehrere Properties besitzen, in denen der eigentliche Content gespeichert wird. 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 ihr beim Anlegen eine eindeutige Identifikationsnummer zugewiesen werden soll. 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 es von einem File-System bekannt ist, zum machen. Da Nodes wiederum mit anderen Nodes mittels einer Referenz verlinkt werden können, kann eine Struktur, wie z. B. eine Kundenakte, viel später nachgezogen werden. Die Suche erfolgt dann ähnlich, wie dies von den Web-Suchmaschinen bekannt ist, über eine Volltextsuche. Im JCR-Modell kann auch über die Inhalte der Vorversionen von Inhalten gesucht werden. Sind 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.

JCR-Konformität

Die JCR-Spezifikation unterscheidet unterschiedlich zu unterstützende Level. Die Funktionen zum Level 1 müssen unterstützt werden, während Level 2 und einige weitere Funktionen optional sind. Zum Level 1 gehört die Suche (query) und das Lesen (read), sowie der Export. Typische Anwendungen sind demnach rein präsentierende Systeme wie Web Content Management oder Reporting Tools. Zu den Level 2 Funktionen gehört das Schreiben (write), der Import, die Volltextsuche, die Zugriffskontrolle sowie die referentielle Integrität. Level 2 Funktionen sind typisch für Entry Level Content, Document und Workflow Management Systeme. Für Enterprise Content Management Systeme oder Source Control Management Systeme werden auch die optionalen Funktionen wie die Versionierung, Sperrung (Locking), Beobachtung und Transaktionen benötigt. Anwendungen, die JCR-kompatibel sind, müssen sich bzgl. der genannten Level zertifizieren lassen. Dazu gibt es ein so genanntes Technology Compatibility Kit (TCK) mit über 1000 zu bestehenden Test-Routinen.

Queries

Ein JCR-basiertes Content Repository benutzt für die Suche den Standard XPath. Die Version 2.0 wird optional auch eine Form von SQL-Queries nutzen. Die Apache Jackrabbit Referenzimplementierung von JCR unterstützt durch die Integration von der Apache Lucene Search Engine die Volltextsuche über auch unstrukturierte Daten wie Dokumenten im CI-Format.

Verfügbare Implementierungen

Beide JSRs werden von David Nuescheler von Day Software geführt. Day bietet eine kommerzielle JCR-Implementierung namens Content Repository Extreme (CRX) an und beteiligt sich zudem an dem Open Source Apache Jackrabbit JCR,^[6][7] das als Referenzsystem für ein JCR-basiertes Content Repository mit der Version 1.0 im April 2006 verfügbar wurde. Magnolia ist ein Enterprise Content Management System, das die JCR API nutzt, um seine Inhalte per default in Jackrabbit zu speichern, aber auch jedes andere JSR-170 vollzertifizierte Repository nutzen kann. Das eXo JCR von ObjectWeb ist ein Open Source Repository, für das gegen Zahlung Support und Dokumentation zur Verfügung steht. Viele andere kommerzielle Hersteller arbeiten an der JCR-Konformität ihrer Produkte wie IBM, SAP, Oracle, OpenText, EMC DOCUMENTUM. Alfresco und Jeceira bieten ebenfalls ein Open Source Content Management Systems an als eigene Repositories. GX hat die neue Community Version ihrer Enterprise Web Content Management Plattform freigegeben, das nativ auf Apache Jackrabbit aufsetzt. SAPERION unterstützt mit der im März 2009 freigegebenen Version 6 die Schnittstelle unter dem Namen SAPERION Content Repository (SCR). Auf der Client-Seite wird das SCR durch das Produkt SAPERIONvelocity ergänzt, einem Framework zur Konfiguration von Anwendungen im Bereich der elektronischen Akte.^[8][9][10]

Einzelnachweise

1. ↑ JCR: A Practitioner’s Perspective, by Alexandru Popescu and Joseph Ottinger´
2. ↑ Java API for XML Registries – Another Java API for Registries and Repositories
3. ↑ JSR-170
4. ↑ Reference implementation and the technology compatibility kit
5. ↑ JSR-283
6. ↑ Website von Apache Jackrabbit
7. ↑ JCR links to articles and applications based on JCR.
8. ↑ SAPERION Content Repository
9. ↑ SAPERIONvelocity
10. ↑ Artikel "Content Repository – einheitlicher Zugriff auf elektronische Daten in Datenbanken", veröffentlicht in WissenHeute Jg. 62 10/2009