Today I’ll set up a simple application to demonstrate how easy it is to consume a WCF service through a Javascript Library, the popular Jquery to be exact. We opt for this approach as Jquery uses ajax calls for these things which are asynchronous and it limits the postbacks to the server (as Javascript is ran client side).

So let’s get started:

First, you can get JQuery over at the Jquery website: jquery.com

Once we have that we’ll start up a new project in visual studio. Create a folder scripts, and a folder services and add a new wcf service to the solution (in the services folder). Add the jquery script to the scripts folder.
Once you’ve done that, your solution would look like this:

Normally the wcf should be configured to run on the fly. You can test it by running the solution (press F5 ).
Once it’s running, surf to http://localhost:portnumber/services/restwcf.svc
If you get a result like the one below it is configured successfully:

If you get an error, there is most likely a configuration option missing in the web.config file. I’ve added a download link to the project below so you can see for yourself how the web.config in the solution I created looks like.

Note: if you want to test it by publishing it to your local iis machine, make sure that wcf is installed. It comes with the .net framework 3.0 and upwards but isn’t configured automatically for iis. You can do it very easily in msdos though (start=> run => cmd.exe )
Screen below includes the easy to follow steps:

Next, we’ll add a class file to our solution in the services folder named datacontracts. We’ll build the class we are sending to our Jquery in there.
I’ve written a small class named Beer (guess what it’ll contain eh? ) in the datacontracts file. That’ll contain the data we’ll send over our WCF.

I’ve implemented the IXmlSerializable Interface here so we can determine what we send back ourselves. If you leave it out, the object will get serialized into xml and sent instead(as long as you keep the Serializable attribute there ). In order to get the interface I added a using System.Xml.Serialization;
The first two functions I’ve left empty, as we are only going to do a get (readxml takes care of the post), and we won’t be needing no schema as we’ll know what’s coming our way.

Next up I’ve added a function call to the Irestwcf.cs file (our interface to our service):

The WebGet attribute tells our wcf (and us) how we will call the function (http://localhost/Services/RestWcf.svc/Beers )
In order to access the Webget I’ve added the using System.ServiceModel.Web namespace. In my case it didn’t take from the first go and I had to add the namespace as a reference to my solution first (references, add reference and search for it ).
Which just leaves us our actual service and that part is done with;


I’ve added the Activation namespace so I can add in the 2 attributes you see above.

Note: The first attribute tells us that it’ll act in ASP.Net mode (so we can send http commands to it, think ASMX services ). The second attribute tells the service to create (and destroy!) an object of the service for every call we make, rather than one for each session. (so 2 calls is 2 objects created and destroyed). If we set it to single it’ll only be created once. You can find more information about these attributes on msdn.

We just send back a new Beer object (that’ll trigger the WriteXml property in our datacontracts).
I also changed some things around in the Web.config file under the system.servicemodel section:

Mainly I added the endpointbehaviour section, and changed the first endpoint’s binding to webhttpbinding instead of wshttpbinding (as we’ll be using http instead of https) and adding the behaviorconfiguration attribute.
Once all this is done (Congratulations on configuring a wcf service by the way), and you surf to the url, you should get something like this:

So far, so good. Now for the really juicy bit, namely setting up Jquery to grab that xml (and do something silly with it! )
For this we’ll turn our attention to the default.aspx page in our solution. Add a reference to the jquery script file you added and add a script block (we’ll add our code in there ).

As you can see I’ve added a function RunMe in the script block and a button (note the absence of the runat=”server” attribute, meaning that little trooper ‘ll run on the client side baby!).  Go ahead, run the page and click the button. If all goes well the page will throw you a messagebox stating it’s being run. This means we enter the function, which is good as we’ll do the work there. The main culprit we’ll be using for our call to our webservice is the ajax() function (information can be found here: http://api.jquery.com/jQuery.ajax/ )
I’ve added the code snippet below:

After adding, click the page again.

If you get the above, success! You did it (Yes I know the table formatting borked out. Guess the html engine had a little too much beer there)!

A small side note however: the $.ajax call is prone to failure (as it is still case sensitive) so careful debugging is of the essence here.

Second side note: the find function I call in the script takes care of empty xml tags. If I should have left a tag empty (go ahead and play around with it), it’ll return me an empty value, which will show up as empty on the screen too. It won’t blow up on that so feel free to drop those null value checks you were implementing.

Well, that’s all folks.
Next time I’ll talk abit about the EXT.js framework and it’s EXT.NET derivate.

About Kris

Software Engineer. Mainly working with ASP.NET(C#), Javascript (ext.js & jquery) and WCF