In order for XML Web Services to exist, there needs to be some sort of universal programmatic access. That is, there needs to be some way for an application on one computer to "talk" with an application running on another computer, perhaps across the Internet. This access mechanism really needs to be independent of the operating system or development tools used on either end. Developers using Visual Studio .NET should be able to consume XML Web Services created by developers using a completely different set of tools, on a non-Windows operating system, if necessary.
In addition, to be able to create and consume Web Services, you must have available the following items:
A way to find service providers. Without this, how would you know what XML Web Services are available?
A way to discover services a specific provider exposes. Once you've found the provider, you'll need to know exactly what's available on the server.
A common, extensible service description format. With this, the consumer can determine how to call the service, what parameters to send, and what data to expect in response. Even if you know that a server provides a particular method, what good is it if you don't know what parameters to send or what information it returns?
A common, extensible message format. With this, the consumer can construct a request for data, and the service can respond with the results. You'll need to construct a packet of information containing your request, and the service will do the same with the response. If you both don't format your packets in a mutually agreed-upon format, how will you and the server be able to decipher the information?
A standard way to represent data. With this, Web Service creators and consumers can understand the information going back and forth. Without some standard mechanism for representing text in the request and response packets, how can your code and the server communicate?
In order to see how XML Web Services satisfy these needs, let's start at the end of the list, working backwards from the smallest issue (data representation) to the biggest (determining available providers):
Representing data. Clearly, XML is the solution (they'd hardly be called XML Web Services if they didn't use XML, right?). Because XML is extensible and supports namespaces that allow developers to specify the context for elements within the body of the text, XML makes a perfect solution to the problem of how to transport requests and responses over the Internet. In addition, because XML always consists of text (not binary information), you're guaranteed that XML can pass through firewalls something you can't say for binary-encoded information.
Message format. Because the sender and receiver must agree on a common request/response mechanism, you need some standard XML schema describing the method name, parameters, and so on, when making a method call. The Simple Object Access Protocol (SOAP) specification provides the standard messaging format (for more information, browse to http://www.w3.org/2000/xp/). The SOAP specification indicates exactly how to create the XML request and response packets and has no reliance on any particular transport (although you'll most likely be using HTTP), tools (you'll probably be using Visual Studio .NET), or operating system (we're guessing you'll be using Windows). The SOAP specification only requires XML containing particular elements because it doesn't require HTTP transport, you could just as well create SOAP requests over e-mail or some queuing mechanism.
Service description format. Web Service consumers require some way to determine what messages the Web Service understands. That is, Web Services need some way to document a "contract" that contains information about how consumers can call methods, what parameters the methods expect to receive, and what the methods return. The Web Services Description Language (WSDL) does this job for you. This XML grammar contains all the information your Web Service consumers need in order to communicate with the XML Web Service. Without this information, your consumers would have no idea how to construct method calls to the server.
Finding service providers. How do you find plumbers in your local area? You look in the phone book, of course! It's not so obvious where to look, though, if you want information on XML Web Services. To make it possible for you to find out what's available, a group of companies (including Microsoft and IBM) have crafted Universal Description, Discovery, and Integration (UDDI). This specification provides a mechanism so that Web Service providers can "expose" their services. UDDI isn't part of Visual Studio .NET, but you can take advantage of this service. (See http://www.uddi.org or http://uddi.microsoft.com for more information.)
Table 28.1 summarizes this discussion, listing the requirements and solutions for you.
Table 28.1. In Order for Web Services to Exist and Function, Developers Must Take Advantage of All These Technologies
|Requirement ||Technology/Solution |
|Representing data ||XML |
|Message format ||SOAP |
|Service description format ||WSDL |
|Discovering service providers ||UDDI |