Dec 16 2005

SOAP Destined to A Life of Obscurity

Published by Ian Davis at 3:18 pm under Uncategorized and tagged as , , , , ,

This piece from Dare Obasanjo hot on the heels of the UDDI public registry closure adds weight to my suspicion that SOAP is finally being sidelined into a niche activity.

When I worked on the XML team, I used to interact regularly with the Indigo folks. At the time, I got the impression that they had two clear goals (i) build the world’s best Web services framework built on SOAP & WS-* and (ii) unify the diverse distributed computing offerings produced by Microsoft. As I spent time on my new job I realized that the first goal of Indigo folks didn’t jibe with the reality of how we built services. Despite how much various evangelists and marketing folks have tried to make it seem otherwise, SOAP based Web services aren’t the only Web service on the planet. Technically they aren’t even the most popular. If anything the most popular Web services is RSS which for all intents and purposes is a RESTful Web service. Today, across our division we have services that talk SOAP, RSS, JSON, XML-RPC and even WebDAV. The probability of all of these services being replaced by SOAP-based services is 0.

One response so far

One Response to “SOAP Destined to A Life of Obscurity”

  1. # John McDowallon 17 Dec 2005 at 6:40 am

    While I have not looked at Indigo I can say that .Net 1.1 is REST hostile and makes doing simple things extremely hard, while Java Servlets makes it trivial to enable the creation of a REST interface. .Net tries to make development wizard driven and hide the complexity and in doing so puts a straight jacket on the developer which constrains the style they choose to develop in. Java, Perl, Python, Ruby, etc are much more open ( and hence require more knowledge) so can be adapted to any design pattern easily if you have the skill and knowledge.

    In essence the Indigo/.Net approach is to tell developers to pay no attention to the man behind the curtain or just trust us. If the architectural patterns are well defined this may work but we are still defining the path to teh best approach to a services based network and these constraints just get in the way.