On 19 Dec 2006, at 00:17, Alexander Johannesen wrote: > The end of SOAP : > "It won't happen at once, it wont be overnight, but one day SOAP will > be over. We will look back and wonder "what were we thinking". It will > be up there with ActiveX, EJB2, and other things that we will describe > as mistakes that should never have made it past the powerpoint stage." I'm no great fan of SOAP, but this runs much deeper - the alternative "AJAX API" require you host a bit of Google Javascript gubbins in your Web page - not very helpful if like me you have built some Python into a pipeline to crawl for XML Schema documents.
In many ways specifying the language and environment you need to call a service is a step back before the days of RPC. It's also harder to bury Google's search inside your Web 2.0 "mashup". > "Incidentally, this shows a problem with relying on any external SOAP > or REST service for some mission-critical role in your own code. How > can you be sure that one day your service provider won't turn it off?" This is the same as it ever was: how do you stop your supplier going bust, withdrawing a product or service, or changing some key aspect you rely upon. > No one can solve the problem of people turning their services > completely off, but how do we make sure that switching from one to > another is as painless as possible? It's much easier if you have a business relationship with them, they aren't a monopoly, they have a "standard" interface, or their source code and data are "open". Paul -- http://blog.whatfettle.com
