SOA kann man nicht kaufen. Nun mag mancher einwenden, dass SOA doch im Markt angeboten wird. Zahlreiche Softwareanbieter bewerben ihre Produkte mit diesem Schlagwort, viele Produkte und auch Dienstleistungen schmücken sich mit der Bezeichnung SOA als Garant für Modernität und Zukunftssicherheit. Gibt es SOA also doch zu kaufen? Die Antwort lautet nein, weil SOA keine fertige Lösung oder technische Schnittstelle ist, sondern ein Paradigma, ein Denkmuster – und Denkmuster kann man nicht kaufen, sondern nur anwenden. Das SOA-Paradigma geht vom Begriff des Service, des Dienstes aus. An dieser Stelle sei darauf hingewiesen, dass Service nicht sofort eine bestimmte technische Implementierung, etwa einen Web Service, meint. Wesentlich ist, dass ein solcher Dienst eine genau abgegrenzte, nicht zu komplexe Aufgabe umfasst, die genau definiert und beschrieben werden kann.

Geschäftsprozesse und Dienste

Dieses Verständnis des Service wird nun verbunden mit einem erweiterten Verständnis von Geschäftsprozessen. Während die klassische Beschreibung eines Geschäftsprozesses von dem Bild der Wertschöpfungskette ausgeht, in dem einem Produkt durch aufeinander folgende Verarbeitungsschritte Wert hinzugefügt wird, wird immer mehr deutlich, dass dieses einfache Modell in vielen Fällen nicht mehr der Komplexität heutiger Wirtschaft entspricht. Erweiterte Modelle gehen von einem Netzwerk von Beziehungen zu Kunden und Lieferanten aus, die untereinander Dienste anbieten oder anfordern. Dieses Netzwerk von Beziehungen bildet den Geschäftsprozess.

Die Betrachtung eines Geschäftsprozesses als Netzwerk von angebotenen und in Anspruch genommenen Diensten gilt nicht nur für Geschäftsprozesse außerhalb des Unternehmens. Es kann auch auf die Prozesse innerhalb eines Unternehmens übertragen werden. Die einzelnen Abteilungen und Gruppen agieren dabei als Kunden für bzw. Lieferanten von Leistungen.

Genau hiermit sind die beiden wesentlichen Bestandteile von SOA beschrieben: der Prozess und der Dienst. Beide bilden den theoretischen Unterbau einer serviceorientierten Architektur. So geht es bei SOA in erster Linie also nicht um einen neuen technischen Standard oder eine neue Schnittstellentechnik. Bei SOA geht es um Geschäftsprozesse und die Dienste, die diesen Prozess abbilden. Geschäftsprozesse in modernen Unternehmen sind heute ohne Informationstechnologie nicht mehr denkbar – SOA schlägt die Brücke vom Prozess zur IT. Die serviceorientierte Architektur geht dabei der Fragestellung nach, wie Geschäftsprozesse in der IT abgebildet werden können. Die Abbildung erfolgt dadurch, dass die für einen Geschäftsprozess erforderlichen Dienste von der IT bereitgestellt werden. Unter Diensten werden dabei Komponenten verstanden, die untereinander lose verbunden sind. Die Komponenten sind dabei nicht unlösbar voneinander abhängig, sondern können durch andere Komponenten ersetzt werden, die den gleichen Dienst anbieten. Die Steuerung des Geschäftsprozesses selbst erfolgt nicht durch die Komponenten, diese stellen nur die definierte Funktionalität zur Verfügung und sind nur für ihre eigenen Daten verantwortlich. Die nur lockere Verbindung der Dienste und die Kapselung der Daten, die für einen Dienst benötigt werden, stellen weitere wesentliche Merkmale von SOA dar. Die Dienste sind nur soweit miteinander verbunden, wie es für die Inanspruchnahme eines Dienstes durch einen anderen notwendig ist. SOA ist damit nicht vergleichbar mit Softwareanwendungen, die aus mehreren Komponenten bestehen und durch fest kodierte gegenseitige Aufrufe miteinander verbunden sind.

Anbieter und Konsument

Aus der Sicht des Geschäftsprozesses stellt der Dienst ein Angebot dar, das möglicherweise konkurrierend zu anderen Diensten am „Markt“ vorhanden ist und verwendet werden kann. Aus Sicht des Dienstes stellt der Geschäftsprozess den Konsumenten dar, der einen Dienst benötigt und den auswählt, der verfügbar ist und den Anforderungen entspricht.

Dieses Verhältnis von Anbieter (service provider) und Konsument (service consumer) ist auch eines der grundlegenden Elemente des „OASIS Reference Models for Service Oriented Architecture 1.0“ (www.oasis-open.org), mit dem ein Framework für SOA außerhalb jeder technischen Implementierung definiert wird. Dieses Framework fügt dem Modell des „service providers“ und „consumers“ noch die Begriffe „policy“ und „contract“ hinzu. Damit wird unterstrichen, dass das Verhältnis von einer genauen Spezifikation des Services einschließlich der allgemeinen Bedingungen und Einschränkungen, die für ihren Einsatz gelten (policy), und der gegenseitigen Vereinbarung, unter welchen Bedingungen der Service genutzt werden kann (contract), abhängt.

Wie werden nun die locker miteinander verbundenen Dienste zu einem Gesamtsystem integriert? Der einfachste Weg besteht darin, dass die Anwendungen, die den Geschäftsprozess in der IT darstellen, die Dienste dann aufrufen, wenn sie benötigt werden. Für überschaubare Systeme mit einer geringen Zahl von Anwendungen ist das sicherlich möglich und bietet den Vorteil, dass die Dienste ausgetauscht werden können, ohne dass die Anwendung selbst davon berührt wird – sofern der neue Dienst sich genau an die Anforderungen hält, die an ihn gestellt werden. Damit ist aber höchstens eine Teilmenge der Möglichkeiten einer SOA ausgenutzt worden. Da SOA ein Paradigma ist, das sich am Geschäftsprozess orientiert, ist es nur zu sinnvoll, dass dieser Geschäftsprozess selbst Bestandteil der SOA ist.

Das führt zu den Begriffen Orchestrierung und Choreografie. Zu einer vollständigen SOA gehören Komponenten, die definieren, für welche Aufgabe welcher Dienst verwendet wird und die zudem die Prozesssteuerung übernehmen, damit die Dienste in der richtigen Abfolge und unter den richtigen Bedingungen aufgerufen werden.

Begriffe im SOA Umfeld

Vor diesem Hintergrund tauchen einige Begriffe auf, die im SOA-Umfeld immer wieder genannt werden und häufig eher zur Verwirrung als zur Klärung beitragen. Begriffe wie Enterprise Service Bus (ESB) und Enterprise Application Integration (EAI) beschreiben, wie der Aufruf von Services durchgeführt werden kann. Dabei ist EAI mehr technisch auf die Lösung der Fragestellung ausgerichtet, wie Anwendungen bzw. Dienste mit unterschiedlichen Schnittstellen aufgerufen werden können. ESB ist dagegen stärker auf die Abbildung von Prozessen durch Dienste ausgerichtet.

Web Services und die damit zusammenhängenden Begriffe SOAP, Universal Description, Discovery and Integration (UDDI) und Web Services Description Language (WSDL) sind dagegen eine spezifische Implementation, die für SOA verwendet werden kann. Die Begriffe sind keinesfalls gleichbedeutend mit SOA. Systeme, die Web Services verwenden, sind auch nicht unbedingt eine Implementierung einer serviceorientierten Architektur.

Dennoch zeigt die Implementierung von SOA durch Web Services, welche Elemente wichtig sind. SOAP ist die auf XML beruhende Schnittstelle zu den Diensten. Dabei wird per XML sowohl der Funktionsaufruf als auch die dazu gehörenden Daten übergeben und die Antwort des Dienstes zurückgegeben. UDDI und WSDL sind die Implementierung der Registrierung von Diensten im Sinne einer Bekanntmachung des Angebotes. Dabei wird zum einen die Plattform geschaffen, in der solche Angebote abgegeben werden können, zum anderen aber auch festgelegt, wie das Angebot beschrieben werden soll. Was fehlt ist die Komponente der Prozesssteuerung. In diesen Bereich gehören Begriffe wie Business Process Management (BPM), Business Process Execution Language (BPEL) oder Business Process Modeling Notation (BPMN). Während BPM ein allgemeiner Oberbegriff ist, stellen die beiden anderen Begriffe konkrete Möglichkeiten der grafischen (BPMN) bzw. XML-basierten (BPEL) Darstellung von Prozessen dar.

Zusammenfassung

SOA ist kein technischer Standard, sondern ein Paradigma und somit auch keine kurzlebige Modeerscheinung. Das ist zugleich die Stärke und das Risiko von SOA. Vielleicht wird der Begriff der serviceorientierten Architektur nach einiger Zeit durch einen moderneren ersetzt. Das Paradigma der SOA, Geschäftsprozesse eng mit der Informationstechnologie zu verknüpfen und diese als notwendiges und wichtiges Mittel zur Ausführung der Prozesse zu sehen, wird für die Informationstechnologie erhalten bleiben und sich weiter entwickeln.

Zugleich ist die Tatsache, dass SOA nicht einfach zu kaufen ist, auch die Schwäche in vielen SOA-Projekten. Häufig werden SOA-fähige Produkte in der Hoffnung eingekauft, so eine serviceorientierte Architektur implementieren zu können, ohne die Geschäftsprozesse sorgfältig zu definieren und mit den vorhandenen oder neuen Anwendungen zu implementieren. SOA ist zunächst keine Frage der Technik und keine Aufgabe für IT-Spezialisten, sondern zu aller erst für die Fachabteilungen.