Part of Microsoft's grand design for the way computer users conduct business includes the concept of using .NET Web services. This month, I present a primer in .NET Web services, some background information, and an example program that uses Web services.
In ".NET Web services" the word "services" does not mean what it does in other computer contexts, such as that of a background task like a printing daemon. In this context, a "Web service" is a server computer on a network that has been set up to deliver some specific information on request. A Web service, then, is much like an Internet Web site--but for computer programs, rather than for people using a browser. Even so, the process of getting information from a Web service provider is much like the process a person would use--looking up a URL, finding the needed information, and returning.
What makes using a Web service in a program so compelling is the close relationship between Web services and .NET programming languages. Almost all of the grisly details of distributed object integration and remote services brokering inherent in platforms like CORBA and COM have gone under the covers since the improvements in the .NET and Web services integration model.
The mother of all Web services is BizTalk, from (whom else) Microsoft. BizTalk offers a wide range of Web services like "systems integration, business-to-business transaction processing, and business process management." Many other Web service providers supply explicit pieces of information. For instance, there is a Web service to provide a list of Irish legal holidays, another for prime numbers, and another for movie theatres in your area. And most Web services are available at no charge. All you have to do is create a C# or VB.NET program that references the Web service. The Web service will then be treated in your program as if it were a local object that has an exposed interface of methods and properties. You may then set properties and invoke methods to send the request and receive the reply.
Some Web Services Basics
Just as Web content information coming to a browser for display is formatted as HTML, data coming from a Web service for consumption by a requesting program is formatted as XML. The request and response is conducted over your Internet connection using a transaction protocol called Simple Object Access Protocol (SOAP). But fear not! You don't have to learn much about XML or SOAP to use a Web service in a C# or VB.NET program.
Microsoft Visual Studio (VS) has the capability of helping you create a VB or C# application that can access standard services available on the Web. VS will help you find an appropriate Web service and then build an interface for that particular service automatically, using specifications published by the Web service provider. The specifications are published in a language called Web Service Description Language (WSDL). When you create a reference to the service in your program, the WSDL is examined, and the appropriate interface is created. The Web service's public properties and methods are discovered and incorporated into the program.
But before you can access the information from a Web services provider, you have to know where to send your request. The Universal Description, Discovery, and Integration (UDDI) service is a central repository of listings where Web service providers may register their servers and where those in need of services may get a referral to a service provider.
A Simple Web Service Application
For example, suppose you were writing a simple Windows program that would allow a user to type in a name and address for the purpose of producing a set of mailing labels. You want to help the user with this task, so you decide to include a customary feature in your program whereby the user keys in a ZIP code, and the computer looks into a PC file for the city and state that correspond to the ZIP code and offers them to the user. It's been used for years. Assuming you acquire the ZIP code data from, say, the Postal Service and get the solution working, it won't be long before problems arise as your ZIP file falls out of date. The Postal Service creates new ZIP codes and changes existing ZIP codes all the time. To solve this problem, you could get a refreshed ZIP code file from the Postal Service at regular intervals, or you could build your program so that it asks a standard Web service to get the ZIP code information for you. The standard Web service provides this support on behalf of the Postal Service to many users, free of charge, and the ZIP code information is accurate and current.
This C# example will send a request to the ZIP code Web Server and display the response:
(Click images to enlarge.)
To see how a program like this is built, start a new C# or Visual Basic project in Visual Studio 2003 or later. In the Solution Explorer window, right-click References and select Add Web Reference. This will launch a browser-like wizard that will help you find an appropriate Web service.
If you know the name of the Web service, you can key it into the URL box, as in the figure, or you can browse the UDDI directory. In this example, I use a Web service provided for educational purposes by Glenn Johnson Technical Training. Click the Go button, and the wizard will discover and return the specifics for the Web service. The Web reference name for the service is then displayed (com.teachatechie in this case). Click on Add Reference. After a bit, the new Web reference is added to the Solution Explorer. Double-clicking the reference name will display the object browser for the new Web service object, and the methods and properties for the Web service will be shown just as if the service was a local resource.
From this point, it's a matter of generating some code to create an instance of the Web server object, getting a ZIP code from the user, passing the request, and getting the response. The example code below is invoked when the user keys a ZIP code into a text box and clicks the Lookup button:
int ib = 0;
int ie = 0;
Cursor.Current = Cursors.WaitCursor;
// Create a dataset to receive the city/state info...
DataSet s = new DataSet("ZipCode");
// Create a ZIPcode Web Service object...
t = new com.teachatechie.ZipCode();
// Invoke the ZIPcode object's GetLocation method,
// passing the ZIP code to be looked up...
s = t.GetLocation(txtZip.Text);
// Get the XML representation of the dataset in a string...
sWork = s.GetXml();
// Dump the raw XML into a label control
// just to see what it looks like...
lblsWork.Text = sWork;
// Put the first city/state name into labels for display...
ib = sWork.IndexOf("
ib = ib + 12;
ie = sWork.IndexOf("/CITYSTNAME>", ib);
ie = (ie - ib) - 1;
lblCity.Text = "";
if (ie > 0)
lblCity.Text = sWork.Substring(ib, ie);
ib = sWork.IndexOf("
ib = ib + 7;
ie = sWork.IndexOf("/STATE>", ib);
ie = (ie - ib) - 1;
lblState.Text = "";
if (ie > 0)
lblState.Text = sWork.Substring(ib, ie);
Cursor.Current = Cursors.Default;
Notice that a dataset object must be created to accept the response from the server. This is necessary because the server may return 0, 1, or many records (in the figure, two cities, Seattle and Times Square, are returned for a single ZIP code).
The response will be in XML format, but that's not a problem thanks to .NET's XML handler. Notice the GetXml method that will render the dataset content as a string, which may then be parsed.
Some Considerations for Using Web Services
Naturally, there are some problems inherent with using Web services. Obviously, there can be no Web services if there is no connection, so an application of this sort cannot function in a standalone form. Also, what happens if the Web services host is not functioning properly? If your application is entirely dependent on Web services being available, there may be times when your application doesn't function at all. Another factor to consider is what may happen when a given Web service provider changes the formatting of the returned information. And what if the provider gets out of the Web services business altogether?
As Web service platforms become more mature and established, the practice of incorporating Web services into production applications will become more accepted. There may come a day when dozens or even hundreds of this type of resource will be routinely regarded as viable and essential tools for building your .NET applications.