Roy Hoobler has been involved with Internet programming from 1995 and developing Web businesses and "niche" market sites since 1996. In 1997, he completed his MCSD certification and worked for a large consulting firm primarily focusing on Intranet and Extranet applications for fortune 1000 companies. In early 1998, seeing the potential of how business would be conducted on the Internet, Roy joined Net@Work Inc. where he designs (and still codes) business and cutting-edge e-commerce applications using a wide range of technologies, including XML. Creating Web services with Visual Studio.NET is a great way to get systems communicating with each other; either internally over the network or externally over the Internet. However, building a scalable OOP (object-oriented programming) client is just as important. This article discusses building an ASP.NET application that retrieves event information from a Web service.
Web services and Web service clients should be better planned and designed than traditional applications. By definition, a Web service client application is 'loosely coupled' from the remote service. Our client should contain code that also will be easy to test and reuse. In this case, classes need to be built that link the Web service to our client application and process XML or other data.
The client ASP.NET Web site will retrieve either a list of 'events' for a current date, or the same list filtered by a category. The client will also need to connect and get the category list as well.
Designing classes for a Web service
For the Web service client, three projects are actually needed. An ASP.NET project, a class library with two classes and a Windows application for testing.
From the description above, I can start to design what my objects are going to look like. In the Visual Basic class library, a class is needed to handle the request to the Web service (Listing 1). Each ASP.NET page could have contacted the Web service directly, but what would happen if our Web service provider changes a Web method parameter or goes out of business? Using a central place to connect to the Web service will require changes in just one class which is called WebServiceCalls.vb.
In the class library, a reference to the Web service needs to be created. In most .NET projects, there is a folder in the Solution Explorer for "Web references" or "references". Right clicking on the folder and selecting "Add Web reference", brings up an interesting dialog where you can enter the URL to the Web service (for example: http://localhost/eventWS/eventWS.asmx). If successful, a list of available methods will appear. Adding the Web reference will allow you to call any of the methods listed. Once the object is instantiated as "...New mySite.com.eventWS()," all the Web methods are available to our class.
The three methods in the WebServiceCalls.vb class mirror the three Web methods of the Web service. The ASP.NET and Windows application can then use this new VB class library. The three methods are: getCategoryList, getEventsByDateAndCategory and getEventListByDate. In the ASP.NET and in the test windows application, you need to add a project reference to the class library project.
Since the category list is returned as XML, I created an XML utility class (Listing 2) that populates an array from XML and then uses the result to populate a Web Form Listbox control. Again, the objectives are to keep the XML code out of the ASP.NET page, build a reusable component and make sure this component can be tested individually.
Before working with an ASP.NET project, it is better to test the classes locally, in the Windows application project. This saves a lot of time because configuring and connecting to a Web server is not necessary. Testing the above classes in an ASP.NET project would require remote debugging and the time it takes to build a simple test application is always less than remote debugging. This Windows application can also be improved to be a complete program testing how the classes actually work and if the Web service is running.
Listing 3 displays a sample test function used in a Visual Basic.NET application.
Integrating the Web service classes with ASP.NET
Now that the Web service is working with a test application, transferring the code to an ASP.NET page is rather easy. However, there might some changes to get everything working properly with Web Forms or User Controls. At first, I wanted to bind a Listbox to a DataTable. However, it seemed simpler to just add items to the Listbox by looping through an array. I thought most of the Web form controls could be databound. It turned out this wasn't the case.
The ASP.NET page displays the information as expected and assigning values to the controls from the results works well. Fortunately, the search results come back as HTML from the Web service. If the results came back as an Array or XML, more functions could be added to the XMLData.vb classes, but the ASP.NET code would change very little.
Listing 4 shows the index.aspx file and the code behind index.aspx.vb file.
The Final Results
The process of consuming a Web service using objects, as in this example, takes quite a bit more time than just adding a Web service reference to your index.aspx.vb file. However, the class library is a great piece of reusable code that can be used in other applications and can also be tested locally using a Windows application. As the project grows, more functionality can be put into the WebServiceCalls.vb and XMLData.vb classes. Other classes such as Error handling can also be added to the class library. In the end, the stability of using OOP techniques far out-weighs the time of planning and developing the initial classes.
For More Information