Richtlinie: Servicekomponentenmuster
Diese Richtlinie demonstriert eine Reihe von Mustern, die bei der Entwicklung von Servicekomponenten für die Realisierung von Services verwendet werden können.
Beziehungen
Hauptbeschreibung

Einführung

Durch das Zerlegen einer Servicekomponente in ihre funktionalen und technischen Bestandteile haben wir die von der Servicekomponente für die funktionalen Zuständigkeiten des Subsystems bereitgestellte Funktionalität delegiert. Funktionale Komponenten stellen die erforderliche Geschäftsfunktionalität zur Verfügung, technische Komponenten dagegen die generische Funktionalität, zu der Authentifizierung, Fehlerbehandlung, Überwachung, Protokollierung usw. gehören. Die generische Funktionalität ist operational und nicht funktional ausgerichtet.

Ein Servicemodell ist ein Artefakt der Designzeit. Als solches interagiert es nicht direkt mit der Serviceimplementierung. Die tatsächliche Implementierung eines Service oder einer Servicegruppe wird von der Realisierung einer Servicespezifikation durch eine Servicekomponente ausgeführt. Die Servicespezifikation stellt den Implementierungsvertrag bereit. Welche Technologie oder welches Verfahren für die Implementierung des Service verwendet wird, ist irrelevant, sofern der Vertrag erfüllt wird. Im Konzept Serviceorientierte Architektur wurde die folgende Abbildung vorgestellt, die die Beziehung zwischen den identifizierten Services und den Komponenten und Objekten, die die Implementierung dieser Services bereitstellen, demonstriert.

 Im Begleittext beschriebene Abbildung

So ist erkennbar, wie das Designmodell von RUP verwendet werden kann, um das Design der Komponenten- und Objektschichten zu erfassen. Zu diesen gehören Implementierungsmodelle und -artefakte, die Details der Objektschicht und der zugeordneten Implementierungs- und Deployment-Artefakte erfassen. Wichtige Aspekte der Beziehung zwischen dem Servicemodell und dem Modell des Komponentendesigns sind folgende: Die Servicespezifikationen stellen Verträge dar, die erfüllt werden müssen; Operationen, die in Spezifikationen identifiziert werden, müssen auf AS-IS-Basis implementiert werden, und Servicekonsumenten verwenden dasselbe Modell, um die Schnittstelle und das Verhalten der Services, die sie verwenden möchten, zu verstehen. Im Grunde genommen gibt es eine direkte 1:1-Beziehung zwischen der Servicespezifikation und einem Implementierungsartefakt, das für den Service als Eingangspunkt der Erstimplementierung fungiert.

Prüfen Sie z. B. das folgende Diagramm eines Serviceproviders, das die Details von Modellelementen, die in dieser Definition verwendet werden, zeigt.

Im Kontext beschriebene Abbildung

Der Schlüssel zur Verwendung dieser Servicekomponente ist, sie direkt zum Servicemodell zurückzuverfolgen. Am einfachsten ist es, wenn Sie den Umstand nutzen, dass das Element der Servicespezifikation eine UML-Schnittstelle ist, die von der Servicekomponente realisiert wird und so die Konformität des Elements mit der strukturellen Spezifikation sicherstellt. Das Ergebnis wäre folgendes:

Im Kontext beschriebene Abbildung

Es liegt jetzt in der Zuständigkeit desjenigen, der die Komponente implementiert, eine Gruppe von Komponenten und Klassen zu definieren, die das Verhalten der entstehenden Komponente bestimmen.

Arten von Servicekomponenten

Funktionale Komponenten

Die Komposition dieser funktionalen Komponenten zu einer übergeordneten Servicekomponente ist keine rein strukturelle Zusammensetzung. Es wird auch ein Ablauf definiert, d. h. die Kollaboration der funktionalen Komponenten, um die Funktionalität zur Unterstützung des Geschäftsprozesses bereitzustellen. Wie wir bereits festgestellt haben, wird die Funktionalität dieser geschäftsbezogenen Komponenten über die definierten Services aktiviert (die von der detaillierteren Objektstruktur oder herkömmlichen Systemstruktur der Komponente implementiert werden).

Es ist wichtig, dass Sie erkennen, dass dieser Schritt auch traditionelle OOAD-Aktivitäten umfasst. Wir haben einen fokussierten und gut gegliederten Geltungsbereich für die Steuerung des Objektdesigns. Beim traditionellen objektorientierten Design gibt es eine Tendenz, größere und abhängigere Objektdiagramme zu erstellen. Wenn auf die Identifikation von Funktionsbereichen innerhalb des Geschäfts jedoch eine Subsystemanalyse folgt, liegt ein sehr klar definierter Geltungsbereich vor, auf den wir uns konzentrieren und unsere Designbemühungen ausrichten können. Diese Bemühungen münden dann in einer Reihe sehr lose miteinander verbundener Objektmodelle (durch Systemanwendungsfälle ausgelöste Klassendiagramme und Ablaufdiagramme).

Technische Komponenten

Technische Komponenten werden wie funktionale Komponenten zu übergeordneten Servicekomponenten zusammengesetzt. Technische Komponenten wie die Authentifizierung, Protokollierung und Berichtserstellung können geschäftsprozessübergreifend verwendet werden. Diese allgemeinen Komponenten werden für die Infrastruktur zur Unterstützung der funktionalen Komponenten benötigt. Ein Hauptgrund für Variationen bei Geschäftsprozessen sind Geschäftsregeln. Dies ist in der folgenden Abbildung "Unternehmenskomponentenmuster" dargestellt. Diese Variationen werden in der Regel beim variationsorientierten Design erfasst.

Servicekomponentenmuster

Es wurde gesagt, dass die Servicekomponente einfach die Servicespezifikation realisiert. Allerdings hat der Implementierer wenig Unterstützung, wenn er von einer allgemein definierten Servicedefinition zu einer Gruppe differenzierter Implementierungsklassen und -artefakte wechselt, die erforderlich sind, um das Verhalten des Service zu bestimmen. In diesem Zusammenhang verlässt er sich üblicherweise auf Muster, die der entstehenden Servicekomponente eine Struktur geben, in Form eines anfänglichen Framework oder spezifischer Muster, um bestimmte strategische Anforderungen zu berücksichtigen.

Musterauswahl, NFR-gesteuert, Architektur [mehr]

Die zusätzlichen Stereotypen, die hier eingeführt werden, sind im Artefakt Servicekomponente beschrieben.

Basismuster für Servicekomponenten

Bei der Definition der anfänglichen Struktur eines Service wird das folgende Muster als Ausgangspunkt für die Anpassung und Fertigstellung bereitgestellt.

Im Kontext beschriebene Abbildung

Die Elemente dieses Musters sind:

  • Fassadenkomponente. Die Fassade realisiert dieselbe Schnittstelle wie die Servicekomponente selbst und stellt grundlegende Funktionen für die Nachrichtenvalidierung bereit, bevor sie die Anfrage zur Ausführung an die pro Operation verwendeten Komponenten übergibt. In diesem Fall wird die Komponente zur Klarstellung mit dem Stereotyp <<Facade>> versehen.
  • Pro Operation verwendete Komponente. Aufgrund der Unterteilung der Services ist es in den meisten Fällen nützlich, eine separate Komponente bzw. Klasse für die Implementierung der einzelnen vom Service bereitgestellten Operationen zu haben.

Im Folgenden wird die Sicht der zusammengesetzten Struktur dieses Musters veranschaulicht. In diesem Falle wird die Fassade an die Servicekomponente selbst delegiert. An sich werden Konsumenten, die Operationen für die Servicekomponente aufrufen, von der Fassadenkomponente bedient. Beachten Sie, dass auch UML-2.0-Ports verwendet werden können, um die Schnittstellen verfügbar und die Delegierung mit Konnektoren explizit zu machen.

Im Kontext beschriebene Abbildung

Servicekomponentenmuster für eine Einzeloperation

In einigen Fällen, in denen Services mit mehreren Operationen im Servicemodell identifiziert werden, ist es besser, die Operationen einzeln als eigenständige Services zu implementieren und die Sichten für die logischen und die physischen Services zu trennen. Ein solches Muster hat Vorteile hinsichtlich der Flexibilität, der Quellenermittlung, der Versionssteuerung und der Weiterentwicklung, verzichtet jedoch auf die Kategorie der Schnittstelle zu Gunsten eines Service als Gruppe zusammengehöriger Operationen.

Bei der Modellierung von Servicekomponenten gemäß diesem Muster wird nur eine <<Servicekomponente>> verwendet, die eine Schnittstelle mit einer Einzeloperation realisiert. Die Benennung erfolgt in Übereinstimmung mit allgemeinen Konventionen, die nachfolgend dargestellt sind.

Im Kontext beschriebene Abbildung

In diesem Fall gibt es, wie erwähnt, keine direkte Realisierung der ursprünglichen Servicespezifikation durch ein Element im obigen Muster. Daher scheint es lohnend zu sein, ein Element in das Modell einzuführen, das die Rückverfolgbarkeit zur Servicespezifikation gewährleistet. Im folgenden Beispiel wird eine Komponente mit dem Stereotyp <<Subsystem>> eingeführt, die laut Beschreibung die Servicespezifikation implementiert und auch Eignerin der oben beschriebenen Elemente ist.

Im Kontext beschriebene Abbildung

Dieses Muster führt auch nicht die Komponente <<Fassade>> ein, da Servicekonsumenten die Verantwortung dafür tragen, die Services, die sie nutzen, zu identifizieren.

Muster für vermittelte Operationen

Wenn es eine Möglichkeit gibt, die Anfrage eines Servicekonsumenten zur Ausführung an eine Auswahl von Operationskomponenten weiterzuleiten, kann das Muster mit einem Mediator erweitert werden, um diese Nachrichten weiterzuleiten. Sehen Sie sich dazu die folgende Abbildung an. Beachten Sie, dass die Komponente bzw. Klasse zur Klarstellung mit dem Stereotyp <<Mediator>> versehen wird. Der exakte Mechanismus für die Vermittlung ist nicht definiert. Eine statische Gruppe von Implementierungen könnte vorab definiert werden, eine Registry könnte ebenfalls verwendet werden, um eine Zuordnung zu einer bestimmten Implementierung vorzunehmen, basierend auf Konsument, Anfragenachricht usw. Dieses Muster ist nicht für die Verwendung mit dem Muster für Einzeloperationen vorgesehen.

Im Kontext beschriebene Abbildung

Das betrifft auch die Sicht für die zusammengesetzte Struktur der Servicekomponente. Wie unten dargestellt, verläuft die Mediatorverbindung über die Fassade, die sie verwendet, um Aufrufe an die Operationskomponente zu leiten.

Im Kontext beschriebene Abbildung

Wenn eine Registry außerhalb des Mediators selbst verwendet wird, ist es eventuell nicht möglich, in den verschiedenen Teilen des zusammengesetzten Strukturdiagramms statische Abhängigkeiten zwischen Mediator, Operationskomponenten oder Konnektoren aufzuzeigen. Wie also kann eine Abhängigkeit des Mediators von den vermittelten Operationskomponenten modelliert werden? Im folgenden Diagramm wurde eine Schnittstelle eingeführt, die von jeder Operationskomponente implementiert werden soll. Anschließend kann die Verwendung vom Mediator bis zur Schnittstelle, wie unten dargestellt, modelliert werden.

Im Kontext beschriebene Abbildung

Außerdem wird die Beziehung im zusammengesetzten Strukturdiagramm geändert, das einen neuen, durch die Schnittstelle typisierten Teil enthält. Die Multiplizität zwischen dem Mediator und den Operationskomponenten im Konnektor wird wie in der folgenden Abbildung dargestellt.

Im Kontext beschriebene Abbildung

Komponenten für Datenzugriff

Wenn Serviceoperationen gemeinsame Datenanforderungen haben, kann es außerdem nützlich sein, die spezifischen Komponenten hervorzuheben, die Datenmanagementfunktionen für die Implementierung bereitstellen. Beachten Sie, dass die Komponente bzw. Klasse zur Klarstellung mit dem Stereotyp <<Data Access>> (Datenzugriff) versehen wird.

Im Kontext beschriebene Abbildung

Unternehmenskomponentenmuster

Das folgende Unternehmenskomponentenmuster zeigt die Servicekomponente als Fassade für die zugrunde liegenden funktionalen und technischen Komponenten. Services werden an der Außengrenze der Servicekomponente, auf der Komponentenfassade, verfügbar gemacht. Serviceanfragen auf der Fassade werden an einen Mediator gesendet, der die Nachricht dann an die entsprechende funktionale oder technische Komponente weiterleitet.

Im Begleittext beschriebene Abbildung

Unternehmenskomponentenmuster

Die Abhängigkeiten der funktionalen Komponenten von den technischen Komponenten und ihre Anforderungen an die technischen Komponenten sind unten am Beispiel "Rent-a-Car" dargestellt.

Im Begleittext beschriebene Abbildung

Servicekomponente "Reservierung" von Rent-a-Car unter Verwendung des Musters Unternehmenskomponente

Aus den Subsystemkomponentenmodellen wird das Modell der funktionalen Komponenten zusammengestellt, das die Abhängigkeit der funktionalen Komponenten von den technischen Komponenten und die Wechselwirkungen zwischen den funktionalen Komponenten zeigt. Untergeordnete, in der Hierarchie als Blattknoten dargestellte Prozesse, die der Subsystemfassade zugeordnet sind, müssen als vom Subsystem bereitgestellte Services spezifiziert werden. Diese untergeordneten Prozesse werden durch eine detailliertere Gruppe von Systemanwendungsfällen unterstützt und implementiert, die in die Struktur des Subsystems eingebunden sind. Die funktionalen Komponenten bilden die Voraussetzung für die Realisierung der Anwendungsfälle, sind jedoch hinsichtlich ihrer Infrastrukturanforderungen auf die technischen Komponenten und Dienstprogramme angewiesen.