Alex Thissen Weblog Build 1.15.10.1971 : AJAX

Combining AJAX and WCF 2.0

Alex Thissen — Fri, 21 Mar 2008 20:36:47 GMT

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.

[WebService]
[ScriptService]
public class MyService
{
  // Implementation details
}

The ScriptServiceAttribute enables you to reference a JavaScript proxy from your client-side JS by including

<script src="http://.../AlmostCoolestService.asmx/js" />

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:

<system.web>
  <httpHandlers>
    <remove verb="*" path="*.asmx"/>
    <add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, ..."/>
    <add verb="*" path="*_AppService.axd" validate="false" type="..."/>
    <add verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, ..." validate="false"/>
  </httpHandlers>
</system.web>

This replacement .asmx handler will return JSON data instead of the usual SOAP enveloppes, allowing for easy usage from the JavaScript code.

<Side.note>

Here is a bit of JSON (JavaScript Object Notation) data:

{ "Name" : "Alex", "Age" : 35 }

Did you know that this is actually just a JavaScript fragment? Take a look at this:

var person = { "Name" : "Alex", "Age" : 35 };
window.alert(person.Age);

So, when you send some JSON data over the wire, it is very easy to start working with that data.

</Side.note>

This is quite a bit of work, right?

In Orcas we get support for JSON, URL parameters and non-SOAP XML. It also has Atlas-specific conventions such as the JavaScript proxy.

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:

<%@ ServiceHost Service="CoolestWCFService" Factory="WebScriptServiceHostFactory" %>

Here WebScript actually means AJAX-enabled.

When you host the WCF service yourself, you should edit your configuration file to enable JSON support.

<system.serviceModel>

<endpoint address="" behaviorConfiguration="AjaxBehavior"

binding="webHttpBinding" contract="IAjaxService" />

</service>

</services>

</behavior>

</endpointBehaviors>

</behaviors>

</system.serviceModel>

Note how you only need to add an endpoint behavior for enabling WebScript. This makes WCF do the same thing as ASMX web services: it can generate a JavaScript proxy when you visit the URL http://.../CoolestWCFService.svc/js. BTW, the WebScriptServiceHost automatically adds this behavior to any endpoint that has a WebMessageEncodingBindingElement in its Binding element list, but does not have the WebHttp behavior defined. If you are interested in a little more on hosting, check here (a bit dated, but still pretty much ok).

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:
Going forward from .NET 3.0 the DataContract way of serializing is the preferred way. In 3.5 you may have noticed that Linq to SQL and ADO.NET Entities have built-in support for DataContract as well. The generated types for both Linq to SQL and ADO.NET Entities are [DataContract] types. Also, Linq to XML will have its XNode and derived types serialize to strings, so there is no problem to send them over the wire and use these in JavaScript. Furthermore, the DataContract is an opt-in model, so your type never gets serialized by accident. This is especially important, since you are sending the information to the browser client. The future directions of "Orcas+1" also indicate neat stuff to happen with the workflow data model and transformations (see this entry for a little more detail).
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.

IT-Boxing event in Sofia: the Bulgarian adventure

Alex Thissen — Mon, 10 Mar 2008 12:07:10 GMT

A couple of weeks ago I was invited to participate in the IT-Boxing event that took place last thursday, March 6th in Sofia, Bulgaria. The IT-Boxing event is a one-night competition, organized by the Bulgarian Association of Software Developers (BASD), in which a couple of teams battle to be the best. Each of these competitions has a particular theme and the one in which I joined was "Web development platforms". There were four teams representing Java (Echo2, Google Web Toolkit, Java Server Faces), PHP (Symphony), Ruby (on Rails) and ASP.NET. Each team is given a couple of timeslots of 20 minutes to demonstrate a particular part of their framework that would crush the opposition in features, demos, arguments, beauty and plain insults of the others. If arguments are not enough, you could always try to beat your opponent another way: with raw physical power. Check out the video of one of those fights (use the YouTube version if SoapBox doesn't work for you).

Note: no humans were hurt (badly) making this movie.

I got two out of three slots to show off the capabilities of ASP.NET AJAX and the ASP.NET MVC Framework (of course the CTP2 version that was released just the day before at MIX08!). Emil Stoychev demo-ed the Dynamic data controls. We stomped the opposition with great arguments. A certain victory awaited us, or did it?

Well, as it turned out the Java team won that night. Their main argument against ASP.NET was that the combination of Visual Studio and the ASP.NET framework was too much designer and clicking around to get things done. Java would allow (and need) you to write most code by hand, but that was "much more development at enterprise level". Cheaters as they were (pun intended here), they pulled in the entire J2EE platform to show that Java development was the way for large enterprises. Their only "real" demo was a video of some Content Management System that was shown as a video, and a boring one at that. Sigh. During the discussion round we argued that we could show off products like BizTalk, SharePoint and the like, but that this was all about web development frameworks. Unfortunately, nearly all .NET devotees had gone home early, sure of the immense victory, only to make it a small one for the Java team. All-in-all around 150 votes (out of 300 attendees) were given: 79 for Java, 49 for ASP.NET, 13 or so for Ruby and 11 for PHP.

Despite the loss I had so much fun on this event. It is a welcome change from the normal user group meetings with a vibrant, animated and fun format. To top, this one was cross-platform and therefore very educational for anyone that is mainly dedicated to a single platform. There are so many options, even for a single framework or platform. Call to Dutch user-group organizers: do a similar event in the Netherlands. Should be good fun. The event in Sofia got 300+ people to attend on a normal weekday evening. Nuff said.

Out with CAPTCHA, in with NoBot control

Alex Thissen — Sat, 02 Dec 2006 22:15:23 GMT

It seems like almost everybody (including myself) was having big trouble getting a comment into my weblog. The main culprit was the CAPTCHA control that I found on the MSDN site and have been using since. It resulted not only in a lot of user unfriendliness, but also a lot of runtime errors (memory corruption :O ) and an unavailable weblog.

So, out goes the CAPTCHA control. Welcome to the AJAX Control Toolkit’s NoBot control. It is an “open source” collaboration that extends the AJAX ASP.NET Extensions library that you can find on the Microsoft AJAX website.

The NoBot control uses three different techniques to filter out bot postbacks on a webform:

Use a configurable JavaScript calculation to test if a browser makes the request and that the script is actually executed.
The postback itself must be a certain amount of time later than the request. This is true for humans typing something into a form.
A limit on the number of postbacks that can be made from a single IP address within a time window.

I hope this will work.

Also new in this release is the BlogML 2.0 support. BlogML is a syndication format that is gaining momentum to move your blog content to another blogging engine. This is not just the postings, but also their categories and comments. Of course both engines must support BlogML export and import respectively. You can get the recent entries of my weblog as BlogML and even the entire contents.

Promise to self: If this weblog goes down one more time due to unexplainable errors, I am switching to Community Server. The Community Server 2.1 BlogML converter is right here, so it shouldn’t be too much of a problem. Tried and tested. (I will probably switch anyway, because CS is superior by far. I would have to give up the freedom to add whatever functionality to the blogengine I want).

All of this effort is part of an important personal message I will put up shortly.

Calling webservices from client-side Atlas: part 2 of 2

Alex Thissen — Wed, 26 Jul 2006 07:29:55 GMT

Part 1 left us able to call web services that are local. In part 2 we will take a look at web services that are remote to our own website that hosts the Atlas enabled page. Seems like a trivial thing to do. I mean, it’s “just” a soap call over HTTP, right? The challenge lies in the fact that the MSXML2.XmlHttp COM object is not allowed to make cross-domain HTTP requests. The solution is to bridge your call through the local website. The hosting web server will make the call on your behalf to the remote web service. The mechanism that Atlas brings is the .asbx bridge file. A bridge file defines what the remote web service looks like.

<?xml version="1.0" encoding="utf-8" ?>

<input>

</input>

</method>

<input>

</input>

</method>

</bridge>

The XML fragment above defines a proxy to the remote service located at the endpoint http://localhost:8442/WebSite/GameQueryService.asmx. Although the web service might define more operations two of those are mentioned and are callable by the proxy. The input and (optional) output parameters are listed as well. The proxy is a server-side class that you must provide. I used a wsdl.exe generated proxy class and included it in the App_Code folder of the Website that also hosts the .asbx file.:

wsdl.exe /language:C# /out:GameQueryServiceProxy.cs /namespace:KillerApps.Games.Atlas http://localhost:1256/Website/GameQueryService.asmx

In the first part you already saw how the ScriptHandlerFactory class handles all requests for .asmx (local web services) and .asbx (bridge files to remote web services). To be able to call a remote service, simply list the location of the .asbx file instead of local .asmx file you saw before.

<atlas:ScriptManager runat="server" ID="scriptManager">

<atlas:ServiceReference Path="~/GameQueryService.asbx" />

</Services>

</atlas:ScriptManager>

Like before, the ScriptManager will emit JavaScript for the bridge containing an object that acts as a JavaScript proxy to the local server, which in turn bridges the call to the remote web service. The JavaScript is inserted by adding a include to the same location as the .asbx file, plus an extra /js, as in: http://localhost/GameQueryService.asbx/js. The resulting JavaScript for the bridge file above is:

Type.registerNamespace('KillerApps.Games.Atlas'); KillerApps.Games.Atlas.GameServerStatus=new function() { this.appPath = "http://localhost:8442/WebSite/"; var cm=Sys.Net.ServiceMethod.createProxyMethod; cm(this,"GetServerStatus","args"); cm(this,"GetPlayers","args"); cm(this,"__invokeBridge","method","args"); }

You can call the web service through the JavaScript object that has a “namespace” and “className” as indicated in the bridge file. The method names correspond to the defined methods. The call to the service looks like this:

function OnLoad(sender, eventArgs)

{

KillerApps.Games.Atlas.GameServerStatus.GetServerStatus

( { "serverAddress" : "213.132.174.125",

"queryPort" : 27030,

"engine" : "HalfLife" },

OnStatusComplete);

}

Notice that the bolded part is a different way to pass all parameters to the proxy. For proxies corresponding to local web services the arguments were “as always”. Now you need to define your arguments in a new Javascript dictionary. The syntax is { “parameterName1” : “argumentValue1”, “parameterName2” : “argumentValue2”, … }. After the arguments you can still provide a callback methodname, plus one for timeouts and one for errors.

You probably noticed that the service endpoint was a local address, that served as a remote web service for testing purposes. As soon as you want to access an actual remotely located web service, you will run into security problems. The bridge won’t let you call into cross-domain methods that are not marked safe. You do so by adding an extra attribute to each method that you consider safe (e.g. which transport non-confidential information, or the ones that cannot be misused)

This should get your web method calls to work. There is some mention of marking your web method calls as a WebOperation, like so:

[WebOperation(true, ResponseFormatMode.Json, true)]

[WebMethod]

public ServerInfo GetServerStatus(string serverAddress, int queryPort, GameEngine engine)

but I haven’t found a situation yet where this is actually necessary to do.

Calling webservices from client-side Atlas: part 1 of 2

Alex Thissen — Thu, 20 Jul 2006 21:05:14 GMT

The March and May 2006 CTP’s of Atlas introduced two formal ways to call web services from a web browser. The difference is in the location of the web services.

Local web services
Remote or external web services

Atlas makes it really easy to call web services when they are local, i.e. reside in the same website as your Atlas-enabled web pages. You can create any ordinary .asmx web service and it will be callable from client-side JavaScript. Sure, you need to do some extra things, but there are no requirements to your service. Let’s take a look at how this works. Full source code is included at the end.

Say we have a web service GameQueryService.asmx whose class is defined like so:

[WebService(Namespace = "unr:www-killerapps-nl:services:games")]

[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]

public class GameQueryService : System.Web.Services.WebService

{

[WebMethod]

[XmlInclude(typeof(HalfLifeServerInfo))]

[XmlInclude(typeof(SourceServerInfo))]

public ServerInfo GetServerStatus(string serverAddress, int queryPort, GameEngine engine)

{

// Not relevant

}

We want to be able to call this web service from JavaScript. In an Atlas enabled .aspx page there is always a atlas:ScriptManager control present. You need to reference the web service from there.

<atlas:ScriptManager runat="server" ID="atlasScriptManager">

<atlas:ServiceReference Path="~/GameQueryService.asmx" />

</Services>

</atlas:ScriptManager>

<div id="serverNameLabel">Loading server information...</div>

Now, the scriptmanager will do loads of things for you. First of all, it will generate JavaScript code that represents a proxy to this very web service. It makes the service available through calls as simple as this:

GameQueryService.GetServerStatus("213.132.174.125", 27030, "HalfLife", OnStatusComplete);

That is almost exactly like a regular C# call to a proxy generated by wsdl.exe or Add Web Reference. The first three arguments are the ones from the WebMethod. The last one is the name of a callback JavaScript method that gets called when the call has completed.
The magic behind the scenes is done by a different handler of .asmx requests. Web.config defines a new HttpHandler for .asmx and ties it to a ScriptHandlerFactory, allowing regular GET requests on the web service. GET requests are not supported by default in ASP.NET 2.0.

In part 2 we will get to the .asbx extension.
You can switch off the ability to reach local web services from GET request, but this is enabled by default from the web.config

<microsoft.web>

Let’s say we want to call this web service when the page loads. You might be tempted to use the onLoad event of the BODY tag to wait for the page to finish loading. You should not do this. There is a slight delay between the loading of the page and the generation of the JavaScript proxy. Instead you must trigger the call to the proxy via the Atlas application object:

</application>

</components>

</page>

</script>

The OnLoad method is called when the application has finished loading.

function OnLoad(sender, eventArgs)

{

GameQueryService.GetServerStatus("213.132.174.125", 27030, "HalfLife", OnStatusComplete);

}

function OnStatusComplete(result)

{

if (result == null)

{

alert("No response received");

return;

}

alert(result.ServerName);

}

</script>

The callback function expects a single parameter which is the result of the web service call, provided that no error or timeout has occured. In our case the result could be a null reference, so we need to test for that. But, if it is not, then you can access the result. We receive a ServerInfo (or one of its derived classes) object. The coolest thing is that you can access the properties of the result as if it were the actual C# object. That’s why you can access result.ServerName, because ServerName is one of the properties from the ServerInfo class.

You should also include a mechanism to catch timeouts and errors. For that, simply create a set of two JavaScript methods and pass the names of them as the last two arguments of the previous call to the proxy:

GameQueryService.GetServerStatus("213.132.174.125", 27030, "HalfLife", OnStatusComplete, OnTimeout, OnError);

function OnError(result)

{

alert('An error has occured. Details are listed below:\n' + result);

}

function OnTimeout(result)

{

var serverNameLabel = new Sys.UI.Label($('serverNameLabel'));

serverNameLabel.set_text('The gadget did not respond in time.');

}

The OnTimeout method has another bit of client-side Atlas, manipulating the DIV with an ID of serverNameLabel through DHTML.

Calling your web service’s methods turns out to be not that complicated. Things change a little when you try to access a web service that is not in the same domain. We will cover bridging such calls in the next part.

File Attachment: LocalWebservicesAtlas.zip (425 KB)