Partager via


Building XML Web Services Using ASP.NET

Building a simple XML Web service using ASP.NET is relatively easy and is covered in Building XML Web Services Using ASP.NET Basics. However, the true power of XML Web services is realized when you look at the infrastructure. XML Web services are built on top of the .NET Framework and the common language runtime. An XML Web service can take advantage of these technologies. For instance, the performance, state management, and authentication supported by ASP.NET can all be taken advantage of by building XML Web services using ASP.NET.

The infrastructure for XML Web services is built to conform to industry standards such as SOAP, XML, and WSDL, and this allows clients from other platforms to interoperate with XML Web services. As long as a client can send standards-compliant SOAP messages, formatted according to a service description, that client can call an XML Web service created using ASP.NET (regardless of the platform on which the client resides). For more information on how ASP.NET provides an attribute-based mechanism for modifying the format of the expected SOAP, see Customizing SOAP Messages.

When you build an XML Web service using ASP.NET, it automatically supports clients communicating using the SOAP, HTTP-GET, and HTTP-POST protocols. Since HTTP-GET and HTTP-POST support passing messages in URL-encoded name-value pairs, the data type support for these two protocols is not as rich as that supported for SOAP. In SOAP, which passes data to and from the XML Web service using XML, you can define complex data types using XSD schemas, which support a richer set of data types. Developers building an XML Web service using ASP.NET do not have to explicitly define complex data types they expect using an XSD schema. Rather, they can simply build a managed class. ASP.NET handles mapping class definitions to an XSD schema and mapping object instances to XML data in order to pass it back and forth across a network.

It is important to note that XML Web services are not a replacement for DCOM, but rather a messaging infrastructure for communicating across platforms using industry standards.

In This Section