Note to self: for working with non-XMLRPC stuff, ensure that xmlrpc-1.2-patched.jar is in $GLOBUS_LOCATION/lib, otherwise you get [JWSCORE-193]. For working with XMLRPC stuff, ensure that xmlrpc-1.2-patched.jar is not in $GLOBUS_LOCATION, otherwise you get “class “org.apache.xmlrpc.XmlRpcRequestConfig”‘s signer information does not match signer information of other classes in the same package” (at least with xmlrpc-*-3.1.2.jar).

Gerade eben dachte ich mir, ich könnte mal wieder meinen Zugang zum BW-Grid richtig einrichten, da wurde demletzt nämlich der Headnode geändert. Also die E-Mail mit dem neuen Hostnamen gesucht, Zertifikat runtergeladen, mit OpenSSL gehashed, passend kopiert, signing policy erstellt… und nix geht, wie immer.

Dass das OpenSSL-Geblödel immer so umständlich sein muss… eine halbe Stunde später habe ich es dann, doch noch hin bekommen – das Root-Zertifikat musste ich auch noch neu runterladen, hashen und die signing policy dafür erstellen. Hauptsache, es geht, gerade eben bin ich erfolgreich auf dem Headnode eingeloggt.

Gefühlt ewig habe ich jetzt daran rumgefrickelt, dass ich einen Globus Toolkit 4-Service nicht via Apache Synapse als Proxy ansprechen konnte, es gab immer eine No Action header-Exception; WSRFLite hatte damit allerdings im Gegensatz zu GT4 komischerweise keine Probleme. Nachdem ich mir jetzt mal alle SOAP-Nachrichten detailliert angeschaut habe war’s recht offensichtlich: Synapse entfernte den Header. Hmm, aber ich hab doch enableAddressing in der Konfiguration angegeben… und was war’s, die Betriebsblindheit natürlich. Denn anstatt so:


<endpoint>
<address uri="http://localhost:8888/wsrf/services/FooService" />
<enableaddressing />
</endpoint>


muss es so aussehen:


<endpoint>
<address uri="http://localhost:8888/wsrf/services/FooService">
<enableaddressing />
</address>
</endpoint>


Hmm, ich fand’s nicht so unlogisch das enableAddressing-Tag für den Endpoint zu setzen, aber gut. Fehlermeldung beim parsen der Config gab’s auch keine, also reichlich uneindeutig den Fehler auf Anhieb zu finden ohne in die SOAP-Nachrichten zu schauen. Ansonsten ist Synapse ziemlich cool, mal sehen wie es sich mit GSI verträgt, das ist ja immer relativ frickelig.

Schon lange gab’s keine Berichte mehr zum Thema “Spaß mit Web Services”, heute ist es mal wieder soweit. Ich habe jetzt kaum einen kompletten Arbeitstag mit einem Problem verschwendet, dass sich mal wieder als äußerst trivial darstellt – ein einziges Attribut in der XML Schema-Definition passend gesetzt und alles geht, ansonsten geht halt nichts.

Kurz zum Hintergrund: ich versuche gerade, einen WS-Agreement Web Service von GT4 auf UNICORE/WSRFLite zu portieren und darüber einen Artikel zu schreiben. Das hat bis gestern auch alles funktioniert, nur habe ich dann festgestellt, dass ich keine Attribute setzen kann, ohne dass es knallt: “Unbound namespace URI ‘http://schemas.ggf.org/graap/2007/03/ws-agreement’” ist die wenig aussagekräftige Fehlermeldung.

Gut, dachte ich mir, vielleicht geht, warum auch immer, nur dieses eine Attribut nicht, also ein anderes gesetzt – nichts. Es lagen auch keinen alten Bibliotheken irgendwo rum, also sehr komisch. “Definierst du dir halt eigenes Element mit Attribut, vielleicht geht’s dann”, dachte ich mir – half aber auch nichts. Also nochmal an den WSRFLite-Beispielservice, dort ein Element um ein Attribut erweitern und testen – geht. Äh, wie jetzt nochmal? Dann habe ich mal mein eigenes Element in eine eigene Schema-Datei extrahiert und auch das ging. Beim vergleichen meiner Schema-Datei mit der von WS-Agreement ist mir dann aufgefallen, dass bei WS-Agreement »attributeFormDefault=”qualified”« gesetzt ist, in meinem Schema aber nicht. Und, oh Wunder, als ich dies entfernt habe, ging’s auf ein Mal.

Mir ist allerdings im Moment nicht klar, wo genau das Problem liegt. Möglicherweise liegt es an der WSRFLite (respektive XFire)-Version, vielleicht auch an der Kombination von »elementFormDefault« (“qualified” bei WS-Agreement) und »attributeFormDefault« (“auch qualified”). Wenn ich dazu noch Muse habe – immer eher unwahrscheinlich, wenn das initiale Problem gelöst ist, aber vielleicht doch, da ich ja immer gerne weiß, warum etwas nicht ging -, werde ich mal untersuchen, wie sich die verschiedenen Kombinationen auswirken; bei Oracle gibt’s zu diesem Thema ein nettes Dokument, XML Schema: Understanding Namespaces.

Einen Policy Decision Point (PDP) – wer nicht weiß, was das ist, hat auch nichts verpasst – in GT4 4.0.X zu schreiben war vielleicht nicht intuitiv, aber auch nicht so unmöglich blöd wie jetzt in 4.2.X. Der PDP tut zwar mittlerweile angeblich das, was er soll, dafür bekomme ich jetzt aber andere lustige Fehlermeldungen, die es ohne diesen PDP nicht gibt – bin da ja auch erst den zweiten Tag dran, macht ja nix… ist ja nicht das erste Mal, dass man da beliebig Zeit verblödelt.