4.2 Web Services Architecture
In ASP.NET, a web service is essentially a listener that monitors a particular URL exposed via HTTP, looking for requests packaged as SOAP messages. When a request arrives, the ASP.NET runtime unpackages the request and calls the method for which the request is intended, passing in any parameters included with the request. If the request has a return value (which is not required), the ASP.NET runtime packages up the return value (based on the XML schema datatype specifications) and sends it to the client as a SOAP message. What this means to developers is that your application doesn't need to know anything about the client that will consume it, other than the fact that it can understand XML and SOAP. Thus, developers can essentially write methods that will be called as web services just as though they were writing methods that would be called locally.
This functionality is provided by the runtime largely for free. Developers expose their functionality as web services by marking their methods with a specific metadata attribute, the WebService attribute. The Common Language Runtime (CLR) takes care of the rest—from packaging and unpackaging SOAP requests to automatically providing HTML documentation of the web service—if it is called from a web browser (rather than by a SOAP request).
Figure 4-1 illustrates how an ASP.NET web service works.
In terms of file structure, web services in ASP.NET are implemented by .asmx pages. An .asmx page begins with the @ WebService directive, which contains attributes instructing the CLR how to run the web service. The .asmx page can either directly contain the code necessary for the web service to operate or can contain a Class attribute in its @ WebService directive that points to a compiled class containing the implementation code. In this latter case, the file containing the source code for the compiled class is called a code-behind file, as introduced in Chapter 3 and illustrated in Figure 4-2.