An Introduction to Web Services

Web services are new types of web applications. They are self-contained, modular programs that can be published, found, and called over the web. They perform functions that can range from something as simple as validating a credit card to updating hotel reservations. After a web service is deployed, users, applications, and other web services can invoke functions (called web methods) that you build within the web service. Still seem like it's too good to be true? Think again. Web services are currently being used in Microsoft's My Services and Passport initiatives. The Passport authentication service is a self-contained web service that exposes an authentication scheme allowing other developers and applications to validate a user's credentials from one location. What this means is that if every developer used the Passport authentication service, it would eliminate the need for ever having to program your own login page.

So what makes up a web service? The basic framework of a web service lies within its platform. Platform, you ask? Web services, unlike their predecessors (RPC, CORBA, and DCOM), rely on open standards. These standards are outlined next:

• XML: The Extensible Markup Language (XML) is the meta language used to write specialized languages to articulate interactions between clients and services. Web services use XML and XML schema to define the data used within web services.

• SOAP: The Simple Object Access Protocol (SOAP) is a protocol specification that defines a uniform way of passing XML data between networks. Think of SOAP in terms of HTTP. With HTTP, a user requests a page (usually by typing in the HTTP address), and a response is returned in the form of a website. The protocol that the website was delivered with was HTTP. SOAP, on the other hand, is the protocol used to define how objects are accessed and transferred across networks, typically packaged using XML within a SOAP envelope "wrapper." A user or service makes a SOAP request and a response is returned, as is the case with HTTP.

• HTTP: The Hypertext Transfer Protocol (HTTP) drives how we access information on the web. Web services use SOAP in conjunction with HTTP. Because HTTP is the protocol for accessing information on the web, SOAP can use HTTP to deliver the "wrapped" XML messages in a universal, operating system independent, and server technology agnostic format.

• WSDL: The Web Services Definition Language (WSDL) provides a way for web service providers to describe how and what their web services do, where they reside, and how to invoke them. You will use WSDL in more detail later in this chapter.

• UDDI: The Universal Description, Discovery, and Integration service (UDDI) provides a mechanism for clients to dynamically find other web services. Using a UDDI interface, applications can locate and use other web services. You can think of UDDI as a DNS for business applications or web services.

As you can see, the foundation for web services lies in open standards such as XML, SOAP, HTTP, WSDL, and UDDI. But how do these components make up the web services architecture? Figure 30.1 sheds some more light on the subject.

Figure 30.1. XML, SOAP, HTTP, WSDL, and UDDI are all key components in the web services architecture.

The building blocks of web services are squarely rooted in open source standards such as XML, SOAP, HTTP, WSDL, and UDDI. But how does one use these standards to create one's own web services? For the most part, the development of web services is up to you. More specifically, web services are created by your language of choice in VB.NET, C#, ColdFusion, and more. How you expose, consume, and discover the web service once it's created is ultimately up to the standards mentioned in Figure 30.1.