Share via

Introduction to Programming Web Services in Managed Code

  • Article

Using Web services, you can exchange loosely coupled data as XML messages between heterogeneous systems. Although remote access of data and application logic is not a new concept, doing it in a loosely coupled fashion is. Previous attempts, such as DCOM, IIOP, and Java/RMI, required tight integration between the client and the server. Rather than using the XML-based contract that is the basis for Web services, they used binary data formats that are both operating system specific and implementation specific.

While DCOM, IIOP, and Java/RMI 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 that they receive. In other words, the client and server agree to a contract, in this case, a contract that is defined using WSDL and an XSL Schema Definition (XSD). Next, the client and server 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 a text format like XML will allow message exchanges 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.

This technology is retained for backward compatibility with existing applications, and is not recommended for new development. For information about recommended alternatives, see the following:  Windows Communication Foundation Services and WCF Data Services in Visual Studio

Web Services and the .NET Framework

If you create a Web service by using managed code that is based on ASP.NET and the .NET Framework, you are not required to write infrastructure code to handle details such as communication protocols or message transports. Moreover, if you create Web services that use the ASP.NET page framework, your services can use many features of the .NET Framework, such as authentication, caching, and state management.

In the ASP.NET application model, Web pages use the .aspx extension. To differentiate Web services from regular ASP.NET pages, Web services use the .asmx extension.

To facilitate a two-way exchange of data by using Web services, a developer must:

  • Create a Web service. When you create an XML Web service, you create an application that exposes functionality to XML Web service clients.

  • Access a Web service. When you access a Web service, the client application locates, references, and uses the functionality that is contained in the Web service. The client of an XML Web service is typically an application. This application can send, receive, and process messages to and from the Web service.

  • The same developer does not necessarily create a Web service and then access it. Some Web services, for example, a traffic information service, might be created by a single entity (for example, the State Department of Transportation). However, this service might be accessed by many Web sites, such as Web sites for freight delivery companies.

Web services can be stand-alone applications or sub-components of a larger Web application. For example, suppose that you create a Web application that sells books online. Your Web application might use Web services as follows:

  • Create a Web service. Your application exposes its order processing logic as a Web service. Your affiliate Web sites access this service in Web applications that sell books online.

  • Access a Web service. Your application accesses a Web service that was developed by another online company that specializes in writing book reviews for online booksellers. When a visitor to your online store views the price of a particular book, they see the reviews of that same book on the same page.

Remember, you can access Web services from many different types of applications, including other Web services, Web applications, Windows applications, and console applications. However, the client must be able to send messages to the Web service.