Related link: http://mail.python.org/pipermail/python-announce-list/2004-August/003318.html
I was surprised to see an old rant of mine quoted in Dr. Dobb’s Python-URL. Of late I’ve simply ceased to think about SOAP. It has become an irrelevance. I rarely come across SOAP in my sojourns. I’m not sure whether this is just bias coloring experience.
I had two recent run-ins with SOAP late last year: one while using Java and one while using Python. The state of Python’s SOAP implementations seemed a complete mess because of neglect. The state of Java’s SOAP implementations seemed a complete mess for a near-opposite reason: energetic conformance to the many SOAP flavors. This slavishness to SOAP’s worst aspects makes it impossible to figure out how to portably work with rich data using SOAP. If you’re not sticking to Java’s primitive data types (in particular, if you’re thinking of your data in XML terms), there is no chance these libraries will fit your head.
But putting the misery of these experiences aside, I’m surprised at how little I’ve had to worry about SOAP. As it became clear to me that Web Services were becoming a menace to much of the goodness wrought by XML, I worried that I would be forced to do a lot of gritting my teeth at work while I accommodated clients’ insistence on WS. This hasn’t turned out to be the case. In several cases where WS “end points” have been suggested, I’ve been surprised at how easily my suggestions of a REST-like alternative are embraced (the fact that I could usually whip up running code in hours helped a lot).
In the comments to part 2 of my Web Services chronicle (see also part 1), Mark Baker challenges me to substantiate my statement “Web services have found critical mass greater than any other distributed computing technology before them.” I made that statement based on observations at that time when it seemed WS was everywhere. Strangely enough, it is soon after that article that I stopped seeing signs of WS dominance. And as I think back on the matter, it was a rather precipitous decline.
So has WS and its SOAP center truly begun to melt away, or is that just the order I’ve imposed on my corner of the Universe? Of course in my superstition I worry that now that I’ve mused about it, I’ll be punished by a SOAP development request from a client in the near future. Time to stock up on shamrocks.
Do Web services still loom large in your world?
Hooray for sense
I'm very glad to read your comments! I too don't embrace the bloat of SOAP with open arms.
And I'll back you up on Web Services being everywhere about a year or two ago - I couldn't open an IT magazine or go to a conference without WS marketing flying at me from everywhere (much like when XML was touted as the grand saviour of all IT problems back in 2000, Web Services had the same weight on its shoulders).
Hooray for sense
Same here. I've seen SOAP used on exactly one project where I was tasked to write a web application interface for a SOAP service.
That was in 2000 (yes, early adopters) for an internal service between different locations of the same company).
After that, nothing (except a lot of hot air saying how SOAP and WS in general are everywhere).
SOAP was hyped to be the latest and greatest BECAUSE it uses XML, not for its own sake.
I think that is part of its downfall. When people started rationalising XML usage they saw how bloated and cumbersome SOAP really is and started using liquid detergent instead.
well...
...in its simplest form, SOAP is just two elements plus your own XML, with an optional header element. You can create a straightforward SOAP binding in about 50 lines of Python. Hardly what I'd call "bloated".
Maybe you could be a bit more precise?
Woot!
Kudos, Uche.
LOL
You cannot create a SOAP binding that would interoperate with *anybody* in even 5,000 lines of Python. You show me this 50 line SOAP binding of yours, and then start going down the line of SOAP services listed in XMethods and see how miserably it fails. It has nothing to do with XML (although in your 50 liner, don't forget to account for the variation on XML mandated by SOAP). It has all to do with SOAP's disgusting data typing regime.
I think maybe I'm not the one being imprecise in this matter?
--Uche
Less than 50...
The trick is that you don't *need* all of that stuff on *both* ends, just one. I recently worked on a project where we used SOAP for an external interface, and used Systinet's WASP for that... and for the internal callers and examples, we don't even use SOAP.py, we just print up XML from strings, because it's fast. Of course, the call is very simple, but that's why it's a useful integration interface - if it were complex, SOAP would be the least of our obstacles. Parsing the reponse would be tricky if it were anything other than "yeah, that worked" - we'll probably move the interface to doc-lit just to simplify that.
For a bunch of internal RPC's we actually do use SOAP.py because it was the easiest RPC to set up, and there, we only care that it interoperates with itself.
Of course, we've started adding a REST interface, now that it's got enough traction that integrators even know what that means.
Less than 50...
SOAP is about interoperability. If you control both ends of the service, you can implement your own system that takes much fewer than 50 lines of Python. Why would you bother with the complexity of SOAP if you control both end points? What does SOAP gain you in that case? I can think of many advantages you *lose*, including speed of processing, excessive bandwidth consumption (bloat), loss of transparency, etc.
--Uche
LOL
http://effbot.org/zone/elementsoap-1.htm
contains the first 32 lines, or so.
add a little code that inspects the soap:Header element, and you're done.
to deal with the soap:Body contents, use your favourite XML tools. it's not like you don't have to write code to interoperate with non-SOAP services...
"It has all to do with SOAP's disgusting data typing regime."
which is entirely optional, of course.
LOL
I tried elementsoap in writing my dW Python/WS series. I couldn't get past first base with it on any third-party Web service without writing so much code I couldn't see the point of using a binding.
Again, show me the code that interoperates with a decent subset of what's listed in XMethods before I think you can make a credible claim of a "straightforward binding".
It's actually easier for me to use XSLT via Kafka (see http://www-106.ibm.com/developerworks/webservices/library/ws-pyth13/) if I truly want to ignore SOAP specs and pretend SOAP is simply XML shoved into a couple of elements.
The data type regime is only optional if you're properly using doc/lit Web services. Two problems for you:
1) Doc/lit Web services are very rare so far (I hope they'll get less so)
2) elementsoap does not really follow the nuances of doc/lit, but rather sort of makes a few wishful assumptions about SOAP, approximating doc/lit in the process
If SOAP were refactored (2.0?), making doc/lit truly as easy as throwing an XML document in tot he body with full transparency, then I'd think your optimism might be warranted. As it is, I honestly think you haven't closely studied the SOAP specs in a while. they're a lot more complex than you make out. If you did, you'd realize that you can't just use any old XML toolkit to process the payload: SOAP modifies the definition of XML, which is why my central point is that SOAP is not XML.
--Uche
LOL
"I couldn't see the point of using a binding"
That's what I'm trying to tell you, of course: you don't really need a binding to talk to any given SOAP service. You have to write some code, sure, but you have to do that also for services that don't use SOAP.
"SOAP modifies the definition of XML"
Are you talking about the QNames mess? (http://www.w3.org/2001/tag/doc/qnameids-2002-04-30)
LOL
I'm confused. You say that SOAP is "not bloated" because you can write a "straightforward binding" in 50 lines of Python. Not that I understand that logic (SOAP is bloated regardless of how many lines it takes to write an end-point), but I let that go to focus on the IMHO ludicrous idea that one could write a SOAP binding in 50 lines.
I pointed out that your elementsoap doesn't really qualify because it does not cover a fraction of enough of the plumbing of SOAP to reasonably be considered a "binding". Your response is along the lines of: "A ha: you don't need a SOAP binding, anyway. Just write custom code". You've completely lost me.
It takes a lot of lines of code to write compliant SOAP. It does take much fewer when you use a truly compliant binding such as Apache Axis or JWSDP, but in the case of SOAP such bindings also have the property of rendering your services usage completely non-transparent. This is the fault of SOAP and the point of my comment.
I can tell you that Using any decent CORBA binding, and OmniORB is an excellent example, I have to write almost no specialized code besides the IDL (and compliant SOAP really does need WSDL to manage sanely, so I don't think CORBA is more complex for requiring IDL). The resulting code is somewhat opaque, but not nearly as bad as the case with SOAP.
As for SOAP's deviations from XML standard, this issue is very well known in the industry, and the very XML-DEV thread in which I made the rant that I linked to in this Weblog was a discussion of SOAP's forking of XML. The differences include treatment of the internal subset, treatment of lexical character data and more. QNames in context are nasty, but do not have anything to do with forking XML.
--Uche