Creating a .NET Web service

Web services are the next step in building distributed, modularized applications. They allow you to take some of your business logic, compartmentalize it in a component, and execute the functionality over the Internet. This article guides you through the creation of a simple .NET Web service.

If you’ve been building COM components in the Microsoft world for the past several years, you’re familiar with the concept of building a middle-tier layer of reusable objects that gives you a much greater degree of code reuse and flexibility. These components can be executed on the same machine as the client application or on separate machines using DCOM.

Now, .NET takes this concept a step further, allowing you to place the components on remote machines to which you have only an HTTP connection; in other words, these remote machines may not be part of your corporate network. Thanks to the advent of the SOAP protocol, the binary standard of DCOM is replaced with a text-based, XML-based calling syntax that allows clients using any operating system to call Web services that are themselves running on any operating system.

Building a Web service with .NET
Microsoft released the SOAP Toolkit for Visual Basic 6 almost two years ago, but .NET makes building Web services much easier. Support for Web services is built into the base .NET Framework, which means any .NET language can create Web services. They even appear as a project type in Visual Studio.NET. As with most .NET project types, you can create the entire application in Notepad.

To create a Web service, you’ll need to have at least the ASP.NET engine installed. This engine is part of the .NET Framework and Visual Studio.NET. If you don’t have it, you can download ASP.NET from the asp.net Web site. The download works with Windows 2000 and Windows XP only. Once you’ve installed ASP.NET, you’ll need to either create a virtual directory or simply create your files in the inetpub\wwwroot directory, which I will do for my example.

I was recently viewing a Web site for a company in London, and the prices on their pages were in pounds. The page had a converter tool to allow you to convert the pounds to dollars. This converter tool will make a good Web service example. So open Notepad and get ready to create an XML Web service.

The first step in creating your Web service is to identify it as a Web service, describe the language it uses, and specify the name of the class you’re creating. For this example, the language will be Visual Basic.NET, and the class name will be ConvertMoney. Your first line of code will look like this:

<%@ WebService Language=”VB” Class=”ConvertMoney” %>

Next, you use the Imports statement to import the System.Web.Services namespace. Doing so allows you to reference classes such as WebService by using just the name, not the entire namespace. This line looks like this:

Imports System.Web.Services

Next, create the shell of the Web service itself. The WebService class prefixes the name of your class, as shown:

<WebService()>Public Class ConvertMoney
‘ code will go here
End Class

You’re almost ready to add the class functionality, but you need to add one more critical line of code. You must inherit from the base WebService class, which is part of the .NET Framework. Doing so provides the functionality that allows the class to be called by any Internet client. After adding the Inherits statement, all your code should look like Listing A.

You’re now ready to add the functionality to your class. In this case, you create a single, simple function accepting the currency amount in British pounds and returning the U.S. dollar amount. Normally, you’d locate the current exchange rate in a database. In this example, you’ll hard-code an exchange rate at which 1 pound is equal to 1.44 dollars. When you add the procedure to the previous code block, you have the total code for the Web service, as shown in Listing B.

Now that the code is complete, you simply save the file in a virtual directory. (c:\inetpub\wwwroot is usually fine.) Save the file as Converter.asmx. The ASMX extension is the identifier for a .NET Web service. Once you’ve saved the file, your Web service is ready for its debut.

Testing the service
It’s rather exciting that you’re now ready to test the Web service, because you do not have to go through an explicit compilation step. You simply save the file in the directory and then call it. ASP.NET compiles it on the fly, just like an active server page (ASP). Understand that the compilation is to native code, not to interpreted code as is the case with classic ASP files.

In order to call the newly created service, open your browser and enter the service path, including the name of the ASMX file. If you placed the service in c:\inetpub\wwwroot, you can simply type http://localhost/converter.asmx.

Something interesting happens when you call the service: A page appears with a large amount of information in it. This may be confusing at first; after all, you haven’t created an HTML page as part of this service. You don’t have to create a test page, however, because the .NET Framework does it for you. When you call the Web service directly through a browser, the Framework generates a page for you that shows you information about the Web service and lists all the available methods. You can see this page in Figure A.

Figure A

Calling the newly created Web service

The list of methods in this example isn’t too exciting, because there’s only one (PoundsToDollars). Click on this method to reveal another page, shown in Figure B. This page is a test page for this particular method, including a text box for each parameter the method accepts. Enter “50” into the text box and click the Invoke button.

Figure B

The PoundsToDollars method is selected.

When you click Invoke, a new browser window opens, revealing some XML. This XML is the return from the Web service and includes the result. The returned XML is shown in Listing C.

This return format is not necessarily the friendliest, but you don’t normally call Web services directly from the browser. Instead, you typically call them from applications and handle the returned XML appropriately. Still, it’s easy to see that the Web service has converted 50 pounds to 72 dollars.

Conclusion
This example may not seem too exciting at first, but recognize what you have done: You’ve created a component that, if placed on a Web server, could be accessed by anyone, anywhere in the world. The client doesn’t have to have COM or DCOM loaded; it doesn’t even have to be a Windows client. Any client that can create an HTTP connection can call the Web service and receive results. This capability opens an entirely new realm of building distributed applications, allowing interoperation between platforms.