next up previous contents index
Next: Begriffsbildung und Umfeld Up: Einführung Previous: Aufgabenstellung

Aufbau und Ergebnisse der Arbeit

 In dieser Arbeit wird aufgezeigt, wie der Aufwand für die Managementinstrumentierung bausteinbasierter Anwendungen erheblich reduziert werden kann. Die hierbei angewandte Vorgehensweise wird in Abb. [*] graphisch dargestellt (die wesentlichen Ergebnisse der Arbeit sind durch graue Hinterlegung gekennzeichnet) und im folgenden kurz beschrieben:


 
Abbildung:  Graphische Darstellung der Vorgehensweise
1#1

Kapitel [*] gibt einen Überblick über typische Vertreter von Bausteinarchitekturen. Aufgrund erheblicher Unterschiede der unterschiedlichen Architekturen wird daraufhin ein für den weiteren Verlauf der Arbeit eindeutiger begrifflicher Rahmen festgelegt und darüber hinaus durch weitere Begriffsdefinitionen aus den Bereichen des Anwendungs- und Dienstmanagements ergänzt.

Ausgehend von der Beobachtung zweier Trends, nämlich dem zum Application Service Provisioning (ASP) und dem zur Bausteinorientierung, werden in Kapitel [*] die Anforderungen, die an eine Managementlösung für die Überwachung bausteinbasierter Anwendungen gestellt werden müssen, ermittelt. Die Szenarien des ASP und der bausteinorientierten Anwendungsentwicklung  werden in einer allgemeinen Form modelliert und ausführlich analysiert. Wesentliche Anforderungen, die hierbei ermittelt werden, sind die Forderung nach Überwachung nutzerorientierter Parameter bei gleichzeitiger Möglichkeit der detaillierten Ermittlung von Fehlerquellen sowie die Möglichkeit, bei Identifikation eines Problems eines einzelnen Bausteins, die Auswirkungen auf die Verfügbarkeit der unterschiedlichen angebotenen Dienste ermitteln zu können.

Im Falle bausteinorientierter Anwendungen stellt die Überwachung der einzelnen Bausteine den geeigneten Detaillierungsgrad dar. Insbesondere die Überwachung von Benutzertransaktion en sowie der von den einzelnen Bausteinen erbrachten Subtransaktion en ist von großer Bedeutung. Die zentrale Forderung, die sich aus der Analyse der Szenarien ergibt, ist jedoch die Forderung nach weitgehend werkzeuggestützter und automatisierter Managementinstrumentierung der Anwendungen.

Die ermittelten Anforderungen werden in Kapitel [*] den aktuell existierenden Ansätzen gegenübergestellt. Hierzu wird eine Klassifikation der unterschiedlichen Ansätze nach Art der Informationsgewinnung angegeben, in die die verschiedenen Lösungen von Standardisierungsorganisationen und Herstellern sowie aktuelle Forschungsansätze eingeordnet werden können. So wird es möglich, unabhängig von einzelnen Produkten die eigentlichen Konzepte zu untersuchen und zu bewerten. Es zeigt sich, daß alle derzeit verfügbaren Ansätze entweder nicht die Information liefern können, die für eine sinnvolle Anwendungsüberwachung  erforderlich ist, oder aber sich der Aufwand für ihre Realisierung als zu hoch erweist.

Daher wird in Kapitel [*] eine Lösung vorgestellt, die die oben beschriebenen Defizite nicht aufweist und die gestellten Anforderungen erfüllen kann. Zunächst werden die bei der Auswahl einer geeigneten Lösung zu treffenden Designentscheidungen dargelegt. Ein erster Ansatz, die Komposition von Managementschnittstellen instrumentierter Bausteine wird vorgestellt. Hierbei wird eine Instrumentierung der grundlegenden Bausteine vorausgesetzt. Aufgrund der Abhängigkeiten zwischen Bausteinen lassen sich die Managementschnittstellen zusammengesetzter Bausteine hieraus ohne weitere Instrumentierung bestimmen. Dieser Ansatz erwies sich allerdings im Verlauf der Untersuchungen als nur bedingt geeignet, die gestellten Anforderungen zu erfüllen. Aus diesem Grund wird ein zweiter Ansatz, die automatische Instrumentierung bausteinbasierter Anwendungen untersucht: Dieser verzichtet vollständig auf die Instrumentierung einzelner Bausteine. Stattdessen werden Meßpunkte mit Hilfe einer erweiterten Entwicklungsumgebung größtenteils automatisch in die zu erstellende Anwendung eingefügt. Auch dieser Ansatz kann letztlich aber nicht alle Anforderungen erfüllen. Die im Anschluß daran vorgestellte Architektur basiert somit auf einer Kombination beider Ansätze und vereint deren Vorteile zu einer Lösung, die den aufgestellten Anforderungen umfassend gerecht werden kann. Die Vorstellung der Architektur gliedert sich in zwei Teile: Zunächst wird die Architektur für die Ermittlung der Managementinformation dargestellt. Diese spezifiziert Managementschnittstellen, die an die im Rahmen der Arbeiten zur Application Response Measurement API (ARM) [#!c807!#] entstandene Schnittstelle angelehnt sind. Es wird also nicht versucht, existierende Ansätze zu ersetzen, sondern geeignet zu erweitern und zu verbessern. Weiterhin wird hier angegeben, wie bestimmte Systembibliotheken zu erweitern sind, um die einfache Überwachung zu gewährleisten. Der zweite Teil der vorgestellten Architektur, die Architektur zur Automation der Managementinstrumentierung legt fest, wie eine Entwicklungsumgebung erweitert werden muß, um einen Großteil der Managementinstrumentierung vollständig automatisiert durchführen zu können. Weiterhin werden sowohl für den Anwendungsentwickler als auch für den Bausteinentwickler einfache Methodiken vorgegeben, nach denen bei der Erstellung von Anwendungen bzw. Bausteinen zu verfahren ist, um mit geringem Aufwand managementinstrumentierte Anwendungen zu erhalten.

Um die Anwendbarkeit der vorgeschlagenen Lösung zu demonstrieren wird in Kapitel [*] eine prototypische Implementierung des Ansatzes vorgestellt. Es handelt sich um eine Erweiterung einer Entwicklungsumgebung für Java-Beans, mit deren Hilfe instrumentierte Anwendungen mit geringem Aufwand für Anwendungs- und Bausteinentwickler erstellt werden können.


next up previous contents index
Next: Begriffsbildung und Umfeld Up: Einführung Previous: Aufgabenstellung
Copyright Munich Network Management Team