I've been working a lot with XML and Web Services over the last few years. Web Services were to become the next wave of web development, but so far have failed to take the world by storm. I don't know all of the reasons, but can help to shed some light on the matter (sorry for the long post, if you are in a hurry).
SOAP is RPC
SOAP, as you probably know, is an HTTP-based (I know, you can run it also on other protocols) for remote procedure calls (RPC). Let me recap where SOAP came from. Some friends of Microsoft (Don Box, in particualr) figured out that DCOM was a mess to use with firewalls, so they suggested to have an external web server to communicate with an internal one, which in turn will call COM objects. This was in the Windows DNA days....
As Joel Spolsky puts it in Joel on Software (page 129), accessing "objects on another computer as if they were on the current computer, sounds logical. Right? Wrong." The issues with "availability, latency, and reliability" can cause a lot of harm. "Conclusion: The next time someone tries to sell you a programming product that lets you access network resources the same way as you access lcoal resources, run full speed in the opposite direction". This guy is smart!
Now the problem with SOAP is that most implementations (in Java, Delphi native Win32, .NET...) bind it to the language and make it transparent. Beside the problems mentioned above (which, in my experience, are relevant and cause you to write a lot of extra code for real world apps), the other issue is the strongly bound interfaces you end up with. Instead of strongly-coupled classes in an application (which make it hard to change), we have strongly-coupled applications around the world, which is a real mess. If a server expects a parameter of a given type and returns a complex data structure, any minimal change in these structures will break the interface contract (published in your WSLD file). You'll either have to maintain many different versions of your servers forever or break or potentially break hundreds of clients accessing your code.
From SOAP to REST
Also, processing SOAP-based data structures is not always the simplest operation (if you've seen some of those deeply nested multi-layer structures, like for example Amazon-WS ones, you will know what I mean). So the idea many have come up with to overcome some of these problems is to actually move plain XML-data (an encoded string for SOAP and WSDL) or use an XML-based attachment (like ebXML suggests, for example): you end up not really using SOAP while you keep using it. Is it better? Yes, I think so (and I'm not alone, for sure). Is it the best we can do? I doubt it.
If you really want to move XML and write your code so that you know you are accessing a remote HTTP-based service and support all Joel suggests in an open and formal way, than you might be ready for REST-based solutions. REST (Representational State Transfer) in most cases uses direct HTTP calls, with the request parameters as plain HTTP parameters (like a URL) instead of a (messy) SOAP Envelope. The result is a plain XML document, with all the data you need. You might think I'm naive, and this is not how the real-world works. I think the opposite is true. One of the largest organizations based on Web Services is Amazon, where sellers, resellers, and buyers contribute info to the portal. Thousands of them. And, according to Amazon itself, over 80% of the third-parties use the REST approach (an XML-RPC approach) over SOAP. I'm one of them: having tried both solutions, my bookstore uses the far simpler REST solution. If you use XSLT for processing the result (like I often do, and I do it for the books page), a plain XML document is far better than one wrapped in a SOAP envelope.
Is REST simple to implement in Delphi? You bet! The code is simpler, it is more cross-platform (Linux, Win32, and .NET, same client code!), and it is easier to make it robust than the SOAP equivalent. This is a sample line:
strXml := IdHTTP1.Get (‘
http://blogs.borland.com/MainFeed.aspx’);
Surprised? The most perfect example of REST and XML-RPC is the use of ATOM and RSS feeds! And this is something that works, is simple to manage both on the server and on the client, is loosly coupled (even if vaguely defined, at times), and is flexible. That's why I like it.
REST is KISS
I could add a lot more rationale to why I prefer REST above SOAP , but I'll stop here. You'll find a lot browsing the web (but little on official sites, maybe they are scared or just they don't get it). If you want actual examples of REST (and SOAP) you can refer to Mastering Delphi 2005 (seems like a shameless plug, but the source code is actually free, see Chapter 23 for the demos). And one final thing: Keep It Simple, Stupid! I wonder if the standard body groups will ever realize this... but I guess they like making money by selling uselessly complex solutions, rather than simple ones.