So, I had managed to dodge it until now, but that’s it, we’re in 2006 and I need to use SOAP web services. Back in 2002 I was implementing and consuming REST+XML or XML-RPC web services all over the place. At the time, SOAP smelled like… well, let’s says it definitely didn’t smell like soap. Today, I’m not a slightiest bit more convinced, but when you gotta do it, you gotta do it.
So yes, I used Java and the AXIS web services library to consume web services, namely the Google Adwords API and the Amazon Electronic Commerce Services. Of course, Java isn’t a dynamic programming language, so you have to generate a bunch of code using the WSDL2Java compiler, but it’s not that difficult. You then get a true Java API that smells like… well, it doesn’t smell very soapy either.
I mean, I’ve already given a sample of the need to instantiate a factory to get a locator service that will build a service implementation that you need to configure. It isn’t pretty. But that’s only the initialization part. Then, you use an API that has been obviously generated by a computer and doesn’t feel user friendly at all. It’s a bit like a DOM API from another dimension. Well, let me pat myself on the back for this cunning analogy, because it is in fact exactly that : the AXIS toolkit did its best to build wrappers around the structure of request and response documents. XML documents, mind you, and I won’t even add insult to injury by reminding my wide audience that those structures are specified in the Ruth Goldberg XML Schema format.
Well, give me embedded XML litterals like in E4X or C# 3.0, and native XPath support like in… well LINQ (also in C# 3.0, there’s a thing going on here), and you’ve got a proper toolkit to consume web services. But here, AXIS generates a bunch of wrappers that are quite awkward to use as soon as the document structure is a tad complicated. Pretty soon you wish you could stop using those wrappers and access the raw XML nodes (preferably using the XOM API, but that’s another story). I’m sure there’s an option somewhere that allows you to do that, but I could not find it, and given what I saw, I expect the result to be quite messy.
Anyway, while struggling with all those bells and whistles, I told myself « Hey, all this mess is caused by the static typing of Java, why not try to do it in Python ?« . Why not, indeed ? Well, because if using SOAP Web Services in Java is awkward, in Python, it’s actually painful, because It Just Won’t Work™.
Oh, I know the documentation are wonderful, and dynamic typing allows for wonderful proxy thingies that all work my magic… CORBA is just sweet in Python (see omniORB), because you don’t have to worry about code generators and compilers and so on. You give your ORB an IDL file and bam, it works. Or not. But that’s another story.
Well, it’s not, actually, because SOAP Web Services are actually a stripped down, crappy version of CORBA, WSDL being a tricky, complicated version of IDL. So you’d expect the experience to be similar, and it is : you give your SOAP library a WSDL and bam, it works.
Except it doesn’t. Because in the Python world, XML libraries in general and Web Services in particular are either half implemented or not unmaintained since the heidy days of 2000-2002. One of the brand new things in Python 2.5 is the inclusion of ElementTree, a replacement Python-friendly DOM API for the pile of non-standard crap that we have right now. Isn’t it about time ?
For web services, the situation is much worse, and the sad truth is that you can use ZSI or SOAPy to consume web services, but you’ve got a very high chance that it won’t be compatible with obscure web services like the one proposed by Google, Amazon or Yahoo. Thanks god the two later also provide REST APIs… But right now it’s the Google APIs that interest me. And Google said « thou shall use SOAP, SOAP thou will use ». And the Python SOAP APIs don’t understand. We might as well use CORBA, for that kind of « interesting » incompatibilities.
raimondas says « Python Web Services – Not Quite Painless« , but I feel that for the sake of precision, we should simply say « Python Web Services – Actually Quite Painful ».
The good thing is, like for all painful things, it’s a relief when it stops. I really didn’t expect to enjoy using Java and AXIS for this. Oh, well…