SOAP Webservices mit iOS

Betrachtet man APIs für aktuelle Web-Plattformen wie Soziale Netzwerke, die Amazon Web Services, Fotodienste à la Flickr oder Instagram und zahllose mehr, so könnte der Eindruck entstehen, REST hätte als der Kommunikation mit entfernten Diensten zu Grunde liegende Architektur das häufig geschmähte und als überbordend und komplex verteufelte SOAP bereits seit langem abgelöst.

Allerdings ist dies nur auf den ersten Blick der Fall. Insbesondere unternehmensintern werden immer noch viele Dienste mittels SOAP abgebildet – insbesondere dort, wo es weniger auf das reine Abholen von Ressourcen oder verhältnismäßig einfache CRUD Operationen ankommt, sondern eher komplexe Datentypen mit einem reichhaltigen Typsystemen und validierbaren Funktionssignaturen im Vordergrund stehen.

Gleich vorab: In diesem Post soll es nicht darum gehen, die Vor- und Nachteile von SOAP und REST gegenüberzustellen oder zu diskutieren, ob die beiden Techniken grundsätzlich überhaupt verglichen werden sollten – damit haben sich andere bereits ausreichend beschäftigt.

Stattdessen geht es hier um die Fälle, in denen die Entscheidung für SOAP und gegen REST bereits gefallen ist, und in denen nun die Problemstellung zu lösen ist, eine iOS Anwendung zu entwickeln, die eben diese SOAP Dienste als Konsument verwenden kann.

Die Verwendung von SOAP hat zum Teil historische Gründe, bei denen die SOAP Schnittstellen bereits existierten, bevor REST populär wurde. Mitunter ist es aber auch eine bewusste Entscheidung, um für interne wie externe Clients über WSDL und etablierte Frameworks eine wohldefinierte und formal prüfbare Schnittstelle anzubieten.

Java: Welche Library darf’s denn sein?

Es existieren im Java Ökosystem verschiedene Web Service (Client) Frameworks , die über Jahre hinweg an Reife gewonnen haben und sich somit weitgehend reibungslos als verlässliche Ressourcen über ein paar Zeilen XML in der pom.xml eines üblichen Java Projekts einbinden lassen.

Einmal auf Basis von WSDL generierte Client Klassen übernehmen die HTTP Kommunikation und das Marshalling/Unmarshalling von Datenstrukturen aus der XML in die Java Welt. Dank statischer Typisierung greifen Code Completion und andere Convenience-Features der IDE. Mit den aktuellen Versionen von JAXB, JavaEE, Spring und anderen treten dabei auch die früher noch üblicheren (weil erforderlichen) Vererbungshierarchien oder Interfaces in den Hintergrund, da mit Annotations und Dependency Injection nochmals viel Boilerplate Code eingespart werden kann. Zur Laufzeit wird lediglich noch das eine oder andere JAR in den Classpath gepackt, und schon läuft die Sache – meistens – rund.

Zwar wird die Auswahl an verwendbaren Frameworks für mobile Anwendungen für Android bzw. insb. JavaME durchaus etwas kleiner, aber auch hierfür stehen brauchbare Lösungen zur Verfügung.

Auf der anderen Seite…

Für iOS steht mit RestKit ein aktiv entwickeltes und vielfach verwendetes Framework zur Verwendung von RESTful Webservices zur Verfügung, für SOAP hingegen wird die Luft schnell dünner.

Eine Google Suche nach “ios soap client” bringt zwar zahlreiche Ergebnisse ans Licht, allerdings sind viele der Ergebnisse sehr eng fokussiert auf ganz individuelle Fragestellungen oder präsentieren sehr einfache (lies: wenig brauchbare) Lösungen, die von String-Concats über reguläre Ausdrücke und andere ebenfalls eher rudimentäre Techniken reichen.

Daneben gibt es eine Reihe von begonnenen, aber nicht besonders aktiv gepflegten Ansätzen für allgemeine Frameworks, die wie z. B. wsdl2objc selbst in Objective-C geschrieben, z. T. (wie csoap oder gsoap ) aber auch reine C-Libraries ohne objektorientierte API sind. Zum Teil lassen sich die generierten Artefakte erst nach einiger Anpassung gegen das iOS SDK kompilieren und sind somit für eine zügige Anwendungsentwicklung nur bedingt geeignet.

Das unter der Apache 2.0 Lizenz stehende sudzc hingegen verfolgt einen anderen Ansatz, indem basierend auf der WSDL Beschreibung einer SOAP Schnittstelle serverseitig mittels ASP.NET/C# und XSLT die entsprechenden iOS Artefakte für Datenstrukturen und Remote-Calls erzeugt werden.

Praktischer Einsatz

Für erfahrene Java Entwickler ist Objective-C als dynamische Sprache eine zunächst ungewohnte Umgebung , in der oft insbesondere die gute IDE Unterstützung, die letztlich in dieser Güte weitgehend nur durch Javas statische Typisierung möglich ist, vermisst wird.

Im Rahmen eines aktuellen Kundenprojekts fiel die Wahl des Werkzeugs auf das o. g. sudzc, da es für Java Entwickler am ehesten wiedererkennbare Ergebnisse produziert. Dies erlaubt es, sich auf die Kundenanforderungen zu konzentrieren, anstatt sich über Gebühr mit technischen Details befassen zu müssen.

Zwar lieferte es für einen mit .NET realisierten und von unserer Anwendung aufzurufenden SOAP Service Endpoint nicht out-of-the-box perfekte Ergebnisse, doch ließ es sich dank der im Source vorliegenden und nach kurzer Einarbeitung gut nachvollziehbaren XSLT Templates mit verhältnismäßig geringem Aufwand so erweitern, dass die bis dato nicht unterstützten Merkmale der konkreten WSDL nun verfügbar sind.
Auch die Nachrüstung der bis vor kurzem noch nicht idealen Unterstützung für das von Apple kürzlich neu eingeführte Automatic Reference Counting (ARC) konnte innerhalb weniger Stunden realisiert werden.

Das Werkzeug produziert im Kern unter Verwendung von Standardtechnologien (XML/XSLT) auf nachvollziehbare und insbesondere unabhängig von der umgebenden .NET Frontendanwendung wartbare Weise objektorientierten und weitgehend typsicher verwendbaren Client Code. Dies ist als deutlicher Vorteil gegenüber allen anderen Optionen zu sehen, die entweder “hemdsärmelig” zahlreiche explizite Stringoperationen erzeugen, oder reinen C-Code produzieren, der nicht ohne weiteren Aufwand nahtlos in einer ansonsten objektorientierten CocoaTouch Anwendung eingesetzt werden kann.

Fazit und nächste Schritte

Die Verwendung von SOAP basierten Services in einer iOS Anwendung ist beileibe nicht so komfortabel und einfach wie in einer typischen Java Anwendung. Dazu sind weder Libraries noch Tooling auch nur annähernd ausgereift und erprobt genug. Aufgrund der eingangs erwähnten Präferenz für REST basierte Schnittstellen seitens der meisten öffentlich verwendeten APIs ist auch fraglich, ob sich die Lage diesbezüglich in naher Zukunft nennenswert verändern wird.

Dennoch steht mit sudzc eine durch die Verwendung bewährter und wohldokumentierter Techniken solide Grundlage zur Verfügung, auf deren Basis sich mit ggf. etwas Anpassungsaufwand recht problemlos Clients für die meisten SOAP Services erstellen lassen dürften.

Für das aktuelle Projekt haben wir den generierten Code als statische Library gekapselt und um eine dünne Abstraktionsschicht ergänzt, dank der er sich problemlos in bereits geplanten weiteren Anwendungen, die auf dem selben SOAP Service basieren werden, einsetzen lassen wird.