I am trying to use WSDL and SOAP with my iOS application. And I am desperate. Seems the 2 code generators, Sudz.com and WSDL2OBJC are not suitable. One has TONS of memory leaks, and the other one has other minor problems.
I need 3 things:
1) A test WSDL file for learning, and a test service wrapped around it. I couldn't find any, no matter how hard I tried.
2) A good tutorial on the matter. After a lot of searching, I still haven't found any good one.
3) A little more guidance on what to do, please.
My advice: Don't use SOAP/WSDL. It is outdated technology created for code generators. Modern services on the internet are moving away from it.
Use JSON and follow as much of the RESTful pattern as makes sense. JSON for the messages, in particular, makes things SO MUCH easier.
There are plenty of JSON server-side libraries and two really common ones on iOS: TouchJSON (used by adwhirl) and SB-JSON (used by facebook app)
Thanks for the advice, although I knew all that. I wish I could abandon SOAP, but I can't. We recently accepted a job from a big corporation that still uses soap in their servers. And we have no access to the internals oftheweb service whatsoever. We are obliged to use soap.
Thanks for the advice, although I knew all that. I wish I could abandon SOAP, but I can't. We recently accepted a job from a big corporation that still uses soap in their servers. And we have no access to the internals oftheweb service whatsoever. We are obliged to use soap.
In this case I would wrap the SOAP services in modern JSON services and have my app talk to that instead.
the power of webservices is that you can wrap webservice from another webservice changing the original behiavour......However is always an additional layer that can be avoided....but if you think that fit your needs, go with that.
Can you elaborate? Won't that mean access to the application server?
Sure, you write your own suite of services, for the app to consume. These can be JSON/REST, whatever. Those services in-turn call the existing SOAP services. The code for those services can be written in Java, .NET, or whatever makes dealing with all that overcomplicated SOAP stuff easy for you. Your app interacts with your new app-centric services -- so your app can be simple and deal with a sane level of complexity regarding those services.
Meaning, you can water-down the existing SOAP services using your wrapper services -- such that the app talks to services that are tailored for its needs and don't have any extra baggage.
Another reason to do this is to insulate yourself from changes in the corporate services -- if you have a service layer on a server you control that is translating for the app, you can keep the app working if the original SOAP services change, without having to deploy a new app binary.
Generally you should have code you control between code you ship to customer systems (the app) and code you don't control (the corporate web services). This is doubly true in the case of the app store, where your release cycle is arbitrarily delayed and subject to Apple's whims. You want to be able to roll out a change to your wrapper services on-demand in order to keep your app functioning properly -- not be forced to submit a new binary and wait what could be weeks for Apple to approve your update while your app is just broken.
OK I'm rambling hope you got the gist of what I'm saying...
Sure, you write your own suite of services, for the app to consume. These can be JSON/REST, whatever. Those services in-turn call the existing SOAP services. The code for those services can be written in Java, .NET, or whatever makes dealing with all that overcomplicated SOAP stuff easy for you. Your app interacts with your new app-centric services -- so your app can be simple and deal with a sane level of complexity regarding those services.
Meaning, you can water-down the existing SOAP services using your wrapper services -- such that the app talks to services that are tailored for its needs and don't have any extra baggage.
Another reason to do this is to insulate yourself from changes in the corporate services -- if you have a service layer on a server you control that is translating for the app, you can keep the app working if the original SOAP services change, without having to deploy a new app binary.
Generally you should have code you control between code you ship to customer systems (the app) and code you don't control (the corporate web services). This is doubly true in the case of the app store, where your release cycle is arbitrarily delayed and subject to Apple's whims. You want to be able to roll out a change to your wrapper services on-demand in order to keep your app functioning properly -- not be forced to submit a new binary and wait what could be weeks for Apple to approve your update while your app is just broken.
OK I'm rambling hope you got the gist of what I'm saying...
I did. And thank you for pointing out the pros of this method. However, as I mentioned in an earlier post, we do not have any access to the application server whatsoever. We can't change any code, and we can't write our own methods. We are obliged to follow the SOAP service as they give it to us.
I did. And thank you for pointing out the pros of this method. However, as I mentioned in an earlier post, we do not have any access to the application server whatsoever. We can't change any code, and we can't write our own methods. We are obliged to follow the SOAP service as they give it to us.
mmm.....what cribasoft is saying, is that you can call your webservice (the webservice that you can't control) FROM ANOTHER webservice (a your webservice) and then add funcionality as json output or any other thing you need.....clear now?
mmm.....what cribasoft is saying, is that you can call your webservice (the webservice that you can't control) FROM ANOTHER webservice (a your webservice) and then add funcionality as json output or any other thing you need.....clear now?
Oh, I see... Forgive me for making this dumb question... but won't this mean having access to a second server that will be setup according to my needs?
Oh, I see... Forgive me for making this dumb question... but won't this mean having access to a second server that will be setup according to my needs?
the second webservice will be in a your server (so you can "access" it). This 2nd webservice, need to be done by you, you need to write it (in java, or c#\vb.net or what you like).
You will use this "new" webservice (that work just as a bridge) instead of ther other webservice from your iphone client
the second webservice will be in a your server (so you can "access" it). This 2nd webservice, need to be done by you, you need to write it (in java, or c#\vb.net or what you like).
You will use this "new" webservice (that work just as a bridge) instead of ther other webservice from your iphone client
I see. Good idea, but it can't be done. We are on a very tight leash on this one. No secondary servers are allowed. Thanks for the time you spent to elaborate, however.
i dont think that adding an abstract second server would really do you any good. The main benefit i got out of cribasoft's post was that you dont have to submit an update to change your webservice interaction. Yes you would - the only way around that would be to guess everything that the developers client MAY introduce and plan ahead for it in the app. Otherwise you are still going to have missing calls to required services.
i.e. if you can download customers on release 1, then the Client decides that the app users should be able to see customer items - adds that into their soap methods - then you cant access it until you tell the phone that it has a new set of data to handle, otherwise where would you save the new data? how would you call the new data?
So what im saying there is youd still have to wait on Apple approval for an update unless you could guess all that your client wanted before release.
Stick with SOAP if that is what you have. I would be happy to email you what i used to use to parse my SOAP messages, but it is very similar to what is in Dany's section 5 "Parse XML" you need to be looking at the didStartElement, didEndElement and foundCharacters methods. It took me a while and some help from a friend at work, but once i had it sorted it all ran fine. Plus once you have got it working for one method then the rest are a real simple copy, paste and adjust the element names.
I would be happy to email you what i used to use to parse my SOAP messages, but it is very similar to what is in Dany's section 5 "Parse XML" you need to be looking at the didStartElement, didEndElement and foundCharacters methods. It took me a while and some help from a friend at work, but once i had it sorted it all ran fine. Plus once you have got it working for one method then the rest are a real simple copy, paste and adjust the element names.
I would be happy to see some example code, too, if you would be so kind to mail it to me. It would be of great help to me. Right now, I am using an abstract class that uses KissXML to isolate the SOAP body in DOM-Style parsing, but I haven't got far enough.
As far as I understand the whole tricky part is to parse the body of a SOAP command?
The way I have it set up is:
One class that is a very genera class. It uses KissXML to parse messages automatically, and extract the SOAP body.
Then depending on the request or response, I intend to make subclasses of the original, using KissXML to assemble and disassemble XML SOAP commands.
I intend to send usernames and passwords using ASIHTTPRequests.
What do you think? Is this a viable solution, or will it prove difficult to follow in long term?
Of course, any other recommendation or help is greatly appreciated.
If you want to understand this download SOAP-UI and find a web service on the internet (just a google search) you just point SOAP-UI at the WSDL and it will create template messages for all the methods, you can fill in the parameters and send/receive SOAP messages.
If you want an easy place to start creating your own web services, have a look at WSO2 WSF/PHP, it takes a bit to compile and get running (you can do it on a virtual machine) and then it creates the WSDLs for you and you can use SOAP-UI to send receive SOAP message. The annotation can be a bit of a pain, but its straightforward.
Just to note as well that your SOAP client doesnt actually need the WSDL to send/receive SOAP messages. Its used to automatically generate templates for method calls.
iOS, WSDL and SOAP?
Linear Mode
