bannkreis.de

Sinn und Unsinn von JSR170

Dieser Specification Request, eine API für beliebige Content-Management-Systeme, ist ein typisches Komiteekind. Oft setzen sich diese, im Bestreben allen Anforderungen gerecht zu werden, zwangsläufig zwischen alle Stühle oder sind derart generalisiert, dass der echte Nutzen der Abstraktion zum Opfer fällt. Ohne bereits produktiv damit gearbeitet zu haben halte ich dieses JSR für gefährdet, mindestens unter die zweite Kategorie zu fallen.
Was für ein Problem sollte gelöst werden? Es gibt eine vielzahl proprietärer Content Management Systeme auf dem Markt. All diese Systeme, oder zumindest die meisten, beziehen und speichern ihre Daten in/aus einem proprietären Format, vielleicht sogar in einem proprietären Datenbanksystem. Um es noch schlimmer zu machen hat jedes CMS seine eigene Organisationsform von Daten, seine eigene Struktur die nur in diesem System einen Sinn ergibt.

Dies macht den CIOs der Unternehmen, welche sie einsetzen, nicht ganz zu Unrecht Kopfschmerzen. In Zeiten der allumfassenden Datenintegration erscheints es fast wie ein Anachronismus, dass das CMS auf seinen Daten hockt wie eine Glucke und keine Funktionalitäten bereitstellt, um sie aus anderen Anwendungen heraus zu modifizieren oder auch nur zu lesen.

Es ist ja nicht so als wäre die "Enterprise Application Integration"-Welle spurlos an den CMS vorbeigegangen. Nur dass es in der Natur jedes CMS-Herstellers liegt, sein eigenes System als das führende anzusehen, an welches sich alles andere andocken soll. Dies erweist sich im Nachhinein als Gift für die Grundidee. Jetzt besitzen die Systeme alle flexible Schnittstellen, um die verschiedensten Datenbanksysteme anzusaugen, nur ihre eigenen Daten geben sie einem Fremdsystem weiterhin nicht preis.

Was bleibt? Speichert das CMS in eine gewöhnliche relationale Datenbank, so kann man versuchen, sich einen Reim auf die Datenstruktur zu machen und sie direkt anzuzapfen. Naturgemäß ist dieser Ansatz heikel, erst recht wenn modifizierend auf die Daten zugegriffen werden soll.  Dokumentiert der Hersteller seine Struktur, so ist das auch nur die halbe Miete, muss doch die Zugriffslogik programmiert werden. Weshalb sollte man für so etwas Geld ausgeben, wenn die notwendigen Funktionalitäten eigentlich da sind, man sogar dafür bezahlt hat?

"Fortschrittlichere" CMS-Hersteller mögen da sogar mit ihrer eigenen API aufwarten, die tatsächlich von ausserhalb verfügbar ist. Das ist momentan wohl das beste was man erreichen kann. Immer noch proprietär, aber maßgenau auf die Struktur des jeweiligen Systems angepasst. Ich persönlich bin der Meinung, das ist sogar das beste was rein logisch erreichbar ist, und die Content Management API bestätigt mich in dieser Ansicht.

Die "Lösung" wähnten also einige namhafte Unternehmen in der Schaffung einer neuen Spezifikation, welche sich dem standardisierten Zugriff auf "Content Repositories" widmet, besagtes JSR170. Das Ziel war so eine Art "JDBC für CMS", einer allgemeingültigen Schnittstelle die man einmal lernt und dann auf alle konkreten Systeme anwenden kann.

Ist das die "Success Story" die wir anstreben sollten? Wenn wir uns JDBC anschauen, dann war diese Spezifikation auch nur ein partieller Erfolg. Der erfolgreiche Teil von JDBC setzt auf den Gemeinsamkeiten aller relationalen Datenbanksysteme auf,namentlich natürlich dem relationalen Modell der und der immergleichen Abfrageschnittstelle, die einen SQL-Text immer mit einem uniformen Resultset belohnt.  Die ersten Spezifikationen von JDBC basierten pur auf diesen Kernfunktionalitäten und umschifften damit die Teile der Systeme, an denen diese grundverschieden waren, z.B. die zum Teil subtil unterschiedlichen SQL-Syntaxen.

So war jeder der JDBC verwendete trotz einheitlicher Schnittstelle gezwungen, sich an den SQL-Standard des jeweils eingesetzten Systems zu halten. Alle späteren Ansätze, JDBC syntaxUNabhängige Funktionen zur Datenmodifikation zu verpassen, z.B. bearbeitbare Resultsets, krankten daran, dass sie auf einem sehr filigranen Level optional für den Treiberhersteller waren. Dies führte logischer Weise dazu, dass fast jeder Treiber einen limitierten Featureset aufweist, der zum Teil in einer komplexen Unterstützungsmatrix dokumentiert wurde. Oft fand man sich dann doch wieder mit nativen SQL-Anweisungen hantierend wieder, weil irgendeine essentielle Funktion fehlte.

Wo passen Content Management Systeme hier rein? Sie sind sicherlich noch heterogener als relationale Datenbanken und bauen nicht alle auf derselben standardisierten Struktur auf. Der gemeinsame Nenner liegt eher auf einem niedrigerem Level und ist das, was uns als Content Management API präsentiert wurde. Was ist es, was wir da haben? Im Endeffekt ist dies DOM, das Document Object Model, eine simple Baumstruktur bestehend aus hierarchischen Knoten mit daran eingehängten Name/Wert-Paaren. Als einziges nicht-optionales Feature, welches zum CMS-Thema passt mache ich den Knotentypen und die damit verbundenen Funktionalitäten aus. Alles andere ist optional, wie Locking, Versionierung, sogar Datenmodifikation ansich. Irgendeine eingebaute Unterstützung für mehrsprachig vorliegende Inhalte habe ich bislang nicht gefunden, ist wahrscheinlich nicht vorhanden.

Wie nützlich ist sowas? Nun, es steht natürlich zu erwarten, dass die CMS-Anbieter diese Grundstruktur sehr unterschiedlich für ihre Systeme interpretieren. Ok, eine Hierarchie hat irgendwie jeder, aber wie diese aufgebaut wird, was für Bausteine dort abgebildet werden und was man dann mit diesen Bausteinen machen kann, all das ist im Endeffekt weiterhin proprietär. Daher ist meine Befürchtung, dass dies wieder nur dann sinnvoll genutzt werden kann, wenn die Programmierung sich wieder an die Gegebenheiten des jeweiligen Systems anpasst. Ok, auch das ist schon bei JDBC so.

Sind wir also weiter gekommen als mit der Benutzung proprietärer APIs? Nun vielleicht, ich bin mir nicht sicher. Sicherlich ist dies nicht der Ansatz mit dem man ab sofort Content Management Systeme alle über einen Kamm scheren kann. Es ist weiterhin notwendig zu wissen, welches System da im Hintergrund konkret ist, damit man es sinnvoll bedienen kann. Unter dem Aspekt betrachtet haben wir wieder genau die JDBC-Situation. Irgendwie schon eine einheitliche Schnittstelle, aber unterschiedlich zu interpretieren und zu bedienen.

Stellen wir uns folgende Frage:
Gibt es Gründe eine vorliegende  proprietäre API gegenüber einer standardisierten API zu bevorzugen? Dies wäre nur dann der Fall, wenn ich spezifische Funktionen des dahinterliegenden Systems nicht über die standardisierte API erreichen kann. Dies ist bei JDBC selten der Fall, da diese Funktionen in der Regel alle über den jeweiligen SQL-Dialekt erreichbar sind. Bei der CM-API hängt es davon ab, wie gut die Hersteller ihre Funktionen auf die API abbilden können. Hier halte ich vorerst Skepsis für angebracht.

Bitte geben Sie hier Ihren Kommentar ein:

Verwende Markdown Syntax

Autor

About

Last comments

  • Oliver:
    Als Antwort auf "Anonym" vom 27. Dezember 2015 (..
  • anonym:
    Habbo als abzocke zu deklarieren finde ich schon..
  • anonym:
    Wenn du es dir leisten kannst und es dich glückl..
  • Jebote:
    ja sicher kommen alle auf diesen 5 jahre alten a..
  • Micha:
    @Ingo, na klar. Alles legitim und voll ok ;-) Mu..

Really currently consuming

Links

  • Mehr Whisky
  • Ich@last.fm
  • Ich@Twitter
  • Dina
  • Julia
  • Der Meister (nebst Frau Meister)
  • Rockender Webworker
  • Irgendwas mit Fischen