An Interview with ICEsoft's Stephen Maryka

---

Most Ajax applications today incorporate some form of asynchronicity (the "a" in Ajax). A popular technique, for instance, updates only a portion of a page in response to an asynchronous server response.

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.

Developers today 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 Ajax and rich-client applications: Enterprise Java developers are increasingly tasked with doing client-side development, including JavaScript development, and asynchronous applications add yet another dimension to that.

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 Ajax capabilities in a manner that's transparent to developers.

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 Ajax and asynchronous capabilities on a per-component basis to JSF. We built an entire component suite around a technique we call direct-to-DOM rendering. That allows you to generate a presentation at the server, and remotely update the client presentation based on that. It gives you what we call automatic Ajax: As a Java developer, you write a pure JSF application, and the framework handles all of the Ajax for you.

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 Ajax updates. From the developer's point, you're just building pure JSF, but you get to use events that trigger changes, and the framework handles all the asynchronous updates.

What do you think of Maryka's description of the asynchronous Web?

Post your opinion in the discussion forum.

Resources

ICEfaces:
http://www.icefaces.org

Talk back!

Have an opinion? Readers have already posted 2 comments about this article. Why not add yours?

About the author

Frank Sommers is Editor-in-Chief of Artima Developer. He also serves as chief editor of the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Advisory Committee. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.