Dienst und Dienstspezifikation

Mit der Definition dienstbezogener Entitäten erfolgt nun die Festlegung der zentralen Bestandteile einer Service-MIB, die zugleich den Aus-gangspunkt für die weitere Modellierung bilden. Entsprechend der in Abschnitt5.2.4dargestellten Informationsanforderungen besteht dabei ein wichtiges Kriterium darin, die Spezifikation und Implementierung des Dienstes strikt zu trennen. Auf das Service-MIB Modell abgebildet,

resultieren aus dieser Anforderung zwei grundlegenden Entitäten, die im Folgenden vorgestellt werden.

Die Aufgabe, gewünschte Eigenschaften und Funktionalitäten des Dienst-spezifikation schafft Basis für Implemen-tierung

Dienstes zu beschreiben, fällt der Dienstspezifikation zu. Sie fungiert damit als Vorlage (Template), auf deren Basis die Implementierung kon-kreter Dienste erfolgen kann und stellt gemeinsame Eigenschaften einer Klasse von Diensten dar. Gemäß den in [DR02] vorgestelltenTemplate Models müssen dabei weiterhin ein Service-,Provider-und Customer-Centric Part berücksichtigt werden (vgl. Abschnitt 3.2.1). Entspre-chend dieser Aufteilung entsteht die folgende Hierarchie von Entitäten, die gleichzeitig die schrittweise Verfeinerung einer Dienstspezifikation repräsentieren:

• BasicServiceTemplate

DasBasicServiceTemplaterepräsentiert die generische Spezifika-tion einer Klasse von Diensten, zusammen mit typischen Dienstei-genschaften. Beispielsweise könnte ein derartiges Template für einen Web-Hosting Dienst beschreiben, dass dieser Dienst aus Web-, Applikations- und Datenbankserver besteht und dass die Anzahl von möglichen Transaktionen pro Sekunde einen wichti-gen Leistungsparameter darstellt.

• ProviderCentricTemplate

Aus einer Verfeinerung des BasicServiceTemplates im Hinblick Spezifika ei-nes Providers werden berück-sichtigt

auf Provider-spezifische Randbedingungen geht das ProviderCen-tricTemplate hervor. Es stellt das Ergebnis der Planungsphase dar und konkretisiert die vom BasicServiceTemplate vererbten Diensteigenschaften dahingehend, dass für den jeweiligen Provi-der typische Ausprägungen bzw. Wertebereiche festgelegt werden (Abschnitt5.2.2). Für den Web-Hosting Dienst am LRZ könnte z.B. ein Wertebereich von fünf- bis zehntausend Transaktionen pro Sekunde definiert werden.

• ServiceSpecification

Als Resultat der Verhandlungsphase mit dem Kunden entsteht Service-Specification ermöglicht Soll-Ist Ver-gleich

schließlich die ServiceSpecification. Sie drückt eine Verfeinerung der imProviderCentricTemplateenthaltenen Diensteigenschaften hinsichtlich der von einem Kunden gewünschten Werte aus und

schafft somit die Voraussetzung für einen Soll-Ist Vergleich wäh-rend der Betriebsphase des Dienstes. Beispielsweise könnte eine derartige Spezifikation für den Web-Hosting Dienst am LRZ vor-sehen, dass mindestens sechstausend Transaktionen pro Sekunde unterstützt werden müssen.

Aus Übersichtlichkeitsgründen wird an dieser Stelle nur die Spezifika-tion der EntitätServiceSpecification (Tabelle6.3) dargestellt, die wei-teren genannten Entitäten finden sich in AnhangA.

Entität ServiceSpecification

Beschreibung Diese Entität entsteht durch eine Verfeinerung des BasicServiceTemplates bzw. des Provider-CentricTemplatesund stellt die Basis für die Im-plementierung des Dienstes für einen bestimmten Kunden dar. Sie beschreibt gewünschte Dienstei-genschaften und ermöglicht so einen Soll-Ist Ver-gleich.

Synonym Dieses Konzept ist in CIM nicht vorhanden; in SID existiert eine Klasse ServiceSpecification, al-lerdings wird nicht zwischen den verschiedenen Arten einer Spezifikation unterschieden

Prozessbezug Wegen der zentralen Bedeutung dieser Entität besteht ein Bezug zu allen Prozessen.

Verwandte Entitäten ManagedServiceElement (Superklasse), Basic-ServiceTemplate, ProviderCentricTemplate, Ser-vice, Category

Tabelle 6.3:Entität ServiceSpecification

Die zweite grundlegende EntitätService(Tabelle6.4) repräsentiert den

Entität Service reflektiert

Im-plementierung auf der Basis einer Dienstspezifikation implementierten Dienst. Sie zielt darauf ab, eine aktuelle Sicht auf den Dienst bzw. die aktuell gemes-senen Werte für Diensteigenschaften zu reflektieren. Letztere werden insbesondere in Abschnitt6.3weiter konkretisiert.

Entität Service

Beschreibung Repräsentiert die Implementierung eines Diens-tes gemäß einerServiceSpecificationund umfasst aktuell gemessene Werte für Diensteigenschaf-ten. Weiterhin ist der Dienst bestimmten Kate-gorien zugeordnet und befindet sich in einer de-finierten Lebenszyklusphase.

Synonym CIM definiert eine Klasse Dienst, diese trägt aber eine unterschiedliche Semantik. In SID ist eine Klasse Dienst ebenfalls vorhanden, es wird al-lerdings eine Unterscheidung zwischen Resour-ceFacingServiceundCustomerFacingService ein-geführt.

Prozessbezug Wegen der zentralen Bedeutung dieser Entität besteht ein Bezug zu allen Prozessen.

Verwandte Entitäten ManagedServiceElement (Superklasse), Service-Specification, QoS, Category, LifecycleStatus

Tabelle 6.4: Entität Service

Zur Überführung der definierten Entitäten in ein geeignetes Modell wurde auf Specification-Pattern von Fowler [Fow96] zurückgegriffen, das gleichzeitig eine Erweiterung des Strategy-Pattern [GHJV95] von Gamma et al. darstellt. Die grundlegende Idee beider Pattern besteht dabei darin, eine Trennung von Spezifikation und Implementierung zu gewährleisten – eine Designvorgabe, die ebenfalls von dem MNM-Dienstmodell abgeleitet wurde. In Abbildung6.3werden diese beiden Teilbereiche verdeutlicht: Der jeweilige Stereotyp (ServiceSpecification oderServiceImplementation) zeigt an, welcher Aufgabe die betreffende Entität untergeordnet ist. Während die verschiedenen Arten der Spe-zifikation in einer Vererbungshierachie angeordnet werden, weist die RelationSpecifiesdarauf hin, dass eineServiceSpecification einem oder mehreren Diensten zugeordnet werden kann.

Weiterhin wurden in dem Modell eine Reihe von Informationsanforde- Einordnung in

Dienstkategori-rungen (Abschnitte5.2.4und 5.3.4) umgesetzt: Um ein Auffinden des en

ImplementationSpecification «ServiceImplementation» Service«ServiceSpecification» ServiceSpecification

«ServiceImplementation» LifecycleStatus currentPhase: int timeOfServiceCreation: timestamp lastPhaseChange: timestamp semanticsForChange: string «ServiceImplementation» ServiceCategory«ServiceSpecification» ServiceCategorySpec

BasicServiceTemplate ProviderCentricTemplate «ServiceImplementation» ServiceFunctionality«ServiceSpecification» ServiceFunctionalitySpec «ServiceImplementation» ServiceTransaction«ServiceSpecification» ServiceTransactionSpec

1 * *

«refine» *

* ServiceType *

1

specifies * ServiceType *

«refine»

Abbildung 6.3: Klassenmodell von Dienst und Dienstspezifikation

Dienstes bzw. der Dienstspezifikation zu unterstützen, erfolgte zunächst die Einführung eines ServiceTypes und einer EntitätServiceCategory.

Den EntitätenServiceundServiceSpecificationkann so ein bestimmter Diensttyp zugewiesen und mit Hilfe dessen eine Einordnung in Dienst-kategorien vorgenommen werden, wie durch die qualifizierten Assozia-tionen in Abbildung6.3ausgedrückt. Dies erlaubt die Einbettung in den Dienstkatalog eines Providers und vereinfacht die Teilaktivität Initial Classification and Recording des Incident-Management Prozesses.

Zur Beschreibung der Dienstfunktionalität dient die Entität Service-Functionality. Sie steht in Aggregationsbeziehung mit demServicebzw.

der ServiceSpecification und besteht selbst wiederum aus einer Reihe vonServiceTransactions.In dieser Weise können funktionale Baustei-ne eiBaustei-nes Dienstes (vgl. die in [DR02] eingeführten FunctionalBB) in ServiceFunctionalities gegliedert und anhand ihrer Transaktionen wei-ter detailliert werden. ServiceTransactions charakterisieren dabei ge-nerische Dienstprimitive (z.B. Aufruf einer Webseite) und abstrahie-ren somit effektiv Details der Implementierungstechnologie (z.B. http-Aufrufe) – ein Mechanismus, der beispielsweise auch innerhalb der Application-MIB [KS98] Anwendung findet. Wie sich in Abschnitt6.3 weiterhin zeigen wird, können mit Hilfe dieser Abstraktion eine Reihe generischer Dienstattribute festgelegt werden.

Als weitere Informationsanforderung fand die Beschreibung der Lebens- Beschrei-bung der Lebenszyklus-phase

zyklusphase eines Dienstes Berücksichtigung. Dazu wurde die Entität LifecycleStatus eingeführt und per Komposition untrennbar mit dem Service verbunden. Sie verfügt über Attribute zur Beschreibung der aktuellen Lebenszyklusphase des Dienstes (currentPhase), des Zeit-punktes, an dem der Service kreiert wurde (timeOfServiceCreation), des Zeitpunktes der letzten Änderung der Lebenszyklusphase (lastPha-seChange) und der Begründung für diese Änderung (semanticsFor-Change).