Die serviceorientierte Architektur (SOA) steht für einen besonders flexiblen Architekturstil von IT-Infrastrukturen. Dabei werden Dienste zentral bereitgestellt und nach Bedarf kombiniert. Auf diese Weise können Sie Prozesse schneller abwickeln und Kosten einsparen. Dieser Ratgeber erläutert, wie genau eine SOA für Unternehmen funktioniert.

SOA-Definition

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.

Was ist SOA?

Der Servicegedanke – die Basis jeder SOA

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.

Die Einteilung in Abstraktionsebenen

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“.

Für Prozesse auf hohen Abstraktionsebenen gilt:

  • Sie bestehen aus mehreren Prozessen auf niedrigen Abstraktionsebenen.
  • Sie eignen sich nicht für eine zentrale Bereitstellung als Modul, weil der entsprechende Dienst nicht parallel von mehreren Abteilungen genutzt wird.

Für Prozesse auf niedrigen Abstraktionsebenen gilt:

  • Sie können in der Regel nicht in weitere Dienste zerlegt werden, sondern bilden selbst die kleinstmögliche Einheit.
  • Sie eignen sich für eine zentrale Bereitstellung als Modul, weil mehrere Abteilungen ein Interesse an der Nutzung haben.

Praxisbeispiel Metallbau

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.

Die Vorteile einer serviceorientierten Architektur

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

Zeitersparnis

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

Kostenersparnis

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.

Wissensvorsprung durch Zentralisierung

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.

Neuentwicklungen werden begünstigt

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.

Fehlerbehebung wird erleichtert

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.

Wie eine SOA aufgebaut ist

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.

Services bilden den Ausgangspunkt

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.

Client-Anwendungen verschaffen Zugriff

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

Registry und Repository versammeln wichtige Daten

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.

Der Enterprise-Service-Bus verbindet die Elemente

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.

Mediatoren erzeugen virtuelle Abbilder

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.

Virtuelles Abbild eines Dienstes

BPEL erleichtert die Konfiguration

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.

Die IDE unterstützt Ihre Entwickler

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.

Frameworks und Konnektoren runden die SOA ab

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.

Managed Services Leitfaden Vorderseite

KOSTENLOSER LEITFADEN

3 Schritte hin zu einer serviceorientieren IT

Der Leitfaden hilft Ihnen eine passende Vorgehensweise für die Definition von IT-Services und die Aufstellung Ihrer IT als interner Service Provider zu entwickeln.

Jetzt herunterladen