Practical Web Service Consumption

One failing that a lot of Internet and free samples have is that they do very little to convey how to use a technology in a practical, real-world scenario. Unless you happen to be writing an application that does nothing but display the phrase "Hello World" in 30 various and sundry ways, most "quick" samples don't do you much good.

For example, most web service samples all work against a single fixed URL. This means that when the web reference was added within Visual Studio, the sample never changed the URL of the web references. There aren't many development situations where the URL of a web service while being developed is the same as the production URL. In addition, there can often be multiple servers hosting the same servicehow does the client application know the URL of the web service in these situations?

In previous versions of Windows Forms, the developer would typically place the URL for the web service in the app.config file and then programmatically retrieve that value and set the web service's Url property accordingly.

Thankfully, that tedious process is no longer required. Using the new application settings system, the URL of the web service is added to the app.config file automatically when you add the web reference.

To see how this works, create a new Windows Forms application and add a web reference to a web service. You will see that the web service's URL is placed in the app.config file as shown in the following code:

<applicationSettings> <PracticalWSClient.Properties.Settings>     <setting name="PracticalWSClient_PracticalWS_Service" serializeAs="String">         <value>http://localhost/PracticalWebService/Service.asmx</value>     </setting> </PracticalWSClient.Properties.Settings> </applicationSettings> 

By storing the URL of the web service in a configuration file rather than leaving it hard-coded in the application itself, you can rapidly change the location of the web service and you can even allow end users to change the setting. The new application settings model is covered in the next section.

Obtaining a Web Service URL from UDDI

An alternative to storing the raw URL of the web service in an application configuration file is to retrieve the URL of the web service using Universal Description and Discovery Interface (UDDI). UDDI is itself a web service that exposes a catalog of directory nodes. These nodes can contain information ranging from business information about the service providers to an actual interface containing a URL to access the service.

By using UDDI, companies that produce smart clients can make a single change to a central UDDI record and all clients would then know about the new URL for the web service and adjust accordingly.

In addition to this centrally managed URL, companies can provide multiple URLs for redundancy. If the first URL fails to respond within a specific time period, a smart client can then move to the next URL in the directory and try to establish a connection with that web service.

UDDI information can either be published globally (see uddi.org ) or it can be hosted within an organization using the new UDDI services that are a part of Windows Server 2003.

The UDDI SDK and creating and using tModels (the data structures that represent a stored model within a UDDI directory) are both beyond the scope of this chapter. For more information on UDDI see http://www.uddi.org or check out http://www.microsoft.com/windowsserver2003/technologies/idm/uddi/default.mspx for information on the Windows Server 2003 UDDI support.