[ return to listing ]
Asynchronous Communication Model for Web Applications
Document Prepared By:
Sam Weinger, Consultant
For information or questions regarding this document or Wrycan's services, please contact us.
Table of Contents
1.0 Overview
2.0 The Traditional Model
3.0 The Asynchronous Model
4.0 Architecture
4.1 Generating the Request
4.2 Input Control
4.3 Processing the Response
5.0 Sample Code
6.0 Tradeoffs
6.1 Benefits
6.2 Drawbacks
7.0 Further Discussion
8.0 Summary
9.0 Technology
The purpose of this document is to describe an emerging web application communication model that allows web interfaces to have a level of responsiveness that is unattainable under the traditional model.
The traditional model for web applications requires that the user click the submit button in an HTML form element in order to send information to the server process. The web client then sends an HTTP request to the specified server. Upon receipt, the server processes the request, extracts the necessary information, and responds with an HTML page that is rendered by the client, all the while blocking further user operation until the new page is fully loaded.
The motivation behind developing this new breed of user interface is to eliminate the need to reload the page every the user provides new input. Instead, use of an asynchronous communication model allows the user to continue to interact with the application while data transmission and retrieval over the network takes place in the background. The body of the page can then be modified using dynamic HTML techniques to reflect the responses received. This type of interaction has been unofficially dubbed "Asynchronous JavaScript and XMLHttpRequest" or Ajax in an essay published on Adaptive Path.
Under this new model, requests are generated on the client side by JavaScript functions. This is contrary to the traditional model, where data is sent to the server upon the submission of a form. On the server side, rather than reloading the page upon each request, the body of the HTTP response can be used to return arbitrary data dynamically generated based on the user action. This means that the page must only be loaded once, when the user initially points his or her browser to the page.
The key to an Ajax interface is the JavaScript that handles the communication with the server. This communication can be established by making use of the XMLHttpRequest object, a technology that has recently gained support among today's popular browsers such as Internet Explorer, Firefox, and Safari. The XMLHttpRequest object provides functions that can send HTTP requests and retrieve data from a response.
The first steps are to instantiate the object and bind an event handler to the onreadystatechange property, an event that is fired each time the state of the object changes. The request is initiated via the open method, with the URL of the server process passed in as an argument. This method also takes an optional Boolean argument which, when set to true, allows for processing on the page to continue before the response has been acknowledged as successfully received. This detail is vital to achieving asynchronous behavior. Calling the send method actually transmits the request to the server.
Instead of form controls contained in the body of the HTML, user input is collected via JavaScript calls to a function that performs the above mentioned operations on the XMLHttpRequest object. The scope of this object must be global to the page, so that the state change handler function can have access to the response when it is received.
When the state change event handler function detects that the transaction has completed successfully, then processing the response can begin. The response can be accessed through either the responseXML property, for XML responses, or the responseText property for normal character data. The former is a DOM compatible Document object that can be parsed using standard DOM methods, while the latter allows the developer the flexibility to choose any format. The HTML can then be modified using JavaScript's HTML DOM Object library.
Figure 1. Asynchronous Communication Model
The following example uses some code and concepts from the Apple developer connection. It is a good design decision to provide a single entry point for sending data to the server, so a generic function that takes a URL as an argument is appropriate. The loadXmlDoc function defined as follows performs the desired operations:
var req;
function loadXMLDoc(url, params) {
// branch for native XMLHttpRequest object
if (window.XMLHttpRequest) {
req = new XMLHttpRequest();
}else if (window.ActiveXObject) {
req = new ActiveXObject("Microsoft.XMLHTTP");
}
req.onreadystatechange = handler;
req.open("POST", url, true);
req.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
req.send(escape(params));
}
Mozilla 1.0, Netscape 7, and Safari 1.2 implement the XMLHttpRequest as a native object, whereas Internet Explorer 5 for Windows implements it as an ActiveX Object, so the body of this function must be forked based on the browser's implementation.
The open method is invoked using the POST method because Microsoft Internet Explorer caches XML documents in order to improve performance, and this technique ensures that the most recent data from the server is received. Alternatively, appending a timestamp to the URL as a request parameter would also achieve the desired effect. This function is invoked, either directly or indirectly, in response to some user triggered event such as a button click. For example, the following might appear somewhere in the body of the HTML:
<input type="button" onclick="loadXmlDoc('http://www.somehost.com/control/','someparam=somevalue')"/>
The event handler for the onreadystatechange event is where the response processing occurs.
function handler() {
if (req.readyState == 4) {
if(req.status == 200) {
var responseXML = req.responseXML.documentElement;
var responseText = req.responseText;
//process response here
} else {
alert("Problem retrieving XML response");
}
}
}
The function uses the readyState and status properties to ensure that the transaction was successful, and if so proceeds to do something with the response. In general, the action that is taken is to somehow modify the HTML DOM according to the contents of the response.
The logic of the server side of an Ajax application is different than that of a traditional web application. The following code uses the Java Servlet API to illustrate this distinction.
public class XMLResponseServlet extends HttpServlet {
BusinessModel businessModel;
public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
//extract parameters
String parameter = request.getParameter("someparam");
//process parameter
//update model
//obtain results
//etc.
String result = businessModel.businessLogic(parameter);
String responseXML = "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\" ?>" +
"<response>" +
"<result>" + result + "</result>" +
"</response>"
response.setContentType("text/xml;charset=UTF-8");
response.getWriter().write(responseXML);
}
}
Rather than forwarding the request using an object such as RequestDispatcher, this Java Servlet writes XML to the body of the response using the ServletResponse object's getWriter() method, which returns a PrintWriter. It first accepts the request generated in the JavaScript loadXmlDoc call, applies some business logic with the user input, and returns a response to the client without causing the page to reload.
Clearly, asynchronous clients require sophisticated JavaScript controllers that handle all communication with the web server. This allows small portions of the HTML page to be updated based on the contents of the server responses, and means that these responses are completely independent of the presentation logic. The use cases of the web application should be used to determine if rich clients such as these are appropriate.
Some potential benefits of this type of interaction model include:
- High Traffic Servers: In situations where the server traffic is extremely high, servicing a high volume of client requests can be very computationally intensive. Transferring logic to the client can lighten the load and therefore improve server response times.
- Automatic Updates: Because page reloads are not necessary to receive data from the server, the information displayed on the page can be refreshed automatically to reflect changes in the application's internal state. Comparisons can be made to the Model-View-Controller architecture where changes in the model are automatically reflected in the view.
- Quicker Page Loading: Often all of the information contained on a page is not visible when the page is initially loaded. The information is revealed in response to user actions, such as expanding a node in a tree. Using this model, a page can acquire information from the server on demand, reducing the amount of time it takes to load the page. This is analogous to the Proxy design pattern, where access to a remote object is controlled through a more lightweight local object.
- User Input Validation In a page that contains several input form controls, each field can be validated individually as data is entered, without having to wait for the entire form to be filled out.
Some potential drawbacks include:
- Browser Dependence: Rich clients such as those required for the asynchronous model are dependent on the user's web browser and version in order to function properly. Different browsers mean different JavaScript interpreter implementations, a variable over which the developer has absolutely no control. Also, the XMLHttpRequest object is only supported by the most recent generation of web browsers, namely Internet Explorer 5, Mozilla 1.0, Netscape 7, and Safari 1.2. If the target users are going to access an application using any browser other than those mentioned, then using this object is not a viable option.
- Network Congestion: A careless implementation can result in requests being generated at such a high frequency that performance actually suffers as compared to the traditional model. This can not only degrade the performance of the web application, it can also monopolize network resources and increase network congestion.
- Server Timeouts: The client has the responsibility to handle the situation where the server timeouts, whereas, under the traditional model, this logic is internal to HTTP. Otherwise, the user could be interacting with a view that is out of synch with the state of the application.
While this is a very intriguing architecture for web applications, it is unlikely that that Ajax will completely replace the traditional synchronous communication model any time soon. Keeping as much presentation logic on the server as possible affords developers the assurance that they have control over essentially everything except the rendering of HTML. The XMLHttpRequest object is by no means a fix all end all solution, but rather a tool that, when applied appropriately, can potentially improve user experience. As use and support of this and comparable technologies becomes more commonplace, frameworks and patterns such as Ruby on Rails and SAJAX will likely emerge that extend the power of this kind of communication model.
It is possible to create highly responsive web interfaces using JavaScript as an intermediary between an HTML page and a server process. This added layer of indirection allows for asynchronous communication with the server, so the user spends less time waiting around for pages to load and more time interacting with the application.
The technologies used while writing this document are:
JavaScript - Client Side Scripting
XMLHttpRequest - Microsoft and Apple
HTML - Hyper Text Markup Language
DOM - Document Object Model
HTTP - Hyper Text Transfer Protocol
J2EE - Java 2 Enterprise Edition
|
