Understanding XML-Based Web Services

For many years, developers have sought ways to reuse the products of their work and to bring together disparate systems that their organizations have already invested in to form a cohesive whole. This quest has been fraught with difficulties, ranging from dissimilar platforms and systems with no common standard for communication to security measures that prevented potential clients outside a corporate network from being able to use existing functionality.

Precursors to Web Services

Early on, remote procedure calls (RPC) were used as a way to allow one machine to use functionality on a remote machine. RPC involved calling a function on a client machine, and passing parameter information to the server, which in turn passed result and status information back to the client. While RPC did in fact work, it required at least one developer on the team who understood the somewhat arcane world of Interface Definition Language (IDL). Distributed COM (DCOM) offered a somewhat easier-to-use solution, but both RPC and DCOM required opening normally unopened ports in corporate firewalls, and the binary nature of the communications between client and server (also known as the wire format) caused problems when, for instance, integer sizes or internal byte ordering differed from machine to machine. Even with two Windows machines communicating using DCOM, configuration problems caused many a veteran programmer to give up on DCOM.

Some of the solutions for these difficulties have included creating custom Web front ends for existing functionality, or using proprietary communications and/ or packaging technologies to bridge the gap between systems. The former solution worked well in some situations, but the organization hosting the application had to create and maintain a UI for the functionality that they made available, as well as creating a front end for any additional functionality added later. Moreover, this UI might or might not fully meet the needs of their existing and/or future clients. The use of proprietary communications or bridging software typically meant greater expense, reliance on a single vendor, and dependence on that vendor’s maintenance and upgrades. XML-based Web services address both of these issues squarely, allowing programmatic functionality to be exposed without the need for a custom Web-based UI, and without the need for proprietary bridging software.

Web services are discrete units of programmatic functionality exposed to clients via standardized communication protocols and data formats, namely HTTP and XML. These protocols and formats are both well understood and widely accepted. (While XML is still a relatively immature technology, it has rapidly gained acceptance in the industry because of its promise as a bridging technology.) By communicating over HTTP, Web services overcome the problem of communicating across the Internet and across corporate firewalls without resorting to proprietary solutions that require additional communications ports to be opened to external access. Because Web services use XML for the formatting of requests and responses, they can be exposed from and consumed by any platform that can format and parse an XML message. This allows XML-based Web services to bring together disparate pieces of functionality—existing or new, internal or external to an organization—into a coherent whole. The following illustration shows how XML-based Web services can bring together a variety of applications and platforms. Note that because XML-based Web services can communicate over standard protocols such as HTTP, they can work over firewalls. In addition to the interactions shown here, server-to-server Web services calls are also possible.

A client accesses Web services by calling into a listener that is able to provide a contract to describe the Web service and also processes incoming requests or passes them on to other application logic and passes any responses back to the client. The following illustration shows how a Web service application can be layered. You can also use Web services to access both legacy logic and new application logic, or to wrap legacy logic for access by a Web service.

SOAP and Web Services

The SOAP is a key enabler of XML-based Web services as a strategy for application integration and Internet-based software services. SOAP is an XML-based messaging protocol that’s being standardized by the World Wide Web Consortium (W3C) and has wide support from a variety of vendors. The SOAP specification provides a mandatory format for SOAP messages (referred to as SOAP envelopes), as well as optional standards for data encoding, request/response processing, and binding of SOAP messages to HTTP.

SOAP and XML-based Web services are too complicated to cover in a single chapter. Fortunately, one of the advantages of the ASP.NET programming model is that it abstracts the complexity of SOAP messaging from the development of Web services.

Additional Needs for Web Services

As mentioned earlier in this chapter, a Web service is nothing more than a way to provide discrete units of application functionality over standard Web protocols using a standardized message format. To be truly useful, however, Web services also need to provide the following:

• A contract that specifies the parameters and data types it expects, as well as the return types (if any) that it sends to callers

• A facility for locating the Web service or a means of discovering Web services offered by a given server or application, and the descriptions of those services

The next several sections will examine creating, advertising, locating, and consuming Web services from the standpoint of an ASP.NET Web developer.