Ein Service ist ein Schlüsselartefakt in der serviceorientierten Architektur, aber was ist ein Service? Es folgt der Eintrag
aus dem Glossar von Rational Unified Process (RUP).
Ein Service ist eine ermittelbare Softwareressource mit einer externalisierten Servicespezifikation. Diese
Servicespezifikation kann von einem Servicekonsumenten gesucht, gebunden und aufgerufen werden. Der Serviceprovider
realisiert die Implementierung der Servicespezifikation und stellt den Servicekonsumenten auch die Anforderungen für
die Servicequalität zur Verfügung. Services müssen durch deklarative Richtlinien geregelt sein und somit einen
dynamisch rekonfigurierbaren Architekturstil unterstützen.
Während die folgenden Abschnitte einige der Schlüsselaussagen aus dem obigen Eintrag umreißen, muss ein weiterer Aspekt
der Services hervorgehoben werden, der sie von Designelementen in älteren Technologien unterscheidet. Services haben
eine Unterteilung, die es erlaubt, sie auf einer geschäftlichen Ebene zu identifizieren. Daher wird auch die
geschäftliche Ausrichtung von Services erläutert.
Services sind nicht Teil einer monolithischen Anwendungsarchitektur. Sie bestehen zur Laufzeit unabhängig von allen
anderen Services in einer bestimmten Lösung. Das bedeutet, dass eine Methode zur Registrierung und Ermittlung von
Services erforderlich ist, die auf Kriterien wie den Servicespezifikationen, die sie realisieren, ihren Serviceprovidern sowie anderen geschäftlichen und technischen
Klassifikationen basiert. Der Erkennungsprozess kann während der Entwicklungszeit ausgeführt werden, um bestimmte
Services mit unterstützenden Services abzugleichen, oder er kann zur Laufzeit ausgeführt werden, um die dynamische
Bereitstellung eines Service (vermittelter Aufruf) zu ermöglichen. Damit ein Service ermittelbar ist, muss er eine
Gruppe von Metadaten bereitstellen, die eine Kategorisierung ermöglicht. Diese Metadaten sind Teil der externen
Spezifikation.
Weitere Informationen finden Sie im Konzept Serviceportfolio und in der Richtlinie Servicevermittlung.
Die externe Spezifikation ermöglicht einem Service, seine Einzeldaten, z. B. Schnittstelle, Position, Richtlinien,
Klassifikationen usw. zu veröffentlichen, ohne dass ein Client auf den Service selbst zugreifen muss. Diese
Informationen werden dann normalerweise an einer bekannten Position oder in einer spezialisierten Service-Registry, die
Abfragen der Metadaten unterstützt, gespeichert. Gegenwärtig ist WSDL (Web Services
Description Language) in der Welt der Web-Services der akzeptierte Standard für die Beschreibung von
Serviceschnittstellen, der vom World Wide Web Consortium entwickelt wurde.
Das Arbeitsergebnis "Servicespezifikation" ist eigentlich eine Kombination dreier Teile: Schnittstelle, Verhalten und
Richtlinienspezifikation. Im Grunde genommen ist die Realisierung dieser verschiedenen Aspekte mehr als nur die
Schnittstellendefinition von WSDL.
Weitere Informationen zu Service-Registrys finden Sie im Konzept Serviceportfolio.
In der obigen Glossardefinition wurde darauf hingewiesen, dass die Servicespezifikation eine Sicht sowohl für den
Serviceprovider als auch für den Servicekonsumenten bereitstellt. Diese Sichten entsprechen zwei Hälften eines
Vertrags, der eine klare Trennung von Spezifikation und Implementierung erlaubt.
Die folgende Tabelle beschreibt, wie die verschiedenen Aspekte einer Servicespezifikation den Provider und den
Konsumenten der Spezifikation beeinflussen.
Rolle
|
Spezifikation der Schnittstelle
|
Spezifikation des Verhaltens
|
Spezifikation der Richtlinie
|
Provider
|
Gibt die Gruppe der Operationen und Nachrichten an, auf die der Service reagieren muss. Alle Operationen
müssen auf die richtigen Nachrichten reagieren und mit den richtigen Nachrichten antworten.
|
Gibt an, welches Verhalten dieser Service unterstützen muss. Wenn eine solche Verhaltensspezifikation
formal und vollständig ist, kann eine Implementierung auf Konformität mit der Spezifikation getestet
werden.
|
Gibt die Einschränkungen an, denen die Serviceimplementierung unterworfen ist, sowie eine Gruppe von
Servicequalitäten, die realisiert werden müssen.
|
Konsument
|
Gibt die Gruppe der Operationen an, die aufgerufen werden können.
|
Gibt an, welche Protokollanforderungen der Konsument erfüllen muss (Anordnung von Operationen, Datenfluss
usw.). Gibt auch alle Operationen an, die der Konsument implementieren muss, um Kollaborationen zu
unterstützen.
|
Gibt die Einschränkungen (z. B. Sicherheitsanforderungen) an, die der Konsument bei der Kommunikation mit
diesem Service berücksichtigen muss. Gibt auch die Servicequalität an, die ein Konsument von einem
bestimmten Provider erwarten kann.
|
Eine solche Servicespezifikation kann als Anwendung des Entwurfs gemäß Vertrag (Design by Contract) betrachtet werden,
ist jedoch ein notwendiger Schritt, wenn es darum geht, ermittelbare und dynamisch rekonfigurierbare Services zu
erreichen.
Normalerweise ist die Verbindung zwischen Geschäftsmodellen, die die Operationen des Geschäfts- und des Designmodells
für unterstützende IT-Anwendungen repräsentieren, bestenfalls lose. In den meisten Fällen wurde die Verbindung
vollständig unterbrochen. Während RUP Anleitungen zum Übergang von Geschäftsmodellen zu Systemanwendungsfallmodellen
(siehe Von Geschäftsmodellen zu Systemen) bereitstellt, erfordert die Verbindung eine Reihe von Umwandlungen,
wenn die Unterteilung und die Abstraktion von der geschäftlichen Perspektive zur IT-Perspektive wechselt.
Im Allgemeinen ist klar, dass Services in geschäftliche oder Infrastrukturservices unterteilt werden können. Im Konzept
Serviceportfolio werden Serviceklassifikationen erläutert.
Ein wichtiger Aspekt der serviceorientierten Architektur ist, dass die Unterteilung von Services, die in einer
serviceorientierten Lösung beschrieben ist, dergestalt ist, dass die von den Services bereitgestellten Operationen oft
auf einer geschäftlichen Ebene identifiziert werden können. Diese erweiterte Unterteilung hinsichtlich unterstützender
Informationstechnologie bedeutet, dass in vielen Fällen Aufgaben, die in Geschäftsprozessmodellen identifiziert wurden,
direkt als Operationen für Services realisiert werden können. Daher werden die professionellen IT-Anwender wesentlich
stärker in den Analyse- und Designprozess einbezogen. Interessant ist auch, dass diese engere Verbindung zum
Geschäftsprozessmodell bewirkt, dass Services den in der RUP-Disziplin "Geschäftsmodellierung" modellierten
geschäftlichen Zielen direkter als IT-Arbeitsergebnisse zugeordnet werden.
Ausführliche Informationen zur Verbindung von Geschäfts- und Servicemodellen finden Sie in der Beschreibung der
Aktivität Analyse vorhandener Assets.
Verwenden Sie bei der Modellierung des Service das UML-Profil (Unified Modeling Language) für Softwareservices und die Anleitung,
die für jedes Element im Profil bereitgestellt wird. Im Großen und Ganzen sind die Elemente, aus denen sich die
statische Sicht der Services und Servicespezifikationen in einem Servicemodell zusammensetzt, im folgenden Diagramm
dargestellt.
-
Der Serviceprovider "UpdateCustomerAddressLegacyProvider" stellt den Service "UpdateCustomerAddress" bereit.
-
Der Service "UpdateCustomerAddress" implementiert die Servicespezifikation "IUpdateCustomerAddress".
-
Die Servicespezifikation "IUpdateCustomerAddress" enthält die Einzeloperation "execUpdateCustomerAddress".
-
Die Operation "execUpdateCustomerAddress" empfängt eine einzelne Eingabenachricht, "UpdateCustomerRequest".
-
Die Operation "execUpdateCustomerAddress" gibt eine einzelne Ausgabenachricht zurück, "UpdateCustomerResponse".
Die Struktur- und Kompositionssicht des Modells erfasst die Kommunikation zwischen Services und der Partitionierung der
Lösung. Weitere Informationen hierzu finden Sie in den Konzepten Servicekomposition und -choreographie und Lösungspartitionierung.
Alternative Methoden
Für die Modellierung einer logischen Struktur gibt es, wie häufig beim Modellieren, alternative Methoden. In einigen
Fällen können die Verfahren genutzt werden, um zusätzliche technische Details darzustellen. Bei der Modellierung der
bereitgestellten und der erforderlichen Leistungsmerkmale eines Service können Sie beispielsweise die Schnittstellen,
die diese Leistungsmerkmale beschreiben, als Servicespezifikationen stereotypisieren und den kombinierten Typ durch
eine nicht stereotypisierte Klasse darstellen. An Stelle der Schnittstellen können Sie aber auch die Klasse
stereotypisieren. Beide Optionen sind in der folgenden Abbildung dargestellt.
Im Allgemeinen werden Sie die Schnittstellen stereotypisieren, wenn diese von weiteren Services in einem anderen
Kontext verwendet werden sollen. Als Faustregel gilt, dass das Element mit der wiederverwendbaren Beschreibung
stereotypisiert werden sollte. Wenn Sie einen Service für einen Serviceprovider erstellen (oder in der UML-Terminologie
einen Port für eine Klasse oder Komponente), sollten Sie - wie nachfolgend gezeigt - die Klasse ServiceType oder
MyService als Typ des stereotypisierten Ports verwenden.
Die resultierende Struktur ist bei Verwendung von ServiceType und MyService identisch. Der Port gibt eine erforderliche
Schnittstelle und eine bereitgestellte Schnittstelle an, z. B. eine Callback-Schnittstelle, die der Client
bereitstellen muss. In einigen Fällen kann es jedoch sinnvoll sein, für die erforderlichen Leistungsmerkmale und die
bereitgestellten Leistungsmerkmale gesonderte Servicebeschreibungen zu erstellen, um beide Arten von Leistungsmerkmalen
explizit voneinander zu trennen. In einem solchen Fall werden für die Realisierung der oben genannten
Servicespezifikationen zwei Klassen benötigt. Die folgende Abbildung demonstriert diese Klassen.
Wenn Sie jetzt den Serviceprovider erstellen, benötigen Sie zwei stereotypisierte Ports, einen zur Darstellung der
Callin-Funktionalität und einen zur Darstellung der Callback-Funktionalität. Vergleichen Sie dazu die folgende
Abbildung.
Wenn diese zusätzliche Flexibilität für Sie erforderlich ist, sollten Sie genau die vorliegende Aufgabe und das
notwendige Ausmaß an Formalität für Ihre Modelle prüfen. Bei dem letzten Beispiel liegt es klar auf der Hand, dass die
Callin-Schnittstelle und die Callback-Schnittstelle gesondert betrachtet werden müssen. Wie sieht es aber aus, wenn ein
Provider eine Reihe von Serviceendpunkten implementiert? Die Vielzahl der Ports könnte das endgültige Ergebnis schwer
lesbar und schwer verständlich machen.
Weitere Informationen zum Design und zur Implementierung von Services finden Sie in der Beschreibung der Aufgabe Entscheidungen zur Servicerealisierung.
|