I do not have a problem with XML - in fact, I use it all the time, especially with XML schema. But most XML documents are nowadays not aimed for human consumption, but rather are targeted at editing with XML-aware tools. For instance, I'm using Intellij's XML-aware editor for my XML editing, and it's just great. Since it's schema-aware, it helps you enforce schema constraints in a document. I'd never go back to plain text or property files.

But my point in this article was not so much XML, or even SOAP. I tried to point out that most Web services out there tend to be simple: They comprise mostly of sending a simple request, and receiving a simple response. I think there are good reasons to believe that most Web services will stay simple for the foreseable future. And if you write a Web service that consists of a simple request/response pattern, would you use SOAP? Or would you just send that message exchange over HTTP? And if you did use SOAP, would you follow a document-style service, or would you model that service as a series of RPCs?

Again, I'm talking here only of simple services. If you have only one request-response exchange (e.g., I send you a city name, and you send me back a document that describes the current weather there, or I send you a company ticker symbol, and you send back a document with that company's financials, etc) -- does it make sense to define an API, create a WSDL document, etc, that consists of just that simple pattern? Or would it not be better to just write a 1-page HTML spec of how to invoke the service?

Of course, this issue goes beyond just design simplicity. That decision can have a big long-term ramification for an application: If you did use RPC-style SOAP, and did create a WSDL, and handed that WSDL to your customers, what will your customers likely do?

They will likely use a tool to generate a set of Java (or C# or whatever) classes from that WSDL. And they will then compile those classes. And once they have those classes, they will hand them to their developers and say, Here, use these classes to invoke this Web services.

And their developers will go ahead and instantiate those classes, and use those objects *as if those objects were regular, local objects.* The problem is that that won't work. The reason is that those objects are *not* local - there is somewhere a network in between. And, in the words of Jim Waldo (Jini's chief designer), the fact that there is a network in between makes all the difference in your life.

When you invoke methods on those objects, those invocations will fail in unpredictable ways, because the network is not going to be reliable all the time. Messages will get lost, a call may take forever to return, etc., Of course, you can try to handle those issues as best as you can. I know that *you* will, but will your developers do the same?

I'm not saying it can't be done. What I'm saying is that it's fairly seductive to think of those WSDL-to-Java generated objects as regular, local objects. My experience is that only developers who have been beaten by the network a couple of times appreciate the difference between local and remote object invocations. Again, if you do appreciate that difference, by all means, use whatever tool you like, SOAP, XML + HTTP, etc.

But if you do have to deal with customers who may be less experienced, it is sometimes good to expose the network's frailties to them, so that they must address those failure modes explicitly in their applications. In that case, specifying a protocol via the simplest possible response-request messages makes sense, because that makes it easier to debug and monitor an application.