By Simon Johnston, Architect, IBM Corporation.
Dieses White Paper beschreibt das Profil für Unified Modeling Language (UML) 2.0, das die Modellierung von Services, serviceorientierten Architekturen und serviceorientierten Lösungen ermöglicht. Das Ziel des Profils besteht darin, eine allgemeine Sprache zur Beschreibung von Services bereitzustellen, die eine Reihe von Aktivitäten im Entwicklungszyklus abdeckt und auch Sichten für verschiedene Stakeholder bereitstellt. Beispielsweise bietet das Profil Funktionen für den Architekten, mit denen Services früh im Lebenszyklus dargestellt werden können. Dazu werden logische Partitionen zur Beschreibung des gesamten unternehmensweiten Service-Portfolios verwendet. Diese Sicht wird von Designern, die die strukturellen und verhaltensbezogenen Servicespezifikationen, die als Verträge zwischen den Serviceclients und den Implementierern fungieren, präzisiert. Die Nachrichtensicht bietet Designern die Möglichkeit, Informationsmodelle für allgemeine Definitionen von Servicedaten wiederzuverwenden.
Das Profil wurde in Rational Software Architect implementiert und erfolgreich für die Entwicklung von Modellen komplexer Kundenszenarios eingesetzt. Es dient auch der Schulung von Personen, die sich mit Problemstellungen bei der Entwicklung serviceorientierter Lösungen befassen.
Das folgende Diagramm ist ein Modell, das die Konzepte, die bei der Modellierung von Services wichtig sind, veranschaulicht. Wie Sie sehen können, gibt es nur relativ wenige Konzepte, die jedem, der schon mit serviceorientierten Lösungen gearbeitet hat, bekannt sein sollten. Beachten Sie jedoch, dass, obwohl das Profil eine Realisierung dieses Modells darstellt, eine Reihe von Konzepten nicht explizite Stereotypen im Profil sind. Beispielsweise gibt es keinen Stereotyp für "Operation" oder "Protokoll", da dies Begriffe sind, die in UML 2.0 existieren und vom Profil eindeutig und ohne weitere Einschränkungen wiederverwendet werden können.
In der folgenden Tabelle sind die Elemente des UML-2.0-Metamodells aufgelistet, die als Metaklassen für Stereotype im UML-Profil verwendet werden.
UML-2.0-Metaklasse | Stereotypen |
---|---|
Klasse (Class) | Nachricht (Message), Servicepartition (Service Partition), Serviceprovider (Service Provider) |
Klassifizierungsmerkmal (Classifier) | Servicekonsument (Service Consumer) |
Kollaboration (Collaboration) | Servicekollaboration (Service Collaboration) |
Konnektor (Connector) | Servicekanal (Service Channel) |
Schnittstelle (Interface) | Servicespezifikation (Service Specification) |
Port | Service, Service-Gateway |
Eigenschaft (Property) | Nachrichtenanhang (Message Attachment) |
Das folgende Diagramm, das mit der Maus angeklickt werden kann, veranschaulicht die konkreten Details des Profils mit allen Stereotypen, wobei die Metaklasse die Erweiterungsnotation (ausgefüllte Pfeilspitze) verwendet. Sie können auch einige Einschränkungen im Modell sehen, insbesondere diejenigen, die zwischen Profilelementen bestehen.
Die folgenden Abschnitte umreißen die Elemente des UML-2.0-Profils laut aktueller Definition. Jeder Abschnitt umreißt einen einzelnen Stereotyp, dessen Details seine Metaklasse, seine Eigenschaften und alle Einschränkungen angeben, die bei der Verwendung des Profils angewendet werden sollen.
Klasse
Eine Nachricht repräsentiert das Konzept laut Definition in
der WSDL-Spezifikation, d. h. ein Container für tatsächliche Daten, der für den Service
und den Konsumenten Sinn ergibt. Eine Nachricht hat möglicherweise keine Operationen,
sondern Eigenschaften und Zuordnungen zu anderen Klassen (Klassen eines Domänenmodells).
Der Stereotyp "Nachricht" (Message) hat eine Eigenschaft zur Bezeichnung seines angenommenen
Codierungsformats (d. h. SOAP-literal
, SOAP-rpc
, ASN.1
etc.).
Die Verwendung dieses Elements kann in einem Tool aus zwei Gründen optional sein. Erstens möchte der Modellierer vielleicht einfach Elemente aus einem Domänenmodell direkt als Parameter für eine Operation verwenden, anstatt eine Nachricht anzugeben, zweitens möchte er eventuell die Konvention zur Angabe einer Gruppe von Ein- und Ausgabenachrichten für eine Operation verwenden. In diesem Fall müsste das Modellierungstool, wenn es Servicebeschreibungen in WSDL generiert, eine Ein- und Ausgabenachricht erstellen, die mit den Parametern übereinstimmt.
Art | Name | Typ | Beschreibung |
---|---|---|---|
Eigenschaft | encoding | String | Bezeichnet den Codierungsmechanismus
der Plattform, der beim Generieren des Schemas für die Nachricht verwendet werden
soll, z. B. SOAP-RPC, Doc-Literal, ASN.1 usw.
|
Eigenschaft
Dieser Stereotyp wird verwendet, um anzugeben, dass manche Komponente einer Nachricht ein Anhang ist (im Gegensatz zu einem direkten Bestandteil der Nachricht selbst). Normalerweise wird dieser Stereotyp bei Designaktivitäten der höheren Ebene nicht oft verwendet, aber für viele Prozesse ist es von Bedeutung, angehängte Daten von eingebetteten Nachrichtendaten zu unterscheiden. Beispielsweise kann ein Katalogservice allgemeine Produktdetails als Bestandteil der strukturierten Nachricht zurückgeben, Grafiken werden jedoch als Nachrichtenanhänge zurückgegeben, da die Codierung der Grafiken im Gegensatz zur Textcodierung der Hauptnachricht binär ist.
Art | Name | Typ | Beschreibung |
---|---|---|---|
Eigenschaft | encoding | String | Bezeichnet den Codierungsmechanismus der Plattform,
der beim Generieren des Schemas für die Nachricht verwendet werden soll, z. B.
SOAP-RPC, Doc-Literal, ASN.1 usw.
|
Port
Das Servicemodellelement stellt den Endpunkt für die
Serviceinteraktion (in der Web-Services-Technologie) bereit, wohingegen die
Definitionen dieser Interaktionen Bestandteil der Servicespezifikation sind. Im Modell
identifiziert ein Service nicht nur die bereitgestellte Schnittstelle, sondern
identifiziert auch erforderliche Schnittstellen (z. B. Callback-Schnittstellen). Ein
Service hat eine zusätzliche Eigenschaft, die die zu verwendende Bindung bezeichnet, z.
B. SOAP-HTTP
, SOAP-JMS
usw.
Keine.
Konnektor
Ein Kanal repräsentiert den Kommunikationspfad zwischen zwei Services. Ein wichtiger Punkt ist, dass die Interaktion über einen Kanal erfolgen kann, der Kanal jedoch keine bestimmte Interaktion darstellt. In der Welt der Web-Services bezeichnet jeder Service die Bindungen, die ihm zugeordnet sind (damit ein Client darauf zugreifen kann). In einem Modellierungsprofil können Sie die Bindung entweder hinsichtlich der Kommunikation zwischen Services oder zwischen einem Service und Konsumenten angeben. So können Sie die Bindungsanforderungen flexibel handhaben.
Art | Name | Typ | Beschreibung |
---|---|---|---|
Eigenschaft | Binding | String | Bezeichnet den Bindungsmechanismus der
Plattform, der beim Generieren der Servicebindung in WSDL verwendet werden
soll, z. B. SOAP-RPC , SOAP-Doc , HTTP-Get usw.
|
Kollaboration
Eine Servicekollaboration ist ein Weg, die Implementierung eines Service als Kollaboration anderer Services anzugeben. Aus dem Blickwinkel der Web-Services betrachtet, entspricht das der Verwendung von BPEL4WS bei der Angabe der Serviceimplementierung. Das bedeutet, dass eine Servicekollaboration als Verhalten eines Service verwendet wird und, falls sie in einer Sprache wie BPEL generiert werden soll, möglicherweise weitere implementierungsspezifische Einschränkungen hat.
Art | Name | Typ | Beschreibung |
---|---|---|---|
Eigenschaft | Binding | String | Bezeichnet den Bindungsmechanismus der Plattform, der beim Generieren der Kollaboration als Prozesschoreographie verwendet werden soll, z. B. "BPEL", "WSFL" usw. |
Klassifizierungsmerkmal
Alle Klassifikationsmerkmale (Klasse, Komponente, ...) können als Konsumenten eines Service agieren, und das schließt einen anderen Service ein. Während dieser Stereotyp definitiv optional ist, kann es nützlich sein, die Elemente eines Modells, die selbst keine Services sind, als Clients von Services zu identifizieren. Es kann aber auch sein, dass sie nicht verwendet werden und zusätzlichen Aufwand erzeugen.
Keine.
Keine.
Port
Ein Service-Gateway erscheint wie ein Service, ist jedoch nur für die Verwendung in Partitionen und nicht Serviceprovidern verfügbar. Ein Gateway agiert als Proxy-Service und kann für die Vermittlung von Protokollen oder die Bezeichnung der für eine Partition verfügbaren Schnittstelle verwendet werden. Beispielsweise ist zu bemerken, dass, obwohl eine Reihe von Services in einer Partition implementiert sind, nur einige für die Verwendung außerhalb der Partition verfügbar sind und daher Gateways für diese Services bereitgestellt werden. Das verstellt anderen Services oder Partitionen die Möglichkeit, mit Services, die nicht über Gateways zugänglich sind, zu kommunizieren.
Keine.
Klasse
Eine Partition stellt eine logische oder physische Grenze des Systems dar. Die Modellierung von Partitionen ist zwar optional, aber nützlich. Beispielsweise können Partitionen zur Darstellung der Web-, Geschäfts- und Datenschicht einer traditionellen Anwendung der n-Schicht verwendet werden. Partitionen können auch verwendet werden, um mehr physische Grenzen (z. B. das primäre Rechenzentrum, den sekundären Standort, Kundenstandort, Partner usw.) zu bezeichnen. In diesem Fall kann das Überschreiten von Partitionen bestimmte Einschränkungen hinsichtlich der Sicherheit, der zulässigen Protokolle, der Bandbreite usw. mit sich bringen.
Eine Partition hat möglicherweise nur Eigenschaften, die verschachtelte Abschnitte, seien es Services oder andere Partitionen, darstellen. Beachten Sie, dass das eine Einschränkung ist. Keine anderen Elemente können gegenwärtig in einer Partition dargestellt werden.
Eine Partition kann auch "strikt" sein. Wenn eine Partition vorgibt, dass die gesamte interne Kommunikation und die Kommunikation mit anderen Partitionen durch typisierte Gateways geleitet werden muss, spricht man von einer strikten Partition.
Art | Name | Typ | Beschreibung |
---|---|---|---|
Eigenschaft | Classifier | String | Ein Klassifikationsname, mit dem der Namespace-Bereich dieser Partition bezeichnet wird. |
Klasse
Der Serviceprovider ist ein Softwareelement, das einen oder mehrere Services bereitstellt. Was die Modellierung angeht, würde man normalerweise erwarten, an dieser Stelle eine UML-Komponente zu sehen, eine solche Einschränkung erscheint jedoch willkürlich, und so wird die Metaklasse im Interesse einer größeren Flexibilität als Klasse bezeichnet. Ein Serviceprovider hat eine Eigenschaft, die Informationen zu seinem Standort erfasst, obwohl die Bedeutung implementierungsabhängig ist. Die Klasse, die als Serviceprovider agiert, legt möglicherweise keine Attribute oder Operation direkt offen. Möglicherweise werden nur öffentliche Ports bereitgestellt (mit dem Stereotyp "Service"), die von Servicespezifikationen typisiert werden.
Die Eigenschaft "location" ist, wenn implementierungs- und plattformspezifisch,
beim Generieren von Serviceendpunktnamen nützlich. Beispielsweise kann der
Standort bei Verwendung von WSDL http://svc.myco.com/
sein und ein
Service kann den Namen CustInfo
haben. In diesem Fall kann der Endpunktname
für den Service als http://svc.myco.com/CustInfo
generiert werden.
Art | Name | Typ | Beschreibung |
---|---|---|---|
Eigenschaft | allowedBindings | String | Bezeichnet den Bindungsmechanismus der Plattform, den
ein Kanal verwenden kann, wenn er eine Verbindung zum Service herstellt, z. B.
SOAP-RPC , SOAP-Doc , HTTP-Get usw.
|
Eigenschaft | location | String | Der Standort des Providers, der von Generatoren zur Erstellung von Endpunktnamen verwendet werden kann. |
Schnittstelle
Die Verwendung einer Schnittstelle bezeichnet eine Gruppe von Operationen, die von einem Service bereitgestellt werden. Beachten Sie, dass ein Service mehrere Schnittstellen implementieren kann. Laut Konvention ist es möglich, einer solchen Spezifikation eine Protokollzustandsmaschine oder UML-2.0-Kollaboration zuzuordnen, um die Reihenfolge beim Aufrufen von Operationen für eine Servicespezifikation festzulegen. Mit dieser Verhaltensspezifikation können alle Implementierungsservices validiert werden, und zwar nicht nur für eine statische, sondern für eine dynamische Spezifikation ihrer Struktur und ihres Verhaltens. Beachten Sie, dass die Servicespezifikation nur öffentliche Operationen bereitstellen kann.
Art | Name | Typ | Beschreibung |
---|---|---|---|
Eigenschaft | published | Boolean | Diese Eigenschaft gibt an, ob der Service in einem Service-Repository veröffentlicht werden soll. Sie ist nicht mit der Eigenschaft "public/private" in UML identisch. |