Adam Bosworth's latest call to "keep it really simple, really lightweight, and really fast" resonated instantly with several influential voices over the weekend.
In a weblog entry entitled KISS and The Mom Factor, Bosworth writes about the joy of designing for "mere mortals" in his new job at Google (so the title means Mom as in Mom-and-Pop, and not MOM as in the tech-industry acronym for message-oriented middleware). He goes on to make the point that designing for that audience means designing with a view to massive scalability, which means keeping the basic plumbing as simple as possible (hence KISS Keep it Simple, Stupid). That in turn means avoiding SOAP if you're not using any of its panoply of accompanying WS-* specifications (and who is?). SOAP is complex to create and slow to consume, compared to the simplicity of pure XML-over-HTTP:
"If you can return HTML, you can return XML. It is this sort of thinking that being at a service company engenders. How do you keep it really simple, really lightweight, and really fast. Sure, you can still support the more complex things, but the really useful things may turn out to be simplest ones.
On an August weekend, there aren't many people posting weblog entries (and not many more of us reading them), but it was interesting to see this posting getting picked up instantly by others for whom it struck a nerve:
Tim Bray, who since his recent move to Sun is even more widely followed than before, gave his ringing endorsement to What Adam Said: "... go read his latest piece, he says in one paragraph what I've been raving about for months in the area of Web Services: 'The really useful things turn out to be the simplest ones.' How many times do we have to re-learn this lesson?"
Sean McGrath, who's one of the industry's most clear-sighted practitioners writing about web services and service-oriented integration in general, finds that the Bosworth piece chimes with his own posting earlier in the week railing against the proliferation of WS-* standards, WS-MD? No thanks: "Get back to basics. You have URIs, you have XML messages. You need reliable, asynchronous message exchange. It's not complicated. It's a simple HTTP exchange pattern on top of a MOM." (That's MOM as in message-oriented messaging, of course, not Mom-and-Pop). Sean's verdict on SOAP is provocative: "SOAP always was and always will be an API-centric worldview. That is not the future. That is the past. Re-implemented badly." And by way of explanation, his weekend posting links back to an ITWorld column he penned in 2002, APIs Considered Harmful: "Don't let some API get in the way of your understanding of XML systems at the document level. If you do, you run the risk becoming a slave to the APIs and hitting a wall when the APIs fail you."
This sudden backlash against SOAP reminds me of my posting a couple of years ago about When and how to use REST (REST being a sort of fundamentalist definition of XML-over-HTTP web services): "Because developers find SOAP more convenient to use, it will often be their first choice when implementing a web service. But I suspect that in many cases they will end up going back and refactoring it out of the application in favor of REST, in order to reach out to a broader universe with less overhead."
Reminiscences aside, I'm glad to see evidence of such a groundswell of opinion in favor of keeping XML web services simple and accessible, because even without all the paraphenalia of SOAP and the WS-* stack, there's still a lot of work that needs doing to make it really simple to produce and consume raw XML. For when the powers-that-be in the world of web standards created XML, they decreed that mere mortals would not want to work with raw XML, arguing that there would always be tools available for them to use. So they built in strict requirements for how XML should be formulated which is no bad thing in itself, I don't have a problem with that except that today there's still a dearth of KISS-simple tools that we mere mortals can use to create well-formed XML.
The test-bed for XML's mass market usability has been RSS, which has led to thousands of lesser mortals I won't say mere yet because we're still at the level of those who've sacrificed time and effort to become at least semi-initiated in the ways of XML taking it upon themselves to write programs that either produce or consume RSS feeds. A few hardy souls have gone further to explore using XML stylesheets to transform XML into HTML and other formats. But as Mark Pilgrim established early on, such experiments often fall short of XML's strict presciptions. And as Sam Ruby has shown in tests on aggregators and on weblogs, even professionally developed programs often fail to handle 'Iñtërnâtiônàlizætiøn' properly.
So it's good to see that some of Google's resources are going to be focussed on making it easier for simple folk to manipulate XML. Those tools will have their own implicit API, of course, since no one's Mom is going to bother messing about with angled brackets and attributes in the raw. The quest for KISS, then, is all about finding the right level of simplicity masking complexity without inhibiting freedom of expression and creativity. The tool has to seamlessly create well-formed XML and handle internationalization without a hitch without creating unnecessary management or processing overhead when deployed to the network while still giving Mom the freedom to consume, design, publish and co-ordinate XML documents in whatever configuration she so desires. Simple, huh?