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
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
Figure 4-1 illustrates how an ASP.NET web service works.
In terms of file structure, web services in ASP.NET are implemented
.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
attribute in its
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.