Architektur

Axis besteht aus mehreren Komponenten. Die Kernkomponente ist dabei die AxisEngine. Sie koordiniert, auf welche Art und Weise die Nachrichten durch das System geleitet werden. Konkret gibt es für den Client den AxisClient und für den Server den AxisServer. An der Verarbeitung einer SOAP-Nachricht sind in der Regel mehrere sogenannte Handler beteiligt, d.h. es werden nacheinander mehrere solcher Handler durchlaufen. Was für Handler das genau sind und in welcher Reihenfolge sie durchlaufen werden, ist zum einen von der Konfiguration abhängig und zum anderen, ob man sich auf Client- oder Server-Seite befindet. Jeder Handler hat die Möglichkeit, eine SOAP-Nachricht zu verarbeiten, zu verändern oder darauf zu reagieren. Mehrere solcher Handler können zu einer Chain (Kette) zusammengefasst werden. Dabei ist eine Chain wieder ein Handler, welcher wieder eine Menge von Handlern aufruft, die zur Chain gehören.

In der folgenden Abbildung wird der Ablauf Ablauf auf Seiten des Servers verdeutlicht.

Abbildung 2.2: Nachrichten Ablauf auf Seiten des Servers
Image ServerMessagePath

Alle SOAP-Nachrichten erreichen zunächst den Transport Listener in Abhängigkeit des verwendeten Transportprotokolls. Der Transport Listener verpackt die Nachricht dann in ein spezielles Message Objekt.
Innerhalb der AxisEngine unterscheidet man zwischen dem request und dem Response Flow. Als request flow wird der Weg hin zum empfangenden Web Service bezeichnet, und als Response Flow wird der Rückweg bezeichnet.
Während das Objekt durch die AxisEngine wandert, wird das Objekt durch drei verschiedene Handlerketten geschleust: die transportspezifische Kette, die globale Kette und die servicespezifische Kette. Die Transportkette enthält alle Handler, die nur dann aufgerufen werden, wenn eine SOAP-Nachricht über ein bestimmtes Transportprotokoll eingegangen ist. Man kann somit für jedes Protokoll andere Verarbeitungsschritte vorsehen.
Als nächstes passiert das Objekt die globale Kette. Handler, die sich in der globalen Kette befinden, werden grundsätzlich immer aufgerufen, unabhängig vom Transportprotokoll und vom Web Service.
Als letztes wird die servicespezifische Kette durchlaufen. Handler dieser Kette werden nur durchlaufen, wenn die zu verarbeitende Nachricht an einen ganz bestimmten Service gerichtet ist. Damit ist es wiederum möglich, für jeden Service eine eigene Handlerkette zu konfigurieren. Die servicespezifische Kette enthält zusätzlich noch einen speziellen Handler, den sogenannten Provider. Der Provider ist dafür zuständig, den addressierten Web Service aufzurufen und gegebenenfalls Parameter mit zu übergeben. Die Antwort, die der Web Service zurückliefert, packt der Provider wiederum in ein Message Objekt, welches dann die Response Nachricht repräsentiert. Da der Provider den Wendepunkt der Nachricht darstellt, wird er auch als Pivot Element bezeichnet. Auf dem Response Flow werden wieder alle drei Handlerketten durchlaufen. Dabei können völlig andere Handler registriert sein als auf dem request flow.

Der Ablauf auf Seiten des Clients ähnelt sehr dem auf Seiten des Servers, lediglich die Reihenfolge der Ketten ist umgekehrt.

Abbildung 2.3: Nachrichtenablauf auf Seiten des Client
Image ClientMessagePath

Die Client Anwendung baut als erstes ein Message Objekt zusammen. Diese übergibt sie dann an die AxisEngine. Hier wird nun zunächst die servicespezifische Kette durchlaufen, dann die globale Kette und schließlich die transportspezifische Kette. In der transportspezifischen Kette befindet sich, wie beim Server in der servicespezifischen Kette, ein spezieller Handler. Es handelt sich hierbei um den Transport Sender. Seine Aufgabe besteht darin, mit Hilfe des Transportprotokolls die SOAP-Nachricht zu versenden und die Rückantwort (falls vorhanden) entgegenzunehmen. Da der Transport Listener auch den Wendepunkt innerhalb des AxisClient darstellt, wird er auch als Pivot Element bezeichnet.

Thomas Termin 2005-02-24