As described so far, the programming of ASP.NET pages is purely a "local" phenomenon. That is, scripts are contained on the same pages that access them, or they are packaged as code-behind files residing on the same local server. The point is, access to your scripts is restricted to the local pages that use them. It is not possible for users to run you scripts except within the confines of your own applications.
Normally, this restricted access to processing routines is not an issue. Your scripts are written for the special purposes of your applications, and there is little reason outsiders need access to them. By the same token, there may be little reason for your applications to access scripts housed on somebody else's server. However, consider a couple of scenarios in which this might not be the case—where remote uses do need access to your scripts or where you need access to remote scripts.
Sharing Server Processes
Imagine, for instance, that you have created a business process, perhaps a code-behind file, that extracts a recordset of your products for display on your e-commerce site. Members of the Web community interested in your products must, of course, come to your site and view these products through your own Web pages. Assume, though, that an enterprising company wishes to serve as a clearinghouse for all such products. Its purpose is to provide a single site where the Web community can window-shop for products from your company and from other companies with like products for sale. This purpose would be served by making your database of products available to the integrator company and accessible through its Web pages. However, you would not want the integrator company to have direct access to your private database. Preferably, you would supply the data in real time, but not compromise access to your server.
A reverse process can also be imagined where you need access to processing routines residing on remote servers. For example, a commercial enterprise often deals with suppliers and distributors of its products. Products are ordered from wholesalers and distributed to retailers through a supply-chain process. Efficiencies are gained by having the various servers manage the transactions automatically, behind the scenes. For instance, your server might run processes housed on a wholesaler's server to place orders when stocks reach certain low levels; or, your server runs processes on a retailer's server to detect inventory levels that automatically trigger sales.
The needs described above are (1) for remote sites to run scripts on your server to provide information to the remote sites or (2) for your site to run scripts on remote sites to provide your site with their information. In either case, the information needs to be shared without either party compromising access to their servers or the information they contain.
This ability to run local processes from remote sites and to run remote processes from the local site is available through Web Services, a technology that is part of ASP.NET. Through Web Services you can make your processing methods available and executable by others on the Web, and you can execute methods on your pages that are made available by others. The general idea is that Web page processing can be handled by your scripts or by scripts housed anywhere on the Web.
The implications of Web Services are enormous. In effect, no longer are you restricted to supplying your own code for your own applications running on your own local server. Web applications can be composed of software components residing anywhere on the Web. In a real sense, the Web itself hosts your applications, with components scattered across multiple servers, your own and potentially many others, all working in concert. In the extreme case, your application may be composed entirely of Web Services supplied by others, all residing on remote servers but used as if they were your own.
Web Services Development Process
In its most simple form, a Web Service is a Visual Basic function that can be called from anywhere on the Web. The function is created and accessed through the following steps.
As the supplier of a Web Service,
In this way, you can supply access to your information without providing or revealing the private internal processes to access it.
As the consumer of a Web Service,
In this way, your page runs the remote Web Service as a local function even though it resides at the remote site. That is, you instantiate the remote function just as if it resided on your local server.
Setting up the Development Environment
The development of a Web Service is the easiest part of the process. All that is required is to create a Visual Basic function that returns the information produced by the service. This function is converted into a Web Service and saved as a .asmx file in a Web-accessible directory so that users can get to it. For the examples presented here it is assumed you have created a virtual directory named c:\MyWebServices on your server. Here is where all Web Services that you supply are stored.
The consumer of a Web Service has the most work to do. In order to use the service you need to acquire the following tools and set up the following directory structures.
First, download and intall the .NET Framework Version 2.0 Software Development Kit (SDK) on your development computer. This kit is available at http://www.microsoft.com/downloads/details.aspx?familyid=fe6f2099-b7b4-4f47-a244-c96d69c35dec&displaylang=en. It includes everything needed to consume Web Services.
Second, set up a folder on your development computer and collect the needed tools for creating a proxy class into this central location for ease of use. Consider creating a c:\WebServices folder on your development computer and copying the following files to it (use Windows Search to locate these files and copy and paste them to the WebServices folder):
A development c:\WebServices folder should resemble the directory shown below.
Keep in mind that this discussion of Web Services is from two different viewpoints. As a developer of Web services, you need a Web-accessible folder on your Web server (say, c:\MyWebServices) to place Web Services (.asmx files) that can be accessed by others. As a consumer of remote Web Services supplied by others, you need a folder on your development computer (say, c:\WebServices) to create proxy files to access these remote services. These .vb files are eventually copied to the app_Code folder on your Web server so that your server applications can use these remote services through their local proxy files.
The process of creating and accessing a Web Service is illustrated below.