Enterprise Software

Testing a Web service with a proxy class

A good way to test a Web service is by building a proxy class/client to consume it. Tony Patton shows you how to develop a simple proxy class via .NET, using either C# or VB.NET.

Now that you know how to make product information available via one or more Web services and have the code for our Web service, the Web service can be utilized by a variety of client applications.

Conceptually, the service will be available publicly via an Internet connection so customers may easily use it. Of course, we need to be able to tell customers how to use it. A good test of the service is building a proxy class/client to consume it. In this week's article, we develop a simple proxy class via .NET.

Proxy class automation

In addition to testing the service with a basic browser call to the service asmx file, we can test it using SOAP as well. A client and a Web service can communicate using SOAP messages, which encapsulate the in and out parameters as XML. Fortunately, for Web service clients, the proxy class handles the work of mapping parameters to XML elements and then sending the SOAP message over the network.

A proxy class is created to shield the client from the complexity involved in invoking the Web service. A proxy class is a class containing all of the methods and objects exposed by the Web service. These methods handle the marshalling of the parameters into SOAP, sending the SOAP request over HTTP, receiving the response from the Web service, and unmarshalling the return value. The proxy class allows the client program to call a Web service as if the Web service was a local component.

A proxy class may be generated from a service description as long as it conforms to the Web Services Description Language (WSDL) standard. You can create a proxy class using the .NET command-line tool wsdl.exe. In turn, a Web service client may invoke proxy class methods, which communicate with a Web service over the network by processing the SOAP messages sent to and from the Web service.

Because a proxy class communicates with the Web service across the Internet, it is a good idea to verify that the url property of the proxy class references a trusted destination. The following command uses the wsdl.exe tool to generate a proxy class for our service:

wsdl /language:cs /protocol:soap http://localhost/WebServiceExample/Service1.asmx

Listing A contains a small portion of the class generated by this call.

A key aspect of the proxy class is its constructor that sets the url property so the Web service is properly accessed. The generated methods mimic methods in the actual Web service. Notice that each method invokes the corresponding method in the Web service.

The wsdl tool accepts various parameters, as seen in our previous call. Here is an overview of the parameters used:

  • /language: Allows you to specify the language used to create the proxy class. The default is C#, so its inclusion in the previous call is extraneous. You can specify CS (C#; default), VB (Visual Basic), JS (JScript), or VJS (Visual J#) as the language argument.
  • /protocol: The protocol implemented in the proxy class with SOAP as the default setting. The additional options are SOAP12, HttpGet/ HttpPost, or a custom protocol.
  • The url points to the Web service. It may also point to an XSD schema or .discomap document. You can obtain discovery documents for an XML Web service using the Web Services Discovery Tool (Disco.exe). The .discomap, .disco, .wsdl, and .xsd files produced by this tool can be used as input to wsdl.exe. You should refer to the wsdl.exe tool documentation for more information on the additional command-line options available.

The following line generates a proxy class using VB.NET:

wsdl /language:vb /protocol:soap http://localhost/WebServiceExample/Service1.asmx

Listing B contains a portion of the VB.NET proxy class generated by the wsdl tool.

With the proxy class in place, it can be utilized to test our Web service. (Note: The proxy class may be developed using the language of your choice. It doesn't have to use the same language as used in the actual Web service.)

Using the proxy class

We can utilize this proxy class in a client application to use the features of our Web service. The client application may be developed with Windows Forms, ASP.NET, or any other .NET application. The ASP.NET Web Form in Listing C utilizes the proxy class and C# to retrieve products by the product id entered by the user (entered via text box on Web Form). Listing D offers the VB.NET equivalent.

The ASP.NET Web Form is simple; it accepts a value via a textbox and passes this value to the service's GetProductByID method. You might consider adding validation to ensure the user enters a valid integer value.

Making it available

You may be wondering how the proxy class helps customers using the class take advantage of the service. The proxy class may be distributed (along with a sample application) as a demonstration of how to use the service. In addition, customers (developers) may use the Web service URL to discover the service details and to utilize in their own application to create proxy classes. It's easy to develop a Web site using the proxy class, allowing customers to query through the site rather than developing their own custom solution.

The next step

At this point, we've developed our service, proxy class, and tested the service via the proxy class and Web site. In the next installment in this series, we'll cover different scenarios of using the service within other applications.

TechRepublic's free .NET newsletter, delivered each Wednesday, contains useful tips and coding examples on topics such as Web services, ASP.NET, ADO.NET, and Visual Studio .NET. Automatically sign up today!

About Tony Patton

Tony Patton has worn many hats over his 15+ years in the IT industry while witnessing many technologies come and go. He currently focuses on .NET and Web Development while trying to grasp the many facets of supporting such technologies in a productio...

Editor's Picks