James Governor's Monkchips

SOAP is boring, wake up Big Vendors or get niched

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Evidence continues to mount that developers can’ t be bothered with SOAP and the learning requirements associated with use of the standard for information interchange. It is often described as “lightweight”, but its RPC roots keep showing.

Developers are turning their backs on the standard. Folks that is, building interesting information splicing apps–semantically rich platforms like flickr and Amazon are being accessed by RESTful methods, not IBM/MS defined “XML Web Services” calls. Now it seems the Creative Commons is responding to RESTful demand. Or more pertinently-not responding to SOAP demand because there isn’t any.

Yesterday my partner Stephen issued a wake up call for middleware and tools vendors – give developers what they want, not what you think they should have.

I have yet to hear any vendor – not one – talk to me about how they help developers design, implement and consume RESTian web services.

I take my hat off to Robert McMillan at Network World for writing this story two years ago…

One big question is why haven’t IBM and Microsoft responded? The obvious answer is vested interest. When you have “bet the company” on a technology stack its kind of a drag to have to respond to something else. Its interesting that in a week when the bug guys, including Gartner, have trumpeted the arrival of UDDI 3.0, the world is quietly getting on with more interesting projects.

A more interesting question is probably where are the disruptive small tools players doing a better job of packaging REST for developers. Who is going to package and extend LAMP and hit a ball out of the park? Maybe someone like Uche.

The slavishness of a not invented here mentality is one of the defining characteristics of the tech industry. Another technology that some developers are actually using, but which big vendors and analyst firms like to describe as dead, is ebXML. Ed Dodds is tracking the standard as closely as anyone. In healthcare, but also automotive, and increasingly supply chain in Asia, ebXML is finding some traction.

ebXML and REST have both been labelled as “not Web Services”. But these technologies are both being adopted by some of the biggest names in ecommerce – GM, Amazon, and some of the coolest new semantic platforms (Bloglines, del.icio.us, flickr).

Whats a web service? Still a great question. But anyone that defines a Web Service using SOAP in the definition is missing out on where the action is. Distinctions between enterprise and “consumer” are breaking down. REST is evidently where that convergence is being played out, not WS-I.

17 comments

  1. You’re dead right – and it makes me think I should do something about it – watch this space! 🙂

  2. I couldn’t agree more. WS-* is looking more and more like CORBA did half a decade ago: Needless, useless complexity that only residents of an ivory tower could love.

    REST itself looks hugely promising, and like any successful solution, it will multiply and spread only if it provides real value.

    SOAP won’t go away anytime soon, but I also suspect because the ever-improving tool support is going to make it easier and easier to use going forward.

    Peaceful coexistence? We’ll see….

  3. Again, with the LARGE VENDOR ADVERTISER media black out Joe McKendrick (

    http://blogs.zdnet.com/service-oriented/index.php?p=184 ) was apparently (allegedly) contractually bound not to report James’ mention of ebXML. (sigh)

  4. No media black out here! 🙂 I’ve followed up with some additional postings. Thanks! -Joe

  5. Hats off to Joe McKendrick!

  6. Doesn’t ebXML use SOAP 1.1 as its enveloping protocol?

  7. ‘Doesn’t ebXML use SOAP 1.1 as its enveloping protocol?’
    no, ebms does.

    As long as we are on xml technologies that are bloated and too much damn trouble to use, the xml schemas for ebms have some real problems such as
    <element ref=”ds:Reference” minOccurs=”0″
    maxOccurs=”unbounded”/>
    <any namespace=”##other” processContents=”lax” minOccurs=”0″
    maxOccurs=”unbounded”/>

  8. What is wrong with the ds:Reference element ref you mention, and how would you propose fixing it?

  9. I did see your blog earlier, but didn’t think to respond. For one thing, I’m a bit wary of the idea of a snap-on REST toolkit. I suspect that Wizard-think is one of the problems that is killing Web services. Apps should be made easier to build by the concepts behind either REST or WS, but only if one accepts the fact that domain modeling is hard, and that these technologies can only work their magic once you have the domain model right. We are working on the edges of this problem at Fourthought in both OSS and commercial initiatives, but I’d be wary of making big claims for our work just yet. It was interesting to see what happened to the SAJAX folks when they jumped too carelessly on the bandwagon.

  10. I do agree with you. Think it becomes useless.

  11. I have to learn soap for an app that we’re building. yeah, it’s way boring — tedious

  12. Yes Soap is boring and guess who has to learn it.. They are dev. an app here too, i can’t believe they want to use that :/

  13. James, I am not sure if you are aware of Apache Wink (http://incubator.apache.org/wink/). Websphere team has actively contributed to Apache Wink (a JAX-RS implementation) and hopefully the work will show up soon in the release stream (http://webspherecommunity.blogspot.com/2009/08/apache-wink-and-jax-rs.html). You can directly use Apache Wink now on existing WAS 6.x and 7.x releases as well

    thanks,
    dims

  14. Hi, James – Interesting post. I, personally, love the simplicity of REST. As far as IBM goes, IBM Mashup Center is a product that not only consumes RESTful services, but also generates them..

  15. I don’t think I agree with the fact that developers in general are turning their backs on WS-*. It is just that WS_* based SOA in the enterprise is now mature and perhaps less spoken of. Meanwhile, many organisations have take it as a new realm and demand new applications to be developed according to their x-layer model, that usually comprises a message bus or other SOA related tools. Usually the web-services built in these x-tier development projects are eventually stored in the ESR or at least documented somewhere.

    Architecturally an enterprise solution based on REST looks fundamentally different from one that is based on WS-*. Although you could mark the REST services as enterprise services as well, they can’t e.g. be used on a service bus and can’t be included in most enterprise service repositories.

    Although I do like to light-weight characteristics of REST, I somehow have the feeling that this makes REST a crippled contender rather than an evolvement when it concerns enterprise services.

    1. For a range of application types WS-* and SOAP are overly heavyweight.

Leave a Reply to Joe McKendrick Cancel reply

Your email address will not be published. Required fields are marked *