Im Rahmen einer ausführlichen Anforderungsanalyse wurde gezeigt, daß es für die Überwachung von Anwendungsdiensten erforderlich ist, die Dienstgüte messen zu können, die tatsächlich einem Benutzer bei Inanspruchnahme eines Dienstes zur Verfügung steht. Es wurde gezeigt, daß für den Benutzer die Zeitdauer für die Bearbeitung einer Transaktion sowie die korrekte Bearbeitung von Transaktionen diejenigen Parameter sind, denen derzeit die herausragendste Bedeutung zukommt. Für den Anbieter des Dienstes sind darüber hinaus weitaus detailliertere Messungen erforderlich, um im Falle der Auftretens eines Fehlers die Ursache schnell und einfach eingrenzen und beheben zu können. Die wesentlichste nicht-funktionale Anforderung ist die Minimierung des durch die Überwachung entstehenden zusätzlichen Aufwands für alle Beteiligten, also insbesondere des zusätzlichen Entwicklungsaufwands, da andernfalls nicht damit gerechnet werden kann, daß entsprechende Vorkehrungen für die Dienstgüteüberwachung auch getroffen werden.
Um die Zeitdauer für die Bearbeitung einer Transaktion messen zu können, war zunächst eine eindeutige Definition von Start- und Endpunkt einer Transaktion erforderlich. Hierbei zeigte sich, daß zwischen der Antwortzeit, also der Zeit zwischen dem Start einer Transaktion bis zum Zeitpunkt der Ergebnispräsentation, und der Transaktionsdauer, also der Gesamtzeit für die vollständige Bearbeitung einer Transaktion, unterschieden werden muß. Es zeigte sich, daß für eine Transaktion beide Parameter gemessen werden können und je nach Anwendungsbereich auch von Managementanwendungen benötigt werden.
Da es ein Ziel der vorliegenden Arbeit war, insbesondere die Überwachung bausteinbasierter Anwendungen zu vereinfachen, wurden die Anforderungen, die über die Anforderungen herkömmlicher Anwendungen hinausgehen, im Anschluß daran explizit untersucht. Es zeigte sich, daß ein einzelner Aufruf eines Bausteins gerade den geeigneten Detaillierungsgrad darstellt, der vom Betreiber eines Anwendungsdienstes gewünscht wird. Aufgrund der Anforderung nach Aufwandsminimierung - sowohl von Seiten des Anwendungsentwicklers als auch von Seiten der Bausteinentwickler - sollten nur ohnehin bei der Erstellung der Anwendung zum Einsatz kommende Techniken und Werkzeuge verwendet werden und muß ein hoher Grad an Automation erreicht werden.
Im folgenden wurden die existierenden Ansätze für die Anwendungsüberwachung den ermittelten Anforderungen gegenübergestellt. Um eine einfache Bewertung existierender und zukünftiger Ansätze zur Anwendungsüberwachung zu gestatten, wurde eine Klassifikation der existierenden Lösungen vorgenommen. Die aktuellen Ansätze von Standardisierungsgremien, aus dem Bereich der Forschung sowie von unterschiedlichen Herstellern von Managementwerkzeugen konnten dann den ermittelten Klassen zugeordnet und so bewertet werden. Hierbei zeigte sich, daß ein Großteil der Lösungen nicht in der Lage ist, die geforderte Information zur Verfügung zu stellen. Dies trifft insbesondere auf die Überwachung des Netzverkehrs sowie auf die Überwachung von Systemparametern zu, die dennoch aktuell den höchsten Verbreitungsgrad aufweisen. Auch die Client-seitige Anwendungsüberwachung liefert nur bedingt aussagekräftige Parameter, da keinerlei Detailinformation über mögliche Fehlerursachen ermittelt werden kann.
Einzig die Überwachung der Gesamtanwendung und hier insbesondere die Anwendungsinstrumentierung ermöglicht es, die tatsächliche Dienstnutzung durch aussagekräftige Parameter sowie hinreichende Detailinformation für den Dienstanbieter zu ermitteln. Dennoch hat die Instrumentierung von Anwendungen aktuell eine sehr geringe Verbreitung, was im wesentlichen auf den erheblichen Aufwand für den Anwendungsentwickler zurückzuführen ist, der mit der Instrumentierung einer Anwendung verbunden ist. Insbesondere im Falle bausteinorientierter Anwendungen ist eine Anwendungsinstrumentierung in vielen Fällen mit den heute zur Verfügung stehenden Mitteln vollständig ausgeschlossen, da eine Propagierung von Transaktionsidentifikatoren über Bausteingrenzen hinweg eine Anpassung aller zum Einsatz kommenden Bausteine erfordern würde.
Ziel der vorliegenden Arbeit war es somit, den Aufwand für die Managementintrumentierung von Anwendungen soweit zu verringern, daß er kein Hindernis mehr für eine Verbreitung dieser Technik der Anwendungsüberwachung darstellt. Idee war es hierbei, die Bausteinstruktur heutiger und zukünftiger Anwendungen auszunutzen und eine - zumindest teilweise - Automation der Instrumentierung zu erreichen.
Der zunächst verfolgte Ansatz basierte auf der Komposition der Managamentschnittstellen instrumentierter Bausteine. Dieser Ansatz erforderte die Managementinstrumentierung sämtlicher zum Einsatz kommender Bausteine. Aufgrund der genauen Kenntnis der Verknüpfung einzelner Bausteine zu einer Gesamtanwendung zum Zeitpunkt der Anwendungserstellung ist es dann möglich, aus den Managementinformationen der einzelnen Bausteine auf die entsprechende Managementinformation der Gesamtanwendung zu schließen bzw. diese daraus zu berechnen. Es sollte also eine ,,Managementlogik`` erstellt werden, die die Verknüpfung der Managementinformationen der einzelnen Bausteine beschreibt und an einer Managementschnittstelle zur Verfügung stellt. Es zeigte sich allerdings, daß dieser Ansatz z.B. hinsichtlich des immer noch hohen Aufwands durch die Instrumentierung aller Bausteine oder der erheblicher Schwierigkeiten bei der Zuordnung der Teilinformation (z.B. im Falle mehrfach genutzter Bausteine oder dynamischer Abhängigkeiten innerhalb der Anwendung) nicht geeignet ist, die gestellten Anforderungen zu erfüllen.
Aus diesem Grund wurde ein zweiter Ansatz, die Automation der Managementinstrumentierung bausteinbasierter Anwendungen eingeführt. Die Idee dieses Ansatzes basiert auf dem automatischen Einfügen von Meßpunkten durch die Entwicklungsumgebung an den Verknüpfungsstellen zwischen Bausteinen. Somit wird es möglich, die Laufzeit sowie die erfolgreiche bzw. nicht erfolgreiche Bearbeitung jedes Bausteins ohne Eingreifen des Entwicklers zu überwachen. Anhand der Kontrollflüsse, in denen die einzelnen Transaktionen einer Anwendung ausgeführt werden, ist es möglich, vollständig automatisch die ermittelten Meßwerte einer beobachtbaren Transaktion zuzuordnen sowie deren Reihenfolge zu rekonstruieren. Leider erwies sich dieser Ansatz an einigen wenigen Stellen aber ebenfalls als nicht ausreichend, um die vollständige Überwachung zu gestatten. Ein Problem stellte insbesondere die Identifikation des genauen Beginns und Endes einer vom Benutzer angestoßenen Transaktion sowie die eindeutige Zuordnung von Meßwerten im Falle sogenannter aktiv er Bausteine dar.
Die letztlich vorgeschlagene Architektur basierte daher auf einer Kombination beider Ansätze, wobei der Ansatz der Automation der Managemeninstrumentierung bausteinbasierter Anwendungen überwiegend verwendet wurde und nur an einigen wenigen Stellen auf eine Instrumentierung von Bausteinen wie im Ansatz der Komposition von Managementschnittstellen instrumentierter Bausteine beschrieben zurückgegriffen werden mußte. Es wurden sowohl die erforderlichen Schnittstellen als auch Methodiken für Anwendungs- und Bausteinentwickler angegeben, die eine problemlose Instrumentierung von Anwendungen und Bausteinen gestatten. Anschließend wurde anhand eines kurzen Beispiels eine mögliche Anwendung der gewonnenen Information für die Bestimmung und Schätzung der Verfügbarkeit von Anwendungsdiensten differenziert nach Anwendung, gewünschter Transaktion und Benutzer dargestellt.
Um die Umsetzbarkeit der vorgeschlagenen Architektur zu demonstrieren, wurde im Rahmen einer prototypischen Implementierung ein Entwicklungswerkzeug für JavaBeans, die sogenannte Beanbox dahingehend erweitert, daß beim Erstellen von Anwendungen automatisch Management-Code an den Verknüpfungsstellen zweier JavaBeans eingefügt wird. Die - nur in wenigen Ausnahmefällen erforderliche - Instrumentierung von JavaBeans wurde anhand einiger Beispiele demonstriert. Aus den instrumentierten sowie einer großen Anzahl von unveränderten JavaBeans wurden dann einfache Beispielanwendungen erstellt. Die durch die automatische Instrumentierung gewonnenen Meßwerte einiger Testläufe wurden mit Hilfe einer prototypischen Managementanwendung visualisiert.
Die vorliegende Arbeit konnte somit eine Architektur angegeben, die den Aufwand für die Managementinstrumentierung bausteinbasierter Anwendungen erheblich verringert. Damit konnte einer der wesentlichen Hinderungsgründe für eine zügige Verbreitung von Instrumentierungstechniken zur Anwendungsüberwachung beseitigt werden. Die Anzahl an verfügbaren instrumentierten Anwendungen könnte durch Verwendung der vorgeschlagenen Architektur zukünftig also wesentlich erhöht werden.