ICESoft recently released the 1.0.1 version of its enterprise Ajax toolkit, ICEFaces. ICEFaces includes the usual fare of UI widgets, but the most interesting aspect of this toolkit is that it turns Ajax application development into a server-side task. Artima Senior Editor Frank Sommers spoke with ICESoft CTO Steve Maryka about this new Ajax toolkit, and how it addresses the unique scalability problems in asynchronous Ajax applications.

Frank Sommers: ICESoft recently released a new version of its enterprise Ajax toolkit. One of the features your product promises is better scalability for Ajax applications. How does scaling up an Ajax application differ from scaling up traditional Web applications?

Steve Maryka: The traditional Web [application] model centers around client-initiated interaction: There is a client that initiates the request, and the server responds to that request. While most Ajax-style features rely on that capability as well, [client-initiated requests] don't give you the ability to process presentation changes based on data changing on the back-end.

An example of server-initiated data changes might be as simple as new email arriving on the server, and the application wanting to alert the user to new email messages. With the traditional model, you can't do that unless the user is interacting with the Web client. With Ajax, you can push [those changes] from the server, adding the [update] dynamics to the other end of the application, to the back-end data model.

For that push model to work, [the server] needs to have an outstanding request from the client. When the server-side application determines that the presentation needs to change, the server will satisfy that request and provide a response [with] the presentation changes. From there, the client can send another request to the server. So you always have [an] open request, and you end up with one open request per client. In the servlet model, you need a thread per client to service those requests. So that model doesn't scale very well with asynchronous Ajax applications.

In addition, with an Ajax application, you may be in a situation where a response is awaiting a request: If multiple updates to the server-side model occur close to simultaneously, the server may service the first update, and then another update on the server will be waiting for the client to come back with a new request.

We offer both a community and an enterprise edition of ICEFaces, and the enterprise edition solves the Ajax push model's scalability problem with an asynchronous HTTP server. That HTTP server lets you configure the number of threads allowed to be opened, and then [we provide] a queuing mechanism that holds [client] requests. As responses become available, the server uses the available threads to service those requests.

Another feature we provide in the enterprise edition is connection management. Ajax type applications rely on long-lived connections. The ICEFaces enterprise edition does connection heartbeat monitoring, and has the ability to keep the connection healthy if the application [client] sits idle.

Apart from these differences, the community and enterprise editions share the exact same framework, the same component suite, and all the development features are in both the community and the enterprise editions.

Frank Sommers: When we spoke with you at JavaOne 2006, you said that the most problematic part of developing Ajax applications was JavaScript. You said that JavaScript not only executes differently in different browsers, but that managing large JavaScript-based applications is also problematic. What is your approach to easing that difficulty?

Steve Maryka: In a traditional Web app, you deliver HTML [to the client] that represents the presentation. In the example of an email application [for instance], you query the back-end mail server and build up the page, and then you send the presentation to the client. Our framework works in much the same way, and this is where we depart from most Ajax application frameworks.

With our approach, the application is entirely server-based. You write a JavaServer Faces based application. We construct the page on the server. The first time the page loads, we send all of the presentation, all of the markup, to the client, including our JavaScript bridge, which is the communication mechanism between the server and the client. As the presentation changes on the server side, we only deliver those incremental changes to the client, and the client reassembles those changes to the view. From a developer's point of view, you don't care about [how the view is updated], you just think about writing a pure JSF application, all in Java.

This works by taking advantage of JSF's render-kit architecture. In JSF, you have your application logic, and from that you build a component tree, and as part of the JSF life-cycle you go through a render phase. That render phase takes the component tree and runs it through the rendering process. Typically, the rendering process would produce HTML, [but] we built a render kit that produces DOM directly. We build up the DOM on the server side... and that DOM is then essentially replicated via the JavaScript bridge to the client. As the next render pass happens, we re-render the DOM: We take the incremental changes to the DOM, send those across [to the client], and then reassemble those [DOM changes] on the client.

Another dimension of [our JavaScript communications bridge] is user interaction. As the user interacts with a page, you need to get that information back to the server so the application can react to those changes. While direct-to-DOM rendering provides the information flowing to the client, the JavaScript events that happen as the user interacts with [the application] come across the bridge in the other direction. The JSF lifecycle is then allowed to react to what the user is doing, and the presentation can change. That's how you get the smooth interaction between the user and the presentation.

This approach also prevents JavaScript proliferation as a page becomes more complex. As you add more and more stuff to a page, and have more and more pieces [of a page] interact with each other, [in a traditional Ajax application] you have to write JavaScript for all that. With our approach, there's only one piece of JavaScript, the communication bridge, and that does not grow with the complexity of the application. The basic [JavaScript] bridge is 45K, and that's the only JavaScript you will need to run on the client.