Status Report for 10/17/2007 -- 10/31/2007

Progress

Prototype architecture for new CIMAClient project

1. Main Frame

2. Implementation of some parts

On server side, main steps for (1), (2) and (3) shown in above figure:

(1) Start the server;

(2) Start handling CIMA http/REST requests

• interact with a CIMA service
• get data from a handle (registration)
• Status information about gateway

(3) Get stream data in "myHandler" method in src/edu/indiana/extreme/www/cima/channel/sink/Channel_sinkImpl.java

On client side, main steps for (4) shown in above figure:

(1) Create a new instance of XMLHttpRequest;

(2) If successful, attach a function to the onreadystatchange event handler, that function will be executed EVERY TIME the server pings the client with an update. The function will be executed every time the readystatechange event is triggered;

In this function,

(a) Check the status properly to make sure that the response was successfully returned from the server;

(b) Extract data from parcel(an XML file);

(c) Generate content;

(d) Create the text for SensorName, TimeStamp and DoubleData to go inside the paragraph;(e) Join these nodes together, and insert the markup just created;

(3) Send the request;

Reference

• Bulletproof Ajax, Keith, Jeremy
• Ajax in practice, Crane, Dave
• JSP : the complete reference, Hanna, Phil
• JavaScript bible, Goodman, Danny
• Ajax for web application developers, Hadlock, Kris
• Ajax design patterns, Mahemoff, Michael
• Ajax : creating Web pages with asynchronous JavaScript and XML, Woychowsky, Edmond
• Ajax bible, Holzner, Steven

Status Report for 09/12/2007 -- 10/17/2007

Progress

Prototype architecture for Ajax-based CIMAClient project

Summary of the comparison with different main frames

Figure 1

Figure 1 shows the traditional model of the web application. For the CIMA web services architecture, once the CIMA sensors have been registered to the client machine, the data stream will be kept sending to the web service in CIMA Client, but the data cannot reach client machine automatically. So the client needs to send the HTTP request to retrieve the data manually. In this case, the method of sending data with respect to the user’s actions and the method of sending data with respect to the browser’s actions are synchronous, so we cannot get the real time data. On the other hand, the server will send back the entire page. Rinse and repeat.

Figure 2

Figure 2 shows the Ajax model based on polling. For the CIMA web services architecture, first the client needs to send register request to ask the CIMA web service to send the variable data just registered to the web service in CIMA Client, then a periodic polling will be done by the Ajax layer, and the client can get the updated data. In this model, the method of sending data with respect to the user’s actions is asynchronous while the method of sending data with respect to the browser’s actions is still synchronous. The advantage is that user interface is never blocked and the bandwidth usage is potentially lower than the traditional model even if it is still high.

In our research work, we found that there were some “smarter” Ajax models which have the features of high update frequency, true real time, low bandwidth usage and low load on the network infrastructure. For example, Ajax-Comet model based on smart polling which is asynchronous polling and the variable polling frequency is controlled by server; another example is Ajax-Comet model based on streaming which implements fully asynchronous push. We might employ all the Ajax models to our application and find out which is the best according to our data features.