Such asynchronicity, however, still occurs in response to some action by the user: The difference from a pre-Ajax interaction model is apparent in a more elegant and responsive UI, but the prevalent sort of asynchronicity introduces few truly new interaction models.
In this interview with Artima, Stephen Maryka, CTO of ICEsoft, discusses a potentially more transforming level of asynchronicity, where updates are pushed to the client without the user having to initiate the updates:
When you look at the Web today, it's pretty much based on a synchronous interaction model: The user interacts with the application, and the application responds with some updates. When you move into the asynchronous Web, you have the ability for the application to deliver state changes to the client, without the user necessarily having to initiate those updates. In effect, you can push updates to the client running inside the browser.
Asynchronous push provides information to the user instantaneously, without waiting for the user to request that information. An early, and simple, example is stock quotes that continuously change. Using asynchronous Web technologies can keep a user updated of those changes.
When you take that concept and look at it from a collaborative perspective, you can have one user of an application interact with the app, and cause changes that others will see. Instant messaging and chat applications are examples of that.
If you apply that concept to an even broader category of Web applications, you can create very sophisticated user interactions. That's especially the case in the context of social networking applications. Some social network sites now provide photo sharing that goes beyond simple posting of photos. These applications let you sit down with your friends, however far apart you may be physically, and take them through your slides, give them a slide show over the Web. That's the kind of capability the asynchronous Web can deliver.
Any application that's static today, and where you have multiple people interacting with the same data, such as a blog, can be made a lot more dynamic by having a mechanism for people to interact real-time—for example, by listening in on a blog post or discussion thread, and getting notified of updated comments as users respond.
These examples are all from the consumer space. You can also start to see what it means when these sorts of interactions are introduced into the enterprise. In any application where some interaction happens based on data in a database, when someone updates that data, notifications can make it more efficient for others to follow how data changes—in sales or inventory management, those sort of asynchronous interactions are very important.
For this to work, the necessary deployment infrastructure has to be present. The HTTP protocol was not necessarily built to support the interaction mode I described. Work has been ongoing with various application servers to build in asynchronous communication mechanisms. Tomcat 6 has asynchronous communication capabilities now, and Glassfish has the Grizzly asynchronous message processing infrastructure. Jetty also has had a continuations mechanism for while. There is also ongoing work to standardize some of that through the JCP.
From a developer's perspective, there has been a lot discussion about rich Internet applications, and about making the user experience richer, more efficient, and more effective. The notion of the asynchronous Web adds another dimension to what many people have been envisioning for Ajax: Not only do you have a lot more freedom in the kinds of user interfaces you can deliver to the user, but if you apply data push on top of that, you can really enrich user interactions.
face several challenges in bringing that sort data push to real applications on
top of rich user interfaces. Much of the skill set today in enterprise Java
development focuses on server-based techniques. You want to be able to maintain
that development style for as long as you can so those skills can be made the
best use of. We've already seen that skill-set stretch with
Our focus with ICEfaces has always been to approach these new a paradigms
in a way that allows the developer to continue to use the techniques they're
used to. In this case, the Java standard we support is JSF. We've built in
asynchronous as well as
The result is that developers can continue to build pure Java applications, and still take advantage of asynchronous capabilities. We simply add a slight twist on how you can do that: Instead of just delivering responses to user requests, we provide mechanisms to deal with asynchronous messages, and state changes that happen in response to asynchronous messages. It's a fairly subtle shift for the developer.
People tend to get into difficulties when they add asynchronous capabilities and then soon encounter the need to build out a lot of plumbing to make that actually work. That takes away time and energy from focusing on the more creative part of actually transforming the user experience by being able to deliver push-style capabilities.
In our ICEfaces framework, we proceeded to add
With that in
place, adding push capabilities is a natural next step. From the developer's
perspective, all you do is add some APIs that will identify events that need to
trigger presentation updates. We leverage the JSF lifecycle, and the framework
handles the automatic