One popular question on our road trip has been "How do I ensure that each Ajax Push is delivered to all clients at the same time?" (By the way, if you don't happen to be a resident of Vancouver, Montreal, or Toronto, you can still catch the talk as a one hour webinar on Monday, June 2, 2008. Be sure to check out the other ICEfaces webinars that same week. If the webinar isn't convenient, Jeanfrancois has a copy of the slides available.)
Of course, it's not actually necessary that the page updates arrive at each client at exactly the same time, just that they arrive within some short interval. In the past, I have objected to applying the term "real time" to Ajax Push on the web. Real time systems typically are used to control physical processes and often have tolerances of a few milliseconds (using Java for real time applications is challenging enough, let alone using Java over the internet). Web2.0 is not yet ready to run your car's antilock breaking system from a central server (I'm sure Web3.0 will easily handle this, though).
But when we define a real time system as one where success is determined not just by the results of the computation but also by having the response within a certain deadline; and further, that a soft real time system is simply considered to provide a lower quality of service when deadlines are missed, it becomes possible to consider Ajax Push from a soft real time perspective. (We have removed the expectations that system responsiveness must be within a few milliseconds, or be "instantaneous", and that the system must be used to control a "real" physical process; instead, we focus only on the timeliness guarantee.)
We can now measure the quality of an Ajax Push system in soft real time terms: assign a time interval based on the application (say, "all bid notifications should be received within 3 seconds of the bid"), and measure the proportion of page updates delivered within the time interval (the more updates that lie outside the interval, the lower the quality of the system). Then, we can work on producing a system capable of operating at the desired quality. The good thing is that the problem is easily parallelized -- each node in a cluster can independently determine the page updates for its sessions (database and network infrastructure may not be so easily parallelized).
In other words, to ensure that updates are delivered in a timely fashion (that is, to satisfy our soft real time requirement) it's important to exploit parallelism within the cluster and to measure the running time of the Ajax Push updates under realistic application conditions. Producing the page updates for each user takes an application-dependent amount of time; this must be measured for the application and hardware planned accordingly.
Technorati Tags:
ajax
ajaxpush
glassfish
icefaces
jsf
vancouver
webinar
