AJAX – IMPROVING THE CUSTOMER EXPERIENCE

.":


70-6.&

*446&

…
888"+"94:4$0/$0.

pushing

into high gear

1-64
)PX
UP
4FMFDU

3*"
5FDIOPMPHJFT

%FMJWFSJOH
/FYU(FOFSBUJPO

6TFS
*OUFSGBDFT
6TJOH
"+"9


0SBDMF
9&

"+"9

"TZODISPOPVT
9.-
JO
"DUJPO

'BTU
4DBMBCMF

"+"9
"QQT

RETAILERS PLEASE DISPLAY

UNTIL SEPTEMBER 30, 2007
Scary Question.
Exactly who is developing your next app?

Contact Us

Address:
555 Not My Home St.
Big City, CO 12345
 Your App Starts Here.
We are the leaders in RIA development services.

INCREDIBLE APPLICATIONS

PASSIONATE USERS

PROVEN SUCCESS

Unlock your potential

with the help of industry leaders in
Rich Internet Application development.
10 Years. 1400+ Customers.
Your app starts here.

CYNERGYSYSTEMS.COM
 March 2007

n6 Taking AJAX Seriously n22 Oracle XE + AJAX:

From the Editor
Asynchronous XML in Action
by Roger Strukhoff
Building a real application
by Przemek Piotrowski

n8 How to Select and Mark Townsend

RIA Technologies
Choosing between two paths: n28 Quasar’s Nuqleo System
AJAX or Adobe Integrates AJAX into
by Jeffrey S. Hammond Enterprise Publishing
Work flows improve, bottlenecks disappear

n12 Delivering Next-Generation when taking a Web-based approach

User Interfaces Using AJAX

The user experience is absolutely
n30 Fast Scalable AJAX Apps
Finding and eliminating
central to the Web 2.0 model
bottlenecks and bloat
by Rado Kotorov
by Dylan Schiemann

n16 AJAX Done Right

n32 Pushing AJAX into High Gear
Or, how I learned to stop worrying
A simple streaming AJAX example with the
and love the DOM
OpenAjax Hub, TIBCO GI, and DWR 2.0
by John Eckman
by Kevin Hakman and Joe Walker

ajax.sys-con.com May 2007 


Group Publisher Roger Strukhoff
Art Director Louis F. Cuffari
Editor
Nancy Valentine, 201 802-3044
nancy@sys-con.com
To submit a proposal for an article, go to
http://grids.sys-con.com/proposal.
Subscriptions
E-mail: subscribe@sys-con.com
U.S. Toll Free: 888 303-5282
International: 201 802-3012
Fax: 201 782-9600
Cover Price U.S. $5.99
U.S. $19.99 (12 issues/1 year)
Canada/Mexico: $29.99/year
International: $39.99/year
Credit Card, U.S. Banks
or Money Orders
Back Issues: $12/each
Editorial and Advertising Offices
Postmaster: Send all address changes to:
SYS-CON Media
577 Chestnut Ridge Road,
Woodcliff Lake, NJ 07677
Worldwide Newsstand Distribution
Curtis Circulation Company,
New Milford, NJ
List Rental Information
Kevin Collopy: 845 731-2684,
kevin.collopy@edithroman.com,
Frank Cipolla: 845 731-3832,
frank.cipolla@epostdirect.com
Promotional Reprints
Megan Mussa
megan@sys-con.com
Copyright © 2007
by SYS-CON Publications, Inc. All rights
reserved. No part of this publication may
be reproduced or transmitted in any form
or by any means, electronic or mechani-
cal, including photocopy or any informa-
tion storage and retrieval system, without
written permission.
AJAXWorld Magazine
is published bimonthly (6 times a year)
by SYS-CON Publications, Inc.,
577 Chestnut Ridge Road,
Woodcliff Lake, NJ 07677.
SYS-CON Media and SYS-CON
Publications, Inc., reserve the right to
revise, republish, and authorize its
readers to use the articles submitted
for publication.
 May 2007
From The Editor
Taking AJAX
Seriously
I
t’s fun to watch kids grow up, as
they move from various cute stages
through the obnoxious teen years and
into what passes for maturity these days.
On an accelerated timescale, it’s fun to
watch technologies grow up, too. Some
mature more quickly than others. Some
mature too quickly and die out, while oth-
ers never seem to mature at all.
Over the past two years, AJAX as a
general technological approach seems to
be maturing very quickly. I won’t bore this
magazine’s savvy audience by recount-
ing for the umpteenth time how, when,
and by whom the term was coined, and
I fully realize that many of you had been
working – sometimes for years – with
JavaScript, XML, and related languages
and approaches before the term AJAX
came into existence.
What is important is that AJAX today
is not the AJAX of early 2005. Seen origi-
nally as part of a communitarian Web
2.0 culture that once again threatened to
overturn the so-old, so-dated IT world of
the past, AJAX is, in fact, now becoming
an integral part of any serious enterprise’s
approach to its IT infrastructure.
Google Maps was seen as the quint-
essential AJAX/Web 2.0 manifestation.
Raucous start-ups such as YouTube, Digg,
et al, with huge Web traffic numbers but
precious few employees were seen as the
way of the future. AJAX interfaces prom-
ised to enhance the customer experience,
leave old-fashioned Websites in the dust,
and change the world.
The trouble with revolutions, though,
is that they burn out quickly and don’t
always manage to overthrow the existing
order. It’s too early to tell whether Web 2.0
Roger Strukhoff
is a revolution, a buzzword, or an inflec-
tion point in the history of technology and
civilization. It’s easier to tell what’s hap-
pening with AJAX. Separating AJAX from
Web 2.0 reveals a seriousness of purpose
by AJAX proponents and developers, and
a future that will be more about improv-
ing existing infrastructures than trashing
them.
Improving the customer experience – a
key goal of AJAX – can be measured by the
very large and very serious companies
that are now integrating AJAX into their
front ends. How quickly can customers
find what they need? How does the new
efficiency aid clickthroughs, sales, and
repeat sales? How does it improve the
company’s effort to develop and maintain
a 360-degree customer view? How does
this compare with competitors? How does
it compare with potential competitors?
All of these questions can be answered
objectively and provide information much
more concrete than that provided by a
mere “wow” factor.
As AJAX becomes less and less about
“wow” and more and more about develop-
ing traditional customer satisfaction, we
can expect the market for AJAX technology
providers to grow and grow. Enterprises
are taking AJAX seriously. AJAX is no lon-
ger some sort of revolutionary concept;
it is becoming the way to do business.
It seems as if AJAX has gone from being
the cute kid, skipped those pesky teenage
years, and become a very nice and pro-
ductive young adult.
This may seem like a terribly unglamorous
statement to all of us who like to act like
radicals now and then. But it strikes me as
a beautiful thing. n
ajax.sys-con.com
 Akamai makes AJAX sites perform 5X faster.

As end users graphically edit

price parameters, information
within the main content area
is dynamically updated.

This instance of Google Maps

dynamically updates as
destination cities are chosen.

As arrival and destination times

are modified, flight information
is updated in real-time.

Akamai delivers AJAX Websites up to 5x faster. Ensure To learn more, download a new White Paper:
every transaction is completed with optimal performance Web 2.0 is Here—Is Your Infrastructure Ready?
for each user—even for highly interactive sites. Visit www.akamai.com/AJAX

©2007 Akamai Technologies, Inc. The Akamai logo is a registered trademark

of Akamai Technologies, Inc. All Rights Reserved
 Frameworks
How to Select RIA Technologies
Choosing between two paths: AJAX or Adobe
Jeffrey Hammond is a senior analyst at
Forrester Research where he covers tools
and techniques for application
design and development.
 May 2007
W
hen it comes to rich Internet appli-
cation (RIA) technologies, application
development professionals must choose
between two paths: AJAX or Adobe. AJAX is the best
bet for experienced Web development shops looking
to incrementally evolve existing Web applications.
Of course, selecting AJAX also raises the question of
whether to go with a homegrown, open source, or
commercial AJAX framework.
In contrast, Adobe is best for shops looking to
completely transform their Web experiences. But
to do so, firms must acquire the skills necessary to
use Flex, which is the development framework for
the Flash runtime environment. Early adopters with
time-to-market concerns and comfort with either
smaller vendors or open source can select AJAX with
confidence. But firms that require support from a
larger vendor and full-featured development tools
will do better with Adobe.
App dev professionals should make the selec-
tion based on their time-to-market requirements,
whether they’re looking to evolve or revolutionize
their user experience, and whether they prefer tools
from large established vendors.
AJAX: The Fast Lane to a
Better User Experience
App dev organizations that prefer a fast path to
RIAs — for developers and users alike — select AJAX
for the following reasons:
• AJAX helps shops meet time-to-market needs.
Developers with existing Web skills find that
adopting AJAX involves a shift in design patterns,
not a wholesale change in programming language
or development tools.
• AJAX favors gradual re-factoring of existing Web
apps. AJAX is based on open and standard lan-
guages like JavaScript and XML. This makes it easy
for developers to integrate AJAX widgets into exist-
ing Web applications that are written in HTML,
DHTML, or server-side JavaScript.
• AJAX can deliver speedy performance. Vendors of
commercial AJAX frameworks like Backbase and
JackBe invest considerable resources tuning their
AJAX frameworks for speed because their clients
by Jeffrey S. Hammond
have tiny footprints and download to browsers so
quickly that there’s no perceptible lag in app per-
formance. Some open source AJAX tool kits share
this trait, but others approach the size of Adobe’s
Flash and have equally long install times.
Developers and architects may salivate over the
technical merits of AJAX, but managers should note
that using AJAX frameworks also introduces risk.
Unmanaged, these risks can increase costs or derail
a development effort entirely. For example:
• It’s easy to choose the wrong AJAX framework.
There are dozens of popular AJAX frameworks,
and they are not created equal. Developers might
want to cut a check based solely on a framework’s
rich widget set or light-speed performance, but
architects will need to validate that the framework
supports corporate standards for security, acces-
sibility, service integration, and data access.
• Finding best-of-breed AJAX development tools
is difficult. Experienced Web developers don’t
mind writing JavaScript and XML in text editors,
but most developers in enterprise IT shops pre-
fer visual designers and WYSIWYG editing tools.
When it comes to AJAX, the only such tool support
available at present is tied to commercial AJAX
frameworks, meaning that the choice of one is
necessarily a choice of the other.
• Cross-browser compatibility issues increase test-
ing costs for AJAX. Testing costs increase in direct
proportion to the number of browser platforms
and versions to be supported. However, using a
commercial AJAX framework can mitigate these
costs, as the framework vendor incurs the cost of
cross-browser testing. For example, Software AG
certifies its cross-vision Application Composer
on multiple versions of browsers like Internet
Explorer, Mozilla, and Netscape.
The AJAX Path Itself Forks with
Homegrown, Open Source, and
Commercial Alternatives
Just because a development team has chosen
to go with AJAX doesn’t mean that its tool selection
effort is complete. There remains the important
ajax.sys-con.com
decision of how many and what type of AJAX frame-
works to use. Today there are three types:
• Many developers create their own frameworks.
Development teams create their own AJAX wid-
gets when they need customized controls that
work in a specific way.
• Other developers build on top of open source
frameworks. Open source communities engage in
a constant process of peer review, which quickly
separates good design from bad. This leads to
successful projects maturing quickly, while poor
frameworks lose critical mass. When selecting an
open source framework, look for active develop-
ment communities with committed corporate
sponsors, as this is an indication of longevity.
OpenLaszlo, Dojo, and the Google Web Toolkit
(GWT), for example, are supported by corpo-
rate sponsors like Laszlo Systems, IBM, AOL, and
Google.
• Commercial frameworks provide a throat to
choke. Commercial AJAX vendors provide sup-
port and certification of their products, which is
appealing for managers who are uncomfortable
taking the open source route. They also focus on
providing capabilities that enterprise developers
require, including high-performance clients and
tooling that makes it easy for developers to con-
nect to enterprise applications.
Just as there are myriad AJAX frameworks, there
are also myriad AJAX framework selection criteria.
These criteria fall into five buckets: customizability;
security and accessibility; widget set; tooling; and
cross-browser support. But not all of these criteria
should be weighted equally (see Figure 1).
Adobe’s Solution Is Powerful, Predictable,
and Productive
Adobe is an attractive RIA solution because it
combines powerful development tools (Flex) with
a near-universal browser plug-in (Flash) that’s
designed to simplify RIA deployment. Managers who
have concerns about small commercial AJAX provid-
ers or support issues with open source AJAX frame-
works consider Flex a safe alternative. But there is a
downside: To be productive in Flex, developers have
to learn two new languages and an extensive run-
time framework — something that can take between
one and three months to learn. Once this initial
hurdle is cleared, Adobe adopters see the following
benefits:
• Widespread adoption of Flash speeds deploy-
ment. When Flash is already installed, application
deployment requires no additional changes to the
ajax.sys-con.com
user’s desktop. Unlike AJAX, Flash doesn’t require
browser-specific code or enablement of JavaScript SYS-CON Media
in the user’s browser. President & CEO
Fuat Kircaali, 201 802-3001
• Flex works well for large-scale RIAs. Large-scale
fuat@sys-con.com
user productivity applications are often designed Group Publisher
with conversation flows that require access to Roger Strukhoff, 201 802-3040
roger@sys-con.com
business data and rules to drive application con-
text. Flex makes it easy for developers to provide Advertising
the right business context and flow while keeping Senior Vice President,
response times to a minimum. Sales & Marketing
Carmen Gonzalez, 201 802-3021
• Flex is evolving quickly and has a predictable
carmen@sys-con.com
trajectory. Adobe has invested heavily in Flex, Advertising Sales Director
and the result has been sustained improvement Megan Mussa, 201 802-3028
from release to release. In contrast, the future of megan@sys-con.com
Associate Sales Manager
AJAX depends on the whims of a dozen vendors
Corinna Melcon, 201 802-3026
and open source projects that aren’t even loosely corinna@sys-con.com
federated. In the words of one architect we spoke Events Manager
with, Flex is “one support framework to rely on, Lauren Orsi, 201 802-3022
lauren@sys-con.com
not dozens to integrate.”
Events Associate
• Flex Builder improves developer productivity Sharmonique Shade, 201 802-3024
and collaboration with designers. Flex Builder sharmonique@sys-con.com
provides developers with a visual, WYSIWYG
Production
experience on a par with the best commercial
Lead Designer
tools for AJAX. What sets Flex Builder apart from Louis F. Cuffari, 201 802-3035
these tools, though, are features that improve louis@sys-con.com
Art Director
collaboration between developers and designers.
Alex Botero, 201 802-3031
Using Flex lets developers and designers at the alex@sys-con.com
American Cancer Society rapidly iterate through Associate Art Directors
design changes and preview them with stakehold- Tami Beatty, 201 802-3038
tami@sys-con.com
ers within hours.
Abraham Addo, 201 802-3037
abraham@sys-con.com
Flex Developers Are Hard to Find and Other
Drawbacks of Flex SYS-CON.COM
Vice President Information
But Adobe isn’t perfect. App dev professionals
Bruno Decaudin, 201 802-3051
should consider the following Adobe drawbacks: bruno@sys-con.com
• Flex developers are difficult to locate and com- Consultant, Information Systems
mand a premium rate. Flex developers are harder Robert Diamond
to find and more expensive to retain than AJAX
robert@sys-con.com
Web Designers
developers: In the United States, they start at Stephen Kilmurray, 201 802-3053
$60,000 and top out around $120,000. One execu- stephen@sys-con.com
tive at a North American financial services firm we Richard Walter, 201 802-3057
richard@sys-con.com
spoke with had to retain talent from South Africa
and the Czech Republic to deliver a successful Accounting
project. As more developers ramp up on Flex this Financial Analyst
Joan LaRose, 201 802-3081
issue will subside, but for now it makes Flex more
joan@sys-con.com
expensive in the short-term than Ajax. Accounts Payable
• Flash upgrade issues can defeat the deployment Betty White, 201 802-3002
value proposition. When users aren’t on the lat- betty@sys-con.com
est version of Flash, requiring them to upgrade is
Customer Relations
risky because almost half will abandon the site. Circulation Service Coordinators
Many are unwilling to wait through the lengthy Edna Earle Russell
install process and instead choose to do business edna@sys-con.com
Alicia Nolan, 201 802-3081
elsewhere — potentially with the competition.
Alicia@sys-con.com
• Success can create an unexpected user response.
May 2007 
 Flash is a broad graphical canvas, and Flex allows
designers to push the boundaries of rich media
further than AJAX does. This can lead to a situa-
tion where users become distracted by a mix of
Flash’s rich media and Flex’s new controls. IT orga-
nizations can avoid this response by introducing
rich media gradually and frequently conducting
A/B testing with focus groups.
Which RIA Technology Is Best for You?
When aggressive developers push the boundaries
of RIA development, they quickly run into barriers
that affect their ability to take full advantage of RIA
technology. Firms interviewed recently by Forrester
Research cited several barriers to their RIA develop-
ment efforts that no tooling available today could
overcome (see Figure 2).
In selecting an RIA technology, application
development professionals should choose AJAX
when time-to-market is critical and updates are
frequent. Experienced Web developers ramp up on
AJAX quickly. AJAX also makes it easy to build RIA
capabilities into existing apps with small, frequent
Figure 1:
Figure 2:
10 May 2007
releases. Finally, AJAX’s customization capabilities
make it possible to tune client frameworks to meet
specific application footprints; this makes AJAX the
better solution for smaller RIA deployments and for
deployments where performance is critical.
For large-scale user productivity applications,
developers should use Flex. Although Flash’s client
footprint is larger than AJAX frameworks, its mar-
ket penetration makes it the preferred deployment
platform for larger, comprehensive RIAs. Adobe is a
safe choice for those who put a high value on reliable
support and product continuity, concerns that are
key when making strategic technology investments.
The downside is that safety comes at the price of
openness.
The benefits are clear: RIAs help users find and
manipulate relevant content, complete complex
transactions, and consume multimedia in the con-
text of a larger app, providing improved customer
experience, higher Web conversion rates, and thus
improved revenues. While there’s no one answer to
the question of which to use, AJAX and Flex provide
today’s developers with options. n
ajax.sys-con.com
 “Pre-built Ajax widgets, cross-browser
compatibility and the full support of the
Backbase team were the keys to our
selecting Backbase.”
Robert Leerdam, Project Manager, ABN/AMRO

Backbase Enterprise Ajax: The Complete Development Solution for Ajax

TRY IT
NOW!

Download a free trial at

www.backbase.com

Product Highlights
• Cross-browser Ajax client runtime
• Simple and easy-to-use Ajax tags
• 100+ Ajax widgets w/ source
• Ajax development tools
• Debugging and testing tools
• SOA integration
• Integration with portal servers
• Server-side integration with Struts and JSF
• Section 508 / WAI compliance
• Extensive documentation and tutorials
• Sample applications
• Open API
• Proven RIA blueprint implementations
• Comprehensive 24x7 support

For more information, call 866-800-8996 (Americas); +31 20 465 8888 (ROW)
 Web 2.0
Delivering Next-Generation
User Interfaces Using AJAX
The user experience is absolutely central to the Web 2.0 model
Rado Kotorov is a technical director of stra-
tegic product management for Information
Builders, Inc., responsible for emerging
reporting, analytic, and visualization
technologies.
12
B
y any reckoning, the Internet and the World
Wide Web have remade the way we do busi-
ness. The ascendance of the Web-based
enterprise has come to be seen as inevitable. But
anyone who takes a hard look at the serious limita-
tions of first-generation Web applications is likely
to have a renewed sense of wonder at the spread
of their adoption thus far. Users experimented with
e-mail, instant messaging, and search engines and
turned them into real communication, collabora-
tion, and information-gathering tools. Those same
business users endured their fitful interactions with
static HTML pages and moved applications to the
Web anyway because of the substantial savings
promised by the shift.
Now their patience is about to be rewarded.
Emerging from a decade of groundwork is Web 2.0,
which offers dramatic gains in productivity for indi-
vidual workers and whole enterprises. Web 2.0 appli-
cations are distributed collaborative tools available
on-demand from any browser anywhere. And those
tools are constructed to be at least as intuitive and
easy-to-use as any application loaded on a desktop.
Web 2.0 is based on many technologies – most
prominent among them being Web Services,
Asynchronous JavaScript and XML (AJAX),
Cascading Style Sheets (CSS), and Really Simple
(Web) Syndication (RSS) – and the list will continue
to grow. Of these, AJAX has attracted the most atten-
tion recently because it’s the technology that most
effectively fills the gap between the user experience
of Web and desktop applications.
And the user experience is absolutely central
to the Web 2.0 model. Web 2.0 applications must
possess a set of user interface components that
are as compelling and responsive as a desktop-
based environment. Developers can no longer be
satisfied to offer discontinuity in user experience,
because widely distributed, frequently mobile users
won’t be able to tolerate it and do their jobs well.
The improved user experience will include, but
must extend beyond, the most common productivity
tools, such as word processing applications and e-
May 2007
by Rado Kotorov
mail. Web 2.0 and AJAX-based applications represent
an opportunity to fully realize the Web’s potential to
make users smarter and more productive, and that
opportunity extends to the most sophisticated back-
end and analytic applications.
How We Got Here: Evolutionary Steps to
Web 2.0
As any significant technology evolves toward
maturity, attention shifts from the technology itself
to the work that the technology enables. That shift is
clearly manifest in Web 2.0, the third major phase of
the Web’s evolution, which can be summarized like
this:
• Web 1.0 – Content delivery and communication.
This early stage changed the dissemination of
information via two innovations, HTML pages and
e-mail.
• Web 1.5 – Content personalization and multi-
level communication. Search and personalization
made the spread of information more efficient,
while chat rooms and instant messaging expand-
ed communication in real-time.
• Web 2.0 – Authoring and collaboration. This cur-
rent stage is not about the dissemination of infor-
mation, it’s about productivity – accomplishing
work-related tasks in a virtual space with tools and
applications that are available anywhere, at any
time, and can be shared collaboratively.
In the past, Web applications’ lack of respon-
siveness and dearth of controls offset most of their
advantages as thin-client tools. In contrast, desk-
top developers have historically taken advantage of
two capabilities of Windows that make applications
more intuitive and user-friendly than their Web
counterparts: richness and responsiveness. When a
complex and robust set of UI components is com-
bined as they have been on the desktop, they make
the user interface natural, informative, and intui-
tive to use. And when the application and the user
interface quickly adapt to user actions, they create
an uninterrupted interaction. Windows applications
ajax.sys-con.com
don’t stop to reload, forcing users to move through
tasks in stops and starts – or causing them to lose the
thread of the business process entirely.
The user experience gap between Windows and
the Web has been due to the limitations of the early
Web client/server model, with the Web server as the
platform for all processing logic and the browser as the
client handling nothing more than the data display. In
this architecture, users interact with HTML and each
of their actions triggers a request to the server, which
in turn triggers the generation of a new page.
The incessant reloading of the page severely
limits the user experience for a couple reasons. First,
flipping from page to page can disorient the user as
the allocation of tasks on different page views causes
loss of context. On top of that, reloading the page
causes a disjointed and rigid interactive flow. The
user has to wait for the next page to initiate a new
interaction or change the workflow, or be bounced
back to the previous page to alter information in
a field. Think of the online shopper on a retail site
who can’t order three shirts instead of two without
returning to page one, and then extend the problem
to business users struggling with enterprise applica-
tions throughout their workday.
The difficulties of the interaction are compound-
ed as the complexity of applications and user options
increases. For example, imagine the user experience
of writing a document in an application created in
Web client/server mode. For each paragraph, the
user must open a dialog, enter the text in the input
box, and wait for the changes to be applied to the
document when the page is refreshed. And then all
the steps must be repeated for every edit or format
change. The frustrated user needs plenty of patience
and training to work with the tool.
Enter AJAX
By contrast, AJAX combines technologies such
as asynchronous JavaScript, the Document Object
Model, XMLhttpRequest, XHTML, and CSS so the
user can incrementally update any element of an
application that resides in the browser. The user
ajax.sys-con.com
never leaves the application – never loses context
or suffers interrupted workflow – because no action
triggers the reloading of a full page.
This seemingly small change has a profound
effect on the user’s experience. Transferring more of
the interaction to the client side not only improves
the workflow, it also allows the addition of enrich-
ing UI components, which put AJAX-based Web
applications on a par with desktop applications for
usability. There are, it should be noted, alternatives
to AJAX – Adobe’s Flash technology also provides a
means to develop rich clients and DHTML allows
one to partially upload components on an HTML
page without reloading the entire page. But AJAX’s
combination of cross-browser compatibility, zero
footprint, and ability to provide interactive com-
plexity to the user gives it a leg up on the competi-
tive technologies.
The improved interactivity of Web 2.0 applications
is driving even more applications off the desktop,
since the lower total cost of ownership now comes
without the offsetting negatives of cumbersome
user experience. These transitional Web 2.0 applica-
tions enabled by AJAX have been productivity tools,
such as word processing and e-mail applications,
calendars and spreadsheets. Examples are Google’s
recently released Writely and Google Spreadsheets;
competitive word processors like Zoho Writer, Abe
Writeboard, and ajaxWrite; Num Sum spreadsheet
functionality; and 30 boxes, a Web-based calendar.
Web-based desktops are also emerging, like the one
available at www.desktoptwo.com.
Their lower TCO comes from centralizing most of
the software in a single location on the server, with
only a browser installed on desktops throughout the
organization. This lowers installation and mainte-
nance costs, provides for incremental upgrades to
existing applications, creates user administration
savings, and offers enterprise-wide control over doc-
ument backup and archiving, as well as compliance
and security. The Web 2.0 model makes applications
– continued on page 18
May 2007 13
 Solutions
AJAX Done Right
Or, how I learned to stop worrying and love the DOM
John Eckman leads the Next Generation
Internet Practice at Optaros (www.optaros.
com), and has over a decade of experience
designing and building Web applications
for organizations ranging from small
non-profit organizations to Fortune 500
enterprises. John´s technical background
includes J2EE and .NET frameworks as well
as scripting languages and presentation-
tier development approaches, in addition
to information architecture, usability test-
ing, and project management. He received
a BA from Boston University and a PhD
from the University of Washington at
Seattle; he expects to complete an MS in
Information Systems from Northeastern
University in 2006. He also achieved PMP
certification in 2003.
jeckman@optaros.com
14
T
he Bad Old Days, or, I Walked a Hundred Miles
to School, in the Snow, and It Was Uphill Both
Ways
Back in the late ’90s, people started to use the
term “Dynamic HTML,” often shortened to DHTML,
to describe the use of JavaScript to manipulate
HTML in the browser. Basic DHTML meant rollover
images that changed state when you moused over
them or drop-down menus that cascaded down
from the top navigation. More complex DHTML
concepts included dragging-and-dropping objects,
hiding and revealing content, and even whole games
built purely from HTML, images, and JavaScript.
The problem with DHTML, of course, was that it
was tremendously hard to do. More accurately, it was
tremendously hard to do well in a cost-effective way.
It was certainly possible to do some of the simpler
functions (drop-down menus, mouseovers) in a reli-
able cross-browser, cross-platform way. But anything
more complicated than that quickly ran into the
problem of alternate browser implementations: for
example, using the “layer” tag for Netscape 4, but the
“iframe” for Internet Explorer and newer Netscape/
Mozilla browsers. Similarly, Internet Explorer 5.x and
later supported document.getElementByID() as did
the Mozilla-based browsers, but Internet Explorer
4.x relied on document.all, and Netscape 4.x on
document.layers.
The whole experience got confusing rather quick-
ly, leading to a number of different alternatives.
Many individuals coded applications or sites
directly to a single browser, leading to the phenome-
non of “Best Viewed in…” badges on sites. (I thought
this behavior had gone the way of the “blink” tag,
but Wal-Mart’s recent digital download site exhibited
similar behavior – for several weeks following the
launch, the site greeted Firefox visitors with an apol-
ogy: “We’re sorry. Our Web site requires the browser
Internet Explorer version 6 or higher. It appears that
you’re using Firefox, Safari, or another browser that
Wal-Mart Video Downloads doesn’t currently sup-
port.” In early March, however, it appeared that the
problems had been rectified.)
May 2007
by John Eckman
Some JavaScript developers learned to create
applications with a series of if-then statements
pointing to specific versions for specific browsers,
replicating the functionality in each major “support-
ed” browser. Sometimes this led to unanticipated
results, as when the tests were too specific (look-
ing for a particular version of a particular browser)
they often broke when new browsers were released.
(Smarter developers learned to test for specific func-
tionality, rather than looking for a particular browser
version – but this could still lead to a number of code
branches for different browser levels.)
Some Web designers found an alternative in
Flash. Flash enabled designers to create animation,
use sound, and create interactivity on the page
without having to worry about browser versions and
platforms. Because Macromedia (now Adobe) is the
sole supplier of the Flash plug-in, it can offer com-
plete control over the experience for both developers
and users. Designers who resisted the urge to create
monster intro movies and used Flash judiciously as
a supplement to an HTML page, rather than as a
replacement for it, found great power in the ability
to add interactive elements and animation without
having to decipher the complexities of DHTML.
(A number of these first-generation Web designers
abused Flash’s power, creating unnecessary ani-
mation, breaking the very interface conventions
new Web users so desperately needed, and sticking
“introduction” movies in front of Web pages, leading
to the birth of the infamous “Skip Intro” button. See
http://www.skipintro.nl/skipintro/ for a humorous
version of the problem.)
Finally, a significant number of information
architects and Web designers simply learned to avoid
DHTML altogether, or at least to avoid any of the
“more complicated” functions. I remember seeing
statements of work for Web development that either
specifically excluded anything but the most basic
DHTML or noted that DHTML use would increase
risk and cost. If you didn’t have the right JavaScript-
and browser-savvy resources as part of your Web
team, it was undoubtedly safer simply to stay away.
ajax.sys-con.com
 None of these approaches, of course, solved
the core problem, or provided a repeatable, cost-
effective (in terms of development and debug-
ging time), standards-based, plug-in independent,
cross-browser solution to browser-side interactiv-
ity.
There’s Got to Be a Better Way: AJAX
The solution, as readers of this publication
undoubtedly recognize, came in the form of AJAX.
As I’ve written in an earlier article in these pages,
Jesse James Garrett’s essay became such a perva-
sive meme precisely because it appeared to cut the
Gordian knot that had long plagued Web develop-
ment using JavaScript. What Garrett’s “AJAX” did was
to give a name to a series of approaches that had
been many years in the works:
As the user base of the old Netscape 4.x applica-
tions waned, and the availability of new platforms
rose, developers were emboldened by the relative ease
of developing cross-browser standard applications
with rich interaction in JavaScript and CSS, more and
more developers started to create AJAX applications.
Garrett’s essay crystallized this movement and gave it
a name.
While Garrett referred directly to the use of
Asynchronous JavaScript and XML, the name
is commonly applied to all kinds of uses of
JavaScript for interactivity: some entirely syn-
chronous, and many bypassing XML in favor of
data representations like JSON. The point really
is that the AJAX label effectively negated the
fears associated with DHTML, and signaled to
the development and design communities (as
well as the customers who write the checks for
site development) that it was now possible to
build client-side interactivity without immense
pain.
Buoyed by the excitement over the Mozilla proj-
ect, and the relative stability of the Document Object
Model (DOM), a number of frameworks emerged
to make AJAX-style development easier, abstract-
ajax.sys-con.com
ing away the plumbing to handle multiple browser
implementations and interpretations.
We have to be wary, however, of the assump-
tion that just because developing AJAX-style Web
applications has gotten easier, we’ve gotten better at
developing them.
Just as word processing software doesn’t (in and
of itself ) improve one’s writing, having access to
frameworks that facilitate AJAX-style development
has increased the potential for users to develop truly
both good usable applications and horrible unus-
able applications.
How can we avoid the “Skip Intro” phase of AJAX
development and move right into the mature, stable,
usable application era?
First, Do No Harm: Don’t
Break the Back Button
It’s crucial that while AJAX can make Web applications
more like desktop applications, it should not remove the
strengths of Web applications in the process or interfere
in the fundamental architectures of the Web.
This means, first and foremost, not breaking the
conventions of back button use, bookmarking, and
link sharing. Granted, these conventions may have
different meaning in different applications, but they
should be thoughtfully considered and only dis-
rupted for a specific rationale. Full AJAX applications
that provide rich interactive functionality but aren’t
conceptually linked to a page-based interface may
not be able to support the conventional use of the
back button. If the interface has no notion of pages,
and is all in a single HTML page, what sense does the
back button make?
For example, Zimbra’s Collaboration Suite, a
Microsoft Outlook- or Lotus Notes-style e-mail client
and calendaring system, doesn’t “support” the back
button in the sense of allowing the user to click on
the browser’s “back” button and somehow change
the interface to the last viewed page or last entry in
the browser history. Because the entire application
lives in a single page at a given URL, allowing the
“normal” function of the back button would result
May 2007 15
 in jumping back out of the application.
However, Zimbra doesn’t simply disable or hide
the back button. Instead, the application pops up a
confirmation dialogue (the same dialogue is used for
other browser-actions that would navigate away, like
clicking on a bookmark, or typing a new address in
the address bar) as shown in Figure 1.
This elegant solution lets the user remain in
control rather than deciding on the user’s behalf.
If, indeed, the user intended to navigate away from
Zimbra – perhaps using the application for now – the
user can simply hit OK and be off to the requested
page. If the user didn’t intend to navigate away, a
simple cancel returns them to the active context
without interruption.
Google’s Gmail, on the other hand, supports the
back button by taking meaningful action when the
user clicks it. If you’re viewing your inbox and click
on a particular message, Gmail loads that message
in the center content pane. Click on the back button
and you return to the inbox view. Because Gmail
treats the different views in a fashion consistent with
the Web-native page metaphor, it makes sense that
the back button should funct ion this way.
Similarly, applications that run in Web brows-
ers should either support or provide meaningful
alternatives to bookmarkability and link sharing.
Google Maps is a wonderful example of this, pro-
viding a “link to this map” icon that enables users
to reproduce a complex map, complete with zoom
level, map type, and current center point, simply by
providing a URL.
Learning What Not to Do, All Over Again:
Security in AJAX Applications
Some have argued that AJAX applications are nec-
essarily more insecure than traditional Web applica-
tions, because they inherently expose a larger “attack
surface.” While I’m not certain I agree with calling
any broadly defined development approach inher-
ently less secure – we’ve all seen how poor develop-
ment practices can make any application prone to
successful exploits – these critics are right to point to
two specific concerns. These concerns are not in fact
unique to AJAX development, but they do have to be
Figure 1: Confirmation Dialog
16 May 2007
understood in new ways.
First, never trust any data that comes from the
client. This has been a truism of Web development
from the beginning. In fact, this was true in cli-
ent/server environments as well: just because it was
much more difficult in client/server environments
for someone to manipulate the client didn’t mean
that client input shouldn’t be checked.
The difference that an AJAX application intro-
duces, as compared to a traditional Web applica-
tion, is the fact that more data manipulation and
processing can be done on the client, and more
complex interactions can be expected between the
client and server. The developer has to be aware
that the threshold is fairly low for users to create
alternate clients that return falsified, inaccurate,
or (worse) deliberately malicious data. Any kind of
Web input form was always already subject to such
forgeries and attacks – but in an AJAX Web applica-
tion you may have many more of them.
While one might be tempted to assume that an
HTTP request generated by a client-side JavaScript
function deep within your complicated application
is less likely to be forged than a simple Web form, but
this is a slippery slope. Far better to assume that any
input that comes from the client (either directly from
the end user or from a JavaScript function) is guilty
until proven otherwise.
Second, don’t send data to the client that you
don’t want the user to see. This has also been a Web
truism from very early on. Many systems are careful
in responding to failed logins to avoid giving more
information than necessary about what went wrong
– typically not telling you, for example, whether
there is or isn’t a username matching what you
entered, just that the username-password combina-
tion is invalid.
The fact that AJAX offers the ability to do client-
side form validation doesn’t mean that you can skip
server-side validation (remember truism number one
above), and it also doesn’t mean that you always
should do client-side validation. Doing so will reveal
to the user what the correct formats are. (In general
this is not a bad thing – but if, as in one recent public
example, what you are validating is a “discount code,”
revealing that code to prying eyes is a no-no).
The Internet Is a Series of Tubes, and the
Tubes Can Be Filled: Keeping Traffic Light
Another common complaint about Web applica-
tions that leverage AJAX is that they can be hard on
the infrastructure: creating additional traffic through
a higher number of requests and swelling bandwidth
as large JavaScript files are downloaded. Although
the increasing prevalence of broadband has made
site download size less of a factor, it’s still critical
ajax.sys-con.com
 Advertising Index
Advertiser URL Phone Page
Akamai www.akamai.com/AJAX 7
BackBase www.backbase.com 866-800-8996 11
Cynergy Systems www.cynergysystems.com 2-3
ICEsoft www.icesoft.com 877-263-3822 17
JackBe www.jackbe.com 240-744-7620 19
Laszlo www.laszlosystems.com/go/webtop 4
NexaWeb www.nexaweb.com 27
Passport www.passportcorp.com 800-926-6736 35
SoftwareAG www.softwareag.com/Ajax 29
Telerik www.telerik.com/prometheus 36
TIBCO http://developer.tibco.com/ 23
Advertiser index is provided as an additional service to our readers. Publisher does not assume any liability
for ommissions and/or misprints in this listing since this listing is not part of any insertion order.
that Web-based applications don’t ignore bandwidth
consumption and traffic generation.
AJAX developers should pay close attention
to caching strategies, designing, segmenting, and
combining code so that libraries of JavaScript can
be aggressively cached on the client and don’t
require frequent downloads. In addition, develop-
ers shouldn’t overlook compression options for
JavaScript code.
It’s also important to be cautious about the net-
work travel your AJAX application generates.
Remember that there are two important factors at
play: actual performance and perceived performance.
The actual performance is the volume of requests
the Web server handles in a given unit of time, and it
includes asynchronous JavaScript calls as well as the
direct user-initiated clickstream. AJAX applications
often increase the number of HTTP connections each
client will make to the server, and may or may not
– continued from page 13
instantly available to users, eliminating desktop
installations. And it’s a model that can be extended
to applications across the enterprise.
For example, as sophisticated analytics and busi-
ness intelligence information are pushed further out
into the enterprise, it is essential that applications
deliver the information smoothly, clearly, and in an
uninterrupted context. AJAX provides the foundation
for user interfaces based on reusable components,
each of which enables a set of UI functions that can be
manipulated individually for or by the user. The flex-
ibility inherent in AJAX-enabled applications translates
into quick, easy rollouts of new functionality as user
needs change, as well as the ability to customize the
interface for users based on their roles and specific
needs. Improving the user experience translates into
a parallel improvement in the user’s ability to apply
high-level information to the decision-making process,
18 May 2007
increase the number of requests each client makes.
The perceived performance is much more difficult
to measure, but has to do with how responsive users
perceive the application to be. If certain requests are
made asynchronously, they may appear more respon-
sive when the user actually examines the data, having
been “pre-fetched.” On the other hand, if the number
of asynchronous calls going on is high, it may actually
begin to negatively impact the users’ experience.
The key is that at the end of the day, actual per-
formance and perceived performance are tenuously
linked: applications with lower actual performance
may be perceived as having higher performance, and
vice versa, depending on the end users’ experience.
(Of course, there are infrastructure cost factors to the
actual performance as well, perceptions aside.)
Your best bet is to prototype rapidly, measure early,
and improve iteratively. Don’t wait until the end of a
cycle to discover that your application will saturate
your connection or take prohibitively long to load.
The More Things Change…
All in all, the good news is that the principles that
make well-designed AJAX applications aren’t radi-
cally different than those that have been best prac-
tices all along in Web-based applications. The new
capabilities AJAX offers inevitably create scenarios
where there is no clear design consensus and where
the application of the principles requires careful
planning, thoughtful design, and a fair amount of
trial and error.
But it sure beats DHTML and the “Stupid Browser
Tricks” it forced on us. n
which is, after all, the goal of business intelligence.
Organizations were moving applications to the
Web even before the emergence of Web 2.0 and
AJAX-based tools because cost savings were so
attractive that they trumped the limitations of first-
generation Web applications. Now, with Web 2.0
applications that provide a user experience equal to
that of desktop applications, that trend is going to
build momentum rapidly.
For several years, enthusiasts have predicted that
the impact of the Internet and the Web will rival that
of the Industrial Revolution. Driven by the same
need to use resources more effectively and increase
productivity as that earlier transformation, Web 2.0
could make those predictions come true. But instead
of centralizing workers and machines in factories,
Web 2.0 will liberate a distributed, mobile workforce
by offering consistent access to applications and
information anywhere in the complex world of the
global enterprise. n
ajax.sys-con.com
 Facing a few barriers
on the road to SOA?

JackBe’s Rich Enterprise Application (REA) platform

clears the road to SOA business benefits.
There’s an abundance of products and vendors to help you create your SOA. Now, consume
those SOA services with JackBe REAs to achieve the business productivity and results that led
you to SOA in the first place. Our new REA platform combines the power of Ajax and SOA with
reliable, secure communications to extend your SOA directly into powerful business applications.
A fully visual IDE reduces manual coding and accelerates the development process. And our
lightweight, vendor-neutral platform easily integrates with existing middleware and services while
maintaining server-side governance and control--unlike products that leave governance to the
browser or create middleware platform dependencies.
Join over 35 industry leaders like Citigroup, the U.S. Defense Intelligence Agency, Sears,
Tupperware, and Forbes who are already optimizing their business activity with JackBe solutions.
Call or visit our website—let us help you remove the barriers on the road to achieving real
business value from your SOA investment.

Web: www.jackbe.com
Phone: (240) 744-7620
Optimizing Business Activity Email: info@jackbe.com
 Inside Look
Oracle XE + AJAX:
Asynchronous XML in Action
Building a real application
Przemek Piotrowski has been following
Oracle 10g Express Edition (Oracle XE)
development since its early beta stages back
in 2005 and can easily distinguish the new
features in this first database from Oracle
that’s free to develop, deploy, and distribute.
Oracle XE’s small footprint doesn’t stop
him from taking advantage of many of its
advanced features and plugging them into
existing Web architectures.
Mark Townsend is vice-president of data-
base product management in Oracle’s
Server Technology Division. His responsibil-
ities include requirement analysis, release
planning, coordinating database product
management activities, communicating
with analysts and the press on database
topics, and the development and delivery
of field technical training. He was product
boss for Oracle XE. Mark has been with
Oracle since 1991 and has specialized in
the Oracle database for over 15 years.
20
T
his article covers the process of building a real
working AJAX application on top of Oracle’s
free database software. The demonstration
takes advantage of features integrated directly into
Oracle Database 10g Express Edition (Oracle XE), the
Embedded PL/SQL Gateway and Oracle XML DB,
which let you serve XML content derived from SQL
queries directly over HTTP protocol.
You’ve probably run up against one of the
numerous frameworks for AJAX that were proba-
bly Java- or .NET-based. Although they fit large-
scale environments perfectly, smaller projects may
not require such overwhelming resources as a J2EE
stack. Besides, understanding the technology behind
XMLHttpRequest may help you use asynchronous
requests better under just about any Web develop-
ment environment.
The concept is surprisingly simple – to make Web
applications more responsive so that they behave like
regular desktop software. Waiting for a page to reload
just to see a change in a single place seems like a com-
plete waste of both time and bandwidth. Having said
that, using AJAX to create Web applications is good not
only for the end user, but for the Web server as well.
Applying this relatively simple technique boosts
your Web applications’ usability many times. The
potential of AJAX is so big that Web applications now
have a real chance of replacing desktop programs
without degrading the user experience.
Prerequisites
All you need is access to an Oracle XE database
instance and its WebDAV folders. Oracle XE is much
more than just a database server: Embedded PL/SQL
Gateway makes it a regular Web server, while the
built-in WebDAV and FTP listeners let you connect
and store files served over HTTP directly through
one of these protocols. This tutorial assumes that you
have Oracle XE installed on your local computer. So
that URLs refer to localhost, you may have to adjust it
to fit your network’s configuration.
I’ll be using the sample HR schema that ships with
Oracle XE. By default it remains unlocked after instal-
May 2007
by Przemek Piotrowski
and Mark Townsend
lation so you need to unlock it first using the SYSTEM
account through SQL*Plus (this command will also
set a new password for HR):
SQL> alter user hr identified by hr account unlock;
User altered.
On Windows, accessing Oracle XE’s storage area is
trivial with the Web Folder Access feature of Microsoft
Internet Explorer; just select File > Open and type
http://localhost:8080 in the address field and the
Open as Web Folder checkbox. Then you’ll be prompt-
ed for a login and password. Supply hr twice here.
If working under Linux or Windows you may
choose to leverage the FTP server built into the XDB
component of Oracle Database 10g. You activate it by
connecting via SQL*Plus as SYSTEM and issuing the
following commands:
Connected to:
Oracle Database 10g Express Edition Release
10.2.0.1.0 - Production
SQL> exec dbms_xdb.setftpport(‘21’);
PL/SQL procedure successfully completed.
SQL> alter system register;
System altered.
The first command enables the FTP listener in the
database, while the latter registers the just-activated
listener on PMON (process monitor) without actually
waiting for its 60-second refresh cycle. Now you can
connect to the server with any FTP client or directly
from the command line (ftp localhost).
Now we can upload static files into the database storage
area. What about dynamic content? The Embedded PL/
SQL Gateway – introduced for the first time within Oracle
XE – enables you to access stored procedures directly
from a Web location. Using the http://SERVER_ADDRESS:
ajax.sys-con.com
PORT/apex/SCHEMA_NAME.PROCEDURE_NAME syn-
tax one can use PL/SQL stored procedures to trigger data-
base events and generate content. For security reasons
this feature has been disabled by default in Oracle XE
so you have to unlock it first. Since this is a component
of Application Express you have to modify the WWV_
FLOW_EPG_INCLUDE_MOD_LOCAL function inside the
FLOWS_020100 schema. As shown in Listing 1, you have
to make two changes: comment out the return false state-
ment just after begin and add the name of a stored proce-
dure you’d like to grant external access to (in this tutorial
we’ll be running HR.AJAXE stored procedure listed later).
(Listing 1-6 can be downloaded from the online version of
this article at http://webddj.sys-con.com)
This strict policy on running stored procedures
prevents one from executing arbitrary PL/SQL code
on the server side, which would be a major security
risk. Using allowed procedure names makes it con-
venient to limit execution. To finalize this step, grant
execute privileges on the AJAXE procedure to PUBLIC
(in SQL*Plus while logged in as SYSTEM or HR):
SQL> grant execute on hr.ajaxe to public;
Grant succeeded.
Figure 1: AJAX application concept
ajax.sys-con.com
Outputting XML from SQL Queries
You can generate XML directly from SQL queries
using the PL/SQL package DBMS_XMLGEN, which
doesn’t depend on Java and so is available on XE. The
query process takes four basic steps:
1. Get the context by supplying a valid SQL query.
2. Set options on the newly created context using the
DBMS_XMLGEN procedures (optional).
3. Get the XML result by using getXML() to get CLOB
or getXMLType() to obtain XMLType. At this point
you can also limit the number of rows returned by
the XML engine using the setMaxRows() proce-
dure on the context.
4. Reset the query to perform step 3 again or run
closeContext() to free up allocated resources.
Unfortunately DBMS_XMLGEN has one flaw that
you’ll run up against almost immediately when working
with remote XML – HTP.PRN, which will be used to print
the output accepts strings of a VARCHAR2 type that can
be 4,000 bytes long. This isn’t much for XML to deal with.
The AJAX_XMLHTP procedure was created, which takes a
context as a parameter and using the DBMS_LOB PL/SQL
package outputs XML in 4,000-char chunks, leveraging the
possibilities standing behind LOBs. (see Listing 2).
May 2007 21
 This procedure will handle all the processing work
for us by setting the content type to text/xml (required
by the XmlHttpRequest object for DOM process-
ing), setting null handling to output empty tags for
null values, and disabling pretty printing for smaller
response size. Also, when something goes wrong at
the query level, e.g., empty result set or invalid query,
the procedure manually outputs the hard-coded “No
data found” message to indicate its state.
The AJAXE procedure will be a core dispatcher of
responses. It will accept two parameters: q – the type
of action requested, w – the extra parameter required
for certain types of action (optional) (See Listing 3).
The functionality of the sample application will be
divided into three basic use cases:
• Filling the SELECT list with elements obtained
through the AJAX request and hooking the event
handler to it
• Obtaining the results set and rendering it into a
HTML table dynamically
• Using simple auto-complete on the HTML input
field
Note that both these procedures have to be created
in the HR schema to work. At this point you can test
whether the procedure is working for you by access-
ing http://localhost:8080/apex/hr.ajaxe?q=count
(remember to adjust the URL to reflect your system’s
configuration). A valid XML document should be out-
putted at this address. You’re halfway through.

Hands-on Document Object Model (DOM)

AJAX extensively relies on a set of JavaScript pro-
gramming techniques once referred to as DHTML.
But now they’re much more powerful thanks to the
unification of the DOM implementation among
Web browser vendors. Back in the days of Netscape
Navigator 4 and Microsoft Internet Explorer 4 you had
to use a different syntax for each browser to manipu-
late page content dynamically. No need to do that
anymore.
The Document Object Model is a tree-like hierarchi-
cal representation of nodes/HTML elements (see Table
1). The root node of an HTML document is the <html>
tag that usually has two children: <head> and <body>
– the manipulations happen in the second. Since DOM
is a vast subject, we’ll focus only on the most useful
properties and methods of JavaScript XML objects. For
the complete DOM specification, see the W3C Web site at
http://w3.org.
Again, remember that there are a number of other
JavaScript methods for working with the DOM object.
For purposes of this article, an ajaxTable function
was created: it builds up the HTML table from the
XML response obtained through the AJAX request.
By default DBMS_XMLGEN returns a XML tree of the
following structure:
Table 1: JavaScript Document Object Model

22 May 2007 ajax.sys-con.com

 <?xml version=”1.0”?>

<ROWSET>

<ROW>

<COLUMN1></COLUMN1>

<COLUMN2></COLUMN2>

...

</ROW>

...

</ROWSET>

The code in Listing 4 represents the body of the

ajaxTable function.
This function appends the DOM tree in Listing 5
to the DIV element of ID=”q” (the TBODY element
is required here to render properly under Internet
Explorer).

AJAX = Asynchronous JavaScript and XML

Technologically, AJAX is nothing new. It owes its recent
popularity to the unification of the JavaScript standards
that allow access to the XmlHttpRequest object. XML isn’t
new either. It now plays a key role in data and informa-
tion interchange and is universally adopted by both the
enterprise and the open source community. The biggest
problem with the Web was that applications needed a
full-page refresh after each user action on the page. It
didn’t matter whether it was just sorting table elements or
downloading a whole new page.
There are a number of AJAX frameworks on the
market, including the Dojo Toolkit, Prototype, or
Microsoft Atlas to name a few. However, writing basic
handlers alone helps enable a deeper understanding of
what’s happening under AJAX’s hood. First, we need an
XmlHttpRequest object that unfortunately still depends
on the browser – Microsoft Internet Explorer continues
handling it using an ActiveX control so the appropriate
requests object creation code is presented in Listing 6.
This is the only part that requires browser-compatibility
code. Everything else here is cross-browser.
As for the handler, a dedicated function to handle
all the asynchronous operations was created. It takes
a request method, a URL, and callback functions
as parameters. After the response is obtained the
callback is immediately called with the fetched XML
passed as an argument.

function async(method, url, callback) {

request.open(method, url, true);

request.onreadystatechange = function() {

if (request.readyState == 4 && request.status ==

Table 2: XmlHttpRequest object methods and properties
200) {

24 May 2007 ajax.sys-con.com

 callback(request.responseXML);
} for the sample application. After putting it into the
} /public/ folder of XE, open http://localhost:8080/
request.send(null);
} After carefully following all the steps of this tutorial
The callback function will do all the DOM process-
ing based on the XML content from the response.
The callback works directly on the XMLDocument
JavaScript object.
Putting It All Together
Now that we have all the building blocks of
the solution, let’s take a look at the logic behind
it. Figure 1 separates client side and server side
into three separate blocks: Oracle XE, Web page,
and browser client. Notice that the Web page has
been separated here because of its state-depen-
dent nature – thanks to AJAX it now incorporates
the logic to handle user actions and transform
them into HTTP requests; the standard Web model
assumes that it’s the browser that dispatches HTTP
requests to the Web server. That is the key concept
in the solution. Take a look at Figure 1 to see the
whole interaction process.
1. The browser client sends a direct HTTP request
to the Web server (here: the Embedded PL/SQL
Gateway of Oracle XE); the URL of the request has
been supplied in the location bar or through a
link.
2. Oracle XE serves a static HTML page that includes
AJAX scripts. This static page is then rendered by
the browser and now all the requests and interac-
tion happen indirectly, as AJAX requests.
3. When the user triggers an event on the Web page
by interacting with page elements such as forms
and links, an event handler catches it and sends the
appropriate HTTP request through the AJAX engine.
4. The XMLHttpRequest object requests a remote
resource from the Embedded PL/SQL gateway.
At this point, the user doesn’t have to wait for the
script to finish fetching responses from the server;
it’s handled in an asynchronous manner. The script
takes as much time as needed to fetch the response
while the user can further interact with the Web
page.
5. The script performs DOM modifications in the
background while the user can trigger the next
events on the Web page.
You can now upload the attached HTML file
(hr-ajax-demo.html) into your XE instance through
ajax.sys-con.com
FTP or WebDAV, which contains the complete code
public/hr-ajax-demo.html with your Web browser.
the demo page should pre-load the list of depart-
ments and respond to user interaction almost imme-
diately.
Advantages and Potential Problems
Although programming AJAX isn’t necessarily dif-
ficult, the question is whether asynchronous query-
ing techniques are safe and production-ready. AJAX
isn’t always a sure choice over standard development
methodologies. There are at least several viewpoints
to consider.
Advantages
• Better user experience
• Greater responsiveness
• Smaller server load, increased performance
• Network applications can be updated on-the-fly
without redistributing updates
• Separation of content from presentation (easier
maintenance)
Potential Problems
• Cross-browser incompatibilities
• Client-side security concerns
The Real World
Today, AJAX applications are gaining a lot of
steam. With Google leading this trend together and
Yahoo! and Microsoft trailing, the desktop experi-
ence is delivered to users through increasingly
dynamic Web pages. Since the early adoption of
AJAX it has matured to be a full-blown solution
often chosen by enterprises for commercial solu-
tions.
After the unification of DOM implementations
and the adoption of World Wide Web Consortium
(W3C) standards among developers of Web brows-
ers, it’s now possible to create cross-platform Web
applications more easily than ever before. With a
wide range of available AJAX toolkits, developers
can now upgrade Web applications to an asyn-
chronous architecture at a low cost. AJAX is flex-
ible enough to be plugged into existing solutions
and greatly enhances usability. The movement
of desktop applications to the Web is a matter
of time and represents the next step in software
evolution. n
May 2007 25
Listing 1 ctxt := dbms_xmlgen.newcontext(‘select * from employees where
create or replace function department_id=:DEPT’);
wwv_flow_epg_include_mod_local(procedure_name in varchar2) dbms_xmlgen.setbindvalue(ctxt, ‘DEPT’, w);
return boolean ajax_xmlhtp(ctxt);
is end if;
begin end;
-- return false; -- remove this statement when you modify this /
function
-- Listing 4
-- Administrator note: the procedure_name input parameter may be function ajaxTable(xml) {
in the format: document.getElementById(‘q’).innerHTML = ‘’;
-- var rows = xml.documentElement.getElementsByTagName(‘ROW’);
-- procedure var table = document.createElement(‘table’);
-- schema.procedure var tbody = document.createElement(‘tbody’);
-- package.procedure table.setAttribute(‘border’, ‘1’);
-- schema.package.procedure var tr = document.createElement(‘tr’);
-- for (var h=0; h<rows[0].childNodes.length; h++) {
-- If the expected input parameter is a procedure name only, the if (rows[0].childNodes[h].nodeType!=1) {
IN list code shown below continue;
-- can be modified to itemize the expected procedure names. }
Otherwise you must parse the var th = document.createElement(‘th’);
-- procedure_name parameter and replace the simple code below with th.appendChild(document.createTextNode(rows[0].childNodes[h].ta
code that will evaluate gName));
-- all of the cases listed above. tr.appendChild(th);
-- }
if upper(procedure_name) in ( tbody.appendChild(tr);
‘HR.AJAXE’) then for (var i=0; i<rows.length; i++) {
return TRUE; var tr = document.createElement(‘tr’);
else for (var j=0; j<rows[i].childNodes.length; j++) {
return FALSE; if (rows[i].childNodes[j].nodeType!=1) {
end if; continue;
end wwv_flow_epg_include_mod_local; }
var td = document.createElement(‘td’);
Listing 2 if (rows[i].childNodes[j].childNodes.length!=0) {
create or replace procedure ajax_xmlhtp(ctxt in number) as td.appendChild(document.createTextNode(rows[i].childNodes[j].first-
xml clob; Child.nodeValue));
chnk number := 4000; } else {
begin td.appendChild(document.createTextNode(‘-’));
owa_util.mime_header(‘text/xml’); }
dbms_xmlgen.setnullhandling(ctxt, dbms_xmlgen.empty_tag); tr.appendChild(td);
dbms_xmlgen.setprettyprinting(ctxt, false); }
xml := dbms_xmlgen.getxml(ctxt); tbody.appendChild(tr);
for i in 1..ceil(length(xml)/chnk) loop }
htp.prn(dbms_lob.substr(xml, chnk+1, i+(i-1)*chnk)); table.appendChild(tbody);
end loop; document.getElementById(‘q’).appendChild(table);
dbms_xmlgen.closecontext(ctxt); }
exception
when others then
htp.print(‘<?xml version=”1.0”?>’); Listing 5
htp.print(‘<ROWSET><ROW><INFO>No data found.</INFO></ROW></ <table border=”1”>
ROWSET>’); <tbody>
end; <tr>
/ <th>HEADING1</th>
<th>HEADING2</th>
Listing 3 <th>...</th>
create or replace procedure ajaxe(q varchar2, w varchar2 default ‘’) </tr>
as <tr>
ctxt number; <td>ROW1, COLUMN1</td>
i number; <td>ROW1, COLUMN2</td>
begin <td>ROW1, ...</td>
if q=’count’ then </tr>
ajax_xmlhtp(dbms_xmlgen.newcontext(‘select count(*) “EMPLOYEES” ...
from employees’)); </tbody>
elsif q=’search’ then </table>
i := length(w);
ctxt := dbms_xmlgen.newcontext(‘select * from employees where Listing 6
upper(substr(last_name, 0, :LEN))=upper(:PREFIX) order by last_name’); var request = false;
dbms_xmlgen.setbindvalue(ctxt, ‘LEN’, i); try {
dbms_xmlgen.setbindvalue(ctxt, ‘PREFIX’, w); request = new XMLHttpRequest();
ajax_xmlhtp(ctxt); } catch(e) {
elsif q=’fetch’ then try {
ajax_xmlhtp(dbms_xmlgen.newcontext(‘select * from employees’)); request = new ActiveXObject(“Msxml2.XMLHTTP”);
elsif q=’select’ then } catch (e2) {
ajax_xmlhtp(dbms_xmlgen.newcontext(‘select department_id, depart- request = new ActiveXObject(“MSXML.XMLHTTP”);
ment_name from departments order by 2’)); }
elsif q=’dept’ then }

26 May 2007 ajax.sys-con.com

 First Look
Quasar’s Nuqleo System Integrates AJAX into Enterprise Publishing
Work flows improve, bottlenecks disappear when taking a Web-based approach
T
here are a couple of very common issues
in enterprise publishing, and they almost
invariably lead to bottlenecks. For exam-
ple, if the designer is the only person who can
modify a page layout, even minor changes will
depend on his or her availability. If only a small
number of people in a workgroup have the pub-
lishing know-how to prepare a publication for
the printer, delays are likely to occur. Most enter-
prises have learned to live with these constraints
in their document production because there just
doesn’t seem to be a better way.
In the typical publishing workflow, design
modifications can only happen on a worksta-
tion equipped not only with the appropriate
software, but also the necessary fonts for
a document. Even graphic elements for a
page layout are usually stored locally on the
designer’s computer (very often simply on
his desktop), until the files are prepared and
transferred to the printer or service bureau.
While this way of working may be accept-
able in small workgroups, it can become
extremely time-consuming when different
departments or offices are involved in the
document creation.
A Different Approach
Quasar’s Nuqleo system takes a different
approach to solving these problems. By using
modern Web technologies such as those com-
mon to the AJAX approach, the company
managed to create a completely de-local-
ized, browser-based system that allows users
anywhere in the world to access data and
documents, to contribute to the publishing
workflow, and even to modify certain aspects
of a page layout document without needing
the software or the expertise of a designer.
While the design files, images, and texts neces-
sary for the design process are stored in a central
server, Nuqleo manages access and user privileges
in a sophisticated manner. In other words, if a user
logs in with the necessary privileges to perform
basic text editing, Nuqleo will not expose any
other aspects of the workflow. This gives the sys-
tem a lot of security against involuntary changes,
and it also allows a high degree of flexibility in the
management of documents.
28 May 2007
This notion not only applies to texts, it
extends to many aspects of page design as
well. While Nuqleo relies on Adobe InDesign
for page layout and typesetting, users with
the appropriate privileges can access design
files in a browser window and make explicitly
authorized changes.
One of the key advantages of Nuqleo is
that it allows Web-based editing of text and
design. This means that last-minute design
changes can be made even when the page
layout application is not present on the com-
puter that participates in the editing process.
Flexibility and an Easy
Learning Curve
Managing collaboration in this way pro-
vides companies with a considerable amount of
flexibility, and also allows the administrator to
define a system that has minimal training over-
head, since only the functionality that is needed
to complete a task is exposed to the user.
The systems can be seen as a toolkit for
modern publishing processes rather than
a one-stop solution for magazine, book, or
catalog publishers. By opening up very early
on in the development process to the con-
siderable complexities of modern enterprise
publishing, the company managed to create
a system that can speed up the enterprise
content publishing workflow significantly.
Key Aspects
• De-localization: Users from around the
world can log into the system and collabo-
rate on a publication.
• User Administration: Sophisticated sup-
port for internal users and external con-
tributors allow an administrator to allocate
precisely which documents, elements, or
program functions can be accessed by a
specific user. Nuqleo even manages con-
tributors who are not allowed access to the
system by managing external assignments
via e-mail.
• Web Editing: Most editing operations are con-
ducted directly in the browser. Many aspects of
a page can be modified without the need for a
page layout application on the host computer.
• Workflow Automation: Nuqleo allows simple
construction of complex workflow scenarios.
A visual workflow editor lets you combine
any number of steps and conditional settings
to cover every possible situation.
• Phonetic Search: Proprietary search algo-
rithms can find text even when exact spell-
ing is unknown. (This is particularly impor-
tant in multi-lingual projects.)
• Visual Tagging: Allows fast access to visual
information that can’t be captured by key-
words.
• Integrated Image Management: Nuqleo
offers centralized picture management
with automatic image quality control and
IPTC/XMP metadata support.
• Translation Management: Nuqleo sup-
ports translation management and can
manage alternate designs, visuals, etc., for
local markets.
• Project Management: Built-in project man-
agement tools and a retro-planning mod-
ule automatically manage documents from
start to finish.
• Publication Management: There are many
different ways in which publications can be
represented in the Nuqleo system. Through
the flatplan manager, a publication can
be displayed and updated in real time in a
browser window. Different views let admin-
istrators check the status of different sec-
tions. Inserts and cover-mounted objects
are also managed, and a highly realistic
preview allows a user to display a publica-
tion and turn its pages on-screen
Few providers of dedicated publishing
systems have the necessary understanding
of the complexities that enterprises face in
their publishing tasks. There is no “typical”
enterprise, and even less a “typical corporate
publishing workflow.”
Quasar provides a system that offers the
flexibility and ease of use to be able to tack-
le the organizational issues so common in
enterprise content production, collaboration,
and automation – while also providing the
necessary integration with other systems and
environments if it is required. n
ajax.sys-con.com
If you thInk thIs Is a
user-frIendly Interface -
let‘s talk

Imagine ajax with a human touch. Where

¬ coding is replaced by designing
¬ development is far beyond ‘trial and error‘
¬ browser compatibility is built-in

Benefit from ajax without coding by working with

Crossvision application designer. The studio and
runtime environment offers easy Web 2.0 develop-
ment and enables rich web applications that match
traditional desktop GUIs in terms of functionality and
usability.

More than 3,000 customers in 70 countries trust

our solutions to maximize the value of their IT.

Software aG
Take The Lead - LeT‘s TaLk!
Free download at www.softwareag.com/ajax
 Performance
Fast Scalable AJAX Apps
Finding and eliminating bottlenecks and bloat
Dylan Schiemann is founding software
engineer for Renkoo and co-founder of
the Dojo Toolkit. He is best known for
building web applications that make use
of JavaScript, Dojo, and other common
Web development technologies. He is the
co-founder of SitePen, a consulting firm
that specializes in designing custom web
applications focused on outstanding user
experience. Previously, he has developed
web applications for Informatica, Security
FrameWorks, and Vizional Technologies, to
name a few.
dylan@sitepen.com
30
S
uccessful AJAX-based applications provide a
better end-user experience than traditional
Web sites. Fast performance is absolutely
essential to deliver on this potential. The large num-
ber of technologies and the additional complexity
that AJAX adds to the mix creates significant head-
aches in tracking down performance bottlenecks
and related issues.
So where do you start tracking down perfor-
mance-related problems? The answer is logical:
by delving into the raw performance data of your
application. Perhaps a pedantic suggestion, but by
not adequately analyzing and measuring the data,
you’re relying only on hunches and past experience.
Fortunately, we now have a number of highly useful
open source and commercial tools available to assist
us in this tedious process.
The best place to begin a thorough search &
destroy mission is with HTTP-level performance
problems that can be resolved in server configura-
tion and fine-tuning. Is the caching configured prop-
erly? Are there issues with load balancing? How many
concurrent requests per server before performance
suffers? AJAX applications typically reduce the data
size per request, but highly aggressive polling can
saturate your servers with too many requests.
When using the Apache Web server, two useful
open source tools are Apache Bench, which is great
for concurrency testing, and Tsung, which provides
a replay proxy mode to monitor system performance
under a variety of scenarios. Similar commercial and
open source tools exist for other Web servers as well.
Push the limits of your servers and find out what
makes them fall down.
As AJAX applications become increasingly com-
mon, users expect real-time updates to accompany
their real-time experience. To be effective, real-time
or highly collaborative applications require a sig-
nificant amount of AJAX polling to make the appli-
cation work. If this is simply too demanding on your
Web server, you may want to consider switching to
a Comet server implementation such as Cometd,
Lightstreamer, KnowNow, or lighttpd. Comet serv-
May 2007
by Dylan Schiemann
ers are optimized for longer-lived connections and
higher volumes of concurrency than typical Web
servers.
A general rule of thumb with polling: if the
response time for a request is comparable to that
of your polling interval, you’re either polling too
frequently, or your server is taking too long to return
useful information.
The performance of SQL queries is essential to
any AJAX application as is the Input/Output (I/O)
performance of your database. Bonnie++ is a use-
ful tool that helps you quickly track down disk I/O
issues. SQL query performance is the topic of hun-
dreds of articles, but sometimes simple EXPLAIN
statements and a healthy dose of query log analysis
will suffice to slow or eradicate performing queries.
Analyzing performance over the Internet and
verifying that you’re getting the correct data from
the server to the browser is the next step in your
quest. A number of tools exist to assist with this
analysis. Wireshark, formerly known as Ethereal,
is a network protocol analyzer that provides com-
plete insight into all data across the wire for your
computer or network. LiveHTTPHeaders, a Firefox
extension, allows easy viewing of all normal HTTP
traffic, XMLHttpRequests, and Comet traffic, includ-
ing the viewing of full headers in the Firefox browser.
Firebug, a debugging extension for Firefox, among
its many capabilities, lets you view not only script
errors and XMLHttpRequest information, but also
measures the load times of various resources such as
script and image files.
For those of you waiting for me to get to the
JavaScript-specific performance optimization tech-
niques, we’ve arrived. With AJAX applications, many
of our performance issues happen before we even
get to the code that’s executed in the browser. Now
that you have effectively ruled out issues outside the
scope of the Web browser, it’s time to take a closer
look at your JavaScript code. If you’re using an AJAX
toolkit such as Dojo, you may already have profiling
code to supplement Firebug. For example, a Dojo
contributor recently found an instance where the
ajax.sys-con.com
code to create a chart was calling attr.nodeName.
toLowerCase() 540,000 times, consuming 15s of time
at page load! Moving this one line of code inside a
loop drastically fixed the performance of the Dojo
Charting component.
Looking specifically for code that’s called a lot of
times or that takes a lot of time per call are the first
places to investigate. Seemingly harmless calls to
code in your libraries can be expensive operations,
especially when iteration, recursion, and/or large
data sets come into play, and a quick performance
profile will expose these resource hogs.
It’s easy to get caught up in the excitement of
using a solid JavaScript toolkit, and forgetting that
your application doesn’t have to use every feature
provided in your toolkit of choice! And even if the
toolkit or browser lets you do something, it doesn’t
mean it’s an effective use of system resources. For
example, Dojo provides an excellent aspect-oriented
programming (AOP) advice system for method-to-
method event connection. However, you should only
be using this when necessary, not in every instance
that one method needs to call another one, since the
cost for each connect instance is more than a simple
method-to-method call.
Assuming that your toolkit has helped you avoid
memory leak issues prevalent in Internet Explorer 6,
and to a lesser extent Firefox 1.5, there’s still a limit
on the number of objects that can be instantiated in
memory at once in any browser before you experi-
ence a significant drag on performance. Our gen-
eral experience is that Safari 1.2/2 allows the fewest
number of objects, Internet Explorer 6/7 are better,
and Opera and Firefox are significantly better than
that. It would be great to see a quantitative study that
compares the memory consumption and relative
performance limits of object instantiation.
In further evaluating browser performance, you
should be looking for expensive operations that
cause CPU spikes, excessive memory consumption,
or leaks, and seek out alternative or more efficient
approaches. Unfortunately, each major browser’s
JavaScript and DOM implementations are different,
and what works well in one browser doesn’t neces-
sarily perform well in another.
When looking at the initial page load time, sig-
nificant consideration should be given to the num-
ber of requests and the size of each request being
made on the server. One large file is preferable to a
ajax.sys-con.com
large number of small files, provided that you aren’t
preloading a large amount of code that’s rarely used
by your application. The Dojo package system and
build tools solve this problem for Dojo users, and
Dojo ShrinkSafe is useful with any JavaScript code.
For image files, it’s worth considering the con-
struction of image sprites to reduce the number of
requests for small image files.
Predictive auto-fetching of images is another
optimization technique. This technique was made
popular by the Google Maps team. In this applica-
tion, images of locations just outside the boundaries
of the currently viewable map region are loaded in
the background after the application has finished
loading.
In analysis, it’s important to note that synchro-
nous requests to a Web server block execution
and give the user the perception of a hanging
browser. So embracing best practices for asyn-
chronous application development is crucial in
creating sophisticated Web applications. That said,
too many concurrent asynchronous requests can
lead to similar issues, so appropriate queuing of
requests is a good practice.
Browser-specific issues are a significant reason for
the proliferation of AJAX toolkits. Unfortunately, not
every browser inconsistency is solved by your toolkit
alone. For example, Internet Explorer by default
enforces a two-connection limit per server, but it’s
possible to work around this issue with the clever
wildcard-masking of aliases. Additionally, caching
of images loaded by JavaScript in Internet Explorer
requires significant workarounds when your appli-
cation design contains many image files. Browsers
literally have thousands of quirks and idiosyncrasies,
so starting with a good toolkit and regularly reading
developer blogs and Web sites will keep you “in the
know” on the latest workarounds.
Given that AJAX applications are intended to be
faster and more feature-rich than traditional Web
sites, it’s imperative that speed and performance
aren’t lost in the excitement of adding new capa-
bilities to your existing app. I’ve only scratched the
surface of what’s required and what’s possible in
optimizing performance, but with a little patience, a
good set of tools, and an understanding of HTTP and
current browser issues, you’ll have a good process to
begin eliminating performance issues before they
turn into performance nightmares. n
May 2007 31
 Inside Look
Pushing AJAX into High Gear
A simple streaming AJAX example with the
OpenAjax Hub, TIBCO GI, and DWR 2.0
Kevin Hakman is the co-founder of General
Interface and director of developer evange-
lism for TIBCO Software Inc.
Joe Walker is the creator of DWR and presi-
dent of GetAhead Ltd, UK.
32
F
ollow along and implement the real-time
streaming AJAX system in Figure 1 using two
different AJAX toolkits and the OpenAjax Hub.
Requirements
The requirements for this solution are straight-
forward. For this application we need a ready-made
data grid control that will display changes in prices
to stocks when those changes occur. A nice-to-have
would be visual indicators in the GUI that show
when a cell value in the grid is increasing or decreas-
ing…and, of course, we want to deploy this to just
a standard Web browser, so we also must do this
without any reliance on plug-ins, applets, or Active-
X controls. (Thanks goodness this is an AJAX article!)
Figure 1 shows the basic design that could be styled
more at a later date. In addition we’ll want to add
more AJAX controls to this page that can tap the
same streaming stock data for other calculations and
visuals, such as charts or portfolio totals. For now,
we’ll keep it simple.
Architectural Design
We don’t have to build the above system from
scratch, and can instead leverage readily available,
reusable AJAX parts to get the job done quickly; the
architectural strategy is to use AJAX pieces and parts
that can work together. At the core of the system in
Figure 2 is the OpenAjax Hub (see the OpenAjax Hub
for Interop sidebar). We’ll use the OAA Hub as a cen-
tral publish/subscribe bus to which we can publish
the live stock data so that the data grid and the future
visual controls and functions can listen for those
events and messages.
Resources
Publish/Subscribe Core
For our publish/subscribe core we’ll use the
OpenAjax Hub, an open source project implement-
ing the evolving OpenAjax Alliance Interoperability
Working Group specifications. Start at HYPERLINK
“http://www.openajax.org” www.openajax.org and
follow the links to the sourceforge.net project from
there.
Ready-Made GUI Controls
For the GUI controls we’ll leverage those from
May 2007
by Kevin Hakman and Joe Walker
TIBCO General Interface, an open source AJAX proj-
ect that currently provides ready-made AJAX controls
for GUI, data, and communications in addition to
visual tools for rapid AJAX application development,
unit and functional testing, and AJAX debugging.
Real-Time Communications
For our real-time data, we’ll use DWR 2.0, the
just-released next version of Direct Web Remoting
(DWR), an open source project that enables you
to remote Java objects through JavaScript in the
browser and now vice versa through its “Reverse
AJAX” capabilities for real-time remote control of
JavaScript objects in the browser via Java objects
on the server across a persistent HTTP connection
(a.k.a “Comet”).
Project Source Code
You can quickly grab a copy of this project and all
its parts from the 2.x release of DWR at http://geta-
head.org/dwr. Once you’ve installed DWR, check
out the General Interface demo. Those who want to
extend the GUI and add more controls should also
download TIBCO General Interface from http://
developer.tibco.com/gi. Note that the OpenAjax.js
file that ships with the project in the DWR down-
load is an older, 46 kb version of the OpenAjax Hub.
The latest version of the OpenAjax Hub, which now
also implements a savvy topic-based event naming
scheme over the basic pub/sub capability, is cur-
rently under 2 kb (yes two kilobytes – that’s not a
typo).
Implementation
The <dwr>/gi/index.html file loads up the
OpenAjax.js file, the needed DWR libraries, and
some application specific files in the head of the
HTML page.
The body of the page includes a div that loads the
TIBCO GI library.
<div style=”width:100%; height:220px;”>
<script
type=”text/javascript”
src=”JSX/js/JSX30.js”
jsxapppath=”gidemo” jsxlt=”true”> </script>
</div>
ajax.sys-con.com
 // But we are going for a fancy option that ScriptProxy proxy = new

The jsxapppath=”gidemo” loads the GI does highlighting ScriptProxy(sessions);

project in /gidemo and in turn renders the for (var property in corporation) {

GUI component declaration: gidemo/compo- if (property != “jsxid”) { Corporation corp = corporations.get-

nents/appCanvas.xml. Once these are loaded, var ox = matrix.getContentElement(corp NextChangedCorporation();

GI’s project init function is called: oration.jsxid, property); proxy.addFunctionCall(“OpenAjax.publish”,

if (ox) { “gidemo”, “corporation”, corp);

function giLoaded() { var current = ox.innerHTML;

OpenAjax.subscribe(“gidemo”, “corporation”,

objectPublished);

dwr.engine.setActiveReverseAjax(true);

This subscribes to the OpenAjax Hub lis-

tening for publications to the ‘gidemo’ + ‘cor-
poration’ topic. When a publish happens, the
objectPublished function is called. The last
line turns DWR’s Reverse AJAX on so that the
data can flow from the server to the client
without polling or waiting for the GI applica-
tion running at the client to request an update
from the server. The objectPublished function
looks like this:

function objectPublished(prefix, name, han-

dlerData, corporation) {

var matrix = giApp.getJSXByName(“matrix”);

var inserted = matrix.getRecordNode(corpor

ation.jsxid);

matrix.insertRecord(corporation, null,

inserted == null); Figure 1: Web-based real-time stock quotes implemented using TIBCO General Interface,
matrix.repaintData();
the OpenAjax Hub, and the recently released DWR 2.0.
}

if (current != “” + corporation[property]) {

This simply takes the published data and ox.style.backgroundColor =

inserts it into the GI matrix component. Each “#FDE4EB”;

column of the matrix component is bound var callback = function(ele) {

to a property of the corporation JavaScript return function() { ele.style.

object. The matrix control, its columns and backgroundColor = “#FFFFFF”; };

bindings were configured using TIBCO GI’s }(ox);

visual tools: TIBCO General Interface Builder. setTimeout(callback, 1000);

There are a number of possible repaint ox.innerHTML =

strategies, including the simplest of them corporation[property];

all: matrix.repaintData(); as shown above. }

However, to meet our requirements above, }

in the source below we’ve implemented a }

more sophisticated approach that enables }

both incremental painting of updated rows ...

and cell highlighting.

Instead of matrix.repaintData(); we’ve Meanwhile, on the server the following
used this: Java code is running in a thread:

... while (!Thread.currentThread().isInterrupt-

// There are many ways to get a table to ed())

repaint. {

// One easy way is to ask it to repaint: Collection sessions = serverContext.

// matrix.repaintData(); getScriptSessionsByPage(“/dwr/gi/index.
Figure 2: System Architecture
html”);

ajax.sys-con.com May 2007 33

int timeToSleep = random.nextInt(2500); push JavaScript to these users. The ScriptProxy
Thread.sleep(timeToSleep); This simply finds the people viewing this is a feature of DWR 2.0 enabling DWR 2.0 to
} page and creates a ScriptProxy to allow us to dynamically generate JavaScript from a Java
API. This is done at runtime rather than com-
pile time, so we can use it to remote control
OpenAjax Hub for Interop many browsers. This makes it very easy to write
Two months ago in New York, immediately following AJAXWorld East 2007, the OpenAjax things like chat applications, or anything par-
Alliance met and held its first InteropFest where a handful of the more than 75 industry ticularly dynamic. Messages are sent to clients
members of the nascent AJAX standards organization demonstrated their technologies across using DWR’s “Reverse AJAX” capability.
working in context of the first specification project of the alliance – the OpenAjax Hub We then ask the corporation’s object for
(OAA Hub). If you haven’t been watching the evolution of this specification targeted at a Stock price change, and publish this to the
enabling AJAX libraries and controls to be interoperable, it’s rather interesting that at the Open Ajax Hub.
core of the OAA Hub is a publish and subscribe event and message bus leveraging the That’s it. Pretty simple.
tried and true interoperation approaches typical of server-side integration strategies, but For the full source to all the files, including
instanced on the client side. the TIBCO GI project files, see the source in
Why is a “pub/sub” system at the core of the standard interoperation strategy for AJAX? the .war file download for DWR 2.0.
With increasingly sophisticated AJAX software, mashups, and composite applications
being built today, the pub/sub strategy makes developing such things simpler. Consider Other AJAX Controls
that when you have a system consisting of more than one part, and especially in such Changes to Java Objects are sent to DWR
systems that may grow and change over time like mashups, portals with AJAX portlets, 2.0’s Reverse AJAX connection, and converted
or composite applications, instead of writing procedural code for each part of the system to JavaScript by DWR. In this case, the convert-
that needs to work with another (which as you CS majors know, leads to the classic “n- ed objects are wrapped in the OpenAjax Hub’s
squared” integration complexity problem), it’s far more efficient to implement a system publish method so that when the pushed
for receiving, then dispatching events and messages so that one part can publish an event code arrives at the client, the OpenAjax Hub
through the intermediary pub/sub hub, and then other parts that need information from publishes the data to a message topic name.
that system can implement specific listeners that subscribe to, receive, and handle the The JavaScript Objects, such as the TIBCO GI
events and messages. matrix GUI component, are coded to listen for
new information on that topic and, in turn,
handle the new information when it arrives.

Conclusion
The solution above demonstrates how
easy it can be to implement powerful systems
based on sound publish and subscribe archi-
tectural principles. Further, the decoupled
nature of the publish and subscribe style
implementation enables one piece of a sys-
tem to be added or replaced without effect-
Figure 3: Comparison of a system of separate parts, integrated point to point versus a ing other parts. Accordingly, this approach is
system integrated based on publish/subscribe events and messages. highly applicable to mashup and AJAX portal
scenarios. As shown, beyond the basics of
using the emerging publish and subscribe
As opposed to the more primitive DOM events such as onclick, onkeydown, standards of the OAA Hub to connect reusable
onmouseover, and the like, typically these types of events and messages are associated client-side components, technologies, such
with “application-level” concepts such as like “userLoggedIn”, “newCustomerCreated”, or as DWR 2.0’s Reverse AJAX and TIBCO’s just
“addNewStockSymbol”. released Ajax Message Service for highly scal-
Figure 3 compares a system with five parts directly linked to each other in a point-to- able real-time data over HTTP, are enabling
point fashion with a system implemented in a publish/subscribe message bus architec- publish and subscribe events to occur across
ture. the network. Accordingly, one can begin to
Architecting your AJAX applications using publish and subscribe techniques enables think not of an HTML page in a browser
each part of the system to be decoupled from the others, and thus to be built and managed connected to a server across a network, but
as distinct units. This modularization not only facilitates greater reuse and more efficient instead the AJAX application running in the
team development, but also helps you to avoid creating the hairballs of code typical of browser being in the same event cloud as the
point-to-point architectural approaches to application systems. The more elements in a server, publishing to and subscribing from
system, the most complex and expensive adding to and maintaining the system becomes streams of information mediated by event bus
in point-to-point architectures when compared to publish/subscribe bus architectures. architectures on the client and on the server,
and, accordingly, enable you to build more
powerful AJAX solutions. n

34 May 2007 ajax.sys-con.com