Arbeitsergebnis: Servicemodell
Das Servicemodell ist ein Modell der Kernelemente einer serviceorientierten Architektur (SOA). Das Servicemodell ist eine wichtige Arbeitsvorgabe für Implementierungs- und Testaufgaben.
Zweck

Das Servicemodell ist eine Abstraktion der in einem Unternehmen implementierten IT-Services, die die Entwicklung einer oder mehrerer serviceorientierter Lösungen unterstützen. Es wird verwendet, um das Design der Softwareservices zu konzipieren und dokumentieren. Es ist ein umfassendes, zusammengesetztes Arbeitsergebnis, das alle Services, Provider, Spezifikationen, Partitionen, Nachrichten, Kollaborationen und deren Beziehungen zueinander umfasst und für Folgendes benötigt wird:

  • Identifizieren geeigneter Services und Erfassen der Entscheidung, welche Services tatsächlich verfügbar gemacht werden
  • Spezifizieren des Vertrags zwischen dem Serviceprovider und dem Konsumenten der Services
  • Zuordnen von Services zu den Komponenten, die für die Realisierung dieser Services benötigt werden
Beziehungen
RollenVerantwortlich: Geändert von:
Eingabe fürVerbindlich: Optional:
  • Ohne
Extern:
  • Ohne
Ausgabe von
Beschreibung
Kurze Gliederung

Das Servicemodell ist oft eine heterogene Sammlung physischer Assets, zu denen UML-Modelle, Dokumente und möglicherweise auch Eingaben in einem Tool für Anforderungsmanagement gehören. Die folgenden logischen Elemente müssen jedoch im Servicemodell enthalten sein (siehe Hauptbeschreibung).

  • Serviceportfolio
  • Servicehierarchie
  • Serviceverfügbarmachung
  • Serviceabhängigkeiten
  • Servicekomposition und -ablauf
  • Nicht funktionale Servicevoraussetzungen
  • Servicenachrichten
  • Entscheidungen zum Zustandsmanagement
  • Realisierungsentscheidungen
Hauptbeschreibung

Das Servicemodell erfasst die Details von Services über mehrere Iterationen, wobei die Details stufenweise ausgearbeitet werden. Das Servicemodell kann für verschiedene Bereichsebenen verwendet werden:

  • Serviceorientierte Entwicklung - Der Projektumfang wird davon bestimmt, den Service unabhängig von anderen Services (so weit wie möglich) zu entwickeln. Die Modellierung umfasst daher die Anwendungsfälle, die Architektur, das Design- und das Implementierungsmodell als vertikalen Sektor für den Service.
  • Projektorientierte Entwicklung - Ein Projekt umfasst die Spezifikation einer Reihe von Services, mit denen eine Gruppe von Anwendungsanforderungen unterstützt wird. In diesem Fall wird der Umfang auf die Anwendungsebene erweitert und kann eine Reihe von Services beinhalten. Praktisch gibt es eine Gruppe von Modellen auf Anwendungsebene für Anwendungsfälle und Architektur sowie eine Gruppe servicespezifischer Design- und Implementierungsmodelle.
  • Unternehmensorientierte Entwicklung oder Serviceportfoliomanagement - Hierbei geht es nur um die Erfassung der Servicespezifikationen und die logische Partitionierung auf Unternehmensebene. Das bietet Designern und Architekten die Möglichkeit, weitreichende Entscheidungen zum gesamten Portfolio zu treffen, obwohl separate Projekte erforderlich sind, um das Design- und das Implementierungsmodell für die identifizierten Services (und Clientanwendungen) zu entwickeln.

Die folgende Abbildung zeigt eine abstrakte Darstellung der Schlüsselaspekte des Servicemodells und die Beziehung zwischen diesen sowie die Aktivitäten Identifikation, Spezifikation und Realisierung.

 

Identifikationselemente

Die erste Ausarbeitung beginnt mit einer Liste geeigneter Services im Serviceportfolio, das während der Aktivität Analyse vorhandener Assets erstellt wurde. Zu den verwendeten Verfahren gehört die Prozessdekomposition (siehe Konzept Dekomposition von Geschäftsprozessen). Diese Services werden entsprechend ihrem Funktionsbereich und dem für ihre Identifizierung verwendeten Verfahren kategorisiert. An dieser Stelle sei ausdrücklich darauf hingewiesen, dass es sich bei dem hier beschriebenen Serviceportfolio um ein projektspezifisches Portfolio handelt, das die geeigneten Services enthält, die mit den verschiedenen Analyseverfahren identifiziert wurden. Diese Verfahren sind im Artikel zur Aktivität Analyse vorhandener Assets beschrieben. In diesem Stadium identifizierte Services werden oft nur namentlich, manchmal auch mit einer Funktionsbeschreibung aufgeführt. Ein einfaches Dokument mit dieser Liste von Services ist häufig ausreichend. Wenn Sie jedoch die UML-Methode verwenden, wird das Portfolio als eine Sammlung von Servicespezifikationen verwaltet und kann unter Verwendung des Berichts Serviceportfolio erstellt werden.

Aus den Services in der Liste wird so schnell wie möglich nach einem funktionalen Klassifikationsschema eine Hierarchie erstellt. (In der Regel basiert das Klassifikationsschema auf Funktionsbereichen, die während der Domänendekomposition identifiziert wurden.) Eine solche Hierarchie demonstriert ein primäres Klassifikationsschema für Services, nämlich das einer Prozessaufrufabhängigkeit, und trägt damit zum besseren Verständnis der Beziehungen zwischen Services bei, die während der Dekompositionsaktivitäten identifiziert wurden. Die Darstellung der Hierarchie kann die Form eines Dokuments, eines Arbeitsblatts oder eines UML-Modells haben. (Im letztgenannten Fall sollte für die Modellierung der Funktionsbereiche das Artefakt Servicepartition verwendet werden.)

Der Begriff Serviceportfolio kann sich auch auf das unternehmensweite Serviceportfolio beziehen (das im Konzept Serviceportfolio erläutert ist). Der Lebenszyklus eines solchen Portfolios reicht über den des projektspezifischen Portfolios hinaus. Zwischen dem Unternehmensportfolio und dem Projektportfolio gibt es allerdings eine Beziehung, die in der folgenden Abbildung gezeigt wird.

Spezifikationselemente

Einer der ersten Schritte bei der Erstellung der Servicespezifikation ist, eine Entscheidung zur Verfügbarmachung von Services zu fällen und diese zu dokumentieren. Es werden die geeigneten Services dokumentiert, die tatsächlich entwickelt und als echte Services verfügbar gemacht werden sollen. Ein Schlüsselverfahren ist die Durchführung von Litmustests für Services. Dieses Verfahren enthält eine bestimmte Anleitung für die Bewertung der Verfügbarmachung von Services. In der UML-Darstellung des Servicemodells wird die Eigenschaft 'status' der Servicespezifikationen, die während der Identifikation entwickelt wurden, auf 'exposed' (verfügbar gemacht) gesetzt. Die so markierten Servicespezifikationen werden dann innerhalb des Modells detaillierter ausgearbeitet. Während der Analyse von Services im Hinblick auf die Verfügbarmachung kann damit begonnen werden, Services zu logischen Angeboten zusammenzufassen. In UML kann dies mit dem Artefakt Serviceprovider modelliert werden.

Beim Dokumentieren von Servicespezifikationen ist es aus verschiedenen Gründen ganz besonders wichtig, alle Serviceabhängigkeiten zu erfassen. Es ist beispielsweise schwierig, Services mit einer großen Anzahl von Abhängigkeiten in unterschiedlichen Umgebungen wiederzuverwenden. Services, von denen viele andere Services abhängig sind, weisen dagegen auf Kernfunktionen hin. Serviceabhängigkeiten können als Text erfasst werden. Häufig werden Tabellen verwendet (siehe Bericht Serviceabhängigkeiten). Für die Modellierung der Serviceabhängigkeiten kann aber auch die UML-Darstellung des Servicemodells verwendet werden. Darüber hinaus ist es wichtig zu erkennen, dass einige Abhängigkeiten auf die Kommunikation zwischen Services zurückzuführen sind. Solchen Abhängigkeiten sind dann bestimmte Details (erforderliche Kommunikationsprotokolle, Sicherheit usw.) zugeordnet, die mit Hilfe des UML-Modells, insbesondere aber mit dem Artefakt Servicekanal in Kollaborationsmodellen dokumentiert werden können.

Beim Definieren von Services werden häufig zusammengesetzte Services identifiziert, die nur dazu dienen, eine Reihe differenzierterer Services zu choreographieren. Komposition und Ablauf sollten die Beziehung zwischen dem zusammengesetzten Service und den zugehörigen Einzelservices beschreiben und die Abhängigkeiten zwischen den Services durch den Verarbeitungsablauf in den Services ausdrücken. In der UML-Darstellung kann diese Komposition gut (mit Kompositionsklassen) beschrieben werden. Der Ablauf (Aktivitäten, Interaktionen) und die Verfahren sind dagegen im Konzept Servicekomposition und -choreographie beschrieben.

Obwohl sich die bisherigen Abschnitte mehr mit den funktionalen Anforderungen beschäftigt haben, ist auch die Erfassung der nicht funktionalen Anforderungen für Services sehr wichtig. In diesem Bereich können die Anforderungen in einem Dokument erfasst werden. Das direkte Ausdrücken der Anforderungen in UML ist deutlich schwieriger. Einfacher wäre die Verwendung eines Anforderungsmanagementprodukts zum Ausdrücken der nicht funktionalen Anforderungen. Wenn Sie die UML-Darstellung des Servicemodells verwenden, empfehlen wir für die Erfassung nicht funktionaler Anforderungen zwei vorhandene RUP-Artefakte, das Dokument zur Softwarearchitektur und die ergänzenden Spezifikationen. Einer der Aspekte der nicht funktionalen Lösungsarchitektur hat mit der Verteilung und Verfügbarkeit von Services zu tun, die mit Hilfe des UML-Modells und hier insbesondere mit den Artefakten Servicepartition und Service-Gateway dokumentiert werden können.

Es liegt auf der Hand, dass die detaillierte Angabe von Servicenachrichten für die Entwicklung verwendbarer Servicespezifikationen von entscheidender Bedeutung ist. Diese Nachrichten können von übergeordneten Modellen abgeleitet oder direkt in einer technologiespezifischen Form (z. B. einem XML-Schema) ausgedrückt werden. Bei den Nachrichtendefinitionen müssen wichtige Aspekte beachtet werden, die in der Aufgabe Nachrichtendesign und der entsprechenden Richtlinie Nachrichtenanhänge dokumentiert sind. Dies gilt unabhängig davon, ob die Nachrichten in Textform, in einer Schemasprache oder im UML-Modell beschrieben sind.

Obwohl wir in einer SOA bestrebt sind, Services statusunabhängig zu machen, ist es nicht immer möglich oder gar wünschenswert, dies als festes Ziel zu verankern. Der Komplex Entscheidungen zum Zustandsmanagement gibt dem Designer Zeit, über Kosten und Nutzen des Zustandsmanagements für Services nachzudenken. Zur Unterstützung dieser Entscheidungen enthält die Richtlinie Zustandsmanagement für Services Beispiele für Zustandsarten, die häufig tatsächlich von einem Service verwaltet werden müssen.

Realisierungselemente

Bei der Realisierung von Services geht es hauptsächlich um drei Bereiche, die Entscheidungen zur eigentlichen Realisierung der Services, die Identifikation von Subsystemen und Komponenten für die Realisierung der Servicespezifikationen und schließlich die Entwicklung dieser Komponenten.

Beim Dokumentieren von Realisierungsentscheidungen ist es wichtig, die Auswahl der Beschaffungs- und Entwicklungsstrategie vernünftig und detailliert begründen zu können. Schauen Sie sich hierzu die Beschreibung der Aufgabe Entscheidungen zur Servicerealisierung dokumentieren an. Diese Entscheidungen lassen sich ähnlich wie die oben beschriebenen nicht funktionalen Anforderungen nur schwer (detailliert) in der UML-Darstellung ausdrücken. Deshalb wird erwartet, dass die gewählten Alternativen für jeden einzelnen Service separat dokumentiert werden.

Eigenschaften
Optional
GeplantYes
Abbildungen
Anpassung
Auswirkungen bei NichtverwendungOhne dieses Arbeitsergebnis wäre es schwierig, Services korrekt zu definieren und die für die Servicerealisierung notwendigen Komponenten zu spezifizieren. Mängel bei der Definition oder Spezifikation könnten wiederum zu Lücken im Serviceportfolio führen und die Verbreitung unnötiger Services, Inkonsistenzen bei der Verfügbarmachung von Services sowie Inkonsistenzen bei den für die Servicerealisierung erforderlichen Komponenten nach sich ziehen.
Gründe für NichtverwendungDieses Arbeitsergebnis wird nicht benötigt, wenn die Servicebeschreibungen nicht externalisiert und an einer signifikanten Unternehmensgrenze (d. h. an der Grenze eines wichtigen Geschäftszweigs innerhalb eines Unternehmens oder der des gesamten Unternehmens) zur Verfügung gestellt werden müssen.
Darstellungsoptionen

Das Servicemodell ist ein umfangreiches Arbeitsergebnis und wird in der Regel unter Einsatz mehrerer Verfahren entwickelt. Für die Beschreibung von Serviceelementen werden beispielsweise UML-Modelle verwendet. Das gesamte Arbeitsergebnis kann jedoch in Form eines Dokuments dargestellt werden, das Diagramme aus dem UML-Modell enthält. In welchem Umfang bei einem Projekt auf die UML-Modelle zurückgegriffen wird, hängt vom Know-how und vom jeweiligen Hintergrund der beteiligten Mitarbeiter sowie von den Erwartungen der Projekt-Stakeholder ab. Im Allgemeinen empfehlen wir, das Modell weitestgehend mit Hilfe der UML-Darstellung zu entwickeln, dann zusätzliche Inhalte (insbesondere beschreibenden Text) zu integrieren und die abschließende Fassung als Dokument zu präsentieren.

Informationen zur UML-Darstellung finden Sie in der Vorlage Servicemodell in UML.

Informationen zur Darstellung im Dokumentformat finden Sie in der Vorlage Servicemodell in Word.

Weitere Informationen