10.1 Defining Web Services

In its working draft, "Web Services Architecture Requirements" (http://www.w3.org/TR/2002/WD-wsa-reqs-20020819), the W3C Web Services Working Group lists the following definition:

A Web service is a software application identified by a URI, whose interfaces and bindings are capable of being defined, described, and discovered as XML artifacts. A Web service supports direct interactions with other software agents using XML based messages exchanged via Internet-based protocols.

From this, you can isolate several key features of the Web Services architecture.

As you'll see later in this chapter, although all of these features are present in .NET, some of them are optional. In particular, the terms definable, describable, and discoverable are significant. As you'll see in a moment, three specific Web Services standards are responsible for the realization of these three features; they are W3C XML Schema, WSDL, and UDDI, respectively.

Web Services is built on a variety of standards, some of which actually serve multiple purposes. You've already seen some of them in other parts of this book, and others will be introduced for the first time here.

10.1.1 HTTP

Most web services, although by no means all, use the Hypertext Transfer Protocol, or HTTP, as their transport mechanism. The reason for this goes back to the roots of Web Services.

Web Services was conceived as a way to use the Internet, and specifically the World Wide Web, to perform more sophisticated tasks than it was originally intended for. The Web did support some rudimentary abilities to perform distributed processing via its Common Gateway Interface (CGI) protocol, but CGI was really intended to act as a gateway to other applications running on a web server or externally. Granted, these applications could do some interesting things, but their input was limited to HTTP POST or GET variables, and their output was limited to HTML or other formats that a web browser could interpret.

Web Services grew out of the idea that input and output could both be specified in XML, and the processing could be done by an application other than a web server. To get around the firewalls that some corporations use to block other types of traffic, many web services use the Internet port reserved for HTTP traffic; in fact, Web Services communication is HTTP traffic.

Although, as the W3C's definition makes explicit, a web service is uniquely addressable via a URI, a single web service may provide multiple functions. The actual function being invoked is determined at a higher-level protocol.

10.1.2 XML

XML is the basis for all the Web Services standards and protocols. Web Services uses XML as its language of choice because XML's strengths provide some very important Web Services features.

• XML provides a flexible, customizable format for structured data, meaning that many sorts of functions can be invoked, consuming and producing many sorts of data.

• XML can easily be transformed into an unlimited number of other formats, meaning that upstream processors need not be altered in order to use them in a Web Services environment.

• XML is license-free and platform independent, meaning that anyone can implement Web Services applications on any hardware platform without paying royalties.

10.1.3 XML Schema

XML Schema, which I introduced in Chapter 8, is used to define Web Services messages. The SOAP envelope, as you saw in Chapter 9, uses XML Schema types as the basis for its data encoding mechanism. XML Schema is also ideally suited for use in distributed applications because it guarantees that an XML request generated by a client will meet all the constraints required by the server that processes the request.

10.1.4 SOAP

SOAP, which I introduced in Chapter 9, is the serialization and messaging format used in .NET Web Services. As I also mentioned in Chapter 9, there are others, such as XML-RPC, but .NET does not support any other serialization formats natively.

10.1.5 WSDL

The Web Services Description Language, or WSDL, serves as a standard language for describing a particular web service. WSDL describes the public interface to a web service. Users of CORBA, another distributed application framework, may be familiar with Interface Definition Language (IDL); WSDL serves a similar function. In addition to describing the interface, WSDL also describes the binding of services to lower level protocols.

The WSDL note is located at http://www.w3.org/TR/2002/WD-wsa-reqs-20020819.

10.1.6 UDDI

Universal Description, Discovery, and Integration, or UDDI, is the mechanism that provides for the discovery of available web services. The UDDI schema is fairly complex, and I'll describe it in detail—along with all the other relevant XML schemas—in the following section. In addition to the XML schema, UDDI includes the infrastructure necessary for web service discovery. Access to this infrastructure is itself implemented in the form of web services.

The various UDDI specifications are located at http://www.uddi.org/specification.html. And the major players each have UDDI documentation available on their own web sites; for example, IBM has http://uddi.ibm.com/, and Microsoft has http://uddi.microsoft.com/.

10.1.7 Where to Learn More About Web Services

There are many new books about Web Services, some of them good. For a good introduction to Web Services, although a bit Java-centric, check out Web Services Essentials (O'Reilly), by Ethan Cerami. For a more .NET-oriented book, look at NET Web Services: Architecture and Implementation by Keith Ballinger (Addison Wesley). If you are developing your projects with Visual Studio .NET, you may want to read some of the later chapters of Building Web Services and .NET Applications, by Lonnie Wall and Andrew Lader (McGraw-Hill).