Richtlinie: Service
Diese Richtlinie befasst sich mit der Definition eines Service als ermittelbare Softwareressource mit einer externalisierten Servicespezifikation.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Einführung

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.

Ermittelbar

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.

Extern angegeben

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.

Vertragsgestützt

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.

Geschäftliche Ausrichtung

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.

Service modellieren

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.

Im Kontext beschriebene Abbildung

  • 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.