In my spare time at conferences and training sessions, I often get asked questions regarding AJAX. Most of the time, these are about the role of partial rendering, tricks to optimize it, and the architectural points it misses out. The remark that sparked off this article regards the ASP.NET AJAX implementation of services.

In recent months, I have witnessed a common misconception about services in ASP.NET AJAX. These services – many think – are not pure REST services, and worse yet they use SOAP under the hood. That ASP.NET script services are not pure REST is an acceptable and largely correct statement. Microsoft itself recognizes this implicitly by telling us that it’s working on REST data services in project Astoria (more on this later). On the other hand, the idea that ASP.NET script services use SOAP internally is simply incorrect.

How to build services in ASP.NET?

A script service is a remote piece of code that resides on the Web server in the same domain – often, in the same application – as the caller page. The service is reachable via HTTP and is backed by a runtime environment that knows how to serialize and deserialize data to and from the Web client. How would you build such a service in ASP.NET? More importantly, how would you do it without heavily restructuring the runtime of ASP.NET? You don’t need to look far, there’s just one option in the .NET Framework 2.0 and two options if you move up to consider the newly released .NET Framework 3.5.

The first option entails using an ASP.NET Web service to implement the remote service. In this case, the URL for client scripts to connect is an ASMX endpoint. Behind this endpoint, you have a live instance of a class that derives from WebService.

The second option is only supported in ASP.NET 3.5 and requires that you expose any needed interface through a Windows Communication Foundation (WCF) service. This service will be hosted in IIS and reached via HTTP. In this case, the endpoint is a SVC resource that binds to an instance of a managed class with the contracted interface.

The first aspect to dig out here is the use of the term ASP.NET Web service. We’re not talking about WS-* Web services hosted on a Web server and communicating through HTTP POST packets padded with SOAP envelopes. What developers are called out to create are in effect just classes nearly identical to classic SOAP-powered Web services:

using System.Web.Services;
[ScriptService]
public class TimeService : WebService
{
	[WebMethod]
	public DateTime GetTime()
	{
		return DateTime.Now;
	}
}

The devil is in the detail, though. Have you noticed the [ScriptService] attribute that boldly decorates the class definition? That’s the key that radically changes the runtime behavior of the resulting class even when that class is deployed behind an ASMX endpoint.

Another fundamental element to consider is the following fragment excerpted from the web.config file of an ASP.NET AJAX application:

<httpHandlers>
	<remove verb=”*” path=”*.asmx” />
	<add verb=”*” path=”*.asmx”
		validate=”false”
	type=”System.Web.Script.Services.
		ScriptHandlerFactory…” />
</httpHandlers>

The first node underneath the <httpHandlers> section removes any HTTP handlers that are installed for ASMX resources, including the standard handler that ASP.NET installs to serve ASMX requests for SOAP-powered Web services. The second node adds a new handler for ASMX requests defined by the ASP.NET AJAX framework. This short excerpt demonstrates that in spite of the appearances ASMX requests are handled differently in ASP.NET AJAX.