Was ist SOA (Service-Oriented Architecture)?

SOA (Service-Oriented Architecture) ist ein Design, bei dem Softwarekomponenten wiederverwendet werden können. Dies wird mithilfe von Service-Benutzeroberflächen ermöglicht, die im Netzwerk eine gemeinsame Kommunikationssprache verwenden. 

Services sind eigenständige Softwarefunktionseinheiten oder Funktionssets, die für die Ausführung spezifischer Aufgaben vorgesehen sind, wie der Abruf bestimmter Informationen oder die Durchführung eines Vorgangs. Ein Service enthält die Code- und Datenintegrationen, die für die Ausführung einer einzelnen vollständigen Geschäftsfunktion benötigt werden. Er wird über Remote-Zugriff aufgerufen und kann individuell bearbeitet oder aktualisiert werden.

Mit anderen Worten, eine SOA integriert Softwarekomponenten, die getrennt bereitgestellt und verwaltet werden, und ermöglicht ihnen, über verschiedene Systeme hinweg als Software-Anwendungen zu kommunizieren und zu funktionieren.

Bevor die SOA Ende der 1990er in Mode kam, war es noch sehr kompliziert, Anwendungen mit Services in einem anderen System zu verbinden. Bei der Punkt-zu-Punkt-Integration mussten Verbindungen, Routing, Übersetzung von Datenmodellen etc. von den Entwicklern für jedes Projekt neu erstellt werden. Diese Modelle waren als „monolithisch“ bekannt, weil der Code der gesamten App in eine einzelne Bereitstellung integriert wurde. Wenn ein Aspekt der Anwendung nicht funktionierte, musste das gesamte Konstrukt zeitweilig offline genommen, repariert und als neue Version wieder bereitgestellt werden. 

Mit der SOA müssen Entwickler die gesamte Integration nicht mehr komplett wiederholen. Grund ist, dass sie damit Services mithilfe standardmäßiger Netzwerkprotokolle (wie SOAP, JSON, ActiveMQ oder Apache Thrift) bereitstellen und so Anfragen senden oder auf Daten zugreifen können. Stattdessen werden als ESBs (Enterprise Service Buses) bekannte Patterns eingesetzt, die die Integration zwischen zentralisierten Komponenten und Backend-Systemen übernehmen und sie als Service-Benutzeroberflächen verfügbar machen. Dadurch können Entwickler vorhandene Funktionen wiederverwenden, anstatt sie neu zu erstellen.

In einer SOA kommunizieren Services über ein System der „losen Kopplung“. Dabei werden Komponenten (oder „Elemente“) in einem System oder Netzwerk verknüpft, damit sie Daten weiterleiten oder geschäftliche Prozesse koordinieren können, wobei die Abhängigkeiten zwischen ihnen reduziert werden. Auf diese Weise entsteht faktisch eine neue App.  

• Schnellere Markteinführung und größere Flexibilität: Die Wiederverwendbarkeit von Services erleichtert und beschleunigt die Entwicklung von Anwendungen. Im Gegensatz zum monolithischen Ansatz müssen Entwickler hier nicht jedes Mal wieder ganz von vorne beginnen. 
• Einsatz von Legacy-Infrastrukturen auf neuen Märkten: Eine SOA macht es den Entwicklern leichter, Funktionen von einer Plattform oder Umgebung zu skalieren und auf andere Plattformen bzw. Umgebungen auszuweiten. 
• Geringere Kosten durch mehr Agilität und eine effizientere Entwicklung
• Einfache Wartung: Da alle Services voneinander unabhängig sind, können sie ohne Beeinträchtigung anderer Services modifiziert und aktualisiert werden. 
• Skalierbarkeit: Da Services in einer SOA auf mehreren Services, Plattformen und Programmiersprachen ausgeführt werden können, wird die Skalierbarkeit deutlich gesteigert. Dazu nutzt eine SOA ein standardisiertes Kommunikationsprotokoll, mit dem Interaktionen zwischen Clients und Services reduziert werden können. Auf diese Weise lassen sich Apps unter weniger Druck und mit mehr Benutzerfreundlichkeit skalieren. 
• Höhere Zuverlässigkeit: Da das Debugging kleiner Services einfacher ist als das von umfangreichem Code, lassen sich in einer SOA zuverlässigere Apps erstellen.
• Umfassende Verfügbarkeit: SOA-Einrichtungen stehen allen Personen zur Verfügung.

Die Bausteine einer serviceorientierten Architektur bestehen aus drei Rollen. 

1. Service-Anbieter

   Ein Service-Anbieter entwickelt Webservices und liefert sie an eine Service-Registry. Der Service-Anbieter ist für die Nutzungsbedingungen des Service verantwortlich.

2. Service-Broker oder Service-Registry

   Ein Service-Broker oder eine Service-Registry ist verantwortlich dafür, Servicenehmern Informationen über den Service zu liefern. Ein Broker kann privat oder öffentlich sein. 

3. Servicenehmer oder Servicenutzer

   Servicenehmer können einen Service in einem Service-Broker oder einer Service-Registry suchen und dann eine Verbindung mit dem Service-Anbieter herstellen, um den Service zu empfangen.

Das mit der SOA eingeführte Service-Konzept hat sich mittlerweile zu einer zentralen Komponente des modernen Cloud Computings und der Virtualisierung in Technologien wie Middleware und Microservices entwickelt. 

Wegen ihrer Ähnlichkeit werden SOA und Microservice-Architektur oft verwechselt. Ein Hauptunterschied zwischen den beiden ist ihr Umfang: Eine SOA ist ein unternehmensweiter Ansatz der Architektur, während es sich bei Microservices um eine Implementierungsstrategie für die Teams in der Anwendungsentwicklung handelt. 

Außerdem kommunizieren beide unterschiedlich: SOA verwendet ESBs, während sich Microservices zustandslos und über APIs austauschen, die von der Programmiersprache unabhängig sind. Durch diese Unabhängigkeit von der Programmiersprache können die Dev-Teams für ihre Arbeit die Tools auswählen, mit denen sie am liebsten arbeiten. So gesehen sind Microservices viel flexibler einsetzbar.

SOA wird häufig auch mit SaaS (Software-as-a-Service) verwechselt. SaaS ist eine Form des Cloud Computings, bei der dem Nutzer eine Cloud-Anwendung mit all ihren zugrunde liegenden IT-Infrastrukturen und -Plattformen zur Verfügung gestellt wird. Webservices können in SOA durch Service-Anbieter als SaaS-Anwendungen geliefert werden. In der Regel verwaltet ein Cloud-Service-Anbieter (wie AWS, Azure oder IBM Cloud) die Cloud-Umgebung, in der die SaaS-Anwendung gehostet wird. 

Die Nutzer interagieren mit der Software über einen Webbrowser auf dem Computer oder Mobilgerät. Sie können auch APIs wie REST oder SOAP verwenden, um die Software mit anderen Funktionen zu verbinden.

Aufgrund der Fortschritte in der Container-Technologie bilden Microservices mittlerweile die Basis für cloudnative Anwendungen. Die Microservices sind lose gekoppelt, werden in Linux-Containern bereitgestellt und zum Message Routing über APIs oder ein Mesh-Netzwerk verbunden. 

Jedes Element implementiert eine Geschäftsfunktion und wird von kleinen DevOps-Teams mithilfe von Workflows wie CI/CD (Continuous Integration/Continuous Deployment) unabhängig erstellt. Dies wiederum ermöglicht eine schnellere Softwareentwicklung, automatische Bereitstellung sowie regelmäßige Updates – ohne die Beschränkungen monolithischer Entwicklungszyklen. 

Dank seines Open Source-Portfolios, darunter Red Hat^® Enterprise Linux^® und Red Hat OpenShift, ist Red Hat ein guter Partner für Unternehmen, die ihre Infrastruktur und Anwendungsentwicklung in die schnelle und adaptive Umgebung des Cloud Computings migrieren möchten. Dies geschieht sukzessive, während bestehende Infrastrukturen weiter voll genutzt werden können.