Chapter 26: XML Web Services

This chapter begins with a short history of multi-tier architecture and network operating systems, a discussion of the early days of the network-as-the-computer, and a discussion of where system architecture is heading today. (The reason for this diversion is to understand the rationale behind Web Services.)

Next, this chapter looks at a sample Web Service, and walks through making it accessible to the Internet as well as accessing it from a client application - both with the Visual Studio IDE and using command-line tools. From there, the chapter moves on to a key feature of Web Services, the Service Repository, Discovery, and Universal Description, Discovery, and Integration (UDDI) features that enable remote programmers to correctly access Web Services.

Finally, the chapter delves into more in-depth topics during the discussion of the four namespaces found in the .NET Framework class library (System.Web.Services, System.Web.Description, System.Web.Services.Discovery, and System.Web.Services.Protocols) that deal with Web Services and how to utilize them with Visual Basic 2005. Moving on, the chapter discusses topics such as security, transactions, and the downsides of any distributed architecture (including any downsides associated with the Web Services model), followed by a short discussion of where you go from here and how you get there.

Introduction to Web Services

A Web Service is a means of exposing application logic or data via standard protocols such as XML, or, more specifically, SOAP (Simple Object Access Protocol). A Web Service comprises one or more functions, packaged together for use in a common framework throughout a network. This idea is illustrated in Figure 26-1, where Web Services provide access to information through standard Internet protocols, such as HTTP. By using a Web Services Description Language (WSDL) contract, consumers of the Web Service can learn about the structure of the data the Web Service provides, as well as all the details about how to actually consume it. A WSDL is a description of the remote interface offered from the Web Service.

Figure 26-1

This simple concept provides for a very wide variety of potential uses by developers of Internet and intranet applications alike, as presented in Figure 26-1. Today, in many cases, the Web Services model is the heart of the next generation of systems architecture because they are all of the following:

• Architecturally neutral - Web services don’t depend on a proprietary wire format, schema description, or discovery standard.

• Ubiquitous - Any service that supports the associated Web Service standards can support the service.

• Simple - Creating Web Services is easy, quick, and can be free. The data schema is human readable. Any programming language can participate.

• Interoperable - Because the Web Services all conform to the same standards, they can all speak to one another.

In basic terms, a Web Service is an object with an XML document describing all of the methods, properties, and events sitting between the code and the caller. Any body of code written in just about any programming language can be described with this XML document, and any application that understands XML (or SOAP) over the assigned protocol (such as HTTP) can access the object. That’s because the parameters you type after the function name are passed via XML to the Web Service, and because SOAP is an open standard.

Microsoft has put a wrapper around all of the XML schemas that support Web Services (including SOAP and WSDL), so they end up looking like .NET or COM objects. The following sections look at how the world views a Web Service, and how Microsoft views Web Services.