HTTP GET is used to read data (only a small request parameter is used), and the admin servlet is targeted. The request is asynchronous, and when the request state changes, the processRequest JavaScript function is invoked:

   req.onreadystatechange = processRequest;

It might seem reasonable to wait for a response before continuing processing. However, you run the risk of having your script hang if a network or server problem prevents completion of the transaction. An asynchronous call with the onreadystatechange event is more resilient.

As the request cycles through to completion, the processRequest event handler is invoked:

function processRequest() {
    if (req.readyState == 4) {
      if (req.status == 200) {
      parseMessages();
      }
....
      setCallback(); // only do this when complete
}
}

Listing 1 shows the available status codes. When the request is complete and HTTP status code 200 (OK) is returned, the parseMessages() method is called to extract the data from the XML message. Then the trapAlert() method is rescheduled again. If the XML response has a different retry interval, this will have been set by the parseMessages() function.

Parse XML Response and Repaint Screen
The parseMessages() function first extracts the XML response and extracts the elements for alert status, alert text, and retry interval:

itemStatus = response.getElementsByTagName('status')[0].firstChild.nodeValue;
itemText = response.getElementsByTagName('textBody')[0].firstChild.nodeValue;
callbackTimeout = parseInt(response.getElementsByTagName('callBack')[0].firstChild.nodeValue);

The alert text is then repainted on to the adminBanner document element (see above):

    document.getElementById("adminBanner").innerHTML = itemText;

The alert message appears on the screen as shown in Figure 3.

Servlet Formats the XML Response
For the browser to display management alerts to the user, XMLHttpRequest is used to request the management state. When the browser sends the request, the servlet uses the MBean helper to check the alert state and, if an alert is available, constructs an XML document as a response.

If there's no state to return, the response status is set as follows:

response.setStatus(HttpServletResponse.SC_NO_CONTENT);

Otherwise the text/XML response type is set:

response.setContentType("text/xml");

Listing 2 shows the servlet method in full.

When the servlet is invoked and the XML content returned, the console should print:

Received alert: alert.broadcast
<message><status>1</status><textBody><![CDATA[System Down in 10
Minutes]]></textBody><callBack>10000</callBack></message>

Capacity Modelling and Security
Because AJAX opens up the architecture in interesting ways, two key areas require elaboration:

• Capacity Modelling
• Security

Capacity Modelling
AJAX-enabled rich clients won't necessarily submit requests any more frequently than before. But with XMLHttpRequest executed asynchronously in the browser, the number of HTTP requests to the server increases in line with the retry interval.

• Retry interval (Think Time) = 20 seconds
• Number of connected users = 5000
• Transactions per second (TPS) = 5000/20 = 250

Of course, it depends what these requests do at the server to increase latency in response time. In our example, each request must look up MBean properties and format an XML response, but the response is very small and the MBean is in local memory. With each Web server thread able to handle approximately 200 GET requests a second, and the user requests load balanced across a J2EE server cluster of perhaps 200 threads, the increased loading isn't significant.

When modelling AJAX architectures, increased load injection can be offset by reduced bandwidth, since the response contains data only in contrast to data plus mark-up.

Security
Suppose you only wanted users in the WebUser group to access the Admin servlet?

If only authenticated users can access the admin servlet, then the XMLHttpRequest will run as that user if that user has authenticated.

For example, once user Joe logs into the application, and Joe is a member of group WebUser, the XMLHttpRequest will be able to invoke the Admin servlet.

Adding the following code to the admin servlet would confirm the authenticated subject, returning true and Joe respectively:

request.isUserInRole("WebUser");
request.getRemoteUser();

Caching
Some users have found that IE will cache the response from the AJAX request. This could be due to browser/page settings, but a forced workaround is to timestamp the URL:

var urlstr = "./admin?reqId=0&ts=" + new Date().getTimeStamp();

To XML or Not to XML
Not to XML. Some AJAX designers happily dispense with XML and send the response as plain text:

response.setContentType("text/plain");

This clearly depends on your client-side requirement and how loosely coupled the client is from the data required. A simple text response would suffice for a text alert. However, the advantage of the XML model for this article is that the response data can be elaborated further to refine both the status and status-related data. This article demonstrates how you'd parse a more complicated response that the client may have to code to accept.

Conclusion
AJAX presents architectural opportunities that shouldn't be overshadowed by the rich-client frenzy. This article has leveraged the architectural advantage AJAX can provide while addressing the technical requirements for both capacity and security that more exotic uses of this technology will demand.

References