Web service Directories allows us to locate providers of Web services. They provide a centralized, Internet-accessible location where Web service users (consumers) can easily locate services offered by other companies and organizations. They can be called as "Yellow Pages" of Web services where we can find a list of Web services and their locations. Using these directories we can search and find any Web service based on the type of service we need.

The Universal Description, Discovery and Integration (UDDI ) currently is the de facto standard for cataloging and finding Web services. The UDDI organization created a directory of services, API's etc for participating companies and organizations providing Web services. You can visit the UDDI website to search for Web services. Else, you can use Visual Studio .NET 's web reference feature to search these directories.

Web services Discovery provides the capability to locate Web services. It's a process of locating documents that define a specific service. These capabilities are described in a standard way using the Web Services Description Language (WSDL) which is specifically designed for this. The discovery process allows a Web service user to search and locate the WSDL document. The DISCO (discovery) specification defines the existence of Web services and helps to locate the Web service's WSDL document. DISCO documents are XML based and have a file extension of .vsdisco. The discovery document is a container for two elements, pointers to WSDL document and pointers to other discovery documents. These pointers are in the form a URL.

You can use Visual Studio .NET 's web reference feature which locates the Web services automatically using the discovery process. To do that you need to enter the URL of the discovery document which will initialize the discovery process. Else, use the .NET Framework's disco tool to search for Web service description files.

Web service Description is an XML document that enables Web service capabilities to be described. Using WSDL we can clearly define the Web-addressable entry points in terms of request/response messages. Also this description includes information about the supported protocols and data types processed by the Web service. ASP .NET and the .NET platform provides the support for generation of this WSDL documents from the Web Service assembly when requested.

The standard method of interacting with a Web Service is through the use of a proxy class. Visual Studio .NET and ASP .NET provide tools to generate a Web Service proxy class. The proxy class is similar to the actual Web service but does not contain all the implementation part. With Visual Studio .NET we can generate the proxy class from WSDL documents with it's Web reference feature to locate a Web service which we want to call. After locating the WSDL document we can generate the proxy class using the Add reference button.

Web service Wire Format allow Web services to exchange data and messages. Wire formats describe the method by which Web service request/response messages are encoded and transported between the Web Service and any consumer. The three wire formats supported are : HTTP-GET, HTTP-POST and HTTP-SOAP.

The HTTP-GET protocol encodes Web service operation requests and arguments in the URL of the Web service. This is coded as part of the URL string and any arguments are coded as query string parameters appended to the base URL. The URL specifies the Web addressable entry point for the Web service which is a .asmx file.

The HTTP-POST protocol encodes Web Service operation requests and arguments within the payload area of the HTTP-POST request as name/value pairs. HTTP-POST is similar to HTTP-GET but the difference is HTTP-POST passes parameters within the actual HTTP request header rather than as a query string appended to the URL.

HTTP-SOAP is the default wire format. Based on the SOAP specification it supports the widest range of simple and complex data types. Web service request and response messages are encoded into SOAP message that are included in the payload area of an HTTP-POST message, SOAP messages are encoded in XML using the SOAP vocabulary defined in the specification.

XML provides a standards-based method for describing data. XML is used extensively in building and consuming Web services. XML has the ability to describe data that is highly interoperable among many different systems on the Internet. Using the basic elements of XML we can define simple and complex data types and relationships. XML promotes the ability of Web services to communicate their data efficiently and effectively. It's this XML that ensures a consistent and accurate interpretation of the data when the service and consumer reside on different platforms.

We hear a lot about SOAP these days. Let's take a look what SOAP is and why it is related to .NET. Simple Object Access Protocol (SOAP) is a lightweight protocol for exchange of information in a decentralized, distributed environment. It's an industry-standard message format that enables message-based communications for Web services. It's XML based and consists of three parts, an envelop that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined data types and a convention for representing remote procedure calls (RPC). The capability of SOAP to provide a modular packaging model and encoding mechanisms for encoding data within modules allows it to be used over multiple protocols with a variety of different programming models.

There are optional parts of the SOAP specification and one optional part defines what an HTTP message that contains a SOAP message looks like. This HTTP binding is important as HTTP is supported by almost all operating systems. The HTTP binding is optional, but almost all SOAP implementations support it as it's the only standardized protocol for SOAP. For this reason, there's a common misconception that SOAP requires HTTP. Some implementations support MSMQ, MQ Series, SMTP, or TCP/IP transports, but almost all current XML Web services use HTTP because it is ubiquitous.

A major source of confusion when getting started with SOAP is the difference between the SOAP specification and the many implementations of the SOAP specification. Most people who use SOAP don't write SOAP messages directly but use a SOAP toolkit to create and parse the SOAP messages. These toolkits generally translate function calls from some kind of language to a SOAP message. For example, the Microsoft SOAP Toolkit 2.0 translates COM function calls to SOAP and the Apache Toolkit translates JAVA function calls to SOAP. The types of function calls and the data types of the parameters supported vary with each SOAP implementation, so a function that works with one toolkit may not work with another. This isn't a limitation of SOAP but rather of the particular implementation you are using.

By far the most compelling feature of SOAP is that it has been implemented on many different platforms. This means that SOAP can be used to link disparate systems within and without an organization. Many attempts have been made in the past to come up with a common communications protocol that could be used for systems integration but none of them have had the widespread adoption that SOAP has. That's because SOAP is much smaller and simpler to implement than many of the previous protocols. For example, DCE and CORBA took years to implement. SOAP, however, can use existing XML Parsers and HTTP libraries to do most of the hard work, so a SOAP implementation can be completed in a matter of months. This is why there are more than 70 SOAP implementations available. SOAP obviously doesn't do everything that DCE or CORBA do, but the lack of complexity in exchange for features is what makes SOAP so readily available.

Universal Discovery Description and Integration is like the "Yellow Pages" of Web services. As with traditional yellow pages, we can search for a company that offers the services we need, read about the service offered and contact the company for more information. We can also offer a Web service without registering it in UDDI.

A UDDI directory entry is an XML file that describes a business and the services it offers. There are three parts to an entry in the UDDI directory. The "white pages" describe the company offering the service, like, name, address, contacts, etc. The "yellow pages" include industrial categories based on standard taxonomies the Standard Industrial Classification. The "green pages" describe the interface to the service in enough detail for someone to write an application to use the Web service. The way services are defined is through a UDDI document called a Type Model or tModel. In many cases, the tModel contains a WSDL file that describes a SOAP interface to an XML Web service, but the tModel is flexible enough to describe almost any kind of service.

The UDDI directory also includes several ways to search for the services we need to build our applications. For example, we can search for providers of a service in a specified geographic location or for business of a specified type. The UDDI directory will then supply information, contacts, links, and technical data to allow us to evaluate which services meet our requirements.

UDDI allows us to find businesses we might want to obtain Web services from. If we already know whom we want to do business with but if we don't know what services are offered then we can use the the WS-Inspection specification that allows us to browse through a collection of XML Web services offered on a specific server to find which ones might meet your needs. XML Web Services