I currently ask myself: "Why do you need client libraries to make SOAP calls?" - Generating the message can simply be done by string concatenation and parsing the response can be done with a very simple parser with very little code. This results in very compact and fast code - ok, who wants to maintain code anyway?

And who has defined this WSDL ? Now, it's a little bit funny. One of the basics of XML is the humanreadable text format. And now look at WSDL which is XML. Is this humanreadable? So it can't be XML...[Carsten Ziegler]

Interesting point.  I've been working with early adopters of my employer's web service offerings and one thing that we've ended up doing is writing the client proxy code for our customers.  Fortunately, everyone's using Apache SOAP or .NET, so that makes the problem tractable, but it's a bit surprising.  Part of the problem is that existing tools don't handle our WSDL contract well (BTW, thanks for the Axis info, Sam), so you end up hand coding the proxy.  The format for the SOAP message is well documented (thanks to .NET's generated default page), but customers are getting hung up on converting that into code.  I think that the benefit of client side SOAP libraries will become more apparent with the spread of things like WS-I, in that the libraries should hide some of that complexity (I hope!), but for now, the benefit's not that great.  The other part of the problem is in processing the messages you receive: how do you ensure that they're valid XML?  So you could possibly get some savings on the transmit side, but I think that you'd be back to DOM or SAX on the receive side. 

LOL on the 2nd paragraph.  I actually feel like I should defend WSDL, but it's after 5 PM, it's Friday, and I don't understand WSDL myself :-)

Working with Complex Data Types in an XML Web Service - Part 1. XML Web Services enable the exchange of complex data types, serialized as XML. Complex data types, such as ADO.NET DataSets and custom classes can be serialized as XML and either sent to the XML Web Service as an input argument, or returned from the XML Web Service as the result. In this article, the author builds an XML Web Service and a consumer Web application.[Sam Gentile's Radio Weblog]

This is a fine article on .NET serialization, but my pet peeve is that once again, someone is talking about exposing ADO.NET DataSets over a Web Service interface.  AFAIK, this will not interop with any other SOAP toolkit, I remember at the last WebServices DevCon, someone demoed a sample that did exactly this and Simon Fell and Sam Ruby (maybe others too) jumped all over the presenter.  What's this xmlns:msdata="urn:schemas-microsoft-com:xml-msdata"?  Is it a documented schema? 

The thing with doing web services is that the absolute biggest benefit, in my mind, is interop.  My employer has spent the last year putting a web service wrapper around our existing COM based application.  Out of the 4 early adopters I've worked with, 3 are using Java and Apache SOAP.  These are customers that we were previously shut out of because they refused to run Windows in their data center, and the Java-COM bridges out there were slow or buggy, or both.  Before you go slapping a [WebMethod] on their methods and start tossing DataSets out on the wire, ask yourself: why?  If what you build will operate only on a single platform, then why not use Remoting, or RMI, or some other method to do distributed computing.  If Interop is a problem with every other distributed computing platform.  I can't think of a reason for SOAP to exist. 

Actually, I have another question about DataSets and remote interfaces.  Even if it would interop, do you really want to go exposing raw data sets out of your interface?  I'm not sure that this is a best practice in the first place.