|  |
JSR 170: Standardisierung der Content-Repository-Schnittstelle
Das World Wide Web ist das am weitesten verbreitete und genutzte Softwaresystem, das jemals entwickelt wurde. Es nutzt eine relativ einfache, standardisierte Schnittstelle, um Informationen aus der ganzen Welt in sich zu vereinen. Das Besondere daran: Es ist irrelevant, wie die Informationen hinter dieser Schnittstelle erstellt, gespeichert und verarbeitet werden. Ein weiterer Vorteil dieses Ansatzes ist die einfache Implementierungsmöglichkeit webbasierter Dienste auf jedem Computer, ungeachtet ob dieser über eine Internet-Verbindung verfügt oder nicht. Die Web-Architektur ermöglicht somit die Komplexität traditioneller, netzwerkbasierter Software zu überwinden.
Leider werden diese Prinzipien oft ignoriert, wenn es darum geht, Applikationen hinter der standardisierten Web-Schnittstelle zu entwickeln. Besonders die Plattformen .NET und J2EE greifen bei der Entwicklung von Software-Diensten auf komplexe und spezifische Schnittstellen zurück, die auf proprietären APIs (Application Programming Interface) beruhen.
Programmierer werden ermutigt, spezifische Schnittstellen zu erstellen, die eng mit dem zu bearbeitenden Objekt verbunden sind. Viele Applikationen reagieren dadurch jedoch anfälliger auf Veränderungen und werden zusätzlich unverständlicher für diejenigen, die sie administrieren. Doch die Bedürfnisse der Benutzer ändern sich stetig; Die Folge der Programmierung von proprietären Schnittstellen ist, dass sich IT-Abteilungen aus Effizienzüberlegungen häufig dafür entscheiden, eine völlig neue Applikation zu entwickeln, statt die existierende an neue Anforderungen anzupassen.
Zwei Ansätze: Control-zentriert vs. Content-zentriert
Die Entwicklung einer Applikation muss nicht unbedingt so komplex wie der Funktionsumfang der Applikation selbst sein. Der Erfolg des Internets verdeutlicht, dass komplexe Ziele auch durch die Nutzung einer einfachen content-zentrierten Schnittstelle und dem Willen zur Standardisierung erreicht werden können. Deshalb sollten dieselben entwicklerischen Prinzipien, die das Web erfolgreich gemacht haben, auch bei der Entwicklung von Server-Applikationen angewendet werden.
Der control-zentrierte Ansatz nutzt zum Beispiel die beeindruckende Funktionalität eines Word-Prozessors. Doch der Nachteil ist, dass die unzähligen Aktionen der Schnittstelle eng mit den spezifischen Versionen des Datenmodells eines Herstellers verknüpft sind. Dies führt letztlich dazu, dass die Grenze des Funktionalitätsumfangs, den ein einzelner Anbieter bereit stellen kann, schnell erreicht wird.
Im Gegensatz dazu vereinfacht eine content-zentrierte Schnittstelle die Integration von Applikationen, da der Fokus hier auf den Eigenschaften des Contents und weniger auf der spezifischen Kontrolle durch eine bestimmte Applikation liegt. Dieser Ansatz limitiert einerseits zwar die Funktionalität, die über die Schnittstelle selbst erreicht wird, andererseits ist jedoch eine beliebige Anzahl zusätzlicher Applikationen integrierbar.
Der Unterschied zwischen einer Control-zentrierten und einer Content-zentrierten Schnittstelle wird am ehesten anhand der Integration einer Word-Applikation deutlich: Im Sinne des Control-zentrierten Ansatzes wird zunächst die Funktionalität betrachtet, die im Kommandomenü des Word- Prozessors zur Verfügung steht (z.B. "Format" oder "Absatz"). Der Entwickler wird nun methodische Schnittstellen schaffen, die die Kommandos und Dateneinträge des Word-Prozessors reproduzieren. Eine Content-zentrierte Strategie betrachtet hingegen die Daten, die von der Applikation verarbeitet werden, in diesem Falle eine Sequenz von Absätzen mit verschiedener Formatierung.
Den architektonischen Prinzipien des Webs beim Design einer Content-zentrischen Schnittstelle zu folgen, heißt nicht, sich auf die Datenformate und Protokolle zu beschränken, die die Web-Schnittstelle bilden (also HTTP und HTML). Vielmehr lernen wir von ihr, auf einfache Art ihre Designprinzipien zu nutzen und den Fokus auf einheitliche Identifikationen, Standardmethoden und erweiterbare Darstellungsarten zu legen. Der Austausch zwischen Web-Clients und Servern basiert auf Nachrichtenaustausch auf grobgranularer Ebene über Netzwerke mit hohen Latenzzeiten.
Im Gegensatz dazu besteht die Applikationsentwicklung innerhalb eines Servers primär aus feingranularer Kommunikation mit lokalen Datenträgern. Dafür wird eine vereinfachende Architektur benötigt, die Content-zentriertes Design über eine einheitliche Oberfläche ermöglicht. Zusätzlich soll der Austausch kleiner Datenmengen genauso möglich sein, wie der Gigabyte-Datentransfer. Eine solche Schnittstelle nennt man Content Repository API.
Was muss ein Content Repository können?
Ein Content Repository agiert als eine Art "Super-Speicher" für Anwendungsdaten. Es soll sowohl kleine als auch große Daten-Interaktionen ermöglichen, sowie strukturierte und unstrukturierte Daten (z.B. Binär- und Textformate oder Metadaten) verändern und speichern können. Außerdem sind Services wie eine einheitliche Zugangskontrolle, Sperrung, Transaktionen, Versionierung, Überwachung und Suche wünschenswert. In einigen Fällen liegt das Content Repository auf dem gleichen Server wie die Applikation selbst, in anderen Fällen wird es aufgrund Erreichbarkeit und Lastausgleich auf einem separaten Server platziert.
Die Vorteile einer standardisierten Programmierschnittstelle (API)
Softwareentwickler können eine standardisierte Schnittstelle als Basis für ihre Applikationen nutzen, ohne von propriäteren Schnittstellen einzelner Anbieter abhängig zu sein. Eine standardisierte Programmierschnittstelle ermöglicht es zudem, die Applikation von einer Content Repositoriy-Implementierung zur nächsten zu verschieben, je nach bestmöglicher Anwendung für die Applikation. Für Entwickler bietet ein Standard ein einheitliches Vokabular, erleichtert den Ideenaustausch bei Design- und Realisierungsüberlegungen und macht das Erlernen dutzender proprietärer APIs überflüssig.
IT-Projektmanager benötigen Standards, um das Risiko bei der Projektplanung zu minimieren. Die Benutzung einer gemeinsamen Schnittstelle unterstützt die Wiederverwendung von Erfahrung und Programmcode, was zu Kostenreduzierung führt und die Planung neuer Projekte vereinfacht. Sofern mit einem Standard gearbeitet wird, der von verschiedenen Herstellern unterstützt wird, entfällt auch das Risiko, von einem einzelnen Hersteller abhängig zu sein. Im Gegenteil, ein einziger Standard für Content Repository-Systeme erleichtert den Vergleich zwischen verschiedenen Herstellern und ermöglicht so auf einfache Art und Weise das geeignetste Content Repository-System für eine bestimmte Applikation auszuwählen. Zudem bietet ein Content Repository-System einen schnelleren Return On Investment, da es nicht auf einzelne Projekte oder Applikationen limitiert ist.
Die Verfügbarkeit eines Standards unterstützt die Entwicklung unabhängiger Dokumentationen sowie Beratungs- und Schulungsangebote. Bald darauf folgen für Entwickler Werkzeuge mit bereits eingebauter Schnittstellen-Unterstützung, die wiederum weitere, auf der Schnittstelle basierende Applikationen hervorbringen. Eine Vielzahl von Applikationen schafft so eine Marktchance für die Entwicklung von Infrastruktursoftware, die weit über den Wert einer einzelnen Applikation hinausgeht. Folglich wird der Standard zum Inbegriff für Leistungsoptimierung.
Von standardisierten Schnittstellen profitieren Applikationsentwickler und Projektmanager ebenso wie Unternehmen, die dafür Werkzeuge, Schulungen und Infrastruktur liefern. Die Softwareindustrie hat diese Folge von Innovation, Standardisierung und rascher Adaption schon oft erlebt. Daher bevorzugen Grossunternehmen heute Hersteller, die Software mit Standard-basierter Architektur anbieten, und nicht Hersteller, die sie in eine technologische Sackgasse führen.
Lesen Sie das nächste Kapitel | | | weiter |  |
07/2007, Dr. Roy T. Fielding
| | Dr. Roy T. Fielding ist Chief Scientist bei Day Software und bekannt für seine Mitarbeit bei der Entwicklung und Definition der heutigen World Wide Web-Infrastruktur. Außerdem ist er Architekt des aktuellen Hypertext Transfer Protocol (HTTP/1.1).
|
Kommentare zu diesem Beitrag | | |
Weitere Beiträge zu diesem Thema | | |
|  | | In einer Keystone-Studie wurden die ERP-Lösungen von Microsoft Dynamics und SAP hinsichtlich ihrer Akzeptanz und Nutzung verglichen. | |  | | Die Contentmanager.days standen dieses Jahr unter dem Motto "Metamorphose". Eine Metamorphose beschreibt in der Natur einen regelmäßigen Prozess des Wandels. Übertragen auf das Content Management bedeutet das: Der Wandel ist beständig... | |  | | Glaubwürdigkeit wird in der Geschäftswelt groß geschrieben. Das ist leicht anhand einiger Negativbeispiele zu belegen... | |  | | Die meisten Wissensmanagement-Aktivitäten vollziehen sich im Medium Sprache. Trotzdem spielt die Qualität dieses Mediums in der Theorie und in der Praxis des Wissensmanagements praktisch keine Rolle... | |  | | Der User will an erster Stelle erfahren, welche Kernaussage Ihr Text ihm vermitteln wird. Um ihm dies zu erleichtern, strukturieren Sie Ihren Text in unterschiedliche Teile... | |
Beiträge aus anderen Themenbereichen | | |
|  | | Im Interview spricht der Schirmherr der Initiative Prof. Dieter Spath über "Das Konstruktionsbüro für Dienstleistungen" und vieles mehr. Am 12. Oktober eröffnet Prof. Dieter Spath den VOICE Days plus Kongress... | |  | | Die Gestattung der privaten Nutzung der betriebseigenen IT-Infrastruktur durch die Mitarbeiter bringt nicht zu unterschätzende rechtliche Komplikationen mit sich – gerade was auch die Archivierung von E-Mails anbelangt... | |  | | Datenschutz spielt auch im eCommerce eine große Rolle. So müssen z.B. für den Betrieb eines Onlineshops die gesetzlichen Vorschriften zum Datenschutz eingehalten werden... | |
| | | |
