Microsoft has also somewhat started promoting 'Best Practices' for software design. This includes developing more modular or 'component' based software. Taking a step back, I need to figure out what my Web service needs to do and what components are going to be needed.
This article shows not only how to implement a Web service server and client, but some of the object oriented issues in designing a Visual Basic .NET application. For many, this will seem trivial, but for others, it should be a nice example of thinking in objects or better, show Visual Basic .NET capability of using objects and how they can be implemented in a Web service.
What I want my Web service to do
Before going 100 MPH coding your Web service, sit back and decide what needs to be done. In my Web service, I want to retrieve a list of events on a particular day. This is a very simple program but some steps will be necessary:
- Get a database connection.
- Create a record set and then HTML or XML from a request.
- Return the results to the user (or Web service). The Web service could also provide a list of categories that would help narrow the search results. The client program will probably not know these categories, so I'll add that functionality, as well as provide a function that accepts the category and date to filter the results.
- Create HTML Select List of categories.
- Return results for date and category. I want to be able to get all the information about an event. In this case, I will create an Event object that has properties. SOAP can actually serialize these objects into XML and transform them back to objects for the client. This class can also be reusable and we will be able to test it before deploying it to our Web service.
- Finally, return event object for a selected event.
Starting the Project
With Visual Studio .NET we will first create a Visual Basic .NET Windows Class Library project (.dll). This component will maintain our database connection as well as retrieve data from the database. Compared to their COM counterparts, .NET DLLs are easily ported to the deployment server and are easier to work with.
A Database Connection Example
.NET has three ways of accessing a database -- a built-in SQL connection, a wrapper for ADO connections and an OLE DB connection. The ADO objects should only be used to integrate with older components that use ADO. For this example, I choose OLE DB because it is probably the most 'portable' type of object and there seems to be plenty of SQL Server examples.
Following a basic design principle, I made two database classes that will make use of OLE DB. Other classes in my application will use my classes instead of OLE DB. Again, if my database changes to SQL later, I only need to change one class (possibly two) instead of every class in my application.
Using DataSet objects
Data Adapters, DataSets and DataTables are all new with Visual Basic .NET and are probably the most used objects. Basically they are built to better abstract the database layer than ADO has done. DataSets are filled, completing the actions of server-side cursors much more efficiently than ADO.
[See Listings 1 and 2]
Creating a class to do what you need done: Your interface
With these database classes, I could start building my Web service. This is an example of programming way too fast. Of course, everyone is looking forward to working on the Web service. However, I want to build a class that actually retrieves the data that will be used in the Web service. This class will also be reusable and allow us to test without using the Web service.
The final version of the class has three public methods and two private methods:
- Get Results For Date
- Get Results For Date and Category
- Get List of Categories
- Get Event Details
When I instantiate my class in the Web service, these methods will be accessible from any client. Here's the code from the Event Class:
[See Listing 3]
Now you can test your application. Add a Windows Application project to the current solution. Within this project, add a reference to your Class Library project and test each function (for example: oEventClass.getCategoryOptionList()). This is a much easier approach and easier to debug than a Web service. As you add functionality, you can test your classes offline.
Plugging in your classes to create a Web service
Finally, we are able to use our new classes as a Web service. After all this work, using our classes in a Web service is almost too easy.
First you will need to add a third project -- a new Visual Basic .NET Web service -- to your current solution. The name of this project will be the directory on the Web server for your Web service. My new project is called companyEventsWS.
You will need to connect to a Web server and have permissions to create a "virtual directory" in IIS. I usually create a separate .NET developer user account on the server and then add them to "site operators" in IIS.
In the Web services project, in the project explorer window, select "Add Reference" and select your (.dll) project. When you add this reference and compile the project, Visual Basic .NET will compile the DLL and place it in a /bin directory under your Web service project -- locally and on the server.
The last step. For each public method in the Event Class, I made a Web method for clients to connect to.
[See Listing 4]
**Note: If you use a COM component in any project, the "Interop" classes will be deployed to the Web service. However, the original COM component will need to be installed or registered.
To test the Web service, open a browser and navigate to http://localhost/companEventsWS/service1.asmx. You should see the three methods and Microsoft actually let's you invoke (test) each service. If you get a http 500 error, check the location of your Access Database file and permissions. The anonymous user will need at least read access to the .mdb file.
Congratulations, you have just completed a great Web service, even though this is a simple example -- we only wrote about 100 lines of code (mostly variable declarations) for the server. Breaking the code into modules allows programmers to reuse the code in other Web services or Windows applications. The code can also be tested 'outside' of the Web service environment. Finally, there is a lot of room for expansion. In the real world, the code in the .asmx file will have more than one line calling a function, but starting with one line is a nice goal to keep in mind.Get the code here (Listings 1-4).
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. (www.netatwork.com) where he designs (and still codes) business and cutting-edge e-commerce applications using a wide range of technologies, including XML.
More on Visual Basic .NET and Web services:
- For insightful opinion and commentary, read our Guest Commentary columns.
- Tired of technospeak? The Web Services Advisor column provides a clear understanding of Web services.
- Looking for shortcuts and helpful developer tips? Visit our Tip Exchange for time-saving XML and .NET tips.
- Visit Ask the Experts for Web services, SOAP, WSDL, XML, .NET, Java and EAI answers.
This was first published in April 2002