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 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.
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.
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.
Diese Struktur ist nicht die Struktur des eigentlichen Validierungsproviders, sondern die Struktur der
Servicekollaboration. Schauen Sie sich dazu die folgende Abbildung an.
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.
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.
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.
|