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.