Service-Oriented Architecture (SOA)

Aus dev.kaibel.net
Version vom 1. November 2025, 13:50 Uhr von PhilKa (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „= 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 Grun…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

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. 

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

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

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. 

Client → Service Registry → Service Provider → Antwort an Client

Technologien und Standards

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

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.

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

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

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

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

Quellen

  • Thomas Erl: *Service-Oriented Architecture: Concepts, Technology, and Design* (2005)
  • Martin Fowler: *Microservices and SOA* (2015)
  • IBM DeveloperWorks: *Understanding SOA fundamentals*
  • Wikipedia: Service-Oriented Architecture
  • OASIS: *SOA Reference Model*
Abgerufen von „http://dev.kaibel.net/index.php?title=Service-Oriented_Architecture_(SOA)&oldid=101“