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. |
Disziplinen: Implementierung |
|
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
Rollen | Primärer Ausführender:
| Zusätzliche Ausführende:
|
Eingaben | Verbindlich:
| Optional:
|
Ausgaben |
|
Prozessverwendung |
|
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.
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.
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".
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.
|
|
Weitere Informationen
© Copyright IBM Corp. 1987, 2006. Alle Rechte vorbehalten.
|
|