News

Server-Side AJAX for the Enterprise

• By Lee Thé
• August 10, 2007

Gertzen should know. He's the primary architect for the open source ThinWire AJAX RIA Framework, and has long focused on transaction issues endemic to enterprise applications. His talk described the evolution of an automated lending system created for a top-10 bank by his employer, Custom Credit Systems. This financial application has been in production on an enterprise scale since early 2005.

The impetus to build an alternative custom application was clear enough. Traditional Web applications didn't meet typical enterprise application needs. Web apps lacked advanced user interface (UI) controls, lacked real-time user interactions, fell short with data-centric apps and runtime network demands, and restricted client computer access.

A Bumpy Road to AJAX
The first generation of this automated lending app was deployed in 2001, utilizing AJAX-like technology. It was based on ASP/JS on the server, without HTML or cascading style sheets (CSS). Each page included a JavaScript (JS) library to support page fragment loading, validation and the like. Page-specific code was embedded through framework calls, which output it for the specific page. A 3K applet handled communication back to the server framework for database queries.

Gertzen said that the ASP/JS component model simplified development, making it more like desktop development. Likewise, it helped to use only JS rather than multiple languages. Also, he really liked being able to request information incrementally from the server to update pages -- the essence of AJAX.

On the other hand, the application had some drawbacks. Most of the users -- who were business analysts and lightweight programmers -- found it hard to follow the request/response flow. State management "was ugly compared to a desktop model," he said. The application lacked many of the UI components that desktop users had come to expect. Moreover, UI development was spread across client and server. Users could write server-side functions that validated data syntactically, giving the illusion of writing everything in one environment, but they still had to know where things were happening. Lastly, Java applets "were abysmal, even for simple communication tasks," due to virtual machine (VM) requirements and compatibility issues. For example, an applet always initialized a UI, regardless of whether you used it or not.

It's said that the pioneers get the arrows. As an early AJAX adopter, Gertzen experienced a number of pitfalls.

He found that client-side development skills were not prevalent. Writing client-side code adds risk of memory consumption, code bloat and performance problems. Sometimes he'd wind up with 200 input fields on one screen, which could bog down the system. And there were almost no testing tools at the time. Moreover, JS "must be considered a top-tier language," he said, adding that he needed excessive event handlers on the server to handle data requests. He also was forced to rethink security and debugging strategies.

Gertzen wound up with a fair amount of code on the Web browser client. Active Web pages were done in HTML/XHTML, application UI code in JS/XML, element level styling with CSS, end point calls in JS/XML, AJAX libraries and widgets in JS/DHTML/DOM, and partial application state in JS.

The application server contained Web-page generation (server language/HTML/CSS), application end-point handlers and page flow management (server language/Web 1.0 Framework), and partial application state (server language session object).

Server-Side Redesign
Gertzen needed to redo this application to improve the design and framework. For the design he wanted to simplify what it took to build a complex enterprise Web app, playing to his developers' strengths in business knowledge. He didn't want to require more programming expertise than they had.

His developers' business perspective focused on user-initiated events, rather than the page requests and form submission that usually underlay such events. So he wanted to eliminate request/response from the developer's perspective.

He also wanted to simplify development by placing all of his application logic and events on the server. Having everything in one place eases debugging, and having it on the server puts the code in the same place as all of the server resources.

His goals for the new framework included rich UIs (such as grids, trees and menus), responsive user experience (anything can change anytime), single technology development (Java), a component development model encapsulated into classes, event-driven development responsive to user actions, natural state management (object-based management), and built-in security (single communication channel, view source hides).

He wanted to build a button and have it listen for user actions. The application programming interface would be on the server, hiding from developers all that was associated with responding to the server. Likewise natural state management would hide session state as well. And doing processing and updates on the server meant not having to install an application on client PCs. Yet the browser interface combined with the server code should give end users the same experience as if they were using an application on their desktop that was accessing the data on the server. This wasn't just elegant. "In the enterprise space it's important to conceal these types of things," Gertzen said.

So the application design put all logic and events on the server. The components would be laid out in Java/Spring, adding component event listeners in Java, styling the components in Japa/Global Config File, and storing state naturally in objects using Java.

All of this was going on in late 2004. Then, early in 2005, AJAX exploded on the scene. Gertzen quoted Gartner's classification of adoption levels. Level 1 comprised enhancing existing Web apps with snippets. Level 2 involved adding widgets in the form of UI components such as Grid and Tree. Level 3 required a specialized, single-purpose framework comprising mostly client-side logic. Finally, Level 4 meant a general purpose rich Internet application (RIA) framework with a tightly coupled client/server architecture.

AJAX Meets RIA
Gartner predicted that 60 percent of new apps would be based on an RIA framework by 2010, reasoning that enterprise development favors more structure and a majority of apps are enterprise apps. These need well-defined layers to manage complexity, not to mention the levels of approval required. Also, RIAs do well at integrating advanced widgets.

In Gertzen's book, RIA plus AJAX made zero-footprint enterprise apps practical. This gave him a simplified Web development platform. It could sport a highly interactive, responsive UI. And it would be tightly coupled with the server for ease of development, capable of providing desktop application richness in the browser without plug-ins.

Gertzen named his new framework ThinWire in mid-2005. He released it as open source code in June of 2006 and then relicensed it under the GNU Lesser General Public License (LGPL) in late 2006. ThinWire has had more than 25,000 downloads so far at SourceForge. The solution is free for use in commercial apps, although Gertzen did tout the benefits of annual support subscriptions. By subscribing, users can vote on feature requests and bug fix priorities. They can get answers from Gertzen's team in a timely fashion, and enjoy incident reporting for issue resolution needs.

At this point, Gertzen demonstrated the banking app he built on top of ThinWire. He showed how ThinWire provides a different approach to AJAX development, with everything executing in Java on the server.

ThinWire is an evolving framework. Accordingly, Gertzen showed something his team is working on: a form-building tool that's somewhat like the one in Visual Basic (VB).

"You can use the XML definition to reinstantiate the UI; then use it in the app," he said.

One audience member asked Gertzen about security. He replied that there's only one comm channel used during the entire execution of the app, so you don't have to secure endpoints. The only request a server will listen to during a session is "stuff a user can do on the current screen at the current moment. And it's impossible to reverse-engineer the compiled content because there's none on the client."

Lastly, one audience member wanted to know when a visual development environment was coming. Gertzen said they're working on it. Stay tuned.