Aufgabe: Entscheidungen zur Servicerealisierung dokumentieren
Das Hauptaugenmerk dieser Aufgabe liegt auf der Realisierung eines Servicemodells in Form von Softwarekomponenten, die in vorhandenen Middlewareumgebungen ausgeführt werden können.
Zweck

Ziel dieser Aufgabe ist die Erstellung eines Designmodells für die Implementierung, das Entwickler nutzen können, um Servicekomponenten für die Bereitstellung der erforderlichen Services zu implementieren.

Beziehungen
RollenHauptrollen: Zusätzliche Rollen: Unterstützende Rollen:
EingabenVerbindlich: Optional: Extern:
  • Ohne
Ausgaben
Hauptbeschreibung

Der Zweck des Servicemodells besteht primär darin, Services, deren Organisation, Kollaboration und detaillierte und vollständige Spezifikation zu identifizieren. Die Rolle Implementierung wird an das vorhandene Designmodell und insbesondere das Modellelement Servicekomponente von Rational Unified Process (RUP) delegiert. Im Allgemeinen wird das Servicemodell durch ein Designmodell realisiert. Es wäre jedoch möglich, Artefakte direkt aus dem Servicemodell zu generieren, in dem Spezifikationen erforderlich sind. Es kann auch sinnvoll sein, ein Anwendungsfallmodell aus dem Servicemodell zu erstellen, das eine weitere Beschreibung der Services vor der Konstruktion ermöglicht.

Schritte
Strategie für die Bezugsquellenermittlung bestimmen

Bei der Entscheidung, wie Services realisiert werden sollen, müssen eine Reihe von Alternativen überdacht werden (siehe folgende Abbildung). Es geht nicht einfach um die Entscheidung für Eigenleistung oder Einkauf, sondern um andere interessante Möglichkeiten, die ins Blickfeld rücken. Bei der Umwandlung wird eine Kombination verschiedener Verfahren angewendet. Eines dieser Verfahren ist das Extrahieren von Geschäftsregeln zur Isolierung eines Funktionalitätssegments, das unabhängig für die Realisierung des Service der Komponente genutzt werden soll. Beim Integrieren geht es um die Kapselung herkömmlicher Funktionalität für die Realisierung vorhandener Funktionen. Die Integration ist aufrufbasiert. Für die Subskription muss ein Publish/Subscribe-Modell (in einem nachrichtenorientierten Middlewarekontext) vorhanden sein, bei dem ein Konsument die vom Provider bereitgestellten Services abonniert. Eine der Möglichkeiten ist die Auslagerung der Funktionalität (z. B. der Lohnbuchhaltung) in ein anderes Unternehmen. Mit zunehmender Verbreitung von Web-Services und der Business-to-Business-Integration werden sich mehr Bereiche dieser Möglichkeit öffnen.

  • Eigenleistung - Aus verschiedenen Gründen wird entschieden, grünes Licht für die unternehmensinterne Entwicklung des Service zu geben.
  • Einkauf - Es wird ein Service gekauft, der intern implementiert und betrieben werden kann.
  • Umwandlung - Es wird eine Kombination verschiedener Verfahren angewendet. Eines dieser Verfahren ist das Extrahieren von Geschäftsregeln zur Isolierung eines Funktionalitätssegments, das unabhängig für die Realisierung des Service der Komponente genutzt werden soll.
  • Subskription - Diese basiert auf der Verfügbarkeit eines Publish/Subscribe-Modells (in einem nachrichtenorientierten Middlewarekontext), bei dem ein Konsument die vom Provider bereitgestellten Services abonniert.
  • Integration - Es geht um die Kapselung herkömmlicher Funktionalität für die Realisierung vorhandener Funktionen. Die Integration ist aufrufbasiert.
  • Auslagerung - Mit zunehmender Verbreitung von Web-Services und der Business-to-Business-Integration werden sich mehr Bereiche dieser Möglichkeit öffnen.

Entscheidungen hinsichtlich der Servicerealisierung beziehen sich auf Servicekomponenten. Jede Servicekomponente kann als ein Funktionalitätscontainer betrachtet werden, der für die Realisierung eines Service benötigt wird, und setzt sich funktionalen und technischen Komponenten zusammen oder verwendet beide Arten von Komponenten, Die Entscheidung, wie diese Servicekomponenten realisiert werden, ist von Bedeutung. Hier geht es nicht nur um die Entscheidung für Eigenleistung oder Einkauf. Weitere Aspekte müssen in Betracht gezogen werden, wozu unter anderem folgende gehören:

  • Eine Umwandlung, bei der es um die Extraktion von Regeln oder die Erstellung eines Klons von vorhandenem Code gehen kann, der dann für den Einsatz als Komponente mit definierter Schnittstelle umgeschrieben wird
  • Eine Integration in das Messaging oder in Wrapper

Beispiel

Wir wollen hier die Realisierungsentscheidungen für das Beispiel "Rent-a-Car" erfassen, obwohl dies in dem UML-Modell, das wir in einer Reihe von Beispielen verwendet haben, nicht einfach sein wird. Zur Unterstützung kann die Vorlage "Realisierungsmatrix" verwendet werden, um die Ergebnisse der Entscheidungen zu dokumentieren. Vergleichen Sie hierzu die folgende Abbildung.

Entwicklungsstrategie bestimmen

Der Vorteil der beschriebenen Möglichkeiten besteht darin, dass unabhängig von der ausgewählten Möglichkeit eine Verbindung zwischen ihnen besteht, die die Rückverfolgbarkeit des Anwendungsfallmodells zu einem Designmodell und dann zur Implementierung ermöglicht.

Im Begleittext beschriebene Abbildung

Es wird empfohlen, das Servicemodell mit einem Designmodell zu realisieren. Das bietet dem Designer und Implementierer die Möglichkeit, Muster auf das Designmodell anzuwenden und zusätzliche Funktionen und Strukturen zu modellieren, bevor sie Implementierungsartefakte generieren.

Differenzierte Zuordnung vorhandener Assets

Man darf nicht vergessen, dass nur sehr wenige Lösungen ohne Untersuchung vorhandener Anwendungen erstellt werden, die entweder Funktionen zur Unterstützung der Lösung bereitstellen oder die Interaktion mit der Lösung erfordern. Daher ist es wichtig, dass vorhandene traditionelle Anwendungen, die als Teil aller Lösungen wiederverwendet werden, katalogisiert und hinsichtlich ihrer Funktionalität identifiziert werden. Mit einer serviceorientierten Lösung gibt es verschiedene Wege, um neue Services in vorhandene Funktionen zu integrieren. Diese werden in der Abbildung unten veranschaulicht:

  • Vorhandene Funktion als Service packen. In diesem Fall versucht man, die Funktion unverändert zu lassen, jedoch Tools oder Middleware zu verwenden, um die vorhandene Funktion als Service verfügbar zu machen. Beispielsweise bietet IBM die Möglichkeit, traditionelle CICS-Transaktionen als SOAP-Web-Services verfügbar zu machen.
  • Vorhandene Funktion packen und durch einen Service ersetzen. In diesem Fall wird eine Funktion wie oben eingeschlossen, die entstehende Servicespezifikation wird jedoch eingesetzt, um den Service zu einem späteren Zeitpunkt erneut zu entwickeln, wobei der ursprüngliche Service ersetzt wird und Clients zur neuen Implementierung umgeleitet werden.
  • Adapter verwenden, die in Bezug auf Serviceaufrufe toleranter sind. In einigen Fällen ist es nicht möglich, eine Funktion wiederzuverwenden und als Service verfügbar zu machen, es besteht jedoch die Möglichkeit, die Funktion in ein Element einzuschließen, das einfacher zu integrieren ist, z. B. in eine Schnittstelle für Nachrichtenwarteschlangen oder in die JCA (Java Connector Architecture). Das bietet neuen Services die Möglichkeit, auf die bestehende Funktion zuzugreifen.
  • Die Funktion in den Service integrieren. Offensichtlich besteht in einigen Fällen für den neuen Service die Möglichkeit, auf die bestehende traditionelle Funktion zuzugreifen, indem man die Funktion als logische Komponente innerhalb der Serviceimplementierung verwendet.

Im Begleittext beschriebene Abbildung

Es sollte berücksichtigt werden, dass die dritte und vierte Möglichkeit die größte Flexibilität bieten, da sie die vorhandene Funktion verwenden, sie jedoch nicht länger ungeändert für Clients verfügbar machen. Andererseits können die erste und die zweite Möglichkeit auch zu Problemen mit dem Packen vorhandener Funktionen führen, da die Leistung von Web-Services-Protokollen und Diskrepanzen zwischen nativen Datenformaten und XML Leistungsengpässe bewirken können.

Vorhandene Softwareressourcen sowie deren Abhängigkeiten und Schnittstellen müssen analysiert werden, um festzustellen, ob für die Unterstützung der Geschäftsfunktionalität Änderungen erforderlich sind. Wenn es beispielsweise um die Erstellung einer Web-Services-Schnittstelle für die herkömmliche Implementierung einer Geschäftsfunktion geht, könnten im Rahmen der Analyse die Komposition und der Ablauf von Onlinetransaktionen oder Stapeljobs untersucht werden oder persistente Datenspeicher, die an der Ausführung der Funktion beteiligt sind. Möglicherweise muss zur Unterstützung der Funktionalität das aktuelle Design der vorhandenen Anwendungen geändert werden. Darüber hinaus müssen alle potenziellen Hindernisse für die Erstellung einer Web-Services-Schnittstelle mit der gewünschten Servicequalität identifiziert werden. Eine monolithische Stapelimplementierung einer Geschäftsfunktion könnte beispielsweise, wenn sie als Service aufgerufen wird, eine Antwortzeit von weniger als einer Sekunde erfordern.   

Vorhandene Assets als Servicemuster packen

In einigen Fällen ist es angebracht, eine traditionelle Servicepartition zu entwickeln, auf der untergeordnete traditionelle Funktionen einzeln als Services verfügbar gemacht werden. Diese Partition ist nur für Services höherer Ebene zugänglich, die sie verwenden, um Konsumenten eine stärker unterteilte, geschäftlich ausgerichtete Spezifikation zu präsentieren. Diese Kapselung der traditionellen Funktionen sollte man als temporäre Lösung betrachten und nur in Angriff nehmen, wenn man mit den Leistungsmerkmalen der Wrapping-Technologie vollständig vertraut ist. Weitere Informationen finden Sie im Konzept Lösungspartitionierung.

Eine Möglichkeit, die Kapselung einer traditionellen Funktion zu untersuchen, besteht in einer sehr vereinfachten Form des Modellelements Serviceprovider mit einem einzelnen Service, der eine einzelne Spezifikation mit nur einer Operation realisiert. Das folgende Diagramm veranschaulicht dieses Muster für die traditionelle Funktion "UpdateCustomerAddress".

 Im Kontext beschriebene Abbildung

Bei der Anpassung dieses Musters können Sie wie folgt vorgehen:

  • Es ist wahrscheinlich, dass von derselben Komponente eine Gruppe vorhandener Funktionen bereitgestellt wird, damit derselbe Serviceprovider verwendet wird.
  • Das obige Muster wurde automatisch generiert; es kann besser sein, den Namen der Standardoperation "exec${service}" zu ändern.
  • Analog dazu wäre es nützlich, die generierten Standardnachrichten umzubenennen. Außerdem sollten an diesem Punkt die Nachrichtenstrukturen modelliert werden.
  • Das Standardmuster setzt voraus, dass die Operation eine Nachrichteneingabe bekommt und eine Nachricht zurückgibt. Es kann sein, dass die traditionelle Funktion keine Nachricht zurückgibt oder nur eine Benachrichtigung absetzt und dass die Signatur der generierten Operation verbessert werden muss.
  • Der Architekt/Designer muss sicherstellen, dass im Serviceprovider die richtigen Werte für die Eigenschaft "allowedBindings" angegeben sind.
Eigenschaften
Mehrere Vorkommen
Ereignisgesteuert
Fortlaufend
Optional
Geplant
Wiederholt anwendbar
Weitere Informationen