Introduction to Programming Web Services in Managed Code

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, 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 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 Web services using the ASP.NET page framework, enabling these 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 Web services in managed code, developers can focus on creating or accessing 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 Web services from regular ASP.NET pages, Web services use the .asmx extension.

There are two fundamental roles when working with Web services:

Creating a Web service — When you create an XML Web service, you are creating an application that exposes functionality to XML Web service clients.

Accessing a Web service — When you access a Web service, your client application locates, references, and uses the functionality contained within a separate 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 Web service. However, the minimum requirement is that the client must be able to send messages to the Web service. This includes all applications using the .NET Framework.

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 Web services as follows:

Creating Web service — Your application exposes its order processing logic as a 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 Web service — Your application accesses 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.