UNTIL SEPTEMBER 30, 2007 V~Y 2007 vC||VL 2 |SS|L 3 www.~.~`.SYSCC|.CCV How to Se|ect RlA 1echno|og|es 0e||ver|ng Next-Generat|on User lnterfaces Us|ng AIAX
Orac|e XE + AIAX: Asynchronous XML |n Act|on Past Sca|ab|e AIAX As 1-64 pushing into high gear Contact Us Address: 555 Not My Home St. Big City, CO 12345 Scary Question. Exactly who is developing your next app? Your App Starts Here. We are the leaders in RIA development services. INCREDIBLE APPLICATIONS PASSIONATE USERS PROVEN SUCCESS Unlock your potential with the help of industry leaders in Rich Internet Application development. 10 Years. 1400+ Customers. Your app starts here. C Y N E R G Y S Y S T E M S . C O M Contact Us Address: 555 Not My Home St. Big City, CO 12345 Scary Question. Exactly who is developing your next app? Your App Starts Here. We are the leaders in RIA development services. INCREDIBLE APPLICATIONS PASSIONATE USERS PROVEN SUCCESS Unlock your potential with the help of industry leaders in Rich Internet Application development. 10 Years. 1400+ Customers. Your app starts here. C Y N E R G Y S Y S T E M S . C O M March 2007 n6 TakingAJAXSeriously FromtheEditor by Roger Strukhoff n8 HowtoSelect RIATechnologies Choosingbetweentwopaths: AJAXorAdobe by Jeffrey S. Hammond n12 DeliveringNext-Generation UserInterfacesUsingAJAX Theuserexperienceisabsolutely centraltotheWeb2.0model by Rado Kotorov n16 AJAXDoneRight Or,howIlearnedtostopworrying andlovetheDOM by John Eckman n22 OracleXE+AJAX: AsynchronousXMLinAction Buildingarealapplication by Przemek Piotrowski and Mark Townsend n28 QuasarsNuqleoSystem IntegratesAJAXinto EnterprisePublishing Work fows improve, bottlenecks disappear when taking a Web-based approach n30 FastScalableAJAXApps Findingandeliminating bottlenecksandbloat by Dylan Schiemann n32 PushingAJAXintoHighGear AsimplestreamingAJAXexamplewiththe OpenAjaxHub,TIBCOGI,andDWR2.0 by Kevin Hakman and Joe Walker aJax.SyS-con.coM May 2007 I ts 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, its fun to watch technologies grow up, too. Some mature more quickly than others. Some mature too quickly and die out, while oth- ers never seem to mature at all. Over the past two years, AJAX as a general technological approach seems to be maturing very quickly. I wont bore this magazines savvy audience by recount- ing for the umpteenth time how, when, and by whom the term was coined, and I fully realize that many of you had been working sometimes for years with JavaScript, XML, and related languages and approaches before the term AJAX came into existence. What is important is that AJAX today is not the AJAX of early 2005. Seen origi- nally as part of a communitarian Web 2.0 culture that once again threatened to overturn the so-old, so-dated IT world of the past, AJAX is, in fact, now becoming an integral part of any serious enterprises approach to its IT infrastructure. Google Maps was seen as the quint- essential AJAX/Web 2.0 manifestation. Raucous start-ups such as YouTube, Digg, et al, with huge Web traffic numbers but precious few employees were seen as the way of the future. AJAX interfaces prom- ised to enhance the customer experience, leave old-fashioned Websites in the dust, and change the world. The trouble with revolutions, though, is that they burn out quickly and dont always manage to overthrow the existing order. Its too early to tell whether Web 2.0 is a revolution, a buzzword, or an inflec- tion point in the history of technology and civilization. Its easier to tell whats hap- pening with AJAX. Separating AJAX from Web 2.0 reveals a seriousness of purpose by AJAX proponents and developers, and a future that will be more about improv- ing existing infrastructures than trashing them. Improving the customer experience a key goal of AJAX can be measured by the very large and very serious companies that are now integrating AJAX into their front ends. How quickly can customers find what they need? How does the new efficiency aid clickthroughs, sales, and repeat sales? How does it improve the companys effort to develop and maintain a 360-degree customer view? How does this compare with competitors? How does it compare with potential competitors? All of these questions can be answered objectively and provide information much more concrete than that provided by a mere wow factor. As AJAX becomes less and less about wow and more and more about develop- ing traditional customer satisfaction, we can expect the market for AJAX technology providers to grow and grow. Enterprises are taking AJAX seriously. AJAX is no lon- ger some sort of revolutionary concept; it is becoming the way to do business. It seems as if AJAX has gone from being the cute kid, skipped those pesky teenage years, and become a very nice and pro- ductive young adult. This may seem like a terribly unglamorous statement to all of us who like to act like radicals now and then. But it strikes me as a beautiful thing. n From The Editor Group Publisher Roger Strukhoff Art Director Louis F. Cuffari Editor Nancy Valentine, 201 802-3044 nancy@sys-con.com
To submit a proposal for an article, go to http://grids.sys-con.com/proposal. Subscriptions E-mail: subscribe@sys-con.com U.S. Toll Free: 888 303-5282 International: 201 802-3012 Fax: 201 782-9600 Cover Price U.S. $5.99 U.S. $19.99 (12 issues/1 year) Canada/Mexico: $29.99/year International: $39.99/year Credit Card, U.S. Banks or Money Orders Back Issues: $12/each Editorial and Advertising Offices Postmaster: Send all address changes to: SYS-CON Media 577 Chestnut Ridge Road, Woodcliff Lake, NJ 07677
Worldwide Newsstand Distribution Curtis Circulation Company, New Milford, NJ List Rental Information Kevin Collopy: 845 731-2684, kevin.collopy@edithroman.com, Frank Cipolla: 845 731-3832, frank.cipolla@epostdirect.com Promotional Reprints Megan Mussa megan@sys-con.com Copyright 2007 by SYS-CON Publications, Inc. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechani- cal, including photocopy or any informa- tion storage and retrieval system, without written permission. AJAXWorld Magazine is published bimonthly (6 times a year) by SYS-CON Publications, Inc., 577 Chestnut Ridge Road, Woodcliff Lake, NJ 07677. SYS-CON Media and SYS-CON Publications, Inc., reserve the right to revise, republish, and authorize its readers to use the articles submitted for publication. TakingAJAX Seriously Roger Strukhoff 6 May 2007 aJax.SyS-con.coM Akamai makes AJAX sites perform 5X faster. Akamai delivers AJAX Websites up to 5x faster. Ensure every transaction is completed with optimal performance for each usereven for highly interactive sites. To learn more, download a new White Paper: Web 2.0 is HereIs Your Infrastructure Ready? Visit www.akamai.com/AJAX 2007 Akamai Technologies, Inc. The Akamai logo is a registered trademark of Akamai Technologies, Inc. All Rights Reserved As arrival and destination times are modified, flight information is updated in real-time. This instance of Google Maps dynamically updates as destination cities are chosen. As end users graphically edit price parameters, information within the main content area is dynamically updated. W hen it comes to rich Internet appli- cation (RIA) technologies, application development professionals must choose between two paths: AJAX or Adobe. AJAX is the best bet for experienced Web development shops looking to incrementally evolve existing Web applications. Of course, selecting AJAX also raises the question of whether to go with a homegrown, open source, or commercial AJAX framework. In contrast, Adobe is best for shops looking to completely transform their Web experiences. But to do so, firms must acquire the skills necessary to use Flex, which is the development framework for the Flash runtime environment. Early adopters with time-to-market concerns and comfort with either smaller vendors or open source can select AJAX with confidence. But firms that require support from a larger vendor and full-featured development tools will do better with Adobe. App dev professionals should make the selec- tion based on their time-to-market requirements, whether theyre looking to evolve or revolutionize their user experience, and whether they prefer tools from large established vendors. AJAX:TheFastLanetoa BetterUserExperience App dev organizations that prefer a fast path to RIAs for developers and users alike select AJAX for the following reasons: AJAX helps shops meet time-to-market needs. Developers with existing Web skills find that adopting AJAX involves a shift in design patterns, not a wholesale change in programming language or development tools. AJAX favors gradual re-factoring of existing Web apps. AJAX is based on open and standard lan- guages like JavaScript and XML. This makes it easy for developers to integrate AJAX widgets into exist- ing Web applications that are written in HTML, DHTML, or server-side JavaScript. AJAX can deliver speedy performance. Vendors of commercial AJAX frameworks like Backbase and JackBe invest considerable resources tuning their AJAX frameworks for speed because their clients have tiny footprints and download to browsers so quickly that theres no perceptible lag in app per- formance. Some open source AJAX tool kits share this trait, but others approach the size of Adobes 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: Its 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 frameworks rich widget set or light-speed performance, but architects will need to validate that the framework supports corporate standards for security, acces- sibility, service integration, and data access. Finding best-of-breed AJAX development tools is difficult. Experienced Web developers dont mind writing JavaScript and XML in text editors, but most developers in enterprise IT shops pre- fer visual designers and WYSIWYG editing tools. When it comes to AJAX, the only such tool support available at present is tied to commercial AJAX frameworks, meaning that the choice of one is necessarily a choice of the other. Cross-browser compatibility issues increase test- ing costs for AJAX. Testing costs increase in direct proportion to the number of browser platforms and versions to be supported. However, using a commercial AJAX framework can mitigate these costs, as the framework vendor incurs the cost of cross-browser testing. For example, Software AG certifies its cross-vision Application Composer on multiple versions of browsers like Internet Explorer, Mozilla, and Netscape. TheAJAXPathItselfForkswith Homegrown,OpenSource,and CommercialAlternatives Just because a development team has chosen to go with AJAX doesnt mean that its tool selection effort is complete. There remains the important Choosingbetweentwopaths:AJAXorAdobe Frameworks HowtoSelectRIATechnologies by Jeffrey S. Hammond Jeffrey Hammond is a senior analyst at Forrester Research where he covers tools and techniques for application design and development. 8 May 2007 aJax.SyS-con.coM decision of how many and what type of AJAX frame- works to use. Today there are three types: Many developers create their own frameworks. Development teams create their own AJAX wid- gets when they need customized controls that work in a specific way. Other developers build on top of open source frameworks. Open source communities engage in a constant process of peer review, which quickly separates good design from bad. This leads to successful projects maturing quickly, while poor frameworks lose critical mass. When selecting an open source framework, look for active develop- ment communities with committed corporate sponsors, as this is an indication of longevity. OpenLaszlo, Dojo, and the Google Web Toolkit (GWT), for example, are supported by corpo- rate sponsors like Laszlo Systems, IBM, AOL, and Google. Commercial frameworks provide a throat to choke. Commercial AJAX vendors provide sup- port and certification of their products, which is appealing for managers who are uncomfortable taking the open source route. They also focus on providing capabilities that enterprise developers require, including high-performance clients and tooling that makes it easy for developers to con- nect to enterprise applications. Just as there are myriad AJAX frameworks, there are also myriad AJAX framework selection criteria. These criteria fall into five buckets: customizability; security and accessibility; widget set; tooling; and cross-browser support. But not all of these criteria should be weighted equally (see Figure 1). AdobesSolutionIsPowerful,Predictable, andProductive Adobe is an attractive RIA solution because it combines powerful development tools (Flex) with a near-universal browser plug-in (Flash) thats designed to simplify RIA deployment. Managers who have concerns about small commercial AJAX provid- ers or support issues with open source AJAX frame- works consider Flex a safe alternative. But there is a downside: To be productive in Flex, developers have to learn two new languages and an extensive run- time framework something that can take between one and three months to learn. Once this initial hurdle is cleared, Adobe adopters see the following benefits: Widespread adoption of Flash speeds deploy- ment. When Flash is already installed, application deployment requires no additional changes to the users desktop. Unlike AJAX, Flash doesnt require browser-specific code or enablement of JavaScript in the users 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 con- text. 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 arent 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 stakehold- ers within hours. FlexDevelopersAreHardtoFindandOther DrawbacksofFlex But Adobe isnt perfect. App dev professionals should consider the following Adobe drawbacks: Flex developers are difficult to locate and com- mand 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 execu- tive 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 arent on the lat- est 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. SYS-CON Media President & CEO Fuat Kircaali, 201 802-3001 fuat@sys-con.com Group Publisher Roger Strukhoff, 201 802-3040 roger@sys-con.com
Production Lead Designer Louis F. Cuffari, 201 802-3035 louis@sys-con.com Art Director Alex Botero, 201 802-3031 alex@sys-con.com Associate Art Directors Tami Beatty, 201 802-3038 tami@sys-con.com Abraham Addo, 201 802-3037 abraham@sys-con.com
SYS-CON.COM Vice President Information Bruno Decaudin, 201 802-3051 bruno@sys-con.com Consultant, Information Systems Robert Diamond robert@sys-con.com Web Designers Stephen Kilmurray, 201 802-3053 stephen@sys-con.com Richard Walter, 201 802-3057 richard@sys-con.com
Customer Relations Circulation Service Coordinators Edna Earle Russell edna@sys-con.com Alicia Nolan, 201 802-3081 Alicia@sys-con.com aJax.SyS-con.coM May 2007 Flash is a broad graphical canvas, and Flex allows designers to push the boundaries of rich media further than AJAX does. This can lead to a situa- tion where users become distracted by a mix of Flashs rich media and Flexs new controls. IT orga- nizations can avoid this response by introducing rich media gradually and frequently conducting A/B testing with focus groups. WhichRIATechnologyIsBestforYou? When aggressive developers push the boundaries of RIA development, they quickly run into barriers that affect their ability to take full advantage of RIA technology. Firms interviewed recently by Forrester Research cited several barriers to their RIA develop- ment efforts that no tooling available today could overcome (see Figure 2). In selecting an RIA technology, application development professionals should choose AJAX when time-to-market is critical and updates are frequent. Experienced Web developers ramp up on AJAX quickly. AJAX also makes it easy to build RIA capabilities into existing apps with small, frequent releases. Finally, AJAXs 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 Flashs client footprint is larger than AJAX frameworks, its mar- ket penetration makes it the preferred deployment platform for larger, comprehensive RIAs. Adobe is a safe choice for those who put a high value on reliable support and product continuity, concerns that are key when making strategic technology investments. The downside is that safety comes at the price of openness. The benefits are clear: RIAs help users find and manipulate relevant content, complete complex transactions, and consume multimedia in the con- text of a larger app, providing improved customer experience, higher Web conversion rates, and thus improved revenues. While theres no one answer to the question of which to use, AJAX and Flex provide todays developers with options. n Figure 1: Figure 2: 10 May 2007 aJax.SyS-con.coM T R Y IT N O W ! Backbase Enterprise Ajax: The Complete Development Solution for Ajax 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 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 Download a free trial at www.backbase.com For more information, call 866-800-8996 (Americas); +31 20 465 8888 (ROW) Product Highlights B y any reckoning, the Internet and the World Wide Web have remade the way we do busi- ness. The ascendance of the Web-based enterprise has come to be seen as inevitable. But anyone who takes a hard look at the serious limita- tions of first-generation Web applications is likely to have a renewed sense of wonder at the spread of their adoption thus far. Users experimented with e-mail, instant messaging, and search engines and turned them into real communication, collabora- tion, and information-gathering tools. Those same business users endured their fitful interactions with static HTML pages and moved applications to the Web anyway because of the substantial savings promised by the shift. Now their patience is about to be rewarded. Emerging from a decade of groundwork is Web 2.0, which offers dramatic gains in productivity for indi- vidual workers and whole enterprises. Web 2.0 appli- cations are distributed collaborative tools available on-demand from any browser anywhere. And those tools are constructed to be at least as intuitive and easy-to-use as any application loaded on a desktop. Web 2.0 is based on many technologies most prominent among them being Web Services, Asynchronous JavaScript and XML (AJAX), Cascading Style Sheets (CSS), and Really Simple (Web) Syndication (RSS) and the list will continue to grow. Of these, AJAX has attracted the most atten- tion recently because its the technology that most effectively fills the gap between the user experience of Web and desktop applications. And the user experience is absolutely central to the Web 2.0 model. Web 2.0 applications must possess a set of user interface components that are as compelling and responsive as a desktop- based environment. Developers can no longer be satisfied to offer discontinuity in user experience, because widely distributed, frequently mobile users wont 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- mail. Web 2.0 and AJAX-based applications represent an opportunity to fully realize the Webs potential to make users smarter and more productive, and that opportunity extends to the most sophisticated back- end and analytic applications. HowWeGotHere:EvolutionaryStepsto Web2.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 Webs evolution, which can be summarized like this: Web 1.0 Content delivery and communication. This early stage changed the dissemination of information via two innovations, HTML pages and e-mail. Web 1.5 Content personalization and multi- level communication. Search and personalization made the spread of information more efficient, while chat rooms and instant messaging expand- ed communication in real-time. Web 2.0 Authoring and collaboration. This cur- rent stage is not about the dissemination of infor- mation, its about productivity accomplishing work-related tasks in a virtual space with tools and applications that are available anywhere, at any time, and can be shared collaboratively. In the past, Web applications lack of respon- siveness and dearth of controls offset most of their advantages as thin-client tools. In contrast, desk- top developers have historically taken advantage of two capabilities of Windows that make applications more intuitive and user-friendly than their Web counterparts: richness and responsiveness. When a complex and robust set of UI components is com- bined as they have been on the desktop, they make the user interface natural, informative, and intui- tive to use. And when the application and the user interface quickly adapt to user actions, they create an uninterrupted interaction. Windows applications TheuserexperienceisabsolutelycentraltotheWeb2.0model Web 2.0 DeliveringNext-Generation UserInterfacesUsingAJAX Rado Kotorov is a technical director of stra- tegic product management for Information Builders, Inc., responsible for emerging reporting, analytic, and visualization technologies. by Rado Kotorov 12 May 2007 aJax.SyS-con.coM dont 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 cant order three shirts instead of two without returning to page one, and then extend the problem to business users struggling with enterprise applica- tions throughout their workday. The difficulties of the interaction are compound- ed as the complexity of applications and user options increases. For example, imagine the user experience of writing a document in an application created in Web client/server mode. For each paragraph, the user must open a dialog, enter the text in the input box, and wait for the changes to be applied to the document when the page is refreshed. And then all the steps must be repeated for every edit or format change. The frustrated user needs plenty of patience and training to work with the tool. EnterAJAX 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 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 users experience. Transferring more of the interaction to the client side not only improves the workflow, it also allows the addition of enrich- ing UI components, which put AJAX-based Web applications on a par with desktop applications for usability. There are, it should be noted, alternatives to AJAX Adobes 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 AJAXs combination of cross-browser compatibility, zero footprint, and ability to provide interactive com- plexity to the user gives it a leg up on the competi- tive technologies. The improved interactivity of Web 2.0 applications is driving even more applications off the desktop, since the lower total cost of ownership now comes without the offsetting negatives of cumbersome user experience. These transitional Web 2.0 applica- tions enabled by AJAX have been productivity tools, such as word processing and e-mail applications, calendars and spreadsheets. Examples are Googles recently released Writely and Google Spreadsheets; competitive word processors like Zoho Writer, Abe Writeboard, and ajaxWrite; Num Sum spreadsheet functionality; and 30 boxes, a Web-based calendar. Web-based desktops are also emerging, like the one available at www.desktoptwo.com. Their lower TCO comes from centralizing most of the software in a single location on the server, with only a browser installed on desktops throughout the organization. This lowers installation and mainte- nance costs, provides for incremental upgrades to existing applications, creates user administration savings, and offers enterprise-wide control over doc- ument backup and archiving, as well as compliance and security. The Web 2.0 model makes applications continued on page 18 aJax.SyS-con.coM May 2007 13 T he Bad Old Days, or, I Walked a Hundred Miles to School, in the Snow, and It Was Uphill Both Ways Back in the late 90s, people started to use the term Dynamic HTML, often shortened to DHTML, to describe the use of JavaScript to manipulate HTML in the browser. Basic DHTML meant rollover images that changed state when you moused over them or drop-down menus that cascaded down from the top navigation. More complex DHTML concepts included dragging-and-dropping objects, hiding and revealing content, and even whole games built purely from HTML, images, and JavaScript. The problem with DHTML, of course, was that it was tremendously hard to do. More accurately, it was tremendously hard to do well in a cost-effective way. It was certainly possible to do some of the simpler functions (drop-down menus, mouseovers) in a reli- able cross-browser, cross-platform way. But anything more complicated than that quickly ran into the problem of alternate browser implementations: for example, using the layer tag for Netscape 4, but the iframe for Internet Explorer and newer Netscape/ Mozilla browsers. Similarly, Internet Explorer 5.x and later supported document.getElementByID() as did the Mozilla-based browsers, but Internet Explorer 4.x relied on document.all, and Netscape 4.x on document.layers. The whole experience got confusing rather quick- ly, leading to a number of different alternatives. Many individuals coded applications or sites directly to a single browser, leading to the phenome- non of Best Viewed in badges on sites. (I thought this behavior had gone the way of the blink tag, but Wal-Marts recent digital download site exhibited similar behavior for several weeks following the launch, the site greeted Firefox visitors with an apol- ogy: Were sorry. Our Web site requires the browser Internet Explorer version 6 or higher. It appears that youre using Firefox, Safari, or another browser that Wal-Mart Video Downloads doesnt currently sup- port. In early March, however, it appeared that the problems had been rectified.) Some JavaScript developers learned to create applications with a series of if-then statements pointing to specific versions for specific browsers, replicating the functionality in each major support- ed browser. Sometimes this led to unanticipated results, as when the tests were too specific (look- ing for a particular version of a particular browser) they often broke when new browsers were released. (Smarter developers learned to test for specific func- tionality, rather than looking for a particular browser version but this could still lead to a number of code branches for different browser levels.) Some Web designers found an alternative in Flash. Flash enabled designers to create animation, use sound, and create interactivity on the page without having to worry about browser versions and platforms. Because Macromedia (now Adobe) is the sole supplier of the Flash plug-in, it can offer com- plete control over the experience for both developers and users. Designers who resisted the urge to create monster intro movies and used Flash judiciously as a supplement to an HTML page, rather than as a replacement for it, found great power in the ability to add interactive elements and animation without having to decipher the complexities of DHTML. (A number of these first-generation Web designers abused Flashs power, creating unnecessary ani- mation, breaking the very interface conventions new Web users so desperately needed, and sticking introduction movies in front of Web pages, leading to the birth of the infamous Skip Intro button. See http://www.skipintro.nl/skipintro/ for a humorous version of the problem.) Finally, a significant number of information architects and Web designers simply learned to avoid DHTML altogether, or at least to avoid any of the more complicated functions. I remember seeing statements of work for Web development that either specifically excluded anything but the most basic DHTML or noted that DHTML use would increase risk and cost. If you didnt have the right JavaScript- and browser-savvy resources as part of your Web team, it was undoubtedly safer simply to stay away. Or,howIlearnedtostopworryingandlovetheDOM Solutions AJAXDoneRight by John Eckman John Eckman leads the Next Generation Internet Practice at Optaros (www.optaros. com), and has over a decade of experience designing and building Web applications for organizations ranging from small non-profit organizations to Fortune 500 enterprises. Johns technical background includes J2EE and .NET frameworks as well as scripting languages and presentation- tier development approaches, in addition to information architecture, usability test- ing, and project management. He received a BA from Boston University and a PhD from the University of Washington at Seattle; he expects to complete an MS in Information Systems from Northeastern University in 2006. He also achieved PMP certification in 2003. jeckman@optaros.com 14 May 2007 aJax.SyS-con.coM None of these approaches, of course, solved the core problem, or provided a repeatable, cost- effective (in terms of development and debug- ging time), standards-based, plug-in independent, cross-browser solution to browser-side interactiv- ity. TheresGottoBeaBetterWay:AJAX The solution, as readers of this publication undoubtedly recognize, came in the form of AJAX. As Ive written in an earlier article in these pages, Jesse James Garretts essay became such a perva- sive meme precisely because it appeared to cut the Gordian knot that had long plagued Web develop- ment using JavaScript. What Garretts AJAX did was to give a name to a series of approaches that had been many years in the works: As the user base of the old Netscape 4.x applica- tions waned, and the availability of new platforms rose, developers were emboldened by the relative ease of developing cross-browser standard applications with rich interaction in JavaScript and CSS, more and more developers started to create AJAX applications. Garretts essay crystallized this movement and gave it a name. While Garrett referred directly to the use of Asynchronous JavaScript and XML, the name is commonly applied to all kinds of uses of JavaScript for interactivity: some entirely syn- chronous, and many bypassing XML in favor of data representations like JSON. The point really is that the AJAX label effectively negated the fears associated with DHTML, and signaled to the development and design communities (as well as the customers who write the checks for site development) that it was now possible to build client-side interactivity without immense pain. Buoyed by the excitement over the Mozilla proj- ect, and the relative stability of the Document Object Model (DOM), a number of frameworks emerged to make AJAX-style development easier, abstract- ing away the plumbing to handle multiple browser implementations and interpretations. We have to be wary, however, of the assump- tion that just because developing AJAX-style Web applications has gotten easier, weve gotten better at developing them. Just as word processing software doesnt (in and of itself ) improve ones writing, having access to frameworks that facilitate AJAX-style development has increased the potential for users to develop truly both good usable applications and horrible unus- able applications. How can we avoid the Skip Intro phase of AJAX development and move right into the mature, stable, usable application era? First,DoNoHarm:Dont BreaktheBackButton Its crucial that while AJAX can make Web applications more like desktop applications, it should not remove the strengths of Web applications in the process or interfere in the fundamental architectures of the Web. This means, first and foremost, not breaking the conventions of back button use, bookmarking, and link sharing. Granted, these conventions may have different meaning in different applications, but they should be thoughtfully considered and only dis- rupted for a specific rationale. Full AJAX applications that provide rich interactive functionality but arent 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, Zimbras Collaboration Suite, a Microsoft Outlook- or Lotus Notes-style e-mail client and calendaring system, doesnt support the back button in the sense of allowing the user to click on the browsers 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 aJax.SyS-con.coM May 2007 1 in jumping back out of the application. However, Zimbra doesnt 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 users 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 didnt intend to navigate away, a simple cancel returns them to the active context without interruption. Googles Gmail, on the other hand, supports the back button by taking meaningful action when the user clicks it. If youre viewing your inbox and click on a particular message, Gmail loads that message in the center content pane. Click on the back button and you return to the inbox view. Because Gmail treats the different views in a fashion consistent with the Web-native page metaphor, it makes sense that the back button should funct ion this way. Similarly, applications that run in Web brows- ers should either support or provide meaningful alternatives to bookmarkability and link sharing. Google Maps is a wonderful example of this, pro- viding a link to this map icon that enables users to reproduce a complex map, complete with zoom level, map type, and current center point, simply by providing a URL. LearningWhatNottoDo,AllOverAgain: SecurityinAJAXApplications Some have argued that AJAX applications are nec- essarily more insecure than traditional Web applica- tions, because they inherently expose a larger attack surface. While Im not certain I agree with calling any broadly defined development approach inher- ently less secure weve all seen how poor develop- ment practices can make any application prone to successful exploits these critics are right to point to two specific concerns. These concerns are not in fact unique to AJAX development, but they do have to be understood in new ways. First, never trust any data that comes from the client. This has been a truism of Web development from the beginning. In fact, this was true in cli- ent/server environments as well: just because it was much more difficult in client/server environments for someone to manipulate the client didnt mean that client input shouldnt be checked. The difference that an AJAX application intro- duces, as compared to a traditional Web applica- tion, is the fact that more data manipulation and processing can be done on the client, and more complex interactions can be expected between the client and server. The developer has to be aware that the threshold is fairly low for users to create alternate clients that return falsified, inaccurate, or (worse) deliberately malicious data. Any kind of Web input form was always already subject to such forgeries and attacks but in an AJAX Web applica- tion you may have many more of them. While one might be tempted to assume that an HTTP request generated by a client-side JavaScript function deep within your complicated application is less likely to be forged than a simple Web form, but this is a slippery slope. Far better to assume that any input that comes from the client (either directly from the end user or from a JavaScript function) is guilty until proven otherwise. Second, dont send data to the client that you dont 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 isnt a username matching what you entered, just that the username-password combina- tion is invalid. The fact that AJAX offers the ability to do client- side form validation doesnt mean that you can skip server-side validation (remember truism number one above), and it also doesnt 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). TheInternetIsaSeriesofTubes,andthe TubesCanBeFilled:KeepingTraffcLight Another common complaint about Web applica- tions that leverage AJAX is that they can be hard on the infrastructure: creating additional traffic through a higher number of requests and swelling bandwidth as large JavaScript files are downloaded. Although the increasing prevalence of broadband has made site download size less of a factor, its still critical Figure 1: Confirmation Dialog 16 May 2007 aJax.SyS-con.coM that Web-based applications dont 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 dont require frequent downloads. In addition, develop- ers shouldnt overlook compression options for JavaScript code. Its also important to be cautious about the net- work travel your AJAX application generates. Remember that there are two important factors at play: actual performance and perceived performance. The actual performance is the volume of requests the Web server handles in a given unit of time, and it includes asynchronous JavaScript calls as well as the direct user-initiated clickstream. AJAX applications often increase the number of HTTP connections each client will make to the server, and may or may not increase the number of requests each client makes. The perceived performance is much more difficult to measure, but has to do with how responsive users perceive the application to be. If certain requests are made asynchronously, they may appear more respon- sive when the user actually examines the data, having been pre-fetched. On the other hand, if the number of asynchronous calls going on is high, it may actually begin to negatively impact the users experience. The key is that at the end of the day, actual per- formance and perceived performance are tenuously linked: applications with lower actual performance may be perceived as having higher performance, and vice versa, depending on the end users experience. (Of course, there are infrastructure cost factors to the actual performance as well, perceptions aside.) Your best bet is to prototype rapidly, measure early, and improve iteratively. Dont wait until the end of a cycle to discover that your application will saturate your connection or take prohibitively long to load. TheMoreThingsChange All in all, the good news is that the principles that make well-designed AJAX applications arent radi- cally different than those that have been best prac- tices all along in Web-based applications. The new capabilities AJAX offers inevitably create scenarios where there is no clear design consensus and where the application of the principles requires careful planning, thoughtful design, and a fair amount of trial and error. But it sure beats DHTML and the Stupid Browser Tricks it forced on us. n instantly available to users, eliminating desktop installations. And its a model that can be extended to applications across the enterprise. For example, as sophisticated analytics and busi- ness intelligence information are pushed further out into the enterprise, it is essential that applications deliver the information smoothly, clearly, and in an uninterrupted context. AJAX provides the foundation for user interfaces based on reusable components, each of which enables a set of UI functions that can be manipulated individually for or by the user. The flex- ibility inherent in AJAX-enabled applications translates into quick, easy rollouts of new functionality as user needs change, as well as the ability to customize the interface for users based on their roles and specific needs. Improving the user experience translates into a parallel improvement in the users ability to apply high-level information to the decision-making process, which is, after all, the goal of business intelligence. Organizations were moving applications to the Web even before the emergence of Web 2.0 and AJAX-based tools because cost savings were so attractive that they trumped the limitations of first- generation Web applications. Now, with Web 2.0 applications that provide a user experience equal to that of desktop applications, that trend is going to build momentum rapidly. For several years, enthusiasts have predicted that the impact of the Internet and the Web will rival that of the Industrial Revolution. Driven by the same need to use resources more effectively and increase productivity as that earlier transformation, Web 2.0 could make those predictions come true. But instead of centralizing workers and machines in factories, Web 2.0 will liberate a distributed, mobile workforce by offering consistent access to applications and information anywhere in the complex world of the global enterprise. n continued from page 13 Advertiser URL Phone Page Akamai www.akamai.com/AJAX 7 BackBase www.backbase.com 866-800-8996 11 Cynergy Systems www.cynergysystems.com 2-3 ICEsoft www.icesoft.com 877-263-3822 17 JackBe www.jackbe.com 240-744-7620 19 Laszlo www.laszlosystems.com/go/webtop 4 NexaWeb www.nexaweb.com 27 Passport www.passportcorp.com 800-926-6736 35 SoftwareAG www.softwareag.com/Ajax 29 Telerik www.telerik.com/prometheus 36 TIBCO http://developer.tibco.com/ 23 AdvertisingIndex 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. 18 May 2007 aJax.SyS-con.coM JackBes Rich Enterprise Application (REA) platform clears the road to SOA business benefits. Theres an abundance of products and vendors to help you create your SOA. Now, consume those SOA services with JackBe REAs to achieve the business productivity and results that led you to SOA in the first place. Our new REA platform combines the power of Ajax and SOA with reliable, secure communications to extend your SOA directly into powerful business applications. A fully visual IDE reduces manual coding and accelerates the development process. And our lightweight, vendor-neutral platform easily integrates with existing middleware and services while maintaining server-side governance and control--unlike products that leave governance to the browser or create middleware platform dependencies. Join over 35 industry leaders like Citigroup, the U.S. Defense Intelligence Agency, Sears, Tupperware, and Forbes who are already optimizing their business activity with JackBe solutions. Call or visit our websitelet us help you remove the barriers on the road to achieving real business value from your SOA investment. Facing a few barriers on the road to SOA? Web: www.jackbe.com Phone: (240) 744-7620 Email: info@jackbe.com Optimizing Business Activity T his article covers the process of building a real working AJAX application on top of Oracles 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. Youve probably run up against one of the numerous frameworks for AJAX that were proba- bly Java- or .NET-based. Although they fit large- scale environments perfectly, smaller projects may not require such overwhelming resources as a J2EE stack. Besides, understanding the technology behind XMLHttpRequest may help you use asynchronous requests better under just about any Web develop- ment environment. The concept is surprisingly simple to make Web applications more responsive so that they behave like regular desktop software. Waiting for a page to reload just to see a change in a single place seems like a com- plete waste of both time and bandwidth. Having said that, using AJAX to create Web applications is good not only for the end user, but for the Web server as well. Applying this relatively simple technique boosts your Web applications usability many times. The potential of AJAX is so big that Web applications now have a real chance of replacing desktop programs without degrading the user experience. Prerequisites All you need is access to an Oracle XE database instance and its WebDAV folders. Oracle XE is much more than just a database server: Embedded PL/SQL Gateway makes it a regular Web server, while the built-in WebDAV and FTP listeners let you connect and store files served over HTTP directly through one of these protocols. This tutorial assumes that you have Oracle XE installed on your local computer. So that URLs refer to localhost, you may have to adjust it to fit your networks configuration. Ill be using the sample HR schema that ships with Oracle XE. By default it remains unlocked after instal- 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 XEs 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 youll be prompt- ed for a login and password. Supply hr twice here. If working under Linux or Windows you may choose to leverage the FTP server built into the XDB component of Oracle Database 10g. You activate it by connecting via SQL*Plus as SYSTEM and issuing the following commands: Connected to: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production SQL> exec dbms_xdb.setftpport(21); PL/SQL procedure successfully completed. SQL> alter system register; System altered. The first command enables the FTP listener in the database, while the latter registers the just-activated listener on PMON (process monitor) without actually waiting for its 60-second refresh cycle. Now you can connect to the server with any FTP client or directly from the command line (ftp localhost). Now we can upload static files into the database storage area. What about dynamic content? The Embedded PL/ SQL Gateway introduced for the first time within Oracle XE enables you to access stored procedures directly from a Web location. Using the http://SERVER_ADDRESS: Buildingarealapplication Inside Look OracleXE+AJAX: AsynchronousXMLinAction 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 thats free to develop, deploy, and distribute. Oracle XEs small footprint doesnt stop him from taking advantage of many of its advanced features and plugging them into existing Web architectures. Mark Townsend is vice-president of data- base product management in Oracles Server Technology Division. His responsibil- ities include requirement analysis, release planning, coordinating database product management activities, communicating with analysts and the press on database topics, and the development and delivery of field technical training. He was product boss for Oracle XE. Mark has been with Oracle since 1991 and has specialized in the Oracle database for over 15 years. by Przemek Piotrowski and Mark Townsend 20 May 2007 aJax.SyS-con.coM PORT/apex/SCHEMA_NAME.PROCEDURE_NAME syn- tax one can use PL/SQL stored procedures to trigger data- base events and generate content. For security reasons this feature has been disabled by default in Oracle XE so you have to unlock it first. Since this is a component of Application Express you have to modify the WWV_ FLOW_EPG_INCLUDE_MOD_LOCAL function inside the FLOWS_020100 schema. As shown in Listing 1, you have to make two changes: comment out the return false state- ment just after begin and add the name of a stored proce- dure youd like to grant external access to (in this tutorial well be running HR.AJAXE stored procedure listed later). (Listing 1-6 can be downloaded from the online version of this article at http://webddj.sys-con.com) This strict policy on running stored procedures prevents one from executing arbitrary PL/SQL code on the server side, which would be a major security risk. Using allowed procedure names makes it con- venient to limit execution. To finalize this step, grant execute privileges on the AJAXE procedure to PUBLIC (in SQL*Plus while logged in as SYSTEM or HR): SQL> grant execute on hr.ajaxe to public; Grant succeeded. OutputtingXMLfromSQLQueries You can generate XML directly from SQL queries using the PL/SQL package DBMS_XMLGEN, which doesnt depend on Java and so is available on XE. The query process takes four basic steps: 1. Get the context by supplying a valid SQL query. 2. Set options on the newly created context using the DBMS_XMLGEN procedures (optional). 3. Get the XML result by using getXML() to get CLOB or getXMLType() to obtain XMLType. At this point you can also limit the number of rows returned by the XML engine using the setMaxRows() proce- dure on the context. 4. Reset the query to perform step 3 again or run closeContext() to free up allocated resources. Unfortunately DBMS_XMLGEN has one flaw that youll 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 isnt 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). Figure 1: 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 process- ing), setting null handling to output empty tags for null values, and disabling pretty printing for smaller response size. Also, when something goes wrong at the query level, e.g., empty result set or invalid query, the procedure manually outputs the hard-coded No data found message to indicate its state. The AJAXE procedure will be a core dispatcher of responses. It will accept two parameters: q the type of action requested, w the extra parameter required for certain types of action (optional) (See Listing 3). The functionality of the sample application will be divided into three basic use cases: Filling the SELECT list with elements obtained through the AJAX request and hooking the event handler to it Obtaining the results set and rendering it into a HTML table dynamically Using simple auto-complete on the HTML input field Note that both these procedures have to be created in the HR schema to work. At this point you can test whether the procedure is working for you by access- ing http://localhost:8080/apex/hr.ajaxe?q=count (remember to adjust the URL to reflect your systems configuration). A valid XML document should be out- putted at this address. Youre halfway through. Hands-onDocumentObjectModel(DOM) AJAX extensively relies on a set of JavaScript pro- gramming techniques once referred to as DHTML. But now theyre much more powerful thanks to the unification of the DOM implementation among Web browser vendors. Back in the days of Netscape Navigator 4 and Microsoft Internet Explorer 4 you had to use a different syntax for each browser to manipu- late page content dynamically. No need to do that anymore. The Document Object Model is a tree-like hierarchi- cal representation of nodes/HTML elements (see Table 1). The root node of an HTML document is the <html> tag that usually has two children: <head> and <body> the manipulations happen in the second. Since DOM is a vast subject, well focus only on the most useful properties and methods of JavaScript XML objects. For the complete DOM specification, see the W3C Web site at http://w3.org. Again, remember that there are a number of other JavaScript methods for working with the DOM object. For purposes of this article, an ajaxTable function was created: it builds up the HTML table from the XML response obtained through the AJAX request. By default DBMS_XMLGEN returns a XML tree of the following structure: Table 1: JavaScript Document Object Model 22 May 2007 aJax.SyS-con.coM <?xml version=1.0?> <ROWSET> <ROW> <COLUMN1></COLUMN1> <COLUMN2></COLUMN2> ... </ROW> ... </ROWSET> The code in Listing 4 represents the body of the ajaxTable function. This function appends the DOM tree in Listing 5 to the DIV element of ID=q (the TBODY element is required here to render properly under Internet Explorer). AJAX=AsynchronousJavaScriptandXML 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 isnt new either. It now plays a key role in data and informa- tion interchange and is universally adopted by both the enterprise and the open source community. The biggest problem with the Web was that applications needed a full-page refresh after each user action on the page. It didnt 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 whats happening under AJAXs hood. First, we need an XmlHttpRequest object that unfortunately still depends on the browser Microsoft Internet Explorer continues handling it using an ActiveX control so the appropriate requests object creation code is presented in Listing 6. This is the only part that requires browser-compatibility code. Everything else here is cross-browser. As for the handler, a dedicated function to handle all the asynchronous operations was created. It takes a request method, a URL, and callback functions as parameters. After the response is obtained the callback is immediately called with the fetched XML passed as an argument. function async(method, url, callback) { request.open(method, url, true); request.onreadystatechange = function() { if (request.readyState == 4 && request.status == 200) { Table 2: XmlHttpRequest object methods and properties 24 May 2007 aJax.SyS-con.coM callback(request.responseXML); } } request.send(null); } The callback function will do all the DOM process- ing based on the XML content from the response. The callback works directly on the XMLDocument JavaScript object. PuttingItAllTogether Now that we have all the building blocks of the solution, lets take a look at the logic behind it. Figure 1 separates client side and server side into three separate blocks: Oracle XE, Web page, and browser client. Notice that the Web page has been separated here because of its state-depen- dent nature thanks to AJAX it now incorporates the logic to handle user actions and transform them into HTTP requests; the standard Web model assumes that its the browser that dispatches HTTP requests to the Web server. That is the key concept in the solution. Take a look at Figure 1 to see the whole interaction process. 1. The browser client sends a direct HTTP request to the Web server (here: the Embedded PL/SQL Gateway of Oracle XE); the URL of the request has been supplied in the location bar or through a link. 2. Oracle XE serves a static HTML page that includes AJAX scripts. This static page is then rendered by the browser and now all the requests and interac- tion happen indirectly, as AJAX requests. 3. When the user triggers an event on the Web page by interacting with page elements such as forms and links, an event handler catches it and sends the appropriate HTTP request through the AJAX engine. 4. The XMLHttpRequest object requests a remote resource from the Embedded PL/SQL gateway. At this point, the user doesnt have to wait for the script to finish fetching responses from the server; its 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 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 depart- ments and respond to user interaction almost imme- diately. AdvantagesandPotentialProblems Although programming AJAX isnt necessarily dif- ficult, the question is whether asynchronous query- ing techniques are safe and production-ready. AJAX isnt 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) PotentialProblems Cross-browser incompatibilities Client-side security concerns TheRealWorld Today, AJAX applications are gaining a lot of steam. With Google leading this trend together and Yahoo! and Microsoft trailing, the desktop experi- ence is delivered to users through increasingly dynamic Web pages. Since the early adoption of AJAX it has matured to be a full-blown solution often chosen by enterprises for commercial solu- tions. After the unification of DOM implementations and the adoption of World Wide Web Consortium (W3C) standards among developers of Web brows- ers, its now possible to create cross-platform Web applications more easily than ever before. With a wide range of available AJAX toolkits, developers can now upgrade Web applications to an asyn- chronous architecture at a low cost. AJAX is flex- ible enough to be plugged into existing solutions and greatly enhances usability. The movement of desktop applications to the Web is a matter of time and represents the next step in software evolution. n aJax.SyS-con.coM May 2007 2 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(<?xml version=1.0?>); htp.print(<ROWSET><ROW><INFO>No data found.</INFO></ROW></ ROWSET>); 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, depart- ment_name from departments order by 2)); elsif q=dept then 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<rows[0].childNodes.length; h++) { if (rows[0].childNodes[h].nodeType!=1) { continue; } var th = document.createElement(th); th.appendChild(document.createTextNode(rows[0].childNodes[h].ta gName)); tr.appendChild(th); } tbody.appendChild(tr); for (var i=0; i<rows.length; i++) { var tr = document.createElement(tr); for (var j=0; j<rows[i].childNodes.length; j++) { if (rows[i].childNodes[j].nodeType!=1) { continue; } var td = document.createElement(td); if (rows[i].childNodes[j].childNodes.length!=0) { td.appendChild(document.createTextNode(rows[i].childNodes[j].first- Child.nodeValue)); } else { td.appendChild(document.createTextNode(-)); } tr.appendChild(td); } tbody.appendChild(tr); } table.appendChild(tbody); document.getElementById(q).appendChild(table); } Listing 5 <table border=1> <tbody> <tr> <th>HEADING1</th> <th>HEADING2</th> <th>...</th> </tr> <tr> <td>ROW1, COLUMN1</td> <td>ROW1, COLUMN2</td> <td>ROW1, ...</td> </tr> ... </tbody> </table> Listing 6 var request = false; try { request = new XMLHttpRequest(); } catch(e) { try { request = new ActiveXObject(Msxml2.XMLHTTP); } catch (e2) { request = new ActiveXObject(MSXML.XMLHTTP); } } 26 May 2007 aJax.SyS-con.coM T here are a couple of very common issues in enterprise publishing, and they almost invariably lead to bottlenecks. For exam- ple, if the designer is the only person who can modify a page layout, even minor changes will depend on his or her availability. If only a small number of people in a workgroup have the pub- lishing know-how to prepare a publication for the printer, delays are likely to occur. Most enter- prises have learned to live with these constraints in their document production because there just doesnt seem to be a better way. In the typical publishing workflow, design modifications can only happen on a worksta- tion equipped not only with the appropriate software, but also the necessary fonts for a document. Even graphic elements for a page layout are usually stored locally on the designers computer (very often simply on his desktop), until the files are prepared and transferred to the printer or service bureau. While this way of working may be accept- able in small workgroups, it can become extremely time-consuming when different departments or offices are involved in the document creation. ADifferentApproach Quasars Nuqleo system takes a different approach to solving these problems. By using modern Web technologies such as those com- mon to the AJAX approach, the company managed to create a completely de-local- ized, browser-based system that allows users anywhere in the world to access data and documents, to contribute to the publishing workflow, and even to modify certain aspects of a page layout document without needing the software or the expertise of a designer. While the design files, images, and texts neces- sary for the design process are stored in a central server, Nuqleo manages access and user privileges in a sophisticated manner. In other words, if a user logs in with the necessary privileges to perform basic text editing, Nuqleo will not expose any other aspects of the workflow. This gives the sys- tem a lot of security against involuntary changes, and it also allows a high degree of flexibility in the management of documents. This notion not only applies to texts, it extends to many aspects of page design as well. While Nuqleo relies on Adobe InDesign for page layout and typesetting, users with the appropriate privileges can access design files in a browser window and make explicitly authorized changes. One of the key advantages of Nuqleo is that it allows Web-based editing of text and design. This means that last-minute design changes can be made even when the page layout application is not present on the com- puter that participates in the editing process.
FlexibilityandanEasy LearningCurve Managing collaboration in this way pro- vides companies with a considerable amount of flexibility, and also allows the administrator to define a system that has minimal training over- head, since only the functionality that is needed to complete a task is exposed to the user. The systems can be seen as a toolkit for modern publishing processes rather than a one-stop solution for magazine, book, or catalog publishers. By opening up very early on in the development process to the con- siderable complexities of modern enterprise publishing, the company managed to create a system that can speed up the enterprise content publishing workflow significantly. KeyAspects De-localization: Users from around the world can log into the system and collabo- rate on a publication. User Administration: Sophisticated sup- port for internal users and external con- tributors allow an administrator to allocate precisely which documents, elements, or program functions can be accessed by a specific user. Nuqleo even manages con- tributors who are not allowed access to the system by managing external assignments via e-mail. Web Editing: Most editing operations are con- ducted directly in the browser. Many aspects of a page can be modified without the need for a page layout application on the host computer. Workflow Automation: Nuqleo allows simple construction of complex workflow scenarios. A visual workflow editor lets you combine any number of steps and conditional settings to cover every possible situation. Phonetic Search: Proprietary search algo- rithms can find text even when exact spell- ing is unknown. (This is particularly impor- tant in multi-lingual projects.) Visual Tagging: Allows fast access to visual information that cant be captured by key- words. Integrated Image Management: Nuqleo offers centralized picture management with automatic image quality control and IPTC/XMP metadata support. Translation Management: Nuqleo sup- ports translation management and can manage alternate designs, visuals, etc., for local markets. Project Management: Built-in project man- agement tools and a retro-planning mod- ule automatically manage documents from start to finish. Publication Management: There are many different ways in which publications can be represented in the Nuqleo system. Through the flatplan manager, a publication can be displayed and updated in real time in a browser window. Different views let admin- istrators check the status of different sec- tions. Inserts and cover-mounted objects are also managed, and a highly realistic preview allows a user to display a publica- tion and turn its pages on-screen Few providers of dedicated publishing systems have the necessary understanding of the complexities that enterprises face in their publishing tasks. There is no typical enterprise, and even less a typical corporate publishing workflow. Quasar provides a system that offers the flexibility and ease of use to be able to tack- le the organizational issues so common in enterprise content production, collaboration, and automation while also providing the necessary integration with other systems and environments if it is required. n Work flows improve, bottlenecks disappear when taking a Web-based approach First Look QuasarsNuqleoSystemIntegratesAJAXintoEnterprisePublishing 28 May 2007 aJax.SyS-con.coM If you thInk thIs Is a user-frIendly Interface - lets talk Software aG Take The Lead - LeTs 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 Beneft from ajax without coding by working with Crossvision application designer. The studio and runtime environment offers easy Web 2.0 develop- ment and enables rich web applications that match traditional desktop GUIs in terms of functionality and usability. More than 3,000 customers in 70 countries trust our solutions to maximize the value of their IT. Free download at www.softwareag.com/ajax S uccessful AJAX-based applications provide a better end-user experience than traditional Web sites. Fast performance is absolutely essential to deliver on this potential. The large num- ber of technologies and the additional complexity that AJAX adds to the mix creates significant head- aches in tracking down performance bottlenecks and related issues. So where do you start tracking down perfor- mance-related problems? The answer is logical: by delving into the raw performance data of your application. Perhaps a pedantic suggestion, but by not adequately analyzing and measuring the data, youre relying only on hunches and past experience. Fortunately, we now have a number of highly useful open source and commercial tools available to assist us in this tedious process. The best place to begin a thorough search & destroy mission is with HTTP-level performance problems that can be resolved in server configura- tion and fine-tuning. Is the caching configured prop- erly? Are there issues with load balancing? How many concurrent requests per server before performance suffers? AJAX applications typically reduce the data size per request, but highly aggressive polling can saturate your servers with too many requests. When using the Apache Web server, two useful open source tools are Apache Bench, which is great for concurrency testing, and Tsung, which provides a replay proxy mode to monitor system performance under a variety of scenarios. Similar commercial and open source tools exist for other Web servers as well. Push the limits of your servers and find out what makes them fall down. As AJAX applications become increasingly com- mon, users expect real-time updates to accompany their real-time experience. To be effective, real-time or highly collaborative applications require a sig- nificant amount of AJAX polling to make the appli- cation work. If this is simply too demanding on your Web server, you may want to consider switching to a Comet server implementation such as Cometd, Lightstreamer, KnowNow, or lighttpd. Comet serv- 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, youre either polling too frequently, or your server is taking too long to return useful information. The performance of SQL queries is essential to any AJAX application as is the Input/Output (I/O) performance of your database. Bonnie++ is a use- ful tool that helps you quickly track down disk I/O issues. SQL query performance is the topic of hun- dreds of articles, but sometimes simple EXPLAIN statements and a healthy dose of query log analysis will suffice to slow or eradicate performing queries. Analyzing performance over the Internet and verifying that youre getting the correct data from the server to the browser is the next step in your quest. A number of tools exist to assist with this analysis. Wireshark, formerly known as Ethereal, is a network protocol analyzer that provides com- plete insight into all data across the wire for your computer or network. LiveHTTPHeaders, a Firefox extension, allows easy viewing of all normal HTTP traffic, XMLHttpRequests, and Comet traffic, includ- ing the viewing of full headers in the Firefox browser. Firebug, a debugging extension for Firefox, among its many capabilities, lets you view not only script errors and XMLHttpRequest information, but also measures the load times of various resources such as script and image files. For those of you waiting for me to get to the JavaScript-specific performance optimization tech- niques, weve arrived. With AJAX applications, many of our performance issues happen before we even get to the code thats executed in the browser. Now that you have effectively ruled out issues outside the scope of the Web browser, its time to take a closer look at your JavaScript code. If youre 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 Findingandeliminatingbottlenecksandbloat Performance FastScalableAJAXApps Dylan Schiemann is founding software engineer for Renkoo and co-founder of the Dojo Toolkit. He is best known for building web applications that make use of JavaScript, Dojo, and other common Web development technologies. He is the co-founder of SitePen, a consulting firm that specializes in designing custom web applications focused on outstanding user experience. Previously, he has developed web applications for Informatica, Security FrameWorks, and Vizional Technologies, to name a few. dylan@sitepen.com by Dylan Schiemann 30 May 2007 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 thats 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. Its easy to get caught up in the excitement of using a solid JavaScript toolkit, and forgetting that your application doesnt have to use every feature provided in your toolkit of choice! And even if the toolkit or browser lets you do something, it doesnt mean its an effective use of system resources. For example, Dojo provides an excellent aspect-oriented programming (AOP) advice system for method-to- method event connection. However, you should only be using this when necessary, not in every instance that one method needs to call another one, since the cost for each connect instance is more than a simple method-to-method call. Assuming that your toolkit has helped you avoid memory leak issues prevalent in Internet Explorer 6, and to a lesser extent Firefox 1.5, theres still a limit on the number of objects that can be instantiated in memory at once in any browser before you experi- ence a significant drag on performance. Our gen- eral experience is that Safari 1.2/2 allows the fewest number of objects, Internet Explorer 6/7 are better, and Opera and Firefox are significantly better than that. It would be great to see a quantitative study that compares the memory consumption and relative performance limits of object instantiation. In further evaluating browser performance, you should be looking for expensive operations that cause CPU spikes, excessive memory consumption, or leaks, and seek out alternative or more efficient approaches. Unfortunately, each major browsers JavaScript and DOM implementations are different, and what works well in one browser doesnt neces- sarily perform well in another. When looking at the initial page load time, sig- nificant consideration should be given to the num- ber of requests and the size of each request being made on the server. One large file is preferable to a large number of small files, provided that you arent preloading a large amount of code thats 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, its worth considering the con- struction of image sprites to reduce the number of requests for small image files. Predictive auto-fetching of images is another optimization technique. This technique was made popular by the Google Maps team. In this applica- tion, images of locations just outside the boundaries of the currently viewable map region are loaded in the background after the application has finished loading. In analysis, its important to note that synchro- nous requests to a Web server block execution and give the user the perception of a hanging browser. So embracing best practices for asyn- chronous application development is crucial in creating sophisticated Web applications. That said, too many concurrent asynchronous requests can lead to similar issues, so appropriate queuing of requests is a good practice. Browser-specific issues are a significant reason for the proliferation of AJAX toolkits. Unfortunately, not every browser inconsistency is solved by your toolkit alone. For example, Internet Explorer by default enforces a two-connection limit per server, but its possible to work around this issue with the clever wildcard-masking of aliases. Additionally, caching of images loaded by JavaScript in Internet Explorer requires significant workarounds when your appli- cation design contains many image files. Browsers literally have thousands of quirks and idiosyncrasies, so starting with a good toolkit and regularly reading developer blogs and Web sites will keep you in the know on the latest workarounds. Given that AJAX applications are intended to be faster and more feature-rich than traditional Web sites, its imperative that speed and performance arent lost in the excitement of adding new capa- bilities to your existing app. Ive only scratched the surface of whats required and whats possible in optimizing performance, but with a little patience, a good set of tools, and an understanding of HTTP and current browser issues, youll have a good process to begin eliminating performance issues before they turn into performance nightmares. n aJax.SyS-con.coM May 2007 31 F ollow along and implement the real-time streaming AJAX system in Figure 1 using two different AJAX toolkits and the OpenAjax Hub. Requirements The requirements for this solution are straight- forward. For this application we need a ready-made data grid control that will display changes in prices to stocks when those changes occur. A nice-to-have would be visual indicators in the GUI that show when a cell value in the grid is increasing or decreas- ingand, of course, we want to deploy this to just a standard Web browser, so we also must do this without any reliance on plug-ins, applets, or Active- X controls. (Thanks goodness this is an AJAX article!) Figure 1 shows the basic design that could be styled more at a later date. In addition well 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, well keep it simple. ArchitecturalDesign We dont 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). Well use the OAA Hub as a cen- tral publish/subscribe bus to which we can publish the live stock data so that the data grid and the future visual controls and functions can listen for those events and messages. Resources Publish/Subscribe Core For our publish/subscribe core well use the OpenAjax Hub, an open source project implement- ing the evolving OpenAjax Alliance Interoperability Working Group specifications. Start at HYPERLINK http://www.openajax.org www.openajax.org and follow the links to the sourceforge.net project from there. Ready-Made GUI Controls For the GUI controls well leverage those from TIBCO General Interface, an open source AJAX proj- ect that currently provides ready-made AJAX controls for GUI, data, and communications in addition to visual tools for rapid AJAX application development, unit and functional testing, and AJAX debugging. Real-Time Communications For our real-time data, well use DWR 2.0, the just-released next version of Direct Web Remoting (DWR), an open source project that enables you to remote Java objects through JavaScript in the browser and now vice versa through its Reverse AJAX capabilities for real-time remote control of JavaScript objects in the browser via Java objects on the server across a persistent HTTP connection (a.k.a Comet). Project Source Code You can quickly grab a copy of this project and all its parts from the 2.x release of DWR at http://geta- head.org/dwr. Once youve installed DWR, check out the General Interface demo. Those who want to extend the GUI and add more controls should also download TIBCO General Interface from http:// developer.tibco.com/gi. Note that the OpenAjax.js file that ships with the project in the DWR down- load is an older, 46 kb version of the OpenAjax Hub. The latest version of the OpenAjax Hub, which now also implements a savvy topic-based event naming scheme over the basic pub/sub capability, is cur- rently under 2 kb (yes two kilobytes thats not a typo). Implementation The <dwr>/gi/index.html file loads up the OpenAjax.js file, the needed DWR libraries, and some application specific files in the head of the HTML page. The body of the page includes a div that loads the TIBCO GI library. <div style=width:100%; height:220px;> <script type=text/javascript src=JSX/js/JSX30.js jsxapppath=gidemo jsxlt=true> </script> </div> AsimplestreamingAJAXexamplewiththe OpenAjaxHub,TIBCOGI,andDWR2.0 Inside Look PushingAJAXintoHighGear by Kevin Hakman and Joe Walker Kevin Hakman is the co-founder of General Interface and director of developer evange- lism for TIBCO Software Inc. Joe Walker is the creator of DWR and presi- dent of GetAhead Ltd, UK. 32 May 2007 aJax.SyS-con.coM The jsxapppath=gidemo loads the GI project in /gidemo and in turn renders the GUI component declaration: gidemo/compo- nents/appCanvas.xml. Once these are loaded, GIs project init function is called:
function giLoaded() { OpenAjax.subscribe(gidemo, corporation, objectPublished); dwr.engine.setActiveReverseAjax(true); } This subscribes to the OpenAjax Hub lis- tening for publications to the gidemo + cor- poration topic. When a publish happens, the objectPublished function is called. The last line turns DWRs Reverse AJAX on so that the data can flow from the server to the client without polling or waiting for the GI applica- tion running at the client to request an update from the server. The objectPublished function looks like this: function objectPublished(prefix, name, han- dlerData, corporation) { var matrix = giApp.getJSXByName(matrix); var inserted = matrix.getRecordNode(corpor ation.jsxid); matrix.insertRecord(corporation, null, inserted == null); matrix.repaintData(); } 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 GIs 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 weve implemented a more sophisticated approach that enables both incremental painting of updated rows and cell highlighting. Instead of matrix.repaintData(); weve used this: ... // There are many ways to get a table to repaint. // One easy way is to ask it to repaint: // matrix.repaintData(); // But we are going for a fancy option that does highlighting for (var property in corporation) { if (property != jsxid) { var ox = matrix.getContentElement(corp oration.jsxid, property); if (ox) { var current = ox.innerHTML;
if (current != + corporation[property]) { 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- ed()) { Collection sessions = serverContext. getScriptSessionsByPage(/dwr/gi/index. html); ScriptProxy proxy = new ScriptProxy(sessions); Corporation corp = corporations.get- NextChangedCorporation(); proxy.addFunctionCall(OpenAjax.publish, gidemo, corporation, corp);
Figure 1: Web-based real-time stock quotes implemented using TIBCO General Interface, the OpenAjax Hub, and the recently released DWR 2.0. Figure 2: System Architecture aJax.SyS-con.coM May 2007 33 int timeToSleep = random.nextInt(2500); Thread.sleep(timeToSleep); } This simply finds the people viewing this page and creates a ScriptProxy to allow us to 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 com- pile time, so we can use it to remote control many browsers. This makes it very easy to write things like chat applications, or anything par- ticularly dynamic. Messages are sent to clients across using DWRs Reverse AJAX capability. We then ask the corporations object for a Stock price change, and publish this to the Open Ajax Hub. Thats 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. OtherAJAXControls Changes to Java Objects are sent to DWR 2.0s Reverse AJAX connection, and converted to JavaScript by DWR. In this case, the convert- ed objects are wrapped in the OpenAjax Hubs 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 The solution above demonstrates how easy it can be to implement powerful systems based on sound publish and subscribe archi- tectural principles. Further, the decoupled nature of the publish and subscribe style implementation enables one piece of a sys- tem to be added or replaced without effect- ing 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.0s Reverse AJAX and TIBCOs just released Ajax Message Service for highly scal- able 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 OpenAjaxHubforInterop 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 havent been watching the evolution of this specification targeted at enabling AJAX libraries and controls to be interoperable, its 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 n- squared integration complexity problem), its 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.
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-to- point fashion with a system implemented in a publish/subscribe message bus architec- ture. 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. Figure 3: Comparison of a system of separate parts, integrated point to point versus a system integrated based on publish/subscribe events and messages. 34 May 2007 aJax.SyS-con.coM