Wenn es um die Gestaltung unternehmensweiter Anwendungslandschaften geht, ist "Serviceorientierte Architektur", kurz SOA, das derzeit meist verwendete Schlagwort. Dieses Schlagwort wird häufig gleichgesetzt mit Begriffen, wie z. B. Web- Services oder Enterprise Application Integration (EAI), was allerdings nicht ganz korrekt ist. Aus diesem Grund erläutert dieser Artikel was unter SOA zu verstehen ist und gibt Antworten auf die häufig in Zusammenhang mit SOA gestellten Fragen.

Warum eigentlich SOA?

Betrachtet man die Entwicklung der Informationstechnologie der letzten Jahre, so stellt man einen Trend zu immer abstrakter werdenden Programmiersprachen fest. Ziel der Abstraktion ist dabei die Beherrschung der ständig zunehmenden Komplexität der IT-Landschaften. Die letzte Abstraktionsstufe nach den prozeduralen und objektorientierten Paradigmen stellen Web-Services und serviceorientierte Architekturen dar.

Was sind die wesentlichen Merkmale einer SOA?

SOA kann als ein abstraktes Konzept einer Software-Architektur bezeichnet werden, bei dem im Mittelpunkt fachlich getriebene und modulare Services bzw. Dienste stehen. Dabei spielen folgende Instanzen eine wesentliche Rolle:

• Anbieter
• Verzeichnis
• Konsument

Die Hauptaufgabe eines Anbieters ist die Erstellung, die Beschreibung und die Veröffentlichung seiner Dienste in einem Verzeichnis. Der Konsument dagegen durchsucht das Verzeichnis des Anbieters und wählt einen gewünschten Dienst aus. Danach findet eine dynamische Anbindung des Konsumenten an den Anbieter statt und schließlich greift der Konsument auff die Methoden des Anbieters zu.

Das Besondere an dem hier beschriebenen Verfahren ist die dynamische Bindung und die daraus resultierende, so genannte lose Kopplung. Mit einer losen Kopplung ist eine Bindung zur Laufzeit gemeint, bei der im Gegensatz zur Bindung zum Übersetzungszeitpunkt nicht bekannt ist, wie die Aufrufabhängigkeiten sind.

Ein weiteres, wesentliches Merkmal einer SOA ist die flexible Ausrichtung der IT auf die Geschäftsprozesse. Dabei werden die Geschäftsprozesse als ein Verbund von verschiedenen Services betrachtet. Ändert sich ein Prozess, so kann durch Neukombination bzw. Orchestrierung der entsprechenden Services sehr schnell und flexibel auf die geänderten Prozesse reagiert werden. Dies ist möglich durch die geringeren technischen Abhängigkeiten der Services untereinander.

Kann man SOA kaufen?

Durch die Versprechungen vieler Softwarehersteller kann schnell der Eindruck entstehen, dass mit dem Kauf einer SOA-Lösung gleichzeitig auch eine serviceorientierte Architektur eingekauft wird und die Einführung der SOA im Unternehmen nicht allzu weit entfernt sei.

In Wirklichkeit ist ein SOA-Produkt, wie z. B. ESB oder BPEL-Engine, kein Garant für die erfolgreiche Einführung von SOA in einem Unternehmen. Der Grund liegt hier in der Tatsache, dass SOA kein Produkt, sondern vielmehr ein Architekturkonzept bzw. ein Paradigma ist, nach dem im optimalen Fall die gesamte IT-Landschaft erst ausgerichtet werden muss.

Ist SOA nur ein alter Wein in neuen Schläuchen?

Beim genauen Betrachten von SOA stellt man fest, dass die Ideen, die SOA ausmachen, wie z. B. lose Kopplung, Wiederverwendung, Kapselung oder verteilte Entwicklung, nicht vollkommen neu sind. Das Neue an SOA ist lediglich die Ganzheitlichkeit des Konzeptes und die unternehmensweite bzw. unternehmensübergreifende Sichtweise.

Auf der technologischen Ebene sind in der letzten Zeit zwar einige SOA-Produkte entstanden. In den meisten Fällen handelt es sich dabei allerdings um Weiterentwicklungen bereits vorhandener Produkte. Aufgrund der Tatsache, dass SOA momentan ein Modewort ist, können derartige Produkte derzeit gut unter der Marke "SOA" verkauft werden. Eine gesunde Skepsis ist hier also sicher angebracht.

Abb. 1: Das "Hub and Spoke"-Modell von EAI.

Ist SOA ein neues EAI?

Enterprise Application Integration (EAI) ist eine Technologie für die Integration von Anwendungssystemen (Applications). Dabei liegt der Schwerpunkt von EAI auf der technischen Definition von Applikationsschnittstellen mit dem Ziel, die Unternehmenslandschaften miteinander zu verbinden.

Bei einer SOA stehen dagegen fachliche Services im Vordergrund, die in der Regel anwendungsübergreifend agieren. Demzufolge sind die Schnittstellen bei einer SOA fachlich orientiert und bei EAI eher technischer Natur.

Außerdem verfolgt EAI für den Austausch von Nachrichten einen so genannten "Hub and Spoke"-Ansatz. Bei diesem Modell steht eine zentrale Middleware-Komponente im Mittelpunkt, über die der komplette Nachrichtenaustausch stattfindet (siehe Abbildung 1). SOA dagegen richtet sich nach einem verteilten Konzept, bei dem eine dynamische Bindung im Vordergrund steht (siehe Abbildung 2).

Aus den genannten Gründen kann SOA als ein Architekturparadigma nicht mit einer Integrationstechnologie wie EAI verglichen werden.

Sind Web-Services für SOA zwingend notwendig?

Abb. 2: Das verteilte SOA-Konzept.

Die Verwendung von Web-Services und deren assoziierten Technologien wird häufig mit dem Begriff SOA gleichgesetzt. Dabei sind Web- Services eine mögliche Implementierungstechnologie unter anderen, wie CORBA oder Enterprise Java Beans (EJB), mit der SOA realisiert werden kann.

Da Web-Services allerdings über einige standardisierte Protokolle zur technologie- und unternehmensübergreifenden Kommunikation verfügen, eignen sich diese besonders gut für die Implementierung von SOA.

Was hat SOA mit einem Städtebebauungsplan gemeinsam?

Auf der Ebene der Städtebebauung werden Stadtteile wie Industriegebiete, Wohngebiete oder die Kernstadt und die wesentlichen Verbindungen zwischen diesen Gebieten - wie Straßen oder Brücken - festgelegt. Damit werden die Vorgaben und der grobe Rahmen für die Bebauung einer Stadt festgelegt. Die Architektur und das Innenleben eines einzelnen Hauses werden auf dieser Ebene vernachlässigt und einem Hausarchitekten überlassen.

Überträgt man diesen Sachverhalt auf die IT, so stellt man einige Gemeinsamkeiten zwischen der Städtebebauung und der service- orientierten Architektur fest. Auch bei der SOA bewegt man sich im optimalen Fall auf der groben Unternehmensebene und legt den Rahmen bzw. die Service-Domänen für die unternehmensweite SOA fest (siehe Abbildung 3). Mit einer Service-Domäne ist ein so genannter Container gemeint, der logisch eng zusammengehörende Funktionalitäten bzw. Services bündelt.

Das Innenleben bzw. die interne Implementierung eines Services überlässt man in aller Regel einem technischen Software-Architekten, der wie ein Hausarchitekt agiert.

Abb. 3: SOA als Architektur für unternehmensweiten Einsatz.

Wie sieht es mit SOA und der Performance aus?

Des Weiteren lässt sich sagen, dass in einer serviceorientierten Architekturlandschaft die Performance zu einer echten Herausforderung werden kann. Da SOA häufig mit Web-Services und damit mit dem Datenaustauschformat XML realisiert wird, ist hier aufgrund der XML- Tags innerhalb der XML-Dokumente mit einem erhöhten Datenumfang und demzufolge mit längeren Verarbeitungszeiten zu rechnen.

Darüber hinaus müssen beim Versenden und Empfangen von Objektdaten in einer SOA zusätzliche Verarbeitungsschritte durchgeführt werden (Marshalling/Unmarshalling). Der Grund liegt darin, dass XML im Gegensatz zu anderen binären Protokollen, wie z. B. CORBA oder RMI, in aller Regel nur Textzeichen enthält. Beim Versenden müssen die binären Objektdaten demzufolge zuerst in eine Textdarstellung überführt und beim Empfangen der textbasierten Objektdaten wieder in eine binäre Form transferiert werden.

Resümee

Die wesentlichen Vorteile einer SOA können erst dann erzielt werden, wenn SOA unternehmensweit eingesetzt wird. Bis dahin ist es allerdings ein weiter Weg, der in der Anfangsphase hohe Investitionen zur folge hat. Diese Investi-tionen machen sich erst dann wieder bezahlt, wenn nach der SOA-Ausrichtung neue Anforderungen schneller, effizienter und vor allem kostengünstiger realisiert werden können.

Zudem kann man sagen, dass das primäre Ziel von SOA nicht die Minimierung der Komplexität von Geschäftsprozessen und der IT-Landschaft ist, sondern vielmehr die Beherrschung der Komplexität.

Da auch auf der organisatorischen Ebene eines Unternehmens einige Herausforderungen bei der Einführung einer SOA zu meistern sind, werden wir uns im nächsten Teil dieser SOA-Reihe mit der serviceorientierten Organisation (SOA-Governance) beschäftigen.

Markus Fiegler (info@ordix.de).