AjaxWorld 2007 01

THE AJAX MOMENT MUSHROOMS INTO THE WEB 2.
0 MOVEMENT
Enterprise Matters
O
N

T
H
E

E
N
T
E
R
P
R
I
S
E

PAGE 6
March 19-21, 2007
New York City
.~||~|Y 2007 vC||VL 2 |SS|L ! www.~.~`.SYSCC|.CCV
1-64
#VJMEJOHUIF#VTJOFTT
$BTFGPS"+"9
When 0oes AIAX
Make Bus|ness Sense?

Effect|ve AIAX for Everyone
lnc|ud|ng the Enterr|se
W||| Browsers Ever 0e||ver
As lnstead of 0ocument?

Enterr|se Comet:
Awaken the Gr|zz|y!
1he Oen |atform for R|ch
80 Web A||cat|ons
0ata r|vacy and Secur|ty
for AIAX-based Web A||cat|ons
January 2007
n8 AJAXontheEnterprise
Enterprisematters
by Kurt Cagle
n20 Whatsin
ItforMe?
BuildingthebusinesscaseforAJAX
by John Eckman
n24 WhenDoesAJAX
MakeBusinessSense?
Costingitout
by Jon Ferraiolo
n28 EffectiveAJAXforEveryone
IncludingtheEnterprise
Dealingwiththemostdisruptive
technologyevertohitsoftware
by Joshua Gertzen
n32 BeyondHTTP
Willbrowserseverdeliver
applicationsinsteadofdocuments
by Ric Hardacre
n36 EnterpriseComet:
AwakentheGrizzly!
Therealdeal
by Jonas Jacobi & John Fallows
n42 AJAX3D
Theopenplatformforrich
3DWebapplications
by Tony Parisi
n46 Lockdown
Dataprivacyandsecurity
forAJAX-basedWebapplications
Indroniel Deb Roy
4FromtheEditor
Dion Hinchcliffe
6FromthePublisher
JEREMY GEELAN
AJAx.sYs-CoN.CoM January 2007 3
T
he outlook for AJAX in 2007 remains
as bright as its ever been with pundits
and analysts alike reporting that it
will be the dominant Web application model
this year, in lieu of competing (albeit com-
plimentary as well) technologies like Adobe
Flash and Windows Presentation Foundation/
Everywhere. But the AJAX marketplace is just
now getting a good start with tools from
major software vendors just barely reaching
the market. There have been no industry
shakeouts or acquisitions and, just as inter-
esting, there are no companies or products
with clear market dominance, with the pos-
sible exception of the Dojo Toolkit.
This is significant for two reasons: the
story of AJAX has clearly just begun and the
industry snapshot in the previous paragraph
is one of an industry very much in its early
growth stages. Questions abound regarding
the directions the AJAX model will take this
year including:
Will OpenAjax gain the upper hand and
set the standard for how AJAX components
and tooling will work?
Leading online players like Yahoo! are
reporting that their analytics and conse-
quent advertising stats are taking a beating
because their new AJAX applications kill
the page view model. What will this mean
for large-scale mainstream AJAX adoption?
Is AJAX still too difficult for the typical Web
developer to use, making 2007 a skill-build-
ing year instead of an app-building year?
Will the entry in 2007 of major software
vendors like Microsoft into the AJAX prod-
uct space push the things in a whole new
direction?
These and lots of others are on the minds
of Web application developers and architects
everywhere. AJAX takes user interface con-
ventions, search indexing, bookmarking, and
more away from us but gives us the ability
to create compelling, immersive, interactive
applications the likes of which the Web has
never before seen. Its clear that despite the
challenges in development, testing, manage-
ment, and monetization, users will prefer a
well-designed AJAX application every time.
Its like Jesse James Garrett, the inventor of the
term in February 2007, said at AJAXWorld last
year: AJAX is the Web on roller skates. Users
are just not about to go back to applications
with time-consuming, attention-disrupting
page loads and reloads.
Thus, as tooling and practices continue to
improve, including analytics and debugging,
many of the headaches we experience now
will go away as we create the AJAX experi-
ences that our users are coming to expect
more and more.
The real message here, however, is the
moment of opportunity and challenge that
those of us in the Web developer community
face. There is still enormous room to improve
the AJAX application design and development
process. This is also the state of affairs on the
Web experience. Those with strong presence
in the previous generation of HTML and Flash
application development are finding them-
selves facing, like many in the Web 2.0 era, a
disruptive opportunity: providing innovative
new development tools and AJAX -powered
Web sites is now a prerequisite. Reinvention
of skills, core competencies, and focus are the
order of the land across the Web.
Who will reap the rewards and deliver
the winning solutions in the AJAX era? That
remains to be written and I encourage you
to use the information and knowledge in
AJAXWorld Magazine to help you and your
organization rise up to the challenge of the
next generation of online Web applications.
This years AJAX message is clearly one of
disruption and opportunity and it will be
interesting to watch what happens in 2007.n
Dion Hinchcliffe, president and CTO of Hinchcliffe &
Company, is editor-in-chief of AJAXWorld Magazine.
From The Editor
Group Publisher Jeremy Geelan
Art Director Louis F. Cuffari

Editorial
Editor-in-chief
Dion Hinchcliffe
dion@sys-con.com
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.
TheEndofthe
BeginningforAJAX?
Dion Hinchcliffe
4 January 2007
AJAx.sYs-CoN.CoM
E
arly in 2006, before the general Internet-using
public was aware of what I began referring to
in editorials, blog entries, and SYS-CONs
Internet TV Webcasts as The AJAX Moment,
there was a strong sense among industry insiders
that AJAX-like approaches, if not actually AJAX itself,
were a shoo-in as the new paradigm for the develop-
ment of Web 2.0 and the fulfillment of the software
development communitys long-held dream of com-
plete freedom from operating system or runtime
environmentdependent technologies.
By running on Internet technology i-Technology
instead, businesses could not only enjoy such free-
dom but also quickly enable all the rich-media func-
tionality we have come to associate with AJAX ever
since Google popularized a smarter, more respon-
sive and interactive Web experience by launching its
Google Maps and Gmail applications.
Was the early optimism borne out by subsequent
events? Ill say! In fact, if anything, the early pronounce-
ments about the fundamental raising of the user-
experience bar that the rise of AJAX catalyzed were in
hindsight unnecessarily guarded. The architecture of
participation, which MySpace and Flickr exemplified,
has been complemented swiftly and, if one believes
Enterprise Web 2.0 thought-leader Coach Wei, with
enormous business upside, by an architecture of par-
tition thats to say, Web 2.0 is actually based on a new
technology foundation from Web 1.0, one comprising
an application client container, an Internet messaging
bus, and an enterprise mashup server.
Beyond being a consumer phenomenon, Wei
contends, Web 2.0 has a significant impact on busi-
ness computing by enabling better, faster, richer
applications while reducing costs, with tangible and
measurable ROI.
The reason he has coined the phrase architecture
of partition, Wei notes, is that this new technology
stack gives developers, for the first time in Internet
history, the capability of deciding the appropri-
ate architecture partition according to application
requirements.
RIA-compatible approaches like AJAX are simply
a better way to build, deploy, and maintain enter-
prise IT solutions, resulting in better user productiv-
ity, lower operation costs, and reduced development
and maintenance costs. As Wei explains:
The Web 2.0 technology stack eliminates the
need to install client software, enabling compa-
nies to leverage the Internet more cost-effectively.
Equally important, an organization can deploy the
same version of a Web 2.0 application to all its users,
across heterogeneous client configurations and net-
work connection types. This eliminates the need to
develop and maintain multiple client software ver-
sions, the need to standardize client systems and the
need to upgrade network infrastructure.
Weis Enterprise Web 2.0 is just one of countless
themes and memes that will be front and center at
AJAXWorld Conference & Expo 2007 (East) in New
York, March 1921, 2007. Others include the ever-
increasing micro-chunking of the Web; the emerg-
ing social aggregator information architecture that
blogs, startpages, and social networks are all swiftly
converging toward; the Real-Time Web; and the
principles involved in building a successful, sustain-
able, and vibrant online community.
Other March topics are OpenLaszlo including
the Legals project, Componentized Websites,
JavaScript Workarounds, Cost-Effective Scalability,
Next-Generation Web 2.0 Tools, AJAX Vulnerabilities,
Desktop AJAX, Google Gadgets, Microsofts ASP.NET
AJAX, Adobes Apollo, SaaS Business Models, and The
Business Value of RIAs.
As it did with the inaugural AJAXWorld last year,
held in Silicon Valley, the OpenAjax Alliance is tim-
ing a major meeting to coincide with this years East
Coast Conference & Expo, at the historic Roosevelt
Hotel in midtown Manhattan. And indeed a goodly
percentage of OpenAjax Alliance member compa-
nies are exhibiting at, speaking at, or sponsoring the
show.
There isnt much more anyone needs to say right
now about AJAX, RIAs, and Web 2.0 except this: Why
not come to AJAXWorld in March and see/hear/try
out AJAX for yourself?
The 100+ sessions cover every aspect of AJAX-
enabled applications and those creating and deploy-
ing them. And the Web 2.0 track alone is to die
for, with a lineup that includes Steve Rubel, Stowe
Boyd, Hooman Radfar, Yuval Tarsi, Dean Allemang,
Dion Hinchcliffe, Dustin Whittle, Coach Wei, Troy
Angrignon, Andre Charland, and Alex Barnett.
See you in New York!
From The PUBLIsHER
TheAJAXMomentMushrooms
intotheWeb2.0Movement
by JEREMY GEELAN
SYS-CON Media
President & CEO
Fuat Kircaali, 201 802-3001
fuat@sys-con.com
Group Publisher
Jeremy Geelan, 201 802-3040
jeremy@sys-con.com

Advertising
Senior Vice President,
Sales & Marketing
Carmen Gonzalez, 201 802-3021
carmen@sys-con.com
Vice President, Sales & Marketing
Miles Silverman , 201 802-3029
miles@sys-con.com
Advertising Sales Director
Megan Mussa, 201 802-3028
andrew@sys-con.com
Advertising Sales Manager
Andrew Peralta, 201 802-3023
megan@sys-con.com
Events Manager
Lauren Orsi, 201 802-3024
lauren@sys-con.com

Production
Lead Designer
Louis F. Cuffari, 201 802-3035
louis@sys-con.com
Art Director
Alex Botero, 201 802-3031
alex@sys-con.com
Associate Art Directors
Tami Beatty, 201 802-3038
tami@sys-con.com
Abraham Addo, 201 802-3037
abraham@sys-con.com

SYS-CON.COM
Consultant, Information Systems
Robert Diamond, 201 802-3051
robert@sys-con.com
Web Designers
Stephen Kilmurray, 201 802-3053
stephen@sys-con.com
Richard Walter, 201 802-3057
richard@sys-con.com

Accounting
Financial Analyst
Joan LaRose, 201 802-3081
joan@sys-con.com
Accounts Payable
Betty White, 201 802-3002
betty@sys-con.com

Customer Relations
Circulation Service Coordinators
Edna Earle Russell, 201 802-3081
edna@sys-con.com
6 January 2007
AJAx.sYs-CoN.CoM
TheAJAXMomentMushrooms
intotheWeb2.0Movement
I
n Star Trek, Scotty James
Montgomery Scott was my
favorite character, perhaps inevita-
bly. Spock was always the cool and collected
uber-genius, inscrutable and forced into an emotional
straightjacket, and while the parallels to the real politik
of the time are obvious, to me Spock has always been
the epitome of the pure ivory tower researcher. Scotty,
on the other hand, was the enginee , in many ways the
ultimate hacker. Spock may have been able to tell you
what properties of dilithium would induce warp speed,
but Scotty knew exactly how to crack the damn crystals
in such a way as to eke out that last 0.5 warp factor nec-
essary to escape the baddies chasing the Enterprise.
Scotty knew about estimates and how much
you could pad an estimate to insure that you got the
correct time necessary to complete your work down
to the minute. He was not above a brawl or two, but
when it came right down to it, a vacation was the
time it woul take to get to that stack of Linux maga-
zines from 2215 that youve been putting aside for
the last five years and just read.
The Enterprise needed Scotty far more than it
needed Kirk or Spock or even McCoy, yet he was
always little more than an odd bit player, the one who
was never on the bridgeunless he was repairing one
of the computer panels that everyone else kept falling
into every time the gravitational system failed, which
usually didnt happen because of anything that Scotty
did, but because Kirk seemed to have absolutely no
sense of restraint or the cost involved in replacing
one of those warp nacelles. And AJAXlet me tell you
about AJAX on the Enterprise
Ioh, Im sorrythis piece should have been
about AJAX in the enterprise. OopsUm, okay, the
slides are already prepared, and Im going to be
in serious trouble if I have to take this thing from
scratch in front of such an august group of people
as yourselvesso how about letting me tell you a
little bit about AJAX on the Enterprise, and well
see if maybe, just maybe, there are a few nuggets of
wisdom (or at least crystals of dilithium) that we can
extract from all this when dealing with the issues of
AJAX in the enterprise.
AJAX:TheFive-YearMission
In the introduction to the early Star Trek episodes,
the hope of NBC (or at least Gene Roddenberry)
was fairly clear the Enterprise was on a five-year
mission. Unfortunately for them, they managed to
get through only three before the axe fell (and not
surprisingly, when Patrick Stewarts stentorian tones
introduced The Next Generation two decades later, it
had become the Ongoing Mission).
However, I believe that that there was some-
thing about that five-year bit thats actually pretty
important in the here and now. In the 1960s, Central
Planning was as much a part of the American econo-
my as it was the old pre-peristroika Soviet economy,
and the five-year plan described what was often
taken as a convenient metric for how far one could
plan before things became too unpredictable.
Five years also seems to be about the lifespan that
it takes for major technologies to go from being a
good idea to becoming foundational. (Note that this
differs fairly significantly from product marketing
lifecycles, which seem to have about a three-year
cycle from inception to obsolescence). I believe that
were at one of those interesting transitional points
where things are really changing in radical ways, the
end of one five-year mission and the beginning of
another, waiting only for Picard to make it so.
Five years ago, several very interesting things were
happening, both in software and in business in general.
The tech sector was collapsing, warp shields blowing
left, right, and center. Now, to someone whos weathered
a few of these five-year plans, the tech sector collapsing
was really nothing new its an industry thats built on
promises of miracles and every so often the bill comes
due. People invest in tech hoping for outsized gains are
generally deluding themselves tech always underper-
forms in the short-term, and overperforms in the long,
but in ways that few people can really imagine.
Enterprisematters
xML Bindings
AJAXontheEnterprise
by Kurt Cagle
Kurt Cagle is a developer and author,
with nearly 20 books to his name and
several dozen articles. He writes about Web
technologies, open source, Java, and .NET
programming issues. He has also worked
with Microsoft and others to develop white
papers on these technologies. He is the
owner of Cagle Communications and a co-
author of Real-World AJAX: Secrets of the
Masters (SYS-CON books, 2006).
8 January 2007
AJAx.sYs-CoN.CoM
However, in spite of, or more likely because of,
this effort, people who had been hoarding their
cool ideas to capitalize from the next Bay Area VC
suddenly found themselves unemployed and sitting
in their parents spare bedroom with time on their
hands while they waited for some response ANY
response from an employer. So they did what
computer people always do when the next boom
becomes the next bust they began to network.
Standards groups that companies had been rush-
ing to get something out the door began to slow
down and actually start to take some time thinking
about those standards. Several good ones came
out between 2000 and 2002 XSLT, XPath, XML
Schema (well, maybe not schema), XForms, XHTML,
DocBook (just for a break from the 25th letter of the
alphabet), SVG, ebXML, RDF, and a whole host of
specialized industry-specific languages from XBRL
to MathML to HumanML (yup, its up there in OASIS
I was a member of that working group for a while).
Meanwhile, Linus Torvalds pet project went from
an interesting hobbyist effort to looking like a stan-
dard itself, accreting stillborn commercial products
that were given new life in the long tail, reinforcing
the notion believed by most programmers (and
espoused quietly by Scotty himself more than once)
that if you get two developers communicating with
one another, you get something more than twice as
good as what each can develop separately, that three
tend to add value proportionately, and so forth.
In other words, those five years of downtime,
was a time of real research and development, not
done in hopes of getting that next crucial patent (or
the million-dollar payoff ) but rather done because
the work represented real needs that needed to be
rectified and it was to everyones benefit to do so.
Standards matured, projects started and worked and
bloomed and died, and out of the remnants came
new projects and the further tinkering with stan-
dards.
One of those revenant projects was the ghost of
Netscape. Im going to speak whats heresy here in
San Jose, but Netscape failed because it wasnt good
enough. You give away a perfectly good software
product for free against a competitor who has bil-
lions in the bank, and while youll find people cheer-
ing you on, they, and you, are idiots. You will fail.
Netscape failed.
It failed largely because the only way it could com-
pete was to change the rules of the game, for the proj-
ect to divorce itself from the requirements of being a
business. It became a ghost in the machine, one large-
ly sustained by the efforts of Brendan Eich, who is
one of the most brilliant and insightful people I have
ever met. Brendan and others in the nascent Mozilla.
org movement decided to create a browser using an
HTML-like language called XUL that described the
critical components necessary for an application to
work, set up a fairly large set of core services written
in C++ then proceeded to use JavaScript, another Eich
invention, to tie the pieces together.
Ahead,WarpFactor9
PoweringtheWebwithJavaScript
Let me tell you a little bit about JavaScript. Its
a simple language. Now, I know how to program in
Java, and C++ and C# and Smalltalk and a few oth-
ers that Ive picked up over the years, but Ive always
liked the simple languages best. JavaScript has only a
rudimentary definition of type, though itll get more
in upcoming releases. PHP is simple, and its rapidly
becoming the primary Lingua Latina of the server
world, replacing Perl, which was also simple, but a
little too indeterministic. John Thompson created
Lingo for Macromedia Director several years ago,
and much of the spirit of that language (along with
JavaScript) still lies at the heart of ActionScript.
JavaScript is the most ubiquitous procedural lan-
guage in the world. There are more lines of JavaScript
code in existence right now, I suspect, than there are
lines of code in Microsoft Vista. Its a language that
can be picked up by a bright eight-year-old, and yet
now, as a programmer you can command a six-figure
salary if you know how to write it well. Its important
in great part because of its role as the glue that holds
Web pages together, that powers Web applications,
and makes it possible for you to boldly go where no
one has gone before.
Theres a lesson in that, a lesson that emerged
with HTML (and that occasionally needs to be
relearned on the XML side and even on the AJAX
side). Simple is good. Indeed, perhaps more than
that, simple is so friggin essential that your develop-
ment efforts will most likely fail spectacularly if you
dont embrace that fundamental notion.
JavaScript provides a development environment
thats on nearly every browser and increasingly in
many other embedded applications (you can pro-
gram OpenOffice in JavaScript, for instance). In
other words, its out there for anyone to use, and
increasingly managing that JavaScript should be a
part of your larger developmental efforts, because in
the long run lowly JavaScript will trump Java, C++,
C#, and just about everything else because of that
ubiquity.
JavaScript has also been evolving pretty dramati-
cally in the last couple of years, though this evolu-
tion may not be as evident if youve been working
in the Internet Explorer realm. Getters and setters
have become pretty much standard fare, array and
object manipulation has become considerably more
sophisticated and powerful, prototype functional
programming is taking advantage of advanced fea-
tures of languages such as Haskell and Miranda.
However, perhaps as significant has been a
wholesale rewriting of the programming methodolo-
gies surrounding JavaScript to the extent that most
dedicated JavaScript developers today write code
that bears surprisingly little resemblance to that of
even five years ago. For starters, object-oriented pro-
gramming has become far more pervasive, even if
the object-ness tends to bear only a passing resem-
blance to the class/property/method structures of
Java or other similar languages. Code frameworks,
such as the Ruby prototype.js object, scriptaculous,
the Google and Yahoo AJAX frameworks, Atlas, and
so forth, are emerging to handle the more common
use cases, such as drag-and-drop operations, as
well as spurring new interest in animated dynamic
effects. XML manipulation (as will be discussed) is
becoming easier, and a second graphical framework,
the Canvas object, is opening up additional two-
dimensional graphical capabilities.
Theres even an emerging live object transport
protocol, called JSON, thats becoming useful in low-
level messaging systems. JSON uses the J ava S cript O
bject model N otation (hence the acronym) to repre-
sent JavaScript objects and to transport them across
pipes (using the XMLHttpRequest object, discussed
shortly). While JSON is a lightweight alternative to
XML for certain tasks, and while its not going to
replace XML any time soon, JSON does work espe-
cially well in setting up object bindings, though it also
represents a potential security hole that needs to be
watched very carefully, as will also be discussed.
BeamMeUp,Scotty
MessagingandtheXMLHttpRequest
Object
While JavaScript is the engine that drives much
of the AJAX movement, JavaScript by itself isnt
enough. Two factors have changed JavaScript from
something that was almost an afterthought in most
business circles to one that has been gaining a lot
of traction XML and the Asynchronous HTTP
Messaging object, bearing the ungainly name of
XMLHttpRequest object but best thought of as the
Message Pump. The Message Pump can be thought
of as a radio transmitter/receiver it can retrieve
content from an external source a file, a Web server,
or in some cases a database and it can also send
messages to external sources. It was originally a part
of Microsofts Internet Explorer and for many years
it was one of the better kept secrets in that environ-
ment, but the Mozilla folks were smart enough to
recognize a good idea when they saw it (and in all
honesty, the prototypes for the object were there in
Netscape as well, but by then too many other fires
were blazing for it to make much difference).
That message pump means that you can send
information from the client to the server and back
from within a Web page. Of course, you can do that
anyway, but the important distinction is that with
the Message Pump youre not necessarily forced into
refreshing the entire page every time you need to
change some aspect of it. In programming circles,
this means that state management no longer has to
be done exclusively within the server, but can in fact
be significantly offloaded to the client.
Now, to take this back to the Star Trek metaphor
again (hah, you thought Id forgotten, hadnt you!)
imagine the Enterprise without transporters (or look
at the final seriesor maybe not). You want to get
valuable medical equipment to the colonists at Rigel
7, you have to launch a shuttlecraft filled to the brim
with equipment and fuel, have it descend into a hot
steamy jungle with only the vaguest hope of finding
a convenient airstrip to land on, have to provide
armed guards for the shuttle while you unload
the likely heavy equipment then take off from an
unfamiliar planet in hopes of a rendezvous with the
mother ship two or three days later. This was Web
programming circa 1998.
With the Message Pump and some intelligent
JavaScript code you suddenly turn on those trans-
porters (though you also keep the shuttles just in
case Scotty isnt around to press the right levers). You
send down an initial support staff via transporters
who check the security, make the necessary arrange-
ments, and find out what things are specifically
needed. They can then call down equipment that
can be positioned to within a few dozen yards of
where it needs to end up, bring in additional perso-
nel to instruct and train the locals in the use of the
equipment, and while there can beam up the few
serious medical cases that need to be transported to
a more complete medical center. Finally, everyone
beams back up to the Enterprise and spend some
well-deserved time on the Holodeck.
To get back to contemporary terminology, what
this means in practice is that rather than creating a
single page from fairly complex components on the
server and needing to maintain this information on
the server, you instead push the components onto the
client, and each component in turn becomes respon-
sible for its own interactivity with the server. The state
of the application in turn either ends up residing in
each component, or in a client-side model server
which all of the other components interact with.
The distinction between these two forms is
important (and Ill get to them momentarily) but one
of the immediate upshots of this is that the server
can in fact become dumb it doesnt need, in either
situation, to retain anywhere near as much state as it
did before for that particular session or application.
This has a number of immediate consequences:
The server needs to send each component only
once then let the component handle the presenta-
10 January 2007
AJAx.sYs-CoN.CoM
tion layer directly rather than doing this task itself
for each component every time some aspect of state
changes. This makes the server-side code easier to
write and more modular to maintain.
The server can standardize on a single given
transport protocol that the various components can
use, meaning that you have less need for extensive
server-side development of translators between
databases and a whole host of different presentation
formats.
The server layer becomes thinner more a gener-
ic conduit between the database and the client
than a large set of custom presentation and content
pages, and in general this translates into an ability to
generate more sessions for the same resources.
From the client standpoint, however, things tend
to get potentially more complex. (The third law of
programming thermodynamics complexity never
disappears, it only moves around). Browsers are per-
haps more homogenous with regards to interfaces
than they were five years ago (especially now that
Internet Explorer 7 is on the horizon), which in turn
means that the amount of specialization code neces-
sary to write to the diversity of browsers has shrunk.
It hasnt disappeared entirely yet, though the good
news is that the benefits of maintaining a uniform
set of interfaces appears to have sink in to just about
all of the major players.
Moreover, Google, Yahoo, and others have been
working on creating standard frameworks to handle
the small things (such as Sarissa, which provides
hooks into the XSLT transformer objects on most
browsers and supports a limited JavaScript-enabled
transformer for those few platforms that dont have
XSLT support fully enabled), making for a homog-
enous generalized environment without going over-
board in trying to build extensive (and potentially
restrictive) frameworks. These efforts are essential,
since they provide the last homogenization/stan-
dardization in the browser space to use browsers as
independent platforms for applications.
SendDownaCoupleMoreRedShirts
AJAXandWeb2.0
This point in turn raises another and in many
ways more crucial one. The AJAX movement is not
about calling home without refreshing the page, is
not about cool widgets appearing in Web pages, dis-
playing the latest feeds from Slashdot or neat drag-
and-drop effects, though certainly all of these have
a place. Instead, the primary driving motivations
of AJAX is the fundamental belief that the browser
is ultimately the last platform, that the Web will not
truly be universal until browsers can do everything
that a standalone desktop environment can do,
regardless of whether theres a multi-colored flag, a
fruit, or an aquatic fowl on the start-up screen .
This shouldnt be a radical point, but somehow
it is. Your customers, the employees at your com-
pany, and you individually spend a huge amount
of time in front of Web browsers, which are in turn
becoming the primary interfaces for all modalities of
communication. I havent used a standalone e-mail
application in months, most of my IM communi-
cation occurs in a browser context, and increas-
ingly my production tools exist as extensions to my
Web browser. For many people, going from a Web
interface to a standalone application seems a step
backwards, forcing them from their primary point of
contact for news, documentation, and communica-
tion into an isolated environment where they have
to run the browser in the background and click back
and forth to shift between the two.
AJAX has gained momentum not because someone
put a Message Pump on a browser with 15% of the
market, but because this move has basically catalyzed
a reaction among the other browser vendors and proj-
ects and caused the Web developer sphere to shout
Enough is enough! If certain parties wont get their act
together then we will solve this problem ourselves!
Movements are funny things, especially in tech-
nology. No one takes them seriously at first theres
no press releases, no aging rock star starts singing
the praises of the product, usually just a handful of
people who recognize that there is a problem and
that the market isnt rushing to solve it because
theres no immediate money in it.
Often theres a single event that sparks the whole
thing a programmer gets frustrated because no
one can find information about physics papers
written at the research center where he works and
puts up a small set of tools for free, a grad student
who sends out a note saying that because he cant
afford to use the universitys Unix implementation
hes writing his own free one, and would anyone else
like to helpevents that occur almost daily now that
are only important in hindsight. People pitch in not
for glory or money (because theres seldom much of
either) but because most software developers are a
lot like Scotty they do things because they need to
be done and the problems are interesting enough to
them to make it worthwhile.
Yet these sparks are almost invariably observable
only in retrospect and whats more, such sparks are
much like those that start a forest fire there may
be dozens or hundreds of them flickering around a
campfire that go nowhere because conditions arent
right, but if the weather has been dry for too long,
if the underbrush is overgrown and primed then
any one of those sparks (or many of them) may be
responsible for the raging conflagration.
(This same argument, by the way, is one of the
most compelling Ive seen against software pat-
ents, as important as they may seem to CEOs and
12 January 2007
AJAx.sYs-CoN.CoM
investors good ideas can only exist in a proper
context too early and there isnt enough technol-
ogy to support the concepts, too late and the ideas
become obsolete. Because software developers live
in a medium of common (and commonly available)
ideas, its very rare for a truly unique idea to actually
occur in this space.)
About now conditions are ripe for AJAX to occur,
if by AJAX we mean the consolidation of a baseline
platform of XML, JavaScript, and connectivity sup-
port across multiple browsers, the development
of a methodology for building distributed applica-
tions across the Web and agreements on the part of
enough market movers to abide by common con-
ventions to create an established framework.
Its arguable as to whether this should be called
Web 2.0. Its a nice catch-phrase, and Ive written a
few articles myself on what Web 2.0 really means.
However, I think that this tends to mask that whats
really going on here is essentially a continuity with
what happened in the 1990s, after taking a few steps
back to rejig some of the basicsmost notably XML.
The argument has been made elsewhere that Ill
repeat here that the end of the dot.com era occurred
because we pushed the prototype phase of the Web
too far and thought it was complete. Im a software
developer. I practice a form of development that
likely wont be out of place at any of your companies
I start with an idea, a model of where I want to go,
and build it much like I would a sculptures maquette
from clay add a module here, rewrite a part of an
API over there, building something up in pieces until
I get about as far as I possibly can. However, and this
is the important part, this maquette exists only as a
prototype for me to understand what I need to do in
the final product. Functionally its a mess the API
may not be consistent from one class or structure
to the next, the XML may be hideously non-optimal
for either performance or updating, the documen-
tation consists mainly of // To Be Written. It will
work, indeed, it might work quite well because Ive
been doing this gig for a while, but it will be almost
impossible to maintain and passing it off to another
programmer at this point will frankly be an invita-
tion for him or her to rewrite it.
However, that maquette is important to the scul-
tor, just as the prototype is important to a software
developer. It helps both of them shape their final
vision, and having completed the prototype, the
developer can then go in and rebuilt it right, insur-
ing that theres fundamental integrity between and
within the components, that the application is able
to integrate properly, and that the resulting product
is not only functional and (this is the critical thing)
maintainable.
Your applications will start to become obsolete
the moment the programmers stop working on
it because the business cases that the software
was intended to solve will change in response to
changes in the business environment and change
because youve solved the immediate business cases,
which in turn open up possibilities that werent open
before. What this means is that your applications will
spend far more time in a phase of incipient obsoles-
cence than they did in development, which means in
turn that they should be designed to age well.
Given all that, weve developed the prototype
with Web 1.0, and like all too many products out
there, the prototype was shipped. Web 2.0 is not a
new Web, its what happens after engineers take the
crash test dummy from the 100 MPH collision with
a tanker truck and examine whats left. AJAX is, as a
consequence, a natural evolution of that.
EnteringtheHolodeck
XMLMessaging/XMLPresentation
The issue of XML is perhaps fundamental to this
whole discussion. XML is more than just a replace-
ment for HTML, and after a decade of XML being out
there Im not going to spend any time digging into
what exactly it is. If you dont know, ask your program-
mers. If your programmers dont knowfire them.
Seriously. All of your data will eventually be moving
around in XML streams of one sort or another if it
doesnt already, your databases are likely increasingly
speaking XQuery as well as SQL (and there are MANY
MANY benefits to that), chances are that your middle-
ware is increasingly tasked with transporting and
manipulating XML, and of course your client applica-
tions are increasingly assuming one or another XML
dialect to render content. That of course is not even
beginning to talk about the XML services that are out
there, the fact that in your verticals your customers,
business partners, and competitors are already work-
ing with industry-specific XML schemas and will be
expecting you to be too. If your programmers dont
know the basics of working with XML then chances
are pretty good theyll be a liability real soon now.
Keep in mind that XML is fundamentally a mech-
anism for abstraction. Its not a product its not
even, technically speaking, a language. Its simply a
set of conventions for structuring data in particular
ways and providing means to identify compositional
elements in that data. I remember one client ner-
vously viewing the medical landscape and getting
alarmed that a particular hospital group was going
to XML. I was personally ecstatic it meant that the
application I had developed for the client would
be able to work more easily there than with those
groups that were still dealing with patient records
on paper (or even in SQL databases). Its key to this
whole Web 2.0 thing the free flow of information
requires a common structural language, and XML,
for all its warts, is it.
However, that doesnt mean that XML by itself
is the answer, and more importantly doesnt mean
that XML itself hasnt been changing to reflect the
evolution of the Web. In particular, there are several
key aspects of XML that will likely loom large in the
AJAX world, and you should be looking very carefully
at these as you evaluate technological investment for
the next few years.
OnImpulsePower
ObjectiveXML(E4X)
This is an effort on the part of a number of
different language developers to create a simpli-
fied mechanism for working with XML. JavaScripts
version is called HYPERLINK http://www.ecma-
international.org/publications/standards/Ecma-
357.htm \t _top ECMAScript for XML (E4X), PHP
calls it HYPERLINK http://ca.php.net/simplexml
\t _top SimpleXML, Java has HYPERLINK http://
www.alphaworks.ibm.com/tech/xj \t _top XJ,
Microsofts .NET platform has HYPERLINK http://
msdn.microsoft.com/data/ref/linq/ \t _top LINQ.
In nearly all cases, its intent is to undo some of
the verbosity introduced with the W3Cs Document
Object Model (DOM) API and make XML manipula-
tion as easy as object manipulation is in most lan-
guages.
ImReceivingaMessageona
SubspaceFrequency
AtomandXMLSyndication
Syndication is for more than just blogs. Incredible
amounts of information in your system, from red
shirt security types that are expendible to planets
that serve Earl Grey tea can be thought of as lists that
can be presented as syndicated information. Atom is
an XML format designed to be a good mechanism
for presenting lists of content and includes its own
(openly available) publishing formats.
The fact that each Atom entry can also contain a
veritable forest of links of varying types and seman-
tics also makes it a good lightweight alternative to
RDF and other relational formats, especially once
people start migrating to Xquery-enabled databas-
es.
For instance, consider as an example a set of
schematic diagrams (of, say, starships just to keep
in theme here), with each ship being one entry in
an atom feed. Each schematic in turn contains a
breakdown of the schematic by section, and each
section in turn contains a list of callouts that point
to specific items of interest in the schema section.
If each of these lists consists of entries defined with
appropriate linkage structures then this applica-
tion essentially becomes simply a matter of pulling
in external news feeds that contain enough data
to describe particular nodes in a graph while at the
same time provide unique links capable of pointing
to subordinate feeds. Certainly such information
can be expressed as RDF as well, but the fixed com-
monality of Atom feeds means that theres typically
enough to populate generalized components with-
out requiring that semantics seep into the equa-
tion.
Whats perhaps more compelling about such syn-
dicated feeds is that the system for displaying them
assumes that such information changes over time,
that the hyperlinked lists are themselves ephemeral
and have some form of time or thematic relevance.
Obviously, news in general fits this bill well, but does
weather information, availability of computer sys-
tems, lists of students in a given course and so forth?
An Atom list is fundamentally a cohesive editorial
unit, with all items in the list tied together by some
relevant criterion.
One of the critical issues inherent in deploying
Web Services has been the question of determining
how to designate list or array content. If you think
of an Atom feed as an array in which each entry has
a minimal set of metadata that can provide some
context for the links contained in the feed then you
can do such things as build tools that will display
Atom without needing to know what the specific
payload is, which in turn makes it much easier to
componentize such viewers. This is discussed more
in the final section of this article about bindings and
components.
Computer?Yes,Dear
XQueryandXMLDatabases
Every era in computing has defined its own para-
digms for reading and updating data. If youre read-
ing a relational database to convert into XML then
sending XML up to the server and spending time
with DOM converting it into SQL, XQuery is for you.
XQuery is a lightweight (and non-XML) language for
manipulating XML based in large part on the XPath
2.0 specifications that are going gold this month.
Ive written two books and perhaps a dozen
articles and blog postings on XQuery. They were,
admittedly, too far ahead of the curve the speci-
fication for an XML-oriented query language has
been underway since before 2000 and even today the
formal specification strictly handles only the query
(not the update) side of data management. However,
one of the most interesting facets of XML databases
has been the fact that a number of different mecha-
nisms for handling updates have been tried, and the
most elegant of them seem to tie into the notion of
performing such updates in the same query space as
used for getting XML requests in the first place.
I think its fair to talk about XQuery and XML
databases in the same breath. The two are funda-
mentally tied together, and are further tied to the
14 January 2007
AJAx.sYs-CoN.CoM
notion of data provider abstraction. A significant
amount of the work involved in putting together a
Web application of any complexity involves a trans-
lation layer to communicate between the database
and the Web client. For the most part, such middle-
tier services involve using some sort of data abstrac-
tion service such as ODBC, ADO, Spring, etc. to read
from or write to specific fields in a database, typically
using a language such as C# or PHP to handle this
work.
Unfortunately, such code is remarkably fragile,
is very verbose, always deals with information at
the atomic level even when the information may
be coming in (or needs to be produced) at a more
abstract aggregate level, and all too often is spread
out over several different functions or Web Services,
making maintenance costly and cumbersome.
XQuery shifts the processing of such queries (and
potentially updates as well) out of the server lan-
guage and into XQuery scripts.
XML databases are becoming both fast and
robust, and there are some interesting update exten-
sions proposed (and integrated into open source
projects such as HYPERLINK http://exist.source-
forge.net/ \t _top eXist and HYPERLINK http://
www.sleepycat.com/products/bdbxml.html \t
_top Sleepy Cat XML Database) that handle the
update side of XML data query in a clean and seam-
less way. From personal experience, such databases
can cut your development time significantly in the
Web application space.
TheFluxinMatter/Anti-MatterConverters
XSLTandTransformations
XSLT is old hat in the XML world, but its becom-
ing a major part of both the client and server side
of AJAX programming because most browsers now
support some form of XSLT processor. For those that
dont (and as a means of consolidating the slight
variety in existing XSLT APIs) Google has released the
HYPERLINK http://sarissa.sourceforge.net \t _
top Sarissa XSLT Processor that provides JavaScript-
based XSLT support (and that invokes native proces-
sors when available for performance).
XSLT in the hands of a good programmer is a
wonder tool, especially if you can use XSLT 2.0,
which goes gold this month as well it provides a
means to provide exhaustive transformations from
one form of XML into another, can read from mul-
tiple XML streams and produce multiple forms of
output, can be easily subclassed to handle variations
in formats, and works incredibly well even in bind-
ings (which Ill talk about shortly).
One additional facet of eXist that I like is the abil-
ity to perform XSLT transformations from within an
XQuery and then continue processing the results in
the same query (including passing the transforma-
tion onto a conditional pipeline of other transforma-
tions). I cant stress enough how important XSLT is
even now, and how it will perhaps be the dominant
mechanism for manipulating XML in the future.
OutofSpace-Dock
TheMovetoXHTML
The distinction may seem minor XHTML is, for
the most part, simply an expression of HTML using
XML rules rather than the older SGML rules but the
effects are profound. By shifting to XHTML, you gain
all the manipulative tools of XML, including the abil-
ity to create arbitrary tags that can be transformed
or otherwise bound, the ability to incorporate other
namespaces (from the graphically oriented SVG to
MathML to RDF for metadata to Xforms), and the
means to validate such XHTML content quickly and
easily.
Whats more, you can incorporate XHTML frag-
ments into transport formats such as Atom, or as
secondary documentation in many other formats.
Finally, even browsers that dont formally recognize
XHTML (such as Internet Explorer) can still take
XHTML as valid HTML with a minor change in the
response header.
PlottingaCourseforRigel7
XFormsandSchema-DrivenProgramming
As a technology evangelist, one of the things that
I have to be very sensitive to is to recognize those
technologies that are still in their infancy but that
have the potential to be much more. XForms defi-
nitely fits into this category. XForms, another W3C
standard, originally was started to create a some-
what more robust set of controls for the Web that
could take advantage of the newly emergent XML
standard.
One of the first things that came from this was the
realization that such components were ultimately
mechanisms for handling data-binding (assuming,
as has proved prescient, that XML would likely be
the ultimate expression of that data). This in turn
implied the existence of a data-model, and by exten-
sion a control/binding layer that serves to both map
content to the controls and constrain what the con-
tent can be.
What emerged from this effort was the XForms
standard, which was released as a 1.0 standard in
2003 and is scheduled to be released in 1.1 form later
this year, designed to handle use cases and ambi-
guities that arose with the original specification.
This specification includes supports for a number of
features:
XPath Mapping: All components are populated
either directly or indirectly using XPath expressions.
New Form Elements: Including <output> and
<range> (slider) components
Repeating Component Groups and Contextual
Toggles: Making it possible to generate repeating
tables, wizards, and similar components.
Add/Delete Capability: Items (and complete sub-
structures) can be added or removed from the
data model using components without an explicit
need for imperative code.
Auto-updating via XML: The XForms data-model
will, on submission, post the relevant portions of
the data model as XML to the server automatically
without losing the page state.
Constraint Modelling: Constraints are applied to
the data model, not the components, though the
reaction of components to changes in the value or
validity of the model can change the UI.
Abstract Component Model: XForms components
are abstract, and are intended to be subclassed or
otherwise bound via some form of presentation
layer. All implementations provide default bind-
ings, of course, but the XForm should ultimately be
skinnable.
XForms implementations have been around
for a couple of years, with a number of different
approaches being taken. Solutions such as IBMs
Workplace Forms (formerly PureEdge) and x-ports
FormsPlayer are standalone solutions existing in
a separate (albeit embeddable) application space
from the normal browser. Orbeon is an open source
AJAX implementation, while the Mozilla Foundation
is creating an XForms extension that should be
natively installed with Mozilla Firefox 3.0.
While there are other XML aspects that play a
part in the SOA/AJAX space, ultimately they are all
moving towards a form of application in which the
data (moving around typically as XML, or in the case
of lighter-weight messaging as JSON) moves from
point to point in a distributed network, one where
the client becomes far more important, and where
the same client architecture is likely to be rendered
on-the-fly in response to a state contained in the
user profile and experience.
ExtendingTractorBeams
TheImportanceofBindings
Several speakers have made the pronouncement
that while AJAX is powerful, its not QUITE there
yet. And Im inclined to agree for a number of rea-
sons though perhaps not the ones that people had
in mind. In 2005, Tim Berners-Lee gave a keynote
address at the World Wide Web Conference in Japan
where he pointed out that the insecurities plaguing
Web browsers were a direct result of the introduction
of scripting language within the confines of the Web
browser.
Understanding why such a blanket statement, one per-
haps at odds (though in the long run I dont think it is) with
what was covered at the AJAX conference, should be both
made and be true can go a long way towards understanding
where the Web itself is going, and certainly where Web devel-
opment is heading. There are a number of key insecurities
about immediate scripting that make the Web more fragile:
Platform Incompatibilities: Each incompat-
ibility offers both a chance for code to break and
for rogue code to get through. While a common
framework here would be desirable, vendor dif-
ferentiation makes that framework difficult to
achieve.
Cross-Domain Scripting: As AJAX programmers,
we want to have the freedom of getting out of the
sandbox, but the security restrictions involved in
such sandboxing make certain sense.
Intermingling and Poor Code Reuse: Too much
JavaScript is cut and pasted, often out of context
or without consideration of side effects. Toolkits
help, but even they can be used as crutches and
limit the options of what a developer can do, espe-
cially in an enterprise context. Managed code in
the business environment is important, if not crit-
ical, which is part of the reason that uncontrolled
coding in a Web environment makes IT managers
as leery as Scotty with a misaligned transporter
coil.
Lack of Validation: With such cut-and-paste code,
it also makes it far more difficult to validate the
code, because its typically developed in a produc-
tion environment at production deadline speed.
Poor Abstraction and Maintainability: JavaScript
code is more susceptible than most when it comes
to the generation of unmanageable code, and
such code management is the lifebread of enter-
prise IT.
Given all these factors, is there any real alterna-
tive around there? I believe that there is, and its
one that many third-party vendors have of course
twigged onto. This alternative is XML Binding, which
can be thought of as the following:
An XML Binding is the association between an
XML element in a presentation environment and
some form of functionality from an external bind-
ing document that persists beyond a single presen-
tation generation. Properties for the bound element
can, in turn, be set via attributes, or from associ-
ated methods defined from the binding itself. Such a
binding is also known as a behavior.
What this means in a nutshell is that you can
introduce XML tags into your presentation docu-
ments (XHTML or otherwise), define a binding or
behavior on those tags then let this underlying
behavioral functionality control the interactions
with clients in the application.
Such XML Bindings can cover a lot of different function-
ality. A short list of such bindings include such things as:
16 January 2007
AJAx.sYs-CoN.CoM
Page Layout Elements: This includes oriented
boxes, containers, flexible spring controls, stacked
boxes, tabsets, wizards, and similar components.
Data Fed Elements: Undisplayed data providers
(both static and dynamically refreshing, such as
a news feed reader), dynamic tables, XForms data
models, Live treeview components, and so on.
Graphical and Animated Elements: Defined or
complex generated shapes, charts, graphs, bound
image components, animated clocks. and other
widgets.
Secondary Applications: Some tags may also
contain whole applications slideshow widgets,
image selectors, IM windows, and so forth.
In short, such XML Bindings give you all you need
to effectively create either primary applications (an
insurance application) or subordinate infrastructure
(such as a notification widget in a Web page) and
can do so without necessarily requiring an extensive
amount of server-side programming.
Most commercial and open source XML frameworks
are built on the notion of bindings in one fashion or
another, although whether the ability to define subor-
dinate components from those frameworks is imple-
mentation-dependent. Languages such as Mozilla XUL,
Adobe FLEX, Microsoft XAML, Laszlo SystemsLZX, and
so forth are all built in this same way, though being able
to build components (which is what XML binding is all
about) that can be directly integrated into Web page
flows varies considerably from app to app.
There are a number of different languages
for handling binding, the most notable of which,
Mozillas XBL, can be used to create components
directly in Web pages as well as in the Mozilla appli-
cation itself. Most of these languages create a one-
to-one association between the XML object and a
given class written in a language such as JavaScript,
with the additional notion that the component con-
structors, methods, and properties are aware of (and
shadow) the XML element being bound. The class, in
turn, becomes responsible for rendering the content
to be seen in the tag (Ive often found that coupling
such a binding with XSLT works miracles here).
Such bindings offer a huge win for enterprise
development in particular:
Standardized Library: Code can be created in
isolation and then added to an enterprise library
of useful objects, making it much easier for IT
managers to control code workflow.
Separation of Skillsets: A component developer is
a considerably more difficult person to find than
Web designers and developers, so by creating spe-
cialized XML bindings you can keep such develop-
ers focused on building components rather than
spending all of their time marking up code.
Security: Such components, being tested in isola-
tion, can be introduced independent of production
timeflows and can be made appropriately secure.
Moreover, such components can also perform sec-
ondary implementation bootstrap code that pulls
in what should be private coding will only function
if the page is within the appropriate security con-
text, so people cant follow a URL to get a source
code library.
Code Maintenance: With XML Bindings you can
keep your XML contained in a single block with-
out the need for additional inline scripting. This
abstracts the application, making it easier to read
and change under the hood so long as youre
not changing the XML interface, making it much
easier to maintain in the long run.
Platform Flexibility: An additional side effect of
such bindings is that in limited-capability devices
the XML from the source code can be transformed
directly on the server, and the bindings them-
selves can be amended to handle device-specific
implementation details. This masks the need to
have a common development framework, some-
thing thats currently limited with AJAX.
What is perhaps most significant is that its possible
now to create binding layers for most, if not all, browsers
by using JavaScript. In some cases (specifically Mozilla
Firefox and Internet Explorer) native binding languages
do exist. In the short to mid-term, this points to needing
to create specific bindings for each platform, though
effective use of the XBL (or emerging XBL2) standard
can mitigate the actual work considerably.
I see XML Bindings as being the logical progression
of AJAX over the course of the next two years although
the technology exists today in somewhat disparate
form. Its likely that the adoption of such XBLs will
actually take place more in the corporate sphere where
browser use can be mandated and the component use
consequently not limited by the need to build super-
controls than it will in the wider Web, at least first, but
over time many of these components should move into
the mainstream of Web development just as JavaScript
framework libraries are used today.
TheFinalFrontier
The efforts going on in the Web right now are not
a radical revision of the past, but rather a refinement
and refactoring that is at the heart of nearly every
software endeavor, and it is this refactoring, far from
obvious for those in the thick of it but profound
nonetheless, that is ensuring the integrity of the Web.
We are moving to a model where we have both an
imperative model for power and a declarative model
for structure, something near and dear to an old engi-
neers heart, and it will be both glorious and, more to
the point, elegant, when it is done. May you, gentle
reader, boldly go where no one has gone before. n
Contact Us
Address:
555 Not My Home St.
Big City, CO 12345
Scary Question.
Exactly who is developing your next app?
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.
C Y N E R G Y S Y S T E M S . C O M
Contact Us
Address:
555 Not My Home St.
Big City, CO 12345
Scary Question.
Exactly who is developing your next app?
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.
C Y N E R G Y S Y S T E M S . C O M
A
lthough AJAX has gotten a lot of press atten-
tion over the last two years, most of it has
focused on the technology: JavaScript, XML,
and JSON. But what business benefits do AJAX-
enabled Internet applications provide? The primary
benefit for users is an improved experience: one
closer to desktop applications. Here Ill review the
benefits of AJAX for users
and then link them to
specific business
benefits and
ma k e
some recommendations about developing AJAX fea-
tures in existing applications.
AJAXandtheRichInterfaceApplication
The goal of creating Rich Interface Applications
deployed via Web browsers isnt new, of course. In
making the transition from client/server applica-
tions to Web applications, we gained ease of deploy-
ment all you need is a standard Web browser but
we took a major step backwards in terms of the inter-
face. A certain austere simplicity was imposed in the
early days by the limitations of HTML and this argu-
ably made the first wave of Web applications easier
to understand and use by neophytes. Nevertheless,
for users who understood and were accustomed
to more complex, interactive interfaces, Web apps
came to be a frustrating experience at best.
In a report published in May of 2001 (The X
Internet) Forrester Research described the need for
an experience delivered over the Web that was more
akin to the experience of desktop applications. It
noted that todays Internet experience is more like
reading in a dusty library than basking in the birth of
a new medium and argued that the solution would
be an executable Net that greatly improves the
online experience by creating deeper interactivity
and an experience more like desktop applications:
Intelligent applications that execute code near the
user to create rich, engaging conversations via the
Net.
Rather than downloaded heavy Java applets and
applications like those Forrester predicted, con-
temporary Rich Internet Applications are probably
based on AJAX. (The Forrester X Internet report
specifically links the executable Net to millions of
Java Virtual Machines but the clear victor in 2006
would seem to be JavaScript, not Java, for developing
client-side functionality).
BuildingthebusinesscaseforAJAX
Business
Whatsin
ItforMe?
by John Eckman
20 January 2007
AJAx.sYs-CoN.CoM
AJAX-style applications are fundamentally iden-
tified by two key characteristics:
HTTP requests in JavaScript not requiring an
entirely new page request (often, but not always,
asynchronous requests, in the sense that theyre
not triggered by specific user clicks)
Programmatic updating or portions of the page
without a full page reload
These two relatively simple concepts, com-
bined with a healthy dose of programmer ingenuity,
opened the door to developing complex applications
to run in Web browsers without a browser plug-in.
UserBeneftsandBusinessBenefts
The primary business benefits of AJAX applica-
tions derive from the improved experiences they
offer to users:
User Benefit
Associated Business Benefit
Ease of contribution
More frequent contributions from more users
Immediate feedback
Fewer abandoned transactions,
Better data submitted
More interactive experience
Longer sessions,
Increased user loyalty
Responsive local actions
Lower server-side computing, bandwidth costs
Automatic updates
Lower cost of deployment, upgrades
EaseofContribution
Although these arent specifically asynchronous,
AJAX widgets enabling users to contribute content or
data to a page without going through a complicated,
multi-step process are increasingly common. A good
example of this is Amazons ratings widget on product
pages. As the user moves the cursor over it, the avail-
able stars fill in and their meaning is displayed in text
(I hate it, I dont like it, Its OK, I like it, I love it). If the
user clicks on the fourth star, for example, he submits
a four-star rating (I like it) and the Rate this Item
widget is replaced by one listing the saved rating.
While small and unobtrusive, this widget pro-
vides a very usable interface for submitting a rating.
It avoids the need to click on a link, load a separate
page (or pop-up), fill out a Web form, submit that
Web form, and be shown a confirmation page (or
pop-up), which requires another click to return
to the original product page. Similar functionality
abounds in many Web 2.0 properties like the way
Flickr lets users add tags to photos without navigat-
ing through a multi-step process.
Whats the business benefit in making it easier for
users to contribute without disrupting the applica-
tion flow?
Well, increased contributions for one. In the era
of Web 2.0 and the architecture of participation, get-
ting a larger number of users to contribute a review,
comment, tag, or rating can make the difference
between a successful network and dead one.
ImmediateFeedback
One of the most painful experiences of the first
generation of Web applications was the multi-page
form. Whether registering for access to a site, fill-
ing out a checkout form in an e-commerce store, or
trying to establish a recurring payment in an online
banking application, users came to dread the step 1
of 5 flows such applications required.
Far too often users were given weak guidance as
to what to expect of format and style of names, credit
card numbers, phone numbers, and dates. Much of
the time the only way to determine the success or
failure of a multi-step process was to get to the end
at which point one was often returned to the begin-
ning with some vague admonition that an error has
occurred. Please correct and resubmit the form.
One of the benefits of AJAX has been to radi-
cally alter the experience of filling out forms. Forms
inputs can be validated character-by-character or
line-by-line. The user can be informed immediately
upon filling out a given field that the entry in that
field is in error.
Indeed, some AJAX-enabled forms have been
improved to automatically convert common formats
to desired formats. For example, if the credit card
number is supposed to be entered with no dashes or
spaces, an AJAX-enabled form can simply drop any
dashes or spaces entered by the user, adapting the
entered data to the target format.
Whats the business benefit to this approach?
First and foremost, it minimizes end-user pain.
Anything businesses can do to make the experience
of interacting with them via the Web less painful will
create fewer frustrated customers (or potential cus-
tomers).
Additionally, leveraging immediate feedback
and data clean-up will lead to a greater number
of successfully completed transactions, whether or
not that translates into fewer abandoned shopping
carts, more recurring transactions established, or
even a larger number of customer complaints being
accurately and efficiently recorded. (After all, if cus-
tomers are going to complain, its more effective
to accurately and quickly record and acknowledge
them than to frustrate an already disappointed con-
sumer).
MoreInteractiveExperience
Traditional HTML-based applications werent in
any real sense interactive. The user browsed pages
skimming text, identifying links, and then clicking
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. Johns technical background
includes J2EE and .NET frameworks as
well as scripting languages and presenta-
tion-tier development approaches, in addi-
tion to information architecture, usability
testing, 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.
on one of those links to retrieve and display a dif-
ferent text page. The model was (and still is for such
applications) fundamentally page-based: the page
is displayed, the user request received, the page dis-
played, the request received, and so on.
AJAX-based applications, on the other hand, can
enable much richer interactive models. Assets on
the page can be dragged and dropped, opened and
closed, hidden and revealed, collapsed and expand-
ed. All of this can be enabled without requiring a
full-page refresh with its context-clearing impact on
the user.
Google Maps, for example, revolutionized the
online mapping space by letting users pan around
the map space, updating in near-real time the newly
exposed space at the edges of the map. It wasnt that
in previous online mapping interfaces you couldnt
get to what was just west of your field of vision; its
just that in previous maps you did so by clicking on
the west arrow, and an entirely new page reloaded
containing the new area of focus. This was a very
disorienting experience, one greatly improved upon
by the smooth, continuous impression of the Google
Maps approach.
Whats the business benefit?
People enjoy using applications that are more
richly interactive. They are more likely to use an
enjoyable application more often and longer. Given
that users increasingly expect the Web to function as
the primary channel for interaction with the compa-
nies they do business with, its important to be able
to offer those users an experience they find enjoy-
able, not merely create an experience they find less
painful.
ResponsiveLocalActions
Because JavaScript in AJAX applications is run
on the client machine it executes in the browsers
JavaScript engine, not on the server it can provide
a more responsive experience without the latency
caused by the need to fetch additional data from the
server.
Applications can be designed to download a set of
data and then enable the user to take various actions
on that data without reloading it from the server:
expanding and collapsing items in a tree structure,
switching between two or more visible tabs, or sorting
data in a table structure. All of these activities, which
users are accustomed to from desktop applications
and operating systems, can be enabled with local data
and JavaScript acting on that data.
So, whats the business benefit?
In traditional Web application development
before AJAX, a user who wanted to sort the data in
a table might have clicked on a column header. This
request would have been sent to the server, which
would have created a new copy of the page with
GoogleMaps,
forexample,
revolutionizedtheonline
mappingspacebyletting
userspanaround
themapspace,
updatinginnear-realtime
thenewlyexposedspace
attheedgesofthemap
22 January 2007
AJAx.sYs-CoN.CoM
the data sorted and returned the entire page to the
client. This meant server processing time as well
as bandwidth costs to resend data that the client
already had. Similarly, the clients native processing
power (in todays desktop PCs this is a tremendously
underutilized capacity) was ignored, or used merely
to render the HTML returned.
Enabling applications to act locally on data
received for basic transformation, display, sum-
mation, or other functions lowers the need for
server processing load and bandwidth in addition
to delivering a more responsive experience for the
user.
AutomaticUpdates
Because AJAX applications are delivered via Web
browsers visiting Web pages, its become very easy to
update their functionality. Rather than having user
download and apply large binary patches by running
installers, AJAX applications can update themselves
whenever the user visits.
Users get the benefits of always having access
to the latest code base and all the newest features,
while organizations get the ideal deployment model
and dont need to ship CDs, send technicians to
employee desktops, or even instruct users to down-
load and run installers, resulting in a lower overall
maintenance cost.
Which of these benefits can be realized in your
application depends on whether youre integrating
specific components into an existing application
to solve feature-level usability problems (integrat-
ing immediate feedback into registration forms, for
example) or creating an entirely new self-contained
application with desktop-like interactions.
JustBecauseYouCan,DoesntMeanYou
ShouldApproachestoAvoid
Ive focused primarily on the benefits AJAX appli-
cations can bring to Web applications. Enterprise
users should also be aware, however, of the following
cautions with respect to AJAX applications:
We Must AJAXify It!
Beware of any business or IT stakeholder that
insists on using AJAX for AJAXs sake. Given any
multi-page business application, its certainly possi-
ble to identify places where an AJAX-style approach
(partial page transformation, asynchronous request)
might add value. But the requirements should be
driven by improving the experience rather than
having the improved experience tacked on as a post-
development justification.
We Need More Widgets!
In the world of AJAX applications, it can seem
that whoever ships the most widgets wins. But
too many interactive components on a single page
can overwhelm the user. If your users arent early
adopters, they may still be coming to terms with the
notion that part of the page can update without a
page refresh make sure youre not so far ahead of
your users that you end up making the experience
more confusing rather than less. What works in the
latest greatest hot application for bleeding-edge
Web developers may not work in a consumer-facing
application for e-commerce, at least not without
major modifications.
Rip and Replace
Enterprises should focus on deploying AJAX tech-
niques and technologies in the new applications
they develop today, and should look carefully at
existing applications for opportunities to improve
their experience. Rather than creating a set of appli-
cations to be upgraded, look at each application
whenever its up for enhancements or maintenance.
Well Poll for Changes Every 10 Seconds
Multiple approaches to creating long-lived con-
nections between AJAX applications and their serv-
er-side components are being developed and proto-
typed in many popular AJAX frameworks. However,
most AJAX apps still use some form of client polling
to simulate server-pushed information. (In other
words, an AJAX component in a page polls the server
to see if new information is available, ever x sec-
onds). Enterprises, especially those deploying appli-
cations to users, have to be careful about leveraging
client-side polling due to the potential impact on
bandwidth. This isnt to say its always a bad idea, or
even most of the time just that you shouldnt assume
no adverse impact. Design, prototype, test; repeat as
necessary.
WellWriteItAllfromScratch
Ive occasionally seen otherwise sane developers
confronted with AJAX-style applications turn back
into start with a blank screen coders. There are
numerous production-quality ready-to-use applica-
tion frameworks for AJAX-style applications: in just
about any server-side coding language, and in pure
client-side JavaScript. Many are open source. Some
are commercially available. Make sure youre getting
appropriate leverage from the frameworks before
you dive into custom coding.
Above all, the key to delivering effective AJAX
applications is to focus on the business value and the
user experience first and worry about the implemen-
tation details second. If you find yourself trying to
sell management on leveraging AJAX, think about
what the benefits to the business could be and sell
those instead: youll likely find a much more recep-
tive audience. n
H
ard-nosed executives recognize that there
are costs associated with any benefit. To
convince todays upper-level decision
makers to approve strategic investments, they need
to hear more than phrases like essential to the busi-
ness, the results are too unpredictable, and yields
intangible benefits. In the world of Web develop-
ment, the move from HTML to AJAX-powered HTML
can often be achieved at a relatively low cost, but
there are both direct and indirect costs associated
with AJAX that must be taken into account. A close
analysis of these factors will enable business man-
agers to make more well informed decisions when
considering AJAX adoption in a particular applica-
tion and across their organization.
Lets look first at the expected benefits from
AJAX.
AJAX is all about ways to create a more interac-
tive and productive connection between a user and
a Web-based application. Because AJAX provides
similar advanced user interface features to those in
desktop applications (such as advanced UI controls,
animated effects and adjustable layout controls)
thereby providing the visual and interaction tools
needed to make the application self-explanatory
users spend less time learning and operating the
application. The AJAX partial page update feature
minimizes user delays by eliminating the click, wait,
refresh approach of pre-AJAX HTML applications.
Beyond better user interfaces for existing appli-
cations, AJAX enables new classes of applications
that fall under the umbrella term Web 2.0 that also fit
into a Service Oriented Architecture (SOA). Among
the next-generation applications that will power the
enterprise and the Internet of the future are the fol-
lowing:
Users as co-developers: New AJAX-powered envi-
ronments, such as application wikis, are empow-
ering users to create their own customized mash-
ups including personalized dashboards and situ-
ational composite applications.
Collaboration: AJAX technologies are typically the
centerpiece of Web 2.0 information collection and
sharing environments that harness the collective
Costingitout
Feature
WhenDoesAJAX
MakeBusinessSense?
by Jon Ferraiolo
24 January 2007
AJAx.sYs-CoN.CoM
intelligence of disparate communities.
Software above the level of a single device: Web
2.0 is accelerating the movement from installable
desktop applications to Web-based applications,
thereby leveraging the advantages of networks
and information sharing.
Cross-device applications and mobility:
Simultaneous with the adoption of Web 2.0 is
the growing proliferation of Web-capable mobile
devices. AJAX technologies enable Web 2.0 appli-
cations across both large-screen desktops and
small-screen mobile devices.
AJAX often boosts developer productivity. There
are many AJAX technology providers, including both
commercial products and open source initiatives. As
a result, developers will find the off-the-shelf com-
ponents, toolkits, frameworks, educational materi-
als, and other resources they need to produce and
maintain next-generation Web 2.0 applications built
with AJAX. And due to open source alternatives, AJAX
provides zero-cost deployment options as well.
Because of competitive pressures, vendors often
vie for your AJAX business based on the developer
productivity benefits they offer. Two common pro-
ductivity features are UI markup languages (UIMLs)
and IDE integration. The UIMLs allow for the use of
declarative approaches using HTML and/or XML for
large parts of an AJAX application. IDEs can provide
source code completion, source code highlight-
ing, drag-and-drop authoring, JavaScript debugging,
XHR monitors, runtime stack views, and variable
watching.
AJAX and SOA need each other so both can reach
their full potential. SOAs encapsulation of business
functionality into discrete services with well-defined
Web Service interfaces makes it easier for AJAX
toolkits to facilitate the creation of Rich Internet
Applications (RIAs). AJAX applications need to lever-
age business functionality, but, in the absence of
SOA, AJAX toolkits must have myriad adapters sup-
porting disparate technical means of accessing that
functionality. The more that SOA advances, the more
the toolkits will be able to streamline access to busi-
ness functions by supporting Web Service client
technology. Thus, SOA helps move AJAX forward.
Conversely, AJAX helps SOA move forward. We
need RIA technologies to be able to exploit and jus-
tify the significant investment that SOA entails. The
ability to create mashups, dashboards, and compos-
ite applications relatively rapidly to respond flexibly
to changing business conditions is the essence of the
ROI that we expect from investing in SOA.
In addition, AJAX deployment offers several long-
term strategic benefits including:
Replacement for desktop applications: AJAX offers
a desktop-like user experience while retaining the
benefits of server-based application deployment,
centralized infrastructure administration, easier
scalability, and immediate availability of applica-
tion updates to all users. As a result, AJAX helps
accelerate the movement away from installable,
two-tier, client/server applications to multi-tier
Web applications.
Higher customer expectations around the user
interface: The industry is embracing richer, more
desktop-like, user interfaces for customer-fac-
ing Web applications. In many circumstances,
adopting AJAX techniques is becoming a business
requirement to maintain parity with the rest of
the industry and match growing user expectations
about Web-based user experiences.
Operations efficiencies: In todays global econo-
my, cost efficiency is more important than ever.
AJAX techniques can help maintain the efficiency
and competitiveness of internal systems.
WhatAretheCostsAssociatedwithAJAX?
The costs for adopting AJAX depend on the cir-
cumstances of the application youre developing.
In cases where AJAX snippets are added to exist-
ing HTML applications in an ad hoc manner, the
incremental costs can be small. On the other hand,
if the AJAX deployment strategy requires significant
retooling of the existing IT infrastructure and sub-
stantial staff re-training then costs obviously go up.
Its also important to keep in mind that AJAX
techniques require developers to learn techniques
on both the client side as well as the server side.
On the client side, developers may have to famil-
iarize themselves with one or more AJAX client-side
toolkits, along with programming techniques for
incremental DOM updates, XHLHttpRequest-based
client/server communications, and asynchronous
communications event handling. Most of these tech-
niques require incremental knowledge on top of
existing expertise with HTML and JavaScript.
On the server side, re-education requirements
depend on the AJAX toolkits in use. For some tool-
kits, developers may have to familiarize themselves
with the AJAX toolkits UI markup language and its
server-side AJAX APIs.
Most AJAX applications leverage an AJAX frame-
work but still require some level of customization by
the development team. A key factor in calculating
the cost of adopting AJAX is the amount of custom-
ization work required to complete the task. If the
AJAX frameworks built-in features are sufficient for
your needs then your AJAX development costs will
be lower.
For existing applications that are modified to take
advantage of AJAX techniques, end users will require
some re-training on the applications new AJAX-
powered user interfaces.
NewIssuestoManage
Like anything else, the AJAX technique of partial
data exchange can be misapplied so that server and
network loads increase in an undesirable manner. So
its critical that AJAX developers are made aware of
the importance of these issues and that bandwidth
behavior is tested before applications are deployed.
Another concern is the misapplication of AJAX
push techniques, where AJAX toolkits enable servers
to push incremental data to clients without requiring
the clients to poll periodically. Developer education
about these issues and pre-deployment testing of the
applications network behavior are important.
With mashups plugging in third-party compo-
nents there are potential security implications. Its
recommended that IT managers establish a com-
pany policy on mashup products and technologies,
such as only installing markup frameworks from
trusted suppliers; only allowing components from
trusted sources; and requiring secure gateway facili-
ties that control the domains with which particular
components can communicate.
Typically each AJAX toolkit has its own features,
markup, and APIs. Long-term maintenance costs
will be minimized if the application uses a popular
Ajax toolkit thats familiar to a large pool of develop-
ers and by ensuring that the Ajax toolkit is OpenAjax-
conformant. (See Managing Long-Term Costs with
Help from OpenAJAX.)
OtherFactorsToConsider
Now lets take a look at some additional key con-
siderations in the cost/benefit analyses of adopting
AJAX and determining ROI. Some important points
to keep in mind include:
Interaction and user experience requirements:
If a given application requires either high levels
of user responsiveness (that is, its undesirable
to use the old-style click, wait, refresh HTML
technique) or requires a self-evident desktop-like
user interface (to limit training costs) then AJAX
techniques can reduce user wait time and improve
productivity in a measurable way.
Network bandwidth requirements: Applications
that generate high levels of network activity often
benefit from AJAX techniques by leveraging the
partial data exchange and partial page update
features associated with AJAX. AJAX techniques
often replace full-page requests with small data
exchanges, reducing network bandwidth require-
ments, minimizing server CPU processing, and
improving response times.
Scalability requirements: Large and/or growing user
populations require scalable application deploy-
ment architectures. In such scenarios, its critical to
determine whether the AJAX-enabled application
offers appropriate scalability characteristics.
The mission-critical nature of the application:
The greater the strategic value of the application,
the greater the investment in RAS (reliability,
availability, serviceability) required. Highly mis-
sion-critical applications may be less desirable
early candidates, but offer the highest ultimate
return.
The complexity of database interaction: AJAX
will be more difficult to apply where theres no
good separation of back-end databases from the
Web-tier application logic. Relevant questions to
consider: Is the application tightly coupled to a
back-end database? To what degree is transaction
integrity and recoverability critical, and how do
these factors relate to AJAX partial update tech-
niques?
The real-time nature of the underlying applica-
tion: In general real-time monitoring and real-
time business applications benefit significantly
from AJAX, particularly the push technologies
available in some AJAX toolkits.
Systems integrator requirements: If the applica-
tion requires involving a systems integrator then
its important to determine how familiar the inte-
grator is with AJAX and the AJAX toolkits that you
plan to use on the project.
ManagingLong-TermCostswithHelpfrom
OpenAjax
The OpenAjax Alliance produces various speci-
fications that define OpenAjax conformance, an
industry trust mark that promotes interoperability.
As OpenAjax conformance specifications emerge,
customers who require compliance from their AJAX
vendors will increase their interoperability, safety,
and choice, and thereby help manage the long-term
costs of adopting AJAX.
Conclusion
The move to AJAX is part of a business opera-
tions strategy and is often coupled with the move
to SOA. Arriving at estimates of return on AJAX or
SOA is a difficult challenge for IT managers and
executives. IT can support and even lead the effort
by providing recommendations on appropriate
questions to ask the business side of the house.
IT can also help generate the answers needed to
estimate ROI. Establishing an IT-user team to help
the business drive the direction of the AJAX effort
can be a forum for confirming and refining ROI
estimates. Making the leap to AJAX isnt something
that can be done overnight or with the snap of
your fingers. It involves serious consideration and
an honest internal evaluation. But by taking all of
these points into account, decision makers will
be better equipped to pave the way toward AJAX
adoption. n
Jon Ferraiolo is the acting director of
the OpenAjax Alliance, an organization
of more than 50 vendors, open source
projects, and companies using AJAX all
working together to accelerate industry
adoption and success with open and
interoperable AJAX-based Web tech-
nologies. For more information, see the
OpenAjax Alliance Web site at http://
www.openajax.org.
26 January 2007
AJAx.sYs-CoN.CoM
o Io WWW.parasoII.romlw81magatIna r raII (BBB) 8060041, x8601
2JJ P+|+c|| Cc|pc|+||c|. A|| c||| c|p+|] +|J/c| p|cJu| |+| ||||c|J +| ||+J|+|| c| |||| |p||1 cW||.
web Serv|ces
App||cat|oo Server
0atabase
Server
App||cat|oo
Log|c
Preseotat|oo
Layer
Legacy
webs|te Th|o 0||eot
*NQSPWJOH
QSPEVDUJWJUZDBO
TPNFUJNFTCFB
MJUUMFTLFUDIZ
Farasolt roducts have been helinq soltware
develoers imrove roductivity lor over 2O years.
Jtest, webKinq, and S0Atest work toqether to
qive you a comrehensive look at the code you've
written, so you can be sure you're buildinq to sec,
the new code doesn't break workinq roduct, and
any roblems can be lxed immediately. which
means you'll be writinq better code laster.
So make Farasolt art ol how you work today.
And draw on our exertise.
-FU1BSBTPGUmMMJO
UIFCMBOLTXJUIPVS
8FCQSPEVDUJWJUZTVJUF
Qbsbtpgu!TPBuftu
UN
Ver|hes web serv|ces
|oteroperab|||ty aod sec0r|ty
comp||aoce. S0Atest was awarded
"8est S0A Test|og Too|" by
Sys-0oo Ned|a 8eaders
Qbsbtpgu!Kuftu
UN
Ver|hes Java sec0r|ty aod
perIormaoce comp||aoce.J0dged
|oIowor|d's 2006 Techoo|ogy
oI the Year p|ck Ior a0tomated
Java 0o|t test|og.
Qbsbtpgu!XfcLjoh
UN
Ver|hes hTNL ||oks, access|b|||ty,
aod braod 0sage, aod maoages
the 4 key areas oI sec0r|ty aod
aoa|ys|s |o a s|og|e, |otegrated
test s0|te.
L
ike the rest of us developers out there, youve
probably been captivated by the promises
that AJAX and Web 2.0 make. Sure, theres a
great deal of hype surrounding any new technol-
ogy wave, but somehow this feels different. For the
first time since the Web application made its debut,
theres a real sense that a new paradigm shift is
upon us.
Now you might be someone whos been pulling
off browser magic for quite sometime and to you
this latest development may seem obvious, which
to a large extent it is. The groundwork for this new
era started in the late nineties and developers with
an itch to scratch have been heading in this direc-
tion ever since. So what has changed now? Well,
like paradigm shifts of the past, weve reached
the tipping point where the technology and
its benefits are attainable by anyone. The
concepts and technology behind AJAX
are no longer exclusively in the minds of
the hackers who brought them to light.
For any new concept to be wide-
ly adopted, it has to be shown to offer
a benefit to the public-at-large in a
way thats undeniable. Netscape did that
with the graphical Web browser, and so
the Internet was born. You can argue that
the Internet existed long before that and has
nothing to do with the Web browser, and youd
be right, but youd also be wrong.
The Internet didnt really matter until Netscape
Navigator demonstrated to the world why it mattered.
The same holds true for AJAX; it existed under a num-
ber of different names, but it didnt really matter until
the world saw what Google had achieved. Listening
to Jesse James Garrett talk about why he coined the
term AJAX, I cant help but wonder if anyone would
have noticed his seminal article if Google hadnt just
released GMail weeks earlier. Garretts analysis of the
need and where the future lay was stellar, but if the
world hadnt just been brought to the tipping point by
Google, its questionable whether it would have been
enough to push us over the edge.
FleeingtheDesktop
Looking back at how Web applications began is
an interesting exercise because it helps us under-
stand why we all jumped on board in the first
place. When Web applications started to appear,
they lacked much of the rich user interface capabili-
ties that desktop applications had. Developers, who
previously manipulated the user interface with a
high degree of accuracy, were asked to craft complex
data-centric applications on top of something that
was essentially a static content distribution system.
The stateless and detached nature of the Web added
further complications that caused developers to
design applications in an entirely new way that often
limited an applications potential.
Of course, there are a number of things that Web
applications offer in exchange for these limitations
(see Figure 1). First and foremost, simple applica-
tions are easier to prototype and build. If you just
need to collect some data and then do some basic
server processing on it, you can whip something out
fairly quickly. Displaying data in a simple table struc-
ture is equally easy. And application installation and
management is centralized. Push the application out
to a Web server and presto, everyone with a decent
Web browser can access it. If you later discover a bug
in the application you tweak the server code and
everyone will instantly be running the patched ver-
sion. Thats highly valuable.
However, while the benefits that Web applica-
tions introduce generally out weigh the handicaps
they impose, complex Web applications often find
the handicaps too restrictive. As a result, numerous
Web-friendly technologies have been introduced
over the years to break the Web application free of its
limitations.
Java applet technology is probably the most
famous of these failures. It promised desktop-like
applications for the Web, which would have been
great if it werent for the 16MB runtime environment
that must be installed on every desktop! Granted,
it was a third that size in the beginning but band-
width was also a lot scarcer. The technology was also
Dealingwiththemostdisruptivetechnologyevertohitsoftware
HowtheNetscapepromiseisf f f f f f f realized
Enterprise
EffectiveAJAXforEveryone
IncludingtheEnterprise
by Joshua Gertzen
28 January 2007
AJAx.sYs-CoN.CoM
plagued by compatibility issues between various
versions of the runtime environment and to make
matters worse different browsers would often have
different kinds of problems running them.
Some other technologies that have been
deployed along the way include ActiveX Controls,
Java Web Start, .NET Smart Client and Dynamic
HTML (DHTML). Each one of these approaches has
their own set of challenges that ultimately make
them difficult to work with in broad-scale deploy-
ments and none of them completely match the ease
of Web development. Its worth noting that although
DHTML still plays a large role in some AJAX frame-
works and toolkits, it was essentially a failed technol-
ogy until AJAX brought new life to it.
Whats important to reflect on is that none of
these add-on or alternative technologies managed
to fill the gaps in Web development in a way that
carried forward the benefits of the Web. Whats dif-
ferent about AJAX and why it matters in a way unlike
the others is that it doesnt just try to play nice with
the Web, its a true evolution of the Web in a way that
keeps the tenets of the Web alive.
PickingaHorsetoRide
Emerging technology is disruptive and the more
broadly its applied, the more disruptive it is. In
terms of AJAX, it may be the most disruptive technol-
ogy ever to hit the software world, largely because
it has the potential to reshape the most successful
technology ever the Web. The thing about a dis-
ruptive technology is that it causes the market to be
flooded with a number of different options that we
can choose from. Conceptually, the idea is straight-
forward and, as a result, many itchy developers have
jumped in and tried to solve the problem in ways
they think are unique. Right now, there are over 130
frameworks out there to choose from and even with
all those, there are still people proclaiming that AJAX
is straightforward enough to handle on your own.
This market explosion that weve seen is standard
fare for a disruptive technology and its helpful in
that it ultimately leads to a better set of solutions
in the future. The problem is that if youre trying to
determine which horse to ride right now, it can be
quite difficult to work through the options to deter-
mine what solution best fits your needs. What you
need is a buyers guide, like the kind you can get to
help you pick the best car for your needs. Something
that will break down the issues for you and out-
line the benefits of the various choices you have
available. Of course, AJAX hasnt been around long
enough for there to be a comprehensive tool thats
that straightforward. But what we do have is a study
that Gartner, the research firm, released in 2005 that
attempts to categorize different AJAX approaches
into roughly four categories (see Figure 2).
As part of the study a number of projections
were made about AJAX adoption over the next five
years. It figured that early AJAX adoption would
primarily consist of using snippets and widgets to
enhance existing Web applications but shortly there-
after applications would start to transition to Rich
Internet Application (RIA) frameworks that provide
a consolidated approach to handling browser and
server-side logic. It predicted that 60% of new appli-
cations would be based on an RIA framework by
2010. Specialized frameworks were outlined as a cus-
tom approach that should be left to very large con-
sumer-centric Web applications like Google Maps
and Yahoo Mail since the overhead of maintaining
those frameworks is quite high and the specializa-
tions are unlikely to benefit most applications.
The categories Gartner outlined werent compre-
hensive and excluded some important considerations,
but they did provide a good basis on which to start
evaluating various frameworks. The projections it out-
lined were also useful because they focus on how busi-
nesses are likely to adapt to this emerging technology.
What I think needs closer attention is why this is likely
to be the case and from that what are some of the addi-
tional considerations that have to be weighed?
TooManyHandsintheCookieJar
When you step back and look at the various lay-
ers that are involved in a modern Web application,
its actually quite remarkable that weve been as
successful as we have at constructing them. To build
a modern Web application, you have to be fairly
proficient at HTML or a derivative such as XHTML
to structure the content semantically or realisti-
cally, depending on your persuasion. CSS enters
the mix for most of your styling needs; of course
not all browsers support it equally well so you have
to fight battles here and there. Before AJAX came
along, JavaScript was commonly used in small doses
throughout an application to do things like browser
type and version checking, simple client-side data
validation or toggling the background color of fields
to indicate a conditionally required state. And thats
just the things you have to deal with in the browser.
On the server, you have to figure out how to slice
and dice the HTML/CSS and JavaScript so that it
generates a series of properly formed pages. Not
only do you typically add a server language to the
mix, its common to see a template language such as
Java Server Pages (JSP) used to help manage proper
page generation. After that you still have to deal with
inbound data thats submitted via forms, manage
the proper flow of Web pages for error and non-error
states, and determine what application state needs
to persist between pages. After addressing all of these
concerns effectively, you can focus on implementing
the actual business side of your application.
Joshua Gertzen has for the past three years
been the primary architect responsible for
designing, maintaining, and enhancing
the ThinWire Ajax Framework, which is
now open source and in production use.
Over the last six years, he has also played a
key role in building the technology infra-
structure at Custom Credit Systems.

Now lets take a look at what the traditional Web
application stack looks like after you add a client-
centric AJAX framework and some widgets; essen-
tially what Gartner defined as Level 1 and Level 2
AJAX (see Figure 3).
For starters, its important to think about the
differences in how an AJAX application works com-
pared to a traditional Web application. There are two
main differences, the client side has interactive and
responsive elements and the content on a page can
change or be loaded incrementally from the server
on-demand. To do this on top of a traditional stack,
you usually leverage a client-side AJAX framework
that tries to simplify the work involved in modifying
a page dynamically. Depending on the framework
and your needs, a set of widgets may be available as
an add-on to provide things like tree and calendar
controls. If not, its not uncommon to add a second
AJAX framework to the stack that provides the wid-
gets and visual effects.
In the traditional approach you write your appli-
cation entirely from a server-centric perspective, but
using this approach you end up splitting the develop-
ment into two separate environments: the server-side
part of the application with its state and the new
client-side part of the application that has state of its
own. The server-side part maintains many of the same
things you see in a traditional stack. You generate your
page the same way and you handle page flow and
application state in pretty much the same manner.
Sure, you have to include extra references to the client-
side frameworks and the client-side JS files you write
for the page, but doing that is pretty straightforward.
The only real difference on the server is that you
now have a set of special request handlers called end
points that you have to create to serve content to the
client-side part of the application as needed. The
end-point handlers are usually implemented like
standard request handlers, its just that they return
data and incremental content rather than a whole
page. They can be a combination of Web Services,
simple XML over HTTP, JSON data, HTML frag-
ments, or any other form of content that the client-
side part of your application is designed to handle.
On the client side, the story is completely differ-
ent. AJAX wrestles parts of the user interface away
from the servers control and plants it firmly on
the client side. The more AJAX-ified you make your
application user interface, the more control you end
up wrestling away from the server. Ultimately, this
drives the complexity of the client-side JavaScript
well beyond the basic data validation that youve
used it for in the past. It usually starts out simple.
You add a couple asynchronous calls to the server
to populate a dropdown, hide a couple fields on the
screen when a user chooses yes or no, integrate a
grid control that populates with search results when
a user enters some criteria, but before long you end
up in a situation where youre writing large portions
of your application in JavaScript.
As a result, you can no longer treat JavaScript as
a toy language; you have to treat it as a first-class
citizen in your development efforts. A debugging
strategy that works across multiple languages and
execution environments has to be worked out and
you have to start structuring your client-side code
like you would your server-side code so that its read-
able and maintainable. However, suddenly treating
JavaScript as a first-class language and adding it to
Figure 3: Adding Ajax to the Traditional Stack
Figure 4: Simplified Ajax Development with ThinWire
Figure 1: Some Benefits and Negatives of Web Applications
Figure 2: Gartners Four Levels of Ajax Usage
30 January 2007
AJAx.sYs-CoN.CoM
the mix of all the things that you have to manage in
an AJAX application can be cumbersome.
Overall, dealing with the complexity that AJAX
brings to the crowded Web development stack is one
of the biggest hurdles facing anyone looking to adopt
the technology. Architected carefully, you can scale
this approach up to some very large applications. You
just have to do a lot of bookkeeping and testing to
make sure everything works correctly and performs as
expected. Cutting through all that bookkeeping and
simplifying the development stack is what a Level 4
framework such as ThinWire is all about.
MorethanOneWaytoSkinaCat
The Rich Internet Application (RIA) term has techni-
cally been around for quite sometime. A few years back,
different companies made a go at creating sophisti-
cated RIA frameworks on top of technologies such as
Java applets, ActiveX and Flash. For many of the reasons
that I outlined at the top of this article, none of those
approaches ever panned out. Today when we talk about
RIA frameworks, its usually in terms of RIA frameworks
that use AJAX techniques to provide the rich applica-
tion experience. Generally speaking, the goal of an RIA
framework is to provide a simplified Web development
platform that you can use to construct highly interactive
and responsive user interfaces. Different frameworks
approach this goal in unique ways that offer varying
benefits. Im going to use the ThinWire framework to
demonstrate some of the benefits you can gain by using
an RIA framework because as the architect I know it
the best. While my descriptions are not entirely general,
conceptually they can be applied to approaches taken by
other frameworks.
For those of you who havent heard of ThinWire,
its an open source development platform that lets
you easily build applications for the Web that have
responsive, expressive, and interactive user inter-
faces without the complexity of the alternatives. To
show you what I mean, take a look at the layers that
make up a ThinWire application (see Figure 4).
Notice how theres no mention of the Web brows-
er. In a typical ThinWire application, you never write
any HTML, CSS, or client-side JavaScript code for
anything. A ThinWire application is constructed
entirely on the server side, using primarily a single
language on top of an event-driven component
model. That single server-side language is usually
Java, but it can also be any scripting language that
runs on top of Java such as Jython or JRuby. And,
since you get to wipe your hands clean of the Web
browser side of things, the framework can focus on
optimizing the communication and rendering in a
way thats generally more efficient than what you
could do by hand. And as we add more intelligence
to the frameworks predictive routines, your applica-
tion can leverage those improvements without you
having to change any code.
Further benefits to this approach become clear
when you look at how this simplifies the develop-
ment and debugging cycle. With ThinWire, you can
use your existing Java debugger to walk through
any part of your application. Essentially there are
only two possible failure points. Either your server-
side code has a glitch or the framework version
youre using has a glitch. And since the framework
is already in production use at a top-10 U.S. bank,
its been proven out quite significantly. Therefore, in
most cases you can be confident looking strictly at
your server-side code.
The steps for constructing a rich application in
ThinWire are straightforward. You construct your user
interface components and position them on the screen
using either exact positioning or one of the layout man-
agement approaches included in the framework. Then
you add event listeners to the components on which
you want to be notified of a user action. For example,
you might listen for a checkbox to have its checked
property changed or listen for a click action to occur
on a button. Once you have your event listeners tacked
on, you simply write the code for whats supposed to
happen when the event youre listening for occurs.
So, for instance, when the checked state changes,
you might show or hide a set of fields on the screen
by toggling their visible property. After youve written
the code, just configure the Web.xml so it points to the
entry point of your application and start up the server.
The framework will handle the rest.

TheRightToolfortheJob
For all the great things that AJAX adds to the Web
developers toolbox, it can also add layers of complex-
ity to a Web development stack that is already burst-
ing at the seams. The difficultly in choosing the right
AJAX development framework for your needs is com-
plicated by the large number of options that are cur-
rently available. Understanding the four levels of AJAX
frameworks that Gartner has identified can help you
make a better decision. However, you must ultimately
align your applications needs with the capabilities of
the framework you use, so make sure you understand
both your near-term and long-term needs.
While a Level 4 RIA framework like ThinWire can
simplify the development effort required to build
an effective AJAX application, your application may
have specific needs that a Level 1 or 2 framework
addresses more effectively. In the end, AJAX is about
creating better applications that engage the user in
a way that Web applications fell short. Back when
Netscape was still king of the Web and Navigator was
all that mattered, there were many discussions about
how a Web application would be dynamic, interac-
tive, and visually compelling. After all these years,
AJAX has arrived to finally make it a reality. n
W
hat we need is a Web browser that doesnt
just serve up documents, but serves up
applications.
Early in 2006 I was given a design brief: a UK-
based shipping company wanted to replace its ship-
ment tracking system with a Web-based solution.
Its existing system consisted of this: each widget
grower had a contract with the widget producer; this
contract was tracked via an Excel spreadsheet; every
Friday the shipping company would e-mail the lat-
est copy of the spreadsheet to the widget grower,
which would fill out the details of the latest shipment
and the details of each and every container in that
shipment. This would then be passed back to the
shipper, which would then forward it to the widget
producer, which in turn would fill out the produc-
tion usage, quality control results, and the dates
and times of when each container load had
been used. They would forward it back to the
shipper and the cycle would continue. Add
in the two separate ports and warehouses
in the U.K. and about 16 contracts with dif-
ferent widget growers in countries as far
away as Brazil and South Korea, and you
start to see that keeping track of the lat-
est version of each spreadsheet, where
it is, and what is happening to it was
beginning to become something of a
mission unto itself.
This is where I came in. The
simplest Web-based solution
to this would be an online
document store in
which the wid-
get growers, shippers, and producers could just log
in, check out a spreadsheet, edit it, and check it back
in. Instead we landed on the Web 2.0 solution: a
truly online spreadsheet, tailored exactly to the task
at hand, with permissions set on data fields (so that
a widget grower couldnt cheekily amend the widget
producers own quality-control results, for example).
The whole thing would be in real-time and delivered
through Internet Explorer.
This is the sort of real-world application develop-
ment leveraging the Internet that goes unnoticed by
the photo-sharing, music-downloading, blogging
masses. In the same way that the largest fraction
of software developed and deployed in the world
is internal business software, not games and file-
sharing clients. As such I had an advantage; this
wasnt to be some Microsoft Office Excel killer, it
was a tailored, targeted,
bespoke application
that would look a bit
like a spreadsheet
but behave exactly
like a widget-grow-
Willbrowserseverdeliverapplications
insteadofdocuments?
speculations
BeyondHTTP
by Ric Hardacre
32 January 2007
AJAx.sYs-CoN.CoM
ing, shipping and production tracking application.
After several months of meetings, prototypes,
and endless hours of debugging, the final product
was rolled out this summer. The client is happy; their
clients are happy; it works exactly as designed; it can
export to Excel; you can copy and paste in and out;
and it works on IE6, IE7, and Firefox 1.5. I collected
my paycheck and theyve been using it without any
problems ever since.
It does, however, contain over 2,000 lines of
JavaScript, and the spreadsheet view is an HTML
table, with HTML embedded links and images to
power said JavaScript. The rows are inserted via the
DOM and to edit a cell in a particular row the script
has to copy the data from the table row into a faked-
up hidden edit row containing text boxes using
CSS thats hacked to pieces and swapped with the
original row. The Save button at the top left of the
application cycles through every table row on the
page, checking against a bunch of custom attributes
slapped into each TR tag to decide if the row needs
deleting, updating, or inserting to the database. It
builds XMLHttpRequest objects and loads them with
a custom CSV-style mashup of data to be sent to the
server, which in turn sends a similar mashup back,
so that the data on the screen can be kept in sync
with the data in the databaseon the other side of
the planet.
I find myself in a bizarre position. The fact that
Im an expert in this kind of thing and have the
technical know-how and aptitude to design and pull
off such a complex beast on time and as designed
means that I got paid quite well for the six months
it took to develop, and Ill continue to get paid as
and when upgrades are needed. If any old John Doe
could have opened up Visual Studio and slapped it
together then I probably wouldnt find myself getting
paid quite so much for my services. But the thing is it
really could be that easy, or at least, close to it.
Instead of a dedicated platform for develop-
ing Web-based applications we have HTML, the
DOM, JavaScript and the funderful XMLHttpRequest
object. Instead of declaring a pair of <DATAGRID>
tags in HTML, I frankly had to hack the %$#@ out
of a <TABLE>, normally a static read-only piece of
a static read-only document. Compare the Visual
Studio .NET Windows Datagrid with its Web-based
counterpart. Theres no comparison: a confident
user of the former wouldnt immediately be able to
even recognize the latter.
Finally we get to the rub: The document-based
Web as we know it is not a platform for developing
complex applications; sure its possible and there
are plenty of bright people working at places like
Google who are doing it as we speak and creating
frameworks to make it easier. But is this really the
way forward? A tree-based object model accessed by
an interpreted scripting engine tacked onto a speci-
fication designed for static read-only documents?
Now would be a really good time in history to stop,
step back, and look at what we have and what could
be done better. What we need is a Web browser that
doesnt just server up documents, but serves up appli-
cations: full screen native GUI, network-transpar-
ent and, most important, fast, lightweight, real-time
applications. Ideally wed want to start over, build a
whole new spec running on an entirely new platform
and set of protocols. Its unlikely to be that easy. Java
promised us Internet-based apps, but spectacularly
failed to deliver anything other than mobile phone
shoot-em-ups. Flash is only just beginning to be
taken seriously, and may yet mature into something
business can use to track its widgets. Lets take a
moment to dream about what we could have.
First, it would be easy to write for with a choice of
languages the current request-response framework
of the Web can be catered to by PHP, CGI, and ASP
to name just three. Write your app in one and you
get to access the posts, gets, and cookies natively.
So it should expand on that and have a native client
object alongside the server object so an author can
simply call:
client.Document.Forms[someForm].txtSomeInput.value
= hello from the server
And have the asynchronous action happen with-
out any extra effort. And the reverse should be true:
the script in the browser should be able to asynchro-
nously call server functions like this:
function btnMyButtonOnClick()
{
doSomething();
server.doSomethingWithTheDB( gsFavouriteColor );
doSomethingElse();
}
Again, the legwork would be done for you; a new-
bie programmer would be able to create something
like this in no time, but true enlightenment wouldnt
be needed. Custom objects and classes should also
be transparently handled across the network, but we
dont want to belabor the author with XML and SOAP,
it should just happen.
Second, it should have state, and that state should
begin by initializing the applications main source
file on the server when the client first connects. The
application would maintain state between calls,
allowing the use of global variables and custom
classes that persist. Calling an async function from
the client would begin a thread on the server app,
but the advanced programmer could, if he wished,
have power over this too and create a call stack, for
Ric Hardacre discovered the Web in the mid
90s when he really should have been at
lectures and not in the University comput-
er lab. Hes since worked as a Web solutions
developer, systems architect, and wireless
and satellite network specialist. His cur-
rent day job is as an MCP C# Developer
in the UK.
example, to force events to occur in the order they
were sent from the client (not necessarily the order
they arrived). Finally, unlike the current Web meth-
odology, there should be a clear disconnect event
sent when the user closes the window or a connec-
tion stay-alive ping times out.
Thirdly, each user of the app would get his own
instance on the server, but these instances would be
able to access the Master Application that contains
them all, and all its public functions and classes.
A chat application, for example, would be able to
access the channel list with just a call to application.
fetchChannelList(). And to pull up the details of
another connected user with application.getUser-
DetailStruct( intUserID ).
Finally, the author wouldnt be forced into using
the current HTML DOM and its small inflexible set
of user input controls. There should be a much wider
range of inputs, controls, panels, and widgets and has
a native grid-based layout system. I keep mentioning
the MS Datagrid over and over but imagine being able
to create a small spreadsheet object in just a few lines
of code and let the user add, insert, remove, and edit
rows and columns in the comfort of his own native
GUI. This object wouldnt need serializing and send-
ing to the server as far as the author is concerned,
pressing submit would give the server a mirrored
copy of the control, with full access to its innards.
Such a thing is possible, and we need it sooner
rather than later. It would seem simplest to treat the
project in two halves. The first half of the challenge
is to integrate the new user controls where possible
within the existing Web framework. The WHATWG
Web Forms 2 and HTML 5 spec are already headed
down this road, with such simple but badly needed
inclusions as date and time inputs with in-built
validation. The second half needs a paradigm shift,
a move away from the top-heavy and stateless HTTP
protocol to a true lightweight binary client/server
relationship between the user and the application.
The thing is a lot of the inherent problems in such
an approach have already been solved: Connectivity
and synchronicity over a slow or unreliable connec-
tion? IDs Quake addressed this 10 years ago and
so too has almost every FPS since. Cross-platform
compatibility and interaction? Any number of file-
sharing and chat applications will yield the answer
to that one. All it takes is the will to step away from
the Web browser and start something new. As a final
thought it might be worth noting that for 20 years
now the X Windows system has allowed the develop-
ment of applications that can transparently display
their GUI on one computer while doing the actual
processing on a server somewhere elseprobably
the other side of the planet. Sound familiar? n
ric.hardacre@cyclomedia.co.uk
Thedocument-based
Webaswe
knowitisnot
aplatform
fordeveloping
complex
applications
34 January 2007
AJAx.sYs-CoN.CoM
JackBes Rich Enterprise Application (REA) platform
clears the road to SOA business benefits.
Theres 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 websitelet us help you remove the barriers on the road to achieving real
business value from your SOA investment.
Facing a few barriers
on the road to SOA?
Web: www.jackbe.com
Phone: (240) 744-7620
Email: info@jackbe.com
Optimizing Business Activity
T
heres a common misconception among
many end users, consumers, and developers
that AJAX is the ultimate solution for the Web
and that it can provide all the same functionality as
a rich desktop solution. Sure, AJAX can cover most
of our expectations for a rich client, mimicking
functionality provided by a desktop application, but
theres still one area that has yet to be fully integrated
scalable server-initiated message delivery.
With server-initiated message delivery, all end
users of a particular application are simultaneously
notified of any changes to the application state, e.g.,
at the stock exchange a stock is dropping fast and the
trading application has to inform all traders about
the sudden change in price.
Server-InitiatedMessageDelivery
Lets use the trading application as an example
for server-initiated message delivery. Each broker
has his own preferences in stocks and bonds and
requires instant notification of changes in the mar-
ket. A desktop client for a distributed enterprise
application typically registers interest in specific
kinds of server messages so the server can notify the
desktop client when they occur. This lets the desktop
application efficiently use the network on a need-to-
know basis instead of having the client actively ask
for information.
This approach wont work for a traditional Web-
based AJAX application since the server cant initi-
ate a direct connection to the browser because of
browser security, firewalls, and Web proxies.
Sure, its possible with AJAX to notify a Web cli-
ent that a change has occurred on the server using a
technique called polling. By creating a Web appli-
cation that polls every now and then the end user
believes that hes been notified by the server, when in
fact its repeatedly asking for updates like any child
asking for candy Can I get it now? Can I get it now?
Can I get it now? You get the picture.
Of course, this impacts network bandwidth since
theres traffic for each polling request even when no
updates are available from the server. We need a way
for Web clients to register interest in certain types of
messages and then let the server initiate delivery of
those messages, pushing them to each browser.
TheresaTwist
OK, OK, OK, there is a twist you cant actually
push messages to a Web-based AJAX application
unless you maintain an open connection from the
client to the server. However, a thread is kept alive on
the server for each open connection so messages can
be delivered to the browser immediately.
The fact that youd even try to maintain an open
connection per user to a server would have heads
rolling down the corridors in most IT departments.
Just imagine thousands, or even hundreds of thou-
sands of connections, using the thread and process
pooling models provided by most Web Servers today,
keeping each thread alive on the server just to be
able to send a message to the client it doesnt scale!
Lets come back to that one later.
Therealdeal
Web
EnterpriseComet:
AwakentheGrizzly!
by Jonas Jacobi
& John Fallows
36 January 2007
AJAx.sYs-CoN.CoM
HTTPConnectionLimitations
Today most frameworks leveraging AJAX are
using the XMLHttpRequest object, which allocates
an HTTP connection for the duration of the request.
The HTTP 1.1 specification recommends that brows-
ers support a maximum of two open connections
to the hosting server. This presents a problem for
highly interactive AJAX Web applications, especially
on Microsoft Internet Explorer, which enforces this
recommendation.
If there are more than two AJAX frameworks
or components using the XMLHttpRequest on the
same Web page then there will probably be conten-
tion for the two open connections, causing requests
to queue. The result will be blocked and ineffective
communication, defeating the main purpose of hav-
ing AJAX on the Web page. Theres a need to share
server communications over two HTTP connections
at most.
Next-GenerationWebCommunication
The main reason a Web server allocates one
thread per connection is because it expects the
request to be highly active and short-lived. However,
maintaining an open connection to the server is
extremely long-lived and activity is mostly dormant.
We also need a way to meaningfully share server
communications to address the browser connection
limit. Thankfully, there are several projects in pro-
cess addressing the limitations of traditional AJAX
Web applications. Lets have a look at some of these
projects.
Comet-TheNever-EndingRequest
First we need a way to create message-driven
Web applications that require the server to notify the
client about server-side events. This is where Comet
comes in as described by Wikipedia:
Comet is a programming technique that enables
Web servers to send data to the client without having
any need for the client to request it.
Comet provides the means for the server to ini-
tiate a response to a client request, and later send
a message to that client using the same response
for example, in the browser a message will just
appear. Comet also provides clients with a way to
register interest in specific types of messages. When
the server publishes a message, its delivered only to
clients that previously registered interest in that kind
of message.
Comet doesnt solve everything; in fact it creates
some new problems. Using Comet means lots of out-
standing requests, ideally one per client, and intro-
duces similar scalability issues at the server as the
AJAX polling technique. Keeping a separate thread
allocated for each open request will exhaust the
servers resources, so for this model to work properly,
the Web server has to handle multiple requests with-
out allocating one thread per request.
AsynchronousRequestProcessing
The idea behind Asynchronous Request
Processing (ARP) is to manage incoming servlet
requests asynchronously. Rather than committing a
separate Java thread to synchronously process each
servlet request, a single thread leverages Java NIO to
detect when new information needs to be written to
the response of any outstanding request. This tech-
nique provides a huge scalability win for the Comet
use case, giving excellent performance even when
there are a large number of outstanding, mostly dor-
mant, requests at the server.
Although theres no standard defined for ARP sev-
eral teams and projects are providing ARP solutions,
such as Jetty Continuations and Grizzly. We take our
hats off to these visionary teams providing everyday
developers with ARP and Comet solutions.
Note: Theres hope that ARP will be standard in
the Servlet 3.0 and Java EE 6 specifications.
TheCometMessagingProtocol
With Comet and ARP we now have the means to
build message-driven Web applications but, as men-
tioned earlier, W3C recommends at most two active
connections from the browser to the Web server at
any one time. Therefore, wed prefer to have a single
active connection being used for Comet notifica-
tions, leaving the other connection free to download
images, CSS, and JavaScript or communicate with
the server. This requires a way to manage multiple
logical channels of information over a single shared
Comet notification response.
The Bayeux protocol, named for the Bayeux
Tapestry with its picture of Halleys comet, provides
a solution to this problem. Bayeux formalizes the
exact protocol that clients should use to initiate the
Comet connection and subscribe and unsubscribe
from hierarchically named Bayeux channels.
/stocks
/stocks/ORCL
/stocks/MSFT
/bonds
When a message is delivered to a channel at the
server, its only published to those clients that have
previously subscribed to that channel. Due to the
hierarchical naming scheme, messages sent to a
channel named /stocks/ORCL will also be delivered
to clients subscribed to the /stocks channel.
DojoandBayeux
The Bayeux protocol is an effort by the Dojo
Foundation to simplify the use of Comet. Bayeux
Jonas Jacobi is VP of Product Management
& a Brane Surgeon at Brane Corporation,
a new startup company based in Redwood
City, California. A native of Sweden, Jonas
has worked in the software industry for
more than fifteen years. For the past eight
years, he has been working for Oracle as
a Java EE and open source Evangelist,
and product manager responsible for the
product management of JavaServer Faces,
Oracle ADF Faces, and Oracle ADF Faces
Rich Client in the Oracle JDeveloper team.
He is a popular speaker at international
conferences and has written numerous
articles for leading IT magazines such
as Java Developers Journal, JavaPro,
AjaxWorld, and Oracle Magazine. Jonas is
co-author of the recently published book
Pro JSF and Ajax: Building Rich Internet
Components , (Apress).
John Fallows is an Architect & a Brane
Surgeon at Brane Corporation, a new
startup company based in Redwood
City, California. Originally from Norther
Ireland, John graduated from Cambridge
University in the United Kingdom and has
worked in the software industry for more
than ten years. Prior to joining Brane, John
was a Consulting Member of Technical
Staff for Server Technologies at Oracle
Corporation. During his last 5 years at
Oracle, John focused on designing, devel-
oping, and evolving Oracle ADF Faces to
fully integrate Ajax technologies. John is a
popular speaker at international confer-
ences and has written numerous articles
for leading IT magazines such as Java
Developers Journal, AjaxWorld Magazine,
and JavaMagazine (DE). John is co-author
of the recently published book Pro JSF and
Ajax: Building Rich Internet Components
, (Apress).
development is hosted as a sibling project to the
Dojo Toolkit, which already includes client-side
Bayeux support in JavaScript.
OK, we might be jumping ahead here, but we feel
that Bayeux is likely to become the de facto stan-
dard for Comet messaging because the Dojo Toolkit
has gotten tremendous backing from the developer
community and because the protocol is language-
neutral. Bayeux has a pluggable transport layer so
any agreed wire syntax can be used to marshal mes-
sages between the client and server, or vice versa
and there are already implementations in multiple
languages.
ARPandCometArchitecture
Our sample solution, the trading application,
requires sophisticated integration with external
business systems, such as business services updat-
ing the stock prices.
TheTradingApplication
Our message-driven distributed enterprise appli-
cation needs an ARP solution for the Web client, so
were going to use Grizzly as our server-side ARP and
Comet runtime implementation. Grizzly provides
ARP support in Java and is currently snoozing under
the covers of Project Glassfish, version 2. (http://
glassfish.dev.java.net).
For our sample application we also used the
Dojo Toolkit (http://dojotoolkit.org/), which
already includes client-side Bayeux support in
JavaScript.
Note: When this was written, there was no server-
side Bayeux protocol support in Grizzly so for this
article we used our own Bayeux servlet. We intend to
convert this to a Bayeux weblet and make it available
for download from the Weblets Project (http://web-
lets.dev.java.net).
Well use a simple UI to demonstrate the trad-
ing applications server-initiated message-delivery
mechanism. The UI contains three buttons each
capable of initiating a request to publish a stock
price update message. The server will immediately
notify all end users who subscribed to the same
stock. The page source for this simple trading appli-
cation is in Listing 1.
The page contains standard Dojo Toolkit ini-
tialization via the dojo.js library and imported the
required Dojo packages for dojo.io.cometd and dojo.
event.topic:
function setupComet() {
cometd.init({}, /comet-war/bayeux);
cometd.subscribe(/stocks);
dojo.event.topic.subscribe(/cometd/stocks/
ORCL,onStockUpdate);
dojo.event.topic.subscribe(/cometd/stocks/
SUNW,onStockUpdate);
}
When the page loads, we initialize the Dojo
cometd support with the URL to the BayeuxServlet,
/comet-war/bayeux. In this sample we then
subscribe directly to the /stocks Bayeux chan-
nel, as well as the local event topics /cometd/
stocks/ORCL and /cometd/stocks/SUNW.
These two local event topic subscriptions could
easily be done by the end user after the applica-
tion is launched, but for now we can treat them as
default subscriptions.
Lets have a look at the three buttons; each one
in the body is configured to publish an event to a
specific Bayeux channel at the server:
<button onclick=cometd.publish(/stocks/
ORCL,
{name:ORCL, price:
19.75}); >SUNW 19.75
</button>
When a message is published to the server on a
Bayeux channel, such as /stocks/ORCL, then its
delivered to all clients subscribed to the /stocks/
ORCL channel or the /stocks channel. If a mes-
sage is sent to /bonds then its delivered to all clients
subscribed to /bonds. In this example, the trading
Figure 1:
Figure 2:
38 January 2007
AJAx.sYs-CoN.CoM
i: www.backbase.com t: (866) 800-8996 e: sales-us@backbase.com
Backbase BV - all rights reserved. BACKBASE is a trademark of Backbase BV.
AJAX for Java
Backbase ofers a comprehensive AJAX
Development Framework for building Rich Internet
Applications that have the same richness and
productivity as desktop applications.
The Backbase AJAX JSF & Struts Editions:
are based on JavaServer Faces (JSF) or Struts/JSP
run in all major Application Server
support development, debugging and deployment in Eclipse
embrace web standards (HTML, CSS, XML, XSLT)
Download a 30-day Trial at www.backbase.com/jsf
application only gets messages for /stocks. This

server-side filtering ensures that unwanted mes-
sages arent sent to clients.
When a message is delivered to a client, the
Dojo event system delivers it to any locally reg-
istered subscribers in the page. By default, local
event topics are named by prefixing the Bayeux
channel name with /cometd. For example, if
a message is received from the server via the
Bayeux channel /stocks/ORCL then its pub-
lished to local subscribers using the topic name
/cometd/stocks/ORCL. Local event topic sub-
scription is shown in the setupComet() JavaScript
function:
dojo.event.topic.subscribe(/cometd/stocks/ORCL,
onStockUpdate);
dojo.event.topic.subscribe(/cometd/stocks/SUNW,
onStockUpdate);
}
Figure 1 shows two clients running the code used
in the page source sample.
In the second set of screen shots shown in Figure
2 weve clicked on all three buttons in the application
running in Firefox and since were using Comet this
causes both clients to be updated with new informa-
tion.
As you can see, there are only two messages
displayed in each client. The Dojo event system
delivers the messages to the locally registered
subscribers in the page. In this case Microsofts
stock hasnt been displayed because we didnt
subscribe to /cometd/stocks/MSFT locally.
Notably, if we changed the cometd subscrip-
tion from /stocks to /stocks/ORCL and /stocks/
SUNW then the observed behavior would be the
same, but the /stocks/MSFT message would be
filtered at the server, not locally at the brows-
er.
TheInternalProcess
The Grizzly Comet implementation provides a
CometEngine thats used to create a CometContext
to which clients can register a handler. The handler
is responsible for initiating the response and notify-
ing each client about new messages that match the
clients channel subscriptions. All handlers regis-
tered to the same CometContext will be simultane-
ously notified when a new event is delivered to the
CometContext.
In our trading application, all Bayeux requests go
to a BayeuxServlet at /bayeux in a Web application
with context root /comet-war.
1. Initial Request
This is a regular request to have the page ren-
dered in the Web client, HTML, and Dojo Toolkit
JavaScript including Bayeux protocol support.
2. Bayeux Handshake Request
In our trading application Bayeux lets us cre-
ate one channel per stock. Were still only using
one HTTP connection and we can use Bayeux to
listen for events targeting a particular area of our
application in this case a stock. If we didnt have
Bayeux wed either have to invent our own publish
and subscribe protocol, or else go back to polling
the server because the browser connection limita-
tions would prevent us from having more than two
open HTTP connections to get the Comet notifica-
tions.
Request URI = /comet-war/bayeux
Request Payload = handshake message
The Bayeux handshake request sends a message
to the /meta/handshake channel to indicate pos-
sible connection types and gets a response from the
server indicating supported connection types, their
recommended configuration, and a client identifier
thats used for subsequent communication with the
BayeuxServlet. In this case we use an iframe connec-
tion type.
3. Bayeux Connect Request
Since were using an ARP server each request
will register a key containing information about the
request. This will let the ARP release resources by
releasing threads currently not used.
Request Payload = connect message
It sends a message to /meta/connect channel to
begin the long-lived Comet request. Using Grizzly
APIs from within the BayeuxServlet, the connect
request causes the client-specific CometHandler
to be registered with this trading applications
CometContext.
If the server-side CometHandler times out while
the trading application is still active, the client sends
a Bayeux reconnect request to establish a new long-
lived Comet notification request.
4. Bayeux Subscribe Request
In our application we subscribe to the /stocks
channel to get browser notifications for all
stocks.
Request Payload = subscribe message
40 January 2007
AJAx.sYs-CoN.CoM
The Bayeux subscribe request sends a message to
the /meta/subscribe channel, subscribing the client
to the /stocks channel. Using Grizzly APIs from with-
in the BayeuxServlet, each subscribe request causes
the list of per-client subscriptions to be updated for
this CometContext. If the long-lived connect request
is still open then this subscribe request is sent to the
server using the remaining available browser con-
nection.
5. ORCL Stock Price Changes
The Oracle stock price changes and a message
is published to the /stocks/ORCL Bayeux chan-
nel with an application-defined structure, e.g., {
name:ORCL, price: 19.75 }.
Using Grizzly, we get a CometContext for this
application and send a message including chan-
nel name. All CometHandlers registered for this
CometContext will get this message, but only those
subscribed to the /stocks/ORCL or /stocks channel
will actually propagate the message to the browser.
If the long-lived connect request is still open then
this unsubscribe request is sent to the server using
the remaining available browser connection.
6. Bayeux Unsubscribe Request
Theres also a way to unsubscribe from chan-
nels and with a more sophisticated trading appli-
cation the end user would be able to unsubscribe
from getting updates for a stock, for example, Sun
Microsystems (SUNW).
Request Payload = unsubscribe message
A message would be sent to the /meta/unsub-
scribe channel, to unsubscribe from /stocks/
SUNW channel. Using Grizzly APIs from within the
BayeuxServlet, the unsubscribe request updates the
list of subscribed channels for this client on this
CometContext.
Conclusion
Enterprise Comet is definitely the real deal.
Theres still work to be done before we have a com-
plete Enterprise solution for developing message-
driven Web 2.0 applications, but with the techniques
and technologies above weve made a good start.
Not only that, but the Dojo Toolkit also includes a
rich set of DHTML widgets, and client-side Bayeux
protocol support, which provides a great foundation
for building Comet-based Web applications.
The major thing missing now is a way to realize
Comet in the context of Java EE for technologies
such as JSF, JMS, and EJB 3. More about this in our
next article, which will show how to create a Comet-
based JavaServer Faces component. n
Listing1
<!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN>
<html>
<head>
<title>Cometd Bayeux Example</title>
<script type=text/javascript src=dojo/dojo.js ></script>
<script type=text/javascript >
dojo.require(dojo.io.cometd);
dojo.require(dojo.event.topic);

dojo.event.topic.subscribe(/cometd/stocks/ORCL,
onStockUpdate);
dojo.event.topic.subscribe(/cometd/stocks/SUNW,
onStockUpdate);
}
function onStockUpdate(message) {
var stock = message.data;
dojo.hostenv.println(stock.name + is now valued at +
stock.price);
}

dojo.addOnLoad(setupComet);
</script>
</head>
<body>
<div>
<button onclick=cometd.publish(/stocks/ORCL,
{name:ORCL, price:19.75}); >ORCL 19.75
</button>
</div>
<div>
<button onclick=cometd.publish(/stocks/MSFT,
{name:MSFT, price:41.16}); >MSFT 41.16
</button>
</div>
<div>
<button onclick=cometd.publish(/stocks/SUNW,
{name:SUNW, price:21.37}); >SUNW 21.37
</button>
</div>
</body>
</html>
Reference Material:
Jean-Francois Arcands blog about Grizzly - http://weblogs.java.net/blog/jfar-
cand/
Alex Russells blog about Bayeux and Comet - http://alex.dojotoolkit.org/
Greg Wilkins http://blogs.webtide.com/gregw/
Project Cometd http://cometd.com/
Project Glassfish http://glassfish.dev.java.net/
Project Weblets http://weblets.dev.java.net/
R
eal-time 3D is emerging as a first-class
media type for the Web. Network bandwidth
and graphics hardware processing power
are now sufficiently advanced to enable compelling
Web-based 3D experiences, including games, online
virtual worlds, simulations, education, and training.
Commercial developers are expressing increasing
interest in exploiting real-time 3D in Web applica-
tions to enhance production values, create engaging
immersive experiences, and deliver information in a
more meaningful way.
Much of the infrastructure is in place to enable
professional Web 3D deployment in a cross-platform,
open, royalty-free environment. Interoperability
standards such as ISO-standard Extensible 3D
Graphics (X3D) are now mature, fully functional,
and robust and supported by multiple open source
implementations and affordable production pipe-
lines. However, those technologies only go so far
in that they are focused on the transportability of
embedded rich content, and not on the applications
that embed it. The industry is in need of a rapid
development environment for creating scalable,
highly interactive client/server 3D applications on
the Web.
AJAX Asynchronous JavaScript and XML has
emerged as a preferred method for developing
sophisticated Web applications. AJAX makes client/
server programming available to JavaScript develop-
ers via Dynamic HTML, resulting in rich, responsive
applications hosted in a Web browser. While AJAX is
being used to deploy some of the industrys leading
applications, such as Google Maps and Netflix, cur-
rent browsers are limited in their capacity to render
dynamic content, in particular, high-performance
real-time 3D.
AJAX3D combines the power of X3D, the stan-
dard for real-time 3D on the Web, with the ease of
use and ubiquity of AJAX. AJAX3D employs the X3D
Scene Access Interface (SAI) the X3D equivalent of
the DOM to control 3D worlds via JavaScript. With
the simple addition of an X3D plug-in to todays Web
browsers, we can bring the awesome power of video
game technology to the everyday Web experience.
The initial development has begun. Media
Machines has created the first showcase applica-
tions and tutorials, and has launched a Web site
(www.ajax3d.org) as an open industry forum to
explore technologies, techniques, and best practices.
This article describes the key technical concepts
behind AJAX3D and, via examples, introduces the
beginnings of a formal programming framework for
general use.
AJAX3DBasics
AJAX3D is based on the integration of two pro-
gramming models: the W3C Document Object Model
(DOM) and the ISO Scene Access Interface (SAI).
The DOM defines a model for programs interacting
with a Web document; the SAI allows programs to
control X3D scenes. JavaScript code running on a
Web page can interact with the DOM and the SAI
simultaneously, enabling applications that integrate
traditional 2D Web page elements with the 3D world.
Both the DOM and SAI are independent of any pro-
gramming language; however, our focus for AJAX3D
is on JavaScript.
One DOM object is of particular interest to AJAX
programmers: the XMLHttpRequest object, which
allows a Web application to make server requests
without requiring that the contents of the page be
refreshed. This capability is fundamental for creat-
ing dynamic, responsive applications that meet the
expectations of todays consumers. The SAI has a
similar capacity in createX3DFromURL, a method of
the X3D browser object that loads 3D content on
demand.
The combination of the DOM, SAI, and
XMLHttpRequest comprise the underpinnings of
AJAX3D and, in fact, suggest a precise definition
of AJAX3D, where an AJAX3D application is a Web
browser-hosted program that:
Uses the SAI to access a real-time 3D scene
Uses the DOM to manipulate Web page content in
response to changes in the 3D scene
Uses server-request methods (XMLHttpRequest,
createX3DFromURL) to store and retrieve data in
response to, and/or leading to, changes in a 3D
scene.
EmbeddingX3DScenesinaWebBrowser
The first step in creating an AJAX3D application
is to create an HTML page that embeds X3D content.
Theopenplatformforrich3DWebapplications
3D
AJAX3D
by Tony Parisi
42 January 2007
AJAx.sYs-CoN.CoM
This is done using EMBED or OBJECT tags (the for-
mer being well supported in all Web browsers):
<embed WIDTH=640 HEIGHT=480 NAME=FLUX
SRC=helloajax3d.x3d TYPE=model/x3d DASHBOARD=0
BGCOLOR=0xFFFFFF>
Note: all examples in this document use Media
Machines FLUX Player as the X3D plug-in. However
any SAI-compliant X3D plug-in that supports
JavaScript should be able to support AJAX3D.
AccessingtheX3DScenefromJavaScript
Once the X3D plug-in has been embedded, it
can be accessed from JavaScript like any other DOM
object. The FLUX object is used to access the SAI
browser object not to be confused with the Web
browser, which is the main object defined by the
SAI for connecting to the 3D scene. The browser is
accessed as follows:
var browser = document.FLUX.getBrowser();
Once we have a handle on the X3D browser, we
can access the ExecutionContext object, which lets
us access all of the live objects in the scene
to retrieve and change properties, or send
and receive events:
var context = browser.getExecutionCon-
text();
WorkingwiththeX3DSceneGraph
The primary data structure in an X3D world is
the scene graph or a collection of graphical objects
organized in hierarchical relationships. The scene
graph is akin to a DOM document in that its struc-
tured data representing the rendered content; how-
ever. 3D scene graphics tend to be far more complex
than even the richest DOM documents.
The SAI provides a few ways to access the scene
graph. Once a valid execution context is obtained
(see above), we can either ask it for an object by
name, or a collection of all the top-level nodes in the
scene as follows:
var theText = context.getNode(THETEXT);
or:
var nodes = context.getRootNodes();
The scene graph is hierarchical, but its not a
strict tree like a DOM document. Objects in the
scene graph can have multiple parents so long as
no object is a descendant of itself either directly or
indirectly. The technical term for this structure is
a Directed Acyclic Graph or DAG hence the term
scene graph. Many operations on the X3D scene
graph require knowledge of this structure so its
important to understand this concept early on.
Nodes,Fields,andEvents
The fundamental object type in X3D is the node.
Nodes are scene graph elements; they can represent
geometric shapes, their visual properties, animations,
scripts that contain program code, clickable behav-
iors, and so on. The properties of nodes are called
fields; fields store basic data type information such
as floating point
values, inte-
gers,
strings, 2D and 3D vectors, bitmapped images, and
arrays of those types.
Dynamic behaviors in the scene graph are accom-
plished via events fields that let their values be
changed, or that tell the application when their val-
ues have changed. An AJAX3D application can send
events via the SAI using a straightforward JavaScript
property-setting syntax as in the following example:
theText.string[0] = Hello;
theText.string[1] = AJAX3D!;
The SAI also defines field listeners: objects with
callback methods that are invoked when an event
is generated. Heres an example of adding a field
listener to a TouchSensor an object that tells the
programmer when some geometry in the world has
been clicked on (by generating a touchTime event):
var observer = new Object;
observer.readableFieldChanged = clickCallback;
sensor1.touchTime.addFieldEventListener(observer);
DynamicallyGeneratingSceneGraph
Content
The SAI supports the dynamic generation of X3D
content from strings, URLs, or using factories that
create nodes by type. Heres an example of creating
X3D with a string:
var str = <Shape><Box size=.5 .5 .1/></Shape>;
var newscene = Browser.createX3DFromString(str);
By combining this capability with AJAX tech-
niques (i.e., using XMLHttpRequest), an AJAX3D
application can build an entire 3D world program-
matically based, for example, on queries to a MySQL
database.
Taken together, the ability to control rich X3D
worlds from JavaScript running in Web pages, to
update Web pages based on events that occur in the
world, and to dynamically build worlds from program
code make AJAX3D a complete system for delivering
3D applications on the Web. The possibilities of this
approach are endless, and this presents a challenge:
how to best harness the vast power of AJAX3D into a
useable set of tools and framework code for develop-
ing a broad range of applications. We will explore this
issue below, but first an example.
Example:TheStrikefghter
Larry Rosenthal of Cube Productions has been
designing real-time 3D content for over 15 years and
has been running a science fiction virtual world/
online community called StarbaseC3 for nearly that
long. In 2001 he developed the first version of a 3D
Web game called Strikefighter based on StarbaseC3
models. Over the years Larry has updated the game
from time to time, and ported it across various 3D
engines, both open and proprietary.
Larry teamed up with programmer Dave
Arendash to once again port Strikefighter (shown
in Figure 1). Using AJAX3D, Dave connected the
game to a live Web server (running PHP and
MySQL) that implements a scoreboard. When the
game is over, it checks the current score against
a database of high scores residing on the server.
If the players score is in the top 10 hes invit-
ed to post his name on the public scoreboard.
Strikefighter is similar to the Flash-based mini-
games that have proliferated on the Web over the
last several years. Until AJAX3D, Larry wasnt able
to deploy a 3D game like this based on a royalty-
free, open platform that fully integrates with a Web
server and runs on a page.
TheAJAX3DInitiative
In a sense, the technical underpinnings for
AJAX3D, like those of AJAX itself, are almost trivi-
ally simple (that is, if one considers Web brows-
ers, XML, and real-time 3D Web plug-ins simple
things). There are a small number of basic constructs
involved: JavaScript, XMLHttpRequest, the DOM,
and the SAI. However, the many possible combina-
tions of these, combined with the ability to deliver
code and content worldwide at nearly the speed of
thought, have profound implications.
AJAX3D promises a royalty-free, open, global plat-
form for creating a next-generation Web experience.
The key to realizing that promise lies in establish-
ing techniques and best practices that can be used
throughout the industry, supported by tools and
frameworks, and developed in an open setting. In
other words, AJAX3D is as much about community
process and collaboration as it is about technology.
In August 2006, Media Machines launched
www.ajax3d.org as an open industry body to foster
Figure 1: The Strikefighter Game in AJAX3D
Tony Parisi, president and CEO of Media
Machines, is co-creator of the Virtual Reality
Modeling Language (VRML), the ISO stan-
dard for 3D graphics on the World Wide
Web. He is widely recognized as an expert
in standards, technologies, and emerging
markets for interactive rich media. In 1995
Tony founded Intervista Software, an early
innovator in real-time networked 3D graph-
ics technology and developed WorldView,
the first real-time VRML viewer for Microsoft
Windows. He started Media Machines in
2001 and is spearheading the development of
FLUX, a real-time 3D technology that contin-
ues to push the envelope in interactive graph-
ics for the Web. He is also a lead editor and
co-chair of the Extensible 3D (X3D) specifica-
tion, the new standard for Web3D graphics
being developed by the Web3D Consortium.
44 January 2007
AJAx.sYs-CoN.CoM
AJAX3D development. The site has a large mailing
list, active discussion forums, and several exam-
ples. Media Machines intends to hand the mainte-
nance and governance of the site, and the project as
a whole, over to an all-volunteer group in the near
future.
With the initial launch of AJAX3D, we have just
scratched the surface of what is possible. The group
has identified important next steps to be taken over
the next several months:
Develop a programming framework (ajax-
3dlib): The first tutorials hint at a general-pur-
pose programming framework, but theres still a
lot of work to be done in this area.
Create domain-specific modules: It would be ben-
eficial to develop reusable modules for game
play, data visualization, e-commerce, and other
domains.
Build out the showcases and examples: The site
is continually soliciting showcases and exam-
ples.
Identify areas for ongoing R&D: While most
of the effort in the AJAX3D project will be
focused on deployment, there are some areas
that require further research. For example, is
it possible to deliver real-time messages for
multi-user game play using AJAX, or are other
technologies required?
Engage with the industry: Develop relation-
ships and begin conversations with other groups
involved in AJAX and Web 3D development, both
official and ad hoc.
Summary
Royalty-free standards such as X3D have made
it possible for anyone to deliver rich 3D con-
tent in real-time over the Internet. At the same
time, AJAX has emerged as a worldwide phenom-
enon and unleashed a flurry of new application
development. By bringing these two technolo-
gies together, AJAX3D promises a complete open
platform for creating a next-generation 3D Web
experience.
With AJAX3D immersive virtual worlds can be
deployed in a Web browser and integrated with
pages and other media. AJAX3D worlds can com-
municate with standard Web servers using XML and
AJAX technologies, enabling professional, scalable,
industrial-strength applications with high produc-
tion value and visual impact.
AJAX3D is in its infancy. In the coming months
it will need to be nurtured and actively devel-
oped. Media Machines hopes that the initiative
that began at www.ajax3d.org will take on a life
of its own and become a worldwide forum for
researching and developing this exciting new
technology. n
AJAX3Dpromisesa
royalty-free,open,
globalplatformfor
creatinganext-generation
Webexperience
A
JAX is definitely taking Web applications to
the next level in ease of use and desktop-like
user interfaces. And it can even be used to
create the secure, privacy-oriented Web applications
that are so needed in todays Web world.
AJAX is based on Web browsers endowed with
powerful JavaScript engines. In this article Ill explain
a framework for AJAX-based Web applications based
on client-side data encryption using a Secure Key for
maximum data security and privacy. This framework
can be used with any Web application, saving a lot
of potentially sensitive user data like bank account
details and login details for Web sites.
This framework will put the user in full control
of sensitive data; the back-end server will just be
a mechanism to save the encrypted blob from the
user. Its based on client-side JavaScript and XML for
all the business logic and data encryption/decryp-
tion, searching, and sorting. It will also open up
new dimensions for making online payments and
banking since it can talk to different Web Services
from the client browser instead of going through an
intermediate server, thus minimizing the risk of any
third party intruding on the data.
Regular unencrypted user data will be present
only in the client browser. Anywhere outside the cli-
ent browser the data will be encrypted, be it on the
wire or saved in a back-end database to maximize
security and privacy. And Ill explain how to write an
easy AJAX-based Web application using DWR (Direct
Web Remoting) with this framework.
TheNeedforaClient-side
EncryptionFramework
When saving sensitive private information in any
Web application, questions always cross my mind.
How secure is my private data? Do I really trust all
the servers where its saved? Most of the time I have
to trust the server since theres no other way to get
stuff done using the current Web application secu-
rity framework.
All Web applications save private user informa-
tion in their databases either encrypted or unen-
crypted with a server-generated key, which creates a
major threat since the mechanism to view the data
lies with the server and is available to all sorts of
manipulation by the back-end servers users and any
interloper with access to the server. So for Web appli-
cations where user privacy is a primary concern,
theres no robust architecture to give users the upper
hand in controlling their private data.
Our framework, using client-side encryption to
encrypt user data, gives the user full control of the
data and the data is encrypted once it leaves the
users browser. The user is given the ultimate privacy
and security and can rest assured that no one can
do anything with it. But coming up with a real func-
tional Web application using this concept is a little
difficult without the power of AJAX and JavaScript.
Figure 1 shows the data transfer mechanism in a
typical Web application. Figure 2 shows how the cli-
ent-side encryption concept works differently than
typical Web applications.
In Figure 2, the basic data transfer mechanism
is shown for Web applications doing client-side
encryption where the data is in encrypted form
anywhere outside the browser JS engine. In a clas-
sical Web application, HTTPS/SSL is implemented
only to transfer the data encrypted on the wire,
but once it reaches the server, it resides in unen-
crypted form or is encrypted with a server-gener-
ated key.
For client-side data encryption to work and ensure
data privacy the private user data in the browser
is encrypted with a user-provided key (secure key)
that is never transported or saved in the server. The
data is saved in encrypted form in the server and
the server doesnt have a clue what the unencrypted
data is! And when getting the private user data back
from the server, the data is downloaded in encrypted
form. To view the data or to take any action on the
data it has to be decrypted using the Secure Key
used to encrypt it. The data lives its unencrypted life
only in the browsers user session and all the logic to
interact with any Web Service to do application logic
or any searching or sorting is done using JavaScript
and XML programming on the client side. This puts
a lot of processing and application logic in the client-
Anewconceptofdataprivacyandsecurity
forAJAX-basedWebapplicationsusing
client-sidedataencryption
Framework
Lockdown
by Indroniel Deb Roy
Indroniel Deb Roy works as an architect for
a leading knowledge management solution
provider. Previously he contributed to the
development of Oracle XML Publisher as
development manager and participated
actively in developing Novells exteNd XML
integration server. He has a passion for
innovation and works with various XML
and J2EE technologies.
46 January 2007
AJAx.sYs-CoN.CoM
side JavaScript engine, but its secure enough that its
virtually impossible to break in.
Let me use an analogy and explain the concept
in terms of a person storing his valuables in a safety
deposit box at a bank. A person (our user) opens a
safety deposit box account (the user account) at a
bank (your typical Web application) and stores all
his valuables (his private data) there, but the boxs
key (the password) stays with the bank and the user
can only get it after verifying his identity to the bank.
He can go to the bank anytime and verify his identity
and get access to his valuables, but since the key
stays with bank, the bank has full access to the stash.
Our concept lets the person put a lock on the valu-
ables using a private key (a Secure Key) before stor-
ing them in the box so the bank doesnt have access.
Only the person with the key has access to the box.
In the real world too, this concept adds more robust
security to the user scenario.
SimpleUseCasesWheretheFramework
MayBeUseful
Our framework is useful in any Web application
where the users privacy and security is a major
concern. Ill provide use cases for two simple Web
applications where it will find great application.
AnOnlineAccountHandlerApplication
If you think about the different online accounts
you open or maintain everyday, you know it would
be precious to have a Web application where you
can store and manage the login credentials for
all your Web accounts without sacrificing pri-
vacy. The technology in typical Web applications
doesnt scale well. Our approach guards the users
interest and gives him full control of his private
data.
OnlineShoppingandPaymentApplications
Theres a plethora of Web applications that save
user bank and credit card information online so the
user can make payments with the click of a mouse
and give him a rich experience in terms of ease of
use, but they also expose him to phishing attacks.
The client-side encryption framework offers both
ease of use and enough security for them to put their
private information on them without hesitation. On
the server side there will be less rumpus about pass-
word or credit card theft since it will be impossible
for anyone other than the user to make use of the
secured private information. Hackers can break into
the site but it wont matter.
Banking and online shopping sites could put a
stop to phishing and other vulnerabilities with this
approach if the Secure Key combined the user-provid-
ed key and a unique server key to identify the server.
ASampleWebApplicationwiththe
ConceptatWork
Now lets see how easy it is to put this client-side
encryption framework to use in a very basic imple-
mentation. Ill take the use case of an online account
handler application and write a reference imple-
mentation. The application I implement will explain
the idea of client-side encryption in detail.
To keep it simple the sample Web application
has a UI to punch in the Secure Key that will be
used to encrypt all the user data that wont be
transported or saved in the server. It will pro-
vide a basic HTML form to key in the user
data with one button called Encode.
When Encode is pressed, the user-pro-
vided Secure Key will encrypt the data
and a Save button will be displayed.
When Save is hit, the encrypted user
information will be saved to the server.
To display the user data the encrypted
data will be fetched back to the browser
and displayed with a Decode button.
When the Decode button is hit and the
correct Secure Key entered, the informa-
tion will be decoded and shown to the user.
To try it on your machine youll need a serv-
let container (Tomcat 5.5). Please deploy the
war file ClientSideEncryption.war, which can be
downloaded from the magazines code server. Once
deployed, youll need a JavaScript-enabled browser
like Firefox, Internet Explorer, or Opera to see the
application at work.
For a more complete version of the application
with user login and a more functional implementa-
tion for mass use see http://www.eSecureKey.com.
TechnologiesUsed
This application is based on open source tech-
nologies. It uses Blowfish encryption, a tried and
tested algorithm, to encrypt the user data. Although
the information stored on the server side is very
simple and can be captured in just one database table
containing three columns (id,userdata,user_id), Ive
used the open source Hibernate framework to fetch
and serialize the data to a native HSQL database. To
transfer the encrypted data from the client browser
to the server and fetch the encrypted data back from
the server side. I used the DWR (Direct Web Remoting,
Easy Ajax for Java) framework. In general the heart
of the application lies in its JavaScript and XML pro-
gramming in the client browser, server interaction is
only to save and retrieve the encrypted data.
ImplementingtheClient-sideEncryption
Framework
The biggest hurdle with this application was
to choose a versatile open source cryptographic
algorithm devoid of any patent or any government
restrictions and good enough so that theres no
way to break it. After evaluating a lot of crypto-
graphic algorithms, I picked the Blowfish encryption
algorithm. Blowfish is a general-purpose algorithm
intended to replace an aging DES and free of the
problems associated with other algorithms. At the
time, many other designs were proprietary, encum-
bered by patents, or government secrets. According
to its core designer, Blowfish is unpatented, and will
remain so in all countries. The algorithm is hereby
placed in the public domain, and can be freely used
by anyone. With that in mind I started searching
for an implementation of Blowfish in JavaScript and
I found an implementation by Stephen Griffin to
start building the functionality I wanted that fit my
requirements. The finished core Blowfish JavaScript
engine can be found in decipher.js, which contains
the added functionality suitable for the present Web
application. Two main functions to use in descipher.
js are:
function getEncodedText(password, plaintext)
where password is the User provided Secure Key
plaintext is the text to encrypt
returns text encrypted with the given pass-
Figure 2: Client-side encryption
Figure 1: Data transfer mechanism in a typical Web application
48 January 2007
AJAx.sYs-CoN.CoM
The terms on everyones lips this year include AJAX, Web 2.0 and
Rich Internet Applications. All of these themes play an integral role at
AjaxWorld. So, anyone involved with business-critical web applications
that recognize the importance of the user experience needs to attend
this unique, timely conference especially the web designers and
developers building those experiences, and those who manage them.
BEING HELD MarcH 19 - 21, 2007!
We are interested in receiving original speaking proposals for this
event from i-Technology professionals. Speakers will be chosen
from the co-existing worlds of both commercial software and open
source. Delegates will be interested in learning about a wide range
of RIA topics that can help them achieve business value.
NEW YORK CITY
Asynchronous JAvAscript And XML Asynchronous JAvAscript And XML Asynchronous JAvAs-
cript And XML Asynchronous JAvAscript And XML Asynchronous JAvAscript And XML Asyn-
chronous JAvAscript And XML Asynchronous JAvAscript And XML Asynchronous JAvAscript
And XML Asynchronous JAvAscript And XML Asynchronous JAvAscript And XML Asynchro-
nous JAvAscript And XML Asynchronous JAvAscript And XML Asynchronous JAvAscript And
XML Asynchronous JAvAscript And XML Asynchronous JAvAscript And XML Asynchronous
Rich Internet Applications: AjAx, Flash, Web 2.0 and Beyond...
Rich Internet Applications: AjAx, Flash, Web 2.0 and Beyond...
r
E
G
Is
t
E
r
t
o
D
a
y
a
N
D
$
a
v
E
!
COPYRIGHT 2006 SYS-CON MEDIA. ALL RIGHTS RESERVED
sys-coN Events is proud to announce the
ajaxWorld East conference 2007!
the world-beating conference program will provide developers and It managers alike
with comprehensive information and insight into the biggest paradigm shift in website design,
development, and deployment since the invention of the World Wide Web itself a decade ago.
www.AjaxWorldExpo.com
t H E r o o s E v E L t H o t E L L o c a t E D a t M a D I s o N & 4 5
t h
word
function getDecodedText(password,encodedText)
where password is the User provided Secure Key
encodedText is the text passes for decryption
returns plaintext decrypted with the given password
For the full implementation see the decipher.js source code.
Once this core functionality was up and working, it was easy to
plug in the HTML code to come up with the UI for the user to key
in a Secure Key that will be present just in the client browser and a
form to punch in the users ID and the user data. The user data is
always encrypted using the function above with the Secure Key as
the password before transporting it to the server for persistence.
ImplementingtheServerSide
For simplicitys sake, the application logic on the server side is
pretty thin in this implementation since the encrypted data is just
saved in a back-end database table and fetched back when asked
for. I used the open source Hibernate framework to provide this
functionality with its native HSQLDB support. So, nothing needs to
be changed to set Hibernate up in your client system after deploy-
ing the .war file.
To configure the database table using Hibernate, I added
UserData.java, a wrapper for the underlying saved data in the
database having a properties id (unique to each UserData), the
data (the encrypted data), and a userid (the user identification ID
associated with each UserData); UserData.hbm.xml is defined to
map the UserData to a valid table in the database using Hibernate.
UserDataFactory.java is used to provide basic functionality like
add, edit, delete, and search on the UserData. A skeletal view of the
class is:
public class UserDataFactory {
Session hibernateSession = null;
public UserDataFactory() throws Exception
protected void init() throws Exception
public UserData getUserData(String dataId)
public java.util.List getLoggedInUserDataSet(String userid)
public void addUserData(String emailId,String userdata)
public void updateUserData(String id,String emailId, String
userData)
public int deleteUserData(String id)
protected void finalize() throws Throwable
}
For Hibernate power users this is very obvious, but for users
with no Hibernate experience this information is required to
understand how the application works.
ImplementingtheAJAX-based
Client/ServerInteraction
Both our client and server side are now ready for our online
account handler application. Only the data transportation layer
has to be implemented to complete the application. Since were
doing the encryption and decryption of data on our client side
using JavaScript, its quite easy to set up a JavaScript-based
framework to transport the data to the back-end server asyn-
chronously. The DWR framework is the easiest way to implement
such functionality. There are other open source frameworks like
DOJO and RICO that do the same thing, but in this case theres
one class, UserDataFactory, on the server side that pretty much
takes care of all the basic application functionality, so exposing the
UserDataFactory using DWR seemed to be the easiest option.
To integrate the DWR framework in this Web application Web.
xml was changed to incorporate the DWR servlet definition and
mapping, and a dwr.xml file was added to the WEN-INF folder with
mapping to create the UserDataFactory class and use UserData
and Iterator classes through JavaScript. Thats it; the data trans-
portation framework is all set up. Look at the JavaScript functions
exposed from UserDataFactory that were used to complete the
Web application:
function UserDataFactory() { }
UserDataFactory.getUserData = function(p0, callback) {}
UserDataFactory.getLoggedInUserDataSet = function(p0, callback)
{}
UserDataFactory.addUserData = function(p0, p1, callback) {}
UserDataFactory.updateUserData = function(p0, p1, p2, callback)
{}
UserDataFactory.deleteUserData = function(p0, callback) {}
Please look into the source files to see the actual implementa-
tion details.
Conclusion
In this article I show a very basic implementation. For a more
complete implementation like the online shopping and payment
applications using client-side encryption, Web Services may be
called from the client-side JavaScript engine to make online pay-
ments and still maintain absolute privacy of the user data. It will
also be possible for the user to grant someone temporary access to
the private data, a scenario that opens up new strategies for secur-
ing data even from existing server-side applications while granting
temporary access to third-party partners across the globe without
sacrificing user privacy.
To sum up, client-side encryption that provides a secure and
privacy-oriented application using AJAX and Web 2.0 can be used
efficiently in various Web applications to put users in ultimate
control of their data. The concept is easy to understand and pretty
simple to implement and will probably create a new set of Web
applications with enhanced privacy and security.
References
eSecureKey.com a live service based on the concepts elabo-
rated in this article: http://www.eSecureKey.com
Blowfish Encryption the Blowfish Encryption algorithm
explained: http://en.wikipedia.org/wiki/Blowfish_(cipher)
Blowfish HTML Encryption a Blowfish HTML encryption
library by Stephen Griffin: http://i-code.co.uk/javascript/blow-
fishhtmlencryption.php
Hibernate Framework an object/relational persistence and
query service for Java: http://www.hibernate.org/
DWR, Easy AJAX for Java direct Web remoting to expose Java
objects in JS: http://getahead.ltd.uk/dwrn
50 January 2007
AJAx.sYs-CoN.CoM

AjaxWorld 2007 01

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

AjaxWorld 2007 01

Загружено:

Авторское право:

Доступные форматы

THE AJAX MOMENT MUSHROOMS INTO THE WEB 2.

application only gets messages for /stocks. This

Вам также может понравиться