A fine site

Consuming a WCF Service with jQuery or ScriptManager

Leave a comment

I recently created a working example of WCF service that is consumed by both a jQuery AJAX call and a ScriptManager AJAX call. I was interested to see how the WCF improvements offered by .NET 4 compared with the latest jQuery library (v1.7.1 at the time of writing). You candownload the solution’s source code or take a look through this post where I discuss the particulars of this comparison.

Before delving into the code I want to point out a few things; (1) I’ve cut out all of the extraneous code from this sample so what’s included is the bare essentials in order to get the sample working (unless otherwise indicated), (2) this post assumes you are familiar with WCF, AJAX, jQuery, and ScriptManager, and (3) I have avoided implementing a DataContract, again to keep it simple.


There are two projects in this solution, an ASP.NET Web Application which contains the jQuery and ScriptManager calls, and the Class Library which serves as the Service Library. The web application references the service library.

The solution’s source code ( can be downloaded via Google Docs.

Service Library

For good practice I decoupled the service implementation from the presentation layer, hence having two projects rather than just the one web application. A much simpler alternative, recommended for very small projects, is to create an “AJAX-enabled WCF Service” item within the web application. This would actually have been fine but I wanted to expose a service within my web application that mapped to my WCF Service Library’s service and this wouldn’t have been possible with the aforementioned approach. In addition, I created a Class Library rather than a WCF Service Application as I prefer to add project code myself and not have to strip out a lot of unnecessary Visual Studio template code.

The Service Library contains a simple service with one method; GetAllCountries(), which accepts no parameters and returns a JSON-formatted response of country names. Note that I don’t have to explicitly state the response format as JSON is the default.



1 namespace ServiceLibrary.Countries
2 {
3     [ServiceContract(Namespace = "Countries")]
4     public interface IEurope
5     {
6         [OperationContract]
7         List GetAllCountries();
8     }
9 }




01 namespace ServiceLibrary.Countries
02 {
03     public class Europe : IEurope
04     {
05         public List GetAllCountries()
06         {
07             List allCountries = new List();
09             allCountries.Add("Albania");
10             allCountries.Add("Andorra");
11             // More countries added.
12             allCountries.Add("United Kingdom");
13             allCountries.Add("Vatican City");
15             return allCountries;
16         }
17     }
18 }


Web Application

There is a short-list of files in the web application, the most important being the one which maps the AJAX calls to the Service Library; Europe.svc.



1 <%@ ServiceHost Service="ServiceLibrary.Countries.Europe" Factory="System.ServiceModel.Activation.WebScriptServiceHostFactory"%>


This one simple line has the Service attribute pointing at the Service Library service; Europe. Followed by the Factoryattribute that references the WebScriptServiceHostFactory which “automatically adds an ASP.NET AJAX endpoint to a service, without requiring configuration, in a managed hosting environment that dynamically activates host instances for the service in response to incoming messages” – MSDN.



1 <?xml version="1.0"?>
2 <configuration>
3     <system.web>
4         <compilation debug="true" targetFramework="4.0" />
5     </system.web>
6 </configuration>


If you’ve had some experience with WCF you’ll notice the most obvious difference is that there is absolutely no endpoint configuration settings. I’ve read, and been told, that you still need to keep the <standardendpoints> node and it’s child nodes, however I removed this from the solution and noticed no difference. The default values are adequate for this solution and the WebScriptServiceHostFactory does the remainder of the heavy lifting – you can start to see how much easier this is. Don’t get me wrong, I’d still recommend that developers implementing this type of code have a solid grasp of the ABCs of WCF as there are a lot of WCF considerations to address once you move away from your basic web application – security, performance, maintainability etc.


Before I get into the JavaScript you can see that the <body> only contains a button, and a div for outputting my responses. The header contains a jQuery reference followed by a single function which is called by the buttons onclick event and performs the asynchronous HTTP request: $.ajax.



01 <%@ Page Language="C#" AutoEventWireup="true" CodeBehind="jQuery.aspx.cs" Inherits="WebApplication.jQuery" %>
02 <html>
03 <head>
04     <title>jQuery</title>
05     <script src="Resources/JavaScript/jquery-1.7.1.min.js" type="text/javascript"></script>
06     <script type="text/javascript">
07         //<![CDATA[
09         function Test()
10         {
11             $.ajax(
12             {
13                 type: "POST",
14                 contentType: "application/json;charset=utf-8",
15                 url: "Services/Countries/Europe.svc/GetAllCountries",
16                 data: null,
17                 dataType: "json",
18                 beforeSend: function (jqXHR, settings)
19                 {
20                     $("#divOutput").append("<br/>Before send...");
21                 },
22                 success: function (response, status, jqXHR)
23                 {
24                     // The ".d" property is the name for the name/value JSON response.
25                     for (i in response.d)
26                         $("#divOutput").append("<br/>" + response.d[i]);
28                     $("#divOutput").append("<br/>Success.");
29                 },
30                     error: function (jqXHR, status, error)
31                 {
32                     $("#divOutput").append("<br/>Error " + jqXHR.responseText);
33                 },
34                 complete: function (jqXHR, status)
35                 {
36                     $("#divOutput").append("<br/>Complete " + status + ".");
37                 }
38             });
39         }
41         // ]]>
42     </script>
43 </head>
44 <body>
46     <h1>Using jQuery</h1>
48     <form runat="server">
50         <p>
51             <input type="button" value=" Test " onclick="return Test();" />
52         </p>
54         Output:
55         <div id="divOutput"></div>
57     </form>
59 </body>
60 </html>


The jQuery AJAX API has an array of functions and methods, some of which are employed in the code above. There is one API function in particular; beforeSend which isn’t required but I’ve included it as it shows that you can use it to start up a loading animation, for example, while you’re waiting to receive an asynchronous response.

As the code reads – a click event fires a call to the JavaScript Test() method which makes an asynchronous AJAX POST request to GetAllCountries() exposed by the web application’s service mapping, which in turn calls the Service Library’s (similarly named) operation contract. The response returned is then dynamically inserted into the specified<div>. I’ve purposefully excluded posting any request data as I wanted to keep this simple. Once everything is wired up you can see it’s not too difficult to implement or understand.


Contained within the System.Web.Extensions assembly (System.Web.UI namespace) is the ScriptManager class which “manages ASP.NET Ajax script libraries and script files, partial-page rendering, and client proxy class generation for Web and application services” – MSDN. It’s a powerful resource, which like jQuery, cuts down on a significant amount of development time and heavy lifting. You can see the tag at the bottom of the following code sample, referencing the web application’s .svc file. This allows you to make an asynchronous call to the GetAllCountries() method as illustrated in the JavaScript’s Test() function.



01 <%@ Page Language="C#" AutoEventWireup="true" CodeBehind="ScriptManager.aspx.cs" Inherits="WebApplication.ScriptManager" %>
02 <html>
03 <head>
04     <title></title>
05     <script type="text/javascript">
06         //<![CDATA[
08         function Test()
09         {
10             Countries.IEurope.GetAllCountries(OnRequestComplete, onError);
11         }
13         function OnRequestComplete(response, state)
14         {
15             for (i in response)
16                 document.getElementById("divOutput").innerHTML += "<br/>" + response[i];
17         }
19         function onError()
20         {
21             document.getElementById("divOutput").innerText = "Error";
22         }
24         // ]]>
25     </script>
26 </head>
27 <body>
29 <h1>Using ScriptManager</h1>
31     <form runat="server">
33         <p>
34             <input type="button" value=" Test " onclick="return Test();" />
35         </p>
37         Output:
38         <div id="divOutput"></div>
40          <asp:ScriptManager runat="server">
41              <Services>
42                  <asp:ServiceReference Path="~/Services/Countries/Europe.svc" />
43              </Services>
44          </asp:ScriptManager>
46     </form>
47 </body>
48 </html>


The first thing that stands out when comparing the two methods is the amount of coding required. ‘Yes’ you don’t get a nicebeforeSend type method with ScriptManager but look at how much less code there is.

If you look at the ScriptManager.aspx page’s source code from within your browser you’ll see (not too far from the bottom) a script reference to the web application’s service file:


1 <script type="text/javascript" src="Services/Countries/Europe.svc/jsdebug"></script>


If you enter this into the browser’s address bar you’ll get back some script which contains the JavaScript proxy code that does the bulk of the work. You can see how this dynamically generated code is tucked away so you can focus on what’s important when building your solution. If you remove the “debug” part from the end of the srcattribute’s value so you only have:


1 <script type="text/javascript" src="Services/Countries/Europe.svc/js"></script>


You’ll notice that you get back the JavaScript less the debugging code.

Comparison of jQuery and ScriptManager

Which approach is “better”? Personally I think it depends on a number of factors such as the technologies you’re encouraged to include (or avoid), the technical skills inherent to the developer building this part of your solution, whether you need to implement one of the additional jQuery.ajax() methods not made available via ScriptManager etc. At the end of the day it’s nice to know there is more than one option available when making WCF service calls from JavaScript. And I don’t see jQuery or ScriptManager disappearing anytime soon so both approaches are certainly future-proof … for the next few years anyway.

Download Source Code

The solution’s source code ( can be downloaded via Google Docs.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s