Es muss nicht immer eine relationale Datenbank sein, um Inhalte persistieren zu können. JCR (derzeit ist nur 1.0 bzw. JSR 170 freigegeben) bietet eine viel reichhaltigere Datenhaltung an. In diesem Artikel wird eine Übersicht über die Fähigkeiten dieser Spezifikation gegeben. Zudem geht es darum, die Spezifikation im Zusammenhang mit der Anbindung an ein DMS und die daraus folgenden Vorteile darzustellen. Zu Beginn werden Philosophie und Ziele der JCR erklärt und einige Eigenschaften der JCR vorgestellt, die traditionelle Persistenz mit Datenbanken oder File-Systemen erweitern. Darauf folgend wird auf das Thema DMS und im Speziellen auf die neuen Möglichkeiten eingegangen, die ein DMS mit Implementierung der JCR hat.

JSR 170 (283) – Ziele der Spezifikation

Mit der Veröffentlichung des JSR 170 wurde eine uniformelle API, ein Interface für den Zugriff auf einen Content-Speicherort, bereitgestellt, die für Anwender herstellerunabhängig ist. Das heißt, das Austauschen von Verkäuferlösungen besteht nur im Austauschen von Bibliotheken, jedoch nicht für aufgerufene Repository-Methoden. Derzeit wird an Version 2.0 der Spezifikation (JSR 283) gearbeitet, die viele Veränderungen, wie die Verwaltung von Metainformationen, neue Benutzerrechte, Workspace- und Nodetype-Funktionalität, mit sich bringen soll und somit als Ablöser der JSR 170 gilt.

Abb. 1: Aufbau der Java Content Repository

JCR-Philosophie

Die JCR-API definiert eine einfache hierarchische Struktur: Das Repository besteht aus einem bis mehreren Workspaces. Jedes Workspace hat eine Baumstruktur, die aus Nodes und Items besteht, ein Workspace hat also genau einen Root Node, an die andere Items angehängt werden können. Der Node-Baum kann eine beliebige Tiefe bzw. Breite haben. Ein Item kann sowohl Node als auch Property sein. Der Unterschied zwischen Nodes und Properties besteht darin, dass an ein Node Properties sowie weitere Nodes angefügt werden können, an eine Property jedoch nicht. Property und Node stehen immer in einer OneToOne-Beziehung. Ausschließlich Properties besitzen Inhalte: von kleinen Strings oder Numbers bis großen Dateien (Bilder, PDF-Dokumente etc.). Abhängig vom Zugriffslevel (Level I: Lesender Zugriff und Level II: Schreibender Zugriff) stellt das Repository vier Grundoperationen zur Verfügung: Lesen, Schreiben, Suchen und Löschen. Mit Listing 1 lässt sich diese grundlegende Funktionalität veranschaulichen.

1. Listing 1
2. Repository repository = (Repository)InitialContext.lookup("repository");
3. // Get a Credentials object
4. Credentials credentials = new SimpleCredentials("name", "***".toCharArray());
5. // Get a Session
6. Session session = repository.login(credentials, "my_workspace");
7. // Get the root node
8. Node root = session.getRootNode();
9. // Traverse to the node you want
10. Node nodeA = root.getNode("NodeA");
11. // Retrieve a property of NodeA
12. Property property = nodeA.getProperty("property1");
13. // Get the value of the property
14. Value value = property.getValue();
15. // Convert the value to the desired type
16. String stringValue = value.getString();
17. // Add a child node
18. Node nodeB = nodeA.addNode("nodeB");
19. // Add a property
20. nodeB.setProperty("property1", "Property String");
21. // Persist the changes
22. session.save();
23. // Remove the node NodeA (and its subtree: NodeB)
24. nodeA.remove();
25. // Persist the changes
26. session.save();

Als fortgeschrittene JSR-170-Features zur Verwaltung von Inhalten zählen Observation Management, Nodetype Management, Versionierung und Transaktionsverwaltung.

Abb. 2: Repository in einer Applikation