Um dem Diensterbringer die Möglichkeit zu geben, die Ursache fehlerhafter oder (zu) langsamer BTA s zu bestimmen, ist es erforderlich, diese in Subtransaktion en aufzuteilen. Die Subtransaktionen müssen dann ihren jeweiligen BTA s zugeordnet werden. Dies wird in Abbildung nochmals anhand des Beispiels einer einfachen ARM-Instrumentierung eines Webbrowsers verdeutlicht [#!hare00!#]. Transaktion A stellt die gesamte BTA des Herunterladens einer Webseite dar. Diese wird weiter in zwei Subtransaktionen B und C unterteilt, die die Auflösung der IP-Adresse des Webservers bei einem DNS Server bzw. den tatsächlichen Download der Seite vom Webserver umfassen. Somit ist es möglich, bei Auftreten eines Problems die Ursache schnell einzugrenzen und die Fehlerbehebung zu beschleunigen.
Wie in Abschnitt bereits dargestellt, ist es im Falle bausteinbasierter Anwendungen sinnvoll und erforderlich, die von den jeweiligen Bausteinen ausgeführten Operationen als Subtransaktionen zu betrachten und zu überwachen. Somit ergeben sich die erforderlichen Meßpunkte folgendermaßen: Die Entwicklungsumgebung muß jeweils unmittelbar vor dem Aufruf eines Bausteins und unmittelbar nach Beendigung der Bearbeitung eines Aufrufs durch einen Baustein einen entsprechenden Meßpunkt in die Anwendungslogik einfügen.
Im Fall synchroner Aufrufe von Bausteinen ist dies vollständig automatisierbar. Jeweils unmittelbar vor dem Aufruf und unmittelbar nach dem Aufruf eines Bausteins muß ein Meßpunkt in den generierten Code eingefügt werden (vgl. Abbildung ). Die erfolgreiche bzw. nicht erfolgreiche Bearbeitung des Aufrufes kann von der Anwendungslogik durch das Abfangen evtl. auftretender Exceptions erkannt werden. Tritt eine Exception auf, so ist von einer nicht ordnungsgemäßen Bearbeitung des Aufrufes auszugehen. Um den Programmablauf nicht zu stören muß die Exception anschließend an den ursprünglich aufrufenden Baustein übergeben werden.
[Identifikation der Meßpunktes für
Subtransaktionen]Identifikation der Meßpunktes für
Subtransaktionen
[r]