The Web Services Component

The fundamental concept of web services is powerful and continues to evolve and advance. The original SOAP (Simple Object Access Protocol) standard is the use of the HTTP protocol to pass XML-formatted data to the server from a client and receive XML-formatted results in return. This can be from within a web browser using the XmlHttpRequest object or directly from a desktop application or another server. Before web services became widely adopted, it was not uncommon for developers to programmatically request a page as an HTML document and extract the desired data from it, a technique known as screen-scraping. This causes all sorts of frustrations as sites are continually updated and the screen-scraping clients must try to keep up by modifying their parsing code to adapt to the new HTML the target site is rendering.

This produced frustration, as sites that presented data using HTML visual pages were prone to modifying those pages and this would break the screen-scraping program, which expected to see the data in the original format. Web services were created as a nonvisual way to transfer data over the web, and they are the natural way to isolate remote method calls from the presentation layer. Now, instead of screenscraping, you are able to call a web service and get XML-formatted data returned that is easily consumed by a program.

By passing plain text data formatted as XML and by eliminating the visual elements, data passed in web services is much easier to parse than HTML. And, since XML can contain an embedded schema, code can inspect the schema and use it to determine the structure and types used in the data. You can extend the schema passed with the data being returned without worrying that consuming applications will be broken, and therefore XML readers can be somewhat tolerant of modifications that would have certainly caused a screen-scraper a great deal of grief!

The schema for data can be extended without requiring all consumers to be updated. Consumers can easily get the parts of the XML document they wish to process and disregard the rest. This has progressed beyond simple XML formats. Unlike previous implementations of web services, you can now define web service contracts to be built to employ arbitrary encoding and utilize any one of a number of wire protocols. What drives the web service concept is the ability to access data easily from various applications in a loosely coupled way, and the new Microsoft Windows Communication Foundation (WCF) takes this concept to a whole new level, allowing the contract to specify wire protocols, deployment strategies, and logging infrastructure, along with providing support for transactions.

ASP.NET AJAX provides a set of JavaScript proxy objects to access some new web services built-in to ASP.NET. Profile information, membership services, and role management can be easily accessed from the client. Developers don’t need to create their own infrastructure to support these fundamental application services, but can include a few lines of code to take advantage of server resources from JavaScript code running in the browser, thereby dramatically extending the reach of ASP.NET to include both the client and the server. And because the JavaScript libraries are designed to be easy to use for developers already familiar with server-side .NET programming, all of this extra functionality comes in a friendly