Übertragung des ARM Correlator in den Web Service

In einer service orientierten Architektur kann es viele Web Services geben, die sich alle untereinander aufrufen. Damit man auch solch ein Szenario instrumentieren kann, ist es notwendig, den ARM Correlator in den Web Service mit zu übertragen. Der empfangende Web Service kann dann auch eine ARM Transaktion starten und seinen Correlator wiederum weiter geben. Zur Lösung dieses Problems gibt es mehrere Überlegungen, die alle zu einem mehr oder minderen großen Erfolg führen. Für das Entgegennehmen des Correlator im Web Service entfällt natürlich die Voraussetzung, dass bestehende Web Services nicht geändert werden sollen.
Das eigentliche Problem liegt darin, dass im Web Service weder die SOAP Nachricht greifbar ist, noch kann man irgendwie auf das MessageContext Objekt der Handler zugreifen. Diese Tatsache zwingt dazu, einen anderen Ansatz zu finden.
Ein erster Ansatz dafür könnte sein, dass man direkt im WSDL File für die dort beschriebenen Methoden einen weiteren Parameter vorsieht für den Correlator. Wenn allerdings der Client weiterhin die Methodensignatur verwenden soll ohne den zusätzlichen Parameter, dann muss es einen Handler geben, der dem SOAP Body den Correlator als Parameter hinzufügt. Dieser Ansatz hat den Nachteil, dass man zwei WSDL Beschreibungen benötigt, nämlich eine für den Client, der nichts von dem zusätzlichen Parameter wissen soll, und eine für den Web Service, der den Parameter kennen soll. Desweiteren ist dieser Ansatz sehr fehleranfällig, da der Handler den Parameter an der richtigen Stelle platzieren muss und der Handler überhaupt auch immer vorhanden sein muss, da sonst der Aufruf des Clients aufgrund der falschen Methodensignatur fehlschlägt. Dieser Ansatz ist auf keinen Fall empfehlenswert und wird für dieses Projekt auch nicht verwendet.
In Axis sind die sogenannten Provider dafür zuständig, den eigentlichen Web Service aufzurufen. Es wäre denkbar, diese bestehenden Provider abzuändern. Für diesen Ansatz wurden allerdings keine weiteren Untersuchungen bzgl. der Realisierbarkeit vorgenommen. Da sich im Verlaufe der Zeit diese Provider weiter ändern können von seiten der Axis Entwickler, ist es keine gute Idee, Änderungen am Quellcode vorzunehmen. Die abgeänderten Provider könnten unter Umständen nicht mehr für neueren Axis Implementierungen verwendet werden.
Wenn man den Provider also nicht ändern möchte, er aber das letzte Element im request flow von Axis ist, gibt es nur noch die Möglichkeit, diesen zu umgehen. Wie man so etwas realisieren könnte, sieht man in der folgenden Abbildung.
Abbildung 3.2: Provider umgehen
Image provider_umgehen

Der Teil über der gestrichelten Linie stellt den request flow dar. Es wird ein Singleton Objekt erzeugt, welches als Attribut den ARM Correlator besitzt. Es gibt einen speziellen Handler, der aus dem MessageContext den letzten Correlator ausliest und diesen in das Singleton Objekt ablegt. Dieser spezielle Handler muß der letzte Handler vor dem Provider sein, damit garantiert ist, dass auch wirklich der aktuelle Correlator im Singleton liegt. Der Web Service hat nun die Möglichkeit, sich ebenfalls die Singleton Instanz zu beschaffen und hat somit Zugriff auf den ARM Correlator. Vorteil dieser Lösung ist, dass man keine Änderungen im Provider vornehmen muß und dieser auch nichts merkt von der Übertragung des ARM Correlator. Ein erheblicher Nachteil dieser Lösung besteht darin, dass konkurrente Zugriffe auf das Singleton Objekt entstehen können und somit der Wert, den ein Web Service ausliest, nicht der ist, den er auslesen sollte. Ein einfaches Beispiel: Es findet ein Threadwechsel statt, nachdem der erste Thread den Correlator im Singleton Objekt abgelegt hat. Nun läuft der zweite Thread durch bis zum Schluss, und der Web Service liest den für ihn bestimmten Correlator aus dem Singleton. Der Web Service, der ursprünglich den Wert des ersten ausführenden Threads lesen soll, liest nun auch den vom Thread zwei. Dieser Ansatz wurde trotz der oben genannten Probleme für diese Projekt verwendet. Dabei ging es nicht um die perfekte Lösung, sondern darum, dass es überhaupt in irgend einer Form möglich ist, den Correlator dem Web Service zur Verfügung zu stellen.

Thomas Termin 2005-02-24