Web Services: Building Reusable Web Components with SOAP and ASP.NET
David S. Platt

This article assumes you’re familiar with XML and Visual Basic
Level of Difficulty 1 2 3
Download the code for this article: WebComp.exe(93KB)
Browse the code for this article at Code Center: TimeServiceDemo
SUMMARY XML and HTTP are cross-platform technologies especially suited for building applications that can communicate with each other over the Internet, regardless of the platform they are running on. Web Services in the Microsoft .NET Framework make it easy to write components that communicate using HTTP GET, HTTP POST, and SOAP.
An understanding of these concepts, along with knowledge of synchronous and asynchronous operations, security, state management, and the management of proxies by the .NET Framework is essential in building these applications.
This article has been adapted from David Platt’s upcoming book introducing the Microsoft .NET Platform to be published by Microsoft Press in Spring 2000.
--------------------------------------------------------------------------------

seismic shift is just now beginning in Internet programming. Internet access will soon be built into nearly every program anyone ever writes. You won't use a generic browser, except when you feel like browsing generically. Instead, you will use dedicated programs that are optimized for accomplishing specific tasks. You won't be aware of the program's Internet access (except when it breaks).
An early example of this type of program is Napster, which allows you to search the shared hard drives of thousands of participating users for music files that meet specified criteria, and download the ones you like. The dedicated user interface of a multi-player game is another example of hidden Internet access. And the latest edition of Microsoft® Money does a good job of seamlessly blending Web content (current stock quotes, latest balances, and so on) and desktop content (financial plans you create locally).
In order to develop programs of this type, there needs to be a quick and easy way (which, in turn, means a cheap way) to write code that communicates with other programs over the Internet. The idea isn't new; there are a number of existing technologies that enable this type of communication: RPC, DCOM, and Microsoft Message Queue Services (MSMQ). Each of these techniques is cool in itself, but they all share one fatal failing: they only work from one similar system to another. MSMQ talks only to MSMQ, a DCOM client only to a DCOM server, and so on.
What's really needed is universal programmatic access to the Internet—some way for a program on one box to talk to any other program on any other box. It has to be independent not only of the operating system, but also of the programs' internal implementations. (Is it C++ or Visual Basic®? Which vendor is it from? Which version is it? Right now you can barely solve this problem on a single desktop.) And it has to be easy to program, or no one will be able to afford it.

Solution Architecture
The only way to deal with the enormous numbers of heterogeneous entities on the Internet is to use the lowest common denominator. In other words, when bytes are transferred from one box to another, the process needs to use some standard that everyone on the Internet supports. The most common Internet transfer protocol is HTTP, which is used today by essentially all Web browsers to request the pages they display. The emerging cross-platform standard for encoding pure information transferred over HTTP is XML.
Microsoft put these ideas together and developed the concept of a Web Service—a seamless way for objects on a server to accept incoming requests from clients using HTTP and XML. To create a Web Service, you simply write a Microsoft .NET server object as if it were going to be accessed directly by local clients, ma