Quelltext der Seite Service-Oriented Architecture (SOA)

= Service-Oriented Architecture (SOA) =

Die '''Service-Oriented Architecture''' (kurz: '''SOA''', deutsch: '''dienstorientierte Architektur''') ist ein **Architekturstil**, der Softwareanwendungen als eine Sammlung **lose gekoppelter, wiederverwendbarer und interoperabler Dienste** beschreibt.  
Jeder Dienst stellt eine **klar definierte Schnittstelle** bereit und kann unabhängig von anderen Diensten genutzt werden.

SOA bildet die **konzeptionelle Grundlage moderner Architekturen** wie der [[Microservices-Architektur]].

== Grundidee ==
In einer SOA werden Anwendungen nicht als monolithische Systeme entwickelt, sondern als eine **Sammlung unabhängiger Dienste**, die über standardisierte Protokolle miteinander kommunizieren.  
Ein Dienst kann dabei eine Funktion, ein Geschäftsprozess oder eine Datenquelle repräsentieren.

<pre>
+-------------------+
|   Client-Anfrage  |
+-------------------+
          |
          v
+-------------------+     +-------------------+     +-------------------+
|  Service A (Auth) | --> |  Service B (Data) | --> |  Service C (Mail) |
+-------------------+     +-------------------+     +-------------------+
</pre>

== Merkmale ==
* **Lose Kopplung:** Dienste sind unabhängig voneinander.  
* **Wiederverwendbarkeit:** Dienste können in verschiedenen Anwendungen verwendet werden.  
* **Standardisierte Schnittstellen:** Nutzung offener Protokolle (z. B. SOAP, REST).  
* **Interoperabilität:** Kommunikation zwischen verschiedenen Plattformen und Programmiersprachen.  
* **Service-Komposition:** Komplexe Prozesse werden aus mehreren Diensten zusammengesetzt.  
* **Verteilte Architektur:** Dienste laufen oft auf verschiedenen Systemen oder Servern.

== Komponenten einer SOA ==
{| class="wikitable"
! Komponente !! Beschreibung
|-
| '''Service Provider''' || Stellt den Dienst bereit und beschreibt dessen Schnittstelle (z. B. in WSDL).
|-
| '''Service Consumer''' || Nutzt den angebotenen Dienst über eine definierte Schnittstelle.
|-
| '''Service Registry''' || Zentrales Verzeichnis, in dem Dienste veröffentlicht und gefunden werden können (z. B. UDDI).
|-
| '''Service Contract''' || Formale Beschreibung der verfügbaren Operationen, Eingaben und Ausgaben.
|-
| '''Enterprise Service Bus (ESB)''' || Kommunikationsschicht für Routing, Transformation und Integration der Dienste.
|}

== Funktionsweise ==
1. Ein **Dienstanbieter (Service Provider)** registriert seinen Dienst in einer **Service Registry**.  
2. Ein **Dienstnutzer (Service Consumer)** sucht den passenden Dienst.  
3. Der Consumer ruft den Dienst über dessen definierte Schnittstelle auf (z. B. SOAP- oder REST-API).  
4. Der Dienst wird ausgeführt und das Ergebnis zurückgegeben.

<pre>
Client → Service Registry → Service Provider → Antwort an Client
</pre>

== Technologien und Standards ==
{| class="wikitable"
! Technologie / Standard !! Beschreibung
|-
| '''SOAP (Simple Object Access Protocol)''' || XML-basiertes Protokoll für strukturierte Datenübertragung.
|-
| '''WSDL (Web Services Description Language)''' || XML-basierte Beschreibungssprache für Webservices.
|-
| '''UDDI (Universal Description, Discovery and Integration)''' || Standard für Service-Registrierung und -Entdeckung.
|-
| '''REST (Representational State Transfer)''' || Leichtgewichtiges Webservice-Prinzip über HTTP.
|-
| '''ESB (Enterprise Service Bus)''' || Middleware zur Integration, Nachrichtenweiterleitung und Transformation.
|}

== Beispielhafte SOA-Kommunikation ==
<syntaxhighlight lang="text">
1. Ein Client sucht im Service-Registry nach dem „Kundenservice“.
2. Registry liefert die WSDL-Adresse des Dienstes zurück.
3. Client ruft den Dienst via SOAP oder REST auf.
4. Der Dienst verarbeitet die Anfrage und liefert die Antwort.
</syntaxhighlight>

== Vorteile ==
* **Wiederverwendbarkeit** von Diensten über verschiedene Anwendungen hinweg  
* **Plattformunabhängigkeit** durch standardisierte Schnittstellen  
* **Bessere Wartbarkeit** durch klare Diensttrennung  
* **Skalierbarkeit** durch verteilte Bereitstellung  
* **Integration** älterer Systeme (Legacy-Systeme) durch standardisierte Protokolle  

== Nachteile ==
* **Hoher Initialaufwand** für Design und Infrastruktur (z. B. ESB)  
* **Komplexe Verwaltung** vieler Dienste  
* **Leistungsprobleme** durch XML-Overhead (SOAP)  
* **Schwierigere Fehlersuche** durch verteilte Kommunikation  
* **Abhängigkeit von zentralen Komponenten** wie Service Registry oder ESB  

== Beispielhafte Einsatzgebiete ==
* Unternehmensanwendungen (ERP-, CRM-, Buchungssysteme)  
* E-Government-Systeme  
* Zahlungsabwicklung und Online-Banking  
* Integration heterogener IT-Landschaften  
* Service-APIs in großen Organisationen

== Vergleich zu Microservices ==
{| class="wikitable"
! Merkmal !! SOA !! Microservices
|-
| Architekturgröße || Unternehmensweit (Enterprise-Level) || Anwendungsspezifisch (App-Level)
|-
| Kommunikation || Über ESB (zentrale Vermittlung) || Direkt oder über API Gateway
|-
| Datenhaltung || Gemeinsame Datenbanken möglich || Datenbank pro Service
|-
| Kopplung || Lose, aber oft zentralisiert || Sehr lose, dezentral
|-
| Technologie || Häufig SOAP/WSDL || REST, gRPC, Messaging
|-
| Deployment || Schwergewichtig (Server, ESB) || Leichtgewichtig (Container)
|-
| Beispiel || SAP, Oracle Fusion Middleware || Kubernetes, Docker, Spring Boot
|}

== SOA und Event-Driven Architecture ==
Viele SOA-Systeme nutzen ereignisgesteuerte Kommunikation:  
Dienste können auf **Events** reagieren, die über einen **Enterprise Service Bus (ESB)** oder einen **Message Broker** verteilt werden.  
Dadurch lässt sich SOA mit [[Event-Driven Architecture]] kombinieren.

== Beispielhafte Tools und Frameworks ==
{| class="wikitable"
! Bereich !! Tools / Technologien
|-
| '''Middleware / ESB''' || Apache Camel, Mule ESB, IBM Integration Bus, WSO2
|-
| '''Web Services''' || Apache CXF, JAX-WS, Spring Web Services
|-
| '''Service Registry''' || UDDI, Consul, Eureka (moderne Variante)
|-
| '''Protokolle''' || SOAP, REST, AMQP, JMS
|}

== Zusammenhang mit anderen Architekturen ==
{| class="wikitable"
! Architektur !! Beziehung
|-
| [[Client-Server-Architektur]] || SOA erweitert das Client-Server-Prinzip auf verteilte Unternehmensdienste.
|-
| [[Microservices-Architektur]] || Moderne, leichtgewichtige Weiterentwicklung der SOA mit stärkerer Dezentralisierung.
|-
| [[Event-Driven Architecture]] || Ergänzende Architektur zur asynchronen Kommunikation zwischen Diensten.
|-
| [[Reactor-Entwurfsmuster]] || Wird in Messaging- und Eventsystemen innerhalb einer SOA verwendet.
|}

== Fazit ==
Die Service-Oriented Architecture ist ein **wichtiger Meilenstein in der Evolution verteilter Systeme**.  
Sie hat die Grundlage für **Microservices**, **Cloud-native Anwendungen** und **API-basierte Kommunikation** geschaffen.  
Während klassische SOA-Implementierungen heute seltener verwendet werden, leben ihre Prinzipien in modernen, leichtgewichtigen Architekturen fort.

== Siehe auch ==
* [[Microservices-Architektur]]  
* [[Client-Server-Architektur]]  
* [[Event-Driven Architecture]]  
* [[Distributed Systems]]  
* [[Entwurfsmuster (Softwareentwicklung)]]  
* [[Reactor-Entwurfsmuster]]

== Quellen ==
* Thomas Erl: *Service-Oriented Architecture: Concepts, Technology, and Design* (2005)  
* Martin Fowler: *Microservices and SOA* (2015)  
* IBM DeveloperWorks: *Understanding SOA fundamentals*  
* [https://en.wikipedia.org/wiki/Service-oriented_architecture Wikipedia: Service-Oriented Architecture]  
* OASIS: *SOA Reference Model*