Vermittlung ist der Vorgang, bei dem eine Intervention zwischen im Konflikt befindlichen Parteien erfolgt, um
Abstimmungen oder Kompromisse zu ermöglichen. Es sind drei allgemeine Abstimmungsformen in verteilten Systemen
erforderlich. Dazu kommen serviceorientierte Lösungen.
-
Schnittstellenvermittlung. In der objekt- oder komponentenbasierten Systemschnittstelle ist die Vermittlung
die Änderung zwischen den Operationsdefinitionen von Sender und Empfänger. In einer serviceorientierten Lösung wird
das als Diskrepanz zwischen den Nachrichteninhalten bzw. -schemata von Sender und Empfänger betrachtet.
-
Protokollvermittlung. Die meisten objekt- oder komponentenbasierten Lösungen basieren häufig auf einem
allgemeinen Protokoll oder einer Protokollgruppe für Kommunikation. In serviceorientierten Lösungen ist eine
Mischung von Protokollen in der gesamten Lösung üblich, was einen der Vorteile der Architektur darstellt. Die
Kommunikation zwischen Services und Nachrichten muss verschiedene Protokolle zwischen Sender und Empfänger
umfassen.
-
Operationsvermittlung. Diese Form der Vermittlung ist Entwicklern möglicherweise vertraut. Sie bezieht sich
auf das allgemeine Strategiemuster. Eine Komponente kann aus einer Gruppe von Implementierungen eines
bestimmten Service oder einer bestimmten Operation auswählen. Die Auswahl basiert auf Laufzeitparametern oder dem
Inhalt der Anfrage. Dieser Vorgang wird auch als inhaltsbasierte Weiterleitung bezeichnet.
Ein wichtiger Punkt ist, dass immer mehr Middleware-Plattformen Funktionen für erweiterte Vermittlung bereitstellen,
ohne dass explizite Vermittlungskomponenten entwickelt werden müssen. In diesem Fall kann die Middleware, während sie
Abweichungen in der Datenstruktur oder in den Kommunikationsprotokollen ermittelt, die Vermittlung in ihrer Laufzeit
durchführen. Diese Plattformen können auch Mediatoren bereitstellen, die basierend auf Nachrichteninhalt und
Geschäftsregeln als Schalter fungieren, mit denen die richtige Implementierung einer bestimmten Konsumentanfrage
ausgewählt werden kann.
Hinsichtlich der Verbindung von Services, bei denen Nachrichtendefinitionen nicht übereinstimmen oder Nachrichten
zwischen Sender und Empfänger konvertiert werden müssen, kann eine von den UML-2.0-Aktivitäten bereitgestellte Funktion
zur Bezeichnung dieser Konvertierung verwendet werden. Diese Funktion, die Zuordnung eines UML-2.0-Verhaltens zu einem
Objektfluss zwischen zwei Aktionen, erlaubt es, ein wiederverwendbares Konvertierungsverhalten zu identifizieren, das
eine Nachricht in eine andere umsetzen kann (in der UML-2.0-Spezifikation heißt es genau: Changes or replaces data
tokens flowing along edge).
Die Konvertierung ist, wie oben beschrieben, ein wiederverwendbares Element. Daher kann sie für die Umsetzung eines
Nachrichtentyps in einen anderen identifiziert und anschließend nach Bedarf verwendet werden, um Nachrichten zwischen
einem Sende- und einem Empfangsservice zu vermitteln. UML stellt zwar Aktionen bereit, die das Lesen und Aktualisieren
einer Struktur erlaubt und mit denen man in der Struktur navigieren kann, diese sind jedoch relativ komplex und können
sich für die Definition von Konvertierungen als zu komplex herausstellen. Es wird erwartet, dass die Umsetzung eine
kompaktere Darstellung (z. B. Sprache XSL/T) bietet oder dass eine neue Methode zum Ausdrücken von UML-Aktionen
bereitgestellt wird.
Die Datenvermittlung kann auch als konkretes Muster der Serviceiteration behandelt werden. Beispielsweise gibt es einen
expliziten Vermittlungsservice, der für die Implementierung einer oder mehrerer Datenkonvertierungen zuständig ist. In
diesem Fall muss der Vermittler vom Konsumenten gesendete Nachrichten beantworten, die Nachricht konvertieren und an
den Service übergeben, wie unten dargestellt.
Die Vermittlung von Protokollen ist andererseits gut bekannt und wird im Modell explizit unterstützt. Da die
Protokolldaten als Bindung für einen Servicekanal angegeben sind, besteht die Möglichkeit, zusätzliche Modellelemente
entweder des <<Service>> oder des <<Service-Gateway>> einzuführen, die die Protokollspezifikation
ändern. Beispielsweise können Sie im folgenden zusammengesetzten Strukturdiagramm zwei Partitionen sehen, eine für
Webfacing-Services und eine für interne Services, und es gibt einen Servicekanal zwischen den Partitionen mit der
Bindung "HTTP-SOAP", die für Webfacing-Services typisch ist.
Das Problem ist, dass zur Unterstützung der erforderlichen Leistungsstufe und anderer nicht funktionaler Anforderungen
die gesamte Kommunikation in der internen Partition über plattformspezifische Protokolle stattfindet. Das folgende
Diagramm zeigt, wie ein Service über das Java-RMI-Protokoll mit dem Service-Gateway "Port : ISvcTwo" verbunden wird.
Warum aber wird die Webpartition über HTTP-SOAP mit demselben Gateway verbunden?
Die Antwort ist, dass das Service-Gateway selbst das Protokoll vermitteln kann, indem es Nachrichtenstrukturen und
Aufrufe von einem Format in ein anderes konvertiert. Das ist allgemeine Funktionalität, die normalerweise von
Middleware wie Object-Request-Brokern (ORBs) oder Nachrichten-Brokern bereitgestellt wird. Tatsächlich wäre es bei
Bedarf möglich, solche Middleware über Generation im Modell zugänglich zu machen, oder "Port : ISvcTwo" als
eigenständigen Service zu verwenden, der Aufrufe von der Webpartition annimmt und erneut an die eingeschlossenen
Services sendet.
Es sei noch einmal darauf hingewiesen, dass die Vermittlung explizit als Service und nicht als Service-Gateway
modelliert wird, der die richtige Schnittstelle mit der Bindung auf Konsumentenseite zugänglich macht und die
Implementierung an den Providerservice mit einer anderen Bindung delegiert.
Wie in der Einführung beschreiben ist es üblich, eine Struktur zu definieren, in der ein Service von einem anderen
Service abhängig ist, um eine bestimmte Operation ausführen zu können. Der tatsächliche Service, der für eine bestimmte
Anfrage aufgerufen wird, ist jedoch von Einzeldaten in der Anfrage abhängig. Wichtig ist, wer die Anfrage abgesetzt
hat, und welche Geschäftsregeln mit diesen Informationen angewendet wurden. Als Beispiel eignet sich normalerweise eine
Kundenanfrage, der empfangende Service kann je nach Kundenebene eine von zwei Implementierungen auswählen.
Beispielsweise könnten Kunden, die mehr Geld ausgeben, eine bevorzugte Behandlung erhalten.
Wie zuvor schon beschrieben, ist es bei dieser Art von Vermittlung wichtig, den Versuch zu unternehmen, die Regeln, die
für die Auswahl einer oder mehrerer Provider der konkreten Operationsimplementierung verwendet werden, zu
externalisieren. Im obigen Diagramm wird das als Regelkomponente, die dem Vermittlungsservice zugeordnet ist,
dargestellt. Es besteht die Möglichkeit, die Lösung als Gruppe von Services zu erstellen, bei der der Mediator, die
Regeln und alle Implementierer separate Services sind. Das wird im Folgenden erläutert.
Wie Sie sehen können, ist die Vermittlungskomponente nicht nur Eignerin ihrer realisierten Servicespezifikation,
sondern auch einer Servicespezifikation, die von allen Services, die sie vermittelt, implementiert werden muss. Das
bietet die Möglichkeit, die zusammengesetzte Struktur des Service (siehe oben) und das unten dargestellte dynamische
Verhalten zu definieren. Beachten Sie, dass in der oben dargestellten Struktur der Teil, der die vermittelten Services
darstellt, von der erforderlichen Schnittstelle bezeichnet und mit unbegrenzter Multiplizität dargestellt wird.
Es sei noch einmal darauf hingewiesen, dass diese Art von inhaltsbasierter oder regelbasierter Nachrichtenweiterleitung
von der Middleware-Plattform, die als Bestandteil der Lösungsarchitektur ausgewählt wurde, durchgeführt werden kann.
|