Dienstekomposition
Dienstekomposition (englisch service composition) ist ein Begriff aus der Informatik und beschreibt die Art und Weise, wie Dienste miteinander verknüpft sind. Da der Begriff meistens im Bereich der serviceorientierten Architektur verwendet wird, ist er auch unter Web Service Composition geläufig. Es werden zwei Arten der Kompositionen unterschieden: Orchestrierung und Choreographie. Eine Dienstekomposition kann aus einer oder beiden Arten bestehen.
Orchestrierung
Orchestrierung (englisch
, Instrumentierung, Inszenierung) ist das flexible Kombinieren mehrerer Services zu einer Komposition. Diese Komposition beschreibt einen ausführbaren Geschäftsprozess. Sowohl unternehmensinterne als auch unternehmensexterne Dienste können kombiniert werden. Der Prozessfluss wird durch einen Teilnehmer gesteuert. Jeder Dienst hat dabei einen eingeschränkten Sichtbereich (englisch
) und kann für Prozesse nur innerhalb seines Sichtbereichs entscheiden. Aktivitäten hinter einem direkten Kommunikationspartner bleiben verborgen.
WS-BPEL ist ein Beispiel für eine Sprache zur Orchestrierung von Webservices.
Choreographie
Bei der Choreographie (englisch
) beschreibt jeder Dienst seine eigene Aufgabe in der gesamten Komposition. Es gibt keinen zentralen Punkt, der die Korrektheit sicherstellt und die Aufgabenerfüllung steuert. Der Fokus liegt auf dem Nachrichtenaustausch zwischen den Diensten. WS-CDL ist ein Beispiel für eine Choreographiesprache.
Abgrenzung Orchestrierung und Choreographie
Die Orchestrierung enthält eine Beschreibung der Services, ihre Bedingungen zum Aufruf sowie Abhängigkeiten und Alternativen. Dabei ist der Prozess aus der Perspektive eines der „Beteiligten“ gesehen, das heißt, dieser ruft andere Prozesse auf. Im Gegensatz dazu beschreibt Choreographie, wie die einzelnen Prozesse untereinander agieren. Entsprechend dem Schema rechts ist die Orchestrierung die lokale Beschreibung eines (Geschäfts-)Prozesses (blau umrahmt), wohingegen die Choreographie die Interaktion mehrerer Prozesse umfasst (rot umrahmt).
Man kann den Unterschied zwischen Orchestrierung und Choreographie auch anschaulich am Beispiel einer Straßenkreuzung erklären: Orchestrierung entspricht einer Ampelsteuerung zur zentralen Steuerung sämtlicher Fahrzeuge durch Lichtzeichen. Choreographie entspricht dagegen einem Kreisverkehr ohne zentrale Steuerung. Allgemeine Regeln im Kreisverkehr legen fest, wie Fahrzeuge in den Kreisverkehr einbiegen und diesen dann wieder verlassen.[1]
Ein weiteres Beispiel wäre die Situation in einem klassischen Orchester: Betrachtet man aus der Sicht eines Orchestermitglieds eine Einzelstimme, dann entspricht dies der Choreographie. Schaut man hingegen durch die Augen des Dirigenten auf die Partitur, dann bekommt man einen Überblick über das, was insgesamt abläuft. Folglich entspricht dies der Orchestrierung.
Beispiele
Als Beispiel für eine Orchestrierungssprache wäre WS-BPEL zu nennen. Im Gegensatz dazu wäre WS-CDL ein Beispiel für eine Choreographiesprache. Dienstkomposition wurde auch in öffentlich geförderten Forschungsprojekten beforscht, welche für verschiedene Domänen und verschiedene Beschreibungssprachen Dienstkomposition untersuchen. Ein Beispiel für eine solche Domäne ist die Elektromobilität und die dazugehörigen Dienstleistungen[2]. Ein mehr technisches Beispiel ist der Ansatz SEMAPLAN von Akkiraju[3].
Diensteorchestrierung aus Konzeptsicht
Ein anderer Ansatz, Orchestrierung in der IT zu beschreiben, nutzt eine weiter gefasste und undifferenzierte Sicht auf die nötigen Konzeptebenen und Technologien, die bei der Zusammenarbeit von Services zur gemeinsamen Leistungserbringung relevant sind. Die Orchestrierung spielt sich demzufolge in einem weiten Feld ab und berührt u. a. folgende Bereiche:
- Geschäftsprozessmodellierung
- Prozesssteuerung und -beschreibung
- Serviceverzeichnis
- Servicebeschreibung
- Kommunikationsabsicherung und Methoden-Aufrufe
- Nachrichtenprotokolle und -struktur.
Für diese Konzeptebenen gibt es unterschiedliche Lösungen, die jeweils eigene technologische Schwerpunkte setzen.
Diensteorchestrierung in statischen Prozessumgebungen
Für verschiedene Anwendungsbereiche wurde das Zusammenspiel bestimmter Techniken auf einigen Konzeptebenen vielfach erprobt, wodurch sich gewisse Best-Practices etabliert haben. So wird in Umgebungen, die eine serviceorientierte Architektur auf Basis von Webservice ermöglichen und zusätzlich eher statische Prozesse implementieren (wie beispielsweise die Schnittstelle von Google AdWords), sehr häufig das Dreigespann WSDL, UDDI und SOAP eingesetzt. Hierbei werden sowohl die Beschreibung und Identifikation der Dienste als auch der Aufbau und die zuverlässige Durchführung der Kommunikation zwischen den Systembeteiligten ermöglicht.
Diensteorchestrierung in dynamischen Prozessumgebungen
Beim Einsatz von SOA in dynamischen Umgebungen, in denen das System sich auf flexibel ändernde Prozessabläufe und unvorhersehbare Dienst-Verfügbarkeiten einstellen muss, stößt die oben genannte Technologiekombination an Grenzen.
In solchen Umgebungen stehen zusätzlich zu den oben genannten Herausforderungen zur Dienste-Beschreibung und System-Kommunikation andere Aspekte im Fokus der SOA-Lösung. Der dynamischen Dienste-Analyse, -Generierung und -Bindung kommt dann eine besondere Bedeutung zu. Diese setzt sowohl eine semantische Beschreibung der Dienste als auch eine Art intelligent agierender Orchestrierungsschicht voraus, die die Funktion eines rein passiven Dienste-Verzeichnisses (wie beispielsweise UDDI) entscheidend erweitert.
Solche semantischen bzw. ontologischen Ansätze zur Diensteorchestrierung finden sich beispielsweise beim Adaptive Services Grid, wobei bislang keine Fälle von dynamischer Dienstekomposition bekannt sind. Statt semantischer Verfahren wäre auch eine einfache thematische Gliederung oder eine Standardisierung von Parametern innerhalb einer Plattform eine Alternative.
Einzelnachweise
- ↑ Nicolai Josuttis: SOA in der Praxis. 2008, S. 121
- ↑ Endbericht des Forschungsprojektes EMD: Erweiterbare und adaptive Elektro-Mobilitätsdienste, 2016, https://edocs.tib.eu/files/e01fb16/87395324X.pdf
- ↑
