Analyse zur Erweiterungsmöglichkeit der Axis Umgebung

Um den Anforderungen gerecht zu werden, bedarf es einer genauen Analyse der beiden Axis Implementierungen.
Wie man in den Grundlagenkapiteln über die Axis Architektur erfahren konnte, ist diese sehr flexibel bezüglich der Änderbarkeit und Erweiterbarkeit der Komponenten. Die komplette SOAP Nachricht durchläuft sowohl auf Client- als auch auf Serverseite eine Reihe von Handlern. Axis bietet die Möglichkeit, eigene Handler zu entwickeln. Mit Hilfe des Deployment Deskriptors, jeweils für Client und Server, hat man dann die Möglichkeit, die eigenen Handler an den gewünschten Stellen bekannt zu machen, sowohl im request flow als auch im Response Flow. Desweiteren ist es möglich, über den Deployment Deskriptor dem Handler Parameter in Form von Name-Value Paaren mit zu übergeben. Aufgrund der Tatsache, dass dieses Konzept sowohl bei der C++ Implementierung als auch bei der Java Implementierung vorhanden ist, eignet es sich hervorragend als Lösung für eine generische Instrumentierung. Erste Tests mit dieser Lösung zeigen jedoch das Problem, dass man Variablen und/oder Werte die man auf dem request flow erzeugt hat im response flow nicht mehr verfügbar sind. Eine ARM Transaktion, die auf dem request flow gestartet wird, soll im response flow wieder gestoppt werden. Aufgrund der Tatsache, dass man im response flow das C++ Transaction Handle und in Java das Transaction Objekt nicht mehr zur Verfügung hat, kann man die Messung nicht korrekt durchführen. Da man im Handler feststellen kann, ob man sich im request flow oder im response flow befindet, besteht der erste Ansatz darin, ein und denselben Handler zu benutzen und diesem statische Variablen hinzuzufügen. Dies hat allerdings den Nachteil dass man sowohl im Client als auch im Server nur einen Handler dieser Klasse verfügbar machen kann, da die statischen Variablen natürlich nur einmal belegt werden dürfen.
Abbildung 3.1: Problem mehrere Handler mit einer static Variable
Image static_problem_kleiner

In der Abbildung sieht man, dass ein Handler jeweils zweimal im request flow und zwei mal im response flow verfügbar gemacht wurde. Der jeweils oben dargestellte Handler soll die ARM Transaktion starten, und der jeweils dazugehörige untere Handler soll die Transaktion stoppen. Nutzt man nun die Lösung mit den statischen Variablen, kommt es zu folgendem Effekt:

  1. Handler a setzt eine Variable für seinen Nachbar Handler d im response flow
  2. Handler b setzt die gleiche Variable wie Handler a für seinen Nachbar Handler c
  3. Handler c kann auf die Variablen seines Nachbarn Handler b zugreifen (Messung wird korrekt gestoppt)
  4. Handler d sieht nicht mehr die Werte, die Handler a geschrieben hat, da diese von Handler c überschrieben wurden (Messung wird nicht korrekt gestoppt)
Diese Lösung ist also nicht brauchbar für diese Performance Instrumentierung, bei der ein Handler in mehrere Stränge eingeklinkt werden soll.

Ein zweiter Lösungsansatz wäre, dass man die Variablen als Name-Value Paar in einer http Session ablegt. Dieser Ansatz kommt allerdings nicht in Frage, da das Prinzip der Session ID in der C++ Implementierung noch nicht vorhanden ist. Ein weiterer Nachteil dieser Lösung liegt darin begründet, dass man dann die Messungen immer nur mit ``session scope`` durchführen könntei, d.h. es muss immer erst eine SessionId existieren, um korrekte Messungen durchzuführen.

Axis bietet die Möglichkeit, im MessageContext Objekt (C++ IMessageData Objekt), in welchem auch die eigentliche SOAP Nachricht enthalten ist, Propertys der Form Name-Value abzulegen. Dabei wird garantiert, das alle Handler sowohl im request flow als auch im response flow Zugriff auf diese Propertys haben. Da dieser Ansatz die Nachteile der ersten beiden Lösungen vermeidet, wurde dieser als Lösung für das Projekt gewählt.

Thomas Termin 2005-02-24