Content Repository - Gibt es den einheitlichen Zugriff auf Content?
Gastbeitrag von Dr. Martin Bartonitz, Product Manager Workflow
SAPERION AG
E-Mail: martin.bartonitz@saperion.de
Webseite: www.saperion.de Stand heute gibt es in den Firmen die unterschiedlichsten Informationsinseln, sprich pro Anwendung jeweils einen anderen Speicherort:
| | | |
| | · | File-Server für die „einfache“ Ablage typischer Office-Dateien, |
| | · | über Archive und Document Management Systemen (DMS/ECM) mit einer optimierten Verwaltung dieser Office-Dateien, |
| | · | Web Content Management Systemen (WCMS) zur internen Präsentation von Regularien und neuen Firmeninformationen sowie externen Präsentation von Produktbeschreibungen, anstehenden Events und Success Stories, |
| | · | ERP, CRM oder individuelle entwickelte Legacy Systemen zur Verwaltung und Steuerung der internen und externen Prozessen, |
| | · | die neuen Web 2.0 Anwendungen wie Wikis und Blogs, |
| | · | Directory Services mit systemspezifischen Benutzerdaten, |
| | · | Versioning Management Systeme zu Verwaltung von Programmiercode, |
| | · | Bis hin zu Mail-Servern mit weiteren individuellen und Gruppenablagen von Geschäftskorrespondenzen. |
Je größer die Firmen, desto mehr Content-Inseln. Speziell Konzerne haben einen hohen Aufwand, den Flohzirkus, der nach Zukäufen von weiteren Firmenteilen entsteht, unter Kontrolle zu bekommen. Neben der Herausforderung, diese Systeme zu organisieren, kommt noch das Problem hinzu, dass viel Aufwand betrieben werden muss, um alle relevanten Daten zu einem Geschäftsfall (Kunde oder Projekt) über nur eine Anwendung zusammen zu bekommen. Häufig müssen diese Daten in den unterschiedlichen Anwendungen zusammen gesucht werden und häufig genug scheitert dies, weil man nicht an eine Mail im Postkorb eines gerade nicht anwesenden Mitarbeiters heran kommt.
Die Grafik zeigt heutige Systemlandschaften mit jeweils anwendungsspezifischen, proprietären Repository-SchnittstellenWie viel einfacher wäre es, wenn die einzelnen Content-Anwendungen über eine einheitliche Schnittstelle auf Daten in den unterschiedlichen Datenspeicher (Content Repository) zugreifen könnten? Auch würden die Ausbildungskosten für Programmier stark gesenkt werden können, da diese auf dem Job-Markt schon zu haben wären.
Einer für Alle: Java Content Repository – JCR
Genau dies war die Intention einer Expertengruppe, die sich aus Mitarbeitern Markt-bestimmender Hersteller als auch Anwender zusammensetzt, den ersten Standard für einen solchen einheitlichen Zugriff zu definieren. 2003 gründete sich diese Gruppe innerhalb des Sun Java Community Process und verabschiedete die erste Version 2005 unter der Bezeichnung JSR 170 -: Content Repository for JavaTM Technology API. In der Expertengruppe sind Firmen wie IBM, Sun Microsystems, SAP, Oracle, BEA Systems, Fujitsu und Software AG vertreten. Inzwischen steht schon die Version 2 mit der Bezeichnung JSR 283 vor der Freigabe. Ein alternativer Name für beide Standards ist JCR, stehend für Java Content Repository, der im Folgenden weiter verwendet werden wird.Ein JCR-konformes Content Repository bietet die Vorteile sowohl von File-Systemen als auch von relationalen Datenbanken, wie Transaktions-sicherheit, Skalierbarkeit, Zugriffskontrollen, Datenhierarchisierung, effiziente Handhabung großer Dateien, Volltext-Suche, Versionierung sowie einem „Data First“-Ansatz, der von Beiden nicht unterstützt wird. Relationale Datenbanken und File-Systeme gehen von einem „Structure First“- Ansatz aus, d.h. Daten können erst gespeichert werden, wenn die Strukturen geklärt und implementiert sind.
Die Grafik zeigt die zukünftigen Systemlandschaften mit einer Standard Repository API, über die die einzelnen Anwendungen auf die Daten der jeweiligen Content Repositories zugreifen. Optimal wäre am Ende nur eines zu verwenden.Ein großer Vorteil der Schnittstelle ist, dass sie unabhängig von der darunterliegenden Speicher-archi-tektur ist. So können die Daten in einer relationalen Datenbank, in einem Document Management System, in einem File-System oder in einem XML-basierenden System liegen. Damit liegt aber auch wieder die Qual der Wahl beim Anwender, der je nach seinen Anforderungen bzgl. Performance oder Datensicherheit (siehe Regularien wie GDPdU, SOX, Basel II, etc.) das passende Repository aussuchen muss. Im Falle von rechtssicherer Aufbewahrung von Dokumenten kann es nützlich sein, ein Dokumenten Management System als Repository zu nutzen, das sich um Aspekte der Aufbewahrungsfristen und notwendigen Löschungen in Hinsicht auf Datenschutz kümmert. Sind die Daten weniger kritisch, wäre aus Kostengründen erste Wahl ein File-System-basiertes Repository.
Standards: Vorgänger und Alternativen
Die Grafik zeigt die zeitliche Entwicklung von Standards, die Zugriffe auf Content festlegen. Die Zeiten sind“ ca.“ angegeben.
Da die JCR-Schnittstelle Java-orientiert als auch aufgrund der hohen funktionalen Anforderungen auch sehr komplex ist und es damit einer Reihe von „einfachen“ Anwendungen sowie .NET-basierten schwer macht, hat sich inzwischen eine weitere Expertengruppe unter der Federführung von Microsoft und IBM gegründet, und reichte Ende 2008 den ersten Draft mit dem Namen CMIS bei der OASIS zur Standardisierung ein. Die Erfahrung zeigt, dass es noch mindestens ein bis eineinhalb Jahre bis zur Freigabe dauern wird. CMIS steht für Content Management Interoperability Services. Während der Standard JSR 170/283 ein API beschreibt, beschreibt CMIS ein Protokoll (Web-Service), so dass CMIS aus Sicht einer Architektur sich über die JCR-API setzen könnte, mit der Einschränkung, dass einige Funktionen der JCR-API nicht nach oben durchgereicht werden können. früher Versuch für eine Standardisierung war die ODMA (Open Document Management API), die sich aber nicht durchsetzen konnte, u.a. aufgrund der Windows-Lastigkeit.
Ein weiterer wichtiger Standard ist die WebDAV (Web-based Distributed Authoring and Versioning unter Federführung der IETF). WebDAV ist im Prinzip eine Erweiterung des HTTP-Protokolls, so dass auch Inhalte auf einem Web-Server verändert werden können. Für den Anwender ist u.a. die Nutzung einer WebDAV-Quelle in seinem Datei-Explorer transparent, d.h. für ihn stellt sie sich wie ein weiteres Laufwerk dar. Wie es mit den Arbeiten an dieser Schnittstelle weitergeht, ist noch unklar, da die IETF die WebDAV-Arbeitsgruppe 2007 aufgelöst hat. Da WebDAV ein Protokoll ist, gibt es inzwischen auch Implementierungen auf dem JCR API, so dass hierüber mittels WebDAV Dateien gesucht, gelesen und geschrieben werden können.
Ein weiteres, wichtiges File-Sharing-Protokoll (alle Windows Systeme) ist das CIFS – Common Internet File System, das bei der SNIA - Storage Network Industry Association - standardisiert wird und 2002 in der Version 1.0 freigegeben wurde. Die SNIA betreibt den ebenfalls Content-relevanten API-Standard, die XAM – eXtensible Access Method Version 1.0 freigegeben in 2008 -, der eine einheitliche Schnittstelle für Storage Systeme wie EMC Centera, IBM DR550 oder Netapp Snaplock definiert.
Was ist Content, warum ist Content mehr als Daten?
Der Begriff Content entspricht dem deutschen Begriff Medieninhalt und wird im Zuge der Verbreitung des Webs vorrangig für die auf den Web-Seiten verfügbaren Inhalte verwendet. Dabei kann mit Content eine komplette Homepage, ein Seite, ein Film, ein Bild, ein Dokument oder auch nur der Inhalt eines ausgefüllten Formulars gemeint sein. Der Content umfasst also sämtliche Datenformate, seien es strukturierte, wie Adressdaten, die eher in Datenbanktabellen gespeichert werden, oder Dokumente, wie Rechnungen, die in einem revisionssicheren, elektronischen Archiv aufbewahrt sind, oder Produktbeschreibungen, die in Document Management Systemen verwaltet werden. Für die primäre Verwaltung aller dieser Daten werden unterschiedliche Systeme eingesetzt, für die Präsentation im Web z.B. so genannten Content Management Systeme.
Content durchläuft meist einen Prozess von der initialen Erstellung, über die Prüfung, Freigabe mit Veröffentlichung, die Überarbeitung, Archivierung und der abschließenden, kontrollierten Löschung. Jede dieser Tätigkeiten wird meist durch eine spezielle Rolle wahrgenommen, d.h. es wird eine Zugriffsrechteverwaltung benötigt. Da der Content sich im Laufe der Zeit verändert, müssen Versionen aufbewahrt werden. Typische Beispiele für Aufbewahrungspflichten sind veröffentlichte AGBs oder zugesicherte Produkteigenschaften.
Content hat eine Stimme, d.h. sie will etwas kommunizieren. Wenn Jemand einen Blog schreibt, so will der Autor eine Idee, einen Standpunkt vermitteln oder jemand Anderen von etwas überzeugen. Content ist persönlich. Wenn ein Autor im Auftrag einer Firma schreibt, so wird zur Sicherstellung der dargestellten Firmenmeinung eine Freigabe benötigt. Ein Autor mag Rohdaten beschreiben, er interpretiert aber auch subjektiv. Wir Lesenden berücksichtigen die Autorität und die Perspektive des Autors, wenn wir über die Vertrauenswürdigkeit des Content entscheiden.
Content besitzt Eigentumsrechte. Daten haben üblicherweise kein Copyright, während dies Content hat. Personen, die Content erzeugen, wie z.B. diesen Artikel, Berichte, Filme oder Musik, werden verständlicherweise verärgert, wenn andere Personen diese kopiere oder für ihre Arbeit verwerten.
Content ist für ein menschliches Auditorium gedacht. Während Content Management Puristen danach streben, Inhalte von der Präsentation zu trennen, so bemühen sich Autoren um ein gesamt stimmiges Bild der Darstellung. Sie wollen Kontrolle über jeden Zeilenumbruch oder Hervorhebung haben, um ihre Botschaft möglichst optimal dem Auditorium zu präsentieren. Während das semantische Web aus nichts anderem besteht als aus Maschinen, die Web Content verstehen zu scheinen, so sind sie am Ende nur Agenten, die versuchen, brauchbare Informationen für das menschliche Auge (oder Ohrenfell) zu finden. Content wird mit dem Auditorium im Hinterkopf geschaffen, während Daten nur aufgenommen werden.
Content hat Kontext. Neben der Kenntnis, von wem ein Inhalt stammt, ist auch die Platzierung des Inhalts von Wichtigkeit. Wir kümmern uns intensiv darum, wie der Inhalt klassifiziert und organisiert ist, damit er einfacher gefunden werden kann. Eine Datenbanktabelle kümmert sich wenig darum, wie die enthaltenen Daten sortiert sind, es ist die Aufgabe der Anwendung zusammen mit dem Autor festzulegen, wo genau ihre Assets in den Auflistungen erscheinen.
Content braucht einerseits einen Ablageort, der Datensicherheit (Schutz vor Verlust & Zugriffsdifferenzierung) gewährleistet sowie andererseits eine je nach Anforderung gestaltete Oberfläche zur Präsentation. Um die Ablage kümmert sich das Content Repository, für die Präsentation sind die jeweiligen Anwendungen, wie Portale, Wikis, Blogs etc. zuständig.
Metadata