.NET & XML

HTTP

Most web services, although by no means all, use the Hypertext Transfer Protocol, or HTTP, as their transport mechanism. The reason for this goes back to the roots of Web Services.

Web Services was conceived as a way to use the Internet, and specifically the World Wide Web, to perform more sophisticated tasks than it was originally intended for. The Web did support some rudimentary abilities to perform distributed processing via its Common Gateway Interface (CGI) protocol, but CGI was really intended to act as a gateway to other applications running on a web server or externally. Granted, these applications could do some interesting things, but their input was limited to HTTP POST or GET variables, and their output was limited to HTML or other formats that a web browser could interpret.

Web Services grew out of the idea that input and output could both be specified in XML, and the processing could be done by an application other than a web server. To get around the firewalls that some corporations use to block other types of traffic, many web services use the Internet port reserved for HTTP traffic; in fact, Web Services communication is HTTP traffic.

Although, as the W3C’s definition makes explicit, a web service is uniquely addressable via a URI, a single web service may provide multiple functions. The actual function being invoked is determined at a higher-level protocol.