Mono WCF Advent Day 10: ASP.NET AJAX Integration

Well, yes, it continues a bit more...

Yesterday I explained WebHttpBinding which is dedicated to REST world. It is however just one aspect of the new REST support in .NET 3.5. Here is another one - you can invoke remote WCF services from ASP.NET AJAX.

Javascript proxy generator

What's done here is, basically the same as what ASP.NET AJAX do for System.Web.Services asmx support. In asmx integration land, there is Javascript proxy generator that accesses to the remote service and returns server responses back to Javascript land. The Javascript proxy source is retrieved at http://your.host.name/service.svc/js or http://your.host.name/service.svc/jsdebug (with debugging info).

The implementation is in ProxyGenerator class in ASP.NET AJAX assembly (System.Web.Ext.dll). By using ProxyGenerator.GetClientProxyScript() method, you can see how the raw Javascript proxy code is generated from your service contract, without actually deploying your service at your host.

It matches the Javascript code that you can see at somewhere like: http://your.host.name/service.svc/jsdebug

WebScriptEnablingBehavior

The next question is, how to provide such Javascript proxy at ./js or ./jsdebug for each service (endpoint). When there are two or more services, there will be two or more js proxies (foo.svc/js and bar.svc/js).

To resolve this, there is "WebScriptServiceHostFactory" which adds support for those js proxies for each service endpoint. It internally uses WebScripeEnablingBehavior which is derived from WebHttpBehavior. When WebScriptEnablingBehavior is attached to a service endpoint, it adds a special request "dispatcher" (precisely, EndpointDispatcher) to the host to handle requests to ./js or ./jsdebug as to return js proxy string.

I don't explain the mechanism a lot here, but in case you are curious, ChannelDispatcher, EndpointDispatcher and DispatchRuntime have a lot of customizible things at service host.

(In my previous post, I didn't explain much about WebHttpBehavior, an implementation of IEndpointBehavior. It actually plays the primary role on the REST binding support such as, setting "message formatter" to serialize request parameters using JSON serializer, to bind to and generate parameters from "URI template", etc. etc.)

Anyways, now we have a dedicated endpoint for Javascript for each service endpoint from the service instance. The service instance should be adjusted to use WebHttpBinding which is configured to use JSON as its message format so that the service can communicate with the JS proxy running in users' browser.

ASP.NET hosting

The entire service host setup above is valid to standalone ServiceHost too. But it does not make sense to do so - the primary purpose of those js proxies is reference from ASP.NET AJAX web pages. Hence there is almost no use for standalone hosting.

I don't write a lot to explain how to use <asp:ServiceReference > and proxies in your ASP.NET AJAX web page (Javascript) here - our bug #525575 shows simple usage.