>>>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. :-)

Java's native HTTP tools are pretty lame and don't support advanced features out of the box (unless this has changed very recently). Last I looked SSL support wasn't even included in the Java Runtime Libraries.

.NET definitely has the tools and they're reasonably easy to use. XMLHTTP is OK, but very limited if you need to work with proxies and binary content.

>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.

I don't agree. I think a Web Service actually forces you to build a consistent front end to a component that's exposed in this fashion. Without it the front end layer often is very application centric (a little like sticking some of the business logic into form controls). By having a distinct class that acts as the front end you're forcing some structure into how that data is exposed. Now you can do the same with plain XML services, but it's less likely that you do.

I klnow that in my own work I have many Web Connection methods that were XML enabled before there was SOAP and it's worked well, but if you compare the code between with and without Web Services on the server side and especially on the client side you find that a lot less code is involved and the code is much more readable and easily debugged beccause all the transport logic is completely hidden away.

>> 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.

Yes, but unfortunately most of these don't interoperate very well yet. And worse there's not enough flexibility in these tools to allow adjusting for slightly different formats.

>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.

While I think that's true, I think just about any client can come up with a SOAP toolkit of some sort. I mean the front end choices are pretty limited unless we start talking about phones/PDAs etc. in which case it all is a PITA no matter how you design it.