|< Day Day Up >|
The Web Service architecture is a service-oriented architecture that enables applications to be distributed across a network or the Internet to clients using any language or operating system. As shown in Figure 18-1, Web Service communications are implemented using existing technology and standards that require no proprietary vendor support. This technology either formed the basis of the Internet or evolved from it. HTTP and XML have been discussed in earlier chapters, but let's take a brief look at them from a Web Services perspective along with TCP/IP and SOAP:
Figure 18-1. Web Service transport
Discovering and Using a Web Service
To use a Web Service, a client must have a description of how to access the service. This information is provided by a Web Services Description Language (WSDL) document that provides the name of the service, the signature of the method(s) that can be called, the address of the service (usually a URL), and binding information that describes how the transport operation will occur. In practical terms, the WSDL information contains the methods that actually call a Web Service. We implement these methods in our client code (as source or a DLL reference) and use them as a proxy to access the service. Section 18.2, "Building an XML Web Service," provides a concrete example of using .NET to retrieve WSDL information and incorporate it into a client application.
Introduction to UDDI
Web sites are identified by a domain name and IP address that are maintained by a distributed network service known as the Domain Name System (DNS). Servers in this network are responsible for controlling e-mail delivery and translating domain names into IP addresses. The combination of DNS and Web search engines enables users to quickly locate Web content. However, neither DNS servers nor search engines provide a formal way of identifying Web Services.
To organize Web Services into a publicly searchable directory, a public consortium (www.uddi.com) comprising hundreds of companies has defined a standard known as Universal Description Discovery and Integration (UDDI). This standard defines a SOAP-based interface that can be used to publish a service or inquire about services in a UDDI-compliant registry. The registry has a business-to-business flavor about it containing information about a company, its services, and interface specifications for any Web Services it offers. Importantly, there is no single UDDI registry. IBM, SAP, and Microsoft maintain the most prominent registries. Users may query each separately by entering a business name or service as a search term. Figure 18-2 provides an overview of the inquiry process.
Figure 18-2. Discovering and accessing a Web Service
The dialog between the client and UDDI registry server is conducted using SOAP messages. Overall, UDDI defines approximately 40 SOAP messages for inquiry and publishing.
UDDI Discovery Example
To demonstrate how to use UDDI, w'e'll look at the SOAP messages sent between client and server as we seek to discover a Web Service that can provide a stock quote. A Web-based UDDI browser (described shortly) sends and receives the messages.
Step 1: Send Discovery Request
For our example, we'll search the UDDI registry provided by Microsoft:
An inquiry may request business information or tModel information. The former contains information about a business, including contact information and a description of services. The tModel structure is much simpler: It consists of a unique key, optional description, and a URL or pointer to a Web page where information for using the service is described. The following message requests a list of tModel keys for companies whose service includes providing a stock quote.
<Envelope> <Body> <find_tModel generic="1.0" maxRows="100"> <findQualifiers/> <name>stock quote</name> </find_tModel> </Body> </Envelope>
Step 2: Registry Service Responds with List of Services Matching Request
A list of tModel keys is returned. These keys are used for the subsequent query:
<soap:Envelope> <soap:Body> <tModelList generic="1.0" operator="Microsoft Corporation" > <tModelInfos> <tModelInfo tModelKey="uuid:7aa6f610-5e3c-11d7-bece-000629dc0a53"> <name>Stock Quote</name> </tModelInfo> <tModelInfo tModelKey="uuid:265973ab-31cb-4890-83e0-34d9c1b385e5"> <name>Stock Quotes and Information</name> </tModelInfo> </tModelInfos> </tModelList> </soap:Body> </soap:Envelope>
Step 3: Retrieve Overview Document Containing WSDL
Send a request for tModel details for the service with the specified tModelKey:
<Envelope> <Body> <get_tModelDetail generic="1.0"> <tModelKey>uuid:7aa6f610-5e3c-11d7-bece-000629dc0a53 </tModelKey> </get_tModelDetail> </Body> </Envelope>
The response message includes the OverviewURL element that points to a WSDL document. This document contains the information needed to create an application to access the service.
<overviewDoc> <description xml:lang="en"> Get Stock quote for a company symbol </description> <overviewURL> http://www.webservicex.net/stockquote.asmx?WSDL </overviewURL> </overviewDoc>
You can display the WSDL by pointing your browser to this URL. To invoke the Web Service, remove the query string (?WSDL) from the URL, and navigate to it with your browser.
How to Communicate with a UDDI Service Registry
To interact with a UDDI registry whether to publish or inquire you need a way to generate SOAP requests and interpret responses. One option is to write your own application using the Microsoft UDDI 2.0 SDK. It contains excellent C# examples that demonstrate the API and can be run against a test UDDI registry hosted by Microsoft.
For making registry inquires, Web-based UDDI browsers are available. A publicly available one as well as a wealth of accompanying UDDI information can be found at
|< Day Day Up >|