Beispiel: Beispiel für SOA-Modell

Problembeschreibung Seitenanfang

Dieses Beispiel befasst sich mit den Problemen eines Einzelhändlers, der bestimmte Funktionen, die von den Anwendungen in den PoS-Terminals (Point-of-Sale) als Services genutzt werden, erneut implementieren möchte. Heute wird die Handelsanwendung (Trading Application, TA) als monolithische Anwendung mit sehr eng gekoppelten Komponenten entwickelt. Von diesen Komponenten befinden sich einige auf In-Store-Servern (ISS), und einige Anforderungen werden von diesen Servern sogar zu zentralen Servern im Unternehmen weitergeleitet. Das Problem besteht darin, dass die Infrastruktur des Speichers im Allgemeinen und die Handelsanwendung im Besonderen aufgrund der engen Kopplung der Komponenten und der Verwendung proprietärer Protokolle und Technologien bei der Entwicklung von Komponenten und der Verbindung zwischen ihnen zuweilen schwierig zu pflegen ist.

Bei vorherigen Generationen von Handelssystemen wurden proprietäre Maschinen mit niedriger Kapazität für die PoS-Terminals verwendet, und es gab Einschränkungen hinsichtlich der Bandbreite sowohl im Handelssystem als auch außerhalb. Diese Einschränkungen bestehen nun weitestgehend nicht mehr. Dieser Umstand und die Verlagerung hin zu serviceorientierter Architektur in Back-End-Systemen von Unternehmen hat dazu geführt, dass man entschied, einige der Funktionen des ISS und zentraler Server den Handelssystemen als Services bereitzustellen.

Projektumfang und -ziele Seitenanfang

Anfänglich werden die zu berücksichtigenden Funktionen ausgewählt, weil sie ein gemeinsames Muster haben hinsichtlich des Umstands, dass sie Logik in der Handelsanwendung benötigen, die Informationen aus mehreren Datenspeichern abruft. Daher stellen die vorgeschlagenen Services nicht nur eine gemeinsame Schnittstelle zur Verfügung, es ist auch nicht mehr erforderlich, dass die Handelsanwendung die Datenposition genau kennt und mehrere Protokolle handhaben muss. Die Handelsanwendung greift mit RMI auf den ISS-Service zu und ISS mit SOAP over JMS auf den zentralen Service.

Serviceidentifikation Seitenanfang

Im Folgenden werden die Schritte umrissen, die bei der Entwicklung serviceorientierter Lösungen von dem Architekturteam, das sich aus Mitgliedern der eigenen IT-Abteilung des Einzelhändlers und externen, als Experten hinzugezogenen Beratern zusammensetzt, ausgeführt werden. Beachten Sie, dass die folgenden Schritte nicht eine empfohlene Serie von RUP-Aktivitäten darstellen, sondern lediglich die Aktivitäten eines konkreten Projekts katalogisieren sollen.

Wichtig ist, dass dieses Projekt die technische Implementierung gegenwärtig vorhandener Funktionen verbessern soll und daher nicht viel Zeit für die Geschäftsmodellierung oder -analyse aufwendet, da die für die ursprüngliche Handelsanwendung erstellten Modelle wiederverwendet werden können. Die aktuelle Modellgruppe (im folgenden Diagramm auf der linken Seite) folgt der unten dargestellten Struktur und zeigt ein RUP-Anwendungsfallmodell, ein Analysemodell für die allgemeinen Komponenten der Handelsanwendung, gefolgt vom detaillierten Designmodell und schließlich von einer Gruppe von Implementierungsmodellen für die Java-Entwicklungsteams.

Diagramm ist im Textinhalt beschrieben.

Das Servicemodell wurde (im obigen Diagramm auf der rechten Seite) als Präzisierung des Analysemodells zu einer Gruppe von Services mit eigenen Implementierungsmodellen eingeführt. Das Design der Handelsanwendung kann jetzt dahingehend modifiziert werden, dass die Verwendung dieser allgemeinen Services und die Beziehung zwischen der Handelsanwendung und den Java-Modellen des Service ebenfalls gezeigt werden.

Erstellung des Servicemodells

Das Store Support Service Model wurde gemäß dem UML-Profil für Softwareservices und einem Schablonenmodell (das in Rational Software Architect enthalten ist) erstellt, wie im folgenden Diagramm dargestellt. Das Modell wurde als Verbesserung des Analysemodells identifiziert, wie oben dargestellt. Wie zu sehen ist, wird die Struktur in einem Übersichtsdiagramm gezeigt, das die Abhängigkeiten zwischen den von der Schablone empfohlenen Sichten veranschaulicht.

Diagramm ist im Textinhalt beschrieben.

Die Diagrammlinks neben den Sichtpaketen ermöglichen eine schnelle Navigation im Modell und werden in den folgenden Abschnitten vervollständigt.

Weitere Informationen finden Sie im Toolmentor Servicemodell in RSA erstellen.

Servicepartitionen (Lokalität) identifizieren

Anhand der Beschreibung des Problems wird deutlich, dass es verschiedene Methoden gibt, das System zu partitionieren. Beispielsweise können Partitionen eingeführt werden, die das Bestandsmanagement, das Service-/Garantiemanagement und PoS-Operationen (Preissuche, Kunde etc.) darstellen. Für den Architekten sind das allerdings nicht die wichtigsten Probleme, daher stellen die dem Modell hinzugefügten Partitionen logische Lokalitäten für die Services dar, die entweder in der Filiale oder auf Unternehmensebene bereitgestellt werden.

Diagram ist im Text beschrieben.

Wenn man davon ausgeht, dass es sich dabei um logische Partitionen handelt, legt man fest, dass die Filialservicepartition eine Gruppe von Services enthält, die auf Filialebene instanziert werden, es wird keine Aussage über das physische Deployment dieser Services (einzelner Server, Cluster etc.) gemacht. Diese logischen Partitionen werden dem Architekten zur Verfügung gestellt, um die wichtigen Aspekte der Lösung zu repräsentieren.

Beachten Sie auch, dass der Architekt im obigen Bild ein zusätzliches Element, die Handelsanwendungselbst, eingeführt hat, damit die Kommunikation zwischen der Anwendung und den Services beschrieben werden können. Die Handelsanwendungist eine UML-2.0-Komponente mit dem Stereotyp Servicekonsument (Service Consumer).

Weitere Informationen finden Sie im Konzept Partitionierung der Lösung.

Vorhandene Funktionen analysieren

Der nächste Schritt besteht darin, die aktuelle Implementierung der Handelsanwendungzu analysieren und die Details des in der Problembeschreibung identifizierten Datenbankzugriffs zu prüfen. Die folgende Tabelle wird dann entwickelt (bitte beachten, dass nur Details für die Kunden- und Bestandsreferenzen enthalten sind).
 
Name Technologie Eingabe Ausgabe Kommentare
sp_get_custlist_by_phone Gespeicherte Prozedur des SQL-Servers phonenum (char 10) Liste:
custid (id)
custname (char 40)
Diese gespeicherte Prozedur gibt eine Liste mit Kundendaten nach Telefonnummer zurück, die Liste kann dem Kunden zur Auswahl angezeigt werden. Mit dem Aufruf sp_get_cust_details wird ein einzelner Satz mit Kundenstammdaten zurückgegeben.
sp_get_cust_details Gespeicherte Prozedur des SQL-Servers custid (id) Kundenstammdaten Die Einzeldaten eines Kunden, d. h. Name, Adresse, Kontaktinformationen usw. werden zurückgegeben.
CUST_QUERY IBM MQSeries phonenum (char 10)
return-queue-name (char 120)
correlation-id (char 120)
nicht anwendbar In diese Warteschlange stellt die Anwendung die Einzeldaten der abzufragenden Kunden, die Nachricht wird an die Zentrale geliefert, wo der Server die Antwortnachricht an die identifizierte Rückgabewarteschlange übergibt.
<Name_der_Rückgabewarteschlange> IBM MQSeries nicht anwendbar correlation-id (char 120)
Liste mit Kundenstammdaten
Bei der Rückgabe der Kundenstammdaten enthält die Rückgabenachricht auch die Korrelations-ID, um sicherzustellen, dass die Antwort einer bestimmten Anfrage zugeordnet werden kann. Das erlaubt dem Filialserver, eine einzige Rückgabewarteschlange für alle Terminals zu verwenden. Das Terminal fragt die Warteschlange nach einer Antwortnachricht ab, wozu sie deren Korrelations-ID verwendet.
sp_get_invstate_for_sku Gespeicherte Prozedur des SQL-Servers sku (char 13) Bestandsdaten
INVENTORY_QUERY IBM MQSeries sku (char 13)
return-queue-name (char 120)
correlation-id (char 120)
nicht anwendbar
<Name_der_Rückgabewarteschlange> IBM MQSeries nicht anwendbar Bestandsdaten

Wie man sehen kann, stellen diese Einträge die vorhandene Implementierung dar, die durch eine neue Implementierung ersetzt wird. Der Zweck und die Funktion bleiben erhalten.

Entwicklung einer ersten Servicespezifikation

Die Aktivität Serviceidentifikation führt eine Reihe von Techniken für die Identifikation der Services sowie der Operationen für Services aus, die zur Unterstützung einer Lösung erforderlich sind. Im Falle dieses Beispiels wird eine Art traditioneller Erneuerung, die Umwandlung vorhandener Funktionen in ein Servicemodell, insbesondere Technologie zur Implementierung von Services, in Augenschein genommen. Dabei wird zuerst die Gruppe der Servicespezifikationen entwickelt. Diese stellen die Verträge für die Services bereit, die die oben beschriebenen Funktionen implementieren. Das folgende Diagramm zeigt die drei gegenwärtig leeren Servicespezifikationen, die an diesem Punkt erstellt werden, einen für jeden der Services, die in der Einführung erläutert werden.

Diagramm ist im Textinhalt beschrieben.

Als Nächstes werden mögliche Verwendungsmuster für die Services analysiert. Beispielsweise ist es möglich, zwei Services zu verwenden, einen Filialservice und einen Unternehmensservice. Dabei ist die Logik sowohl für den Datenbankzugriff als auch den Unternehmenszugriff im Filialservice gekapselt. Alternativ dazu kann man in der Filiale einen Fassadenservice einsetzen, der die Logik kapselt und zwei identische Services aufruft, einen, der den lokalen Datenbankzugriff kapselt und den zweiten beim Unternehmen. Die zweite Option erhöht die Flexibilität für das Ändern der Logik, die auf die zwei Filialen zugreift, erhöht jedoch auch den System- und Kommunikationsaufwand für eine relativ einfache Funktion. Für die Kundensuche und die Bestandssuche wurde also die erste Option ausgewählt. Bis jetzt sind die Details der Verteilung von Services und Serviceprovidern nicht entschieden, und die Serviceidentifikation ist wesentlich effektiver, wenn sie sich nur auf Servicespezifikationen konzentriert.

Zur Identifikation der Rollen und Zuständigkeiten dieser Services werden eine Servicekollaboration und insbesondere ein zusammengesetztes UML-2.0-Strukturdiagramm, das die Konfiguration der Services für die Kundensuche repräsentiert, verwendet. Das Strukturdiagramm wird unten gezeigt, mit UML-2.0-Teilen, die die einzelnen Elemente in der Kollaboration darstellen. Beachten Sie, dass die Konnektoren zwischen der Handelsanwendungund dem Filialservice sowie zwischen dem Filialservice und den Unternehmensservices den Stereotyp Servicekanal (Service Channel) haben, und bezeichnen Sie die zu verwendenden Bindungen (RMI oder JMS, wie oben angegeben). Die Bindung für den Konnektor zwischen dem Filialservice und der lokalen Datenbankkomponente ist nicht definiert.

Diagramm ist im Textinhalt beschrieben.

Ein Schlüsselelement in diesem Zusammenhang ist der Umstand, dass LocalCustomerLookupProvider ein generierter Service ist. Er ist ein Thin-Wrapper-Service, der eine Datenbankabfrage einschließt, und eine Einzeloperation stellt eine SQL-Auswahl dar. Dieser Ansatz wurde über direkten Zugriff auf die Datenbank, der vom Filialservice für Kundensuche durchgeführt wurde, ausgewählt, um zusätzliche Geschäftsregeln aufzunehmen oder für die Zukunft einen kompletteren Service zu erhalten.

Dieses Diagramm zeigt jedoch nur die Struktur der Kollaboration, das folgende Interaktionsdiagramm (UML-2.0-Ablaufdiagramm) stellt die konkrete Kommunikation zwischen den Services dar. Beachten Sie, dass die Operation getCustomerByPhone zur Servicespezifikation hinzugefügt wurde. Beachten Sie auch, dass UML 2.0 die Spezifikation optionaler "Fragmente" eines Ablaufdiagramms zulässt. In diesem Fall ist angegeben, dass die Kommunikation mit dem Unternehmensservice nur stattfindet, wenn die lokale Suche fehlschlägt.

Diagramm ist im Textinhalt beschrieben.

Die Kombination statischer Struktur- und Kommunikationsdiagramme bietet die Möglichkeit, die Servicezusammensetzung und -kollaboration zu dokumentieren und in diesem Fall lediglich den Bedarf an einer Einzeloperation für die Servicespezifikation zu identifizieren.

Weitere Informationen finden Sie im Abschnitt zur Aktivität Serviceidentifikation.

Servicedesign Seitenanfang

Auf der Basis des Modells aus der Serviceidentifikation wird die Identifikation einer Gruppe geeigneter Services in das detaillierte Design der zu erstellenden Services überführt. Der erste Schritt besteht darin, die Servicespezifikationen, die die obigen Spezifikationen realisieren, darzustellen. Es muss entschieden werden, wie Services die Servicespezifikationen aus dem obigen Modell realisieren sollen. In diesem Beispiel gibt es eine recht einfache Struktur, die wahrscheinlich jedoch von vielen Projekten genutzt wird. Hier ist ein einzelner Serviceprovider vorhanden, der einen einzelnen Service, in diesem Fall die Realisierung einer einzelnen Spezifikation, darstellt. Es ist möglich, mehrere Services pro Provider zu haben. Außerdem sind einige Verwendungsbeziehungen zwischen den Services in diesem Modell zu beachten. Diese Abhängigkeiten sind wichtig, um verstehen zu können, wie Services im Laufe der Zeit weiterentwickelt werden können.

Diagramm ist im Textinhalt beschrieben.

Diese Struktur erlaubt eine stärkere Verlagerung in den Bereich der Verteilung, während das Modell noch eine logische Sicht der Services ist, da die Serviceprovider die Deployment-Einheiten für das Servicemodell repräsentieren. Die Serviceprovider sind auch für die Definition zusammengesetzter Services erforderlich, da ein Service für sich (ein UML-2.0-Port) nicht Eigner der Struktur sein kann, die für die Beschreibung der Zusammenstellung erforderlich ist.

Nachrichtendesign

Im Zusammenhang mit der Aktivität "Serviceidentifikation" wurde oben nichts über die konkreten Nachrichten gesagt, die zwischen den in den Servicespezifikationen beschriebenen Operationen ausgetauscht werden. Üblich ist, die Zuständigkeiten der Services im Hinblick auf Operationen, die das detaillierte Design der Nachrichten auf einen späteren Zeitpunkt verschieben, zu erfassen. In manchen Fällen wird dieser Ansatz umgekehrt, wenn die Nachrichtenstrukturen vorab bekannt sind und dann in einer Gruppe von Operationen zusammengefasst werden.

In diesem Falle kann ein Domänenmodell, das als Teil des Komponentenanalysemodells (zuvor entwickeltes Asset) entwickelt wurde, genutzt werden. Das Nachrichtenmodell wird also nicht aus dem Nichts entwickelt, sondern identifiziert eine Teilgruppe des wiederzuverwendenden Domänenmodells. Das Beispiel unten veranschaulicht diese Beziehung, die Domänenklassen sind in keiner Weise technologie- oder plattformsensitiv, die Nachrichten andererseits sollen Datenübertragungsobjekte sein, d. h. Strukturen, die zwischen Services übertragen werden. Anstatt also das Domänenmodell zu ändern, werden die Nachrichten aus Elementen, die sich innerhalb der Klassenstruktur befinden, sozusagen der Klassenstruktur erstellt.

Diagramm ist im Textinhalt beschrieben.

Weitere Informationen finden Sie im Konzept Nachrichtendesign.

Servicerealisierung Seitenanfang

In diesem Fall liegt der Fokus auf der Realisierung des Filialservice für Kundensuche. Dieser Service ist typisch bei der Umwandlung vom Service- zum Designmodell. Die Umwandlung selbst ist in einer Richtlinie dokumentiert und ergibt die folgende Modellstruktur:

Diagramm ist im Textinhalt beschrieben.

Es handelt sich dabei zwar immer noch um ein Designmodell, aber dieses Modell kann mit Tools weiter in die EJB-Implementierung umgewandelt werden, wie unten dargestellt. Im Grunde wird diese Implementierung aus der oben erwähnten Klasse CustomerByPhone umgewandelt, und die Nachrichten mit Detailangaben zum Kunden werden in die Entity-Bean, die zur Abfrage der Datenbank verwendet wird, umgewandelt.

Diagramm ist im Textinhalt beschrieben.

Weitere Informationen finden Sie in der Richtlinie Von Services zu Servicekomponenten.