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.
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.
Weitere Informationen finden Sie im Toolmentor Servicemodell in RSA erstellen.
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.Name | Technologie | Eingabe | Ausgabe | Kommentare |
---|---|---|---|---|
sp_get_custlist_by_phone | Gespeicherte Prozedur des SQL-Servers | phonenum (char 10) | Liste:
custid (id) |
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 |
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.
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.
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.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.
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.
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.
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:
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.
Weitere Informationen finden Sie in der Richtlinie Von Services zu Servicekomponenten.