Design und Implementierung eines Eclipse-Plugins zum Performance Monitoring verteilter Anwendungen

Transkript

1 Fachhochschule Wiesbaden Fachbereich Design Informatik Medien Studiengang Allgemeine Informatik Diplomarbeit zur Erlangung des akademischen Grades Diplom-Informatiker/in (FH) Design und Implementierung eines Eclipse-Plugins zum Performance Monitoring verteilter Anwendungen vorgelegt von Morris Milekovic am 04. April 2006 Referent: Prof. Dr. R. Kröger Korreferent: Prof. Dr. K.O. Linn

2 II

3 Erklärung Ich versichere, das ich die Diplomarbeit selbstständig verfasst und keine anderen als die angegebenen Hilfsmittel benutzt habe. Idstein, Morris Milekovic Hiermit erkläre ich mein Einverständnis mit den im Folgenden aufgeführten Verbreitungsformen dieser Diplomarbeit: Verbreitungsform ja nein Einstellung der Arbeit in die Bibliothek der FHW Veröffentlichung des Titels der Arbeit im Internet Veröffentlichung der Arbeit im Internet Idstein, Morris Milekovic III

4 IV

5 Inhaltsverzeichnis 1 Einführung 1 2 Grundlagen Eclipse Einführung Architektur Die Plug-In-Architektur Das Standard Widget Toolkit Die Test and Performance Tools Platform Instrumentierung Einführung log4j Einführung Konzept API JDK Logging Einführung Konzept API Das Common Base Event Format Einführung Erweiterbarkeit Nutzung des CBE Formates Application Response Measurement Einführung V

6 Konzept API Java Binding Analyse Anforderungen Rahmenbedingungen Anwendungsfälle Registrierung Konfiguration Präsentation Datenquellen Einführung Existierende Ansätze Ermittlung der Daten Datenhaltung Genutzte Datenquellen Logging- und Tracing-Daten Performance-Daten Integration in das Performance Monitoring Plug-In Datenpräsentation Existierende Ansätze Genutzte Datenpräsentation Die AWT-Widgets Integration in das Performance Monitoring Plug-In Datenauswertung Existierende Auswertungsmodelle Bereitszustellende Auswertungen Integration in Eclipse Einführung Integration von Datenquellen Logging- und Tracing-Daten ARM-Datenquelle Integration der Datenpräsentation Integration des graphischen Editors VI

7 4 Design Architekturüberblick Das Performance Monitoring Plug-In Überblick Die Quellenverwaltung Überblick Registrierung der Datenquellen Der Observer Überblick Datenformat Datenimport Datenaktualisierung Die Editorverwaltung Überblick Initialisierung Der Controller Die View-Komponente Die Modell-Komponente Die Exportverwaltung Überblick Registrierung neuer Export Plug-Ins Zugriff während der Präsentation Die Präsentationsverwaltung Überblick Die Datendarstellung Registrierung neuer Datenpräsentations Plug-Ins Aufbau einer Verbindung Die Datenquellen Plug-Ins Einführung Architekturüberblick Das TPTP Datenquellen Plug-In Überblick VII

8 Datenerfassung Datenverwaltung Integration in Eclipse Das ARM Datenquellen Plug-In Überblick Datenerfassung Datenverwaltung Integration in Eclipse Die Datenpräsentation Überblick Registrierung Zugriff während der Präsentation Aufbau einer Verbindung Die Export Plug-Ins Einführung Architektur Registrierung Zugriff während der Präsentation Das Datenauswertungs Plug-In Das Datensicherungs Plug-In Implementierung Einleitung Entwicklungsumgebung Namenskonventionen Registrierung der Plug-Ins Das Performance Monitoring Plug-In Die Quellenverwaltung Registrierung der Datenquellen Der Extension Point dataaccess Der Observer Die Editorverwaltung Initialisierung VIII

9 Der Controler Die View-Komponente Die Modell-Komponente Die Exportverwaltung Registrierung neuer Export Plug-Ins Zugriff während der Präsentation Die Präsentationsverwaltung Die Datenquellen Plug-Ins Überblick Datenerfassung Datenverwaltung Die Datenpräsentation Die Export Plug-Ins Einführung Das Datenauswertungs Plug-In Das Datensicherungs Plug-In Implementierungsaufwand Fallbeispiel Zusammenfassung Literaturverzeichnis 183 A Abkürzungen 185 B Das CBE Datenformat 187 B.1 Datentypen B.2 Das Datenformat B.2.1 Überblick B.2.2 Component Identification IX

10 X

11 Abbildungsverzeichnis 2.1 Eclipse Architektur nach [Riv03] Plugin Architektur in Eclipse nach [Riv03] Mögliche Verteilung einer neuen Funktionalität nach [Dau05] Architektur des Remote Agent Controller [CS05] Architekturüberblick Hyades Appender gemäß [Roo05] Überblick über die ARM Management System Interaction nach [Gro04] Verteilte Transaktionen nach [Gro04] Verteilte Transaktionen nach [Gro04] ARM Transaction unter Verwendung von start()/stop() nach [Gro04] Zeitmessung durch eine Anwendung nach [Gro04] Anwendungsfälle Registrierung Anwendungsfälle Konfiguration Anwendungsfälle Präsentation Anwendungsfälle Präsentation der Export-Komponenten Modell der Datenermittlung durch eine zusätzliche Komponente Zugriff auf die CBE-Daten Überblick über das Graphical Editing Framework nach [Hud03] Zusammenspiel von Modell, Edit-Part und Graphical Viewer nach [Hud03] Architekturüberblick über das Performance Monitoring Plug-In Überblick Performance Monitoring Plug-In Überblick Quellenverwaltung im Performance Monitoring Plug-In Klassendiagramm der Quellenverwaltung Ablauf der Registrierung eines neuen Datenquellen Plug-Ins Überblick über die Architektur des Observer im Performance Monitoring Plug-In XI

12 4.7 Klassendiagramm des Observer Klassendiagramm des GenericPerformanceData Formats Aufbau des GenericPerformanceData-Objekts Eindeutigkeit der Namen innerhalb des GenericPerformanceData-Formats Ablauf der initialen Datenerfassung Ablauf der Datenaktualisierung für die Auswahl der Daten Auswahl eines Attributs für die Datenaktualisierung Ablauf der Datenaktualisierung Überblick über die Editor-Komponente Klassendiagramm der Editorverwaltung Klassendiagramm des Modells innerhalb des graphischen Editors Überblick Exportverwaltung im Performance Monitoring Plug-In Klassendiagramm der Exportverwaltung Ablauf der Registrierung der Export Plug-Ins Aktivierung einer Auswertung eines Export Plug-Ins Überblick über die Architektur der Präsentationsverwaltung Klassendiagramm der Datendarstellung Abbildung der GenericPerformanceData-Objekte innerhalb des Data- Selection-Views Ablaufdiagramm Monitoring Starten Klassendiagramm der Registrierung neuer Datenpräsentations Plug-Ins Verbindungsaufbau für die Werteversorgung eines Widgets Schematische Übersicht über die Werteversorgung eines Widgets aus einem Datenquellen Plug-In Datenübertragung der Logging- und Tracing-Daten an das TPTP Datenquellen Plug-In Architekturüberblick TPTP Datenquellen Plug-In Klassendiagramm der Datenermittlung im TPTP Datenquellen Plug-In Klassendiagramm der Preferences im TPTP Datenquellen Plug-In Datenübertragung der Performancedaten an das ARM Datenquellen Plug-In Architekturüberblick ARM Datenquellen Plug-In Klassendiagramm der Datenerfassung im ARM Datenquellen Plug-In XII

13 4.36 Klassendiagramm des ARM Data Access-View im ARM Datenquellen Plug-In Klassendiagramm der Datenpräsentation im ARM Datenquellen Plug-In Ablauf des Zeichnens eines AWT-Widgets nach den Angaben des Modells Ablauf der Identifizierung eines Widgets Architekturüberblick über die Export Plug-Ins Klassendiagramm einer Eclipse View-Action Klassendiagramm des Datenauswertungs Plug-Ins Auswahl der statistischen Filter über ein Kontextmenü Klassendiagramm des Datensicherungs Plug-In Die Klasse PerformanceMonitoringPlugin Überblick über die Package-Struktur des Performance Monitoring Plug-Ins Packagediagramm der Quellenverwaltung Packagediagramm des Observers Packagediagramm der Editorverwaltung Ablauf Initialisierung des graphischen Editors Packagediagramm der Exportverwaltung Packagediagramm der Präsentationsverwaltung Packagediagramm des TPTP Datenquellen Plug-In Packagediagramm des ARM Datenquellen Plug-In Ablauf der Datenerfassung in den Datenquellen Plug-Ins Erzeugung des Counter-Filters im Datensicherungs Plug-In Packagediagramm des Datenauswertungs Plug-In Packagediagramm des Datensicherungs Plug-In Die speisenden Philosophen nach [Tan02] Zusammenstellen einer Monitoring-Ansicht Registrierte Datenquellen Plug-Ins im Data Selection-View Auswahl der zu überwachenden Anwendung im ARM Data-Access-View Übersicht der ermittelten Daten im Data Selection View Momentaufnahme der Überwachung der Anwendung durch den Monitoring View B.1 Überblick über das Common Base Event Format B.2 Component Identification XIII

14 XIV

15 Tabellenverzeichnis 2.1 Überblick Hyades Appender Besetzung der CBE-Attribute durch log4j und JDK Logging Mapping CBE-Severity auf log4j bzw. JDK Logging Besetzung der ComponentIdentification durch log4j und JDK Logging Besetzung der sourcecomponentid durch log4j und JDK Logging Besetzung der extendeddataelements durch log4j Besetzung der ARM Context Properties durch emiva Überblick über die bereitgestellten AWT-Widgets de.fh_wiesbaden.cs.vs.performancemonitoring de.fh_wiesbaden.cs.vs.performancemonitoring.dataexport de.fh_wiesbaden.cs.vs.performancemonitoring.editor de.fh_wiesbaden.cs.vs.performancemonitoring.manager de.fh_wiesbaden.cs.vs.performancemonitoring.figures de.fh_wiesbaden.cs.vs.performancemonitoring.model de.fh_wiesbaden.cs.vs.performancemonitoring.model.commands de.fh_wiesbaden.cs.vs.performancemonitoring.parts de.fh_wiesbaden.cs.vs.performancemonitoring.preferences de.fh_wiesbaden.cs.vs.performancemonitoring.sourceregistration de.fh_wiesbaden.cs.vs.performancemonitoring.views de.fh_wiesbaden.cs.vs.performancemonitoring.wizards de.fh_wiesbaden.cs.vs.tptpdatasource de.fh_wiesbaden.cs.vs.tptpdatasource.dataaccess de.fh_wiesbaden.cs.vs.tptpdatasource.manager de.fh_wiesbaden.cs.vs.tptpdatasource.preferences XV

16 5.17 de.fh_wiesbaden.cs.vs.armdatasource de.fh_wiesbaden.cs.vs.armdatasource.dataaccess de.fh_wiesbaden.cs.vs.armdatasource.manager de.fh_wiesbaden.cs.vs.armdatasource.preferences de.fh_wiesbaden.cs.vs.armdatasource.views de.fh_wiesbaden.cs.vs.performancemonitoringstatisticalfilter de.fh_wiesbaden.cs.vs.performancemonitoringstatisticalfilter.actions de.fh_wiesbaden.cs.vs.performancemonitoringstatisticalfilter.filterthreads de.fh_wiesbaden.cs.vs.performancemonitoringstatisticalfilter.manager de.fh_wiesbaden.cs.vs.performancemonitoringstatisticalfilter.preferences de.fh_wiesbaden.cs.vs.performancemonitoringstatisticalfilter.registration de.fh_wiesbaden.cs.vs.performancemonitoringdatawriter de.fh_wiesbaden.cs.vs.performancemonitoringdatawriter.manager de.fh_wiesbaden.cs.vs.performancemonitoringdatawriter.registration Gesamtübersicht Implementierungsaufwand Ausschnitt aus den festgehaltenen Zeitspannen der Überwachung des vierten Philosophen B.1 Datentypen des CBE-Formates B.2 Severity-Level des CBE-Format B.3 Schlüsselwörter des location-property B.4 Schlüsselwörter des componentidtype-property XVI

17 Verzeichnis der Quellcodes 2.1 Initialisierung eines Loggers Ausgabe von Logmeldungen Zugriff auf die Konfigurationsdatei Beispiel-Konfigurationsdatei im Property-Format Zugriff auf den NDC-Kontext Nutzung des JDK Logging Beispielkonfigurationsdatei JDK Logging Einbettung eines AWT-Objekts in ein SWT Die Datei plugin.xml des Performance Monitoring Plug-In Registrierung eines Datenquellen Plug-Ins Definition des Extension Points dataaccess Attribute des Extension Points dataaccess Erzeugung eines AWT-Widgets für die Präsentation Benennung des Extension Point dataaccess in durch das TPTP Datenquellen Plug-In Datenaktualisierung in einem Datenquellen Plug-In Benennung des dataexport Extension Points durch das Datenauswertungs Plug-In Benennung des dataexport Extension Points durch das DataWriter Plug-In Hauptschleife der speisenden Philosophen Ausschnitt aus der Sicherungsdatei der Überwachung Ausschnitt aus der Ablauf-Protokollierungsdatei des Fallbeispieles XVII

18 XVIII

19 Kapitel 1 Einführung In nahezu jedem Bereich des Alltags begegnet man informationsverarbeitenden Softwareanwendungen. So stellt beispielsweise das Abwickeln der Bankgeschäfte per online- Banking, oder das Buchen einer Reise über das Internet längst kein außergewöhnliches Ereignis mehr dar. Diese Entwicklung hat dazu geführt, dass dererlei Angebote für eine breite Masse zu einem selbstverständlichen Bestandteil des Lebens geworden sind. Um einer wachsenden Nachfrage vielfältiger Angebote gerecht werden zu können, entstehen immer komplexere und aufwendigere Softwaresysteme. Daraus ergeben sich zwangsläufig Herausforderungen, denen sich die Anbieter und Betreiber solcher Anwendungen stellen müssen. Dazu zählt unter anderem die Frage nach der Performanz einer Anwendung, insbesonders bei Softwaresystemen, die für die Sicherheit und das Wohlbefinden von Menschen verantwortlich sind. Dabei wird von einer Anwendung verlangt, dass sie eine Anfrage in einer festgelegten Zeitspanne bearbeitet kann. Damit Software solchen Qualitätskriterien entsprechen kann, müssen geeignete Maßnahmen, sowohl während der Entwicklungsphase als auch für den laufenden Betrieb, ergriffen werden, wozu beispielsweise das Instrumentieren der Anwendung gehört. Über das Einbringen von geeigneten Anweisungen lassen sich, insbesondere während der Entwicklungsphase im Rahmen eines Performance-Debuggings, Schwachstellen und Flaschenhälse finden. Während des Betriebs können wertvolle Informationen über den inneren Zustand der Anwendung gewonnen werden. Außerdem können vorgegebene Antwortzeiten im Rahmen eines Service Level Monitorings überwacht oder die Abarbeitungsreihenfolge innerhalb der Anwendung leichter nachvollzogen und dokumentiert werden. Dabei lassen sich die entsprechenden Informationen in Abhängigkeit des aktuellen Lastzustandes der Anwendung kontinuierlich ermitteln, was wiederum auch für einzelne Teilbereiche oder spezielle Abschnitte der Anwendung möglich ist. Dadurch werden wertvolle Informatio- 1

20 Kapitel 1. Einführung nen für eine detaillierte Überwachung und Auswertung gewonnen. Vor allem die Möglichkeit, die Antwortzeit einer Anfrage zu ermitteln, ist ein wertvoller Indikator für das Feststellen der Leistungsfähigkeit einer Anwendung. Das trifft insbesondere während der Laufzeit der Anwendung zu. So lassen sich durch die Überwachung von ausgewählten Schlüsselstellen in einer laufenden Anwendung frühzeitig Probleme und eventuell drohende Fehlfunktionen aufspüren. Dadurch wird die Möglichkeit geboten, regulierend einzugreifen, wodurch Schäden vermieden werden können. Solche Anforderungen verlangen natürlich nach geeigneten Instrumentierungsmechanismen, wodurch die benötigten Informationen ermittelt und mitgeteilt werden können. Außerdem werden entsprechende Auswertungswerkzeuge benötigt, die in der Lage sind, die gewonnen Informationen schnell und sicher so zu verarbeiten, dass sie anschließend optisch ansprechend dargestellt werden. Eine Person, deren Aufgabe in der Überwachung einer solchen Anwendung besteht, muss durch einen Blick die wesentlichen Kenngrößen und den aktuellen Zustand erfassen können, damit festgestellt werden kann, ob ein Eingreifen notwendig ist oder nicht. Für das Integrieren solcher Instrumentierungsanweisungen in eine Anwendung gibt es unterschiedliche Ansätze, wie beispielsweise das Einbringen in den Quellcode der Anwendung. Dabei ist allerdings zu beachten, dass eine solche Instrumentierung einen zeitaufwendigen Prozess und eine potentielle Fehlerquelle darstellt. Zum einen müssen die geeigneten Stellen und Abschnitte innerhalb der Anwendung identifiziert werden, die sich für das Ermitteln der Informationen eignen. Zum anderen kann das Einbringen des Codes an sich Fehler verursachen. Das Projekt effiziente Modell-basierte Instrumentierung verteilter Anwendungen (emiva) unterstützt Softwareentwickler bei einer Quellcode- Instrumentierung von Anwendungen. Dabei wird eine Verbesserung in Hinblick auf Fehlerfreiheit und Effizienz bei der Integration entsprechender Quellcodefragmente erreicht. Durch emiva werden Werkzeuge bereitgestellt, welche die integrierte Entwicklungsumgebung Eclipse erweitern. Das Projekt wird vom Labor für Verteilte Systeme 1 der Fachhochschule Wiesbaden, gemeinsam mit der tang-it Consulting GmbH 2 in Wiesbaden und DFS Deutsche Flugsicherung GmbH 3 in Langen durchgeführt. Für eine Quellcode- Instrumentierung auf Methodenebene verfolgt emiva Ansätze basierend auf: Strukturierten Kommentaren und aspektorientierter Programmierung (AOP), Markern in der integrierten Entwicklungsumgebung, Einem UML-Modell der Anwendung und abstrakten Instrumentierungsmustern

21 Kapitel 1. Einführung Im Rahmen der aspektorientierten Programmierung werden strukturierte Kommentare in die Anwendung eingebracht, aus denen Instrumentierungscode generiert und mittels AOP in die Anwendung eingeflochten wird. Im zweiten Fall wird der Editor der Entwicklungsumgebung um graphische Marker erweitert. Mit diesen Markern kann der Entwickler die geeigneten Stellen des Anwendungscodes auszeichnen und per Knopfdruck aus dieser graphischen Repräsentation Instrumentierungscode in einer der unterstützten Sprachen - derzeit Java und C/C++ - generieren lassen. Innerhalb des dritten Ansatzes erfolgt die Instrumentierung bereits im UML-Modell der Anwendung. Dafür unterstützt emiva die folgenden Instrumentierungsarchitekturen: ARM API 4.0 für C/C++ und Java log4j und JDK Logging log4cxx Unter Einsatz der von emiva bereitgestellten Werkzeuge wird bei der DFS eine Performance-Instrumentierung des Radardatenverarbeitungssytem Phoenix realisiert, um ein umfassendes Performance-Monitoring der Anwendung zu ermöglichen. Die vorliegende Diplomarbeit wird im Rahmen des emiva-projektes erarbeitet. Das Ziel besteht in der Entwicklung geeigneter Werkzeuge für das vorgesehene Performance Monitoring verteilter Anwendungen, die in die Entwicklungsumgebung Eclipse integriert werden. Diese Werkzeuge sollen eine graphische Auswertung der gewonnenen Instrumentierungs-Informationen während der Laufzeit einer Anwendung ermöglichen, um so Aussagen über das Verhalten der Anwendung treffen zu können. Als Grundlage für die Überwachung dienen die Instrumentierungs-Informationen der von emiva unterstützten Architekturen log4j, JDK-Logging sowie ARM. Darüber hinaus sollen die zu entwickelnden Werkzeuge auch die Möglichkeit bieten, sowohl weitere Architekturen zu integrieren, als auch Anwendungen zu überwachen, die nicht durch emiva instrumentiert wurden. Für die graphische Anzeige der ermittelten Informationen kommen unterschiedliche Grafikkomponenten zum Einsatz, die auch als Widgets bezeichnet werden. Jedes dieser Widgets bietet eine Form der Anzeige, wie beispielsweise ein Diagramm oder eine numerische Anzeige. Sie werden vom Labor für Verteilte Systeme der Fachhochschule Wiesbaden bereitgestellt und stammen aus einem Projekt, in dem sie zur Steuerung und Überwachung von verteilten CORBA-Anwendungen genutzt wurden. Innerhalb der umzusetzenden Arbeit sollen diese Widgets durch die Nutzung eines graphischen Editors auf einer Oberfläche angeordnet werden können. Dadurch wird die Möglichkeit geboten, unterschiedliche 3

22 Kapitel 1. Einführung Monitoring-Oberflächen zusammenzustellen, die sich für die jeweilige Überwachung am besten eignen. Für die Nutzung in dem geschilderten Rahmen werden sie in die zu entwickelnden Werkzeuge integriert. Für eine Überwachung sollen zeitgleich unterschiedliche Datenquellen genutzt werden können, wobei Logging-, Tracing- und Performance-Daten unterstützt werden sollen. Die Werkzeuge selbst werden als Plug-Ins für die integrierte Entwicklungsumgebung Eclipse realisiert. Die Übertragung der Logging und Tracing- Daten erfolgt durch die TPTP-Plattform, die ebenfalls in Form von Plug-Ins für Eclipse zur Verfügung steht. Für die Auswertung der ARM-Daten wird auf eine bereitgestellte Software-Bibliothek der tang-it Consulting GmbH zurückgegriffen. In den folgenden Kapiteln werden die einzelnen Komponenten genauer beschrieben. Außerdem wird deren Einbettung in das umzusetzende Plug-In dargestellt. Zunächst wird im Kapitel Grundlagen die Entwicklungsumgebung Eclipse vorgestellt. Es wird deren Architektur beschrieben und gezeigt, wie sie durch Plug-Ins erweitert werden kann. Dabei wird auch die innerhalb von Eclipse zu nutzende Grafikbibliothek Standard Widget Toolkit (SWT) vorgestellt. Abgeschlossen wird dieser Teil mit einer Beschreibung der Test and Performance Tools Platform (TPTP). Innerhalb des Themenkomplexes Instrumentierung erfolgt zunächst eine Einführung in das Thema, gefolgt von der Vorstellung der Architekturen log4j, JDK Logging und ARM. In diesem Zusammenhang wird auch das Common Base Event-Format vorgestellt. Das Kapitel Analyse untersucht die zum Einsatz kommenden Komponenten und zeigt in einem ersten Entwurf, wie das Ziel dieser Diplomarbeit erreicht werden kann. Dazu fasst es zunächst die Anforderungen an diese Arbeit zusammen, indem es im ersten Schritt die allgemeinen Rahmenbedingungen formuliert. Anschließend wird anhand der vorgestellten Anwendungsfälle die geforderte Funktionalität beschrieben. Im weiteren Verlauf werden die Datenquellen vorgestellt, die zum einen von aktuellen Monitoring Werkzeugen eingesetzt, und zum anderen im Rahmen dieser Diplomarbeit genutzt werden. Der Teil Datenpräsentation diskutiert die unterschiedlichen Möglichkeiten der Anzeige von ermittelten Informationen. Wie diese Informationen zusätzlich noch ausgewertet werden können, wird in Abschnitt Datenauswertung erklärt. Der letzte Teil dieses Kapitels befasst sich mit der Integration der einzelnen Komponenten in Eclipse. Einen genauen Einblick, wie die gewonnenen Erkenntnisse umgesetzt werden können, enthält das Kapitel Design. Es bietet einleitend einen Architekturüberblick der in groben Zügen aufzeigt, wie das Ziel dieser Diplomarbeit erreicht werden kann. In den darauf folgenden Abschnitten wird der vorgestellte Entwurf weiter ausgearbeitet. Am Ende des Kapitels liegt das vollständige Design der umzusetzenden Werkzeuge vor. Dabei wird für jede Komponente gezeigt, wie sich die Anforderungen mit den verfügbaren Möglichkeiten konzeptionell umsetzten lassen. Implementierungsspezi- 4

23 Kapitel 1. Einführung fische Details der einzelnen Werkzeuge fasst das Kapitel Implementierung zusammen. Im Anschluss wird der Einsatz dieser Werkzeuge durch ein Fallbeispiel demonstriert. Abgeschlossen wird die Diplomarbeit mit einer Bewertung der erreichten Ergebnisse dieser Arbeit, zu der auch ein Ausblick hinsichtlich künftiger Erweiterungen gehört. Um innerhalb dieser Arbeit die Orientierung zu vereinfachen, wurden die folgenden Konventionen eingeführt: Quellcode Quellcodefragmente, sowie Klassen und Methodenname werden in Nichtproportionalschrift gesetzt. Wichtige Begriffe Wichtige Begriffe werden bei ihrer Definition kursiv dargestellt. 5

24 6 Kapitel 1. Einführung

25 Kapitel 2 Grundlagen Dieses Kapitel dient der Vorstellung der unterschiedlichen Architekturen und Komponenten, die im Rahmen dieser Diplomarbeit zum Einsatz kommen. Dem Leser wird dabei ein grundlegender Überblick gegeben. Des weiteren werden Begriffe eingeführt, die zum Verständnis der Aufgabenstellung notwendig sind. Der erste Teil stellt die Entwicklungsumgebung Eclipse vor. Dieser Abschnitt enthält auch die Vorstellung des Plug-In Mechanismuses von Eclipse und eine Einführung in das Standard Widget Toolkit (SWT), gefolgt von der Vorstellung des Test and Performance Tools Platform-Projekt (TPTP). Der zweite Teil beginnt mit einer Einführung in das Thema Instrumentierung. Anschließend werden drei Instrumentierungsarchitekturen vorgestellt: log4j, JDK Logging und das Application Response Measurement (ARM). In diesem Zusammenhang wird auch das für diese Arbeit wichtige Common Base Event-Format vorgestellt. 2.1 Eclipse Einführung Eclipse ist als eine leistungsstarke integrierte Entwicklungsumgebung (Integrated Development Enviroment (IDE)) unter Java-Entwicklern bekannt, ist jedoch nicht auf die Programmiersprache Java beschränkt. Mittlerweile gibt es Erweiterungen, die die Entwicklung von Anwendungen unter C/C++, PHP, COBOL und weiteren Sprachen unterstützen. Seinen Ursprung hat das Eclipse Projekt in der von IBM 2001 gegründeten Eclipse Board of Stewards, zu der auch sieben weitere Software-Hersteller gehörten. Ziel war es, Eclip- 7

26 2.1. Eclipse Kapitel 2. Grundlagen se als Open-Source -Projekt zu etablieren. Dieses, im Laufe der Zeit weiter gewachsene Konsortium, wurde 2004 in eine not-for-profit Organisation umgestaltet, der Eclipse Foundation 1, in der IBM allerdings immer noch eine gewichtige Rolle einnimmt. Die Eclipse Foundation verwaltet seitdem die gesamte Entwicklung von Eclipse und ist auf über 150 Mitglieder angewachsen. Heute erfreut sich Eclipse sehr großer Beliebtheit und kann leicht um unterschiedliche Entwicklungswerkzeuge erweitert werden. Laut [SFK + 04] war das oberste Ziel bei der Entwicklung von Eclipse, eine Plattform zur Verfügung zu stellen, welche die Integration von Entwicklungswerkzeugen unterstützt. So wird gemäß der Eclipse Foundation Eclipse als eine Platform für alles Mögliche und nichts im Besonderen bezeichnet. Eclipse ist daher mehr als eine reine Entwicklungsplattform. Ermöglicht wird dies durch eine Plug-In-Architektur. Dadurch wird es leicht erweiterbar und unterstützt das Erstellen, Integrieren, Erweitern und Nutzen von neuen Softwarewerkzeugen. Mit Ausnahme eines kleinen Kerns wird die gesamte Funktionalität von Eclipse durch unterschiedliche Plug- Ins bereitgestellt. Zur Unterstützung der Entwicklung eigener Werkzeuge (Tools) stellt Eclipse eine Reihe höherer Klassen wie Editoren, Viewer, Ressourcenverwaltungs-, Problembehandlungsund Hilfs-Systeme, sowie verschiedene Assistenten und Wizards zur Verfügung. Diese Klassen werden von Eclipse selbst bei der Implementierung der eigenen Arbeitsoberfläche (Workbench) oder in der Java-IDE genutzt. Für die Entwicklung eigener Plug-Ins bietet Eclipse das Plug-In Development Enviroment (PDE) Framework 2 an. Mit der Version 3.x wurde das Konzept der Rich Client Plattform (RCP) eingeführt. Darunter versteht die Eclipse Foundation: das minimale Set von Plug-Ins, die notwendig sind, um eine Client-Anwendung zu entwickeln. Diese stellen das Minimumm an graphischer Oberfläche und Laufzeitumgebung zur Verfügung. Die Eclipse-Plattform wurde dabei so konzipiert, dass zusätzlich benötigte Funktionalität mit den von Eclipse bereitgestellten, einzelnen generischen Komponenten hinzugefügt werden kann. Desweiteren kann eine Rich-Client-Anwendung auch über eigene Plug-Ins erweitert werden. Eclipse selbst ist in der Programmiersprache Java geschrieben und steht in der Version 3.1 für eine Vielzahl von Betriebssystemen unter der Eclipse Public License 3 frei zur Verfügung 4. Im Rahmen dieser Diplomarbeit wird Eclipse in der Version 3.1 eingesetzt engl. Rahmenwerk. Es bezeichnet eine Anwendungsarchitektur, die eine Unterstützung für die Entwicklung eigener Anwendungen bietet

27 Kapitel 2. Grundlagen 2.1. Eclipse Architektur Dieser Abschnitt soll einen Einblick in die Eclipse-Architektur geben und die wesentlichen Komponenten vorstellen. Abbildung 2.1 zeigt den Aufbau der Eclipse-Plattform. Abbildung 2.1: Eclipse Architektur nach [Riv03] Die Eclipse Platform beinhaltet die wesentlichen Komponenten des Eclipse-Projektes und bildet für diese die gemeinsame Grundlage. Sie wird in zwei Bereiche unterteilt: in den als core bezeichneten Teil und in den als UI (User Interface) bezeichneten Teil. Zum Eclipse-Core gehört die Platform Runtime, der Workspace und Ant 1. Zum Teil UI gehört die Workspace-Komponente mit den Bibliotheken SWT und JFace. Die Komponenten Help, Team und Debug werden beiden Teilen zugeordnet. Die Platform Runtime bildet den Kern der Eclipse-Plattform. Diese Platform Runtime fungiert dabei als ein Mikrokern, indem sie nur die notwendigsten Startaufgaben einer Eclipse-Instanz übernimmt. Dazu gehört das Registrieren aller installierten Plug-Ins. Der Workspace verwaltet Dateien, Verzeichnisse und Projekte, die ein Anwender angelegt hat und mit denen er arbeitet. Diese werden auch als resources bezeichnet. Damit Werkzeuge wie etwa Editoren auf diese Ressourcen zugreifen können, stellt der Workspace den Plug-Ins seine API zur Verfügung, über die Modifikationen durchgeführt werden können

28 2.1. Eclipse Kapitel 2. Grundlagen Außerdem ermöglicht diese Komponente das Navigieren durch die Ressourcen, bildet die Struktur der Projekte auf das Dateisystem ab und sorgt für die Persistenz und die Wiederherstellung von Ressourcen. Die Workbench bildet die Benutzer-Schnittstelle zu Eclipse (UI) durch Editoren, Views und Perspektiven. Views dienen der Darstellung von Informationen über Objekte. Als Beispiel dient der Navigator View, der alle Objekte innerhalb eines Workspace anzeigt. Perspektiven erlauben es, mehrere Views gruppiert zur Anzeige zu bringen. Die Graphikbibliothek SWT sorgt dabei für die Darstellung der graphischen Objekte innerhalb der Workbench und wird in Abschnitt näher vorgestellt. JFace baut auf dem SWT auf und realisiert komplexere UI-Aktionen. Dazu gehören Dialoge, Wizards und Preferences (preferences (engl.) = Vorlieben, bedt. Einstellungen). Die Komponente Team ermöglicht das Entwickeln von Anwendungen innerhalb eines Teams durch ein Versions- und Konfigurationsmanagement (VCM). Debug ermöglicht das Finden von Fehlern während der Entwicklung von Anwendungen. Help bietet dem Anwender Zugriff auf Hilfsthemen über einen Web Browser. Ant unterstützt das Kompilieren von Projekten, sodass diese lauffähig ausgeliefert werden können. Das Java Development Tool (JDT) ermöglicht das Entwickeln von Java-Anwendungen. Diese Komponente ist als Plug-In realisiert und nutzt das Eclipse API für die Integration in Eclipse. Das JDT wird vom PDE genutzt, indem es auf die JDT-API und auch auf die Eclipse API zugreift. Die in Abbildung 2.1 gezeigten Komponenten Tool 1, Tool 2 und Tool 3 stellen Werkzeuge dar, die die Eclipse-Funktionalität erweitern. Diese sind jeweils als einzelne Plug-Ins realisiert, wobei es unter diesen einzelnen Tools Abhängigkeiten geben kann (Tool 3 besitzt eine Abhängigkeit zu Tool 2). Die einzelnen Tools können eigene Entwicklungen sein oder auch Werkzeuge anderer Anbieter. Seit der Eclipse Version 3.x müssen Plug-Ins dem Standard Open Service Gateway Initiative 1 (OSGi) entsprechen. Diese Architektur ermöglicht das Hinzufügen von Plug-Ins zur Laufzeit, ohne dass Eclipse neu gestartet werden muss, sofern die darin laufenden Plug- Ins in der Lage sind, auf unterschiedliche Konfigurationen zu reagieren. Zudem können verschiedene Versionen desselben Plug-Ins nebeneinander laufen

29 Kapitel 2. Grundlagen 2.1. Eclipse Die Plug-In-Architektur Durch die Plug-In-Architektur ist es möglich, Eclipse um eine neue Funktionalität zu erweitern. Diese neue Funktionalität wird durch ein Plug-In realisiert. Ein Plug-In (to plug (engl.) = einstecken) ist in Java entwickelt worden und bildet nach [Obj03], die kleinste funktionale Einheit innerhalb von Eclipse und kann als eigenständige Einheit entwickelt, getestet und weitergegeben werden. Es besteht auch die Möglichkeit, eine neue Funktionalität auf mehrere Plug-Ins zu verteilen. Damit ein Plug-In auf die bereits bestehende Funktionalität von Eclipse oder anderer Plug-Ins zugreifen kann, muss es Extension Points (extension (engl.) = die Erweiterung, Erweiterungspunkte) benennen. Ein solcher Extension Point stellt nach [SFK + 04] einen nach außen offenen Zugriffspunkt dar, der die Möglichkeit bietet, die Funktionalität des eigenen Plug-Ins oder die anderer Plug-Ins zu erweitern. Er stellt damit eine eindeutig benannte Schnittstelle dar, an die sich andere Plug-Ins andocken können, um die Funktionalität des bisherigen Plug-Ins zu erweitern. Eine Erweiterung wird Extension genannt. Um Eclipse den Zugriff auf die Funktionalität aller installierten Plug-Ins zu ermöglichen, müssen sie der gestarteten Eclipse-Instanz bekannt gemacht werden. Dazu liest die Platform Runtime die Manifestdateien aller installierten Plug-Ins ein. Jedes Plug-In enthält mindestens die Manifestdatei plugin.xml. Mit der Eclipse Version 3.x ist eine zweite Manifestdatei hinzugekommen, um dem OSGi Standard zu entsprechen. Plug-Ins enthalten seitdem die Manifestdateien plugin.xml und MANIFEST.MF. Die Manifestdatei MANIFEST.MF wird auch als OSGi-Manifestdatei bezeichnet (siehe Abschnitt 2.1.2). Diese Datei enthält beispielsweise Angaben über die Abhängigkeiten des Plug-Ins, benötigte Bibliotheken und Laufzeitinformationen. In vorherigen Versionen von Eclipse wurden diese Informationen auch in der Datei plugin.xml angegeben. Mit der Umstellung auf OSGi mit Eclipse 3.x enthält die plugin.xml nur noch Angaben über die Extension Points und die Extension, die dieses Plug-In benennt bzw. erweitert. Beide Dateien liegen im XML-Format vor. Für die Verwaltung eines Plug-Ins bietet Eclipse mit der Umstellung auf OSGi einen Manifesteditor, der das Editieren der MANIFEST.MF-Datei komfortabel ermöglicht. Die Realisierung einer Extension erfolgt durch die Ableitung der Klassen des zu erweiternden Plug-Ins, das den Extension Point bereitstellt, oder durch die Implementierung entsprechender Interfaces. Möchte ein neues Plug-In beispielsweise die bestehende Menüleiste von Eclipse nutzen, um ein eigenes Icon anzuzeigen, muss es den Extension Point org.eclipse.ui benennen. Dadurch erhält das neue Plug-In Zugang zur bestehenden Eclipse Menüleiste und kann diese, durch die Implementierung der entspre- 11

30 2.1. Eclipse Kapitel 2. Grundlagen chenden Schnittstelle, erweitern. Dadurch wird der Menüleiste eine weitere Extension zur Verfügung gestellt. Abbildung 2.2 zeigt das Erweitern der Funktionalität eines bestehenden Plug-Ins durch ein neues Plug-In. Plug-In A deklariert den Extension Point P. Das Abbildung 2.2: Plugin Architektur in Eclipse nach [Riv03] zugehörige Interface I stellt die erforderlichen Schnittstellen für den Extension Point P bereit. Plug-In B implementiert mit seiner Klasse C die Schnittstellen des Interface I und erweitert so den Extension Point P mit der eigenen Extension. Plugin A instantiiert bei Bedarf die Klasse C des Plug-Ins A und kann die Methoden des Interfaces I aufrufen. Alle Plug-Ins, die die Funktionalität einer Eclipse-Installation ausmachen, befinden sich in einem eigenen Verzeichnis mit Namen plugins innerhalb des Eclipse Installationsverzeichnisses. Beim Start von Eclipse wird innerhalb dieses Verzeichnisses nach den Manifestdateien eines jeden Plug-Ins gesucht und diese eingelesen. Dadurch wird die Plugin Registry aufgebaut, wodurch alle Plug-Ins registriert werden. Anschließend steht die Funktionalität dieser Plug-Ins über die Eclipse Plattform zur Verfügung. Wird die Funktionalität eines Plug-Ins benötigt (indem der Anwender z.b. ein Menü-Icon drückt) wird das spezielle Plug-In, das diese Funktionalität implementiert, über den eigenen Java Classloader geladen. Dieser sorgt für die Instantiierung der Plug-In-Klasse, die die benötigte Funktionalität implementiert hat. In Abbildung 2.2 entspräche das der Klasse C. Ein Plug-In gilt ab diesem Moment als aktiviert und bleibt in diesem Zustand, bis die Eclipse-Instanz beendet wird. Dieses, als lazy loading bekannte Verfahren, ermöglicht eine effizientere und ressourcenschonende Arbeitsweise, da die Anzahl der installierten Plug-Ins stark ansteigen kann. Wenn die Funktionalität eines Plug-Ins nur bereitgestellt, aber noch nicht genutzt wird (d.h. die Plug-In-Klasse nicht instantiiert wurde), ist dieses Plug-In im Zustand aktiv. Aus Sicht des OSGi-Standards erfolgt die Registrierung eines Plug-Ins nach folgendem Muster. OSGi konforme Dienste (oder OSGi Bundles) müssen das Interface 12

31 Kapitel 2. Grundlagen 2.1. Eclipse BundleActivator implementieren. Ein Plug-In entspricht einem OSGi Bundle, die Platform Runtime entspricht einem OSGi-Server. In der start() Methode des OSGi- Bundle registriert sich dieser Dienst bei einem OSGi-Server. Dadurch steht dieser Dienst zur Verfügung. Die Abmeldung des Dienstes erfolgt in der stop() Methode des OSGi- Bundles. Dieses Modell wird von Eclipse wie folgt genutzt. Die Initialisierung des Plug- Ins erfolgt durch die start()-methode, die von Eclipse aufgerufen wird. Dort können entsprechende Aufgaben erledigt werden. Analog dazu, können in der stop()-methode entsprechende Aufräumarbeiten durchgeführt werden. Es gibt insgesamt drei Möglichkeiten, Eclipse eine neue Funktionalität hinzuzufügen. Abbildung 2.3 zeigt ein Beispiel, indem eine neue Funktionalität auf drei Plug-Ins ver- Abbildung 2.3: Mögliche Verteilung einer neuen Funktionalität nach [Dau05] teilt wird. Neben Plug-Ins bietet Eclipse auch Features. Features bieten die Möglichkeit, mehrere Plug-Ins zu gruppieren. Dies ist dann sinnvoll, wenn eine Funktionalität durch mehrere Plug-Ins realisiert wird, wie in Abbildung 2.3 gezeigt. Darüber hinaus besteht die Möglichkeit, ein Feature zu erweitern. Dazu gehört beispielsweise die Angabe eines Lizenzvertrages und die Möglichkeit, das Plug-In (oder die Plug-Ins, wenn es sich um mehrere Plug-Ins innerhalb eines Features handelt) über einen Update-Mechanismus zu aktualisieren. Für diesen Update-Mechanismus wird ein Uniform Resource Locator (URL) angegeben. Diese Adresse benennt eine Updateseite, über die man das Plug-In beziehen oder aktualisieren kann. Jedes Plug-In kann sogenannte Fragmente (Fragments) enthalten. Sie erlauben das Aufteilen eines Plug-Ins in seine Kernfunktionalität und in ergänzende Komponenten wie etwa Sprachpakete oder betriebssystemabhängige Teile. Plug-Ins und Fragmente lassen sich getrennt voneinander entwickeln, ausliefern und installieren. Fragmente enthalten wie Plug-Ins eine Manifestdatei, die fragment.xml genannt wird. Dort wird die Abhängigkeit des Fragmentes zum Plug-In beschrieben. Während Plug-Ins ohne ein zugehöriges Fragment auskommen können, sind Fragmente ohne das zugehörige Plug-In nicht lauf- 13

32 2.1. Eclipse Kapitel 2. Grundlagen fähig. Nach der Installation eines Fragmentes geht dieses völlig im zugehörigen Plug-In auf, da es zum Namensraum des Plug-Ins gehört. Möchte man beispielsweise ein Plug-In in mehreren Sprachen anbieten, können die sprachabhängigen Teile durch ein Fragment realisiert werden. Diese Sprachpakete können dann später in das Plug-In integriert werden, ohne dass das eigentliche Plug-In geändert werden muss. So ist es möglich, dasselbe Plug-In durch unterschiedliche Fragmente für unterschiedliche Sprachen anzubieten Das Standard Widget Toolkit Das Standard Widget Toolkit, im folgenden SWT genannt, stellt eine Bibliothek für die Implementierung von Widgets und anderen Graphikkomponenten in Java zur Verfügung und ist Bestandteil von Eclipse. Ein Widget ist innerhalb von SWT ein abstraktes Objekt, das alle Arten von graphischen Objekten repräsentieren kann. Die Klasse Widget bildet in der Vererbungshierarchie die Oberklasse über alle in SWT verfügbaren graphischen Elemente. Das SWT enthält über 40 Widgets. Dazu gehören beispielsweise Buttons, Fortschrittsanzeiger, Tabellen und weitere Komponenten. SWT bietet auch die Möglichkeit, eigene Widgets zu erstellen wobei man bestehende Elemente nutzen kann. Eclipse nutzt das SWT zur Darstellung aller graphischen Objekte innerhalb der Workbench. Deshalb müssen alle Plug-Ins das SWT nutzen, wenn sie in Eclipse integriert werden sollen und auf das User Interface (UI) von Eclipse zugreifen wollen. Das SWT entspricht den AWT 1 /Swing Komponenten in Java, hat aber einen entscheidenden Vorteil gegenüber AWT und Swing: AWT gilt als zu langsam, zu fehleranfällig, zu ressourcenverbrauchend und zu eingeschränkt, was das Portieren auf andere Plattformen betrifft. Auch Swing gilt als zu langsam. Daher war der Wunsch nach einer effizienten und portierbaren Grafik-Bibliothek groß. Nach [Riv03] bietet SWT eine gute Performance, gute Portierungsmöglichkeiten, eine gute Grundlage zur Entwicklung robuster GUI-Oberflächen und eine effiziente Integration in native Window-Systeme. Dabei entspricht das Ansprechverhalten der SWT-Komponenten dem Verhalten nativer (in C/C++ geschriebener) Anwendungen. Dies erreicht SWT gemäß [Dau05] durch die nahtlose Einbettung der Applikation in die jeweilige Laufzeitumgebung. Die SWT-Komponenten stellen einen Adapter für die Dienste der Laufzeitplattform dar, die für die Erzeugung der graphischen Elemente verantwortlich sind. Dadurch wird ein einheitliches Aussehen der Anwendung erreicht, auch wenn diese auf unterschiedlichen Systemen läuft. 1 Abstract Window Toolkit 14

33 Kapitel 2. Grundlagen 2.1. Eclipse Das SWT nutzt das Java Native Interface (JNI). Durch JNI ist SWT in der Lage, direkt auf die API der Programmiersprache C zuzugreifen. Dadurch bietet SWT eine strikte eins-zueins Abbildung von SWT Objekten auf die zugehörigen Betriebssystemaufrufe, was zur Robustheit der SWT Objekte beiträgt. Für den Fall, dass kein passendes Widget auf dem aktuellen Betriebssystem zur Verfügung steht, emuliert SWT ein Passendes Die Test and Performance Tools Platform Die Test and Performance Tools Plattform, kurz TPTP, ist eines der Top Level Projekte von Eclipse und war früher unter dem Namen Hyades bekannt. TPTP bietet die Möglichkeit, den gesamten Lebenszyklus einer Anwendung zu begleiten. TPTP enthält Werkzeuge zum Testen, für die Ablaufprotokollierung, Auswertung und das Monitoring von Anwendungen, beginnend mit den ersten Entwicklungsschritten bis hin zur produktreifen Anwendung. Dabei ermöglicht TPTP das einfache Erweitern dieser Funktionalität um eigene Werkzeuge. Im Rahmen dieser Diplomarbeit wird TPTP in der Vision 4.1 genutzt. Die Version 4.2 ist zum Zeitpunkt der Abfassung dieser Diplomarbeit neu freigegeben worden. Die folgenden Erklärungen beziehen sich auf die Version 4.1. TPTP besteht aus insgesamt 4 Unterprojekten: TPTP Platform Dieses Projekt bildet die Grundlage für die folgenden TPTP-Projekte. Es beinhaltet neben weiteren Komponenten, die Infrastruktur, die Datenmodelle und die Kommunikationskontrolle, auf die die Komponenten der anderen Projekte zugreifen können. Monitoring Tools Dieses Projekt beinhaltet ein Framework, das es ermöglicht, Anwendungen oder Systeme zu überwachen (Monitoring) und Protokollierungsdaten (Logging-Daten) aus unterschiedlichen Anwendungen und Systemen auszuwerten. Dafür enthält es Referenzimplementierungen, die beispielsweise eine CPU-Überwachung und eine Speicherüberwachung realisieren. Testing Tools Dieses Projekt beinhaltet ein Framework, das es ermöglicht, Testwerkzeuge zu entwickeln, um so die Funktionalität von TPTP zu erweitern. Außerdem beinhaltet es unterschiedliche Testwerkzeuge für das Testen von Anwendungen. Dazu gehört beispielsweise die Möglichkeit, auf JUnit basierende Testklassen für die zu testende Anwendung, generieren zu können. 15