PHP5 und BiPRO Teil III

Vor ein paar Tagen hat Sebastian von safe.me mich um einen Rat wegen eines Webservices gefragt, wobei ich auf ein sehr interessantes Feature des SoapClient Objektes gestoßen bin, mit dem ich mir vor Monaten jede Menge Nerven, Zeit und Ärger hätte sparen können. Zu jenem Zeitpunkt ging es um die Realisierung einer Anbindung zum BiPRO Webservice der AXA Versicherung AG.

Das Problem

Bei der Integration des Security Token Services der AXA warf der Soap Client immer wieder einen Fehler, dass ein Schema des W3C, welches in der WSDL Datei der AXA Versicherung vermerkt war, nicht importiert werden konnte.

SOAP-ERROR: Parsing Schema: can’t import schema from ‚http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd‘

Die Ursache des Problems ist das W3C selbst. Aufgrund von exzessivem Traffic durch den Aufruf von W3C Spezifikationen hat die W3C sich dazu entschlossen den direkten Zugriff für Applikationen, die keinen User Agent oder einen nicht erlaubten User Agent mit sich führen, nicht mehr zu erlauben. Unser Soap Client kann also gar nicht funktionieren, so lange die ausgelieferte WSDL Datei einen Verweis auf W3C gehostete Definitionen enthält. Es gibt aber Mittel und Wege, wie man dieses Problem beheben kann.

Die Lösung

Wir wissen also, dass das W3C den Zugriff auf ihre Definitionen einschränkt. Also geben wir unserem SoapClient doch einfach einen User Agent mit, der uns den Zugriff auf die XSD Datei erlaubt. Das PHP5 SoapClient Objekt hat zu diesem Zweck eine Option „user_agent“, mit der wir unser Vorhaben realisieren können. Dazu folgender Biespielcode:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// Link zu unserer AXA STS WSDL Datei
$wsdl = 'https://zint.entry.axa.de/sts/services/SecurityTokenService?wsdl';
 
// Optionen für den Soap Client
$options = array(
    'trace' => true,
    'exceptions' => true,
    'cache_wsdl' => WSDL_CACHE_NONE,
    'connection_timeout' => 30,
    'user_agent' => 'Mozilla/1.0N (Windows)'
);
 
// Los geht 's
try {
    $client = new SoapClient($wsdl, $options);
    var_dump($client->__getTypes());
} catch (SoapFault $e) {
    var_dump($e);
}

In Zeile 10 des oben dargestellten Programmcodes setzen wir einfach die Option „user_agent“ und definieren unseren User Agent mal mit einem ganz einfachen Mozilla Standard. Im Normalfall solltet ihr mit diesem Beispiel sämtliche Typen Definitionen des AXA STS auf dem Bildschirm angezeigt bekommen. Der Soap Client wird in einer von mir genutzten Entwicklungs Konfiguration aufgerufen. Im Live Betrieb sollte der Cache natürlich aktiviert werden, so dass man hier ein wenig Performance sichern kann. Das Timeout sollte im Live Betrieb auch wesentlich kürzer gewählt werden.

Kann man das so im Live Betrieb verwenden?

Definitiv nein! Dagegen sprechen sogar mehrere Gründe. Das W3C ist natürlich nicht blöd. Direkte Aufrufe von W3C gehosteten Definitionen werden vom W3C mit einem Delay versehen, so dass der Aufruf künstlich in die Länge gezogen wird. Ihr werdet sicherlich gemerkt haben, dass die Initialisierung unseres Soap Clients ein paar Sekunden gedauert hat. Genau hier kommt das genannte Delay zum Einsatz. Um es noch einmal direkter zu verdeutlichen, könnt ihr ja mal versuchen die XSD Datei direkt im Browser aufzurufen. Genau der gleiche Effekt.

Die Versicherungsunternehmen, die die BiPRO Norm nutzen, könnten dieses Delay ganz einfach umgehen, indem sie W3C gehostete Definitionen einfach auf ihren eigenen Servern hosten würden. Somit würde das W3C Delay entfallen. Allerdings hätten die Versicherungsunternehmen dann auch den Traffic, der durch den Aufruf der Definitionen erzeugt wird. Zumindest ist das der einzige Grund, der mir persönlich als einleuchtend erscheint, warum dies nicht schon längst gemacht wird. Zur Verteidigung der Unternehmen muss aber auch gesagt werden, dass es auch Versicherer bzw. Dienstleister gibt, die dieses Problem erkannt haben und entsprechende Lösungen anbieten.

Was kann man also tun, um das W3C Problem aus der Welt zu schaffen. Ich für meinen Teil habe die WSDL Datei des Versicherungsunternehmens überarbeitet, so dass nicht mehr auf das W3C verwiesen wird. Die fraglichen XSD Dateien als auch die WSDL Datei liegen nun auf dem Server des Maklers. Der dadurch erzielte Geschwindigkeitsvorteil bei der Initialisierung des Soap Clients ist enorm. Allerdings birgt das lokale Hosting der WSDL Datei auch Probleme. Was passiert zum Beispiel, wenn der Versicherer seine WSDL Datei ändert, ohne es dem angebundenen Makler mitzuteilen?

Noch Fragen?

Es gibt hier eine ausgezeichnete Kommentarfunktion. Nutzt sie einfach. 😉

About Author: Marcel
Ich bin Senior PHP Developer bei MM Newmedia. Seit 2005 bin ich begeisterter Webentwickler und arbeite als Freelancer für namenhafte Firmen und entwickle jede Menge abgefahrenes Zeug und berichte darüber in meinem Blog.