Ajax World Magazine (May, 2007)

AJAX – IMPROVING THE CUSTOMER EXPERIENCE .":


70-6.&

*446&

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

pushing into high gear 1-64 )PX
UP
4FMFDU
3*"
5FDIOPMPHJFT %FMJWFSJOH
/FYU(FOFSBUJPO
6TFS
*OUFSGBDFT
6TJOH
"+"9
0SBDMF
9&

"+"9
"TZODISPOPVT
9.-
JO
"DUJPO 'BTU
4DBMBCMF
"+"9
"QQT

RETAILERS PLEASE DISPLAY UNTIL SEPTEMBER 30, 2007

Scary Question. Exactly who is developing your next app? Contact Us

Address: 555 Not My Home St. Big City, CO 12345

Your App Starts Here. We are the leaders in RIA development services.

INCREDIBLE APPLICATIONS PASSIONATE USERS PROVEN SUCCESS

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

March 2007

n6

Taking AJAX Seriously



From the Editor



by Roger Strukhoff

n8



How to Select RIA Technologies



Choosing between two paths:



AJAX or Adobe



by Jeffrey S. Hammond

n12

Delivering Next-Generation User Interfaces Using AJAX



The user experience is absolutely



central to the Web 2.0 model



by Rado Kotorov

n16

AJAX Done Right



Or, how I learned to stop worrying



and love the DOM



by John Eckman

ajax.sys-con.com

n22



Oracle XE + AJAX: Asynchronous XML in Action



Building a real application



by Przemek Piotrowski



and Mark Townsend

n28



Quasar’s Nuqleo System Integrates AJAX into Enterprise Publishing



Work flows improve, bottlenecks disappear



when taking a Web-based approach

n30

Fast Scalable AJAX Apps



bottlenecks and bloat



by Dylan Schiemann

n32

Pushing AJAX into High Gear



OpenAjax Hub, TIBCO GI, and DWR 2.0



by Kevin Hakman and Joe Walker





Finding and eliminating

A simple streaming AJAX example with the

May 2007



From The Editor Group Publisher Roger Strukhoff

Taking AJAX Seriously

Art Director Louis F. Cuffari Editor Nancy Valentine, 201 802-3044 [email protected] To submit a proposal for an article, go to http://grids.sys-con.com/proposal.

Roger Strukhoff

Subscriptions E-mail: [email protected] U.S. Toll Free: 888 303-5282 International: 201 802-3012 Fax: 201 782-9600 Cover Price U.S. $5.99

I

U.S. $19.99 (12 issues/1 year)

t’s fun to watch kids grow up, as they move from various cute stages through the obnoxious teen years and into what passes for maturity these days. On an accelerated timescale, it’s fun to watch technologies grow up, too. Some mature more quickly than others. Some mature too quickly and die out, while others never seem to mature at all. Over the past two years, AJAX as a general technological approach seems to be maturing very quickly. I won’t bore this magazine’s savvy audience by recounting for the umpteenth time how, when, and by whom the term was coined, and I fully realize that many of you had been working – sometimes for years – with JavaScript, XML, and related languages and approaches before the term AJAX came into existence. What is important is that AJAX today is not the AJAX of early 2005. Seen originally as part of a communitarian Web 2.0 culture that once again threatened to overturn the so-old, so-dated IT world of the past, AJAX is, in fact, now becoming an integral part of any serious enterprise’s approach to its IT infrastructure. Google Maps was seen as the quintessential AJAX/Web 2.0 manifestation. Raucous start-ups such as YouTube, Digg, et al, with huge Web traffic numbers but precious few employees were seen as the way of the future. AJAX interfaces promised to enhance the customer experience, leave old-fashioned Websites in the dust, and change the world. The trouble with revolutions, though, is that they burn out quickly and don’t always manage to overthrow the existing order. It’s too early to tell whether Web 2.0

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, [email protected], Frank Cipolla: 845 731-3832, [email protected]

Promotional Reprints Megan Mussa [email protected]

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 mechanical, including photocopy or any information storage and retrieval system, without written permission.

AJAXWorld Magazine is published bimonthly (6 times a year) by SYS-CON Publications, Inc., 577 Chestnut Ridge Road, Woodcliff Lake, NJ 07677. SYS-CON Media and SYS-CON Publications, Inc., reserve the right to revise, republish, and authorize its readers to use the articles submitted for publication.



May 2007

is a revolution, a buzzword, or an inflection point in the history of technology and civilization. It’s easier to tell what’s happening with AJAX. Separating AJAX from Web 2.0 reveals a seriousness of purpose by AJAX proponents and developers, and a future that will be more about improving existing infrastructures than trashing them. Improving the customer experience – a key goal of AJAX – can be measured by the very large and very serious companies that are now integrating AJAX into their front ends. How quickly can customers find what they need? How does the new efficiency aid clickthroughs, sales, and repeat sales? How does it improve the company’s effort to develop and maintain a 360-degree customer view? How does this compare with competitors? How does it compare with potential competitors? All of these questions can be answered objectively and provide information much more concrete than that provided by a mere “wow” factor. As AJAX becomes less and less about “wow” and more and more about developing traditional customer satisfaction, we can expect the market for AJAX technology providers to grow and grow. Enterprises are taking AJAX seriously. AJAX is no longer some sort of revolutionary concept; it is becoming the way to do business. It seems as if AJAX has gone from being the cute kid, skipped those pesky teenage years, and become a very nice and productive young adult. This may seem like a terribly unglamorous statement to all of us who like to act like radicals now and then. But it strikes me as a beautiful thing. n

ajax.sys-con.com

Akamai makes AJAX sites perform 5X faster.

As end users graphically edit price parameters, information within the main content area is dynamically updated.

This instance of Google Maps dynamically updates as destination cities are chosen.

As arrival and destination times are modified, flight information is updated in real-time.

Akamai delivers AJAX Websites up to 5x faster. Ensure every transaction is completed with optimal performance for each user—even for highly interactive sites.

©2007 Akamai Technologies, Inc. The Akamai logo is a registered trademark of Akamai Technologies, Inc. All Rights Reserved

To learn more, download a new White Paper: Web 2.0 is Here—Is Your Infrastructure Ready? Visit www.akamai.com/AJAX

Frameworks

How to Select RIA Technologies

by Jeffrey S. Hammond

Choosing between two paths: AJAX or Adobe

W

hen it comes to rich Internet application (RIA) technologies, application development professionals must choose between two paths: AJAX or Adobe. AJAX is the best bet for experienced Web development shops looking to incrementally evolve existing Web applications. Of course, selecting AJAX also raises the question of whether to go with a homegrown, open source, or commercial AJAX framework. In contrast, Adobe is best for shops looking to completely transform their Web experiences. But to do so, firms must acquire the skills necessary to use Flex, which is the development framework for the Flash runtime environment. Early adopters with time-to-market concerns and comfort with either smaller vendors or open source can select AJAX with confidence. But firms that require support from a larger vendor and full-featured development tools will do better with Adobe. App dev professionals should make the selection based on their time-to-market requirements, whether they’re looking to evolve or revolutionize their user experience, and whether they prefer tools from large established vendors.

AJAX: The Fast Lane to a Better User Experience

App dev organizations that prefer a fast path to RIAs — for developers and users alike — select AJAX for the following reasons: • AJAX helps shops meet time-to-market needs. Developers with existing Web skills find that adopting AJAX involves a shift in design patterns, not a wholesale change in programming language or development tools. • AJAX favors gradual re-factoring of existing Web apps. AJAX is based on open and standard languages like JavaScript and XML. This makes it easy for developers to integrate AJAX widgets into existing Web applications that are written in HTML, DHTML, or server-side JavaScript. • AJAX can deliver speedy performance. Vendors of commercial AJAX frameworks like Backbase and JackBe invest considerable resources tuning their AJAX frameworks for speed because their clients

Jeffrey Hammond is a senior analyst at Forrester Research where he covers tools and techniques for application design and development.



May 2007

have tiny footprints and download to browsers so quickly that there’s no perceptible lag in app performance. Some open source AJAX tool kits share this trait, but others approach the size of Adobe’s Flash and have equally long install times. Developers and architects may salivate over the technical merits of AJAX, but managers should note that using AJAX frameworks also introduces risk. Unmanaged, these risks can increase costs or derail a development effort entirely. For example: • It’s easy to choose the wrong AJAX framework. There are dozens of popular AJAX frameworks, and they are not created equal. Developers might want to cut a check based solely on a framework’s rich widget set or light-speed performance, but architects will need to validate that the framework supports corporate standards for security, accessibility, service integration, and data access. • Finding best-of-breed AJAX development tools is difficult. Experienced Web developers don’t mind writing JavaScript and XML in text editors, but most developers in enterprise IT shops prefer visual designers and WYSIWYG editing tools. When it comes to AJAX, the only such tool support available at present is tied to commercial AJAX frameworks, meaning that the choice of one is necessarily a choice of the other. • Cross-browser compatibility issues increase testing costs for AJAX. Testing costs increase in direct proportion to the number of browser platforms and versions to be supported. However, using a commercial AJAX framework can mitigate these costs, as the framework vendor incurs the cost of cross-browser testing. For example, Software AG certifies its cross-vision Application Composer on multiple versions of browsers like Internet Explorer, Mozilla, and Netscape.

The AJAX Path Itself Forks with Homegrown, Open Source, and Commercial Alternatives

Just because a development team has chosen to go with AJAX doesn’t mean that its tool selection effort is complete. There remains the important

ajax.sys-con.com

decision of how many and what type of AJAX frameworks to use. Today there are three types: • Many developers create their own frameworks. Development teams create their own AJAX widgets when they need customized controls that work in a specific way. • Other developers build on top of open source frameworks. Open source communities engage in a constant process of peer review, which quickly separates good design from bad. This leads to successful projects maturing quickly, while poor frameworks lose critical mass. When selecting an open source framework, look for active development communities with committed corporate sponsors, as this is an indication of longevity. OpenLaszlo, Dojo, and the Google Web Toolkit (GWT), for example, are supported by corporate sponsors like Laszlo Systems, IBM, AOL, and Google. • Commercial frameworks provide a throat to choke. Commercial AJAX vendors provide support and certification of their products, which is appealing for managers who are uncomfortable taking the open source route. They also focus on providing capabilities that enterprise developers require, including high-performance clients and tooling that makes it easy for developers to connect to enterprise applications. Just as there are myriad AJAX frameworks, there are also myriad AJAX framework selection criteria. These criteria fall into five buckets: customizability; security and accessibility; widget set; tooling; and cross-browser support. But not all of these criteria should be weighted equally (see Figure 1).

Adobe’s Solution Is Powerful, Predictable, and Productive

Adobe is an attractive RIA solution because it combines powerful development tools (Flex) with a near-universal browser plug-in (Flash) that’s designed to simplify RIA deployment. Managers who have concerns about small commercial AJAX providers or support issues with open source AJAX frameworks consider Flex a safe alternative. But there is a downside: To be productive in Flex, developers have to learn two new languages and an extensive runtime framework — something that can take between one and three months to learn. Once this initial hurdle is cleared, Adobe adopters see the following benefits: • Widespread adoption of Flash speeds deployment. When Flash is already installed, application deployment requires no additional changes to the

ajax.sys-con.com

user’s desktop. Unlike AJAX, Flash doesn’t require browser-specific code or enablement of JavaScript in the user’s browser. • Flex works well for large-scale RIAs. Large-scale user productivity applications are often designed with conversation flows that require access to business data and rules to drive application context. Flex makes it easy for developers to provide the right business context and flow while keeping response times to a minimum. • Flex is evolving quickly and has a predictable trajectory. Adobe has invested heavily in Flex, and the result has been sustained improvement from release to release. In contrast, the future of AJAX depends on the whims of a dozen vendors and open source projects that aren’t even loosely federated. In the words of one architect we spoke with, Flex is “one support framework to rely on, not dozens to integrate.” • Flex Builder improves developer productivity and collaboration with designers. Flex Builder provides developers with a visual, WYSIWYG experience on a par with the best commercial tools for AJAX. What sets Flex Builder apart from these tools, though, are features that improve collaboration between developers and designers. Using Flex lets developers and designers at the American Cancer Society rapidly iterate through design changes and preview them with stakeholders within hours.

SYS-CON Media President & CEO Fuat Kircaali, 201 802-3001 [email protected] Group Publisher Roger Strukhoff, 201 802-3040 [email protected]

Advertising Senior Vice President, Sales & Marketing Carmen Gonzalez, 201 802-3021 [email protected] Advertising Sales Director Megan Mussa, 201 802-3028 [email protected] Associate Sales Manager Corinna Melcon, 201 802-3026 [email protected] Events Manager Lauren Orsi, 201 802-3022 [email protected] Events Associate Sharmonique Shade, 201 802-3024 [email protected]

Production Lead Designer Louis F. Cuffari, 201 802-3035 [email protected] Art Director Alex Botero, 201 802-3031 [email protected] Associate Art Directors Tami Beatty, 201 802-3038 [email protected] Abraham Addo, 201 802-3037 [email protected]

Flex Developers Are Hard to Find and Other Drawbacks of Flex

SYS-CON.COM Vice President Information

But Adobe isn’t perfect. App dev professionals should consider the following Adobe drawbacks: • Flex developers are difficult to locate and command a premium rate. Flex developers are harder to find and more expensive to retain than AJAX developers: In the United States, they start at $60,000 and top out around $120,000. One executive at a North American financial services firm we spoke with had to retain talent from South Africa and the Czech Republic to deliver a successful project. As more developers ramp up on Flex this issue will subside, but for now it makes Flex more expensive in the short-term than Ajax. • Flash upgrade issues can defeat the deployment value proposition. When users aren’t on the latest version of Flash, requiring them to upgrade is risky because almost half will abandon the site. Many are unwilling to wait through the lengthy install process and instead choose to do business elsewhere — potentially with the competition. • Success can create an unexpected user response.

May 2007



Bruno Decaudin, 201 802-3051 [email protected] Consultant, Information Systems Robert Diamond [email protected] Web Designers Stephen Kilmurray, 201 802-3053 [email protected] Richard Walter, 201 802-3057 [email protected]

Accounting Financial Analyst Joan LaRose, 201 802-3081 [email protected] Accounts Payable Betty White, 201 802-3002 [email protected]



Customer Relations Circulation Service Coordinators Edna Earle Russell [email protected] Alicia Nolan, 201 802-3081 [email protected]



Flash is a broad graphical canvas, and Flex allows designers to push the boundaries of rich media further than AJAX does. This can lead to a situation where users become distracted by a mix of Flash’s rich media and Flex’s new controls. IT organizations can avoid this response by introducing rich media gradually and frequently conducting A/B testing with focus groups.

Which RIA Technology Is Best for You?

When aggressive developers push the boundaries of RIA development, they quickly run into barriers that affect their ability to take full advantage of RIA technology. Firms interviewed recently by Forrester Research cited several barriers to their RIA development efforts that no tooling available today could overcome (see Figure 2). In selecting an RIA technology, application development professionals should choose AJAX when time-to-market is critical and updates are frequent. Experienced Web developers ramp up on AJAX quickly. AJAX also makes it easy to build RIA capabilities into existing apps with small, frequent

releases. Finally, AJAX’s customization capabilities make it possible to tune client frameworks to meet specific application footprints; this makes AJAX the better solution for smaller RIA deployments and for deployments where performance is critical. For large-scale user productivity applications, developers should use Flex. Although Flash’s client footprint is larger than AJAX frameworks, its market penetration makes it the preferred deployment platform for larger, comprehensive RIAs. Adobe is a safe choice for those who put a high value on reliable support and product continuity, concerns that are key when making strategic technology investments. The downside is that safety comes at the price of openness. The benefits are clear: RIAs help users find and manipulate relevant content, complete complex transactions, and consume multimedia in the context of a larger app, providing improved customer experience, higher Web conversion rates, and thus improved revenues. While there’s no one answer to the question of which to use, AJAX and Flex provide today’s developers with options. n

Figure 1:

Figure 2:

10

May 2007

ajax.sys-con.com

“Pre-built Ajax widgets, cross-browser compatibility and the full support of the Backbase team were the keys to our selecting Backbase.” Robert Leerdam, Project Manager, ABN/AMRO

Backbase Enterprise Ajax: The Complete Development Solution for Ajax

TRY IT NOW!

Download a free trial at www.backbase.com

Product Highlights • • • • • • •

Cross-browser Ajax client runtime Simple and easy-to-use Ajax tags 100+ Ajax widgets w/ source Ajax development tools Debugging and testing tools SOA integration Integration with portal servers

• • • • • • •

Server-side integration with Struts and JSF Section 508 / WAI compliance Extensive documentation and tutorials Sample applications Open API Proven RIA blueprint implementations Comprehensive 24x7 support

For more information, call 866-800-8996 (Americas); +31 20 465 8888 (ROW)

Web 2.0

Delivering Next-Generation User Interfaces Using AJAX

by Rado Kotorov

The user experience is absolutely central to the Web 2.0 model

B

Rado Kotorov is a technical director of strategic product management for Information Builders, Inc., responsible for emerging reporting, analytic, and visualization technologies.

12

y any reckoning, the Internet and the World Wide Web have remade the way we do business. The ascendance of the Web-based enterprise has come to be seen as inevitable. But anyone who takes a hard look at the serious limitations of first-generation Web applications is likely to have a renewed sense of wonder at the spread of their adoption thus far. Users experimented with e-mail, instant messaging, and search engines and turned them into real communication, collaboration, and information-gathering tools. Those same business users endured their fitful interactions with static HTML pages and moved applications to the Web anyway because of the substantial savings promised by the shift. Now their patience is about to be rewarded. Emerging from a decade of groundwork is Web 2.0, which offers dramatic gains in productivity for individual workers and whole enterprises. Web 2.0 applications are distributed collaborative tools available on-demand from any browser anywhere. And those tools are constructed to be at least as intuitive and easy-to-use as any application loaded on a desktop. Web 2.0 is based on many technologies – most prominent among them being Web Services, Asynchronous JavaScript and XML (AJAX), Cascading Style Sheets (CSS), and Really Simple (Web) Syndication (RSS) – and the list will continue to grow. Of these, AJAX has attracted the most attention recently because it’s the technology that most effectively fills the gap between the user experience of Web and desktop applications. And the user experience is absolutely central to the Web 2.0 model. Web 2.0 applications must possess a set of user interface components that are as compelling and responsive as a desktopbased environment. Developers can no longer be satisfied to offer discontinuity in user experience, because widely distributed, frequently mobile users won’t be able to tolerate it and do their jobs well. The improved user experience will include, but must extend beyond, the most common productivity tools, such as word processing applications and e-

May 2007

mail. Web 2.0 and AJAX-based applications represent an opportunity to fully realize the Web’s potential to make users smarter and more productive, and that opportunity extends to the most sophisticated backend and analytic applications.

How We Got Here: Evolutionary Steps to Web 2.0

As any significant technology evolves toward maturity, attention shifts from the technology itself to the work that the technology enables. That shift is clearly manifest in Web 2.0, the third major phase of the Web’s evolution, which can be summarized like this: • Web 1.0 – Content delivery and communication. This early stage changed the dissemination of information via two innovations, HTML pages and e-mail. • Web 1.5 – Content personalization and multilevel communication. Search and personalization made the spread of information more efficient, while chat rooms and instant messaging expanded communication in real-time. • Web 2.0 – Authoring and collaboration. This current stage is not about the dissemination of information, it’s about productivity – accomplishing work-related tasks in a virtual space with tools and applications that are available anywhere, at any time, and can be shared collaboratively. In the past, Web applications’ lack of responsiveness and dearth of controls offset most of their advantages as thin-client tools. In contrast, desktop developers have historically taken advantage of two capabilities of Windows that make applications more intuitive and user-friendly than their Web counterparts: richness and responsiveness. When a complex and robust set of UI components is combined as they have been on the desktop, they make the user interface natural, informative, and intuitive to use. And when the application and the user interface quickly adapt to user actions, they create an uninterrupted interaction. Windows applications

ajax.sys-con.com

don’t stop to reload, forcing users to move through tasks in stops and starts – or causing them to lose the thread of the business process entirely. The user experience gap between Windows and the Web has been due to the limitations of the early Web client/server model, with the Web server as the platform for all processing logic and the browser as the client handling nothing more than the data display. In this architecture, users interact with HTML and each of their actions triggers a request to the server, which in turn triggers the generation of a new page. The incessant reloading of the page severely limits the user experience for a couple reasons. First, flipping from page to page can disorient the user as the allocation of tasks on different page views causes loss of context. On top of that, reloading the page causes a disjointed and rigid interactive flow. The user has to wait for the next page to initiate a new interaction or change the workflow, or be bounced back to the previous page to alter information in a field. Think of the online shopper on a retail site who can’t order three shirts instead of two without returning to page one, and then extend the problem to business users struggling with enterprise applications throughout their workday. The difficulties of the interaction are compounded as the complexity of applications and user options increases. For example, imagine the user experience of writing a document in an application created in Web client/server mode. For each paragraph, the user must open a dialog, enter the text in the input box, and wait for the changes to be applied to the document when the page is refreshed. And then all the steps must be repeated for every edit or format change. The frustrated user needs plenty of patience and training to work with the tool.

Enter AJAX

By contrast, AJAX combines technologies such as asynchronous JavaScript, the Document Object Model, XMLhttpRequest, XHTML, and CSS so the user can incrementally update any element of an application that resides in the browser. The user

ajax.sys-con.com

never leaves the application – never loses context or suffers interrupted workflow – because no action triggers the reloading of a full page. This seemingly small change has a profound effect on the user’s experience. Transferring more of the interaction to the client side not only improves the workflow, it also allows the addition of enriching UI components, which put AJAX-based Web applications on a par with desktop applications for usability. There are, it should be noted, alternatives to AJAX – Adobe’s Flash technology also provides a means to develop rich clients and DHTML allows one to partially upload components on an HTML page without reloading the entire page. But AJAX’s combination of cross-browser compatibility, zero footprint, and ability to provide interactive complexity to the user gives it a leg up on the competitive technologies. The improved interactivity of Web 2.0 applications is driving even more applications off the desktop, since the lower total cost of ownership now comes without the offsetting negatives of cumbersome user experience. These transitional Web 2.0 applications enabled by AJAX have been productivity tools, such as word processing and e-mail applications, calendars and spreadsheets. Examples are Google’s recently released Writely and Google Spreadsheets; competitive word processors like Zoho Writer, Abe Writeboard, and ajaxWrite; Num Sum spreadsheet functionality; and 30 boxes, a Web-based calendar. Web-based desktops are also emerging, like the one available at www.desktoptwo.com. Their lower TCO comes from centralizing most of the software in a single location on the server, with only a browser installed on desktops throughout the organization. This lowers installation and maintenance costs, provides for incremental upgrades to existing applications, creates user administration savings, and offers enterprise-wide control over document backup and archiving, as well as compliance and security. The Web 2.0 model makes applications – continued on page 18

May 2007

13

Solutions

AJAX Done Right

by John Eckman

Or, how I learned to stop worrying and love the DOM

T

John Eckman leads the Next Generation Internet Practice at Optaros (www.optaros. com), and has over a decade of experience designing and building Web applications for organizations ranging from small non-profit organizations to Fortune 500 enterprises. John´s technical background includes J2EE and .NET frameworks as well as scripting languages and presentationtier development approaches, in addition 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. [email protected]

14

he Bad Old Days, or, I Walked a Hundred Miles to School, in the Snow, and It Was Uphill Both Ways Back in the late ’90s, people started to use the term “Dynamic HTML,” often shortened to DHTML, to describe the use of JavaScript to manipulate HTML in the browser. Basic DHTML meant rollover images that changed state when you moused over them or drop-down menus that cascaded down from the top navigation. More complex DHTML concepts included dragging-and-dropping objects, hiding and revealing content, and even whole games built purely from HTML, images, and JavaScript. The problem with DHTML, of course, was that it was tremendously hard to do. More accurately, it was tremendously hard to do well in a cost-effective way. It was certainly possible to do some of the simpler functions (drop-down menus, mouseovers) in a reliable cross-browser, cross-platform way. But anything more complicated than that quickly ran into the problem of alternate browser implementations: for example, using the “layer” tag for Netscape 4, but the “iframe” for Internet Explorer and newer Netscape/ Mozilla browsers. Similarly, Internet Explorer 5.x and later supported document.getElementByID() as did the Mozilla-based browsers, but Internet Explorer 4.x relied on document.all, and Netscape 4.x on document.layers. The whole experience got confusing rather quickly, leading to a number of different alternatives. Many individuals coded applications or sites directly to a single browser, leading to the phenomenon of “Best Viewed in…” badges on sites. (I thought this behavior had gone the way of the “blink” tag, but Wal-Mart’s recent digital download site exhibited similar behavior – for several weeks following the launch, the site greeted Firefox visitors with an apology: “We’re sorry. Our Web site requires the browser Internet Explorer version 6 or higher. It appears that you’re using Firefox, Safari, or another browser that Wal-Mart Video Downloads doesn’t currently support.” In early March, however, it appeared that the problems had been rectified.)

May 2007

Some JavaScript developers learned to create applications with a series of if-then statements pointing to specific versions for specific browsers, replicating the functionality in each major “supported” browser. Sometimes this led to unanticipated results, as when the tests were too specific (looking for a particular version of a particular browser) they often broke when new browsers were released. (Smarter developers learned to test for specific functionality, rather than looking for a particular browser version – but this could still lead to a number of code branches for different browser levels.) Some Web designers found an alternative in Flash. Flash enabled designers to create animation, use sound, and create interactivity on the page without having to worry about browser versions and platforms. Because Macromedia (now Adobe) is the sole supplier of the Flash plug-in, it can offer complete control over the experience for both developers and users. Designers who resisted the urge to create monster intro movies and used Flash judiciously as a supplement to an HTML page, rather than as a replacement for it, found great power in the ability to add interactive elements and animation without having to decipher the complexities of DHTML. (A number of these first-generation Web designers abused Flash’s power, creating unnecessary animation, breaking the very interface conventions new Web users so desperately needed, and sticking “introduction” movies in front of Web pages, leading to the birth of the infamous “Skip Intro” button. See http://www.skipintro.nl/skipintro/ for a humorous version of the problem.) Finally, a significant number of information architects and Web designers simply learned to avoid DHTML altogether, or at least to avoid any of the “more complicated” functions. I remember seeing statements of work for Web development that either specifically excluded anything but the most basic DHTML or noted that DHTML use would increase risk and cost. If you didn’t have the right JavaScriptand browser-savvy resources as part of your Web team, it was undoubtedly safer simply to stay away.

ajax.sys-con.com

None of these approaches, of course, solved the core problem, or provided a repeatable, costeffective (in terms of development and debugging time), standards-based, plug-in independent, cross-browser solution to browser-side interactivity.

There’s Got to Be a Better Way: AJAX

The solution, as readers of this publication undoubtedly recognize, came in the form of AJAX. As I’ve written in an earlier article in these pages, Jesse James Garrett’s essay became such a pervasive meme precisely because it appeared to cut the Gordian knot that had long plagued Web development using JavaScript. What Garrett’s “AJAX” did was to give a name to a series of approaches that had been many years in the works: As the user base of the old Netscape 4.x applications waned, and the availability of new platforms rose, developers were emboldened by the relative ease of developing cross-browser standard applications with rich interaction in JavaScript and CSS, more and more developers started to create AJAX applications. Garrett’s essay crystallized this movement and gave it a name. While Garrett referred directly to the use of Asynchronous JavaScript and XML, the name is commonly applied to all kinds of uses of JavaScript for interactivity: some entirely synchronous, and many bypassing XML in favor of data representations like JSON. The point really is that the AJAX label effectively negated the fears associated with DHTML, and signaled to the development and design communities (as well as the customers who write the checks for site development) that it was now possible to build client-side interactivity without immense pain. Buoyed by the excitement over the Mozilla project, and the relative stability of the Document Object Model (DOM), a number of frameworks emerged to make AJAX-style development easier, abstract-

ajax.sys-con.com

ing away the plumbing to handle multiple browser implementations and interpretations. We have to be wary, however, of the assumption that just because developing AJAX-style Web applications has gotten easier, we’ve gotten better at developing them. Just as word processing software doesn’t (in and of itself ) improve one’s writing, having access to frameworks that facilitate AJAX-style development has increased the potential for users to develop truly both good usable applications and horrible unusable applications. How can we avoid the “Skip Intro” phase of AJAX development and move right into the mature, stable, usable application era?

First, Do No Harm: Don’t Break the Back Button

It’s crucial that while AJAX can make Web applications more like desktop applications, it should not remove the strengths of Web applications in the process or interfere in the fundamental architectures of the Web. This means, first and foremost, not breaking the conventions of back button use, bookmarking, and link sharing. Granted, these conventions may have different meaning in different applications, but they should be thoughtfully considered and only disrupted for a specific rationale. Full AJAX applications that provide rich interactive functionality but aren’t conceptually linked to a page-based interface may not be able to support the conventional use of the back button. If the interface has no notion of pages, and is all in a single HTML page, what sense does the back button make? For example, Zimbra’s Collaboration Suite, a Microsoft Outlook- or Lotus Notes-style e-mail client and calendaring system, doesn’t “support” the back button in the sense of allowing the user to click on the browser’s “back” button and somehow change the interface to the last viewed page or last entry in the browser history. Because the entire application lives in a single page at a given URL, allowing the “normal” function of the back button would result

May 2007

15

in jumping back out of the application. However, Zimbra doesn’t simply disable or hide the back button. Instead, the application pops up a confirmation dialogue (the same dialogue is used for other browser-actions that would navigate away, like clicking on a bookmark, or typing a new address in the address bar) as shown in Figure 1. This elegant solution lets the user remain in control rather than deciding on the user’s behalf. If, indeed, the user intended to navigate away from Zimbra – perhaps using the application for now – the user can simply hit OK and be off to the requested page. If the user didn’t intend to navigate away, a simple cancel returns them to the active context without interruption. Google’s Gmail, on the other hand, supports the back button by taking meaningful action when the user clicks it. If you’re viewing your inbox and click on a particular message, Gmail loads that message in the center content pane. Click on the back button and you return to the inbox view. Because Gmail treats the different views in a fashion consistent with the Web-native page metaphor, it makes sense that the back button should funct ion this way. Similarly, applications that run in Web browsers should either support or provide meaningful alternatives to bookmarkability and link sharing. Google Maps is a wonderful example of this, providing a “link to this map” icon that enables users to reproduce a complex map, complete with zoom level, map type, and current center point, simply by providing a URL.

Learning What Not to Do, All Over Again: Security in AJAX Applications

Some have argued that AJAX applications are necessarily more insecure than traditional Web applications, because they inherently expose a larger “attack surface.” While I’m not certain I agree with calling any broadly defined development approach inherently less secure – we’ve all seen how poor development practices can make any application prone to successful exploits – these critics are right to point to two specific concerns. These concerns are not in fact unique to AJAX development, but they do have to be

understood in new ways. First, never trust any data that comes from the client. This has been a truism of Web development from the beginning. In fact, this was true in client/server environments as well: just because it was much more difficult in client/server environments for someone to manipulate the client didn’t mean that client input shouldn’t be checked. The difference that an AJAX application introduces, as compared to a traditional Web application, is the fact that more data manipulation and processing can be done on the client, and more complex interactions can be expected between the client and server. The developer has to be aware that the threshold is fairly low for users to create alternate clients that return falsified, inaccurate, or (worse) deliberately malicious data. Any kind of Web input form was always already subject to such forgeries and attacks – but in an AJAX Web application you may have many more of them. While one might be tempted to assume that an HTTP request generated by a client-side JavaScript function deep within your complicated application is less likely to be forged than a simple Web form, but this is a slippery slope. Far better to assume that any input that comes from the client (either directly from the end user or from a JavaScript function) is guilty until proven otherwise. Second, don’t send data to the client that you don’t want the user to see. This has also been a Web truism from very early on. Many systems are careful in responding to failed logins to avoid giving more information than necessary about what went wrong – typically not telling you, for example, whether there is or isn’t a username matching what you entered, just that the username-password combination is invalid. The fact that AJAX offers the ability to do clientside form validation doesn’t mean that you can skip server-side validation (remember truism number one above), and it also doesn’t mean that you always should do client-side validation. Doing so will reveal to the user what the correct formats are. (In general this is not a bad thing – but if, as in one recent public example, what you are validating is a “discount code,” revealing that code to prying eyes is a no-no).

The Internet Is a Series of Tubes, and the Tubes Can Be Filled: Keeping Traffic Light

Figure 1:

16

Confirmation Dialog

May 2007

Another common complaint about Web applications that leverage AJAX is that they can be hard on the infrastructure: creating additional traffic through a higher number of requests and swelling bandwidth as large JavaScript files are downloaded. Although the increasing prevalence of broadband has made site download size less of a factor, it’s still critical

ajax.sys-con.com

Advertising Index



Advertiser

URL

Phone

Akamai

www.akamai.com/AJAX

7



BackBase

www.backbase.com

11



Cynergy Systems

www.cynergysystems.com

2-3



ICEsoft

www.icesoft.com

877-263-3822

17



JackBe

www.jackbe.com

240-744-7620

19



Laszlo

www.laszlosystems.com/go/webtop

4



NexaWeb

www.nexaweb.com

27



Passport

www.passportcorp.com

35



SoftwareAG

www.softwareag.com/Ajax

29



Telerik

www.telerik.com/prometheus

36



TIBCO

http://developer.tibco.com/

23

866-800-8996

800-926-6736

Page

Advertiser index is provided as an additional service to our readers. Publisher does not assume any liability for ommissions and/or misprints in this listing since this listing is not part of any insertion order.

that Web-based applications don’t ignore bandwidth consumption and traffic generation. AJAX developers should pay close attention to caching strategies, designing, segmenting, and combining code so that libraries of JavaScript can be aggressively cached on the client and don’t require frequent downloads. In addition, developers shouldn’t overlook compression options for JavaScript code. It’s also important to be cautious about the network travel your AJAX application generates. Remember that there are two important factors at play: actual performance and perceived performance. The actual performance is the volume of requests the Web server handles in a given unit of time, and it includes asynchronous JavaScript calls as well as the direct user-initiated clickstream. AJAX applications often increase the number of HTTP connections each client will make to the server, and may or may not

– continued from page 13 instantly available to users, eliminating desktop installations. And it’s a model that can be extended to applications across the enterprise. For example, as sophisticated analytics and business intelligence information are pushed further out into the enterprise, it is essential that applications deliver the information smoothly, clearly, and in an uninterrupted context. AJAX provides the foundation for user interfaces based on reusable components, each of which enables a set of UI functions that can be manipulated individually for or by the user. The flexibility inherent in AJAX-enabled applications translates into quick, easy rollouts of new functionality as user needs change, as well as the ability to customize the interface for users based on their roles and specific needs. Improving the user experience translates into a parallel improvement in the user’s ability to apply high-level information to the decision-making process,

18

May 2007

increase the number of requests each client makes. The perceived performance is much more difficult to measure, but has to do with how responsive users perceive the application to be. If certain requests are made asynchronously, they may appear more responsive when the user actually examines the data, having been “pre-fetched.” On the other hand, if the number of asynchronous calls going on is high, it may actually begin to negatively impact the users’ experience. The key is that at the end of the day, actual performance and perceived performance are tenuously linked: applications with lower actual performance may be perceived as having higher performance, and vice versa, depending on the end users’ experience. (Of course, there are infrastructure cost factors to the actual performance as well, perceptions aside.) Your best bet is to prototype rapidly, measure early, and improve iteratively. Don’t wait until the end of a cycle to discover that your application will saturate your connection or take prohibitively long to load.

The More Things Change…

All in all, the good news is that the principles that make well-designed AJAX applications aren’t radically different than those that have been best practices all along in Web-based applications. The new capabilities AJAX offers inevitably create scenarios where there is no clear design consensus and where the application of the principles requires careful planning, thoughtful design, and a fair amount of trial and error. But it sure beats DHTML and the “Stupid Browser Tricks” it forced on us. n

which is, after all, the goal of business intelligence. Organizations were moving applications to the Web even before the emergence of Web 2.0 and AJAX-based tools because cost savings were so attractive that they trumped the limitations of firstgeneration Web applications. Now, with Web 2.0 applications that provide a user experience equal to that of desktop applications, that trend is going to build momentum rapidly. For several years, enthusiasts have predicted that the impact of the Internet and the Web will rival that of the Industrial Revolution. Driven by the same need to use resources more effectively and increase productivity as that earlier transformation, Web 2.0 could make those predictions come true. But instead of centralizing workers and machines in factories, Web 2.0 will liberate a distributed, mobile workforce by offering consistent access to applications and information anywhere in the complex world of the global enterprise. n

ajax.sys-con.com

Facing a few barriers on the road to SOA?

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

Web:

www.jackbe.com

Phone: (240) 744-7620 Optimizing Business Activity

Email:

[email protected]

Inside Look

Oracle XE + AJAX: Asynchronous XML in Action

by Przemek Piotrowski and Mark Townsend

Building a real application

T

Przemek Piotrowski has been following Oracle 10g Express Edition (Oracle XE) development since its early beta stages back in 2005 and can easily distinguish the new features in this first database from Oracle that’s free to develop, deploy, and distribute. Oracle XE’s small footprint doesn’t stop him from taking advantage of many of its advanced features and plugging them into existing Web architectures.

Mark Townsend is vice-president of database product management in Oracle’s Server Technology Division. His responsibilities include requirement analysis, release planning, coordinating database product management activities, communicating with analysts and the press on database topics, and the development and delivery of field technical training. He was product boss for Oracle XE. Mark has been with Oracle since 1991 and has specialized in the Oracle database for over 15 years.

20

his article covers the process of building a real working AJAX application on top of Oracle’s free database software. The demonstration takes advantage of features integrated directly into Oracle Database 10g Express Edition (Oracle XE), the Embedded PL/SQL Gateway and Oracle XML DB, which let you serve XML content derived from SQL queries directly over HTTP protocol. You’ve probably run up against one of the numerous frameworks for AJAX that were probably Java- or .NET-based. Although they fit largescale environments perfectly, smaller projects may not require such overwhelming resources as a J2EE stack. Besides, understanding the technology behind XMLHttpRequest may help you use asynchronous requests better under just about any Web development environment. The concept is surprisingly simple – to make Web applications more responsive so that they behave like regular desktop software. Waiting for a page to reload just to see a change in a single place seems like a complete waste of both time and bandwidth. Having said that, using AJAX to create Web applications is good not only for the end user, but for the Web server as well. Applying this relatively simple technique boosts your Web applications’ usability many times. The potential of AJAX is so big that Web applications now have a real chance of replacing desktop programs without degrading the user experience.

Prerequisites

All you need is access to an Oracle XE database instance and its WebDAV folders. Oracle XE is much more than just a database server: Embedded PL/SQL Gateway makes it a regular Web server, while the built-in WebDAV and FTP listeners let you connect and store files served over HTTP directly through one of these protocols. This tutorial assumes that you have Oracle XE installed on your local computer. So that URLs refer to localhost, you may have to adjust it to fit your network’s configuration. I’ll be using the sample HR schema that ships with Oracle XE. By default it remains unlocked after instal-

May 2007

lation so you need to unlock it first using the SYSTEM account through SQL*Plus (this command will also set a new password for HR): SQL> alter user hr identified by hr account unlock;

User altered.

On Windows, accessing Oracle XE’s storage area is trivial with the Web Folder Access feature of Microsoft Internet Explorer; just select File > Open and type http://localhost:8080 in the address field and the Open as Web Folder checkbox. Then you’ll be prompted for a login and password. Supply hr twice here. If working under Linux or Windows you may choose to leverage the FTP server built into the XDB component of Oracle Database 10g. You activate it by connecting via SQL*Plus as SYSTEM and issuing the following commands: Connected to: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

SQL> exec dbms_xdb.setftpport(‘21’);

PL/SQL procedure successfully completed.

SQL> alter system register;

System altered.

The first command enables the FTP listener in the database, while the latter registers the just-activated listener on PMON (process monitor) without actually waiting for its 60-second refresh cycle. Now you can connect to the server with any FTP client or directly from the command line (ftp localhost). Now we can upload static files into the database storage area. What about dynamic content? The Embedded PL/ SQL Gateway – introduced for the first time within Oracle XE – enables you to access stored procedures directly from a Web location. Using the http://SERVER_ADDRESS:

ajax.sys-con.com

PORT/apex/SCHEMA_NAME.PROCEDURE_NAME syntax one can use PL/SQL stored procedures to trigger database events and generate content. For security reasons this feature has been disabled by default in Oracle XE so you have to unlock it first. Since this is a component of Application Express you have to modify the WWV_ FLOW_EPG_INCLUDE_MOD_LOCAL function inside the FLOWS_020100 schema. As shown in Listing 1, you have to make two changes: comment out the return false statement just after begin and add the name of a stored procedure you’d like to grant external access to (in this tutorial we’ll be running HR.AJAXE stored procedure listed later). (Listing 1-6 can be downloaded from the online version of this article at http://webddj.sys-con.com) This strict policy on running stored procedures prevents one from executing arbitrary PL/SQL code on the server side, which would be a major security risk. Using allowed procedure names makes it convenient to limit execution. To finalize this step, grant execute privileges on the AJAXE procedure to PUBLIC (in SQL*Plus while logged in as SYSTEM or HR): SQL> grant execute on hr.ajaxe to public;

Grant succeeded.

Figure 1:

Outputting XML from SQL Queries

You can generate XML directly from SQL queries using the PL/SQL package DBMS_XMLGEN, which doesn’t depend on Java and so is available on XE. The query process takes four basic steps: 1. Get the context by supplying a valid SQL query. 2. Set options on the newly created context using the DBMS_XMLGEN procedures (optional). 3. Get the XML result by using getXML() to get CLOB or getXMLType() to obtain XMLType. At this point you can also limit the number of rows returned by the XML engine using the setMaxRows() procedure on the context. 4. Reset the query to perform step 3 again or run closeContext() to free up allocated resources. Unfortunately DBMS_XMLGEN has one flaw that you’ll run up against almost immediately when working with remote XML – HTP.PRN, which will be used to print the output accepts strings of a VARCHAR2 type that can be 4,000 bytes long. This isn’t much for XML to deal with. The AJAX_XMLHTP procedure was created, which takes a context as a parameter and using the DBMS_LOB PL/SQL package outputs XML in 4,000-char chunks, leveraging the possibilities standing behind LOBs. (see Listing 2).

AJAX application concept

ajax.sys-con.com

May 2007

21

This procedure will handle all the processing work for us by setting the content type to text/xml (required by the XmlHttpRequest object for DOM processing), setting null handling to output empty tags for null values, and disabling pretty printing for smaller response size. Also, when something goes wrong at the query level, e.g., empty result set or invalid query, the procedure manually outputs the hard-coded “No data found” message to indicate its state. The AJAXE procedure will be a core dispatcher of responses. It will accept two parameters: q – the type of action requested, w – the extra parameter required for certain types of action (optional) (See Listing 3). The functionality of the sample application will be divided into three basic use cases: • Filling the SELECT list with elements obtained through the AJAX request and hooking the event handler to it • Obtaining the results set and rendering it into a HTML table dynamically • Using simple auto-complete on the HTML input field Note that both these procedures have to be created in the HR schema to work. At this point you can test whether the procedure is working for you by accessing http://localhost:8080/apex/hr.ajaxe?q=count (remember to adjust the URL to reflect your system’s configuration). A valid XML document should be outputted at this address. You’re halfway through.

Hands-on Document Object Model (DOM)

Table 1:

JavaScript Document Object Model

22

May 2007

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

ajax.sys-con.com

... ...

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

AJAX = Asynchronous JavaScript and XML

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

Table 2:

XmlHttpRequest object methods and properties

if (request.readyState == 4 && request.status == 200) {

24

May 2007

ajax.sys-con.com

callback(request.responseXML); } } request.send(null); }

The callback function will do all the DOM processing based on the XML content from the response. The callback works directly on the XMLDocument JavaScript object.

Putting It All Together

Now that we have all the building blocks of the solution, let’s take a look at the logic behind it. Figure 1 separates client side and server side into three separate blocks: Oracle XE, Web page, and browser client. Notice that the Web page has been separated here because of its state-dependent nature – thanks to AJAX it now incorporates the logic to handle user actions and transform them into HTTP requests; the standard Web model assumes that it’s the browser that dispatches HTTP requests to the Web server. That is the key concept in the solution. Take a look at Figure 1 to see the whole interaction process. 1. The browser client sends a direct HTTP request to the Web server (here: the Embedded PL/SQL Gateway of Oracle XE); the URL of the request has been supplied in the location bar or through a link. 2. Oracle XE serves a static HTML page that includes AJAX scripts. This static page is then rendered by the browser and now all the requests and interaction happen indirectly, as AJAX requests. 3. When the user triggers an event on the Web page by interacting with page elements such as forms and links, an event handler catches it and sends the appropriate HTTP request through the AJAX engine. 4. The XMLHttpRequest object requests a remote resource from the Embedded PL/SQL gateway. At this point, the user doesn’t have to wait for the script to finish fetching responses from the server; it’s handled in an asynchronous manner. The script takes as much time as needed to fetch the response while the user can further interact with the Web page. 5. The script performs DOM modifications in the background while the user can trigger the next events on the Web page. You can now upload the attached HTML file (hr-ajax-demo.html) into your XE instance through

ajax.sys-con.com

FTP or WebDAV, which contains the complete code for the sample application. After putting it into the /public/ folder of XE, open http://localhost:8080/ public/hr-ajax-demo.html with your Web browser. After carefully following all the steps of this tutorial the demo page should pre-load the list of departments and respond to user interaction almost immediately.

Advantages and Potential Problems

Although programming AJAX isn’t necessarily difficult, the question is whether asynchronous querying techniques are safe and production-ready. AJAX isn’t always a sure choice over standard development methodologies. There are at least several viewpoints to consider.

Advantages • • • •

Better user experience Greater responsiveness Smaller server load, increased performance Network applications can be updated on-the-fly without redistributing updates • Separation of content from presentation (easier maintenance)

Potential Problems

• Cross-browser incompatibilities • Client-side security concerns

The Real World

Today, AJAX applications are gaining a lot of steam. With Google leading this trend together and Yahoo! and Microsoft trailing, the desktop experience is delivered to users through increasingly dynamic Web pages. Since the early adoption of AJAX it has matured to be a full-blown solution often chosen by enterprises for commercial solutions. After the unification of DOM implementations and the adoption of World Wide Web Consortium (W3C) standards among developers of Web browsers, it’s now possible to create cross-platform Web applications more easily than ever before. With a wide range of available AJAX toolkits, developers can now upgrade Web applications to an asynchronous architecture at a low cost. AJAX is flexible enough to be plugged into existing solutions and greatly enhances usability. The movement of desktop applications to the Web is a matter of time and represents the next step in software evolution. n

May 2007

25

Listing 1

create or replace function wwv_flow_epg_include_mod_local(procedure_name in varchar2) return boolean is begin -- return false; -- remove this statement when you modify this function --- Administrator note: the procedure_name input parameter may be in the format: --procedure -schema.procedure -package.procedure -schema.package.procedure --- If the expected input parameter is a procedure name only, the IN list code shown below -- can be modified to itemize the expected procedure names. Otherwise you must parse the -- procedure_name parameter and replace the simple code below with code that will evaluate -- all of the cases listed above. -if upper(procedure_name) in ( ‘HR.AJAXE’) then return TRUE; else return FALSE; end if; end wwv_flow_epg_include_mod_local;

Listing 2

create or replace procedure ajax_xmlhtp(ctxt in number) as xml clob; chnk number := 4000; begin owa_util.mime_header(‘text/xml’); dbms_xmlgen.setnullhandling(ctxt, dbms_xmlgen.empty_tag); dbms_xmlgen.setprettyprinting(ctxt, false); xml := dbms_xmlgen.getxml(ctxt); for i in 1..ceil(length(xml)/chnk) loop htp.prn(dbms_lob.substr(xml, chnk+1, i+(i-1)*chnk)); end loop; dbms_xmlgen.closecontext(ctxt); exception when others then htp.print(‘’); htp.print(‘No data found.’); end; /

Listing 3

create or replace procedure ajaxe(q varchar2, w varchar2 default ‘’) as ctxt number; i number; begin if q=’count’ then ajax_xmlhtp(dbms_xmlgen.newcontext(‘select count(*) “EMPLOYEES” from employees’)); elsif q=’search’ then i := length(w); ctxt := dbms_xmlgen.newcontext(‘select * from employees where upper(substr(last_name, 0, :LEN))=upper(:PREFIX) order by last_name’); dbms_xmlgen.setbindvalue(ctxt, ‘LEN’, i); dbms_xmlgen.setbindvalue(ctxt, ‘PREFIX’, w); ajax_xmlhtp(ctxt); elsif q=’fetch’ then ajax_xmlhtp(dbms_xmlgen.newcontext(‘select * from employees’)); elsif q=’select’ then ajax_xmlhtp(dbms_xmlgen.newcontext(‘select department_id, department_name from departments order by 2’)); elsif q=’dept’ then

26

May 2007

ctxt := dbms_xmlgen.newcontext(‘select * from employees where department_id=:DEPT’); dbms_xmlgen.setbindvalue(ctxt, ‘DEPT’, w); ajax_xmlhtp(ctxt); end if; end; /

Listing 4

function ajaxTable(xml) { document.getElementById(‘q’).innerHTML = ‘’; var rows = xml.documentElement.getElementsByTagName(‘ROW’); var table = document.createElement(‘table’); var tbody = document.createElement(‘tbody’); table.setAttribute(‘border’, ‘1’); var tr = document.createElement(‘tr’); for (var h=0; h
Listing 5

...

HEADING1	HEADING2	...
ROW1, COLUMN1	ROW1, COLUMN2	ROW1, ...

Listing 6

var request = false; try { request = new XMLHttpRequest(); } catch(e) { try { request = new ActiveXObject(“Msxml2.XMLHTTP”); } catch (e2) { request = new ActiveXObject(“MSXML.XMLHTTP”); } }

ajax.sys-con.com

First Look

Quasar’s Nuqleo System Integrates AJAX into Enterprise Publishing Work flows improve, bottlenecks disappear when taking a Web-based approach

T

here are a couple of very common issues in enterprise publishing, and they almost invariably lead to bottlenecks. For example, if the designer is the only person who can modify a page layout, even minor changes will depend on his or her availability. If only a small number of people in a workgroup have the publishing know-how to prepare a publication for the printer, delays are likely to occur. Most enterprises have learned to live with these constraints in their document production because there just doesn’t seem to be a better way. In the typical publishing workflow, design modifications can only happen on a workstation equipped not only with the appropriate software, but also the necessary fonts for a document. Even graphic elements for a page layout are usually stored locally on the designer’s computer (very often simply on his desktop), until the files are prepared and transferred to the printer or service bureau. While this way of working may be acceptable in small workgroups, it can become extremely time-consuming when different departments or offices are involved in the document creation.

A Different Approach

Quasar’s Nuqleo system takes a different approach to solving these problems. By using modern Web technologies such as those common to the AJAX approach, the company managed to create a completely de-localized, browser-based system that allows users anywhere in the world to access data and documents, to contribute to the publishing workflow, and even to modify certain aspects of a page layout document without needing the software or the expertise of a designer. While the design files, images, and texts necessary for the design process are stored in a central server, Nuqleo manages access and user privileges in a sophisticated manner. In other words, if a user logs in with the necessary privileges to perform basic text editing, Nuqleo will not expose any other aspects of the workflow. This gives the system a lot of security against involuntary changes, and it also allows a high degree of flexibility in the management of documents.

28

This notion not only applies to texts, it extends to many aspects of page design as well. While Nuqleo relies on Adobe InDesign for page layout and typesetting, users with the appropriate privileges can access design files in a browser window and make explicitly authorized changes. One of the key advantages of Nuqleo is that it allows Web-based editing of text and design. This means that last-minute design changes can be made even when the page layout application is not present on the computer that participates in the editing process.

Flexibility and an Easy Learning Curve

Managing collaboration in this way provides companies with a considerable amount of flexibility, and also allows the administrator to define a system that has minimal training overhead, since only the functionality that is needed to complete a task is exposed to the user. The systems can be seen as a toolkit for modern publishing processes rather than a one-stop solution for magazine, book, or catalog publishers. By opening up very early on in the development process to the considerable complexities of modern enterprise publishing, the company managed to create a system that can speed up the enterprise content publishing workflow significantly.

Key Aspects

• De-localization: Users from around the world can log into the system and collaborate on a publication. • User Administration: Sophisticated support for internal users and external contributors allow an administrator to allocate precisely which documents, elements, or program functions can be accessed by a specific user. Nuqleo even manages contributors who are not allowed access to the system by managing external assignments via e-mail. • Web Editing: Most editing operations are conducted directly in the browser. Many aspects of a page can be modified without the need for a page layout application on the host computer.

May 2007

• Workflow Automation: Nuqleo allows simple construction of complex workflow scenarios. A visual workflow editor lets you combine any number of steps and conditional settings to cover every possible situation. • Phonetic Search: Proprietary search algorithms can find text even when exact spelling is unknown. (This is particularly important in multi-lingual projects.) • Visual Tagging: Allows fast access to visual information that can’t be captured by keywords. • Integrated Image Management: Nuqleo offers centralized picture management with automatic image quality control and IPTC/XMP metadata support. • Translation Management: Nuqleo supports translation management and can manage alternate designs, visuals, etc., for local markets. • Project Management: Built-in project management tools and a retro-planning module automatically manage documents from start to finish. • Publication Management: There are many different ways in which publications can be represented in the Nuqleo system. Through the flatplan manager, a publication can be displayed and updated in real time in a browser window. Different views let administrators check the status of different sections. Inserts and cover-mounted objects are also managed, and a highly realistic preview allows a user to display a publication and turn its pages on-screen Few providers of dedicated publishing systems have the necessary understanding of the complexities that enterprises face in their publishing tasks. There is no “typical” enterprise, and even less a “typical corporate publishing workflow.” Quasar provides a system that offers the flexibility and ease of use to be able to tackle the organizational issues so common in enterprise content production, collaboration, and automation – while also providing the necessary integration with other systems and environments if it is required. n

ajax.sys-con.com

If you thInk thIs Is a user-frIendly Interface let‘s talk

Imagine ajax with a human touch. Where ¬ coding is replaced by designing ¬ development is far beyond ‘trial and error‘ ¬ browser compatibility is built-in Benefit from ajax without coding by working with Crossvision application designer. The studio and runtime environment offers easy Web 2.0 development and enables rich web applications that match traditional desktop GUIs in terms of functionality and usability. More than 3,000 customers in 70 countries trust our solutions to maximize the value of their IT.

Software aG Take The Lead - LeT‘s TaLk! Free download at www.softwareag.com/ajax

Performance

Fast Scalable AJAX Apps

by Dylan Schiemann

Finding and eliminating bottlenecks and bloat

S

Dylan Schiemann is founding software engineer for Renkoo and co-founder of the Dojo Toolkit. He is best known for building web applications that make use of JavaScript, Dojo, and other common Web development technologies. He is the co-founder of SitePen, a consulting firm that specializes in designing custom web applications focused on outstanding user experience. Previously, he has developed web applications for Informatica, Security FrameWorks, and Vizional Technologies, to name a few. [email protected]

30

uccessful AJAX-based applications provide a better end-user experience than traditional Web sites. Fast performance is absolutely essential to deliver on this potential. The large number of technologies and the additional complexity that AJAX adds to the mix creates significant headaches in tracking down performance bottlenecks and related issues. So where do you start tracking down performance-related problems? The answer is logical: by delving into the raw performance data of your application. Perhaps a pedantic suggestion, but by not adequately analyzing and measuring the data, you’re relying only on hunches and past experience. Fortunately, we now have a number of highly useful open source and commercial tools available to assist us in this tedious process. The best place to begin a thorough search & destroy mission is with HTTP-level performance problems that can be resolved in server configuration and fine-tuning. Is the caching configured properly? Are there issues with load balancing? How many concurrent requests per server before performance suffers? AJAX applications typically reduce the data size per request, but highly aggressive polling can saturate your servers with too many requests. When using the Apache Web server, two useful open source tools are Apache Bench, which is great for concurrency testing, and Tsung, which provides a replay proxy mode to monitor system performance under a variety of scenarios. Similar commercial and open source tools exist for other Web servers as well. Push the limits of your servers and find out what makes them fall down. As AJAX applications become increasingly common, users expect real-time updates to accompany their real-time experience. To be effective, real-time or highly collaborative applications require a significant amount of AJAX polling to make the application work. If this is simply too demanding on your Web server, you may want to consider switching to a Comet server implementation such as Cometd, Lightstreamer, KnowNow, or lighttpd. Comet serv-

May 2007

ers are optimized for longer-lived connections and higher volumes of concurrency than typical Web servers. A general rule of thumb with polling: if the response time for a request is comparable to that of your polling interval, you’re either polling too frequently, or your server is taking too long to return useful information. The performance of SQL queries is essential to any AJAX application as is the Input/Output (I/O) performance of your database. Bonnie++ is a useful tool that helps you quickly track down disk I/O issues. SQL query performance is the topic of hundreds of articles, but sometimes simple EXPLAIN statements and a healthy dose of query log analysis will suffice to slow or eradicate performing queries. Analyzing performance over the Internet and verifying that you’re getting the correct data from the server to the browser is the next step in your quest. A number of tools exist to assist with this analysis. Wireshark, formerly known as Ethereal, is a network protocol analyzer that provides complete insight into all data across the wire for your computer or network. LiveHTTPHeaders, a Firefox extension, allows easy viewing of all normal HTTP traffic, XMLHttpRequests, and Comet traffic, including the viewing of full headers in the Firefox browser. Firebug, a debugging extension for Firefox, among its many capabilities, lets you view not only script errors and XMLHttpRequest information, but also measures the load times of various resources such as script and image files. For those of you waiting for me to get to the JavaScript-specific performance optimization techniques, we’ve arrived. With AJAX applications, many of our performance issues happen before we even get to the code that’s executed in the browser. Now that you have effectively ruled out issues outside the scope of the Web browser, it’s time to take a closer look at your JavaScript code. If you’re using an AJAX toolkit such as Dojo, you may already have profiling code to supplement Firebug. For example, a Dojo contributor recently found an instance where the

ajax.sys-con.com

code to create a chart was calling attr.nodeName. toLowerCase() 540,000 times, consuming 15s of time at page load! Moving this one line of code inside a loop drastically fixed the performance of the Dojo Charting component. Looking specifically for code that’s called a lot of times or that takes a lot of time per call are the first places to investigate. Seemingly harmless calls to code in your libraries can be expensive operations, especially when iteration, recursion, and/or large data sets come into play, and a quick performance profile will expose these resource hogs. It’s easy to get caught up in the excitement of using a solid JavaScript toolkit, and forgetting that your application doesn’t have to use every feature provided in your toolkit of choice! And even if the toolkit or browser lets you do something, it doesn’t mean it’s an effective use of system resources. For example, Dojo provides an excellent aspect-oriented programming (AOP) advice system for method-tomethod event connection. However, you should only be using this when necessary, not in every instance that one method needs to call another one, since the cost for each connect instance is more than a simple method-to-method call. Assuming that your toolkit has helped you avoid memory leak issues prevalent in Internet Explorer 6, and to a lesser extent Firefox 1.5, there’s still a limit on the number of objects that can be instantiated in memory at once in any browser before you experience a significant drag on performance. Our general experience is that Safari 1.2/2 allows the fewest number of objects, Internet Explorer 6/7 are better, and Opera and Firefox are significantly better than that. It would be great to see a quantitative study that compares the memory consumption and relative performance limits of object instantiation. In further evaluating browser performance, you should be looking for expensive operations that cause CPU spikes, excessive memory consumption, or leaks, and seek out alternative or more efficient approaches. Unfortunately, each major browser’s JavaScript and DOM implementations are different, and what works well in one browser doesn’t necessarily perform well in another. When looking at the initial page load time, significant consideration should be given to the number of requests and the size of each request being made on the server. One large file is preferable to a

ajax.sys-con.com

large number of small files, provided that you aren’t preloading a large amount of code that’s rarely used by your application. The Dojo package system and build tools solve this problem for Dojo users, and Dojo ShrinkSafe is useful with any JavaScript code. For image files, it’s worth considering the construction of image sprites to reduce the number of requests for small image files. Predictive auto-fetching of images is another optimization technique. This technique was made popular by the Google Maps team. In this application, images of locations just outside the boundaries of the currently viewable map region are loaded in the background after the application has finished loading. In analysis, it’s important to note that synchronous requests to a Web server block execution and give the user the perception of a hanging browser. So embracing best practices for asynchronous application development is crucial in creating sophisticated Web applications. That said, too many concurrent asynchronous requests can lead to similar issues, so appropriate queuing of requests is a good practice. Browser-specific issues are a significant reason for the proliferation of AJAX toolkits. Unfortunately, not every browser inconsistency is solved by your toolkit alone. For example, Internet Explorer by default enforces a two-connection limit per server, but it’s possible to work around this issue with the clever wildcard-masking of aliases. Additionally, caching of images loaded by JavaScript in Internet Explorer requires significant workarounds when your application design contains many image files. Browsers literally have thousands of quirks and idiosyncrasies, so starting with a good toolkit and regularly reading developer blogs and Web sites will keep you “in the know” on the latest workarounds. Given that AJAX applications are intended to be faster and more feature-rich than traditional Web sites, it’s imperative that speed and performance aren’t lost in the excitement of adding new capabilities to your existing app. I’ve only scratched the surface of what’s required and what’s possible in optimizing performance, but with a little patience, a good set of tools, and an understanding of HTTP and current browser issues, you’ll have a good process to begin eliminating performance issues before they turn into performance nightmares. n

May 2007

31

Inside Look

Pushing AJAX into High Gear A simple streaming AJAX example with the OpenAjax Hub, TIBCO GI, and DWR 2.0

F

ollow along and implement the real-time streaming AJAX system in Figure 1 using two different AJAX toolkits and the OpenAjax Hub.

Requirements

The requirements for this solution are straightforward. For this application we need a ready-made data grid control that will display changes in prices to stocks when those changes occur. A nice-to-have would be visual indicators in the GUI that show when a cell value in the grid is increasing or decreasing…and, of course, we want to deploy this to just a standard Web browser, so we also must do this without any reliance on plug-ins, applets, or ActiveX controls. (Thanks goodness this is an AJAX article!) Figure 1 shows the basic design that could be styled more at a later date. In addition we’ll want to add more AJAX controls to this page that can tap the same streaming stock data for other calculations and visuals, such as charts or portfolio totals. For now, we’ll keep it simple.

Architectural Design

We don’t have to build the above system from scratch, and can instead leverage readily available, reusable AJAX parts to get the job done quickly; the architectural strategy is to use AJAX pieces and parts that can work together. At the core of the system in Figure 2 is the OpenAjax Hub (see the OpenAjax Hub for Interop sidebar). We’ll use the OAA Hub as a central publish/subscribe bus to which we can publish the live stock data so that the data grid and the future visual controls and functions can listen for those events and messages.

Resources

Publish/Subscribe Core

Kevin Hakman is the co-founder of General Interface and director of developer evangelism for TIBCO Software Inc.

For our publish/subscribe core we’ll use the OpenAjax Hub, an open source project implementing the evolving OpenAjax Alliance Interoperability Working Group specifications. Start at HYPERLINK “http://www.openajax.org” www.openajax.org and follow the links to the sourceforge.net project from there.

by Kevin Hakman and Joe Walker

TIBCO General Interface, an open source AJAX project that currently provides ready-made AJAX controls for GUI, data, and communications in addition to visual tools for rapid AJAX application development, unit and functional testing, and AJAX debugging.

Real-Time Communications For our real-time data, we’ll use DWR 2.0, the just-released next version of Direct Web Remoting (DWR), an open source project that enables you to remote Java objects through JavaScript in the browser and now vice versa through its “Reverse AJAX” capabilities for real-time remote control of JavaScript objects in the browser via Java objects on the server across a persistent HTTP connection (a.k.a “Comet”).

Project Source Code You can quickly grab a copy of this project and all its parts from the 2.x release of DWR at http://getahead.org/dwr. Once you’ve installed DWR, check out the General Interface demo. Those who want to extend the GUI and add more controls should also download TIBCO General Interface from http:// developer.tibco.com/gi. Note that the OpenAjax.js file that ships with the project in the DWR download is an older, 46 kb version of the OpenAjax Hub. The latest version of the OpenAjax Hub, which now also implements a savvy topic-based event naming scheme over the basic pub/sub capability, is currently under 2 kb (yes two kilobytes – that’s not a typo).

Implementation The /gi/index.html file loads up the OpenAjax.js file, the needed DWR libraries, and some application specific files in the head of the HTML page. The body of the page includes a div that loads the TIBCO GI library.

<script type=”text/javascript” src=”JSX/js/JSX30.js”

Joe Walker is the creator of DWR and president of GetAhead Ltd, UK.

32

Ready-Made GUI Controls

For the GUI controls we’ll leverage those from

May 2007

jsxapppath=”gidemo” jsxlt=”true”>

ajax.sys-con.com

// But we are going for a fancy option that

The jsxapppath=”gidemo” loads the GI project in /gidemo and in turn renders the GUI component declaration: gidemo/components/appCanvas.xml. Once these are loaded, GI’s project init function is called:

ScriptProxy proxy = new

does highlighting

ScriptProxy(sessions);

for (var property in corporation) { if (property != “jsxid”) {

Corporation corp = corporations.get-

var ox = matrix.getContentElement(corp

NextChangedCorporation();

oration.jsxid, property);

proxy.addFunctionCall(“OpenAjax.publish”,

if (ox) { function giLoaded() {

“gidemo”, “corporation”, corp);

var current = ox.innerHTML;

OpenAjax.subscribe(“gidemo”, “corporation”, objectPublished); dwr.engine.setActiveReverseAjax(true); }

This subscribes to the OpenAjax Hub listening for publications to the ‘gidemo’ + ‘corporation’ topic. When a publish happens, the objectPublished function is called. The last line turns DWR’s Reverse AJAX on so that the data can flow from the server to the client without polling or waiting for the GI application running at the client to request an update from the server. The objectPublished function looks like this: function objectPublished(prefix, name, handlerData, corporation) { var matrix = giApp.getJSXByName(“matrix”); var inserted = matrix.getRecordNode(corpor ation.jsxid); matrix.insertRecord(corporation, null,

Figure 1:

inserted == null); matrix.repaintData();

Web-based real-time stock quotes implemented using TIBCO General Interface, the OpenAjax Hub, and the recently released DWR 2.0.

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

This simply takes the published data and inserts it into the GI matrix component. Each column of the matrix component is bound to a property of the corporation JavaScript object. The matrix control, its columns and bindings were configured using TIBCO GI’s visual tools: TIBCO General Interface Builder. There are a number of possible repaint strategies, including the simplest of them all: matrix.repaintData(); as shown above. However, to meet our requirements above, in the source below we’ve implemented a more sophisticated approach that enables both incremental painting of updated rows and cell highlighting. Instead of matrix.repaintData(); we’ve used this:

ox.style.backgroundColor = “#FDE4EB”; var callback = function(ele) { return function() { ele.style. backgroundColor = “#FFFFFF”; }; }(ox); setTimeout(callback, 1000); ox.innerHTML = corporation[property]; } } } } ...

Meanwhile, on the server the following Java code is running in a thread:

...

while (!Thread.currentThread().isInterrupt-

// There are many ways to get a table to

ed())

repaint.

{

// One easy way is to ask it to repaint: // matrix.repaintData();

Collection sessions = serverContext. getScriptSessionsByPage(“/dwr/gi/index. html”);

ajax.sys-con.com

Figure 2:

May 2007

System Architecture

33

int timeToSleep = random.nextInt(2500);

This simply finds the people viewing this page and creates a ScriptProxy to allow us to

Thread.sleep(timeToSleep); }

OpenAjax Hub for Interop

Two months ago in New York, immediately following AJAXWorld East 2007, the OpenAjax Alliance met and held its first InteropFest where a handful of the more than 75 industry members of the nascent AJAX standards organization demonstrated their technologies working in context of the first specification project of the alliance – the OpenAjax Hub (OAA Hub). If you haven’t been watching the evolution of this specification targeted at enabling AJAX libraries and controls to be interoperable, it’s rather interesting that at the core of the OAA Hub is a publish and subscribe event and message bus leveraging the tried and true interoperation approaches typical of server-side integration strategies, but instanced on the client side. Why is a “pub/sub” system at the core of the standard interoperation strategy for AJAX? With increasingly sophisticated AJAX software, mashups, and composite applications being built today, the pub/sub strategy makes developing such things simpler. Consider that when you have a system consisting of more than one part, and especially in such systems that may grow and change over time like mashups, portals with AJAX portlets, or composite applications, instead of writing procedural code for each part of the system that needs to work with another (which as you CS majors know, leads to the classic “nsquared” integration complexity problem), it’s far more efficient to implement a system for receiving, then dispatching events and messages so that one part can publish an event through the intermediary pub/sub hub, and then other parts that need information from that system can implement specific listeners that subscribe to, receive, and handle the events and messages.

push JavaScript to these users. The ScriptProxy is a feature of DWR 2.0 enabling DWR 2.0 to dynamically generate JavaScript from a Java API. This is done at runtime rather than compile time, so we can use it to remote control many browsers. This makes it very easy to write things like chat applications, or anything particularly dynamic. Messages are sent to clients across using DWR’s “Reverse AJAX” capability. We then ask the corporation’s object for a Stock price change, and publish this to the Open Ajax Hub. That’s it. Pretty simple. For the full source to all the files, including the TIBCO GI project files, see the source in the .war file download for DWR 2.0.

Other AJAX Controls

Changes to Java Objects are sent to DWR 2.0’s Reverse AJAX connection, and converted to JavaScript by DWR. In this case, the converted objects are wrapped in the OpenAjax Hub’s publish method so that when the pushed code arrives at the client, the OpenAjax Hub publishes the data to a message topic name. The JavaScript Objects, such as the TIBCO GI matrix GUI component, are coded to listen for new information on that topic and, in turn, handle the new information when it arrives.

Conclusion

Figure 3:

Comparison of a system of separate parts, integrated point to point versus a system integrated based on publish/subscribe events and messages.

As opposed to the more primitive DOM events such as onclick, onkeydown, onmouseover, and the like, typically these types of events and messages are associated with “application-level” concepts such as like “userLoggedIn”, “newCustomerCreated”, or “addNewStockSymbol”. Figure 3 compares a system with five parts directly linked to each other in a point-topoint fashion with a system implemented in a publish/subscribe message bus architecture. Architecting your AJAX applications using publish and subscribe techniques enables each part of the system to be decoupled from the others, and thus to be built and managed as distinct units. This modularization not only facilitates greater reuse and more efficient team development, but also helps you to avoid creating the hairballs of code typical of point-to-point architectural approaches to application systems. The more elements in a system, the most complex and expensive adding to and maintaining the system becomes in point-to-point architectures when compared to publish/subscribe bus architectures.

34

May 2007

The solution above demonstrates how easy it can be to implement powerful systems based on sound publish and subscribe architectural principles. Further, the decoupled nature of the publish and subscribe style implementation enables one piece of a system to be added or replaced without effecting other parts. Accordingly, this approach is highly applicable to mashup and AJAX portal scenarios. As shown, beyond the basics of using the emerging publish and subscribe standards of the OAA Hub to connect reusable client-side components, technologies, such as DWR 2.0’s Reverse AJAX and TIBCO’s just released Ajax Message Service for highly scalable real-time data over HTTP, are enabling publish and subscribe events to occur across the network. Accordingly, one can begin to think not of an HTML page in a browser connected to a server across a network, but instead the AJAX application running in the browser being in the same event cloud as the server, publishing to and subscribing from streams of information mediated by event bus architectures on the client and on the server, and, accordingly, enable you to build more powerful AJAX solutions. n ajax.sys-con.com