Judging by the looks of current web platform APIs, like those of social networks, Amazon’s web services, photo sharing sites like Flickr or Instagram and many more, one could get the impression that REST has fully replaced the much maligned SOAP as the underlying communications architecture.
However, this is only true at first glance. Lots of company internal or B2B services are implemented with SOAP – especially where there is a need for more complex operations than in typical CRUD scenarios – or for more complex data structures and formal function signatures.
First things first though: This post is not about comparing advantages and disadvantages of REST and SOAP or a discussion of whether they should be compared at all – others have done that at great depth already.
Instead, this is about those cases where the decision for SOAP and against REST has already been made and where you now have to implement an iOS application that acts as a consumer of SOAP services.
The use of SOAP sometimes has historical reasons, because it might have already been established before REST became popular. But using it can also be a conscious decision, e. g. when a formally verifiable and very explicit specification is required for internal or external consumers.
Java: Which library would you like?
In the Java ecosystem you can choose from a range of web service libraries that have grown quite reliable over the years and can be plugged into most projects easily by ways of simply adding a few lines of XML to the pom.xml.
Classes generated based on the service’s WSDL take care of transparently encapsulating HTTP communication and the (un-)marshalling of data structures between XML and the Java representation. Thanks to static typing IDEs can offer code completion and other convenience features. With current versions of JAXB, JavaEE, Spring and others you can even stop worrying about (formerly required) mandatory dependency hierarchies, as annotations and dependency injection help getting rid of that plumbing. Just make sure to have the relevant JARs in your classpath at runtime, and off you go.
For Android and especially JavaME there is certainly less choice in frameworks, but there are solutions there, too.
On the other side…
RestKit provides an actively developed and widely used framework to use RESTful web services from iOS. However, regarding SOAP we’re not so lucky.
Searching Google for “ios soap client” produces quite a number of hits, however many of these are very narrowly focussed on specific individual problems or they present very simple (read: hardly usable) solutions, ranging from String-Concats and regular expressions to other quite rudimentary techniques.
Apart from that, you can find a few unfinished attempts at (not very well maintained) generic web service frameworks. Some of them (like wsdl2objc) are written in Objective-C themselves, others (like csoap or gsoap) are pure C libraries without objected oriented APIs. Artifacts generated by these tools sometimes require manual tweaking before they can be compiled against the iOS SDK and are therefore not ideally suited for quick application development.
The Apache 2.0 licensed sudzc on the other hand pursues a different approach. It provides a web interface for uploading or pointing at a WSDL service description and transforms it via server-side code written in ASP.NET/C# and a series of XSLT templates to iOS compatible artifacts, conveniently packaged as a full Xcode project in a ZIP.
Seasoned Java developers sometimes have a rough start with the (dynamic) Objective-C language and the initially alien development environment. They usually miss the undoubtedly excellent IDE support that Java enables through its static type system.
For a current customer project we decided on sudzc for our SOAP needs, because it produces artifacts that are very reminiscent of what you would expect when working with Java. This made it easy to focus on customer requirements and not have to delve in to technical details too much.
Although sudzc did not produce perfect results for the .NET based SOAP service at hand, due to it being open source we were able add to the well-readable XSLT templates a few required additions to handle our specific service. This took only a moderate amount of work. The same was true for adding support for Apple’s recently introduced Automatic Reference Counting (ARC) which took only a couple of hours to implement, but has since been added upstream independently.
sudzc produces well-done object oriented classes in an understandable and maintainable manner using portable technologies (XML/XSLT). Thanks to that reliance on a powerful standard, we were able to make the necessary adjustments without any need to touch its .NET front end application at all.
These are clear advantages it has over the other framework alternatives, that either produce somewhat “write-only” code with lots of string operations, or pure C code which often does not integrate smoothly into an otherwise object oriented CocoaTouch application.
Conclusion and next steps
Consuming SOAP based services from an iOS client program is not nearly as easily done as it is in a typical Java application – neither frameworks nor the tooling side are even remotely as mature. The aforementioned wide-spread focus on RESTful services with most popular public APIs makes it unlikely that this situation is going to change any time soon.
Nevertheless, with sudzc we seem to have found a viable solution for SOAP clients. Its standards based core principles are a good foundation that should help to keep the effort needed to add support for not yet supported SOAP features manageable.
For our current project we have wrapped the generated classes in a static library and added a thin abstraction layer, allowing us to very easily re-use them in further applications that have already been planned and will rely on the same service.