Sea of acronyms
Microsoft has positioned Web Services as a key focus of .NET, and its rivals including Google, IBM and Sun place an equal importance on them. In this article, I’ll be examining what Web Services are, what they’re useful for and why you might want to build them. The first problem is one of nomenclature – Web Services are in danger of drowning in a sea of acronyms, like XML, SOAP and WSDL. I spent some time querying the most popular search engines for the terms I’ll be using in this article, and when I entered “Web Services” I was rather shaken when Google returned 442 million hits. For comparison, MSN Search returned a mere 241 million hits and Ask.com a feeble 166 million. I haven’t had time to review all these hits, but you can see how hot this topic has become.
Before looking at how to build a Web Service, we need to understand what one is. The World Wide Web Consortium (W3C) defines a Web Service as “a software application identified by a URI, whose interfaces and bindings are capable of being defined, described, and discovered as XML artefacts”. The definition then explains that a Web Service interacts with clients by sending XML-based messages, exchanged via internet-based protocols. But what exactly does that all mean? Well, first it says a Web Service is just an application that clients can access by typing a URI (such as http://host/webservice/service.asmx) into a web browser, either over the internet or via an internal corporate intranet. A Web Service’s client communicates with the service via XML-based messages rather than by some binary protocol specific to that application, as is the case with earlier systems. Finally, the “internet protocols” part of the definition means these XML messages are sent using HTTP. In effect, this turns HTTP into a higher-level, firewall-passing transport protocol (Microsoft’s Jesper Johanssen describes this as morphing it into the Universal Firewall Bypass Protocol).
The functions of Web Services can’t be fully supported using HTTP alone, although you can invoke the service in the first place by an HTTP Post message. For greater flexibility, an extra protocol called SOAP (Simple Object Access Protocol) has been developed, which is used to send messages programmatically between Web Services and their clients. To enable clients and services to communicate effectively, Web Services are formally defined using a description language called Web Services Description Language, or WSDL.
And on top of all this there’s Universal Description, Discovery and Integration (UDDI), which provides directory services that enable businesses both to register new Web Services and to search for existing ones. UDDI was a great idea, and useful when getting the Web Service concept off the ground, but it isn’t used much today. If you need to use a Web Service, you either know where it is already (and therefore don’t need UDDI) or you’re going to use a search engine such as Google to search for it. Even Microsoft’s own UDDI registry at http://uddi.microsoft.com has been closed since the start of this year (see http://tinyurl.com/pehwl for more information), and the URL now redirects to http://tinyurl.com/76wx6.
Web Services vs RPC
At first sight, Web Services might appear to be just a new kind of Remote Procedure Call (RPC), where a client asks a server for something and gets it by return. While there are certainly some similarities, there are also some key differences: