CMIS: Hype oder nachhaltiger Industriestandard?
Aug 7, 2009 | by admin | 0 Comments

Der Content Management Interoperability Services-Standard (CMIS) wurde letzten Herbst durch EMC Documentum, IBM und Microsoft in einer Version 0.5 als Entwurf dem Standardisierungsgremium OASIS (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cmis) übergeben. Daraufhin beteiligten sich auch andere Branchen-Schwergewichte wie Open Text, Alfresco, SAP und sogar die Apache Software Foundation an den Standardisierungsbemühungen. Heute sind praktisch alle bedeutenden ECM-Marktkräfte dort vertreten.

 

Weshalb nun plötzlich das breite Interesse für einen ECM-Standard? Zuvor scheiterten ja schon diverse Initiativen, zuletzt der Java Content Repository Standard (JCR http://jcp.org/en/jsr/detail?id=170), der zwar durch etliche Web Content Management- und Portalanbieter implementiert wurde, mit Ausnahme von Alfresco aber nicht von den Branchenschwergewichten aus dem DMS-Bereich.

Entgegen seines Namens behandelt CMIS nicht Content als Ganzes, sondern er bietet lediglich ein Minimal-API für das Dokumenten-Management an, regelt somit den Zugriff auf Ordner, Dokumente und deren Beziehungen untereinander. CMIS macht zudem wenige Vorschriften bzgl. der Funktionalität des darunter liegenden Repositories. Umfangreiche Meta-Abfragen erlauben es einem Client, abzufragen, welche Funktionalität ein bestimmtes Repository durch CMIS anbietet. Aus Sicht des Anbieters bedeutet dies beispielsweise, dass ein Repository, welches Versionierung nicht unterstützt, wegen CMIS nicht extra erweitert werden muss. Es wird durch die Metadaten-Abfrage einfach bekannt gegeben, dass CheckIn/CheckOut nicht möglich sind. Dies ist ein großer Unterschied zu JCR, der hier viel härtere Vorgaben setzt. Dies macht es für die Anbieter relativ einfach, CMIS umzusetzen. Voraussetzung ist einzig, dass ein Repository eine minimale Order/Dokumenten-Struktur unterstützt. Und das kann schon ein simpler File-Server.

 

Dies hat natürlich auch seine Kehrseiten. Software-architektonisch ist CMIS gut vergleichbar mit JDBC/ODBC, welche den Zugriff auf relationale Datenbanken vereinheitlichen. Obwohl auf letzteren beiden Standards eine Anwendung gegen beliebige relationale Datenbanksysteme laufen sollte, wird jemand, der das schon versucht hat, gleich abwinken. Zu groß sind die Unterschiede in der SQL-Syntax und im Leistungsumfang der RDBMS, als dies einfach möglich wäre. Man bekommt dann halt doch eine Oracle, db2 oder MySQL-Version der Anwendung. So ähnlich wird es sich mit CMIS verhalten. Hier stehen aber vor allem die bereits erwähnten unterschiedlichen Leistungsmerkmale der Repositories im Vordergrund. Sie werden dazu führen, dass um CMIS herum eine weitere Softwareschicht notwendig ist, welche diese Unterschiede „abfedert“. Diese Softwareschicht liegt nun klar in der Verantwortung des Clients von CMIS, also dem Kunden, der CMIS einsetzen will. Bei ihm fällt ein entsprechender Aufwand an.

 

Man sollte die Sache aber deswegen nicht gleich wieder in die Ecke stellen. Auch wenn es – leicht abgewandelt – nur ein kleiner Schritt für den ECM-Anwender ist, so ist es doch ein großer für die ECM-Welt. Zu Beginn seiner Arbeit hatte das JCR-Gremium einmal erhoben, wie viele Arten es wohl gäbe, um Dateinamen innerhalb eines Folders herauszulesen. Eine sehr einfache Operation also. Heraus kamen bei der Befragung der Anbieter über 100 APIs, in den verschiedensten Programmier- und Scriptsprachen sowie Kommunikationsmethoden. So gesehen ist es wirklich ein großer Fortschritt, dass sich mit CMIS ein einheitlicher Syntax via WebServices resp. REST (HTTP) etabliert. Die zusätzlich nötige Softwareschicht sollte in einer Service-Orientierten Architektur untergebracht werden, genauso wie CMIS selbst natürlich auch. Und hier ergibt sich dann das wohl größte Sparpotential: wer heute bereits auf SOA-Basis Document-Repositories integriert, dürfte ein paar proprietäre Schnittstellen über Bord werfen können;  für alle anderen wird die Integration solcher Systeme in Zukunft einfacher.

 

Hier liegt auch ein weiterer zentraler Punkt: CMIS ist in einer Architektur nur ein kleines Element, dass CRUD-Funktionen für ein Repository übernimmt. Es ist also unerlässlich, dass CMIS durch eine übergeordnete SOA gesteuert wird, welche die einzelnen atomaren Schreib-/Lesefunktionen koordiniert. Eine solche übergeordnete SOA ist beispielsweise die Ressource Oriented Architecture, welche ich in meinem letzten Blog-Eintrag vorgestellt habe (http://ecm-blog.fme.de/allgemein/2009-05/resource-oriented-architecture-das-www-furs-unternehmen). Überhaupt ist der Einsatz von CMIS vorerst nur im SOA-Umfeld sinnvoll, also nur dort, wo Informationen aus zwei oder mehr Repositories oder Silos gelesen werden sollen. Betreiben Sie eine Anwendung, welche nur ein Repository benutzt, so würde CMIS nur zusätzlichen Overhead und vielleicht sogar eine Limitierung des Funktionsumfangs des DMS bedeuten.

 

Zusammenfassung

 

CMIS hat eine fast nicht breiter zu machende Unterstützung aus der ECM-Industrie erhalten, entsprechende CMIS-Adapter werden schnell nach Erscheinen der verabschiedeten Spezifikation (Optimisten rechnen damit noch dieses Jahr) erhältlich sein. Die Adaption durch die Anwender ist zu diesem Zeitpunkt naturgegeben noch völlig offen. Diese wird vor allem wachsen mit der Anzahl an umgesetzten Service-Orientierten Architekturen in den Unternehmen, und dem Wunsch, Informationen aus verschiedensten Quellen und Silos zusammenzuziehen, um damit dem Endbenutzer eine vollständigere Information zu präsentieren und ihm schlussendlich eine effizientere Arbeitsweise zu ermöglichen. Auch wenn der CMIS-Standard in der Version 1 nur der kleinste gemeinsame Nenner der ECM-Industrie sein wird, d.h. sich auf die Abbildung eines einfachen Ordner/Dokumenten-Datenmodells fokussiert, so ist doch die Vereinfachung für SOA-Projekte direkt greifbar, weil eine große Anzahl proprietärer Schnittstellen entfallen dürfte. Nach und nach werden weitere Funktionen dazukommen, wie etwa Collaboration- oder Records-Management-Unterstützung.

 

Insofern ist absehbar, dass der CMIS-Standard kreiert wird, um zu bleiben.