In the Spotlight - Ted Goddard

JSFOne is rapidly (if you account for summer vacation) approaching: September 4th - 6th, near Washington D.C. It looks to be the most comprehensive JavaServer Faces event yet and will be a good opportunity to learn about and discuss JSF 2.0. As an ICEfaces community member you are eligible for a substantial discount if you register before August 15th (let us know if you missed the email with the registration code). Here are some of the sessions on ICEfaces:

• Ajax Push and ICEfaces for Enterprise Collaboration: How to use Ajax Push (aka "Comet" with JavaServer Faces)
• Mobile Ajax with JSF: Development tips and demos for JavaServer Faces on mobile devices, such as the iPhone
• Filthy Rich Portlets with ICEfaces and Liferay: How to develop portlets with rich user interfaces and how to integrate them with each other through Ajax Push

We hope to see you there. Also, don't forget to check out Dan's new book, Seam in Action (especially the Ajax chapter).

There are many dimensions to Ajax, yielding many different possible approaches. One particularly interesting dimension is the division of labour between client and server. Generally, ICEfaces assigns the most work to the server, treating the browser as a remote display. There are a number of reasons for this:

• The data is on the server.
• Server-side logic is not open to inspection by attackers.
• MVC is preserved.
• Only server-side events can trigger Ajax Push.
• Java code is far easier to write and maintain: client-side code requires custom JavaScript.

So how do you implement a date picker? As a custom JSF component, of course. Clicking on an arrow to the right of "July" updates the page with a new calendar for "August", containing an <h:commanLink> for each day of the month. It can handle a wide range of locales and can account for varied daylight savings time legislation throughout history. But if we ignore the chaos introduced by daylight savings time, is this ultimately the right solution from a distributed computing point of view? Wouldn't it be more efficient to page through calendars in the browser, and only submit data to the server when the user had actually picked a date?

Of course, a client-side date picker is more efficient at runtime; the reasons that ICEfaces took a server-side approach with this particular component were because, at the time, we didn't want to write the JavaScript and we wanted to experiment with a component as complex as a date picker.

As an alternative, the Snappy Calendar is a purely client-side date picker for ICEfaces. You will also find a Snappy Table that provides a client-side table with sorting and row selection. There are two particularly interesting things about these components: one, that they are client-side implementations; and two, that they are developed outside ICEfaces.org. Please try them out and provide your comments directly to the author or on the ICEfaces forums.

Jazoon 2008 will be starting shortly (June 23 - June 26), and you'll have several opportunities to learn about Ajax Push at the conference:

• GlassFish Community Day (a free event)
• The Jazoon talk AJAX Push for Revolutionary Enterprise Applications
• The mimacom stand in the exhibition.

mimacom ag has a great deal of experience building enterprise applications, and is now a strategic ICEsoft partner. The beginning of this partnership can be seen in an interactive locking demo that we have put together for Jazoon. The essential idea is to build collaboration features through the mimacom edoras lock manager and ICEfaces Ajax Push. The demo allows multiple users to edit and lock records in a common data set. Besides being able to see changes to the data in real time they can also negotiate locks through chat and lock operations right within the application.

The locking demo will be featured in the Jazoon talk and at the mimacom exhibition stand (where you can learn how to apply edoras and ICEfaces to build a complete application). For GlassFish Community Day, I plan to demonstrate WebMC and possibly the new SIP telephony demo.

The telephone is an excellent source of asynchronous events — you never know when it is going to ring. This means that web-based views of the telephony space make for interesting applications of Ajax Push.

Using SailFin and ICEfaces we've put together a very simple call setup demo. It shows when your phone is online and allows you to initiate a call between any two phones just by selecting them and pressing "call".

To run the demo:

1. Download a recent build of SailFin.
2. Download the demo binary callsetup.sar.

3. java -Xmx512m -jar sailfin-installer-v1-b36-darwin.jar
   cd sailfin
   ant -f setup.xml
   bin/asadmin start-domain domain1
   bin/asadmin start-database
   cp callsetup.sar domains/domain1/autodeploy/
   

4. Point your SIP phone (such as X-Lite Demo) at a localhost Proxy.
5. Point your browser at http://localhost:8080/CallSetup/registrations.iface

As phones connect and disconnect, the list in the registrations page will be dynamically updated, showing user presence.

The full source code is available at http://anonsvn.icefaces.org/repo/projects/CallSetup/. To build the .sar (assuming you have SailFin running as above):

svn co http://anonsvn.icefaces.org/repo/icefaces/trunk/icefaces/
cd icefaces
ant
cd ..
svn co http://anonsvn.icefaces.org/repo/projects/CallSetup/
cp icefaces/lib/{backport-util-concurrent.jar,icefaces-facelets.jar,commons-fileupload.jar,icefaces.jar,commons-logging.jar} CallSetup/web/WEB-INF/lib/
cd CallSetup
ant
cp dist/CallSetup.sar $sailfin/domains/domain1/autodeploy/

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.