Ist das Java Content Repository die ideale Technologie für eine E-Akte?

Eine E-Akte orientiert sich oft an der papierbasierten Welt, was die Abbildung der logischen Zusammenhänge und Beziehungen der Fachlichkeit betrifft. Dazu wird typischerweise ein Datenmodell entwickelt, welches eine Akte als oberstes Objekt definiert und Bei- oder Teilakten sowie Vorgänge enthält. Darunter sind Dokumente angesiedelt, die wiederum Anhangsdokumente beinhalten oder auf das selbe physische Dokument verweisen. Die Modellierungsform einer relationalen Datenbank kann diese meist verschachtelten und hierarchischen Beziehungen nur umständlich übersetzen. Spätestens wenn die Metadaten und Beziehungsinformationen der fachlichen Objekte in der Datenbank mit Dokumenten im Dateisystem ergänzt werden und diese auch noch versioniert werden müssen, entsteht ein komplexes, proprietäres Datenmodell, das aufwändig zu pflegen und schwer nachzuvollziehen ist.

Eine andere Herangehensweise bietet das Java Content Repository, das speziell dafür entwickelt wurde, hierarchische Metadaten und ihre Binärinhalte zu speichern, suchen und abzurufen. Wir setzen bei dem Papierflieger auf das Java Content Repository. In diesem Artikel nennen wir einige gute Gründe dafür.

![Java Content Repository: Das Beste aus beiden Welten für die E-Akte](http://res.cloudinary.com/ditemis/image/upload/v1436776687/ditemisblog/jcr_e-akte.png)

Was ist Java Content Repository?

Im Java Community Process (JCP) wurden die Java Specification Requests (JSR) 170 (JCR Version 1.0) und JSR 283 (JCR Version 2.0) verabschiedet. Damit ist die Grundlage für JCR eine gemeinschaftlich beschlossene Spezifikation, für die es verschiedene Implementierungen gibt. In den “Standards und Architekturen für eGovernment-Anwendungen (SAGA) vom November 2011 wird JCR wie folgt beschrieben:

JCR spezifiziert ein abstraktes Modell und eine Java API für die Datenspeicherung und zugehörige Services von inhaltsorientierten Anwendungen. [...]
JCR KANN nicht nur für traditionelle Content Management Systeme (CMS), sondern für jede Anwendung, die mit unstrukturierten digitalen Objekten und strukturierten Informationen umgehen muss, eingesetzt werden.

Es existieren verschiedene kommerzielle und Open-Source Implementierungen der JCR Spezifikation:

Die Daten in einem JCR bestehen aus einem Baum mit einzelnen Knoten, denen Eigenschaften zugeordnet sind. Diese Eigenschaften halten Werte als Zahlen, Zeichenketten oder Binärdaten mit beliebiger Länge. Knoten haben Typinformationen, die ihre Verhaltensweisen bestimmen und festlegen, welche Arten von Eigenschaften sie besitzen und welche Typen und Anzahl von Kindern sie haben. Knoten können auf andere Knoten mit einer speziellen Referenzeigenschaft verweisen. Damit unterstützt JCR sowohl referenzielle Integrität als auch die Vererbung nach der Objektorientierung. Jeder Knoten hat einen universellen eindeutigen Identifikator (UUID), der es ermöglicht, dass zusätzliche Knotentypen auf die bestehenden referenzierbaren Knotentypen verweisen. Für die Abfrage eines JCR können verschiedene Abfragesprachen für Hierarchien genutzt werden, die sich an SQL anlehnen oder den XPath eines Knoten nutzen.

Wer einen tieferen technischen Einblick für die Gründe zur Wahl eines JCR gegenüber eines RDBMS möchte, dem empfehlen wir den Artikel “JCR or RDBMS: why, when, how?”, aus dem wir auch die Darstellung zu den Features von Datenbanken, Dateisystemen und Content Repositories entnommen haben.

Was hat das mit E-Verwaltungsarbeit zu tun?

Die elektronische Verwaltungsarbeit ist durch strukturierte, geordnete Vorgänge geprägt. Es gibt eine klare Hierarchie und Beziehungen zwischen Aktenplan, Akten, Vorgängen und Dokumenten. Im Fokus stehen letztendlich die Dokumente und ihre Inhalte. Das JCR ist daher die ideale Speichertechnologie, um die fachlichen Strukturen im Datenmodell abzubilden und die Dokumentinhalte an den Blättern des Aktenbaums anzuhängen.

Beispielhaft zeigt die folgende Liste den hierarchischen Charakter der E-Akte und gleichzeitig auch die Struktur, wie ein JCR diese fachlichen Inhalte in Pfaden verwalten würde:

  • 1 Aktenplan
    • 1.1 Aktenplan
      • 1.1.A Akte 1234
        • Vorgang 998
          • Dokument 567
            • Dokumentanhang 1
      • 1.2.B Akte 4711
        • Dokument 0815
          • Dokumentanhang 1
          • Dokumentanhang 2
    • 1.2 Aktenplan
  • 2 Aktenplan
  • 3 Aktenplan

Welche Features macht das JCR für die E-Akte vorteilhaft?

Der Papierflieger nutzt die JCR Implementierung Modeshape von JBOSS. Modeshape unterstützt alle zwingend benötigten und viele optionale Fähigkeiten der JCR Version 2.0. Dadurch können eine Vielzahl an Bedürfnissen einer E-Akte bereits mit der Datenhaltung erfüllt werden:

  • Versionierung: Knotentypen können als versionierbar deklariert werden. Dadurch werden Änderungen an Eigenschaften oder Dokumentinhalten vollkommen transparent nachvollziehbar. Das Prinzip der Aktenmäßigkeit wird gewährleistet, ohne das der Entwickler besondere Abhängigkeiten beachten muss.
  • Hierarchische Strukturen, Vererbung und Referenzen: Die (Unter-)Strukturierungen und Beziehungen zwischen Akten, Vorgängen und Dokumenten können in Typinformationen deklariert werden, sodass sich Eigenschaften vererben, Verweise zwischen Objekten angelegt und Vater-Kind-Beziehungen definiert werden können.
  • Volltextsuche: Beim Hinzufügen von Binärinhalten (Dokumente) wird versucht das Format des Dokuments zu identifizieren. Bei unterstützten Formaten kann die Inhaltsextraktion direkt im Anschluss erfolgen, sodass z.B. mit einer Optical Character Recognition (OCR) der Inhalt von Scandokumenten in den Index aufgenommen wird, sodass die Inhalte mit einer Volltextsuche durchsucht werden können.
  • Speichern von Binärinhalten: Die Inhalte von Dokumenten werden als Knoteneigenschaft angesehen, sodass die Speicherung transparent für den Entwickler erfolgt. Es muss keine aufwändige, manuelle Synchronisation zwischen Datenbank und Dateisystem implementiert werden.
  • Zugriffsberechtigung: Jeder Knoten besitzt eine Access Control List (ACL), die die Lese- und Schreibrechte für Gruppen oder einzelne Benutzer festlegt. Die Berechtigungen vererben sich von Vater- auf Kindknoten, wie man es von Ordnerstrukturen gewohnt ist. Wenn einem Nutzer die Leseberechtigung auf eine Akte entzogen wird, wirkt sich das automatisch auf alle enthaltenen Vorgänge und Dokumente aus.
  • Locking: Beim schreibenden Zugriff eines Nutzers auf einen Knoten wird dieser für Zugriffe durch andere Nutzer automatisch oder manuell gesperrt. Die Verriegelung wirkt sich ebenfalls auf die Kindelemente aus, sodass kein inkonsistenter Zustand in der Hierarchiestruktur von Akten, Vorgängen und Dokumenten entstehen kann.
  • Interoperabilität: Durch RESTful WebServices und die Konformität zu den Content Management Interoperability Services (CMIS) können einzelne Knoten abgerufen und verändert werden. Dadurch können eine Vielzahl von Clients bedient werden und die Datenmigration wird durch das beschriebene Datenmodell und den offenen Zugriff darauf vereinfacht.

Lohnt sich der Einsatz eines JCR für eine E-Akte?

Mit dem Papierflieger möchten wir zeigen, dass ein JCR die ideale Technologie für eine E-Akte Lösung ist. Es ist für jeden Anwendungsfall abzuwägen, ob sich das vertraute Konzept der RDBMS durch ein JCR ablösen lässt. Durch die stark inhaltsorientierte, strukturierte und hierarchische Domäne der Verwaltungsarbeit sehen wir eine Datenhaltung, die den Dokumentinhalt in den Vordergrund stellt, deutlich im Vorteil. Auch die integrierten Fähigkeiten zur Volltextsuche, Skalierbarkeit und dem erweiterbaren Typsystem, helfen dabei, das Datenmodell einfach und flexibel zu halten.