JCR ist ein Standard, um (hauptsächlich in Java, aber es gibt auch APIs in anderen Sprachen und Abwandlungen wie PHPCR
) Inhalte beliebigen Formats in einem einheitlichen Datenspeicher (Repository) abzulegen. Die abgelegten Daten (oder auch Dateien) können dann mit Metadaten (Eigenschaften, Properties) und ggf. Unterdaten (Unterverzeichnissen, Child-Nodes) versehen werden. Die JCR-API regelt den Zugriff auf diese Daten direkt oder durch Abfragen ähnlich wie in einer relationalen Datenbank oder auch wie in einer XML-Datenbank per XPath. Sie regelt auch die Beschreibung von Node-Typen, Versionierung, Zugriffsrechte, etc. Ein besonderer Bonus ist, das man zumeist auch per WebDAV auf die Daten zugreifen kann (zumindest auf entsprechende Node-Typen). Siehe auch den Wikipedia-Artikel sowie die Jackrabbit Homepage und das dortige Wiki.
JCR ist definiert worden von der Firma Day (heute Teil von Adobe) und dann im Rahmen des Java Community Prozess in der Version 1 als JCP-170 und in Version 2 als JCP-283 standardisiert worden. Die Referenzimplementierung ist Apache Jakrabbit. Es gibt aber auch einige andere interessante Implementierungen wie z.B. JBoss ModeShape oder auch viele offene (z.B. Alfresco) und proprietäre Dokumentenmanagement-Systeme, die eine JCR-Schnittstelle anbieten, um auf Ihre Daten zuzugreifen.
Versuch einer Abgrenzung #
In seiner Gesamtheit erscheint mir eine Implementierung des JCR-Standards von den Zugriffsmöglichkeiten her leistungsfähiger als spezialisiertere Content- oder Dokumentenmanagement-Systeme oder NoSQLDatenbanken. Letzlich handelt es sich um eine wohldefinierte Art einer NoSQL-Datenbank, die recht gut mit interner Struktur der Daten umgehen kann (ein Fokus, den auch sogenannte XML-Datenbanken haben, die auch oft ähnliche Eigenschaften haben). Der WebDAV-Zugriff zeigt, das die Stärke bei der Verwaltung von Daten liegt, die man gemeinhin als "Dateien" bezeichnen würde. Die zusätzlichen Metadaten erlauben dann weitere Strukturierung und Information. Wenn man Kommentaren in Foren folgt, hat Jackrabbit bestimmte Schwächen, wenn das Repository richtig gross wird. Das liegt zum Teil sicherlich daran, das gewisse Versprechen hinsichtlich der Durchsuchbarkeit auch zwangsläufig zu gewissen Kompromissen bei der internen Struktur der Daten führen. Andererseits habe ich noch keine grundsätzliche Kritik an JCP, sondern eher an der Jackrabbit-Implementierung gelesen. Wer also mehr Daten verwalten will, kann dies auch mit JBoss ModeShape (Unterschiede) oder Alfresco probieren oder sich ggf. sogar was proprietäres kaufen.
Interessante Links zum Thema gibt es im Jackrabbit Wiki: JcrLinks. Es gibt ein paar informative ältere Artikel über JCR (bei onjava.com und IBM). Interessant ist bestimmt auch Apache Sling. Das ist ein Webframework, das komplett auch dem JCR aufbaut. Es erlaubt, Webapplikationen direkt aus dem Content zu erstellen.
Einstieg #
Den Jackrabbit Standalone Server hatte ich ohne runterladen in unter 5 Minuten laufen. Dann kann man bereits per Browser und per WebDAV auf das Repository zugreifen. Auf der Jackrabbit-Webseite gibt es die Seite First Hops, die einen einfachen Einstieg in die API bietet.
Browser für JCR #
Schön für erste Spielereien und auch für die Wartung eines Repositories ist eine BEnutzeroberfläche, die es einem erlaubt, sich im Repository umzusehen - und das unabhängig von einer bestimmten Applikation, die vielleicht bestimmte Nodetypen benutzt. Hier gibt es einige Browserprogramme:
- JCR Controller/Connector - Swing
- SPTJCRManager - Java EE (Webapplikation)
- JCR Web-Explorer - Webapplikation
- Jackrabbitexplorer - Webapplikation (GWT)
- JCR Browser - Auf Basis der Eclipse-Plattform
- JCR Standalone Client - Swing, (Version 0.1 und Sourceforge-Status "planning")
- http://www.jcrbrowser.org/sling/website/ - Read-only Webapp im Sling-Framework (kann nicht viel, könnte aber ein gutes Sling-Beispiel sein)
- In JBoss ModeShape scheint es Pläne zu geben, demnächst einen Repository Browser zu integrieren
- ältere Übersicht bei Day
- es gibt aber auch andere Möglichkeiten: