Summary
ICEsoft recently released version 1.5.2 of ICEfaces, an open source JSF-based AJAX application framework for Java developers. This release adds support for Jetty Continuations as an alternate way to enable a server to "push" messages to a client.
Advertisement
Although ICEfaces had supported the notion of "Ajax Push" in earlier releases, it had implemented it by supplying an asynchronous server, which uses non-blocking IO, that could be deployed as a separate web application alongside your own web application. (The asynchronous server listens on its own port for client requests.) Version 1.5.2 added support for Jetty Continuations, so that if you're using Jetty 6, you need not deploy the asynchronous server separately, you can just use Jetty.
Artima spoke with Dr. Ted Goddard, Senior Software Architect at ICEsoft, about the Jetty Continuations support. He said:
Jetty continuations let you do blocking HTTP requests. The blocking requests don't tie up threads on the server. This allows you to serve delayed responses to requests that the server receives. You can serve an arbitrary number of requests with a bounded number of threads. This is a fundamental asynchronous capability that the servlet API needs, because there are lots of reasons you may want to delay the handling of a request. The reason this asynchronous capability is important is it lets you scale.
The reason we need it in ICEfaces is we do AJAX push. We make a request to the server and ask, "Do you have any page updates?" This is the next level of AJAX, where the first level would be using XML HTTP requests to refresh portions of a page without doing a full page refresh. But simply using XML HTTP requests that way means the application is still user-driven. "Fully asynchronous" means the server can update the page when it wants to.
The way we enable a server to update a page when it wants is from JavaScript, we get the browser to ask the server if there are any updates at this time. But the server doesn't need to respond right away. It holds the connection open until it has something to send back. In this way, we invert the normal message flow of HTTP, effectively allowing you to send messages from server to client.
In what ways have you needed to delay responses from HTTP requests, and how have you implemented it?
You really don't need this unless you want to provide IRC-like functionality on your page. Basically live updates. I'd say, if you want live updates, you *may* want to look at an applet. :)
Are live updates that important? Is HTML/XHTML designed for live updates? How do live updates benefit our ability to search the web?
Is there any use to live updates beyond the eye candy, the wow factor, and the buzzword factor of "Web 2.0"?
> You really don't need this unless you want to provide > IRC-like functionality on your page. Basically live > updates. I'd say, if you want live updates, you *may* > want to look at an applet. :)
I'll assume you're challenging two points here -- we don't need asynchronous capabilities in Servlets and we don't need Ajax Push.
First, we do need asynchronous capabilities in Servlets for all web applications. It's what allows an application to support a large number of users even if some back-end resource is slow. For instance, if a database query is taking a long time to return, you don't want to block a thread in the web server, you simply want to handle the response when the database query is complete. Continuations give you a particularly elegant way to do this (the final mechanism standardized in the Servlet API might be different, but it will be asynchronous).
Second, Ajax Push can be used for much more than IRC, although that's one of the first things that people tend to implement (I guess people like to talk to each other). It's unfortunate, but Applets have largely failed in the marketplace because of platform UI differences and because of the complexity of JVM installation.
> Are live updates that important? Is HTML/XHTML designed > for live updates? How do live updates benefit our ability > to search the web? > > Is there any use to live updates beyond the eye candy, the > wow factor, and the buzzword factor of "Web 2.0"?
Ajax Push allows you to transform any application into a new communication medium, allowing people to work together in new ways. Chat capabilities are the most obvious; for instance, this message forum could encourage discussion further if pages were dynamically updated as messages were posted. Consider an inventory application: if the inventories update dynamically on the page, users can make better decisions based on current information. Or consider a trip planning application where you and a friend in another city use a dynamically updating map to agree on which route to take.
The more challenging question is can we think of any application that cannot benefit in some profound way from Ajax Push?
With regard to searchability, it's true that many Ajax frameworks make web applications less searchable because they generate the content dynamically within the browser. ICEfaces does not take this approach; all content is generated as complete pages on the server. So, an ICEfaces application will be easily indexable provided you create a set of links to the individual dynamically generated pages.
Could you build a better search engine user interface with Ajax Push? Absolutely. What if working and broken links were progressively highlighted in the search results?
Previous Topic
