Da meine Versuche, funktionierende Stubs mit WSMakeStubs zu erzeugen, fehlgeschlagen sind, habe ich mich entschlossen es mit gSOAP zu versuchen.
Also hab ich gSOAP heruntergeladen, mit ./configure -prefix=/installdir - make - make install gSOAP compiliert und installiert.
Mit "wsdl2h -o NameDerHeaderDatei.h http://url_zur_wesdldatei.wsdl" und "soapcpp2 NameDerHeaderDatei.h" hab ich die Stub Files erzeugt und anschließend die erzeugten Dateien + stdsoap2.h und stdsoap2.cpp zu meinem Xcode Projekt hinzugefügt.
Leider hat direkt der erste Versuch das Projekt zum compilieren und zu linken fehlgeschlagen.
Der Linker hat die Meldung

"_namespaces", referenced from:
_namespaces$non_lazy_ptr in stdsoap2.o
symbol(s) not found"

ausgeworfen. Intensive Recherchen bei Google haben mich leider nicht weitergebracht.



Was letztendlich geholfen hat, war gSOAP erneut, mit dem Flag "--disable-namespaces" zu compilieren:

/configure --prefix=/installdir --disable-namespaces
make
make install

Die anschließend neu erzeugten Stub Files hab ich erneut in mein Projekt importiert, dann noch die Library libsoap++.a eingebunden (einfach mit der Maus vom Finder in die Dateiliste im XCode ziehen).
Leider gab es immer noch Probleme beim Linken des Projektes. Die Ursache war diesmal jedoch, dass die importierten Quellcodes nicht alle compiliert wurden. Ich hab sie dann von Hand zum Target hinzugefügt (wieder per Drag&Drop in den Abschnitt "Compile Sources"):



Jetzt endlich kann das Projekt erfolgreich compiliert und gelinkt werden. Auch die Verwendung der erzeugten Klassen aus den Stub Files funktioniert ohne Probleme.

Tags:gSOAP, Soap, Xcode

Aus irgendwelchen Gründen bin ich auf die Schnaps-Idee gekommen, gleich bei einem meiner ersten Testprojekte einen Webservice Aufruf starten zu wollen. Apple liefert mit Xcode ein kleines Tool mit dem Namen 'WSMakeStubs' aus, welches anhand einer WSDL Datei Stub Files für verschiedene Programmiersprachen erzeugt.
Die erzeugten Stub Files hab ich dann per Drag & Drop in Xcode importiert. Soweit war das auch alles kein Problem.
Der Aufruf der Webservice Methode sollte mit Hilfe dieses Code Schnipsels eigentlich kein Problem darstellen:

SoapTestWithLogin *stat = [[SoapTestWithLoginLogin alloc] init];
[stat setParameters: [NSNumber numberWithLong:100] in_username:@"felix" in_password:@"******"];
NSDictionary *dict = [stat getResultDictionary];

Leider lieferte mit der Aufruf nur folgende Fehlermeldung des Servers (übrigens J2EE):

No WSDL:Port has been found for the SOAP operation {http://anonuri/} ...

Nach längere Recherchen und Vergleichen hab ich dann festgestellt, dass beim HTTP Request folgender Header mitgeschickt wird: Soapaction: SOAPACTION.
Das macht nicht nur wenig Sinn, sondern ist auch falsch. Ich hab mir die von WSMakeStubs erzeugten Stub Files näher angesehen und dabei einen Fehler in der Datei WSGeneratedObj.m gefunden.
Die lokale Variable 'soapAction' überdeckt hier den Parameter mit dem gleichen Namen. Durch einfaches umbenennen der Variablen konnte der Soapaction Header korrigiert werden.
Der neue Codeabschnitt sieht jezt so aus:

NSString* soapActionHeader = @"SOAPAction";
NSDictionary* headers = [self copyHeaderDictionary:1 extraVals:&soapAction extraKeys:&soapActionHeader];
WSMethodInvocationSetProperty(ref, kWSHTTPExtraHeaders, headers);
[headers release];

Allerdings funktioniert der Soap Request immer noch nicht. Jetzt beschwert sich der Server über ein unbekanntes Element im XML Code.
Ich werde mich jetzt wohl oder übel direkt mit den Core Services befassen müssen da mich die erzeugten Stub Files nicht weiterbringen.
Allerdings bin ich schon etwas enttäuscht dass dieses Tool ganz offensichtliche Fehler enthält die auch bei Apple längst jemand bemerkt haben dürfte.
Eine Alternative zum Erzeugen von Cocoa Stub Files habe ich übrigens nicht finden können. Ich wäre da für jeden Tipp sehr dankbar.
Einen ganz interessanten Artikel zum Thema Core Web Services habe ich bei macdevcenter gefunden.

Tags:Soap, WSMakeStubs