Integriertes Performance-Monitoring von SOA-Anwendungen Electronic Communications of the EASST Volume 17 (2009) Workshops der Wissenschaftlichen Konferenz Kommunikation in Verteilten Systemen 2009 (WowKiVS 2009) Integriertes Performance-Monitoring von SOA-Anwendungen Markus Schmid, Jan Schäfer, Reinhold Kröger 12 pages Guest Editors: M. Wagner, D. Hogrefe, K. Geihs, K. David Managing Editors: Tiziana Margaria, Julia Padberg, Gabriele Taentzer ECEASST Home Page: http://www.easst.org/eceasst/ ISSN 1863-2122 http://www.easst.org/eceasst/ ECEASST Integriertes Performance-Monitoring von SOA-Anwendungen Markus Schmid, Jan Schäfer, Reinhold Kröger Fachhochschule Wiesbaden, Labor für Verteilte Systeme Kurt-Schumacher-Ring 18, 65197 Wiesbaden {schmid|jan.schaefer|kroeger}@informatik.fh-wiesbaden.de http://wwwvs.informatik.fh-wiesbaden.de Abstract: Der Beitrag stellt einen Ansatz zur Integration von Performance-Mo- nitoring-Aspekten in serviceorientierte Architekturen (SOAs) vor. Der Fokus liegt hierbei auf der konsistenten Instrumentierung bereits existierender SOA-Dienste. Hierfür wird ein im Rahmen des Projekts Performance Management of Enterprise Applications (PerManEntA)1 entwickeltes Werkzeug vorgestellt, das eine modellba- sierte Instrumentierungsunterstützung mit Hilfe grafischer Marker vorsieht. Der An- satz ermöglicht die Verwendung einheitlicher Monitoringschnittstellen und -funk- tionalität für alle in einer SOA kooperierenden Dienste und die konsistente Instru- mentierung mit Hilfe teilautomatisierter, werkzeuggestützter Instrumentierung und Quellcodegenerierung. Im Ausblick werden Möglichkeiten zur Integration mit un- terschiedlichen Ansätzen für das Service Level Management im SOA-Kontext auf- gezeigt. Keywords: Performance Monitoring, Management, Instrumentierung, ARM, SCA, SLM, SOA 1 Einleitung Die Realisierung von Geschäftsanwendungen mit Hilfe einer serviceorientierten Architektur (SOA) bietet durch die implementierungsunabhängige Spezifikation von Dienstschnittstellen und die Möglichkeit der Choreografie von Diensten zu Geschäftsprozessen viele Vorteile für den Betreiber. Allgemein wird die Einführung von SOA-basierten Anwendungen mit der daraus resultierenden Flexibilität und Skalierbarkeit der IT-Infrastruktur begründet [HHV06, HK04]. Betrachtet man allerdings die technische Architektur einer SOA-Anwendung als Ganzes, kann man im Vergleich zu traditionellen Anwendungsserver-basierten Multi-Tier-Anwendungen eine deutliche Komplexitätszunahme feststellen. In komplexen, geschäftskritischen Umgebungen ist ein einheitliches Performance-Monitoring aller Geschäftsprozesse und damit der beteiligten Softwarekomponenten notwendig, um eine zuverlässige Performance-Sicht der Gesamtanwendung bereitzustellen. Neben der eigentlichen Geschäftsfunktionalität muss jeder geschäftskritische SOA-Dienst daher auch eine Schnittstelle für Monitoring-Informationen zur Verfügung stellen. Gleichzeitig kann nur ein konsistentes Mo- nitoring die notwendige Grundlage zur Realisierung eines effektiven Service Level Managements (SLM) einzelner Dienste samt unterlagerter Infrastruktur bilden. 1 Projekt gefördert durch das BMB+F, Förderkennzeichen 1706X07 1 / 12 Volume 17 (2009) Integriertes Performance-Monitoring von SOA-Anwendungen Idealerweise werden Schnittstellen und die dazugehörige Instrumentierung für das Performan- ce-Monitoring zur Laufzeit bereits während des Entwurfs der einzelnen Dienste vorgesehen und als integrale Bestandteile des Software-Designs betrachtet. Häufig werden jedoch existierende Anwendungen als Dienste in eine SOA-Infrastruktur integriert, sodass auch für bestehende Soft- ware-Komponenten ein Weg zur nachträglichen Integration geeigneter Monitoring-Schnittstellen aufgezeigt werden muss. Eine fehlerfreie, konsistente Instrumentierung komplexer Anwendun- gen ist jedoch kein einfaches Unterfangen, da Instrumentierungscode i.d.R. an unterschiedlichs- ten Stellen ergänzt werden muss und Anwendungsentwickler in der Regel wenig Erfahrung mit entsprechenden APIs besitzen. Vor diesem Hintergrund stellt dieser Beitrag einen Ansatz zur IDE-gestützten Integration von Performance-Monitoring-Aspekten in existierende SOA-Dienste vor, der die grafische Auszeich- nung von relevanten Messpunkten im Quellcode einer Anwendung ermöglicht und so eine feh- lerfreie und konsistente Instrumentierung sicherstellt. Er lässt sich mit einem parallel von uns entwickelten Ansatz zur modellgetriebenen Instrumentierung neuer Dienste (vgl. [SSK08]) zu einer einheitlichen Monitoring-Umgebung für SOA-Dienste verbinden. Diese Monitoring-Um- gebung bildet die dann Grundlage für ein Performance-Monitoring auf Ebene von SOA-Anwen- dungen, welche als Komposition unterschiedlicher Dienste aufgefasst werden können. Gleich- zeitig können die durch die Instrumentierung gewonnenen Daten zur Überwachung und zum IT-Management der Implementierung einzelner Dienste verwendet werden. In Abschnitt 2 wird zunächst auf die Service Component Architecture, eine Spezifikation zur Strukturierung von SOA-Anwendungen eingegangen, Abschnitt 3 stellt Ansätze zur Quellcode- Instrumentierung vor. Die Abschnitte 5 und 6 beschreiben das zugrundeliegende Instrumentie- rungsmodell und den Ansatz zur IDE-gestützten Instrumentierung von SOA-Diensten. Der Bei- trag schließt mit einer Zusammenfassung und einem Ausblick auf Integrationsmöglichkeiten mit bestehenden SOA-Managementansätzen. 2 Service Component Architecture Eine relativ neue Spezifikation zur Beschreibung statischer Abhängigkeiten zwischen Kompo- nenten innerhalb einer SOA ist die Service Component Architecture (SCA). SCA hat zum Ziel, eine einheitliche Sicht auf SOA-Komponenten bereitzustellen und ihr Zusammenspiel inner- halb der Architektur strukturiert zu modellieren. Die derzeit vorliegende Version 1.0 der SCA- Spezifikation wurde von der Open SOA Collaboration2, einem Zusammenschluss mehrerer im SOA-Umfeld aktiver Unternehmen (u.a. IBM, Sun, Oracle, SAP und BEA) entwickelt. Der wei- tere Standardisierungsprozess ist in der Zwischenzeit an OASIS übergeben worden. SCA definiert eine Komponente (SCA Component) als ein Element mit beliebig vielen Schnitt- stellen (Services) und Abhängigkeiten (References). Ein Service kann durch andere SCA Com- ponents referenziert werden, was dann als Binding bezeichnet wird. Des Weiteren definiert SCA noch Properties, die zur Laufzeit von einer Komponente verwendet werden können. SCA erlaubt die Gruppierung mehrerer SCA Components mitsamt ihrer Bindings zu einem SCA Composite, das sich nach außen wiederum als eine SCA Component darstellt und wie diese über Services, Properties und References verfügt. 2 Details unter http://www.osoa.org Proc. WowKiVS 2009 2 / 12 http://www.osoa.org ECEASST 3 APIs zur Quellcode-Instrumentierung Zur Quellcodeinstrumentierung von Anwendungen stehen zahlreiche Technologien zur Verfü- gung. Neben klassischen Logging-Schnittstellen, wie z. B. dem in der Java-Welt verbreiteten log4j-API [Gü02], existiert speziell zur detaillierten Vermessung von Vorgängen in verteilten Anwendungen das von der Open Group spezifizierte Application Response Measurement (ARM) 4.0 API [Ope03]. ARM unterstützt die Vermes- Abbildung 1: ARM-Instrumentierung sung von mit Start- und Stopp- punkten ausgezeichneten Quellco- deabschnitten (Units of Work) in verteilten Anwendungen (z.B. zur Antwortzeitmessung). Diese Units of Work werden im ARM-Kontext als ARM-Transaktionen bezeichnet und können zusätzlich mit Kontext- Informationen angereichert wer- den (z.B. CPU-Last zum Mess- zeitpunkt). Des Weiteren unterstützt ARM die Verknüpfung verteilter Messungen durch die Verwendung von eindeutigen Tokens, sogenann- ten ARM-Korrelatoren, die nachgeordneten Messungen übergeben werden können. Damit las- sen sich zum Auswertungszeitpunkt detailliert Hierarchien von Einzelmessungen aufschlüsseln, die z.B. eine Aufruffolge über mehrere Komponenten hinweg nachverfolgbar machen. Für kriti- sche Anwendungsgebiete kann es erforderlich sein, einzelne Dienste und deren Implementierung detailliert zu überwachen (einschließlich der beteiligten Middleware-Plattformen und nachgela- gerten Systeme). Zur nahtlosen Integration stellen viele Middleware-Komponenten (z. B. IBM WebSphere, vgl. [Web06]) selbst ARM-Schnittstellen bereit, die dann mit eigenen Messungen verknüpft werden können. Abbildung 1 zeigt, auf welche Weise Zeitmessungen in einer ARM-instrumentierten Anwen- dung realisiert werden. Die im ARM-Stardard spezifizierten Start- und Stoppanweisungen im Quellcode der instrumentierten Anwendung resultieren in API-Aufrufen einer herstellerspezifi- schen ARM-Bibliothek. Diese führt die eigentlichen Zeitmessungen durch und leitet die gesam- melten Daten an einen zentralen ARM-Agenten weiter. Hier können dann Ergebnisse verteilter Messungen mithilfe der ARM-Korrelatoren verknüpft werden, sodass eine anwendungsübergrei- fende Auswertung erfolgen kann. Der ARM-Standard beschränkt sich auf die Spezifikation des ARM-APIs; eine Standardisierung von ARM-Agenten und Auswertungswerkzeugen ist nicht vorgesehen. Durch einfachen Tausch der verwendeten ARM-Bibliothek kann eine bestehende ARM-Instrumentierung in die Monitoring-Umgebung eines anderen Anbieters überführt werden, ohne dass Anpassungen am Quellcode vorgenommen werden müssen. Eine sogenannte Null-Bi- bliothek kann zur Anwendung hinzugebunden werden, wenn keine Auswertung von Messungen erwünscht ist. 3 / 12 Volume 17 (2009) Integriertes Performance-Monitoring von SOA-Anwendungen 4 Performance-Monitoring von SOA-Diensten 4.1 Überblick Abbildung 2 zeigt beispielhaft den typischen Aufbau einer SOA-Anwendung. Auf oberster Abstraktionsebene werden in einer SOA Workflows als technische Realisierung einzelner Ge- schäftsprozesse definiert, die bei ihrer Abarbeitung auf die Geschäftsschnittstellen unterschied- licher Dienste zugreifen. Diese sind in der Grafik hell gekennzeichnet. Neben der eigentlichen Geschäftsfunktionalität können SOA-Dienste auch weitere Funktionen bereitstellen, in der Ab- bildung erkennt man eine dunkel gekennzeichnete Schnittstelle zum Abruf von Performance- Kenngrößen. Außerhalb des SOA-Fokus befindet sich Abbildung 2: Monitoring und IT-Management in SOA-Anwendungen dabei die eigentliche Implementierung eines Dienstes. Hierbei kann es sich beispielswei- se um eine existierende Anwendung handeln, die zur SOA-Integration um eine standar- disierte Geschäftsschnittstelle erweitert wur- de. Häufig existieren in Firmen oder Abtei- lungen (in der Grafik als administrative Do- mänen bezeichnet) bereits individuelle Mo- nitoring- und Managementansätze zur Über- wachung solcher Anwendungen. Derartige Lösungen zeichnen sich aber typischerwei- se durch einen Mangel an Standardisierung aus und eignen sich deshalb nicht für die Be- reitstellung einheitlicher Performance-Infor- mationen über Dienst- und Domänengrenzen hinweg. Die in Abschnitt 3 vorgestellte ARM-Tech- nologie kann durch die Unterstützung für verteilte Messungen dazu beitragen, in einem solchen Umfeld wertvolle dienstübergeifende Performance-Daten zu liefern, die die Grundlage für ei- ne detaillierte Bewertung der Performance eines SOA Workflows bilden können. Im Vergleich zu Zeitmessungen innerhalb einer entsprechend modifizierten Workflow-Engine erlaubt der hier vorgestellte Ansatz deutlich feingranularere Messungen, die ggf. auch um implementierungsspe- zifische Informationen angereichert werden können. Gleichzeitig kann die ARM-Instrumentie- rung auch für das Performance-Monitoring im Rahmen des IT-Managements einer geschäftskri- tischen Dienst-Implementierung als Datenquelle dienen. 4.2 Einheitlicher Zugriff auf Performance-Daten Um die Ergebnisse einer ARM-Instrumentierung über Dienst-Grenzen hinweg nutzen zu kön- nen, muss eine einheitliche Schnittstelle zum Abrufen von Kenngrößen bereitgestellt werden, die die durch Performance-Instrumentierung erhobenen Kenngrößen mithilfe einer Monitoring- Komponente nach außen hin bereitstellt. Proc. WowKiVS 2009 4 / 12 ECEASST Da der ARM-Standard kein einheitliches API für das Auslesen der Kenngrößen spezifiziert, ist zur Realisierung der Monitoring-Komponente die Nutzung einer herstellerspezifischen Schnitt- stelle unumgänglich. In der praktischen Umsetzung des hier vorgestellten Ansatzes wurde die kommerzielle ARM-Implementierung der Firma tang-IT [tICG04] eingesetzt, für die eine Java- basierte Client-API zur Verfügung steht. Unter Nutzung dieser API konnte eine generische Mo- nitoring-Komponente entwickelt werden, die lediglich mit einer geeigneten Konfiguration zum Auslesen der erzeugten Messungen versehen werden muss. Aus SOA-Sicht koexistieren Geschäfts- und Abbildung 3: Integration von Geschäfts- und Monitoring-Schnittstelle Monitoring-Schnittstelle einer Dienstimplemen- tierung aber zunächst als unabhängige Kompo- nenten; die auf Implementierungsebene gegebe- ne Abhängigkeit wird nach außen nicht sicht- bar. Wie in Abschnitt 2 gezeigt, ist es mithil- fe von SCA möglich, die auf Implementierungs- ebene bestehende Abhängigkeit zwischen Moni- toring- und Geschäftskomponente in Form eines SCA Composites zu beschreiben. Hauptvorteil ei- ner SCA-basierten Kopplung von Geschäfts- und Monitoring-Funktionalität einer Komponente ist die Möglichkeit zur transparenten Integration der Monitoring-Funktionalität in bestehende Umge- bungen. Ein auf diese Weise instrumentierter Dienst kann von bestehenden Komponenten weiter- hin unverändert adressiert werden, da die Geschäftsschnittstelle zur Integration des Monitoring- Anteils nicht modifiziert werden muss. Trotzdem ist über diese Kopplung eine eindeutige Zuord- nung der neu erzeugten Monitoring-Schnittstelle zu einer Geschäftskomponente möglich. Abbildung 4: Beispiel: Gruppierung von Geschäfts- und Monitoring-Funktionalität 5 / 12 Volume 17 (2009) Integriertes Performance-Monitoring von SOA-Anwendungen Abbildung 4 zeigt als Beispiel die Gruppierung eines Web Services (Calculator) mit der dazu- gehörigen Monitoring-Schnittstelle, in dem die jeweiligen Komponenten als Java-Klassen refe- renziert werden. Durch den Ausdruck wird für die Geschäfts- und die Moni- toring-Funktionalität eine entsprechende Web-Service-Schnittstelle bereitgestellt. Somit können instrumentierte SOA-Dienste durch eine SCA-Laufzeitumgebung bereitgestellt werden. In den folgenden Abschnitten wird genauer auf unseren Ansatz für die Performance-Instru- mentierung bestehender SOA-Dienste (vgl. Abschnitte 5 und 6) eingegangen, die die Bereitstel- lung einer einheitlichen Instrumentierung und somit von Laufzeit-Performance-Kenngrößen für die hier skizzierte Schnittstelle zum Ziel hat. 5 Zugrundeliegendes Instrumentierungsmodell Als Grundlage für den in diesem Beitrag vorgestellten IDE- � � ����� ������ � � ���� � ��� �� ����� ���� � � � � ������ ��� ����� � ������ �� ���� Abbildung 5: Im Modell verwendete Basismuster gestützten Instrumentierungsansatz von SOA-Diensten wurde ei- ne Reihe abstrakter Instrumentierungsmuster entwickelt. Diese be- schreiben im Kontext von SOA-Diensten häufig auftretende Inter- aktionsmuster, deren Erfassung oder Vermessung zur Laufzeit von Interesse sein können. Instrumentierungsmuster bestehen aus Instrumentierungspunk- ten, die über Kanten miteinander verknüpft werden. Instrumentie- rungspunkte markieren dabei Stellen im Programmablauf, an denen z. B. eine Zeitmessung starten oder enden soll. Über die Zuordnung von Rollen zu einzelnen Punkten innerhalb eines Musters können diese Funktionen explizit ausgedrückt werden. Instrumentierungs- muster werden in Basismuster und Komplexe Muster unterteilt. Im Modell verwendete Basismuster sind die in Abbildung 5 dargestell- ten Muster Event, Trigger und Action. Ein Event entspricht einem unabhängigen Ereignis im Ab- � � � � � � ���� ��� � �� ��� � ��������� � �� ��� � ������ ����� �� Abbildung 6: Request / Respon- se-Muster lauf, das keine Auswirkung auf andere Punkte des Sys- tems hat. Für ein Event kann später z. B. eine Lognachricht im Quellcode generiert werden. Ein Trigger beschreibt ei- ne Beziehung zwischen zwei Ereignissen in unterschiedli- chen Komponenten, in der das erste Ereignis (Rolle Activator) durch sein Auftreten das zweite Ereignis (Listener) auslöst. Ein Trigger kann z. B. für die Vermessung einer Einwegnach- richt verwendet werden, bei der die Erfassung von Versende- und Empfangszeitpunkt relevant ist. Eine Action bezeichnet einen durch einen Ein- und einen Austrittspunkt (Start und Stopp) begrenzten Bearbeitungsschritt innerhalb einer Kom- ponente. Eine Action kann z. B. für die Messung der Ausfüh- rungsdauer eines Algorithmus oder eines Aufrufs einer ent- fernten Komponente verwendet werden. Proc. WowKiVS 2009 6 / 12 ECEASST Um anspruchsvollere Instrumentierungsszenarien (z. B. Client- und Server-seitige Vermes- sung eines RPC-artigen Aufrufs) abzubilden, können die beschriebenen Basismuster zu komple- xen Mustern zusammengefügt werden. Ein Beispiel hierfür ist das in Abbildung 6 dargestellte Request/Response-Muster, das zur Auszeichnung der Verknüpfung von Zeitmessungen in den Komponenten A und B genutzt werden kann. In diesem Muster werden zwei Trigger und zwei Actions miteinander kombiniert, um eine typische Client/Server-Interaktion abzubilden. Mithilfe der hier beschriebenen Instrumentierungsmuster ist es möglich, gängige Performan- ce-Instrumentierungsszenarien auf Modellebene – und damit zunächst unabhängig von einer konkreten Instrumentierungstechnologie oder einem bestimmten API – zu definieren. Bei der IDE-gestützten Instrumentierung von SOA-Diensten kann sich der Entwickler damit auf einer hohen Abstraktionsebene bewegen, die – durch die Möglichkeit der dienstübergreife- nenden grafischen Darstellung der Instrumentierungspattern – einen guten Überblick über die erfolgte Instrumentierung gewährleistet. 6 Das IDE-basierte Instrumentierungswerkzeug Im Rahmen des Projekts Performance Management of Enterprise Applications3 (PerManEntA) wurde an der FH Wiesbaden ein Eclipse-basiertes Werkzeug zur Performance-Instrumentierung verteilter Anwendungen entwickelt, das auf dem in Abschnitt 5 beschriebenen Instrumentie- rungsmodell aufsetzt. Das Werkzeug erweitert die Eclipse-Entwicklungsumgebung um eine Rei- he von Plugins, zur grafischen Instrumentierung von Anwendungen. 6.1 Vorgehensweise bei der Instrumentierung Vergleichbar mit Debugger-Breakpoints kön- Abbildung 7: Bildschirmausschnitt des In- strumentierungswerkzeugs nen relevante Quellcodeabschnitte zur Performan- ce-Instrumentierung markiert werden. Für SOA- Dienste sind hier vorrangig Operationen von In- teresse, die über die externe Dienstschnittstelle aufgerufen werden können. Zusätzlich können je- doch auf diese Weise feingranulare Messungen innerhalb der Implementierung spezifiziert wer- den, um z. B. den Anteil von Datenbankabfragen oder einzelner Algorithmen an der Gesamtausfüh- rungsdauer einer Operation bestimmen zu können. Auf Knopfdruck kann für die mit Instrumentie- rungspunkten und -Patterns ausgezeichneten Stel- len dann Instrumentierungscode generiert werden oder zuvor erzeugter Code wieder entfernt wer- den. Der Instrumentierungscode wird im Rahmen des Generierungsprozesses direkt in die zu instru- mentierende Datei eingefügt. Das Werkzeug er- 3 Näheres unter http://wwwvs.informatik.fh-wiesbaden.de/projekte/permanenta.html 7 / 12 Volume 17 (2009) http://wwwvs.informatik.fh-wiesbaden.de/projekte/permanenta.html Integriertes Performance-Monitoring von SOA-Anwendungen laubt das Gruppieren von Instrumentierungsmustern zu Aspekten, die gemeinsam aktiviert oder deaktiviert werken können, sodass zur Laufzeit nur relevante Teile der vorgenommenen Instru- mentierung aktiv gehalten werden müssen. Dadurch lässt sich zum Einen der durch die Instru- mentierung verursachte Laufzeit-Overhead minimal halten, zum Anderen können beispielsweise bei der Fehleranalyse oder zum Systemtest durch Zuschalten zusätzlicher Aspekte zeitweise de- tailliertere Messungen erfolgen. Abbildung 7 zeigt einen Bildausschnitt des Instrumentierungswerkzeugs, in dem eine Instru- mentierungsmusteransicht (1), grafische Instrumentierungspunkte (2) und die Eigenschaftenan- sicht eines einzelnen Instrumentierungspunktes zu sehen sind. Nachdem die Performance-Instrumentierung eines SOA-Dienstes wie beschrieben erfolgt ist, kann die Auswertung der Performance-Messungen mithilfe der in Abschnitt 4.2 beschriebenen generischen Monitoring-Komponente erfolgen, auf die aus der SOA über die bereitgestellte Mo- nitoring-Schnittstelle zugegriffen werden kann. Zum jetzigen Zeitpunkt ist das Werkzeug noch nicht in der Lage, zusätzlich zur Instrumen- tierung die zur Kopplung von Monitoring- und Geschäftsfunktionalität eines SOA-Dienstes not- wendige SCA-Beschreibung zu generieren. An dieser Stelle ist damit derzeit noch eine manuelle Ergänzung der Implementierung existierender SOA-Dienste notwendig. 6.2 Architektur des Instrumentierungswerkzeugs Die im Rahmen des PerManEntA-Projekts entwi- Abbildung 8: Architektur des Instru- mentierungswerkzeugs ckelte Implementierung unterstützt aktuell die Instru- mentierung von Java-Quellcode mithilfe von ARM und Log4J. Durch die modulare Architektur des Werkzeugs ist jedoch die Möglichkeit der Erweiterung auf andere Programmiersprachen und Instrumentierungs-APIs ge- geben. Zu diesem Zweck sind API-spezifische Teile in eigenen Eclipse-Plugins, den sogenannten Instrumen- tierungs-Backends, gekapselt. Abbildung 8 zeigt das Zusammenspiel der einzelnen Teile des Werkzeugs, die jeweils als einzelne Eclipse- Plugins realisiert sind. Zentrales Element der Architek- tur ist das Core-Plugin, das die Initialisierung des Ge- samtsystems übernimmt und das Zusammenspiel zwi- schen der Entwicklungsumgebung und den API-spezi- fischen Backends koordiniert. In der JDT-UI-Extension sind spezifische Erweiterungen der Eclipse Java Entwicklungsumge- bung (JDT) realisiert, hierzu zählen beispielsweise Funktionalität zur Manipulation des Editor- Buffers sowie zum Zugriff auf den durch JDT bereitgestellten Abstract Syntax Tree (AST) einer Java-Klasse. Das Common-Plugin realisiert von Instrumentierungs-API und Programmiersprache unabhän- gige Funktionalität; hierzu zählen beispielsweise Visualisierung und Manipulation der spezifi- zierten Instrumentierungsmuster sowie Funktionalität zum Anstoßen der Code-Generierung oder des Entfernens von Instrumentierungscode. Da nicht notwendigerweise jede Instrumentierungs- Proc. WowKiVS 2009 8 / 12 ECEASST technologie alle der in Abschnitt 5 diskutierten Patterns unterstützt, informieren die Backends das Common-Plugin über die von ihnen unterstützten Funktionen. Zur Code-Generierung wird durch den Core das vom Benutzer gewählte Backend aufgerufen. Die Instrumentierungsinformationen für einzelne Klassen werden durch ein Repository-Plugin gekapselt und im XML-Format als separate Datei im Eclipse-Workspace abgelegt. 6.3 Integration mit einem modellgetriebenen Instrumentierungsansatz Im Rahmen des Projekts wurde parallel ein modellgetriebener Ansatz zur Instrumentierung neu zu entwickelnder SOA-Dienste entwickelt. Hierbei wird eine grundlegende Instrumentierung der einzelnen Operationen eines auf UML-Ebene modellierten SOA-Dienstes automatisiert im Rah- men des MDA-Codegenerierungsprozesses vorgenommen. Die resultierende Instrumentierung arbeitet dabei mit der gleichen Monitoring-Komponente wie der oben vorgestellte Ansatz. Zu- sätzlich zur eigentlichen Codegenerierung erzeugt der MDA-Transformationsprozess ein XML- Repository, sodass eine nachträgliche Verfeinerung der Instrumentierung mit dem hier vorge- stellten Eclipse-basierten Instrumentierungswerkzeug möglich ist. Der MDA-basierte Instru- mentierungsansatz für neu zu entwickelnde SOA-Dienste ist detailliert in [SSK08] dargestellt. 6.4 Weitere Module Zur Unterstützung des lokalen IT-Managements von Dienst-Implementierungen wurden im Rah- men des Projekts weitere Module zur Auswertung der durch die Instrumentierung erhaltenen Performance-Informationen entwickelt. Wie die in Abschnitt 4.2 vorgestellte Monitoring-Kom- ponente operieren diese auf der durch den ARM-Agenten bereitgestellten Datenbestand und nut- zen damit ein herstellerspezifisches API. Zur Integration der Performance-Messwerte in existierende SLM-Systems wurde ein Modul zur Überwachung von Schwellenwerten entwickelt, mit deren Hilfe komplexe Constraints über Messpunkte und Instrumentierungspatterns spezifiziert werden können. Das Modul agiert gegen- über einer existierenden IT-Managementumgebung als SNMP-Agent und kann so im Bedarfsfall mittels SNMP-Traps über Schwellwertverletzungen informieren. Die Definition entsprechender Constraints und die Überwachung von Schwellwerten ist detailliert in [Tex08] beschrieben. 7 Verwandte Arbeiten Traditionell werden zur Vermeidung fehleranfälliger manueller Instrumentierung von Anwen- dungen Compiler-basierte Ansätze verfolgt; hierbei generiert ein Compiler z. B. zusätzlichen Instrumentierungscode für Funktionsaufrufe. Neuere Ansätze versuchen das Anwendungsver- halten indirekt über bereits existierende Sensorik zu bestimmen. Aguilera et al. [AMW+03] be- schreiben einen Black-Box-Ansatz zur Performance-Analyse verteilter Anwendungen auf Basis der Auswertung von Kommunikations-Traces und verzichten somit vollständig auf jegliche An- wendungsinstrumentierung. Der Ansatz beschäftigt sich intensiv mit der Rekonstruktion relevan- ter Aufrufgraphen aus der aufgezeichneten Kommunikation. Im Gegensatz zu unserem Instru- mentierungsansatz können Aufrufgraphen jedoch nur mit einer bestimmten Wahrscheinlichkeit 9 / 12 Volume 17 (2009) Integriertes Performance-Monitoring von SOA-Anwendungen und im Nachhinein ermittelt werden, weiterhin ist die Granularität des Performance-Monitorings auf Dienst-Interaktionen festgelegt – feingranulare Messungen sind somit nicht möglich. Pinpoint [CKF+02] ist ein System, das sich mit automatischer Problemerkennung in großen, dynamischen Internet-basierten Systemen beschäftigt. Pinpoint stellt eine Reihe instrumentier- ter Middleware-Komponenten bereit, mit deren Hilfe ein Request bei seinem Lauf durch das System beobachtet werden kann. Pinpoint erlaubt allerdings keine weitere Verfeinerung durch zusätzliche Messungen, das System verwendet einen nicht-standardisierten Messansatz und ist nicht offen für Erweiterungen. Durch die Verwendung einer einheitlichen Monitoring-Schnittstelle können mit dem in diesem Beitrag vorgestellten Ansatz instrumentierte Dienste prinzipiell in Architekturen integriert wer- den, die alternative Dienste innerhalb eines Workflows basierend auf ihrer Dienstgüte auswählen. Ein Beispiel für einen solchen Ansatz ist WSQoSX [BGR+05]. Diese Architektur unterstützt ein QoS-abhängiges Binding von Diensten, wobei unter anderem die Antwortzeit eines Dienstes als Auswahlkriterium herangezogen wird. WSQoSX wählt dabei unter mehreren Diensten mit äqui- valenter Funktionalität diejenigen aus, mit deren Beteiligung an die Architektur gestellte SLAs erfüllt werden können. In [MDGA08] wird eine modellbasierte Monitoring-Infrastruktur für Composite-Services vor- gestellt, die mit existierenden Managementumgebungen integriert werden kann. Im Unterschied zum hier präsentierten Ansatz konzentrieren sich die Autoren bei der Erfassung von Performan- ce-Kenngrößen auf die Ebene des Workflow-Managementsystems, wodurch es möglich ist, eine Auswahl der zu vermessenden Operationen aus Geschäftssicht zu treffen. Durch die Beschrän- kung auf die Workflow-Ebene erfolgen Messungen allerdings in deutlich geringerer Granularität, Performance- oder Durchsatzmessungen können bei nachrichtenbasierter (Einweg-)Kommuni- kation nicht durchgeführt werden. Der hier vorgestellte Ansatz kann aber problemlos mit der in [MDGA08] diskutierten Architektur kombiniert werden, so dass sich die Vorteile beider Ansätze nutzen lassen. 8 Zusammenfassung und Ausblick Das in diesem Beitrag geschilderte Vorgehen zur Integration von Performance-Monitoring-Funk- tionalität in den Designprozess von SOA-Diensten ist ein erster Schritt hin zur modellgestützten Integration weiterer Management-Funktionalität für derartige Komponenten. Mithilfe des IDE- basierten Instrumentierungswerkzeugs kann eine Performance-Instrumentierung bereits existie- render Dienste erfolgen oder eine bereits vorhandene Instrumentierung weiter verfeinert werden. Gleichzeitig bildet der Ansatz die Grundlage für ein integriertes, dienstübergreifendes Per- formance-Monitoring in SOA-Anwendungen. Um Abhängigkeiten zwischen Messungen über Dienstegrenzen hinweg verfolgen zu können, müssen ARM-Korrelatoren beim Aufruf eines Dienstes an diesen übergeben werden. [STTK07] und [Sch06] beschreiben die prinzipielle Vorgehensweise zur transparenten Übertragung von ARM-Korrelatoren zwischen unterschied- lichen Middleware-Komponenten. Zur Realisierung einer integrierten Performance-Monitoring für SOA-Anwendungen soll diese Vorgehensweise mit dem in dieser Arbeit vorgestellten Ansatz zusammengeführt werden. Durch Erweiterung des bestehenden Instrumentierungsmodells erscheint auch die Integra- Proc. WowKiVS 2009 10 / 12 ECEASST tion einer universelleren Dienst-Management-Funktionalität möglich, wie sie beispielsweise in [SK08] für einzelne SOA-Dienste und Workflows vorgeschlagen wird. [SK08] beschreibt einen Ansatz zum dezentralen Performance-Management in SOAs, bei dem auf Workflow- und Dienstebene angesiedelte Management-Komponenten zur Durchsetzung Performance-bezoge- ner Dienstgüteanforderungen kooperieren. Der hier vorgestellte Ansatz zur Performance-Instru- mentierung kann dabei als Datenquelle zur Dienstüberwachung eingesetzt werden. Hierbei wäre jedoch eine engere Verknüpfung von Modell und generiertem Quellcode durch bidirektionalen Abgleich von Änderungen wünschenswert, da dies die Flexibilität bei der Entwicklung von An- wendungen erhöhen würde. Literatur [AMW+03] M. K. Aguilera, J. C. Mogul, J. L. Wiener, P. Reynolds, A. Muthitacharoen. Perfor- mance Debugging for Distributed Systems of Black Boxes. In Proc. of ACM Symp. on Operating Systems Principles (SOSP’03). 2003. [BGR+05] R. Berbner, T. Grollius, N. Repp, O. Heckmann, E. Ortner, R. Steinmetz. An ap- proach for the Management of Service-oriented Architecture (SoA) based Appli- cation Systems. In Enterprise Modelling and Information Systems Architectures, Proceedings, 2005. Pp. 208–221. Oktober 2005. [CKF+02] M. Y. Chen, E. Kiciman, E. Fratkin, A. Fox, E. Brewer. Pinpoint: Problem Deter- mination in Large, Dynamic Internet Services. In Proceedings of the Int. Conf. on Dependable Systems and Networks (DSN’02). 2002. [Gü02] C. Gülcü. Log4j Manual. 2002. http://logging.apache.org/log4j/docs/manual.html. [HHV06] A. Hess, B. Humm, M. Voß. Regeln für serviceorientierte Architekturen hoher Qua- lität. Informatik Spektrum 6, 2006. [HK04] T. Heimann, R. Kappes. Mit SOA aus der Kostenfalle. IT Management, November 2004. [tICG04] tang IT Consulting GmbH. tang-IT ARM. 2004. http://www.tang-IT.com/arm/. [MDGA08] C. Momm, T. Detsch, M. Gebhart, S. Abeck. Model-Driven Development of Mo- nitord Web Service Compositions. In Harroud et al. (eds.), Proceedings of the 15th Annual Workshop of the HP Software University Association. Pp. 93–104. Juni 2008. [Ope03] The Open Group. Application Response Measurement. 4.0 edition, Oktober 2003. http://www.opengroup.org/arm. [Sch06] J. Schaefer. An Approach for Fine-Grained Web Service Performance Monitoring. In Eliassen and Montresor (eds.), Distributed Applications and Interoperable Sys- tems: 6th IFIP WG 6.1 International Conference, DAIS 2006, Bologna, Italy, June 14-16, 2006, Proceedings. Pp. 169–180. Springer Verlag, June 2006. 11 / 12 Volume 17 (2009) http://logging.apache.org/log4j/docs/manual.html http://www.tang-IT.com/arm/ http://www.opengroup.org/arm Integriertes Performance-Monitoring von SOA-Anwendungen [SK08] M. Schmid, R. Kroeger. Decentralised QoS-Management in Service Oriented Ar- chitectures. In Meier and Terzis (eds.), Distributed Applications and Interoperable Systems: 8th IFIP WG 6.1 International Conference, DAIS 2008, Oslo, Norway, June 4-6, 2008. Pp. 44–57. Springer Verlag, Juni 2008. [SSK08] M. Schmid, J. Schaefer, R. Kroeger. Ein MDSD-Ansatz zum QoS-Monitoring von Diensten in Service-orientierten Architekturen. PIK - Praxis der Informationsver- arbeitung und Kommunikation 31 / 4, 2008. [STTK07] M. Schmid, M. Thoss, T. Termin, R. Kroeger. A Generic Application-Oriented Per- formance Instrumentation for Multi-Tier Environments. In 10th IFIP/IEEE Inter- national Symposium on Integrated Network Management (IM2007). Pp. 304–313. IEEE, Mai 2007. [Tex08] A. Textor. Monitoring unternehmenskritischer Anwendungen unter Verwendung modellbasierter Performance Constraints. B.Sc. Thesis, FH Wiesbaden, FB Design Informatik Medien, September 2008. [Web06] WebSphere Application Server Manual – Getting performance data from request metrics. 2006. http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere. base.doc/info/aes/ae/tprf_rqenable.html Proc. WowKiVS 2009 12 / 12 http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.b ase.doc/info/aes/ae/tprf_rqenable.html http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.b ase.doc/info/aes/ae/tprf_rqenable.html Einleitung Service Component Architecture APIs zur Quellcode-Instrumentierung Performance-Monitoring von SOA-Diensten Überblick Einheitlicher Zugriff auf Performance-Daten Zugrundeliegendes Instrumentierungsmodell Das IDE-basierte Instrumentierungswerkzeug Vorgehensweise bei der Instrumentierung Architektur des Instrumentierungswerkzeugs Integration mit einem modellgetriebenen Instrumentierungsansatz Weitere Module Verwandte Arbeiten Zusammenfassung und Ausblick