Beyond RDBMS - Erweiterte Persistenzlösung

In einer Applikation wird das Content Repository als eine Schicht zwischen dem Business Logic Layer und dem Persistence Layer positioniert. Das Repository-Schema (oder Informationsmodel) spezifiziert, welche Strukturen von Inhalten und deren Metadaten abgespeichert werden. Als eine Analogie dient hier das Datenbankschema. Die Repository Engine stellt Zugriffsmethoden und Funktionen zur Content-Verwaltung zur Verfügung. Diese beiden Komponenten eines Repository stellen mehrere Features bereit, die eine Datenbank wesentlich erweitern. Die Entscheidung zugunsten JCR fällt, wenn man mit komplexen oder hierarchischen Daten arbeitet, die klassifiziert oder referenziert werden. Laut Philip A. Bernstein, Forschungsleiter von Database Group of Microsoft Research, bringen Repositories mehrere Vorteile gegenüber traditionellen Datenbanken:

• Objektmanagement: Jedes Repository verwaltet eine Menge von vordefinierten Objekten, es handelt sich z.B. um Session-, Node- und Property-Objekte, die ein entsprechendes Element einer Repository-Struktur darstellen. Die JCR-API stellt verschiedene Methoden zur Manipulation des Objektzustands zur Verfügung. Auf diese Weise können Properties oder weitere Kinder-Nodes zu einer bestimmten Node hinzugefügt bzw. entfernt werden. Alle Änderungen werden erst durch den Aufruf der save()-Methode auf der Parent Node persistent, sonst bleibt der Zustand der Node transient. Bei Properties unterscheidet man zwischen Single-valued- und Multi-valued-Properties. Die Multi-valued-Properties werden durch Collections repräsentiert.

1. nodeA.remove();
2. root.save();

• Dynamische Erweiterbarkeit: In JCR-API-Begriffen handelt es sich hier um Nodetype-Management. Jedes Objekt im Repository hat einen Typ. Die JCR-Node ist durch einen und nur einen Primary Type definiert. Hier wird der Name der Node, dazugehörige Properties und weitere Typen definiert, denen Child Nodes zugewiesen werden können. Ein Pendant zum primary type wäre das Datenbankschema. Darüber hinaus kann eine Node ein oder mehrere Mixin-Typen haben. Mixins stellen erweiterte Attribute einer Node dar. Somit wird der Typ einer Node leicht erweiterbar.

1. Node node = rootNode.addNode(NodeC, nt :unstructured);
2. node.addMixin(mix:lockable);

• Management von Referenzen: In der Java Content Repository API gibt es eine Möglichkeit, Referenzen zwischen Repository-Knoten zu setzen. Um eine andere Node zu referenzieren, muss der referenzierenden Node der Mixin-Typ mix:referenceable zugewiesen werden (Listing 2). Ein anderer Aspekt des Referenzmanagements ist die referenzielle Integrität: Das Löschen einer Node führt zum Löschen der dazugehörigen Child Nodes.
  

1. Listing 2
2. Node node1 = rootNode.addNode(nodeName1, nt :unstructured);
3. Node node2 = rootNode.addNode(nodeName2, nt :unstructured);
4. node2.setProperty(reference, node1);
5. rootNode.save();

• Benachrichtigung: Objekte in der Repository können auf Änderungen von anderen Objekten lauschen. Diese Funktionalität ist in der JCR-API als Observation Manager Interface definiert. Dies stellt einen ereignisbasierten Mechanismus dar, der die von dem Repository gesendeten Events bearbeitet. Dadurch wird vermieden, dass parallel geöffnete Sessionobjekte an einer bereits gelöschten Node arbeiten.
• Versionsmanagement: Mit diesem Feature lässt sich die Abstammungslinie eines Objekts leicht ermitteln. Versionierung ist weder in den relationalen noch in objektorientierten Datenbanken als Standard definiert. Wie in der JCR üblich, wird diese Eigenschaft durch einen Mixin-Typ zugewiesen. Durch mix:versionable wird die Versionierung an einem bestimmten Knoten möglich.

1. Listing 3
2. Node node1 = rootNode.getNodeByUUID(« 123456789 »);
3. node1.addMixin("mix:versionable");
4. session.save() ;
5. node1.checkout();
6. node1.setProperty("property1", new StringValue("text"));
7. session.save();
8. node1.checkin();

• Konfigurationsmanagement: Workspaces im Java Content Repository beinhalten mehrere Objekte. Die Definition eines Workspace enthält die Information, welche Nodes, Typen etc. zugelassen sind.

Die aufgezählten Aspekte zeigen, dass Repositories eine weitaus höhere semantische Ebene als relationale oder objektorientierte Datenbanken unterstützen.

Perspektiven für DMS

So viel zu der Spezifikation, die eine schlanke API zur Content-Verwaltung anbietet. Oft wird die JCR im Zusammenhang mit Content-Management-Systemen angesprochen. Allerdings ist das gesamte Spektrum der Anwendungsgebiete der JCR viel breiter. Weil sich die JCR auf Content oder Daten fokussiert, wird nun angesprochen, welche Möglichkeiten sich für DMS mit JCR eröffnen. In den vergangenen Jahren hat sich auf diesem Gebiet ein wahrer Boom entwickelt. Was anfangs noch belächelt wurde, trifft man heute selbstverständlich in jedem Unternehmen an. Es gibt mittlerweile unzählige Firmen, die sich auf diesem Markt etablieren wollen und klassische DMS-Systeme für den Mittelstand oder den Großkunden anbieten.