CMIS mit Apache Chemistry – ein Praxisbeispiel
Die Content Management Interoperability Services können einen breiten Bereich von Einsatzszenarien im Bereich des Enterprise Content Management (ECM) abdecken. Eine beispielhafte Implementierung einer Client-Applikation oder eines CMIS-Servers mit Apache Chemistry.
- Jens Hübel
Die Content Management Interoperability Services können durch ihre Plattformneutralität und Sprachenunabhängigkeit einen breiten Bereich von Einsatzszenarien im Bereich des Enterprise Content Management (ECM) abdecken. Der Artikel zeigt beispielhaft, wie sich mit Apache Chemistry eine CMIS-Bibliothek nutzen lässt, um eine Client-Applikation oder einen CMIS-Server zu implementieren.
Etwas wie SQL im Bereich relationaler Datenbanken fehlte bisher für Content-zentrierte Daten. CMIS (Content Management Interoperability Services) hat den Anspruch, in diese Lücke zu springen und eine gemeinsame Sprache zu definieren, die unterschiedliche Systeme implementieren können, die mit Content umgehen.
Für einfache Funktionen reicht ein Browser als Client-Applikation für CMIS (Content Management Interoperability Services) aus. Ist kein CMIS-fähiges Repository vorhanden, kann der Entwickler eine der zwei Beispielimplementierungen von Apache Chemistry, einem neuen Top-Level-Projekt der Open-Source-Organisation, verwenden (fileshare oder in-memory), die sich mit wenigen Handgriffen einrichten lassen. Hierzu benötigt er Java, einen Servlet-Container wie Jetty oder Tomcat und die .war-Dateien von OpenCMIS.
Sollte man noch kein JDK installiert haben, ist als Erstes Oracles Java SDK herunterzuladen und zu installieren (die Java-Runtime genügt nicht für Tomcat). Als Nächstes besorgt man sich den Tomcat 6 und die In-Memory-Webapplikation von OpenCMIS. Nach dem Entpacken des Tomcat-Archivs öffnet der Entwickler unter Windows einen Command-Prompt und wechselt ins bin-Verzeichnis des Tomcat. Dort befindet sich ein Startskript (startup.bat für Windows, startup.sh für Unix). Nach dessen Aufruf sollte man einen laufenden Webserver haben. Tippt man nun in einem Webbrowser die Adresse http://localhost:8080/ ein und sieht die Tomcat-Startseite, war das Vorgehen erfolgreich. Kommt es zu Fehlern, liegt das häufig daran, dass die Umgebungsvariable JAVA_HOME nicht oder nicht richtig gesetzt ist. Sie muss auf das Verzeichnis zeigen, in dem das JDK installiert ist.
Als Nächstes öffnet der Entwickler das Zip-Archiv von OpenCMIS und extrahiert die Datei chemistry-opencmis-server-inmemory-0.2.0-incubating.war. Nicht notwendig, aber sinnvoll, um viel Tipparbeit zu sparen, ist es, diese Datei in einen kurzen Namen umzubenennen, zum Beispiel in opencmis.war. Dann kopiert man die Datei ins webapp-Verzeichnis der Tomcat-Installation. Der Servlet-Container sollte die neue Webapplikation automatisch erkennen und nach einigen Sekunden ein Verzeichnis opencmis innerhalb von webapps erstellen. In der mitgelieferten Standardkonfiguration legt der In-Memory-Server ein Repository mit der ID "A1" an sowie einige Typen, Ordner und Dokumente.
Läuft der Server, kann der Entwickler sich mit einem Webbrowser verbinden und sich die Repository-Information anzeigen lassen. Dazu tippt er http://localhost:8080/opencmis/atom in die Adressenzeile ein. Der Browser erhält eine Antwort, deren Dateityp er jedoch nicht kennt und die er in eine Datei speichern sollte. Je nach Browser hat diese unterschiedliche Namen, und man benennt sie am besten um, etwa in repoInfo.xml. Zieht der Programmierer die Datei per Drag & Drop auf den Browser, kann er sich die Antwort des Servers in Form einer AtomPub-Antwort ansehen. Zu erkennen ist, dass der Beispielserver ein einziges Repository enthält, das den Namen "A1" trägt. Nach dem Expandieren des RepositoryInfo-Tags erhält man genauere Informationen darüber.
Der Vorbereitungen nicht genug
Danach sei der Inhalt des Root-Folders aufgelistet. Diesen können die meisten Browser sogar direkt anzeigen, allerdings sieht der Entwickler nur einen Teil der gelieferten Information. Den Link dazu findet er unter dem Tag "app:collection" mit dem collectionType "root" (der Root-Folder des Repository hat die ID 100):
http://localhost:8080/opencmis/atom/A1/children?id=100
Darauf antwortet der Server mit einem Feed im AtomPub-Format, den der Browser anzeigen kann.
Der Root-Folder enthält drei Dokumente (My_Document-0-0, My_Document-0-1 und My_Document-0-2) sowie zwei Ordner (My_Folder_0_0 und My_Folder-0-1). Viele Informationen sind allerdings in den CMIS-spezifischen Erweiterungen des AtomPub-Protokolls enthalten, die der Browser aber nicht kennt und deshalb ignoriert. Sie lassen sich anzeigen, wenn man den Quelltext des Feeds anschaut (Ansicht | Seitenquelltext anzeigen).
Hier erkennt man zum Beispiel einen Link auf den Inhalt des Dokuments:
<atom:content src="http://localhost:8080/opencmis/atom/A1/content/
data.txt?id=133" type="text/plain"/>
oder die Properties des Dokuments in <cmis:properties>.
Der In-Memory-Server gestattet nicht nur lesenden Zugriff, sondern es lassen sich auch Dokumente und Ordner erstellen oder modifizieren. Hierzu reicht der Webbrowser allerdings nicht aus, da dazu HTTP-POST- und -PUT-Requests zu senden sind. Möchte man das Protokoll im Detail verstehen, bieten sich dazu Tools wie wget oder curl an. Zudem unterstützt der In-Memory-Server das SOAP-Binding. Die WSDL (Web Services Description Language) des Repository-Services kann man mit folgender URL im Browser anzeigen.
http://localhost:8080/opencmis/services/RepositoryService?wsdl
Lässt der Entwickler den Parameter ?wsdl weg, bekommt er eine Übersichtsseite mit allen Services und deren URLs.
Der Programmierer wird jedoch schnell feststellen, dass eine Implementierung auf Protokollebene ziemlich aufwendig ist. Eine Bibliothek, die eine komfortable API in der jeweiligen Zielsprache anbietet, kann einem dabei viel Arbeit ersparen. Das war die Motivation hinter dem Apache-Chemistry-Projekt, das eine solche API für Java (opencmis) und einige weitere Sprachen anbietet. Wird direkt auf Protokollebene entwickelt, kommt man mit dem SOAP-Binding schneller zum Ziel als mit AtomPub, sofern die Entwicklungsplattform den WSDL-Import unterstützt.
Für Endanwender ist es jedoch wesentlich komfortabler, einen CMIS-spezifischen Client zu verwenden, der das Protokoll vollständig versteht. Einen solchen bietet das Apache-Projekt mit der CMIS-Workbench.
CMIS à la Apache
Das Apache-Projekt kann die Arbeit einer CMIS-Integration erheblich erleichtern, sowohl auf Client- als auch auf Serverseite. Chemistry besteht aus mehreren Teilprojekten. Client-Bibliotheken gibt es für Java, PHP, Python und .NET, ein Server- und ein Test-Framework nur für Java. Das Teilprojekt, das sich mit der Java-Implementierung befasst, trägt ebenfalls den Namen opencmis. Es ist das funktional umfassendste Teilprojekt und liegt in einem zweiten Incubator-Release (0.2.0) vor. Das erste TLP-Release 0.3.0 (Top-level Project) wird in Kürze erwartet. Python hat sein erstes Release (0.4.1) bereits erreicht. Die anderen Teilprojekte sind noch in der Entwicklungsphase.
Chemistry entstand ursprünglich als Ableger aus dem Jackrabbit-Projekt, vornehmlich als Initiative von Nuxeo und unterstützt von Day. Schon bald kamen unabhängig von Jackrabbit Entwickler von Alfresco, Open Text und SAP mit dem Ziel zusammen, gemeinsam eine Client-Bibliothek für Java zu entwickeln. Schnell wurde klar, dass es sinnvoll ist, beide Projekte zu vereinigen. Jackrabbit läuft aber unabhängig von Chemistry als eigenständiges Apache-Projekt weiter. Inzwischen ist Chemistry weiter gewachsen, und es unterstützt zusätzlich PHP, Python und .NET. Seit Ende Februar hat es den Incubator-Status verlassen und ist nun ein Top-Level-Projekt.
