I don't know if you've ever tried calling a web service from client script before, but with ASP.NET AJAX it's amazingly simple. In fact, a great deal of the built-in features (such as authentication, my next topic) of ASP.NET AJAX are accomplished through the web services infrastructure inherent to ASP.NET AJAX.
However, there are plenty out there who may never have attempted to call a web service from client script, instead always accomplishing their task with their ASPX pages either through a synchronous or asynchronous page requests. Yet, there are many good reasons to execute a web service from your client script:
- Responsiveness: To render an ASP.NET web page (even one through ASP.NET AJAX) still takes a fair amount of server resources. A great number of controls still must be rendered out and the entire page lifecycle must be executed in order for the response to be generated back to the client. If you want a simple bit of information, why put the strain on your server when you can simply call a basic web service instead?
- Coding Simplicity: Sometimes a web service simply makes more sense than calling a web page. For example, what if you wanted to update a stock ticker on your web page with fresh content every ten seconds. Rather than calling back to the server to process a page that must magically return content that seamlessly updates the stock ticker, the ticker can simply call a web service from the browser and update itself through the browser DOM.
- Cleanliness: Asynchronous behavior is cleaner in a web browser than a full post-back, and a web service, with less data, requires less time to process and will therefore typically return to the client faster.
- Reuse: A web service can be reused many, many times over by many, many different clients. Whether you're writing a desktop application, a script application that runs in your browser, or a legacy UNIX-based mainframe application that leverages pure socket-based programming, one web-service can "service" them all. If you are in the business of implementing stock tickers in web pages, then it makes sense you're likely to use that same application code in other areas; building it as a web-service simplifies the matter (and now that you can easily call it from script code, there's no reason for clumsy shared libraries, etc).
- Mashupability: Mashups are the way of the future - at least for the next year or so until the next way of the future hits the web. A web-service front-end lends itself to mashable behavior much more than some heavy ASPX page. Making your components interact with script increases their overall exposure by allowing them to partake in the new Web 2.0 atmosphere (plus it looks good to your boss too).
Honestly the list could go on and on. I'm sure if you sat and thought you could list off any number of other reasons why updating components on your page using the asynchronous, relatively light-weight nature of web services (at least more so than ASPX pages) wins out over synchronous and asynchronous page-refreshes.
In ASP.NET AJAX it's also wicked simple. The steps are as follows:
- Create a web service,
- Register said web service with the ScriptManager on the ASPX page,
- Call the auto-generated script wrappers for the service and consume the response from the service as properly-typed JavaScript.
I'm going to shamelessly steal the example code from the ASP.NET AJAX sample on using web services for this post because it's about as simple as it gets. So, first we create our web service:

....note the use of the [ScriptService] attribute, this is a must...
Next, we simply register the service address with the ScriptManager that we already have existing on our ASPX page:

And then we simply call an auto-generated script method (scoped the same as the class of the web service method):

To you, the developer, the script method magically appears on the client, ready to use. But, we all know it wasn't magical and there was a great deal of cool work under the hood to make all of this come to life. Just how this works, and how you can leverage it best in your applications, will follow over the next couple days.....