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