The most fundamental problem facing the web services world is how to encourage interoperability. The hype around XML and now SOAP shows how grateful the world is to take even tiny steps in that direction. After all, XML standardizes only the most basic of syntactic constructs for information representation and SOAP does the same (but even less) for protocols.
Interoperability problems are, in my opinion, a fundamental characteristic of the universe. Even if everyone in the world spoke Esperanto, physicists would have different terminology than biologists, biologists will have different terminology than hair dressers, hair dressers will have different terminology than cruise ship captains and so forth. Frequently, we use the same term for multiple different concepts and multiple terms for the same concept. There is no benefit in wishing this away. The best we can do is minimize it. The best we can hope for is to make it possible to map between non-standard constructs. The easier the mapping is, the lower the price of integrating two systems that were not designed to be intereoperable.
In application-level networking, there are three basic things to be standardized
It is possible to standardize addressing and this is what the Web does. The Web's addressing mechanism is the URI. SOAP also uses URIs but the URIs are only used to get to endpoints. In every deployed SOAP web service that I know of, the addresses for individual data objects go within the SOAP message as a parameter. For instance, consider a standard web service call (in a dynamically, not statically typed language):
stockservice = new WebServiceProxy("http://...")
stockservice.getStockQuote("IBM")
This means that you are trying to get the stock quote for the IBM resource. A URI-centric way of doing the same thing would look more like:
stockservice = new WebServiceProxy("http://...")
IBM_endpoint_URI = stockservice.getStockEndpoint("IBM")
IBM_endpoint = new WebServiceProxy(IBM_endpoint_URI)
IBM_endpoint.getStockValue()
As you can see, SOAP toolkits are typically not well designed for this (it takes twice as many lines to accomplish the same thing). This is just as bad in a statically typed toolkit. WSDL will not allow you to statically declare that getStockEndpoint will return a particular service type, so you have no choice but to go through the extra step that converts a URI into an endpoint.
Things are even worse on the server side. Most toolkits do not allow you to dynamically associate and endpoint with a URI. For instance if you used Microsoft's web services code in ASP, you would have to basically put an actual ASP file at /stocks/IBM and another one at /stocks/MSFT etc. If a new stock came into existence you would have to copy the ASP file again. To delete a stock you would have to delete an ASP file. If stocks are being created and deleted every minute then you would have to find some way to automate that process. When you wanted to update the ASP, you'd need to find a way to propogate your changes to all of the copies. If you know of a better way to do this within Microsoft's Web Services toolkit I would like to hear about it!
If you work at the HTTP level rather than the SOAP level, then there is no problem. Dynamically generating resources is trivial using CGI, ASP, PHP, etc. You can just look at the query_string environment variable.
In order to simplify life, every SOAP service I have ever seen uses parameters to do a form of implicit addressing. The important thing to understand is that this implicit addressing is completely proprietary and will vary in its form from one web service to another. One will use UUIDs. The next will use numbers, like purchase order numbers. The next will use names. etc. It is unfortunate that SOAP toolkits require programmers to choose between ease of use and standardization!
The next issue is to standardize the methods. Application protocols like HTTP and SMTP do standardize methods. Layer 6 protocols like SOAP do not. This means that when you communicate with an HTTP-described resource, you know for sure that GET will work. DELETE, PUT and POST might also work. When you contact a SOAP service you have no way of knowing what methods it supports and which parameters to use for implicit addressing. Even with a WSDL, there is no way that software will know how to use the methods without prior agreement specific to that service.
The insight exposed in the HTTP 1.1 protocol is that if you choose the right methods, you can standardize them and yet still solve a tremendous variety of different problems. Basically you need methods that correspond to the "CRUD" concept: Create, Retrieve, Update, Delete. In HTTP they are called POST, GET, PUT, DELETE.
I've said how HTTP standardizes the first two. It doesn't standarize the data structures you can pass back and forth. Neither does SOAP. No protocol could pre-determine the complete scope of things that people would want to to talk about. Such a protocol would quickly become obsolete. It would be like a human language that never added new words or phrases.
So in the end, HTTP standardizes two of the three things, but still it fails to achieve effortless interoperability. I did say from the beginning that this was impossible! Nevertheless, HTTP has a couple of big advantages over SOAP when it comes to interoperability.
First, HTTP separates the standardization of the data from from that for the methods to operate on it. That means that even services that have no interest in standardizing behaviour can share the standardization of data. Consider the most basic example. An HTTP resource could consist of only an integer. An Excel spreadsheet could address the integer to combine it into a calculation without even knowing what it means, where it came from, or what would happen if it were deleted or overwritten. In other words, it could work with partial rather than complete understanding. Similarly a sophisticated content management system might generate RSS documents for each page. Even systems that have no knowledge of the content management system's workflow could work with the addressed RSS.
Second, by "pre-standardizing" two of the three issues there is just less to think about in formal standardization processes. You can get quite a distance by just combining the existing HTTP addressing scheme with pre-existing XML vocabularies.
Third, by pushing all of the interoperability problems into the message payload, HTTP allows you to focus all of your effort on that one level. Here are some of the tools we can throw at that level: