• Publishing the service - once the service is available, how do clients find or discover the Web Service? Just as we have web sites such as MSN and Yahoo! that publish the location of web sites, shouldn't we have something similar for Web Services?
• Describing the service - how do consumers of the service call the service? For example, what protocol does the service support? How does the protocol serialize data? What data types does the service support? Does the Web Service require a schema?
• The network - one of the problems with other protocols such as DCOM, RMI, or CORBA is that they use TCP/IP ports that are closed or restricted, or in some cases require additional software or a specific operating system. Administrators use firewalls to lock down their Internet exposure, usually leaving only ports 80 and 443 left open for HTTP and HTTPS traffic respectively. If the required ports are not accessible, or are blocked, building successful distributed applications is more difficult. Additionally, most web applications are an amalgamation of technologies and operating systems.
• The development framework and tools - given some application logic, is there a common development framework - as opposed to a choice of language, or even platform - that we can use to easily create Web Services?

These challenges are not particularly difficult to overcome. In fact, the work done by Microsoft, IBM, Intel, and HP (to name just a few), has meant that many of these issues have already been addressed through development frameworks (such as Microsoft .NET) or through specifications that have been submitted to standards organizations.

The specifications form part of the solution to the problems we listed. Rather than each company driving its own view of the world, they can agree on a single specification and provide an implementation of it. Standards-based specifications work especially well at the network level since each application can then leverage all the features provided by its native platform.

Let's review some of the specifications.

Specifications
To solve these types of integration, protocol, discovery, and description problems, Microsoft is working with companies that believe that Web Services are the key to building the next generation of web applications. The specifications they are creating fall into three categories:

• Discovery - there are two specifications that address the discovery of Web Services. Universal Description, Discovery and Integration (UDDI) - see http://www.UDDI.org for more details - is a directory that we can use to publish and discover public Web Services. Another specification, DISCO (abbreviated from Discovery) can also be used to group common services together on a server, and provide links to the schema documents the services it describes may require. We'll discuss both of these in the next chapter.
• Description - Web Service Description Language (WSDL), another Microsoft co-submitted W3C specification, defines an XML grammar for describing Web Services. This description includes details such as where we find the Web Service (its URI), what methods and properties that service supports, the data types, and the protocols used to communicate with the service. Tools can consume this WSDL and build proxy objects that clients use to communicate with the Web Services. We'll talk more about what proxies are and how to build them in the next chapter. The WSDL specification is available at http://www.w3.org/TR/wsdl.
• Protocol - as we've already mentioned, SOAP describes an extensible XML serialization format that uses HTTP to transport data. We will discuss SOAP in this chapter, but not in any great detail. The specification is available at http://www.w3.org/TR/SOAP.

Using Discovery, Description, and Protocols
When we want to build a Web Service, UDDI, DISCO, and WSDL are, for the most part, technologies to be used at design time. Here's a scenario for using a Credit Card Validation Web Service:

Credit Card Validation Web Service

The steps here are as follows:

1. We communicate our interest in a Credit Card Web Service to a UDDI node (nodes maintain the available services), either through UDDI's public Web Services, or through the browser.
2. UDDI responds with a listing of credit card services (if they're available - we'll assume they are).
3. The list of services returned by UDDI provides us with URIs that map to either DISCO or WSDL documents. We'll use the DISCO documents. In addition to the programmatic details provided by UDDI, we can also discover documentation for the Web Service at one of the UDDI.org nodes. Hopefully the provider of the service would provide additional details about what the service offered.
4. We follow the URI for the DISCO document. Within the DISCO document we find a listing of the location of WSDL documents.
5. After parsing the DISCO document, we follow the URI for the WSDL document related to the Credit Card Validation Web Service.
6. We parse the WSDL document, and build a proxy object based on the details provided within the WSDL.

Although the DISCO and the WSDL documents can reside on the same server as the Web Service, it is not a requirement. The DISCO document can be stored anywhere since it is only responsible for linking to WSDL documents. Similarly the WSDL document can exist anywhere as long as it accurately describes the Web Service (the description includes the end point of the Web Service).

We now have a proxy object that we can use locally within our code, which looks and feels like the application logic it represents - it exposes the same methods and properties, but rather than the application logic executing locally, the proxy encapsulates the calls to the Web Service. We're now ready to use our Web Service at runtime.

We can build an application that uses the proxy (we'll call it the CreditCardWebService proxy). The proxy encapsulates all the details of how to use the remote Web Service. From our perspective, we're working with a local object. If the company providing the Credit Card Web Service decides to add some more functionality to the Web Service, it can simple update the WSDL. If it only adds new members, and don't change the signatures of existing members, our proxy will continue to work fine.

A lot of companies, including Microsoft and IBM, believe strongly that Web Services will be the next great enabler of the Internet. Support for Web Services is one of the most important features in ASP.NET. In the next chapter we'll look at how we can use the services we build. First though, we need to discuss how we can use ASP.NET to build Web Services.

Building ASP.NET Web Services

Like ASP.NET Pages, ASP.NET Web Services are compiled on their first request, and support a code behind model, in which the code for the Web Service can reside in a pre-compiled .NET Assembly.

In this section we'll discuss the programming model. Our emphasis will be how we expose application logic as a Web Service, rather than upon the application logic itself.

• Publishing the service - once the service is available, how do clients find or discover the Web Service? Just as we have web sites such as MSN and Yahoo! that publish the location of web sites, shouldn't we have something similar for Web Services?
• Describing the service - how do consumers of the service call the service? For example, what protocol does the service support? How does the protocol serialize data? What data types does the service support? Does the Web Service require a schema?
• The network - one of the problems with other protocols such as DCOM, RMI, or CORBA is that they use TCP/IP ports that are closed or restricted, or in some cases require additional software or a specific operating system. Administrators use firewalls to lock down their Internet exposure, usually leaving only ports 80 and 443 left open for HTTP and HTTPS traffic respectively. If the required ports are not accessible, or are blocked, building successful distributed applications is more difficult. Additionally, most web applications are an amalgamation of technologies and operating systems.
• The development framework and tools - given some application logic, is there a common development framework - as opposed to a choice of language, or even platform - that we can use to easily create Web Services?

These challenges are not particularly difficult to overcome. In fact, the work done by Microsoft, IBM, Intel, and HP (to name just a few), has meant that many of these issues have already been addressed through development frameworks (such as Microsoft .NET) or through specifications that have been submitted to standards organizations.

The specifications form part of the solution to the problems we listed. Rather than each company driving its own view of the world, they can agree on a single specification and provide an implementation of it. Standards-based specifications work especially well at the network level since each application can then leverage all the features provided by its native platform.

Let's review some of the specifications.

Specifications
To solve these types of integration, protocol, discovery, and description problems, Microsoft is working with companies that believe that Web Services are the key to building the next generation of web applications. The specifications they are creating fall into three categories:

• Discovery - there are two specifications that address the discovery of Web Services. Universal Description, Discovery and Integration (UDDI) - see http://www.UDDI.org for more details - is a directory that we can use to publish and discover public Web Services. Another specification, DISCO (abbreviated from Discovery) can also be used to group common services together on a server, and provide links to the schema documents the services it describes may require. We'll discuss both of these in the next chapter.
• Description - Web Service Description Language (WSDL), another Microsoft co-submitted W3C specification, defines an XML grammar for describing Web Services. This description includes details such as where we find the Web Service (its URI), what methods and properties that service supports, the data types, and the protocols used to communicate with the service. Tools can consume this WSDL and build proxy objects that clients use to communicate with the Web Services. We'll talk more about what proxies are and how to build them in the next chapter. The WSDL specification is available at http://www.w3.org/TR/wsdl.
• Protocol - as we've already mentioned, SOAP describes an extensible XML serialization format that uses HTTP to transport data. We will discuss SOAP in this chapter, but not in any great detail. The specification is available at http://www.w3.org/TR/SOAP.

Using Discovery, Description, and Protocols
When we want to build a Web Service, UDDI, DISCO, and WSDL are, for the most part, technologies to be used at design time. Here's a scenario for using a Credit Card Validation Web Service:

Credit Card Validation Web Service

The steps here are as follows:

1. We communicate our interest in a Credit Card Web Service to a UDDI node (nodes maintain the available services), either through UDDI's public Web Services, or through the browser.
2. UDDI responds with a listing of credit card services (if they're available - we'll assume they are).
3. The list of services returned by UDDI provides us with URIs that map to either DISCO or WSDL documents. We'll use the DISCO documents. In addition to the programmatic details provided by UDDI, we can also discover documentation for the Web Service at one of the UDDI.org nodes. Hopefully the provider of the service would provide additional details about what the service offered.
4. We follow the URI for the DISCO document. Within the DISCO document we find a listing of the location of WSDL documents.
5. After parsing the DISCO document, we follow the URI for the WSDL document related to the Credit Card Validation Web Service.
6. We parse the WSDL document, and build a proxy object based on the details provided within the WSDL.

Although the DISCO and the WSDL documents can reside on the same server as the Web Service, it is not a requirement. The DISCO document can be stored anywhere since it is only responsible for linking to WSDL documents. Similarly the WSDL document can exist anywhere as long as it accurately describes the Web Service (the description includes the end point of the Web Service).

We now have a proxy object that we can use locally within our code, which looks and feels like the application logic it represents - it exposes the same methods and properties, but rather than the application logic executing locally, the proxy encapsulates the calls to the Web Service. We're now ready to use our Web Service at runtime.

We can build an application that uses the proxy (we'll call it the CreditCardWebService proxy). The proxy encapsulates all the details of how to use the remote Web Service. From our perspective, we're working with a local object. If the company providing the Credit Card Web Service decides to add some more functionality to the Web Service, it can simple update the WSDL. If it only adds new members, and don't change the signatures of existing members, our proxy will continue to work fine.

A lot of companies, including Microsoft and IBM, believe strongly that Web Services will be the next great enabler of the Internet. Support for Web Services is one of the most important features in ASP.NET. In the next chapter we'll look at how we can use the services we build. First though, we need to discuss how we can use ASP.NET to build Web Services.

Building ASP.NET Web Services

Note: ASP.NET Web Service files are simply source files (that are part of an ASP.NET application) with a .asmx file extension.

Like ASP.NET Pages, ASP.NET Web Services are compiled on their first request, and support a code behind model, in which the code for the Web Service can reside in a pre-compiled .NET Assembly.

In this section we'll discuss the programming model. Our emphasis will be how we expose application logic as a Web Service, rather than upon the application logic itself.