Have you ever fished information out of web pages? It's uuuugly. You have to use LWP to fetch the page, possibly faking up a GET or POST query with form data, then either regexps or one of the HTML parsers to extract your information. It's incredibly brittle: if the remote end decides to pretty up their web site, they can break your extraction code.
Web services at its most basic is a way to offer information over the web for another computer to consume, without the fragility of HTML parsing. Essentially you're running an RPC (remote procedure call) server, where the server and client communicate using HTTP and encode parameters and return values in XML. HTTP is good because it's well known, there are libraries for it, and firewalls can deal with it.
SOAP and XML-RPC are the two existing protocols for web services. SOAP is the more complicated one, going through the W3C standards process. It's got Big Company backing (MS, IBM, etc.). XML-RPC provides bare minimum functionality, and as a result is easier to implement and not nearly so appealing to the Big Companies. XML-RPC is a stable, set, standard, untortured by the W3C.
Big Business likes SOAP because the "vision" for web services is of companies talking to companies, exchanging product info, purchases, inventory information, etc. through SOAP. On top of SOAP, then, they want WSDL (Web Services Definition Language) to describe the APIs callable through SOAP, and UDDI (Universal Discovery, Description, and Integration) to describe the services offered through SOAP so that companies can search for specific types of services. All these four-letter acronyms involve beaucoup XML, of course.
The "vision" is pretty futuristic. I've heard comments that perhaps it's too geekly optimistic, in that it doesn't actually allow for humans to be involved in all of this stuff. Normally purchases and other decisions involve a lot of human decision making and lots of internal document transfers, which UDDI et al. may not be planning for. So the jury's still out on whether WSDL+UDDI are the way to go, not that any of the alternatives seem particularly destined for success.
Web services, and in particular SOAP and WSDL, are going to see more life soon when Microsoft starts releasing operating systems featuring .NET. SOAP and WSDL will be integrated into the programming environment, so that you can (in Microsoft terms) drag a WSDL definition to your project and have a class created to access the service described by WSDL. I think they're still planning to keep COM for RPC between processes on the same system, but for cross-system RPC it's all SOAP, baby.
There is quite a bit about SOAP and XML-RPC at the Open Source Convention, mostly in the XML track. We've even got Don Box, co-author of the SOAP spec, to talk about mistakes and mishaps in the implementations of SOAP. In the Perl conference we've got Randy Ray of Redhat talking about some of his work to extend XML-RPC, and Paul Kulchenko to talk about his fantastic module, SOAP::Lite. (If you haven't played with SOAP::Lite, check it out. Wowie). We even have Activestate folks talking about their work to integrate Perl into .NET, which will include their system for generating WSDL for Perl-based SOAP services.
--Nat
