Client-Server Protocols
When searching the web for true AJAX samples (I don’t call pure client sidescripting an AJAX sample – but some people do) you may see that there are
as many protocol definitions as there are samples and frameworks. Even if
they mention to use JSON on the network layer the samples differ in many
ways. I see no specific standard that is bound to AJAX web applications.
Seeing this situation I asked myself why not to use WebServices because I
had a lot of experience with SOAP and already had implemented a SOAP
client in JavaScript some years ago.
Best Practices for a WebService implementation
Using a WebServices client is not so hard to do if you have a layer that takes
care of building the valid XML for the network layer so the client should be
implemented as you expect or know it from other platforms and languages by
providing a stub function on the client that. You can use this local function
from JavaScript to call the corresponding function on the server and pass the
parameters. This is called a RPC network layer.
When using the (non-multitasking) JavaScript interpreter in the browser there
is need for an asynchronous mechanism too. It’s because waiting for an
answer a call to a server can fail in many ways:
• Packets my get lost.
• The network may be unreliable
• The server may be overloaded
• ... and many more pitfalls.
It’s even worse, because when calling a server from the browser using the http
protocol there are some limitations you cannot get around:
• You can only call the server that is serving the page that is displayed
when using the XMLHttpRequest object.
• Only 2 simultaneous calls can be used as specified in the http protocol
definition.
• The timeout the network stack is using by default is too long so you need
to cancel long running requests before the network stack does so if you
want responsive applications.
Using the SOAP protocol has also very important advantage over using
<script> tags or JSON objects together with the eval function because you can
specify and check what data types you expect to send and receive using a
specific function.
SOAP was made for AJAX
I ran over the blog of Dave Winer and his post from Sun, Sep 12, 1999 titled
"An end to the Über-Operating System".
http://davenet.scripting.com/1999/09/12/anEndToTheUberoperatingSystem
... The purpose of both specs [SOAP and XML-RPC] is to enable scripted web
applications to cross operating system boundaries.
Of course the term AJAX was not known then but I thing that "scripted web
applications that cross operating system boundaries" is a good definition of
AJAX. By using SOAP there even is more XML on the wire than with AJAX
applications using a JSON or plain text transport protocol?
Ask yourself: what is or should be the standard protocol for AJAX
applications when retrieving data from the server? - By using SOAP many
aspects of a transport layer have been discussed (data types, attachments ...)
and there are even more upcoming standard extensions for it (security, routing
...).
The only thing that I really miss is a built-in native SOAP client in browsers.
The (deprecated) SOAP spec from 1999:
http://www.oasis-open.org/cover/draft-box-http-soap-00.txt.
I think that this doc is one of the most influencing documents I've read. It
disappeared from the Microsoft site and http://www.ietf.org. Does anybody
know who feels responsible for achieving historical documents from the
internet?
Thanks to Don Box, Dave Winer and all the other founders and protagonists
of SOAP.
XML, WebServices, SOAP and
WSDL are still used as hype-words
and sole people still think that these
protocols can solve all problems.
I personally know they fit the situation
where I use them in AJAX web
applications.
Using WebServices in AJAX applications
There are still some disadvantages with many available AJAX frameworks on
the web and also with my preceding implementation:
• For every function you want to implement a special page must be
realized.
• The URL may exceed a length of more than a few 100 chars and will
bring up problems.
• The implementation on the server consists of code fragments used for the
communication of parameters and the return value together with the
application specific code.
• We need to implement a big part of the framework ourselves, for example
parsing the parameters and converting them to the native types. This
seems to be an easy job but there have been security leaks in (too simple)
AJAX implementations.
Here it is obvious that using the server side communication infrastructure of
WebServices brings in some huge advantages:
• The same functionality can also be used from other WebService enabled
applications like Excel.
• Multiple methods can be implemented together in one class so it is
possible to choose the right granularity for bigger collections of
WebServices.
• You can use data types
• There is exception handling (more on this later)
• A proxy can be created for the client that enables an easy implementation
of calling a server side method. (more on this soon)
• The existing SOAP and WSDL standards in the current available version
(Spring 2005) are perfect usable on http and https connections. The
circumstances for transferring html over http are identical and usable
without any problems for web services.
• The actual discussions about extending the WebService Infrastructure
with security features and routing soap messages are not needed and
SOAP is as secure as the web is in this scenario.
• The core implementation of the WebService infrastructure can be reused.
This part should be highly stable and security issues (buffer overflows
etc.) should be cleared by the big manufacturers like Microsoft, SUN,
IBM, BEA, ... and the AJAX Engine just gets the benefits from this.
WebServices can be implemented very easily in ASP.NET so I prefer this
platform in my samples but also port the core part if it to the JAVA
platform to see how platform independent the Engine is.
The implementation of a WebService for the calculation of the prime
factors can be found in CalcService.asmx in this sample website. The core
implementation is the same as in Request.aspx.
<%@ WebService Language="C#" Class="Service" %>
using System;
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;
[WebService(Namespace = "http://www.mathertel.de/CalcFactorsService",
Description="A WebService for the calculation of prime factors.")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class Service : System.Web.Services.WebService {
The implementation of the AJAX
the web and also with my preceding implementation:
• For every function you want to implement a special page must be
realized.
• The URL may exceed a length of more than a few 100 chars and will
bring up problems.
• The implementation on the server consists of code fragments used for the
communication of parameters and the return value together with the
application specific code.
• We need to implement a big part of the framework ourselves, for example
parsing the parameters and converting them to the native types. This
seems to be an easy job but there have been security leaks in (too simple)
AJAX implementations.
Here it is obvious that using the server side communication infrastructure of
WebServices brings in some huge advantages:
• The same functionality can also be used from other WebService enabled
applications like Excel.
• Multiple methods can be implemented together in one class so it is
possible to choose the right granularity for bigger collections of
WebServices.
• You can use data types
• There is exception handling (more on this later)
• A proxy can be created for the client that enables an easy implementation
of calling a server side method. (more on this soon)
• The existing SOAP and WSDL standards in the current available version
(Spring 2005) are perfect usable on http and https connections. The
circumstances for transferring html over http are identical and usable
without any problems for web services.
• The actual discussions about extending the WebService Infrastructure
with security features and routing soap messages are not needed and
SOAP is as secure as the web is in this scenario.
• The core implementation of the WebService infrastructure can be reused.
This part should be highly stable and security issues (buffer overflows
etc.) should be cleared by the big manufacturers like Microsoft, SUN,
IBM, BEA, ... and the AJAX Engine just gets the benefits from this.
WebServices can be implemented very easily in ASP.NET so I prefer this
platform in my samples but also port the core part if it to the JAVA
platform to see how platform independent the Engine is.
The implementation of a WebService for the calculation of the prime
factors can be found in CalcService.asmx in this sample website. The core
implementation is the same as in Request.aspx.
<%@ WebService Language="C#" Class="Service" %>
using System;
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;
[WebService(Namespace = "http://www.mathertel.de/CalcFactorsService",
Description="A WebService for the calculation of prime factors.")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class Service : System.Web.Services.WebService {
The implementation of the AJAX
engine is done in JavaScript only and
has to take care of the different
browser platforms but is independent
of the server platform because the
protocol is standardized.
...
[WebMethod(Description="Calculate all prime factors of a given number.")]
public string CalcPrimeFactors(string inputText) {
string outputText = String.Empty;
UInt64 prime; // try this factor (only primes will match!)
UInt64 number; // product of the remaining factors
if ((inputText == null) || (inputText.Length == 0) || (inputText == "0"))
return (null);
prime = 2; // start with 2
number = UInt64.Parse(inputText);
while ((number > 1) && (prime * prime <= number)) {
if (number % prime != 0) {
// try the next factor (slowly)
prime += (prime == 2UL ? 1UL : 2UL);
} else {
// found a factor !
outputText = outputText + " " + prime;
number = number / prime;
} // if
} // while
if (number > 1) {
// the last factor (a prime) is here.
outputText = outputText + " " + number;
}
return (outputText);
} // CalcPrimeFactors
...
} // class
http://www.mathertel.de/AjaxEngine/S01_AsyncSamples/CalcService.asmx.
The special thing here, compared to the previous sample using Request.aspx
with an http GET command, is that the functional characteristics of the server
side operation gets clear. There is no need for the programmer to care about
the details of the communication
Because there no usable SOAP client available in the current browsers there is
more overhead in the JavaScript programming in the browser for
implementing the SOAP protocol as far as we need it. There is in deed a
SOAP interface available in Firefox but this implementation is not working
correctly and is only partial implemented.
Fortunately the assembling of the SOAP request and analyzing the result is
also possible by building strings that contain the valid XML code and
transferring if to the server with the well known XMLHttpRequest Object.
Here is some sample code that directly calls a WebService:
// call the server using the SOAP encoding
xmlObj = new ActiveXObject("Microsoft.XMLHTTP");
xmlObj.Open("POST", "http://localhost/CalcFactors/Service.asmx", true);
xmlObj.setRequestHeader("SOAPAction",
"http://www.mathertel.de/CalcFactorsService/CalcPrimeFactors");
xmlObj.setRequestHeader("Content-Type", "text/xml; charset=utf-8");
xmlObj.onreadystatechange = RetrievePrimeFactors;
var soapText = "<?xml version='1.0' encoding='utf-8'?>"
+ "<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'>"
+ "<soap:Body>"
+ "<CalcPrimeFactors xmlns='http://www.mathertel.de/CalcFactorsService'>"
You should use the JavaScript proxies
instead of hand-coding calls to the
server every time. It’s far more robust
and easier to use.
+ "<inputText>" + inputText + "</inputText>"
+ "</CalcPrimeFactors>"
+ "</soap:Body>"
+ "</soap:Envelope>";
xmlObj.Send(soapText);
...
// the response is inside the <CalcPrimeFactorsResult> tag
outputText = xmlObj.ResponseText;
p = outputText.indexOf("<CalcPrimeFactorsResult>");
if (p > 0) {
outputText = outputText.substr(p+24);
outputText = outputText.substr(0, outputText.indexOf("<"));
} // if
This implementation is only used to show how the SOAP protocol works but
has no error handling and lacks of being robust.
This implementation can be found in the page CalcFactorsServerSoap.htm on
the sample website. It only works for IE.
http://www.mathertel.de/AjaxEngine/S01_AsyncSamples/CalcFactorsServerSoap.htm
The server side code gets dramatically simplified when using WebServices.
For the client there also exists a good solution and another level of abstraction
that makes implementing AJAX calls really easy.
BUT
Implementing AJAX can even be simpler than in this sample. We don’t have
to care about SOAP and directly using the XMLHttpRequest object. Have a
look at the AJAX Engine.
has to take care of the different
browser platforms but is independent
of the server platform because the
protocol is standardized.
...
[WebMethod(Description="Calculate all prime factors of a given number.")]
public string CalcPrimeFactors(string inputText) {
string outputText = String.Empty;
UInt64 prime; // try this factor (only primes will match!)
UInt64 number; // product of the remaining factors
if ((inputText == null) || (inputText.Length == 0) || (inputText == "0"))
return (null);
prime = 2; // start with 2
number = UInt64.Parse(inputText);
while ((number > 1) && (prime * prime <= number)) {
if (number % prime != 0) {
// try the next factor (slowly)
prime += (prime == 2UL ? 1UL : 2UL);
} else {
// found a factor !
outputText = outputText + " " + prime;
number = number / prime;
} // if
} // while
if (number > 1) {
// the last factor (a prime) is here.
outputText = outputText + " " + number;
}
return (outputText);
} // CalcPrimeFactors
...
} // class
http://www.mathertel.de/AjaxEngine/S01_AsyncSamples/CalcService.asmx.
The special thing here, compared to the previous sample using Request.aspx
with an http GET command, is that the functional characteristics of the server
side operation gets clear. There is no need for the programmer to care about
the details of the communication
Because there no usable SOAP client available in the current browsers there is
more overhead in the JavaScript programming in the browser for
implementing the SOAP protocol as far as we need it. There is in deed a
SOAP interface available in Firefox but this implementation is not working
correctly and is only partial implemented.
Fortunately the assembling of the SOAP request and analyzing the result is
also possible by building strings that contain the valid XML code and
transferring if to the server with the well known XMLHttpRequest Object.
Here is some sample code that directly calls a WebService:
// call the server using the SOAP encoding
xmlObj = new ActiveXObject("Microsoft.XMLHTTP");
xmlObj.Open("POST", "http://localhost/CalcFactors/Service.asmx", true);
xmlObj.setRequestHeader("SOAPAction",
"http://www.mathertel.de/CalcFactorsService/CalcPrimeFactors");
xmlObj.setRequestHeader("Content-Type", "text/xml; charset=utf-8");
xmlObj.onreadystatechange = RetrievePrimeFactors;
var soapText = "<?xml version='1.0' encoding='utf-8'?>"
+ "<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'>"
+ "<soap:Body>"
+ "<CalcPrimeFactors xmlns='http://www.mathertel.de/CalcFactorsService'>"
You should use the JavaScript proxies
instead of hand-coding calls to the
server every time. It’s far more robust
and easier to use.
+ "<inputText>" + inputText + "</inputText>"
+ "</CalcPrimeFactors>"
+ "</soap:Body>"
+ "</soap:Envelope>";
xmlObj.Send(soapText);
...
// the response is inside the <CalcPrimeFactorsResult> tag
outputText = xmlObj.ResponseText;
p = outputText.indexOf("<CalcPrimeFactorsResult>");
if (p > 0) {
outputText = outputText.substr(p+24);
outputText = outputText.substr(0, outputText.indexOf("<"));
} // if
This implementation is only used to show how the SOAP protocol works but
has no error handling and lacks of being robust.
This implementation can be found in the page CalcFactorsServerSoap.htm on
the sample website. It only works for IE.
http://www.mathertel.de/AjaxEngine/S01_AsyncSamples/CalcFactorsServerSoap.htm
The server side code gets dramatically simplified when using WebServices.
For the client there also exists a good solution and another level of abstraction
that makes implementing AJAX calls really easy.
BUT
Implementing AJAX can even be simpler than in this sample. We don’t have
to care about SOAP and directly using the XMLHttpRequest object. Have a
look at the AJAX Engine.
Tags:
JavaScript