ASP.NET in a Nutshell

Chapter 4. Web Services

The primary purpose of ASP.NET web services is to provide access to application functionality through standard web protocols (including HTTP and XML), regardless of the application’s location or the platform on which it is built. When your application exposes functionality as a web service, that functionality can be consumed by clients on any platform, presuming the clients understand XML and SOAP and can communicate via the HTTP protocol. More plainly, a web service is a function that is called over the Internet.

An ASP.NET web service can be very simple or it can provide complex functionality. It can return a variety of data types -- from simple strings and integer values to complex data types such as classes and datasets. Web services are traditionally thought of as providing only business services (e.g., you call a method, perhaps passing in some parameters, and you receive a return value), but there’s no reason why you can’t create a web service that returns a chunk of HTML. Doing so would allow you to provide cross-platform access to functionality similar to that provided by ASP.NET Server Controls.

Standards

The ability of web services to fulfill their mission of providing cross-platform interoperability and application integration depends on a number of existing and emerging standards and specifications. The following list describes the most important standards, including their current standardization status. Note that the W3C term for a stable standard is Recommendation.

HTTP (Current version 1.1, Recommendation; http://www.w3.org/Protocols)

HTTP is the standard protocol of the World Wide Web. HTTP is essential to web services because most organizations allow communication over TCP port 80 (the default HTTP port) to traverse their firewalls. This contrasts with protocols such as DCOM, which use ports that are routinely blocked -- making them virtually useless for the Internet.

XML (Current version 1.0, Recommendation; http://www.w3.org/XML)

eXtensible Markup Language (XML) provides a standardized way of structuring and communicating data via a tag-based text syntax. Combined with the XML Schema standard, XML allows simple and complex data types to be serialized and deserialized to text for transmission over an HTTP connection.

SOAP (Current version 1.1, Submission; http://www.w3.org/2000/xp)

Simple Object Access Protocol (SOAP) is an emerging standard that specifies how to format RPC-style requests and responses using XML and communicating over HTTP. SOAP is essential to web services. See the sidebar What is SOAP? in Chapter 2, for more information on the SOAP protocol status and its impact on developing web services.

WSDL (Current version 1.1, Submission; http://www.w3.org/TR/wsdl.html)

Web Services Description Language (WSDL) is a specification for creating XML schemas that describe a web service. This description is analogous to a COM type library in the sense that a WSDL file provides a contract of the publicly exposed members of a web service, just as a type library does for a COM object. By reading the WSDL contract for a web service, clients can learn what methods are exposed by the web service and how to call them.

UDDI (http://www.uddi.org)

Universal Description, Discovery, and Integration (UDDI) is an open platform-neutral framework being developed by Microsoft, IBM, and other vendors to address the need for a way to publish, locate, and integrate web services simply and robustly. Web service developers can register their web services with one of the UDDI directories, and potential clients can search the UDDI directory for web services appropriate to their needs.

SOAP, WSDL, and UDDI are not settled standards. Thus, incompatibilities between different implementations of SOAP and web services are possible if those implementations use different drafts of a given standard. A good example of this possibility is WSDL, which is a successor to an earlier draft specification called SDL. Because of incompatibilities between SDL and WSDL, communicating between a client using SDL and a web service using WSDL (or vice-versa) will probably require some tweaking to achieve interoperability. As specifications such as SOAP and WSDL work their way through the standards process (or in the case of vendor specifications, as they gain acceptance), instances of incompatibility should become rarer.