Richtlinie: Servicevermittlung
Diese Richtlinie beschreibt Methoden, mit denen die Kommunikation zwischen inkompatiblen Konsumenten und Services über Vermittlung ermöglicht wird. Dazu werden Konsumentenanfragen oder -protokolle in Formate umgesetzt, die von Serviceprovidern verstanden werden können.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Einführung

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.

Datenvermittlung in Aktivitäten

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.

Diagramm ist im Textinhalt beschrieben.

Protokollvermittlung in Service-Gateways

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.

Diagramm ist im Textinhalt beschrieben.

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?

Diagramm ist im Textinhalt beschrieben.

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.

Aufrufvermittlung mit Servicezusammenstellung

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.

Diagramm ist im Textinhalt beschrieben.

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.

Diagramm ist im Textinhalt beschrieben.

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.

Diagramm ist im Textinhalt beschrieben.

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.