ASP.NET XML Web Service Basics
This topic is specific to a legacy technology. XML Web services and XML Web service clients should now be created using Windows Communication Foundation.
Since ASP.NET provides the infrastructure for the inner workings of a Web service, developers can focus on implementing the functionality of their specific Web service. Enabling a Web service using ASP.NET entails creating a file with an .asmx file name extension, declaring a Web service in that file and possibly another file, and defining Web service methods. The procedures are listed in Walkthrough: Building a Basic XML Web Service Using ASP.NET and are elaborated upon here.
Declaration of Web Services
When you create a Web service in ASP.NET, you place the required @ WebService directive at the top of a text file with an .asmx file name extension. The presence of the .asmx file and the @ WebService directive correlate the URL address of the Web service with its implementation. You also implement the Web service class that defines the methods and data types visible by Web service clients.
The Web service class you define can be included directly in the .asmx file, or in a separate file. If you use a separate file, it must be compiled into an assembly. Optionally, you can apply a WebService attribute to the class that implements the Web service. The class that implements the Web service can derive from the WebService class.
By applying the optional WebService attribute to a class that implements a Web service, you can set the default XML namespace for the Web service along with a string to describe the Web service. It is highly recommended that this default namespace, which originally is http://tempuri.org, be changed before the Web service is made publicly consumable. This is important because the Web service must be distinguished from other Web services that might inadvertently use the namespace as the default (<http://tempuri.org/>).
Classes that implement a Web service created using ASP.NET can optionally derive from the WebService class to gain access to the common ASP.NET objects, such as Application, Session, User, and Context. The Application and Session properties provide access to storing and receiving state across the lifetime of the Web application or a particular session. For more information on state management, see How to: Manage State in Web Services Created Using ASP.NET. The User property contains the identity of the caller, if authentication is enabled, for the Web service. With the identity, a Web service can determine whether the request is authorized. For more information on authentication, see Securing XML Web Services. The Context property provides access to all HTTP-specific information about the Web service client's request. For more information on the Context property, see WebService.Context Property.
Definition of Web Service Methods
Methods of a class that implement a Web service do not automatically have the ability to receive Web service requests and send back responses, but with Web services created using ASP.NET, it is very simple to add that capability. Apply a WebMethod attribute to public methods. Methods of a Web service class that can be communicated with over the Web are called Web service methods.
Web service methods are a key part of the messaging infrastructure employed by Web services. That is, a client and a Web service communicate using messages, specifically SOAP messages, by default. Clients send a SOAP request to a Web service and a Web service method typically returns a SOAP response. Web services define the type of messages they accept using operations, as defined by Web Services Description Language (WSDL). These operations correlate to each of the Web service methods within a Web service. Even though each of these Web service methods are defined in ASP.NET using a method of a class, it is important to realize that the data that is eventually communicated over the network must be serialized into XML. As such, it is important to remember that Web services are not a replacement for DCOM, but rather a messaging infrastructure for communicating across platforms using industry standards.