Vergleich mit der ARM API

   In der folgenden Aufzählung wird die vorgestellte Architektur der ARM API (vgl. Abschnitt ) gegenübergestellt, die im Bereich der Anwendungsinstrumentierung aktuell den größten Verbreitungsgrad besitzt. Somit werden die wesentlichen Weiterentwicklungen der vorgeschlagenen Lösung nochmals herausgestellt:

• Methodik für die Instrumentierung

  Die ARM API liefert lediglich eine Schnittstelle, die vom Anwendungsentwickler aufgerufen werden kann. Sie gibt keinerlei Methodik an, wie bei der Erstellung von Anwendungen vorzugehen ist, um instrumentierte Anwendungen zu erhalten. Insbesondere die Identifikation der relevanten Meßpunkte muß vom Anwendungsentwickler ohne jegliche Vorgaben erfolgen.

  Im Gegensatz dazu werden in der vorliegenden Arbeit Methodiken angegeben, die sowohl Baustein- als auch Anwendungsentwickler in der Erstellung instrumentierter Anwendungen wesentlich unterstützen. Bei Anwendung dieser Methodiken kann die Identifikation der relevanten Meßpunkte durch den Entwickler mit äußerst geringem Aufwand erfolgen.

• Automatisierung und Werkzeugunterstützung

  Im Rahmen der ARM API ist keinerlei Automatisierung oder Werkzeugunterstützung vorgesehen. Ein Entwickler muß die jeweiligen Managementanweisungen vollständig manuell in den erstellten Code einbringen.

  Die vorgeschlagene Lösung ermöglicht es jedoch, große Teile der Managementinstrumentierung vollständig automatisiert zu erbringen. Der nicht zu vermeidende Rest an manuellem Instrumentierungsaufwand wurde vollständig vom Anwendungs- auf den Bausteinentwickler übertragen, was zu einer weiteren Verringerung des Aufwands durch Mehrfachnutzung der instrumentierten Bausteine führt. Für den Anwendungsentwickler verbleibt lediglich die Konfiguration der instrumentierten Bausteine mit Hilfe grafischer Entwicklungsumgebungen.

• Korrelation von Subtransaktionen

  Ein wesentlicher Nachteil der ARM API ist die aufwendige Korrelation von Subtransaktionen. Diese erfolgt durch Generierung eines eindeutigen Identifikators, der als Parameter durch die zu überwachenden Anwendung geschleust werden muß. Dies erschwert neben der nachträglichen Instrumentierung von Anwendungen insbesondere auch die Instrumentierung bausteinbasierter Anwendungen erheblich, da es die Anpassung der Schnittstellen aller Bausteine erfordern würde.

  Im vorliegenden Ansatz wird die Korrelation der Subtransaktionen mit Hilfe der darunterliegenden Kontrollflüsse automatisch und für den Entwickler vollständig transparent erreicht. Dies stellt eine wesentliche Erleichterung für den Anwendungsentwickler - insbesondere im Falle der Erstellung bausteinbasierter Anwendungen - dar. Einzig bei Verwendung aktiver Bausteine muß eine ähnliche Technik wie bei Verwendung der ARM API eingesetzt werden. Hier muß der generierte Identifikator allerdings nicht über Bausteingrenzen propagiert werden, sondern muß lediglich innerhalb des zu überwachenden aktiven Bausteins übergeben werden. Somit stellt auch dies keine wesentliche Einschränkung dar.