Grundlegendes Architekturmodell

Abbildung 6.1: Use Cases f¨ur die Nutzung des Rahmenwerks

durch einen Administrator der Anbieterdom¨ane etabliert wird. Hierzu muss aus einem SLA-Muster zun¨achst eine SLA-Instanz erzeugt werden. Dies erfordert die Beschaffung eines ge-eigneten, zuvor definierten SLA-Musters sowie der notwendigen Konfigurationsinformatio-nen. Anschließend wird durch eine Transformation des SLA-Musters eine Bindung an die zu

¨uberwachende Konfiguration erreicht. Die so entstandene SLA-Instanz wird dann durch einen Deployment-Dienst im System etabliert.

6.2 Grundlegendes Architekturmodell

Die Analyse der im vorherigen Abschnitt vorgestellten Anwendungsf¨alle best¨atigt die in Ab-schnitt 2.3.3 identifizierten Anforderungen an den Etablierungsprozess (EPRO1–EPRO3).

Konkret bedeutet dies f¨ur die Instanziierung durch den Administrator innerhalb der Anbieter-dom¨ane, dass f¨ur die Transformation eines SLA-Musters ein geeignetes Werkzeug existieren muss, welches den Administrator bei der Instanziierung anleitet. Soll die Etablierung eines SLAs durch einen Kunden erfolgen, muss der gesamte Instanziierungsprozess vollst¨andig au-tomatisiert ablaufen k¨onnen.

Abbildung6.2 zeigt die grundlegende Architektur des Rahmenwerks f¨ur die Umsetzung des modellbasierten Service Level Managements im ¨Uberblick. Die Architektur reflektiert die drei Phasen des modellbasierten Ansatzes aus Kapitel 4: Modellierung der SLA-Muster, Erzeu-gung der SLA-Instanzen und Etablierung der SLA-Instanzen.

6 Prototypische Realisierung des modellbasierten Managementansatzes

Abbildung 6.2: Grundlegende Architektur

Nach der Erstellung eines SLA-Musters mit Hilfe eines UML-Werkzeugs und dem in Ka-pitel5 beschriebenen UML-Profil wird das gesamte UML-Modell exportiert und liegt dann im XMI-Format [OMG03l] vor. XMI besitzt allerdings einige entscheidende Nachteile (siehe Abschnitt4.2.1), so dass das UML-Modell nicht unmittelbar weiterverwendet wird, sondern zuerst transformiert wird. Da XMI eine XML-Anwendung ist, wird es mit Hilfe eines ge-eigneten XSLT-Stylesheets [W3C99] manipuliert. Durch diese Transformation werden alle f¨ur das SLA-Muster relevanten Informationen aus den UML-Modell extrahiert; alle f¨ur das SLA-Muster nicht relevanten Informationen werden verworfen. Dadurch wird eine starke Re-duktion des Umfangs des urspr¨unglichen Modells erreicht, da bereits einfache UML-Modelle im XMI-Format ¨uber 1000 Zeilen umfassen. So besteht beispielsweise das

exempla-6.2 Grundlegendes Architekturmodell

rische SLA-Muster aus Kapitel5aus fast 2000 Zeilen. Nach der Transformation umfasst das entsprechende SLA-Muster weniger als 100 Zeilen. Das entstandene SLA-Muster wird dann in einem Repository abgelegt, um f¨ur die weitere Bearbeitung verf¨ugbar zu sein.

Die Transformation des urspr¨unglichen UML-Modells in ein SLA-Muster hat eine Reihe von Vor- und Nachteilen, die gegeneinander abgewogen werden m¨ussen. Der Nachteil ist, dass die Transformation nicht umkehrbar ist, d.h. aus einem SLA-Muster kann nicht wieder das urspr¨ungliche UML-Modell erstellt werden. Daher muss das urspr¨ungliche Modell erhalten werden, wenn es mit Hilfe eines UML-Werkzeugs wieder bearbeitet werden soll. Diesem Nachteil stehen aber eine Reihe von Vorteilen gegen¨uber, die insgesamt ¨uberwiegen. So wird die Realisierung der gesamten Architektur wesentlich vereinfacht, da beispielsweise Parser, die mit SLA-Mustern arbeiten, einen deutlich geringeren Umfang besitzen. Dadurch wird ei-ne schei-nelle Umsetzung gef¨ordert und die Fehlerwahrscheinlichkeit gesenkt. Der gr¨oßte Vorteil ist, dass durch den Einsatz der vereinfachten SLA-Muster eine standardisierte Repr¨asentie-rungsform existiert, die als Startpunkt f¨ur die gesamte Architektur fungieren kann. Zwar ist das Format von XMI auch standardisiert, allerdings weisen die XMI-Umsetzungen derzeitiger UML-Werkzeuge h¨aufig signifikante Unterschiede auf, wodurch die Umsetzung der Architek-tur erschwert wird bzw. das Werkzeug zur Modellierung von SLA-Mustern nicht austauschbar ist. Durch die Verwendung der vereinfachten SLA-Muster muss lediglich das Stylesheet f¨ur die Transformation des UML-Modells angepasst werden, wenn ein anderes Modellierungs-werkzeug verwendet wird. Alle anderen Werkzeuge der Architektur k¨onnen unver¨andert ein-gesetzt werden. Es k¨onnen sogar beliebige Werkzeuge f¨ur die Modellierung verwendet wer-den, unabh¨angig von UML und XMI, solange sich aus deren Daten ein SLA-Muster erzeugen l¨asst.

F¨ur die zweite Phase des modellbasierten Ansatzes, die Transformation eines SLA-Musters in eine SLA-Instanz, existieren mehrere Realisierungsm¨oglichkeiten, je nachdem, ob die Trans-formation interaktiv durch einen Administrator der Anbieterdom¨ane oder automatisch, z.B.

ausgel¨ost durch den Kunden, erfolgen soll. Bei der Instanziierung durch einen Administrator ben¨otigt dieser ein spezielles Werkzeug, welches ihn bei der Transformation des SLA-Musters unterst¨utzt. Da das Rahmenwerk die Bindung von SLA-Mustern an unterschiedliche Managementplattformen (AnforderungFRA3) unterst¨utzen soll, muss das SLA-Werkzeug ei-ne Plugin-Schnittstelle bereitstellen. Die einzelei-nen Plugins kapseln dann die Transformati-onsschritte, die f¨ur die jeweilige Zielplattform erforderlich sind. Die notwendigen Konfigura-tionsinformationen werden vom Administrator interaktiv w¨ahrend der Transformation einge-geben.

Zur automatisierten Instanziierung, wie sie durch einen Kunden oder aber auch durch einen Administrator der Anbieterdom¨ane angestoßen werden kann, m¨ussen alle notwendigen Kon-figurationsinformationen in maschinell verarbeitbarer Form vorliegen. Analog zu den Plugins des SLA-Werkzeugs, existiert f¨ur jede Plattform ein XSLT-Stylesheet, das die notwendige Transformation kapselt. Hierbei werden prinzipiell die gleichen Transformationen verwendet wie in den Plugins. Voraussetzung ist allerdings, dass die Konfigurationsinformationen aus

6 Prototypische Realisierung des modellbasierten Managementansatzes

einem Repository geholt und in XML umgewandelt werden, damit sie bei der Transformation in die entstehende SLA-Instanz eingebaut werden k¨onnen.

Unabh¨angig davon, ob die Transformation durch den Administrator ausgef¨uhrt wurde oder automatisiert erfolgte, ist das Ergebnis dieser Phase stets eine SLA-Instanz. Das Format, in der diese vorliegt, ist abh¨angig von der Zielplattform. Ebenso ist die Etablierung der SLA-Instanz spezifisch f¨ur die verwendete Managementplattform.

In den folgenden Abschnitten werden die Konzepte und die Realisierung der einzelnen Phasen im Detail besprochen.