In ECM Kreisen ist die Zukunft des CMIS Standards (“SQL für Content Management”) aktuell offenbar ein sehr beliebtes Thema. Das Spektrum der Meinungen ist breit und reicht von “tot” bis zu “heiligem Grahl”. Was die Spekulation über die Zukunft von CMIS angeht ist im Moment vermutlich so ziemlich alles gesagt.
Grundsätzlich habe ich persönlich das Gefühl wir empfinden Standards als etwas Positives (weil man nicht an einen Hersteller gebunden ist). Vom Standard geht es über “Quasi Standards” (wie z.B. Spring) stufenlos negativer bis proprietär. Das Wort Standard an sich ist auf Management-Ebene also sicherlich schon ein gutes Argument pro CMIS. Andererseits hat ein Standard aber auch immer etwas Negatives vom “Kleinsten gemeinsamen Nenner” und Schwerfälligkeit.
Ich möchte an dieser Stelle einfach mal ein paar erste praktische Eindrücke welche ich im Rahmen eines Web-Projektes sammeln durfte zum Besten geben. Ich bin sicherlich kein CMIS Experte und habe mich mit dem Standard und der eingesetzten Implementierung OpenCMIS nur mit soviel Tiefgang beschäftigt wie für das Projekt nach meinem Empfinden erforderlich war. Von daher möge man mir bitte verzeihen (und mich gerne auch korrigieren) wenn ich CMIS an der einen oder anderen Stelle Unrecht tue.
In der Praxis wird beim ersten Einsatz einer Technologie meist noch das eine oder andere bisher unberücksichtigte “Detail” zutage gefördert. Außerdem stellt man vielleicht auch fest, das gewisse Argumente wie z.B. “Standard per se” am Ende kaum oder gar nicht ins Gewicht fallen. Wie oft z.B. macht man von Portabilität dank Standard in der realen Welt wirklich Gebrauch ?
Im folgenden ein paar Themen, die mir im Rahmen eines CMIS Projektes begegnet sind:
Leichtgewichtiger Client
OpenCMIS inklusive Library-Abhängigkeiten ist durchaus überschaubar. Das ist sicherlich auch auf die Tatsache zurückzuführen, dass HTTP als Transport-Schicht eingesetzt wird. Andere Technologien bringen hier sicherlich eher mehr “Konfliktpotential” für eine Anwendung mit.
Sessionloser Service
CMIS sieht (im Gegensatz zu SQL) keine Session (Zustand) auf dem Server vor. Diese Tatsache macht Realisierung von Skalierbarkeit und Verfügbarkeit (des Servers) zunächst vergleichsweise einfach.
Transaktionen
Transaktionen sind in der Version 1.0 von CMIS nicht vorgesehen – ein Thema welches ein Stück weit mit der Sessionlosigkeit des Service einhergeht. Im Projekt wurde CMIS nur zum Lesen eingesetzt. Bei komplexeren transaktionalen Schreiboperationen kann es hier unangenehm werden.
Caching
Der Standard CMIS selbst sieht hier nichts vor und überläßt das Thema den Implementierungen. OpenCMIS bringt Unterstütztung für einen First Level (Session) Cache mit.
Security
CMIS Sessions sind grundsätzlich authentisiert. Soll eine Website auch Daten für nicht angemeldete Benutzer abfragen und anzeigen, so braucht man “public” Credentials um eine CMIS Session für die Kommunikation mit dem Repository zu erzeugen und Daten zu lesen und/oder schreiben. Soll die Website (nicht das Repository !) nun sowohl authentisierte als auch unauthentisierte Anfragen unterstützen kann es durchaus kompliziert werden. “Unauthenticated” Sessions können anders cachen, gepoolt und von verschiedenen Usern genutzt werden. Handelt es sich bei der Anwendung um eine Website, so ist es wohl meist sinnvoll für angemeldete User eine “private” CMIS Session in der HTTP Session zu halten – das sollte einem bei der Dimensionierung der Resourcen klar sein. ;)
Joins
Abfragen von Beziehungen in der where clause, also so etwas wie
select art.title from article art, author auth where art.authorId=auth.id and auth.name='Andreas';
wird aktuell nicht unterstützt.
Andererseits unterstützt aber z.B. Alfresco das Abfragen von Aspekten / Mix-Ins als Join. Durchaus besser als nichts, es kann aber auch “anstrengend” werden wenn man im Content Modell sehr stark Gebrauch von Aspekten macht.
Performance
Unabhängig davon ob man CMIS mit AtomPub oder SOAP nutzt sollte man sich darüber klar sein das es sich hierbei am Ende des Tages um XML über HTTP handelt. Bei allzuviel jugendlichem Leichtsinn und unglücklicher Parametrisierung kann es so leicht zu unerwartet hoher Belastung des Systems kommen (Bei meinen ersten Gehversuchen auf “größeren” Datenbeständen wurden da schonmal 150 MB übertragen).
Tooling
Mit CMIS hatte ich grob gesagt etwa den Entwicklungs-Komfort von “rohem” SQL. Wirft man einen Blick in die relationale Welt, so kann schon der Wunsch nach Dingen wie Code-Generatoren (wie z.B. für Hibernate DAO/-Entities) aufkommen.
Hinterher ist man eben immer schlauer.
Für den Interessierten Leser hier noch die Links zur Spezifikation und Zukunftsvisionen:
- Content Management Interoperability Services (CMIS) Version 1.0
- Kommt CMIS zu spät?
- CMIS 1.0 May Be 3.0 Years Too Late
- CMIS 2.0, The Next Generation
- CMIS 2.0 – Where Are You?
- Will CMIS Suffer JCR’s Fate?