The WCF "Orcas" release (the WCF from .NET Framework 3.5 aka WCF 2.0) makes it so much easier to use your WCF service in conjunction with ASP.NET AJAX (formerly known as ‘Atlas’).
Before Orcas you would build a AJAX enabled (web) service by adding the [ScriptService] attribute to the service class.
Notice the /js that is appended at the end. That bit is the work of the ScriptService attribute. You do not have to add the script element manually, but get that automatically when you add a service reference to the ScriptManager control in your page.
Before anything will work all .asmx requests in an AJAX-enabled website are redirected to a different handler:
So, when you send some JSON data over the wire, it is very easy to start working with that data.
This is quite a bit of work, right?
Support for calling WCF service from the client stack
Visual Studio 2008 has WCF AJAX support, meaning that the ScriptManager understands these types of services and new templates like the AJAX-enabled WCF service. The latter will automaticaly create the correct configuration and corresponding skeleton code.
Enabling a WCF service for AJAX is a decision you can make at deployment time. So, you can call into any regular WCF service from AJAX without making any changes to your implementation. You do need to make some changes, which vary based on your hosting scenario.
Let’s assume you have an IIS hosted WCF service. You need to edit the ServiceHost directive in the .svc file and specify a different ServiceHostFactory implementation, like so:
Here WebScript actually means AJAX-enabled.
When you host the WCF service yourself, you should edit your configuration file to enable JSON support.
So, why would you switch to WCF services instead of ASMX services?
- The separation of contract and binding:
Because the service contract and the binding are separated it will line you up better for future versions of encoding or . You will only need to change the configuration file to hook up e.g. some JSON version 2 (which might become reality to fix the recent security vulnerabilities in JSON v1). Or, you can add an application layer to expose the same service simultaneously as an AJAX and a SOAP service.
- The cool features of WCF:
How are you going to protect your ASMX service from Denial of Service (DoS) attacks? In WCF you can protect your service with quotas, throttles and timeouts. There are more manageability options, such as logging, tracing and a whole bunch of performance counters. Think about the extra hosting options (e.g. self-hosted) for WCF services.
Also, Workflow Services in .NET 3.5 allow you to put a workflow inside a service which is behind an AJAX-enabled page. Compared to ASMX you could get performance gains as much as 4 times for large messages (rough estimate and preliminary results). And you get to use the HTTP programming model, such as POX and returning binary data.
- The DataContract data model:
- The future: There has been no investment in new features for ASMX since .NET 2.0 or in Orcas. Will there be for the future?
Finally, here are some characteristics of the WCF AJAX architecture:
- Operation names are in the URL. There are no SOAP actions. A special operation dispatcher makes this happen.
- Parameters in URLs, because no message body is available for GET requests. Again, a special formatter will take care of that.
- JSON parameters in URLs (Atlas-specific) allows for complex types to be passed from the client to the service.