A Web Service in Visual Studio .NET is constructed in a similar manner to an ASP .NET Web Form. There is a small HTML file and a VB code module behind it. The HTML file is not used to display anything in a browser, it is used to invoke the Web Service. Let's create an ASP .NET Web Service project so we can see what we are talking about.
Set up your web server the same way you did for the Web Forms projects. To create a Web Services project, click New Project. Name the project ADOBook10-01. When the dialog opens, select ASP .NET Web Service from the list of templates as shown in Figure 10.1.
Figure 10.1. Creating a Web Services project.
When you click OK, the IDE creates the project. As with an ASP .NET web application, the project is created in the wwwroot subtree of your inetpub directory. When the project is created, the IDE looks like Figure 10.2.
Figure 10.2. The IDE with a new ASP .NET Web Service.
What Do We Want It to Do?
Before we can go any further, we must decide what we want our Web Service to do. Let's stick with our CustomersOrdersOrder Details paradigm. We want our service to provide an interface through which client applications can obtain information about their order status. Notice we said provide an interface . We are also providing data, but more importantly we are providing the interface through which the data can be obtained. This is important because if all we wanted to do was provide the data, we could have used a web page. Instead, we are providing an interface for client applications to use to obtain the data. They can then present the data in any way they desire : via a web page, a Windows Form, a report, or even a Java UI. It doesn't matter to the Web Service.
What Can Be Passed to and from a Web Service
In order to understand what we can send back and forth to a Web Service, we must understand how the Web Service expects to communicate with the client. Remember, with Web Services everything must be able to resolve to an HTML request or XML stream. A Web Service interface is a form of remote procedure call (RPC). A request is sent to the server, and data is returned. From the client's point of view, the request takes the form of a method call. The method can only be a standard method (procedure or function). Property procedures are not supported.
The call is formatted into a request string that consists of the function name and a list of parameters. This is then sent to the server as an HTTP request. The web server looks at the request and knows to route it to the Web Service for processing. The Web Service then processes the request and returns a result. The result is formatted as an XML stream and returned to the client, which parses the stream and returns the data as the value of the function.
The data must be able to be represented as a text data stream. Fortunately, all of the .NET data types and many of the classes have this ability. The DataSet is the only data component that can be moved across HTTP connections.
Web Services cannot source events or callbacks of any kind. In the previous chapter we discussed at length why Web Forms could not communicate in real time with the web server. Web Services have the same restrictions and for the same reasons. The actual service only exists for short periods of time while processing requests, then they terminate. So you have the same concept of request/start service/process request/send results/terminate service. The life cycle of a Web Service is almost identical to that of a Web Form, with the difference being that the Web Service returns an XML stream instead of HTML. Each Web Service method must be a little program unto itself. You cannot use any module level variables to store data between requests , but you can use session variables or cookies.