Definition Was ist eine Serviceorientierte Architektur (SOA)?

Anbieter zum Thema

Paessler AG

Cradlepoint GmbH

Southern Tech GmbH

Die Serviceorientierte Architektur (SOA) ist ein Architekturansatz der IT für verteilte Systeme und Services. SOA strukturiert und modularisiert die verschiedenen Services der IT-Systeme und richtet sie an abstrahierten Geschäftsprozessen aus. Um einen Service einer höheren Abstraktionsebene bereitzustellen, werden Services niedrigerer Abstraktionsebenen zusammengefasst und miteinander kombiniert. Es ergibt sich ein flexibles Architekturmuster mit wiederverwendbaren Services.

SOA ist das Akronym für Service-Oriented Architecture. Die deutsche Übersetzung lautet Serviceorientierte Architektur. Manchmal wird auch der Begriff diensteorientierte Architektur verwendet. Es handelt sich um einen Begriff, der erstmals im Jahr 1996 vom Marktforschungsunternehmen Gartner verwendet wurde. Zu dieser Zeit gab es keine allgemein anerkannte Definition für SOA. Erst später entstanden entsprechende Definitionen und Modelle für dieses Architekturkonzept, wie das OASIS Reference Model for Service-Oriented Architecture (SOA-RM) aus dem Jahr 2006.

Die Serviceorientierte Architektur ist ein Architekturansatz der Informationstechnik für verteilte Systeme. Verteilte und von verschiedenen Eigentümern verantwortete Funktionalitäten und Services werden mit SOA strukturiert und nutzbar gemacht. Die Strukturierung ist an Geschäftsprozessen ausgerichtet und kennt verschiedene Abstraktionsebenen. Um einen Service einer höheren Abstraktionsebene zu schaffen, werden Services niedrigerer Abstraktionsebenen zusammengefasst und kombiniert.

SOA führt technische Dienste der verschiedenen IT-Systeme zusammen, orchestriert sie und erfüllt dadurch Aufgaben übergeordneter Geschäftsprozesse. Es ergibt sich ein flexibles Architekturmuster mit wiederverwendbaren Services. Technisch werden die Services über Netzwerke oder über die Cloud und definierte Schnittstellen angesprochen. Für die Kommunikation kommen Konzepte und Protokolle wie REST, SOAP, XML-RPC und andere zum Einsatz. Die Schnittstellen verbergen nach außen die Art und Weise der Implementierung der Services und ihrer Leistungserbringung.

Komponenten und Funktionsweise einer Serviceorientierten Architektur

Eine Serviceorientierte Architektur besteht aus den verschiedenen Services und den Service-Konsumenten. Service-Konsumenten übergeben den Services Informationen. Die Services verarbeiten diese Informationen und liefern den Konsumenten ein Ergebnis. Jeder Service ist für eine bestimmte Aufgabe oder Funktion vorgesehen. Ausführung und Logik sind über die Service-Implementierung realisiert.

Services werden von einem Service-Anbieter erstellt, implementiert und verwaltet. In einer Art Service-Vertrag sind die Voraussetzungen für die Inanspruchnahme und der Leistungsumfang eines Services beschrieben. Der Vertrag legt quasi die Regeln für die Interaktion der Konsumenten und Service-Anbieter fest. Service-Schnittstellen definieren, wie Services angesprochen werden und wie sie Informationen untereinander oder mit Konsumenten austauschen. Eine weitere Komponente einer Serviceorientierten Architektur ist das Service-Register. Es handelt sich bei diesem Register um ein über das Netzwerk ansprechbares Verzeichnis aller verfügbaren Services inklusive Informationen über Service-Anbieter und Beschreibungen der Services.

Die Kommunikation der Services über das Netzwerk findet über festgelegte Schnittstellen und Protokolle statt. Standardprotokolle und Schnittstellen der Serviceorientierten Architektur sind zum Beispiel Simple Object Access Protocol (SOAP), RESTful APIs, XML-RPC (Extensible Markup Language Remote Procedure Call) oder Java Message Service (JMS). Für die physische Kopplung und die Kommunikation zwischen Services und Service-Konsumenten kommt der Enterprise Service Bus (ESB) zum Einsatz. Der ESB ist ein softwarebasierter Middleware-Service, der Serviceanfragen entgegennimmt und sie an die Services weiterleitet. Technische Unterschiede verschiedener Softwareplattformen, Kommunikationsprotokolle oder Datenformate vermag der ESB auszugleichen.

Ein Grundprinzip der SOA-Implementierung ist die Interoperabilität der Services. Nach außen erscheinen die Services wie eine Blackbox. Services sind unabhängig von der zugrundeliegenden Implementierungsplattform oder -programmiersprache ansprechbar und zeigen untereinander keine direkten Wechselwirkungen. Änderungen eines Services wirken sich nicht auf andere Komponenten aus. Die Services sind untereinander lose gekoppelt und verhalten sich möglichst zustandslos. Sie sind autark und nur eingeschränkt von externen Ressourcen abhängig. Konsumenten benötigen keine Informationen über die genaue Art der Implementierung, sondern erhalten Beschreibungen, was der Service leistet und wie er zu benutzen ist. Die Granularität eines Services ist in der Regel so gestaltet, dass er genau eine konkrete Geschäftsfunktion erfüllt. Komplexere Vorgänge mit mehreren Funktionen werden durch das Zusammensetzen mehrerer Services realisiert.

Abgrenzung zwischen Serviceorientierter Architektur und Microservices

Microservices sind eine Art Weiterentwicklung von SOA. Microservices sind kleine, unabhängige Services, die jeweils nur auf eine einzige Aufgabe spezialisiert sind und über APIs angesprochen werden. Von den Services einer Serviceorientierten Architektur unterscheiden sie sich vor allem hinsichtlich ihrer Granularität, der Art der Implementierung und ihrem Leistungsumfang.

Während bei SOA die Services an Geschäftsprozessen ausgerichtet und recht grobkörnig sind, ist ein Microservice auf eine einzige Aufgabe fokussiert. Seine Funktionalität hat keine weiteren Abhängigkeiten. Die Art der Implementierung unterscheidet sich darin, dass Microservices noch stärker gekapselt und unabhängiger bereitzustellen sind. Sie werden in virtualisierten Containern implementiert und sind von zugrundeliegenden Plattformen völlig entkoppelt. Zudem benötigen sie keinen Enterprise Service Bus (ESB) als Middleware. Der stark fokussierte Leistungsumfang eines Microservices wirkt sich auch auf die Entwicklerteams aus. Ein Entwickler eines Microservices benötigt im Vergleich zu einem Service-Entwickler einer Serviceorientierten Architektur weniger übergreifendes Verständnis der Geschäftsprozesse. Microservices sind schneller und agiler zu entwickeln und lassen sich einfacher skalieren.

Beispiel für die Abbildung eines Geschäftsprozesses in einer Serviceorientierten Architektur

Um das SOA-Prinzip besser zu verstehen, im Folgenden ein einfaches Beispiel der Abbildung eines Geschäftsprozesses in einer Serviceorientierten Architektur. Es wird die Bestellung eines Kunden bei einem Online-Händler betrachtet.

Der Bestellprozess lässt sich in verschiedene Teilprozesse aufteilen. Teilprozesse einer Bestellung sind die Erfassung der Kundendaten, die Produktbestellung, die Verfügbarkeitsprüfung, die Rechnungsstellung, die Bezahlung, die Kommissionierung und der Versand. Für jeden Teilprozess wird ein Service einer bestimmten Abstraktionsebene bereitgestellt. Dieser Service kann sich wiederum aus mehreren Services einer anderen Abstraktionsebene zusammensetzen.

Beispielsweise umfasst die Bezahlung weitere abhängige Services wie Bonitätsprüfung, Online-Zahlung, Bezahlung auf Rechnung, Prüfung des Zahlungseingangs oder die Verzweigung zum Mahnwesen. Um einen kompletten Bestellprozess abzuwickeln, werden mehrere Services sequenziell oder parallel durchlaufen. So startet die Kommissionierung unter Umständen schon, obwohl noch kein Zahlungseingang erfolgt ist. Jeder Service kann prinzipiell mit verschiedenen Programmiersprachen oder auf unterschiedlichen Umgebungen implementiert sein.

Die einzelnen Services kommunizieren über den Enterprise Service Bus und definierte Protokolle und Schnittstellen. Die Services erwarten bestimmte Eingabeinformationen und liefern definierte Ergebnisse. Wie ihr Programmcode aussieht und wie sie genau implementiert sind, ist für die Nutzung der Services unerheblich. Einzelne Services lassen sich unabhängig voneinander verändern oder anpassen. Soll eine Zahlungsmethode durch eine andere ersetzt werden, ist nur ein Service für die neue Methode bereitzustellen. Auf die anderen Services des Geschäftsprozesses der Online-Bestellung hat das keinen Einfluss. Services externer Dienstleister wie die Bonitätsprüfung lassen sich ebenfalls problemlos in den Gesamtprozess einbinden.

(ID:49209121)