Introduction to Programming XML Web Services in Managed Code
XML Web services make possible the exchange of data in the form of XML messages between heterogeneous systems. Although remote access of data and application logic is not a new concept, doing so in a loosely coupled fashion is. Previous attempts, such as DCOM, IIOP, and Java/RMI, required tight integration between the client and the server and used platform and implementation specific binary data formats. While such protocols require a particular component technology or object-calling convention, XML Web services do not. The only assumption made between the client and the server is that recipients will understand the messages they receive. In other words, the client and server agree to a contract, in this case described using WSDL and XSD, and then communicate by generating messages that honor the contract over a specified transport like HTTP. As a result, programs written in any language, using any component model, and running on any operating system can access XML Web services. Furthermore, the flexibility of using a text format like XML makes possible the message exchange to evolve over time in a loosely coupled way. This loose coupling is mandatory in environments where the simultaneous updating of all parties in the message exchange is not possible.
You create XML Web services using the ASP.NET page framework, enabling these XML Web services to access the many features of the .NET Framework, such as authentication, caching, and state management. Because ASP.NET and the .NET Framework are the basis for XML Web services in managed code, developers can focus on creating or accessing XML Web services without needing to write infrastructure code.
In the ASP.NET application model, Web pages intended for the browser use the .aspx extension. To differentiate XML Web services from regular ASP.NET pages, XML Web services use the .asmx extension.
There are two fundamental roles when working with XML Web services:
Creating an XML Web service — When you create an XML Web service, you are creating an application that exposes functionality to XML Web service clients.
Accessing an XML Web service — When you access an XML Web service, your client application locates, references, and uses the functionality contained within a separate XML Web service. The client of an XML Web service is typically an application that is able to send, receive, and process messages to and from the XML Web service. However, the minimum requirement is that the client must be able to send messages to the XML Web service. This includes all applications using the .NET Framework.
XML Web services can be either stand-alone applications or sub-components of a larger Web application. For example, suppose you are creating a Web application that sells books online. Your Web application might interact with XML Web services as follows:
Creating an XML Web service — Your application exposes its order processing logic as an XML Web service, which your affiliate Web sites can in turn use in their Web applications to sell books through your online store without requiring their customers to visit your site.
Accessing an XML Web service — Your application accesses an XML Web service provided by another online company that specializes in writing and supplying book reviews for online booksellers. When a visitor to your online store views the details of a particular book, they also see the reviews of that book on the same page.
Remember, XML Web services are accessible from just about any other kind of application, including other XML Web services, Web applications, Windows applications, and console applications. The minimum requirement is that the client must be able to send messages to the XML Web service.