Zu Diensten: SOA

Service Oriented Architecture, kurz SOA, ist ein neues Schlagwort – ein neues Schlagwort für altbekannte Konzepte!
Seit Jahrzehnten wird über Dienstearchitekturen in der Informationswissenschaft gesprochen. Ein Dienst ist dabei eine geschlossene Funktionalität, die über Standardschnittstellen angesprochen werden kann, auf einem Server (Rechner), auf mehrere verteilt und mehrfach auf einem Server betrieben werden kann. Also nichts Neues? Früher sprach man von Diensten in einer Middleware. Heute sind es halt Services in einer SOA oder in einem Enterprise-Bus. Die Trennung der Anwendungen im Dienste, ist schon lange ein Desiderat um wild wuchernden, immer komplexeren Applikationen begegnen zu können. Aber wird durch SOA die Komplexität geringer? Dienste müssen harmonisiert werden, die Schnittstellen müssen vorhanden sein und funktionieren, die Services müssen administriert und überwacht werden, und es muss die Transaktionssicherheit über alle beteiligten Dienste in einem Prozess realisiert sein. Setzt man auf dieses neue Konzept, holt man sich zunächst eine weitere IT-Infrastruktur neben den bestehenden Systemen ins Haus. Die Vorteile von SOA erschließen sich erst richtig dann, wenn alle Komponenten und Anwendungen auf ein Dienstekonzept umgestellt sind. Nur dann funktioniert auch die »Orchestrierung von Services«. Grundidee ist dabei, dass es für jede Funktion nur einmal einen gekapselten Service gibt. Der Dienst wird dann vom »Service Provider« dem »Service Consumer« bei einem »Service Request« bereitgestellt. Hierbei ist es notwendig alle Parameter und Objekte vollständig und interpretierbar zur Verfügung zu stellen. Ähnliche Konzepte haben wir bereits mit intelligenten Business Objects oder CORBA in der Vergangenheit kennen gelernt, ohne dass sich diese bisher durchsetzen konnten.

SOA als EAI-Alternative

Ein weit verbreiteter Irrtum ist, dass SOA sich nur auf Web-Services bezieht. Natürlich sind Web-Services eine mögliche Implementierungs- und Nutzungsform, jedoch kann man auch in anderen Architekturen wie Client/Server (sic!) das gleiche Prinzip nutzen. Aber weil Portale und Webanwendungen ein modernes Thema sind und hier besonders viele architektonische Mängel zu beobachten waren, wird der SOA-Ansatz in diesem Marktsegment zur Zeit favorisiert aufgegriffen. Für die Kommunikation kommen daher auch Protokolle und Standards zum Einsatz, die im Web-Umfeld beheimatet sind. Oft werden für SOA Web-Services auf der Basis von Standards wie SOAP, WSDL und UDDI oder Enterprise-Java-Beans umgesetzt. Diese technischen Umsetzungen werden häufig aus Performance- und Transaktionssicherheitsargumenten negativ bewertet, so ist zum Beispiel SOAP ein sehr »geschwätziges Protokoll«. Geeignetere Standards gibt es leider noch nicht, so dass SOA vielerorts Vision aber kaum eine Realität ist. Im Prinzip kann aber eine SOA prinzipiell auf jeder dienstbasierten Technologie aufgebaut werden. SOA stellt damit auch eine Alternative zum Enterprise-Application-Integration-Ansatz dar.

Warum ist SOA für ECM wichtig?

Enterprise-Content-Management verfolgt von Anfang an den Ansatz Dienste-orientierter Architekturen – nur den Begriff SOA gab es noch nicht. Die drei wesentlichen Ideen von Enterprise Content Management sind erstens die Abkehr von vertikalen Anwendungen zu einer horizontalen Middleware, zweitens die Kapselung der Funktionalität in Diensten, die über standardisierte Schnittstellen allen Anwendungen und Anwendern gleichermaßen zur Verfügung stehen, und drittens die Bereitstellung eines übergreifend nutzbaren Speicherortes für alle Daten, Informationen, Content, Records usw.
Die Erfahrung zeigt, dass es sehr wenig Anbieter gab und gibt, die solche Architekturansätze unterstützen. Die Verfügbarkeit echter Services ist das derzeitige Problem von SOA. Am ehesten dürfte heute IBM an diesem Konzept dran sein, bei den klassischen ECM-Anbietern vielleicht FileNet und Documentum. Ein Umdenken ist bei den Anbietern gefordert. Standardisierte Dienste und standardisierte Schnittstellen erlauben eine direkte Vergleichbarkeit und eine Austauschbarkeit der Produkte. Dies lag unter dem Gesichtspunkt der »Kundenbindung« nie im Interesse der Anbieter. Jedoch ist es gerade beim allumfassenden Anspruch von ECM mit Capture, Deliver, Store, Manage und Preserve notwendig, auf diese Strategie zu setzen, da kaum ein Anbieter in der Lage ist, rechtzeitig in gebotener Qualität alle Funktionalität selbst zu programmieren. ECM-Suiten lassen sich nur durch die Kombination geeigneter Dienste anbieten. ECM als Infrastrukturkomponente muss daher auf Dienstekonzepte setzen, egal ob sie sich nun SOA oder anderswie nennen. Angesichts des den Ansprüchen von SOA genügenden Produktangebots, fühlt man sich jedoch als Rufer in der Wüste. Zu lange und zu häufig wurde über neue Architekturen gesprochen ohne dass geeignete Komponenten verfügbar gemacht wurden. Auch SOA wird als leeres Akronym enden, wenn nicht das notwendige Umdenken bei Anbietern und Anwendern erfolgt.

Dr. Ulrich Kampffmeyer, Unternehmensberatung PROJECT CONSULT