Konzept: Servicekomposition und -choreographie
Dieses Konzept beschreibt, wie Services kombiniert werden können, um zusammengesetzte und interaktive Strukturen zu erzielen, die neue geschäftsorientierte Services auf einer höheren Ebene bereitstellen.
Beziehungen
Hauptbeschreibung

Einführung

Ein Schlüsselaspekt der serviceorientierten Architektur (SOA) ist, dass Services kombinierbar sein müssen, d. h., dass ein neuer Service oft als Kollaboration zwischen einer Gruppe vorhandener Services zusammengesetzt wird. In vielerlei Hinsicht gilt das für vorhandene komponentenbasierte und objektorientierte Verfahren, abgesehen davon, dass bestimmte Funktionen in der Middleware, die zur Entwicklung serviceorientierter Lösungen verwendet werden, die direkte Ausführung dieser Kollaborationen über Standards wie Business Process Execution Language for Web Services (BPEL4WS, WS-BPEL oder nur BPEL) ermöglichen. Die Möglichkeit, Services nach Struktur zusammenzufassen, d. h. die Verwendungsabhängigkeiten zwischen Services zu definieren, und auch die Möglichkeit, Services nach Verhalten zusammenzusetzen, machen eine servicebasierte Architektur und IT-Strategie für so viele Organisationen interessant.

Immer mehr Organisationen stellen fest, dass sie eine erhöhte Agilität benötigen, um auf sich ändernde Geschäftsumgebungen reagieren zu können, unabhängig davon, ob es sich um den Druck durch die Globalisierung, neue Märkte und Kanäle oder einfach neue Konkurrenten handelt, die Technologie effizienter einsetzen. Diese Organisationen betrachten die serviceorientierte Entwicklung und serviceorientierte Lösungen als Möglichkeit, ihre IT-Assets zu organisieren, um so aktuelle Anforderungen zu erfüllen und eine Infrastruktur geschäftlich ausgerichteter Funktionen bereitzustellen mit dem Ziel, sie wiederverwenden, rekonfigurieren und effizient und effektiv erneut kombinieren zu können.

Ein anderer Aspekt der beschriebenen Komposition von Services ist, dass eine flexible Methode geboten wird, mit der vorhandene IT-Assets auf dieselbe Weise in neue Lösungen eingebunden werden können wie neuere Assets. Beispielsweise können vorhandene Assets, auch diejenigen, die für Mainframeplattformen u. Ä. entwickelt wurden, als Services mit einigen Middlewareprodukten verfügbar gemacht und genau wie neue Services, die mit J2EE, IBM WebSphere oder Microsoft .NET entwickelt wurden, implementiert werden. Leider werden die meisten Assets mit Schnittstellen entwickelt, die die Anleitungen für neue Services nicht unterstützen. Im Grunde genommen ist es nützlich, zusammengesetzte Services zu verwenden, die diese vorhandenen Services nicht einfach nur wiederverwenden, sondern andere, stärker geschäftlich ausgerichtete Schnittstellen bieten, die die vorhandenen Funktionen zusammenfassen und so choreographieren, dass sie die Funktionalität der höheren Ebene bereitstellen.

Servicechoreographie

Betrachten wir kurz den Begriff Choreographie. Er wird in vielen Middlewareprodukten verwendet, um die verwaltete Ausführung eines Scripts zu bezeichnen, der einen Prozessfluss definiert, in dem die Teilnehmer Services sind und die Aufgaben sich auf Nachrichtenaustausch beziehen. In einigen Produkten wird der Begriff Orchestrierung verwendet. Einige Branchenanalytiker und -technologen beschreiben zwar die Unterschiede in der Bedeutung der Wörter und wie diese Begriffe in Standards verwendet werden, für die meisten Benutzer sind diese Unterschiede allerdings weniger interessant als die Ähnlichkeiten.

Für die Standards wurde erst spät eine Choreographie von Web-Services entwickelt, nachdem die meisten führenden Middlewarehersteller proprietäre Lösungen eingeführt hatten. Der aktuelle Branchenstandard ist Business Process Execution Language for Web Services (BPEL4WS oder BPEL). Nähere Informationen zu BPEL4WS finden Sie auf der Website von OASIS WSBPEL oder der Website von IBM BPEL.

Services als zusammengesetzte Strukturen

Services können auf der Basis der von anderen Services bereitgestellten Funktionen einfach rekursiv entwickelt werden, wie im Diagramm unten dargestellt. Die Services sind in der Lage, die Services, auf denen sie basieren, zu identifizieren. In diesem Fall verwendet ein zusammengesetzter Service die Services für den Auftragseingang und das EDI-Gateway (Electronic Data Interchange). Zusammengesetzte Services werden häufig verwendet, wenn die normale Aufgliederung von Servicefunktionen allgemeine Funktionen identifiziert, die unter verschiedenen Umständen bereitgestellt werden können. Für einige Services, deren Rolle darin besteht, Funktionen für die Infrastruktur bereitzustellen (z. B. der EDI-Service unten), kann das relativ einfach identifiziert werden. In anderen Fällen identifizieren detaillierte Servicekollaborationen die Anforderung, einen geeigneten Service in mehrere konkrete Services aufzuteilen.

Im Kontext beschriebene Abbildung

Ein wichtiger Aspekt bei der Verwendung von zusammengesetzten Services ist die Bereitstellung von Funktionen, die von vorhandenen (traditionellen) Assets realisiert werden. In den meisten Fällen erfolgt der Zugriff auf diese Funktionen über Konnektoren oder APIs, die vom Asset selbst bereitgestellt werden, und es wird ein neuer Service entwickelt, der hinsichtlich bestimmter Logikkomponenten von diesen Assets abhängt. Andererseits kann eine alternative Strategie eingesetzt werden, um die Aggregatkomponente flexibler entwickeln und das vorhandene Asset später gegen eine andere Implementierung austauschen zu können. In diesem Fall wird jede vorhandene Funktion als unabhängiger Service zugänglich gemacht. Diese Services werden dann vom zusammengesetzten Service verwendet, damit das vorhandene Asset und die zusammengesetzten Services sich unabhängig weiterentwickeln können.

Eine andere Verwendung von zusammengesetzten Services liegt vor, wenn die Gruppe der konkreten, von einem zusammengesetzten Service genutzten Services im Vorauf bekannt sind. Beispielsweise kann im Falle eines Auftragsverwaltungsservice festgestellt werden, dass die Auftragsvalidierung (OrderValidation) als separate Gruppe unabhängiger Services für Geschäftsregeln gehandhabt werden soll, damit zu einem späteren Zeitpunkt neue Regeln hinzugefügt werden können. Das bezieht sich auf das Thema Servicevermittlung (siehe Richtlinie Servicevermittlung).

Ein solcher Ansatz hat offensichtliche Vorteile, Nachteile hat er jedoch auch. Wenn der Service nur auf der unteren Ebene über Internetprotokolle, wie z. B. SOAP/HTTP, zugänglich gemacht werden kann, ist er wahrscheinlich weniger zuverlässig und leistungsstark, als wenn der Zugriff über eine native API oder einen nativen Konnektor erfolgt. Diese Kompromisse müssen als Bestandteil der architekturbezogenen Entscheidungen bei jedem Servicedesign dokumentiert werden.

Weitere Informationen zum Zugriff auf vorhandene Assets und die Beziehung zwischen geeigneten und tatsächlichen Services finden Sie in der Beschreibung der Aktivität Analyse vorhandener Assets.

Servicekollaborationen

Bei der Modellierung des Verhaltens von zusammengesetzten Services wird das Artefakt Servicevertrag während der Identifikations- und Designphase verwendet.

  • Während der Analyse vorhandener Assets wird die Kollaboration als Tool zur Beschreibung der Rollen und Zuständigkeiten von geeigneten Services verwendet. Beispielsweise kann festgestellt werden, dass die Services für Auftragsvalidierung und Auftragsverwaltung getrennt gehandhabt werden müssen. Dann stellt sich allerdings die Frage, wie sie kommunizieren und für welche Informationen sie zuständig sind. Eine Servicekollaboration wird als Tool zur Beschreibung dieser Kommunikation verwendet, und der erforderliche Nachrichtenaustausch kann anhand des entstehenden Modells identifiziert werden.
  • Während der Servicespezifikation wird die Kollaboration verwendet, um das konkrete Verhalten eines bestimmten Service bzw. einer Operation für einen Service zu definieren. Beispielsweise kann man das obige Beispiel mit der Auftragsvalidierung (OrderValidation) konkret als Gruppe von Nachrichten beschreiben, die an eine Gruppe von Services für Validierungsregeln gesendet werden.

So kann man erkennen, dass eine Servicekollaboration in der Aufgabe Servicedesign direkt mit dem Begriff "Choreographie" für Web-Services in Zusammenhang steht. Sie stellt eine konfigurierbare, externalisierte Ablaufbeschreibung dar, die eine Gruppe von Nachrichtenaustauschvorgängen, die zwischen Services ablaufen, in eine Reihenfolge bringt. In den meisten Middlewareprodukten, die Choreographien implementieren, wird der Ablauf in einer XML-Sprache wie BPEL beschrieben. Solch eine Sprache könnte aus der im Artefakt Servicemodell beschriebenen Servicekollaboration generiert werden, wenn der Ablauf selbst mit UML-2.0-Aktivitäten oder -Interaktionen beschrieben wird.

Die Kollaboration besteht aus einer zusammengesetzten Struktur, aus der Sie die Kollaborateure und deren Verbindungen sowie ein Verhalten ersehen können, das die ausgetauschten Nachrichten und deren Reihenfolge symbolisiert. Das obige Diagramm, das einen CompositeProvider zeigt, veranschaulicht genau wie die folgende Abbildung zur OrderValidation eine zusammengesetzte Struktur.

Im Kontext beschriebene Abbildung

Diese Struktur ist nicht die Struktur des eigentlichen Validierungsproviders, sondern die Struktur der Servicekollaboration. Schauen Sie sich dazu die folgende Abbildung an.

Im Kontext beschriebene Abbildung

Serviceverhalten angeben

Wie oben dargestellt, ist es allgemein üblich, entweder UML-2.0-Aktivitäten oder -Interaktionen, insbesondere Ablaufdiagramme, zu verwenden, um den Ablauf von Nachrichten zwischen Services in einer Kollaboration zu beschreiben. Das folgende Diagramm ist ein UML-2.0-Aktivitätsdiagramm, das das Verhalten des Service OrderValidation veranschaulicht. Für einen bestimmten Auftrag stellt der Service ValidationRegistry eine Liste mit tatsächlichen aufrufbaren Validierungsoperationen bereit.

Im Kontext beschriebene Abbildung

Beachten Sie, dass ein solches Verhalten für einen vollständigen Service oder pro Operation identifiziert werden kann, je nach Bedarf des Service. In diesem Fall bezieht sich die Aktivität innerhalb der Kollaboration auf die Operation Validate() (über die Spezifikation/Methodenzuordnung in UML 2.0).

Servicebindungen angeben

Wie oben dargestellt, werden die für die Kommunikation zwischen Services verwendeten Bindungen (tatsächliche physische Protokolle und Nachrichtencodierungen) als Eigenschaft des Servicekanals in der Kompositionssicht identifiziert. Tatsächliche Bindungen, die zwischen Services verwendet werden, haben große Auswirkungen auf nicht funktionale Anforderungen wie Leistung, Zuverlässigkeit und Sicherheit. So sollten die verfügbaren Optionen mit den jeweiligen Auswirkungen in der gesamten Systemarchitektur dokumentiert werden. Beispielsweise ist es möglich, dass eine Verwendung von Servicepartitionen darauf abzielt, zulässige oder erforderliche Bindungen in der Partition darzustellen, wobei eine allgemeine Anforderung ist, dass Services in einer logischen Zone über Bindungen kommunizieren, die zwar eine hohe Leistung haben, jedoch proprietär sind, wohingegen die Kommunikation mit Services außerhalb der Zone standardisierte Bindungen mit niedrigerer Leistung verwenden.

Viele Leute möchten wissen, ob Funktionen, die für die Leistung, Zuverlässigkeit und Skalierbarkeit von Web-Services erforderlich sind, von einer auf HTTP und SOAP basierenden Architektur, die von Natur aus langsam und unzuverlässig ist, bereitgestellt werden kann. Zuerst muss geklärt werden, was unter "langsam und unzuverlässig" zu verstehen ist. Dann muss man sich mit dem Umstand auseinander setzen, dass sogar zuverlässige Transporte sich auf unzuverlässige Medien stützen. Wenn Sie beispielsweise SOAP over HTTP verwenden, können Sie immer Protokolle und Interaktionen auf Anwendungsebene erstellen, die zusätzliche Funktionen für Nachrichtenbestätigungen und Sicherheit bereitstellen. Wenn man jedoch bedenkt, dass bestimmte Services im selben Sicherheits- oder Anwendungskontext kommunizieren, sollte man in Erwägung ziehen, andere Medien als HTTP zu verwenden.

Es ist sehr wichtig, zu erkennen, dass Sie, auch wenn Web-Services ein einfaches Modell und eine Gruppe einfacher, flexibler Protokolle bereitstellen, nicht auf diese Optionen beschränkt sind. Wenn WSDL bereits Bindungen für SOAP und HTTP GET/PUT hat, müssen Anforderer mit zusätzlichen Optionen bereitgestellt werden. Beispielsweise kann eine einzelner Service eine Nachricht mit einer Bindung für Nachrichtenwarteschlangen und einer SOAP-Bindung offen legen, damit der Anforderer die geeignetere Bindung auswählen kann. In diesem Fall kann der Provider auch Anreize wie eine garantierte Servicestufe bieten, unter der Voraussetzung, dass die Nachrichtenwarteschlange verwendet wird, ohne jedoch eine Servicegarantie für eine HTTP-Kommunikation zu geben.

Wenn wir noch einmal auf das obige Beispiel OrderValidation zurückgreifen, können wir in der folgenden Abbildung erkennen, wie die Bindungen dem Stereotyp Service Channel (Servicekanal) zugeordnet und visualisiert werden.

Im Kontext beschriebenes Diagramm

Bei der Planung und beim Design von unternehmensweiten Lösungen müssen immer die funktionalen und nicht funktionalen Anforderungen berücksichtigt werden, und es muss sichergestellt werden, dass die richtigen Kompromisse erzielt und die richtigen Entscheidungen getroffen werden, um die Geschäftsziele zu unterstützen.