Muster: ServiceOrientedArchitecture

|

Zweck und Funktionsweise

In der Serviceorientierten Architektur (Service-Orented Architecture, abgekürzt mit SOA) werden einzelne IT-Dienste als Services gekapselt. Als IT-Dienste gelten hierbei zB Datenbanken, Applikationsteile oder ganze Applikationen. Die Granularität ist je nach Anwendungsfall unterschiedlich fein oder grob.

Komponenten und Begriffe

Services: Stellen IT-Dienste zur Verfügung. Je nach Anwendungsfall wissen die Konsumenten der Services wenig bis nichts von der Architektur der darunterliegenden Systeme. Die Services können daher einen hohen Abstraktionsgrad aufweisen.
Basis-Services: Wenn die Services sehr abstrakt sind, können Basis-Services als Schicht zwischen den Services für die Konsumenten und den darunterliegenden Systemen eingezogen werden. Diese Basis-Services sind meist granularer und kleiner und greifen auf die eigentlichen Applikationen zu.
Servicegeber (Service provider): Dies ist ein System, das Services bereitstellt. Dies können einzelne Geschäftsapplikationen, aber auch eine Middleware-Software sein.
Servicenehmer / Konsument (Service consumer): Dies ist ein System, das die Services des Servicegebers konsumiert
Serviceverzeichnis (Service repository): Listet alle verfügbaren Services auf

Anforderung an ein Service

In verschiedenen Quellen sind eine Vielzahl unterschiedlicher Anforderungen für Services definiert. Die häufig vorkommenden sind:

Lose Kopplung (loose coupling): Ein Service muss über eine standardisierte Schnittstelle verfügen. Solange diese Schnittstelle eingehalten wird, ist die zugrundeliegende Implementierung jederzeit austauschbar. Ein Service stellt somit eine in sich geschlossene Funktion, ohne Abhängigkeiten zu anderen Services dar.
Zustandslos (stateless): Beim Aufruf des Services befindet sich das Service in einem wohldefinierten Zustand, der bei jedem Start gleich ist. Das Service speichert keine Informationen zu früheren Aufrufen. Sollen solche Informationen persistiert werden, so hat sich der Konsument darum zu kümmern.
Ortstransparenz (location transparency): Für den Konsumenten spielt es keine Rolle, auf welchem Server und wie das Service platziert (gehostet) ist.
Plattformunabhängigkeit (platform independence): Servertechnologien, Betriebssystem und Programmiersprache von Services (auch von einzelnen Services in einer SOA untereinander) und Konsumenten können heterogen sein. Es wird über standardisierte Schnittstellen und über ein standardisiertes Protokoll kommuniziert.
Wiederverwendbarkeit (Service reusability): Services sollen so allgemein wie sinnvoll möglich gehalten werden, um die Wiederverwendbarkeit eines Services zu unterstützen.

Einführungsbeispiel

Implementierung

Typischerweise, aber nicht notwendigerweise, werden SOA-Services mit Webservices als einheitliche Schnittstelle implementiert. Als Technologien kommen REST und SOAP in Frage, wobei SOAP wegen seiner Mächtigkeit derzeit die üblichere Variante darstellt. Prinzipiell kann man eine SOA aber mit jeder geeigneten plattformübergreifenden Schnittstellentechnologie aufbauen.

Vorteile

Einheitliche Kommunikation zwischen einzelnen Systemen einer SOA wird ermöglicht.
Dies führt zur Reduktion der Komplexität in verteilten Systemen
Über mehrere Applikationen verteilte Geschäftsprozesse können leicht abgebildet werden und sind wartbarer als bei monolithischen Lösungen

Nachteile

Es ist abzuwägen, wie granular die Services sein sollen. Zu feine Granularität bedeutet einen hohen Aufwand, zu hohe Granularität bedeutet womöglich schlechte Wartbarkeit und schlechte Wiederverwendbarkeit
Eventuell entsteht Mehraufwand durch Kommunikation

Praxisbeispiele

Hoch zum Inhaltsverzeichnis