Most
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
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