Dieser Blog-Post stellt den Beginn einer Reihe von Beiträgen rund um das Thema SOA dar. Dabei sollen verschiedene Aspekte und Herausforderungen adressiert werden, die einem Software-Architekten in diesem Umfeld 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.

SOA definiert eine bestimmte Art von Softwarearchitektur und ist im Prinzip ein Paradigma zur Software-Entwicklung. 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 Software-Entwicklung. 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. Unternehmen versprechen sich von einer SOA eine größere Flexibilität und damit die Möglichkeit, zeitnah und kostengünstig die Software-Systeme 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 o ffene 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_Blog

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 de finiert 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.
    ServiceContract_Bsp

    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 defi niert, wie verschiedene Participants miteinander arbeiten, indem sie Services nutzen oder zur Verfügung stellen. Die Services Architectur stellt die oberste Sicht in einer SOA dar.
    Servicearchitecture_Bsp

    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.
    Participant_Bsp

    Beispiel Participant

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 identi fiziert. 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 (Web Service Description Language) Datei de finiert, die auf XML basiert. WSDL ist eine Metasprache, mit der das Protokoll des Nachrichtenversands, die Funktionen des Web-Services, Daten und Datentypen defi niert werden können. Web-Services werden häufig in Kombination mit SOAP (Simple Object Access Protocol) eingesetzt.
  • CORBA (Common Object Request Broker Architecture) ist die Spezi kation 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 Spezifi kation können Anwendungen miteinander kommunizieren, die mit unterschiedlichen ORBs bzw. Programmiersprachen implementiert wurden. Mit der IDL (Interface De nition Language) kann ein Entwickler das Interface seiner Anwendung de finieren. 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 evaluliert und mögliche Fallstricke diskutiert.

Literatur:

[1] http://www.omg.org/spec/SoaML/1.0/Beta2

Michael Schidlauske

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.
Michael Schidlauske

Letzte Artikel von Michael Schidlauske (Alle anzeigen)

Antwort hinterlassen

Shares