لطفا منتظر باشید ...
Publisher4.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 restfrom packaging and unpackaging SOAP
requests to automatically providing HTML documentation of the web
serviceif it is called from a web browser (rather than by a
SOAP request).Figure 4-1 illustrates how an ASP.NET web service
works.
Figure 4-1. Inside an ASP.NET web service
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 fileChapter 3 and illustrated in Figure 4-2.
Figure 4-2. How code-behind works
