Von Jörg Freiberger

Applikationsarchitekturen haben ein wandelndes Gesicht. Wie man es auch in vielen anderen Bereichen der IT-Welt kennt, wechseln hier die Paradigmen regelmässig und unterliegen einer ständigen Weiterentwicklung. Und das ist gut so, denn in dem Masse, wie sich beispielsweise Standards oder auch die Hardware im Laufe der Zeit weiterentwickeln, hat die «Evolution» auch Einfluss auf die Applikationsarchitekturen. Drei wesentliche Triebkräfte sind Wartbarkeit, Interoperabilität und Wiederverwendbarkeit. Diese Kräfte treiben die Evolution voran, sind aber manchmal auch nur Ausdruck von Marketing-Strategien. Ist SOA also lediglich ein Ablenkungsmanöver, bis zum Erscheinen von Windows Vista? Denn hatten wir bei der Entwicklung von Software für unsere Kunden nicht schon immer mit den Service-Gedanken im Hinterkopf?

Von EAI zu SOA
Wer kennt denn (noch) den Begriff EAI - Enterprise Application Integration? Eine Definition lautet: «EAI ist die prozessorientierte Integration von Systemen in heterogenen IT-Architekturen». Bei EAI fanden bereits Ansätze und Visionen Verwendung, die heute auch einen Teil von SOA ausmachen. Dies sind insbesondere der Wunsch nach möglichst lose gebundenen Programmmodulen, transparenter Lokation und eine Unabhängigkeit von Protokollen.
Grundsätzlich erfolgt die Integration bei EAI über einen Business-Bus (auch Integrationsplattform oder Message-Bus), bei dem die Kommunikation auf Nachrichtenübermittlung (Messages) basiert. Dabei werden bestehende Komponenten und Applikationen nicht verändert, sondern durch so genannte Adaptoren mit einem Business-Bus verbunden (Abbildung 1).

Mit einer breiten Etablierung von Standards für verteilte Anwendungen (allen voran CORBA, DCOM, EJB und RMI) und der komponentenorientierten Softwareentwicklung (z.B.. COM, J2EE) wurden diese Visionen implementiert. Allerdings geschah dies oftmals in Abhängigkeit einer Plattform, die den oben erwähnten Triebkräften Wartbarkeit, Interoperabilität und Wiederverwendbarkeit entgegenwirkte.

SOA als Allheilmittel?
Die Service Oriented Architecture (SOA) ist ein Konzept für eine Systemarchitektur, bei dem die Bereitstellung fachlicher Funktionalitäten in Form von Diensten (Services) erfolgt. Dabei ist ein wesentliches Ziel die Kapselung von Daten durch einen solchen Dienst. Auf diese Weise werden Redundanzen verringert und die Flexibilität der Systeme erhöht. Ausserdem sollen mit SOA Businessprozess adäquat umgesetzt werden und zwar so, dass analog zu den sich ständig ändernden Business-Anforderungen auch die Software und der implementierte Prozess flexibel sind. Dies bedeutet, dass die Software selbst den Veränderungen standhalten beziehungsweise folgen kann.
Von der technischen Warte aus betrachtet wird ein System, welches aus eigenständigen Diensten besteht, als serviceorientiertes System bezeichnet. Im Wesentlichen sind es vier Merkmale, die ein solches SOA-System ausmachen:
1. Policy-basiert: Die Nutzung eines Dienstes ist an klar vorgegebene Voraussetzungen gebunden. Hierzu gehört beispielsweise eine Authentifizierung als Aufrufkonvention einer SOA-Komponente.
2. Explizite Grenzen: Es muss definiert sein, was innerhalb und was ausserhalb einer Komponente ist, und wann diese Grenzen überschritten werden. Die Interna der einen Komponente dürfen keinen Einfluss auf andere Komponenten haben.
3. Autonomie: Eine Komponente verwaltet die genutzten Daten eigenständig und bestimmt ausserdem die eigene Lebenszeit und Aktivität - interne Zustände sind absolut autark.
4. Austausch von Verträgen: Die Kommunikation mit der Aussenwelt wird ebenfalls definiert. Die Schnittstellen werden durch geeignete Dokumente beschrieben, die auch automatisiert zwischen SOA-Komponenten ausgetauscht werden können.

Bessere Interoperabilität
Im Gegensatz zum Business-Bus bei EAI, dient bei SOA der so genannte Service-Bus als Integrationsplattform. Dienste auf diesem Bus folgen alle den gegebenen Standards, erfüllen vorhandene Policies und passen sich der vorherrschenden Infrastruktur an. All diese Dinge - inklusive des Service-Bus - kennen wir jedoch bereits aus der Vergangenheit. Es sind Methoden und Technologien, die uns bei der Planung und Umsetzung von Softwarelösungen, besonders denjenigen mit verteilten Architekturen, schon immer beschäftigt haben. SOA bietet einen allgemeinen Lösungsansatz. Es ist kein Produkt, das man kaufen kann, und es ist auch kein Mäntelchen, das ich meiner Software anziehen kann. SOA ist eher als Prozess oder auch Vorgehensweise zu verstehen.

SOA bietet vor allem Flexibilität. Durch die lose Kopplung und den damit verbundenen Austausch von Nachrichten wird eine Integration beziehungsweise Interoperabilität stark gefördert. SOA-Dienste können darüber hinaus an Prozesse geknüpft werden. Mit geeigneten Orchestrierungswerkzeugen (z.B. Microsoft BizTalk Server, BEA WebLogic, IBM WebSphere, Sonic SOA Suite) lassen sich komplexe Geschäftsprozesse durch Aneinanderreihung von SOA-Diensten umsetzen.

SOA = Web Services?
Auf einer etwas abstrakten Ebene besitzt ein Dienst im Sinne von SOA eine äussere Hülle, die eine öffentlich zugängliche Schnittstelle zur Verfügung stellt (siehe Abbildung 2). Unter der ersten Schicht befindet sich die interne Implementierung, deren Details für eine Nutzung von ausserhalb keine Rolle spielen darf. Ein Aufruf eines Dienstes erfolgt also immer über das öffentliche Interface, während der Dienst selbst intern weitere Services aufrufen und Ressourcen (Datenbanken, Dateien, etc.) nutzen kann.
Ein Vertrag (oder Kontrakt) liefert Definitionen für die öffentliche Schnittstelle. Hierzu gehören beispielsweise das Kommunikationsprotokoll und Details über den Austausch von Daten (Nachrichtenformat). Weiterführende Regeln und das Verhalten legen jedoch so genannte Policies fest. Über diese wird das Business-Protokoll eines Dienstes definiert und auf diese Weise zum Beispiel beschrieben, ob und welches Authentifizierungsverfahren verwendet wird oder wie die Nachricht signiert oder komprimiert wird. Eine Policy ist dafür verantwortlich, jeden Aspekt der Interaktion eines Services und dessen Laufzeitverhalten zu regulieren.
Gerade hierbei liefern Spezifikation und Standards aus den Bereichen XML, Web Services und SOAP gute Hilfestellung. Das ist ein wesentlicher Grund, warum Web Services so häufig mit SOA gleichgesetzt werden. Aber Web Services sind nicht zwingend die Grundlage für SOA. Genau, wie Menschen auf unterschiedliche Arten miteinander kommunizieren können, so können auch für Dienste unterschiedliche Protokolle verwendet werden. Ob Sprache, E-Mail oder Gesten, Menschen können sich (fast) immer verständigen - man muss sich nur einig werden. SOA-Dienste können auch verschiedene Infrastrukturen nutzen: Ob Web Services, Remoting, DCOM oder J2EE spielt keine Rolle, so lange der Kommunikationspartner die gleiche Sprache spricht.

Die Einschränkungen einer SOA
SOA bringt IT und Business sehr nahe zusammen und lässt so oft die Grenzen verschwimmen. Das geht sogar soweit, dass manch einer gar von Service Oriented Business Architecture (SOBA) spricht. Dieses Spielchen mit Abkürzungen und eigenen Philosophien macht es nicht gerade einfach, auf dem Markt ein generelles Verständnis von SOA aufzubauen. Allerdings ist das wohl eher ein politisches denn technisches Problem.
Doch die Schwierigkeit, einen passenden Begriff inklusive eindeutiger Definition für eine solche Art von Architekturen zu finden, überträgt sich ebenfalls auf die zum Einsatz kommenden Technologien. Beschränken wir SOA einzig auf die Verwendung von Web Services als Infrastruktur, dann reicht das alleine schon aus, um einen einzelnen Entwickler bis zum Ende seiner Werktätigkeit zu beschäftigen, wenn er sämtliche Spezifikationen in diesem Bereich lesen und verstehen soll.
Damit sind wir auch schon beim schwerwiegendsten Nachteil angekommen. Die lang gesuchte und mit SOA scheinbar erreichte Interoperabilität geht sofort wieder verloren. Wenn nämlich Kontrakt und Policy eines Dienstes die Verwendung von bestimmten Protokollen und Spezifikationen vorschreiben, dann muss ein Partner sich natürlich an diese Vorgaben halten. Dadurch aber wird die Interoperabilität lediglich von der Protokoll- oder Objektmodell-Ebene auf die Kontrakt- und Policy-Ebene angehoben. Der Teufel steckt wie immer im Detail.

Fazit
Mit SOA lassen sich komplexe Systeme auf unterschiedlichen Plattformen, wie beispielsweise .NET und J2EE, miteinander integrieren. Hierbei bieten Web Services ideale Voraussetzungen. Sie leisten einen hervorragenden Beitrag zur Vereinfachung der Lösung und damit zur Erreichung des Ziels bei reduziertem zeitlichen und finanziellen Einsatz. Die Verwendung offener, weitgehend verbreiteter Spezifikationen ermöglicht bisher kaum gekannte Integrationsmöglichkeiten. Zwar schafft eine Unmenge an existierenden Standards und Spezifikationen im SOA-Umfeld einen breiten Interpretationsspielraum für sehr viele und unterschiedliche Implementierungen. Und das gilt nicht nur für die Implementierung der Standards selbst, sondern genauso für die darauf aufbauenden Anwendungen. Aber durch die Einigung auf Standards, Spezifikationen und - im Detail - auf Kontrakte wird die gezielte Integration von zwei unterschiedlichen Systemen im Gegensatz zur Vergangenheit (z.B. mit EAI) stark vereinfacht.

Jörg M. Freiberger ist seit 2005 als Associate Principal Consultant bei Avanade Deutschland im Bereich .NETSolution Development tätig.