The Book of VB .NET: Web Services, Part 1
Excerpted with permission from The Book of VB .NET, by Matthew MacDonald, No Starch Press, Copyright 2002.
Web Services are a new introduction to Visual Basic .NET, and are being touted by Microsoft as a new and revolutionary way to program with the Internet. All this excitement raises the inevitable question: Are Web Services really the future of programming, and a sound career investment, or are they doomed to become the "next great thing" that wasn't?
A little background on the subject should help us find the answers. First of all, the concept of Web Services hasn't been created by Microsoft. It represents an exciting new area that several companies are clamoring to gain control of, including such heavyweights as Sun Microsystems and IBM. However, Microsoft has been planning their implementation of Web Services for quite a while, and it shows. Microsoft has made Web Services incredibly easy to program in .NET, while retaining the ability to let Web Services work seamlessly across different browsers and operating systems. A great deal of thought has gone into Web Services, and there is good reason to believe that they are destined to become another powerful tool in the advanced programmer's arsenal, along with ActiveX, COM, and other revolutionary technologies from the past.
This article starts by asking "What is a Web Service?" and takes you through the process of creating, deploying, and interacting with one. Luckily, .NET makes Web Services so quick and convenient that you can be creating simple examples in no time at all. However, it may take many more months of experimentation before you start to realize all of the possible ways Web Services can be used. The end of this article includes some helpful web links to live examples of Web Services.
New in .NET
Web Services are making their debut in Visual Studio .NET-they haven't existed in any form before. Some developers may have created custom Web Service implementations using Microsoft's SOAP toolkit, but only for highly specialized applications.
In fact, Web Services are so new and so promising that they are sometimes identified synonymously with the entire .NET platform. Of course, now that you have read Chapter 1 of The Book of VB .NET, you know what .NET is really about. How large a part Web Services will play in Microsoft's strategy of integrating languages, embracing open standards, and programming the Internet remains to be seen.
The Vision of the Interactive Web
What is a Web Service anyway? Clearly, many sites on the Internet provide useful "services." A common example is a shipping company, which allows you to look up the location and delivery date of packages using a tracking number. Is this a Web Service?
The delivery date lookup meets one of the criteria of a Web Service-it's a discrete unit of functionality that serves a single purpose: returning information about your package. But in order to get this information, you have to navigate to the correct HTML page, select an option from a menu, and then enter your tracking number. In other words, you have to use an Internet application- represented by the shipping company's website-in order to get the information you need.
Web Services: COM for the Internet?
One of the great developments in Windows programming was COM (some parts of which are also called ActiveX), a technology that allows code components to be easily shared among applications. When COM was introduced, it added flexibility.
Instead of using monolithic applications, custom utilities could be created that reused a subset of all the capabilities provided in COM components. In this respect, Web Services are like COM for the Internet. With a Web Service, you can take a unit of logic in a web application, and allow it to be seamlessly accessed and used by other Windows or Internet applications, in a variety of different ways. A Web Service is like a business object: It accepts information and returns information. Your program uses Web Services, without needing to involve the user, and takes care of providing the appropriate user interface. This is particularly important in the world of the Internet, where a user might be accessing information from a full-featured Internet Explorer browser, or from a stripped down interface on a cell phone or other wireless device. In this case, the Web Service used would be the same, but a different application would take care of the display. Like a COM object, a Web Service doesn't need to be tied to any specific interface.
In one important way, however, Web Services are not like COM technology. COM relies on a proprietary Windows standard, which means that it's useless for Macintosh computers, UNIX systems, or any other non-Microsoft platform. Web Services, however, are built on open standards such as SOAP, XML, and WSDL, which will be described in this article. This means that any application can interact with them (though none so easily as a .NET application), and that they can transmit data painlessly over HTTP. Because data is exchanged in a text XML format, there's also no problem sending a Web Service request or receiving its response, even when the Web Service is behind a corporate firewall.
Web Services Today
You are probably already making use of "first generation" Web Services. These are examples of Internet procedures that are integrated into desktop programs, but require company-specific and site-specific standards. For example, you may use a personal finance desktop application that can automatically retrieve stock portfolio information from the Internet. This type of application retrieves information from the Internet, and doesn't bother you with the details of the process. However, it relies on having information provided in a specific way, which was been planned and set up in advance, according to the particular application. It does not use an independent, widely accepted standard, as Web Services will with .NET. As a consequence, other applications can't easily extend or work with its functions and features. They must be recreated for every application that require them.
Now imagine a world with thousands of Web Service components, where a desktop application has access to all kind of features that require up-to-theminute information from the Web. In all likelihood, everyone will have some type of "always on" broadband Internet access, and you won't even be aware when your application is interacting with the Web. Programmers will no longer have to try and constantly redesign off-the-cuff solutions that schedule Internet downloads or parse HTML files manually, looking for specific information.
Of course, that's the future. Today, Web Services will allow you to further modularize Internet applications, and provide components that can be consumed and reused by any other application. Web Services can also use authentication and login procedures, allowing you to support various subscription models. In other words, you can sell units of application functionality to other developers, just like programmers sell ActiveX controls today.
Are Web Services Objects?
Web Services are not objects, at least not in the traditional sense of the word. The main distinction is that Web Services don't maintain state, unless you specifically take extra steps to store information in a database or ASP.NET's Session state collection. In fact, a Web Service that maintains state is rarely a good idea because it means the web server must allocate a portion of its precious memory for each client, which can quickly impose a noticeable performance penalty as the number of clients increases.
Web Services also don't support object-oriented basics like overloaded functions and property procedures. Constructors work, but the Web Service class is destroyed and reconstructed with each request, even if the client maintains a reference. This makes sure that Web Services perform well, but it also means that they can't be used like a local business object. It's best to think of a Web Service as a utility class made up of shared members. You can call a remote function to get a piece of information, but you shouldn't expect to keep a Web Service around and store information in it.
Creating Your First Web Service
Creating a Web Service is easier than you might think. All you have to do is
create a class that incorporates some useful functions. This class should inherit
from the System.Web.Services.WebService class (for maximum convenience),
and all the methods that are going to be made available over the Web must be
To start creating this application, begin a new project and choose ASP.NET Web Service. A series of support files will be created, as with an ASP.NET application. The actual Web Service is contained in the .asmx file (named Service1.asmx by default). The design view of the .asmx file isn't used, but the code view will start off with a couple of sample lines needed to define the Web Service class.
NOTE A Web Service, like the ASP.NET applications we saw in the previous chapter of The Book of VB .NET, must be hosted on a web ser ver in a virtual directory. The Web Service examples for this article are contained in the NoStarchWeb virtual directory. Web Service clients, on the other hand, can be located in any directory.
Now consider a very rudimentary example of a Web Service class for providing information about a package tracked with a shipping company:
Public Class PostalWebService Inherits System.Web.Services.WebService
<WebMethod> Public Function GetDeliveryDate(ByVal TrackID As String) As Date Dim PackageInfo As Package PackageInfo = GetPackageRecordFromDB(TrackID) Return PackageInfo.Date End Function
Private Function GetPackageRecordFromDB(ByVal TrackID As String) As Package ' Some database access code here. End Function
Public Class Package Public PackageID As String Public DeliveryDate As Date End Class
The Package class encapsulates information about a package. Notice that it
doesn't inherit from WebService class or use the
The PostalWebService class has two functions. The GetDeliveryDate function
is marked with a special attribute,
Now, believe it or not, any application using this Web Service will have
access to the features and operations of the GetDeliveryDate function. All you
need is a class that inherits from the basic WebService class, and uses the
To improve your Web Service, you might want to add a description to the
<WEBMETHOD(DESCRIPTION:="USE THIS FUNCTION TO...")>
You should also specify a namespace for your Web Service. Ideally, your namespace should be uniquely identified with you-your company name, for example, or best of all, your web address. If you do not specify a namespace, the default (http://tempuri.org/) will be used. Be aware that this is an XML namespace, not a .NET namespace. An XML namespace looks like an URL, but it doesn't need to correspond to a valid Internet location (although it often does). XML namespaces are just used to distinguish portions of an XML document.
To specify a namespace, change the first line of your class declaration to use the WebService attribute:
<WEBSERVICE(NAMESPACE:="HTTP://MYCOMPANY.COM/POST")> _ Public Class PostalWebService