SOA (Serviceorientierte Architektur): Grundlagen
In diesem Beitrag sollen verschiedene Aspekte und Herausforderungen adressiert werden, die einem Software-Architekten im Umfeld der Serviceorientierten Architektur (SOA) begegnen können. Es werden Themen wie die Migration von Legacy Systemen, der Einsatz von SOA Pattern, SOA Governance und SOA im Kontext mit BPM behandelt. Doch zu Beginn werden hier die Grundlagen gelegt, um auch den SOA-Neuling abzuholen.
Inhaltsverzeichnis
- Was ist SOA (Serviceorientierte Architektur)
- Was ist ein ESB?
- Was sind die Vorteile einer serviceorientierten Architektur?
- SoaML
- Unterschied zwischen SOA und Microservices
- SOA-Techniken zur Implementierung
Was ist SOA (Serviceorientierte Architektur)?
SOA definiert eine bestimmte Art von Softwarearchitektur und ist im Prinzip ein Paradigma zur Softwareentwicklung. Es dient dazu, die zunehmende Komplexität heterogener moderner IT-Systeme zu beherrschen. Vor einigen Jahren gab es um SOAs einen großen Hype. Dieser Hype ist vorbei und inzwischen sind SOAs eine etablierte Methodik in der Softwareentwicklung.
Hinter SOAs steckt die Idee, Geschäftsprozesse – oder Teile davon – hinter Services zu wrappen, und diese sinnvoll zu verknüpfen. Diese Services stehen offen zur Verfügung. SOAs sind plattform- und sprachenunabhängig. Die Services können also in völlig unterschiedlichen Techniken implementiert sein. Das bedeutet, dass SOAs keine Technik an sich, sondern eine Abstraktion einer reellen Begebenheit sind.
Was ist ein ESB?
Der Enterprise Service Bus (ESB) ist eine Softwarearchitekturkomponente, die als zentrale Vermittlungsschicht für die Integration unterschiedlicher Anwendungssysteme und Services innerhalb einer Unternehmens-IT-Landschaft dient. Ein ESB ermöglicht die einfache Kommunikation und den Datenaustausch zwischen heterogenen Systemen, indem er eine Vielzahl von Standardkommunikationsprotokollen, Nachrichtenformaten und Schnittstellen unterstützt. Er bietet Funktionen wie Nachrichtentransformation, -routing, -vermittlung und -anreicherung, um die Interoperabilität zwischen verschiedenen Anwendungen und Services zu gewährleisten. Darüber hinaus unterstützt der ESB die Governance und die Überwachung und Verwaltung von Serviceinteraktionen, was für die Aufrechterhaltung der Servicequalität und die Einhaltung von Geschäftsprozessen unerlässlich ist.
Was sind die Vorteile einer serviceorientierten Architektur?
Unternehmen versprechen sich von einer SOA eine größere Flexibilität und damit die Möglichkeit, zeitnah und kostengünstig die Softwaresysteme an die sich ständig im Wandel befindenden Anforderungen anzupassen. Die Grundlegenden Merkmale einer SOA sind:
- Lose Kopplung bedeutet, dass Dienste bei Bedarf von anderen Diensten oder Anwendungen dynamisch gesucht, gefunden und eingebunden werden. Es handelt sich um eine Bindung zur Laufzeit. Die lose Kopplung ist wesentlich für die hohe Flexibilität von SOAs verantwortlich.
- Dynamisches Binden bedeutet, dass zum Zeitpunkt der Übersetzung oft nicht bekannt ist, welcher Dienst zur Laufzeit aufgerufen wird. Durch äußere Einflüsse ist es sogar möglich, dass die Wahl des zu bindenden Dienstes nicht unter der Kontrolle der Anwendung liegt.
- Verzeichnisdienst: Damit Dynamisches Binden möglich wird, braucht es eine zentrale Instanz, unter der der gewünschte Dienst gesucht werden kann. Grob kann man sich das wie ein Telefonbuch vorstellen. Der Verzeichnisdienst oder auch Registry gestattet es, nach Methoden zu suchen, die gerade benötigt werden.
- Verwendung von Standards: Damit ein gefundener Service auch genutzt werden kann, muss die Sprache ermittelt werden, die gesprochen werden muss, um mit dem Service zu kommunizieren. Das bedeutet, dass der Service eine maschinell lesbare Beschreibung seiner Schnittstellen anbieten muss. Um eine breite Akzeptanz für die Architektur zu erreichen, ist es wichtig, auf offene Standards für die Schnittstellenbeschreibung und die Schnittstelle an sich zu setzen.
- Verteiltheit: Eine SOA setzt sich aus Services zusammen, die von verschiedenen verteilten Systemen zur Verfügung gestellt werden. Diese Services stehen offen im Bereich der Domäne der verteilten Systeme zur Verfügung. Die Domäne kann beispielsweise ein geschlossenes Netzwerk innerhalb eines Unternehmens oder aber auch das Internet sein.
- Prozessorientierung: Ein wesentliches Merkmal einer SOA ist die Orientierung der Services nach Prozessen. Entweder bildet ein Service einen Prozess komplett ab, oder aber eine Menge von Services wird genutzt, um einen Prozess abzubilden.
SOA Tempel
Der SOA-Tempel zeigt nochmal die Merkmale. Die Verteiltheit und die Standards sind das Fundament einer SOA. Die lose Kopplung, der Verzeichnisdienst und die Prozessorientierung sind die Säulen, die eine SOA tragen.
SoaML
Für SOA wurde von der OMG (Object Management Group) eine eigene Modellierungssprache entworfen, die dem Design von SOA-Anwendungen dient. Die OMG hat beispielsweise auch die UML oder die BPMN entwickelt. SoaML “erweitert” die UML um einige Komponenten, die dazu dienen, Contracts, Services, Provider und Consumer in einem Modell abbilden zu können. Generell ist zu sagen, dass SoaML unabhängig von der zur Implementierung gewählten Technik ist. Des Weiteren dient die SoaML nicht dazu, eine Ausführungssemantik zu definieren. Die Entscheidung, welcher Service aufgerufen wird, entscheidet ein Participant zur Laufzeit. Dies ist in dem SoaML Modell nicht sichtbar. Das bedeutet, dass sich aus einem SoaML Modell nur bedingt der fachliche Kontext herauslesen lässt. Dafür ist die SoaML aber auch nicht gedacht. Sie dient ausschließlich dazu die Servicelandschaft abzubilden. Beispielhaft sind im Folgenden sechs wichtige Komponenten aufgeführt. Die komplette Spezifikation von SoaML finden Sie auf der Website der OMG[1].
- Service Interface: Wird mittels einer UML-Klasse oder einem UML-Interface dargestellt. Ein Service Interface definiert die Schnittstelle zwischen einem Service Point und einem Request Point. Es stellt die Rolle in einem Service Contract dar und legt fest, wie sich ein Participant verhalten muss, um einen Service zu nutzen oder anzubieten. In der folgenden Abbildung ist ein einfaches Bespiel mit zwei Service Interfaces zu sehen.
Beispiel Service Contract
- Service Contract: Wird mithilfe einer UML-Collaboration dargestellt. Darin werden die Abmachungen zwischen einem Serviceanbieter und einem Servicenutzer festgelegt.
- Services Architecture: Wird ebenfalls mithilfe einer UML-Collaboration dargestellt. In ihr wird definiert, wie verschiedene Participants miteinander arbeiten, indem sie Services nutzen oder zur Verfügung stellen. Die Services Architecture stellt die oberste Sicht in einer SOA dar.
Beispiel Service Architecture
- Service Point: Wird mit einem UML-Port dargestellt. Angebot eines Services, der mit einem Service Interface typisiert wird.
- Request Point: Wird mit einem UML-Port dargestellt. Nutzung eines Services, der mit einem Service Interface typisiert ist.
- Participant: Wird mit einem UML-Component dargestellt. Ein Participant bietet über einen Service Point einen Service an oder nutzt ihn über einen Request Point. Er kann also die Rolle eines Consumers bzw. Providers annehmen.
Beispiel Participant
Unterschied zwischen SOA und Microservices
Serviceorientierte Architektur und Microservices sind beides Architekturansätze zur Gestaltung und Entwicklung von Softwareanwendungen, die auf Services basieren. Sie teilen einige Konzepte, unterscheiden sich jedoch in ihren Implementierungsansätzen und Designprinzipien.
Hauptmerkmale von SOA:
Integration verschiedener Anwendungen: SOA ist darauf ausgerichtet, die Zusammenarbeit und Kommunikation zwischen unterschiedlichen Anwendungen innerhalb eines Unternehmens zu ermöglichen.
Wiederverwendung von Services: Services unter SOA sind in der Regel größer und umfassender gestaltet, um eine breite Palette von Geschäftsprozessen zu unterstützen. Dies fördert die Wiederverwendung von Funktionalitäten.
ESB: SOA verwendet häufig einen ESB für die Kommunikation zwischen Services, der eine zentrale Vermittlungsschicht bietet und die Integration vereinfacht.
Standards und Protokolle: SOA setzt stark auf Standards wie SOAP (Simple Object Access Protocol), WSDL (Web Service Description Language) und andere Webservices-Spezifikationen für die Interaktion zwischen Services.
Hauptmerkmale von Microservices:
Feingranulare Services: Microservices-Architektur besteht aus kleinen, unabhängigen Services, die jeweils eine spezifische Geschäftsfunktion erfüllen.
Unabhängige Entwicklung und Deployment: Jeder Microservice kann unabhängig von anderen entwickelt, deployt und skaliert werden, was die Agilität und Flexibilität der Entwicklungsteams erhöht.
Dezentralisierte Datenverwaltung: Microservices verwalten ihre eigenen Daten und Datenbanken, was die Entkopplung der Services untereinander fördert.
Kommunikation über leichte Protokolle: Sie verwenden einfache und leichte Kommunikationsprotokolle (wie REST oder gRPC), die eine schnelle und effiziente Inter-Service-Kommunikation ermöglichen.
Unterschiede zusammengefasst
Granularität: Microservices sind feingranularer als die typischen Services in einer SOA.
Datenverwaltung: Microservices fördern die dezentralisierte Datenhaltung, während SOA tendenziell eine zentralisierte Datenhaltung unterstützt.
Kommunikationsmechanismus: Microservices bevorzugen leichte Kommunikationsprotokolle wie REST, während SOA auf komplexe Standards wie SOAP setzt.
Deployment: Microservices können unabhängig voneinander deployt werden, was bei SOA aufgrund der engeren Kopplung von Services schwieriger ist.
Technologieunabhängigkeit: Microservices ermöglichen eine größere Technologieunabhängigkeit für einzelne Services im Vergleich zu SOA, wo häufig eine einheitliche Technologieplattform verwendet wird.
Skalierung: Microservices sind für die horizontale Skalierung und für die Nutzung in Cloud-Umgebungen optimiert, während SOA-Services tendenziell vertikal skaliert werden.
Management und Monitoring: Aufgrund der größeren Anzahl an Services kann das Management und Monitoring von Microservices komplexer sein als bei SOA, das eine zentralisierte Verwaltung begünstigt.
SOA-Techniken zur Implementierung
SOA-Architekturen lassen sich mittels verschiedener Techniken realisieren. Auch die Kombination verschiedener Techniken innerhalb einer Architektur stellt kein Problem dar. Beispielhaft wären hier zu nennen:
- Web Services sind sicherlich die am weitesten verbreitete Variante zur Implementierung eines Service. Web-Services werden eindeutig über eine URI identifiziert. Er unterstützt die direkte Interaktion mit anderen Software-Agenten über auf XML basierende Nachrichten, die über eines der Internet-Protokolle verschickt werden. Web-Services dienen der Maschinen-Maschinen Kommunikation. Die Schnittstelle zur Kommunikation mit einem Web-Service wird über die sogenannte WSDL Datei definiert, die auf XML basiert. WSDL ist eine Metasprache, mit der das Protokoll des Nachrichtenversands, die Funktionen des Web-Services, Daten und Datentypen definiert werden können. Web-Services werden häufig in Kombination mit SOAP eingesetzt.
- CORBA (Common Object Request Broker Architecture) ist die Spezifikation für eine objektorientierte Middleware, die sprachen- und plattformunabhängig ist und es ermöglicht, verteilte Systeme in heterogenen Landschaften zu entwickeln. Für jede Programmiersprache kann ein ORB (Object Request Broker) implementiert werden. Aufgrund der gemeinsamen Spezifikation können Anwendungen miteinander kommunizieren, die mit unterschiedlichen ORBs bzw. Programmiersprachen implementiert wurden. Mit der IDL (Interface Definition Language) kann ein Entwickler das Interface seiner Anwendung definieren. CORBA bietet eine Reihe von eigenen Diensten an, die die Zusammenarbeit von Anwendungen in heterogenen, verteilten Systemen unterstützen. Die Sprachen- und Plattformunabhängigkeit von CORBA bringt, in der Art und Weise wie sie in CORBA realisiert ist, eine gewisse Komplexität mit sich. Diese Komplexität hat dazu geführt, dass CORBA im Vergleich zu anderen Technologien ins Hintertreffen geraten ist.
Ich hoffe, ich konnte Ihnen in diesem Blog einen Überblick über das Thema SOA geben und grob die Grundlagen zu SOAs vermitteln. Der kommende Beitrag wird sich mit der Migration von Legacy Systemen in service-orientierte Architekturen beschäftigen. Dort werden beispielsweise Migrationsstrategien evaluiert und mögliche Fallstricke diskutiert.
Literatur:
[1] http://www.omg.org/spec/SoaML/1.0/Beta2
Über den Autor
Michael Schidlauske arbeitete als Software Engineer und IT Consultants am Standort Frankfurt. Seine Schwerpunkte in agiler Software-Entwicklung, Service-orientierten Architekturen und Business Process Management vermittelt der Informatiker auch in Fachvorträgen und Schulungen.
