Was ist eine SOA und wie nützt sie Ihrem Unternehmen?

Die serviceorientierte Architektur (englisch service-oriented architecture, kurz SOA) möchte bestimmte IT-Dienste zentral für alle Abteilungen bereitstellen und flexibel kombinierbar machen. Dafür geht sie von den Geschäftsprozessen eines Unternehmens aus und betrachtet deren Abstraktionsebene. Beispielsweise ist der Dienst „Liefere die bestellte Ware an den Kunden“ auf einer hohen Abstraktionsebene angesiedelt. Er setzt sich aus mehreren Diensten auf niedrigeren Ebenen zusammen, wie „Verarbeite die Bestellung“, „Überprüfe den Zahlungseingang“ und „Organisiere den Transport“.

Viele Unternehmen bieten diese untergeordneten Bausteine nicht zentralisiert an, obwohl sie für mehr als eine Abteilung von Interesse sind. Beispielsweise kann es für mehrere Abteilungen wichtig sein zu wissen, ob die Ware bereits bezahlt wurde. Stattdessen wird für jeden Auftrag jedes Mal ein komplett neuer Prozess entwickelt. Das ist zeitaufwändig und verschlingt Kosten.

Die SOA-Denkweise schafft hier Abhilfe: Sie macht Dienste auf niedrigen Abstraktionsebenen als standardisierte Module für alle User verfügbar. Bei einem neuen Auftrag werden die benötigten Bausteine einfach kombiniert. Die Module sind also wiederverwendbar und müssen nur orchestriert werden. Das beschleunigt die Abwicklung und spart Ressourcen.

Serviceorientierte Architekturen können sowohl intern durch die eigene IT angeboten werden als auch extern durch einen Managed Service Anbieter. Im letzteren Fall erfolgt die Bereitstellung häufig über die Cloud. Die User greifen dann einfach via Webbrowser auf die Dienste zu. Auch Hybrid-Modelle sind weit verbreitet, in den einige Dienste intern und andere Dienste extern zur Verfügung stehen.

SOA ist ein Konzept, kein striktes Regelgebäude. Es gibt keine verbindlichen Kriterien, die eine IT-Architektur als serviceorientiert klassifizieren. Der Begriff „serviceorientierte Architektur“ wurde im Jahr 1996 durch das Marktforschungsunternehmen Gartner geprägt. Die Idee an sich ist aber wesentlich älter. Die sogenannte CORBA-Spezifikation bot schon Anfang der 90er-Jahre eine vergleichbare Serviceorientierung, konnte sich aber damals nicht durchsetzen.

Im Zentrum jeder SOA steht der zu leistende Service. Im Sinne einer SOA sollten Sie sich immer fragen: Welchen wiederverwendbaren Ablauf wollen wir gewährleisten? Welcher standardisierte Prozess soll für alle User geboten werden?

Diese Serviceorientierung bringt es mit sich, dass SOA-Dienste bevorzugt als „gekapselte“ Module behandelt werden. Es gibt keine Vererbungen zwischen Prozessen, die Abhängigkeiten zwischen den einzelnen Services werden mit Absicht gering gehalten.

Auf diese Weise können Module leicht miteinander kombiniert werden, die Agilität im Unternehmen steigt. Allerdings können sich so auch Redundanzen einstellen, weil die Dienste eben nicht maßgeschneidert, sondern normiert zur Verfügung gestellt werden. Dieser Trade-off wird bewusst in Kauf genommen.

SOAs unterscheiden zwischen hohen und niedrigen Abstraktionsebenen. Je näher sich ein Prozess am Kunden befindet, desto höher ist die Abstraktionsebene, zum Beispiel „Kreiere eine Marketingkampagne für B2B-Unternehmen“. Je weiter vom Kunden entfernt sich der Prozess abspielt, desto niedriger ist die Abstraktionsebene, beispielsweise „Erstelle ein Server-Backup“.

Das folgende Beispiel illustriert die Funktionsweise einer SOA. Ein Automobilhersteller ordert bei einem Metallbauer eine Charge Einspritzleitungen. „Liefere 5000 Einspritzleitungen bis Ende des Monats an den Kunden X“ wäre in diesem Fall der zu leistende Dienst auf der höchsten Abstraktionsebene.

Weil der Metallbauer bereits vor einiger Zeit auf eine serviceorientierte Architektur umgestellt hat, kann er diesen komplexen Service einfach aus bereits vorhandenen IT-Servicebausteinen zusammensetzen. Diese sind:

• Erfassung des neuen Auftrags
• Verfügbarkeitsprüfung: Ist die Ware auf Lager?
• Bonitätsprüfung, falls es sich um einen Neukunden handelt
• Kommissionierung, falls die Bestellung aus verschiedenen Bauteilen oder Typen besteht
• Versand der Ware
• Rechnungsstellung an den Kunden
• Kontrolle des Zahlungseingangs

Diese Service-Bausteine sind nicht an einen bestimmten Kunden oder ein spezielles Produkt geknüpft. Wenn bei der nächsten Bestellung eines Energieunternehmens 18 Präzisionsstahlrohre geordert werden, wird der Metallbauer wieder viele derselben Servicebausteine verwenden. Auf diese Weise können komplexe Dienste flexibel durch die Zusammenstellung von gekapselten Modulen orchestriert werden.

SOAs bieten gegenüber monolithischen Architekturstilen eine Reihe von Vorteilen.

Wenn Geschäftsprozesse für Ihre Kunden aus bereits existierenden Servicekomponenten zusammengestellt werden können, sparen Sie sich viel Zeit und Aufwand.

Eine gut eingestellte SOA kann Kosten reduzieren, weil sie mit wiederverwendbaren Modulen arbeitet. Ist ein Dienst einmal eingerichtet, schlägt er nicht mehr zu Buche.

Sind wichtige Dienste zentral verfügbar, verbessert sich auch das Verständnis Ihrer Mitarbeiter für die Geschäftsprozesse. Über Abteilungsgrenzen hinweg wird stärker als bisher das organisatorische Ganze gesehen. Das hilft Silodenken aufzubrechen.

Von der sehr flexiblen Struktur Ihrer Dienste profitieren auch Produkt- und Serviceinnovationen. In vielen Fällen kann für Neuentwicklungen auf bereits vorhandenen Diensten aufgebaut werden.

Durch den modularen Aufbau einer SOA lassen sich Fehler leichter verorten und beheben. In stärker verzahnten Strukturen fällt das schwerer, weil Fehler hier weitervererbt werden.

Die meisten serviceorientierten Architekturen verwenden bestimmte Standard-Komponenten wie ein Service-Repository oder einen Enterprise-Service-Bus. Im Folgenden erfahren Sie, wie genau diese Komponenten zusammenarbeiten.

Zentralisierte Dienste bilden das Herzstück einer SOA. So können Ihre User ein zentrales Tool nutzen, statt innerhalb jeder Abteilung und Anwendung eine separate Lösung kreieren zu müssen. Anbieter, die solche Services offerieren, bezeichnet man als Service-Provider. Sie können intern durch die eigene IT-Abteilung bereitgestellt werden, aber auch durch externe Managed Service Provider. Gerade die gemanagte Nutzung über die Cloud gewinnt in diesem Zusammenhang immer mehr an Bedeutung. Die Kommunikation zwischen den Diensten erfolgt unter Verwendung von SOAP, REST, XML-RPC und ähnlichen Protokollen.

Um auf die angebotenen Services zugreifen zu können, verwenden die User Client-Anwendungen, beispielsweise Webbrowser. Sie werden auch als Service-Consumer bezeichnet.

Zwischen Service und Client-Anwendung vermitteln die Service-Registry und die Service-Repository. Die Registry ist ein zentrales Verzeichnis aller wichtigen Metadaten zu den angebotenen Diensten. Sie fungiert ähnlich einem Katalog in einer Bibliothek. Auf diese Weise weiß die Client-Anwendung, dass der Service existiert, welche Schnittstelle benötigt wird und welche Anforderungen mit der Schnittstelle einhergehen.

Bei der Repository handelt es sich um ein Verzeichnis von wichtigen Dienstdaten, das sich vor allem an Entwickler und Business-Analysten wendet. Die Repository enthält Serviceverträge, die eine wohldefinierte Beschreibung der im Unternehmen genutzten Dienste bieten. Sie leistet außerdem die Versions- und Zugriffskontrolle und enthält Informationen zu Erweiterungen.

Auch wenn die Begriffe nicht immer klar getrennt verwendet werden, repräsentiert die Registry eher die technische Sicht und die Repository eher die fachliche Sicht. Die Registry liefert primär Daten zur Laufzeit, die Repository geht inhaltlich darüber hinaus.

Damit Client und Service erfolgreich miteinander agieren können, ist außerdem ein Enterprise-Service-Bus als Middleware notwendig. Er leistet die physische Kopplung zwischen Dienstnutzer und Dienstempfänger. Es handelt sich dabei um eine lose Kopplung über eine Vermittlerinstanz, im Gegensatz zu einer engen Kopplung mit einer Punkt-zu-Punkt-Verbindung.

Dem eigentlichen Message-Bus sind Adapter vor- und nachgeschaltet. Sie fungieren als „Übersetzer“. Denn in heterogenen Anwendungslandschaften sind die Dienstanbieter und -Nutzer nur selten direkt kompatibel – zu groß ist das Spektrum an Softwareplattformen, Kommunikationsprotokollen und Datenformaten. Die Adapter gleichen diese Unterschiede aus.

Um Serviceanbieter und Servicekonsumenten noch unabhängiger voneinander zu machen, kommen Mediatoren zum Einsatz. Statt des Original-Services erzeugen sie ein virtuelles Abbild des Dienstes, welches sie dem Konsumenten zur Verfügung stellen. Außerdem kümmern sich Mediatoren um das Load-Balancing. Dabei werden Anfragen je nach Auslastung an die verschiedenen Instanzen eines Services weitergeroutet, ohne dass der Konsument das mitbekommt.

Geschäftsprozesse lassen sich besonders einfach via WS-BPEL orchestrieren. WS-BPEL steht für „Web Service Business Process Execution Language“. Der Vorteil: Die Dienste können grafisch als Diagramm konfiguriert werden, die dann direkt ausführbar sind. Klassische Programmiersprachen wie C# oder Java werden nicht benötigt. Das erleichtert nicht nur Ihren Entwicklern die Arbeit, sondern vereinfacht auch die Kooperation mit Kollegen ohne Programmierkenntnisse. Als Laufzeitumgebung nutzt BPEL eine Business-Process-Engine.

Typischerweise verfügen SOAs über eine integrierte Entwicklungsumgebung (IDE). Oft kommen dafür Eclipse-basierte Umgebungen wie die von Mule oder webMethods zum Einsatz. So kann Ihr Entwickler bequem auf alle Komponenten der SOA-Suite zugreifen. Neue Dienste können in der IDE leicht erstellt, getestet und publiziert werden.

Vervollständigt wird eine SOA-Suite durch Frameworks und Konnektoren. Mithilfe der Frameworks lassen sich die oben genannten Service-Adapter oder auch Web-Anwendungen erstellen. Konnektoren verbinden Ihre Suite mit Business-Anwendungen wie Salesforce oder SAP. Außerdem erlauben sie den Zugriff auf Host-Programme.