>>I agree with the author. The last 3 or 4 web services I've written started out getting scoped as SOAP services, and for some reason or other, the decision was made to use a simple POST, or even a GET instead. SOAP either added too much fluff (read: bandwidth intensive) to the message for high volume services, or added too much complexity for a simple task. Twice there were circumstances that prevented the use of a toolkit on the client, and so the unnecessary complexity of SOAP really hit home. Out of the 10 or 12 times i've needed to expose a service over the web, SOAP turned out to be the best solution only twice.
>
>While I agree in general you're making too many assumptions here on your own devcelopment environment.
>
>Most development tools don't natively provide easy access to HTTP services to send XML back and forth easily and consistently.

That's getting less and less true. Java makes it easy, as do .NET and even VB 6.0 (using XMLHTTP). I haven't tried in COBOL or ADA. :-)

> And then once you have the XML no mechanism to do something useful with it *easily* (read: not manually parsing the XML). SOAP facilitates these processes by providing the HTTP transport and the XML parsing internally.

No, SOAP _toolkits_ facilitate these processes, and that's my point. The protocol itself is klunky. Where the Web Service is little more than a wrapper around one or more methods on an existing component, SOAP is great, because there's a lot of gain to be had with typing and the like, but for one off tasks designed from the ground up to be web-exposed, I don't think SOAP is a good idea, except that toolkits _can_ make it nice.

> But we in VFP are also very spoiled in that we have very easy tools to deal with common XML data (XMLToCursor, XMLToObject etc) that you won't find in other tools predating .NET.

Other tools are catching up fast, and in some cases (.NET and many Java components) have blown by VFP. Objects that know how to serialize themselves as XML are the answer most are offering.

>SOAP aims to simplify this and I think VS.NET is the first environment to really capitilize on that. If you were using .NET as your dev environment, do you still think that pure XML would be your preferred choice? I doubt it...

Very possibly. If I knew beyond a shadow of a doubt that I would have the option of using .NET on all the clients and the server, then yes, but most of the stuff that I've been working for the last couple of years, I don't have that guarantee. If you aren't guaranteed a tidy toolkit on the client, SOAP starts looking like _much_ more trouble than it's worth.