Montag, Juli 07, 2008

How to set up a web project using the AjaxEngine – Part 1b

Some days ago I posted part 1a - a short instruction about how to set up a minimal project.

The sample I used to demonstrate that the infrastructure works was as simple as possible and is using a RPC style of Ajax calls to the server. Some topics have not been touched so here they come.

How to get the files

The easiest way to get all the files I’ve talked about is to go get them directly from the repository hosted as sourceforge. is the projects's home page and you can browse the repository directly by using the url

Here all the development progress will be available as soon as soon as I write about it.

Another possible way to get the files is to use a subversion client for example that includes more functionality like getting a copy of all the current files at once, looking into the change log and comparing different versions of the same file.

From time to time the download archives are updated too. You can find them on my site at

Calling web services the right way

I have to mention, that this is not the best way of calling a server because synchronous calls may block or freeze the client during the call and the call time may be very long when the network or the server is used a lot. Using asynchronous calls is the answer to that problem and there is simple but great mechanism inside the ajax.js file that makes asynchronous programming quiet easy. Here is just a brief explanation of how to use it. More of the mechanism and it's options can be found in the book Aspects of Ajax.

The typical AJAX scenario follows the following pattern and can be split into 4 separate problems:

  1. Waiting for an event that will start the Ajax call to the server.
    Sometime that’s an easy thing to do, because there is a button clicked and we just can attach the initializing code to an event. But sometimes events have to be queued up to avoid a race condition and get wrong answers.
  2. Collecting some data on the client side.
    It is often necessary to do this right before you call the server and not in the moment when the call is initiated.
  3. Communication with the server.
    That is done by using the client stub that is generated for each SOAP based web service.
  4. Finally using the result from the server.
    That must be done, when the data is available and is the typical asynchronous functionality of Ajax.

Many grown-up Ajax implementations are using a JavaScript object that binds the JavaScript functions that all together will solve the scenario and so does the AjaxEngine:

// declare an AJAX action var action1 = { // the prepare function collects and returns the data for the server side method.

// It just returns an array with the parameters and marks it with "multi". prepare: function(obj) { var p = []; p[0] = document.getElementById("n1").value; p[1] = document.getElementById("n2").value; p.multi = true; // the hint for the ajax Engine return (p); }, // the call element points to the proxy for the server call as usual call: proxies.CalcService.AddInteger, // the result will be written it into the appropriate html field. finish: function (p) { document.getElementById("outputField").value = p; } } // action1

This action can be used to start an Ajax call by using some inline code like this:

<input id="n1" onkeyup="ajax.Start(action1)" />

Now Ajax starts getting robust enough in a real web application.

The code is from the sample that you can find in the sample at

Sonntag, Juli 06, 2008

Calling WCF and SOAP based webservices from AJAX

The JavaScript proxy that is implemented for the Ajax engine to call SOAP based web services has been used on the ASP.NET platform for a long time and was ported to other platforms like Java. Some derived work can also be found for PHP and the Qooxdoo. It’s pretty stable for a while and that’s a good message.

When working with some specific Java based platforms there was a specific problem with the automatic generated WSDL descriptions, because they use an external schema for defining the structure of the passed data:

<wsdl:types> <xsd:schema targetNamespace=""> <xsd:import schemaLocation=http://localhost/AJAXEngine/S02_AJAXCoreSamples/CalcFactors.svc?xsd=xsd0

namespace="" /> ... </xsd:schema> </wsdl:types>

The workaround was to write the JSON structure that is used by the JavaScript proxy by hand (and that is still a good idea for high trafic web sites).

When adopting the WCF .svc services this kind of using WSDL and XML schema definitions can be found too.

A solution for this is quiet simple and can now be found in the wsdl.xslt and the GetJavaScriptProxy.aspx files.


The WSDL to JavaScript transformation now looks for import nodes under the wsdl:types and then imports the referenced schema by using the xslt document() function. Then this imported document is searched for the right element and the parameter and return value description is generated through the soapElem template. Here is the added xslt code:

<xsl:when test="/wsdl:definitions/wsdl:types/s:schema/s:import">

<!-- importing an external schema –>

<xsl:variable name="inputElementName" select="substring-after(wsdl:part/@element, ':')" />

<xsl:for-each select="/wsdl:definitions/wsdl:types/s:schema/s:import">

<xsl:variable name="doc" select="document(@schemaLocation)"/>

<xsl:for-each select="$doc/s:schema/s:element[@name=$inputElementName]//s:element">

<xsl:call-template name="soapElem">

<xsl:with-param name="name" select="@name" />

<xsl:with-param name="type" select="@type" />


<xsl:if test="position()!=last()">,</xsl:if>





In the .NET environment the document function will not work for security reasons without some special instructions for the xslt transform. When passing a  XmlUrlResolver when loading the xslt file the document() function can retrieve the referenced external document.

XmlUrlResolver resolver = new XmlUrlResolver();
resolver.Credentials = CredentialCache.DefaultCredentials;

XslCompiledTransform xsl = new XslCompiledTransform();
xsl.Load(Server.MapPath("~/ajaxcore/wsdl.xslt"), XsltSettings.TrustedXslt, resolver);

Implementing a WCF service for Ajax

Implementing a WCF service for Ajax is almost as simple as programming an *.asmx based service but you can also use an external C# class or interface for implementing the service.

You can find a sample source code in:

The configuration

By default the WCF services use the SOAP 1.2 format but we don’t need the ws-* functionality and the soap basic profile is perfect for using webservice with AJAX solutions. This can be done by using the following configuration in web.config:

      <behavior name="AjaxBehavior">
        <serviceMetadata httpGetEnabled="true" />
        <serviceDebug includeExceptionDetailInFaults="false" />

    <service behaviorConfiguration="AjaxBehavior" name="CalcFactors">
      <endpoint address="" binding="basicHttpBinding" contract="CalcFactors" />