| There's not much new to creating and consuming XML Web Services, in theory. Developers have been using these exact techniques for years but as you'll see, it used to be a lot more difficult than it is now. Doing XML Web Services the Hard Way In a normal SOAP-based Web Service application, the client application is responsible for creating the XML request and the SOAP envelope for transporting this XML across HTTP. On the receiving side, there must be a SOAP listener, waiting for SOAP requests. This listener will open the SOAP "envelope," process the contents, and invoke the appropriate object on the server. It must wait for the object to finish its job and then send the XML result back to the client machine. The client must then parse the XML, retrieving the results from the Web Service. Figure 28.1 diagrams this sort of application. Figure 28.1. Using SOAP the hard way requires careful coding on both the client and the server.
In the pre-.NET days, most developers who wanted to use Web Services in their applications wrote most of this code themselves. It's painstaking work, requiring a good understanding of creating and parsing XML and a careful reading of the SOAP specification. Doing XML Web Services the Easy Way Using Visual Studio .NET and the .NET Framework, creating and consuming XML Web Services couldn't be much simpler. The .NET Framework wraps classes around both the client and server sides of Web Services, so you don't need to know anything about either XML or SOAP in order to create and consume Web Services. As you'll see in the next chapter, exposing a method within a Web Service is simply a matter of adding a procedure attribute to the method, and consuming the Web Service is no more difficult than setting a reference. Figure 28.2 shows how the .NET Framework makes it easier for you to interact with Web Services from within your client applications. Instead of requiring you to create SOAP messages using XML yourself, you simply call methods in the Web Service. The .NET Framework wraps up the SOAP information for you in both directions, so your applications aren't even aware that they're communicating with the server using XML. Figure 28.2. Calling Web Services in .NET still uses XML, but you can simply interact with objects provided by the .NET Framework that hide all the details from you.
TIP If you find that you must consume XML Web Services from a non-.NET client (such as VB6 or Microsoft Office), you can take advantage of Microsoft's SOAP Toolkit 2.0, available at http://msdn.microsoft.com/xml. This toolkit provides a COM object that does much of the work provided by the .NET Framework.
| 
