Agile Ajax

Cognitive Load, Portability and the Superiority of Client-Side Frameworks

The recent introduction of TrimPath Junction got me to thinking about Dietrich's widely read post on Cognitive Load and the Superiority of Server-Side Ajax GUI Frameworks. GWT's big advantage is that it mobilizes armies of Java programmers to write browser-based applications without having to learn JavaScript. This is clearly of enormous benefit to organizations with lots of Java programmers, few client-side resources, and a burning desire to build powerful webapps. Yet for the similarly huge army of client-side programmers out there, GWT is pretty useless. Why learn a foreign language just to have it translated back into your native tongue?

I haven't yet had a chance to play with TrimPath Junction, but it sounds pretty cool. Using the open-source Helma framework, it offers Rails-style MVC scaffolding in a JavaScript syntax that executes the same code on the client and server. Basically, it's RoR meets Adobe AIR for JavaScript programmers. I hope to give it a test drive soon.

Server-side JavaScript has been around for ages, but it's never really become a common development model. I remember writing ASP Classic apps in server-side JScript back at the turn of the millennium and having people wig out on me. "Why not write in VBScript like everyone else," they'd ask. My answer: "Because I can save time by running the same validation libraries on the client and the server ... and because I can write the entire app in one language." I obviously have no argument with Dietrich's thesis on cognitive load. It's just that my brain features a JavaScript compiler, not a Java one.

GWT is a great piece of engineering that keeps getting better; just check out the new non-beta 1.4 release. But I think there are a lot of advantages to frameworks that mobilize the JavaScript masses to write front-to-back webapps. The same cognitive efficiencies can be achieved, plus client-side programmers already know all the pieces of the UI puzzle. Ask a room of Java developers how to build accessibility and usability into standards-compliant XHTML and CSS. Nine out of 10 wouldn't have a clue.

The other big advantage to developing UI code in its native language is that you can port it to any server platform. With GWT and similar frameworks, you've got to rebuild much of your UI from scratch if you want to change course in mid-stream. With purely client-side frameworks such as Prototype, jQuery, YUI or MooTools, switching libraries may entail rewiring some of your code to a new API. But switching server platforms, from J2EE to .Net to PHP to RoR, can be done without much work at the UI layer. "The right tool for the right job" is a truism for a reason. Pure client-side development of UI code allows for the development of reusable components whose only dependency is on the standards bodies and browser vendors who control JS, CSS and HTML. GWT and its peers are useful for some teams and some projects, but they're not the only answer to webapp development.

Intellectual Frameworks for Classifying Ajax Frameworks

Who knew that a simple architectural principle like AJAX (Asynchronous Javascript and XML) would cause so much trouble? The trouble I'm having at the moment is classifying different Ajax frameworks in ways that make sense to developers, designers and business people all at once.

There are a number of people who have pondered the Ajax framework classification question and are very much worth reading:

• Dion Hinchcliffe has wrestled some with building an intellectual framework for classifying Ajax frameworks and approaches. He divides them roughly into the full lifecycle Atlas, the declarative Laszlo and Backbase, and the client-side Dojo.
• Michael Mahemoff on his excellent Ajax Patterns Wiki, has taken it upon himself to produce a good collection of Ajax frameworks, somewhat categorized, and the beginnings of a framework comparison martix. His take seems to be client, server and hybrid frameworks.
• Daniel Zeiss has a comparison matrix just for .NET Ajax frameworks. One way he classifies the frameworks is by those that have a multi-page versus a single-page interface.
• The Midnight Coders have a feature matrix comparing their product WebORB with DWR, Ajax.NET and Sajax. It's the usual feature matrix with check boxes in all of WebORB's rows.
• I, myself, have emphasized the benefits of abstraction provided by the server-side frameworks like Echo2, versus the frameworks that expose too much of the browser details.

All of these different takes on comparing Ajax frameworks reminds me of a professor I had at the University of Chicago, McKim Marriot. He was a Social Anthropologist and taught us about South Asian culture. He emphasized to us that the answer to any question about ancient India depended on your viewpoint or context. My memory is failing me a little bit, but as I recall, there were three basic principles -- Dharma, Karma and Artha -- through which everything was filtered. He had a grad student make him a big plexiglass box with each of the three pairs of facing sides tinted a different primary color -- red, green and blue, as I recall. Depending on which way you looked through the box, you got different color combinations. By the time I took his class, the colors had faded and the box was scuffed and suffering from some sort of inner condensation problem.

Still, he would twirl it around in class, mumbling about perspective, context and viewpoint. His way of thinking is very similar to the ideas in UML and the various OOAD approaches, where each diagram or artifact gives a different view or perspective into a system -- domain, design, behavioral, deployment, physical, etc.

Looking at the above different comparisons, we can extract a few perspectives and add our own.

• Architectural - n-Tier webapp, desktop GUI-style abstraction on the server, SOA-style client orchestrator of services, browser extension cross-site apps, etc.
• UI Style - enhanced page based versus single page.
• Language - Java, C#, Javascript, PHP, Ruby, etc., both on the server side and for generating Javascript.
• Component - Client engines, Server engines, Client Plugin, Widgets, Transport Protocols, etc.
• Feature - is it themeable, does it integrate with db, does it degrade gracefully, what kind of effects does it have, etc.
• SDLC - do we develop webapps the same way as before, or do we change?
• Tools & Methods - IDE support, debugging support, etc.
• Platform - pure browser, hybrid Flash/Javascript, etc.
• Application Framework - does it provide all of the things, in an Ajax way, that we've come to expect from other web frameworks: authentication, database persistence, workflow, etc.?

Seen through this prism, some packages we've previously thought of as frameworks are not really frameworks at all. For example, seen through the SOA (service oriented architecture) perspective of Javascript apps running in the browser as orchestrators of web services, Tibco GI is a framework. Seen through a client/server or n-tier webapp architecture perspective, Tibco GI isn't a framework but only a part of a larger solution.

What I've realized over the last few months is that this simple architectural idea of Ajax has opened up a whole new world of possibilities when it comes to writing web applications, with the simple n-tier app giving way to a number of new approaches. Anyhow, this is all still percolating in my brain and is not in a ready state by any means.

Technorati : ajax, architecture, classification, frameworks

Echo2 vs GWT

Back on June 6th I made a note of this post by Echo2 creator Tod Liebeck at The Server Side, entitled Comparing the Google Web Toolkit to Echo2, but never got around to blogging about it. Tod gives a fairly succinct description of both GWT and Echo2:

GWT's defining attribute is the Java-to-JavaScript compiler. This compiler allows you to develop the web interface to your application in Java, then compile it to JavaScript. GWT limits the developer to a subset of the Java 1.4 libraries. GWT applications can be served by any web server, such as Apache, without the need for server-side processing.

Echo2 applications are compiled to Java byte code and run on a Java server. Their Java code is executed by Echo2's "Web Application Container" layer, which sits atop a Java Servlet. On the web browser, the Echo2 "Client Engine" communicates user input to the Web Application Container via AJAX requests, with the server responding with directives to perform incremental updates to the state of the client web browser.

He goes on to analyze other points of comparison, including architectural, performance and legal issues. A good comparison by one of the AJAX worlds leading developers.

One thought here is that many folks have held out a GWT as a tool for writing widgets for other frameworks such as ZK and Echo2. I've been going through the Javascript infrastructure of GWT and it seems there's a whole lot of plumbing that stands in the way of making this a reality. More on this later.

CMS and AJAX

Back in April, CMS Watch published an article entitled Ajax and Your CMS. The article looks at the impact of AJAX on CMS systems from both the content author's and the site visitors perspective. From the author's perspective, the news is all good and pretty conventional as far as AJAX articles go: fewer click, drag-and-drop, faster, more powerful UI. There are a few noteworthy points to the article, however. For one, content management with AJAX enabled, single-page sites puts a premium on managing assets:

If you are going to use a heavily-Ajax-driven interface on your websites, then it is worth considering a CMS to manage intra-page snippets and interaction as discrete elements. In practice it could be difficult to manage a rich, interactive site that uses single page interfaces without a CMS, since at this point you are managing content components rather than entire "pages." The whole notion of "pages" tends to dissipate, which would call for a more component-oriented -- rather than page-oriented -- CMS for those looking to manage Ajax-driven websites.

So, if you're publishing content rather than constructing an application, then composing a bunch of widgets together using a CMS sounds plausible. However,

Web CMS tools are notoriously poor at managing stylesheet elements and client-side scripting in particular. The rise of Ajax should prompt some improvements here.

Improve or die, I guess.

The few bad patches for the content author are things that people are already working on: back button, refresh/reload an state, etc. Previewing content from a single page interface is a problem not just restricted to CMS's. You can identify the "states" within the single page interface and preview those, i.e. "show me the state after a restaurant has been picked."

That's It?

The fact that CMS Watch really struggled to find much more to say about AJAX than "will make it easier to use, may make content harder to manage," I think points out that nobody really has a clue about how to effectively use AJAX for content sites. All of the major AJAX enabled sites these days seem to be collaborative filtering excercises like digg and dzone. There must be better ways than this to apply this nifty technology.

I think we can come up with a few ideas. What are some of the content display issues we can tackle with AJAX? Let me give three off the top of my head:

• Screen real estate - we can summarize an article and expand the full test into a new reading context when the user navigates to it. I have a primitive little example here. Just click on one of the text boxes to read the full article in place.
• Breadcrumbs on steroids - this is more about providing a better reading metaphor. We can make the sections of the paper fold and unfold, allow the reader to rapidly navigate through tabs or trees. No more slow postback means we can try more stuff.
• Contextual control - the WSJ already has the capability to right click on a selected word and perform a search. But contextual search, navigation, and other operations are the next step. Imagine an online newspaper where a reader can right click in an article about their neighborhood and get restaurant review listings for nearby establishments. You no longer have to cram every single relevant thing into the sidebars!

The day is still young on CMS and AJAX. Think outside the box and share your own thoughts on what AJAX can do for CMS.

 

Grizzly - Infrastructure for COMET and AJAX

Other than being the black hole into which the JavaMail API has disappeared, the Open Source Glassfish project -- a J2EE app server building on the Toplink and J2EE code donated by Oracle and Sun respectively -- has some interesting stuff under the hood. They have a new NIO-based HTTP Connector named Grizzly. See their Webtier page; down a little on the page, you'll see a heading entitled "HTTP Connector." Along with a nice high level diagram, the section describes Grizzly as

Grizzly is an HTTP Listener using Java's NIO technology and implemented entirely in Java. A re-usable NIO based framework that can be used for any HTTP related operations (HTTP Listener/Connector) as well as non-HTTP operations, thus allowing the creation of any type of scalable multi-threaded server.

With NIO, as anyone who has ever used the Unix select system call, you can have a single thread operating on a bunch of connections instead of one thread per connection. This can save tremendous overhead and can achieve a surprisingly high degree of performance. See the old single-threaded HTTP servers Boa and Tiny httpd for evidence that this is not a new concept.

To understand why Grizzly helps in one piece of the COMET puzzle, we look at Jean-Francois Arcand's blog entry, Can a Grizzly run faster than a Coyote. He ran ApacheBench against Tomcat and Glassfish and came up with the following result: Tomcat needs 500 threads where Grizzly needs only 10 to handle a large benchmark test.

The results are a little controversial -- nobody likes their app server trashed -- and I don't want to get into a discussion about the relative performance of Tomcat vs Glassfish, but the ability to handle the IO of an application server with a small number of threads bodes well for COMET. COMET, remember, keeps a connection open to the browser while the Servlet is performing some long running calculation or waiting on a message, and that means we'll have more connections open at one time. If we needed one thread per connections, we'd be hosed.

What NIO doesn't solve, however, is the that the waiting Servlet still chews up a thread. As we've mentioned previously, Jetty 6 has a continuation mechanism for Servlets that allows waiting Servlets to give up their threads. That's the other part of the puzzle for COMET. Jetty 6, BTW, also has an NIO HTTP Connector to go with its Servlet Continuations, so this may be the way to go for COMET early adopters.

 

AJAX and Security

Lots of articles like this one from eWeek broach the subject of AJAX and security but give few answers. The most insightful quote from the article is from the Dojo man:

Panelist Alex Russell, co-founder and project lead for The Dojo Toolkit, a popular AJAX framework, said, "It's worth noting that the fundamental problems with browser security and Web application security haven't changed in five years—most rely on a single root of trust, and AJAX doesn't change that. Wider spread use of cross-domain content distribution," which is not new with AJAX, is part of the issue. "The short version is still, Don't trust the client."

Right on. But beyond "nothing to see here...move along, move along," can we at least categorize security concerns and explain how they might apply to AJAX?

The security issues, as I see them, fall into two distinct categories: end-user and server. End-user issues revolve mostly around privacy. A user wants control over what information is revealed to third parties. The server issues, on the other hand, revolve around exposing services that a malicious user can exploit by subverting the client. (There are hybrid versions of these, such as third parties launching attacks on sites using cross domain content, etc.) AJAX has added a wrinkle to both of these issues.

On the client side:

• XHR has made it difficult for the user to know whether information about their behavior is being transmitted back to the server. Solution: give users a way of seeing what is happening with XHR and other "invisible" communications.
• It is easy for developers to overlook the need for SSL or some sort of encryption when confidential information is sent back to the server. Solution: Give the use better insight into how information is about to be transferred.
• Larding in new functionality into the browser raises the chance that security holes might be opened up. Solution: decouple the browser from the OS (IE) and institute a sandbox approach. Don't hold your breath for this one.

Should we give the user more control over XHR, i.e. give them an option to disable certain features of the browser? With the increased complexity of these apps, even tech-savvy users might find it difficult to evaluate the security of the application.

On the server side:

• Ad-hoc code - We've learned to protect ourselves from things like injection attacks and the like on the server side through the use of webapp frameworks. Opening up lots of little services using ad-hoc AJAX tools can lead to repeating these mistakes. Solution: consider using a server-side component GUI framework like Echo2 or ZK to avoid this issue.
• Reliance on too much business logic in the client. No matter how much you obfuscate your code, it is still accessible to the client. This is the pitfall with client-side component GUI frameworks like Tibco GI and OpenLaszlo. Solution: you can try and fight against this by making the services they access as simple as possible and dependent on cryptographically secure session information. I just wouldn't do anything mission critical with this.
• Application complexity - It used to be that if someone compromised your site, they would deface it, install a rootkit or grab some credit card numbers. Now, a cracker might instead modify your AJAX application to send malicious Javascript to the client. Since "view source" ain't what it used to be with DHTML and eval'd Javascript, this sort of compromise might be hard to detect. Solution: regular regression testing against the app is probably the best you can do.

The Open Web Application Security Project has some good resources on webapp security, but they're a little bit behind on AJAX. One of their suggested approaches that I can heartily recommed is using mod_security, sort of a stateful firewall for webapps.

MVC and RIA - Learning From Desktop Apps

Whether you're writing AJAX applications using enhancements to existing webapplication frameworks or adopting the new component GUI approach, you as a developer are faced with a new granularity of events. Where before you had the monster postback, now you must respond to mouse clicks, key presses, menu selections, etc.

On top of this, with a single page interface, you may have many more controls on the page. This brings on the problem of context, i.e. that not all of these controls are appropriate for a particular context such as when a particular part of a table or list box is selected or when the focus is on a particular window.

The above just scratches the surface of the sorts of challenges that you'll discover writing RIA's with AJAX technologies. The good news is that there are already solutions in place since these are the sorts of problems that desktop GUI developers face all of the time. For example:

• Enabling and disabling menus and other controls can be done using the State pattern. A collection of state objects would be used to enable and disable the controls as appropriate.
• Many of the component GUI frameworks implement an Observer pattern for event management. UI events come in now in little bites instead of one huge request and can be consumed by listeners that wait on a specific component.
• MVC needs an upgrade when you're dealing with big heirarchies of components. Combining the Composite and Chain of Responsibility design patterns, you get the Heirarchical MVC (HMVC) pattern. (If you've worked with WebWork you may have run across the "Pull HMVC" pattern. That heirarchy refers to the model, not the whole MVC.)
• The Command pattern is often used to implement undo.

That's just a sampling of desktop GUI solutions you can make use of. What can you do to expand your solution space for RIA's? Read lots of code. Find as many good open-source desktop GUI's as you can and read their code. You'll find ways of doing things that don't resemble the typical webapp approach. Here are a few to get you started.

Resources:

• The Spring Rich-Client Project. Based on the Spring Framework. Used for buidling desktop GUI's. Read the code and get a sense for how to build your RIA framework. Good source for ideas

• HMVC framework and tutorial. View/Implementation independent. You can plug this into your own apps or just learn from it.

• The Scope Framework. The bad new is that this is a desktop GUI framework based on Swing that hasn't been updated since 2002. The good news is that this is a great place to read some code and learn how to develop component GUI applications.
• The HMVC Framework from Crionics. Again, no longer maintained, but a great place to read some code.
• Tutorial (in C#) on implementing undo with the Command pattern.
• A discussion of the Presentation-Abstraction-Control (PAC) architectural pattern. This one is just as old as the MVC pattern, but since the MVC pattern was intended for simple interfaces it was also simpler to implement. Thus MVC won out even in cases where PAC is more appropriate, such as with more complicated UI's.

Update 1: Oliver Steele has an excellent overview of MVC as it exists in the desktop, webapp and RIA worlds. He points out why non-RIA, i.e. traditional webapp programming is so tough:

That complexity includes the real world application of what are still research topics in academia: staged programming for multiple-target code generation (Mac IE, Windows IE, Netscape, Mozilla, Safari, Opera), process migration, and (usually manual) CPS conversion to maintain program state across pages.  No wonder web programming is hard!

Well worth a look.

Struts and the Tension Headache

I'm spoiled. This past week I had to go back and revisit a Struts application I developed back in the early days, before Hibernate, before EJB's. I found myself developing an anger headache as I bounced between the struts-config.xml, the web.xml, the jsp's, the home-brew ORM layer, and the various validators, actions and pieces of business logic. Even using an IDE and with well documented code, it was a real pain to make just a handful of modifications. Each time I made a change, it seemed that I had to modify three or four files to make it work. A little XML, a little JSP, a little Java, a little SQL. Oiy!

Why did this stuff make me so angry? Hadn't I designed my code in layers to avoid all this mess? Well, it was actually pretty painless for a struts application. The problem is that struts, and most frameworks, expose too much of the plumbing and force developers to repeat themselves in several places and in different languages and formats.

Why didn't I just accept that this was the way things were? Because I'd spent the last 7 days working on an AJAX newspaper interface using Echo2, and I hadn't spent one second writing HTML, Javascript, XML plumbing or SQL. Just Java. And now here I was back in the bad old world of the web worrying about sessions and postbacks, repeating myself over and over again in different languages.

Yes, things today aren't as bad as in the early days of struts. Hibernate and Spring have made things easy on the ORM front, so I write little or no SQL. Web application frameworks like Webwork and JSF are moving toward components and a higher level of abstraction. But the problem I have with their MVC is that all three really should be realized in Java, not a mix of different languages. That's the only way to stay DRY (Don't Repeat Yourself).

So, why isn't everyone embracing this new, pure Java (or C#, or Ruby, pick your poison) way of writing apps?

Paradigm Shift
People tend to overuse the term "Paradigm Shift", which was coined by Thomas Kuhn back in 1962 in his book The Structure of Scientific Revolutions. What does it mean, Paradigm Shift? It happens when a scientific theory can no longer explain the facts, i.e. when enough anomalies have cropped up to invalidate it. When this occurs, it isn't just the theory that is discarded but the whole worldview from which is comes. From the Wikipedia:

When enough significant anomalies have accrued against a current paradigm, the scientific discipline is thrown into a state of crisis, according to Kuhn. During this crisis, new ideas, perhaps ones previously discarded, are tried. Eventually a new paradigm is formed, which gains its own new followers, and an intellectual "battle" takes place between the followers of the new paradigm and the hold-outs of the old paradigm.

Yes, we're not fighting about Ptolemaic versus Copernican cosmology and if the latter meant that man was no longer the center of all creation. In our case the paradigm is not how which questions we ask and what experiments we do, but rather how we build web applications now that AJAX has come along. The worldview is not whether the planets revolve around the Earth or the Sun, but what exactly web applications can do. The battle is between those who want to build web applications with the old methods -- sort of a souped-up struts with AJAX -- or with the component GUI approach.

I for one am on the side of the component GUI's. I can't stand the tension headaches.

Not There Yet: COMET with Apache and Jetty

I had intended to marry the nice Apache2 event MPM and Jetty 6 with Continuations in order to achieve a thrifty, thread-sparing COMET capable Java app. The idea is that the Event MPM module in apache frees up a thread when an open connection to the browser is snoozing and Jetty frees up a thread when the backend servlet is snoozing. There are two problems, however.

1. The Event MPM module seems to only snooze between requests. With COMET the need to snooze happens during a requests, i.e. we are expecting something to come back from the server.
2. The request handler module -- in this case mod_jk or mod_proxy_ajp -- and not the Event MPM module handles the socket connections to the servlet container. From my reading of the most recent SVN branch, the modules are using blocking I/O and not polling.

It seems there's still a bit of work to be done to make Apache and Jetty do the COMET dance.

RIA and AJAX: Another Perspective

        Marc Domenig over at javalobby.org has some thoughts on selecting the best product for RIA using AJAX. He gives a decision tree approach to deciding which technology solution to settle on. Given the headlong rush to embrace AJAX for everything from stock tickers to CMS systems, I think it's wise for product managers to carefully consider A) why moving to an RIA model is good for them and B) if AJAX is in fact the best solution.

His view on AJAX is a bit outmoded, however:

JavaScript was designed for scripting rather than full-fledged rich client development. For this reason, a JavaScript/AJAX product may not necessarily support all RIA functions mentioned. Partial screen updates, asynchronous communication, modal dialogs and menus will probably be available. But other RIA goodies may be severely limited in functionality or missing altogether. Typically, the set of rich UI widgets that supports direct manipulation will be poor compared to those we find in toolkits for desktop applications.

Yes to everything except the idea that AJAX means Javascript apps. While frameworks like ZK and Echo2 certainly make use of Javascript for their display manipulation, it is at such a low level that the development of new component widgets and the porting of widgets from existing desktop GUI frameworks is simplified.

He's preaching to the choir when he points out the benefits of a thin, Javascript rendering engine:

JavaScript code can be limited to an application-independent presentation engine that comes with the product, as illustrated by the rightmost option in Figure 4. This pure thin-client approach has several advantages: applications can be written entirely in Java, with a single programming environment. Moreover, there is a homogeneous server-side programming model, and no need to distribute the application code between client and server, nor between different programming languages. This simplifies both development and testing substantially. Finally, the application code will execute primarily in the robust server-side environment.

He goes on to evaluate the Java and Flash alternatives to AJAX. Overall a well thought out and informative article. Well worth the read.

AJAX Component GUI Frameworks: The Reviews

Over the next week or two, I'm going to begin reviewing several AJAX frameworks, specifically those of the Component GUI variety. The basic idea is that these frameworks allow you to develop AJAX application much like a desktop GUI, by composing reusable widgets and attaching behavior and data to them. The development techniques are well understood and mature. Also, the component GUI is a much better design model than the form-and-reports multi-page awkwardness of traditional webapp development techniques and frameworks for developing RIA's. Picking the right approach now will save you time and heartache. To quote Jesse J. Garrett:

Web sites are technologically complex, and getting more intricate all the time. Identifying the technology strategy for the site - platforms, standards, technologies, and how they can all interoperate - is essential to avoiding costly mistakes.

Two Kinds
There are two kinds of Component GUI's we'll be looking at -- servers-side and client-side. Client-side frameworks essentially build an application in Javascript on the browser and communicate with a backend via web services calls. That's a bit of a generalization, but the idea is that much of the logic is in the browser and the server side takes care of the data and some select operations.

Server-side frameworks use the browser mostly as a display servers, i.e. there is a model of the UI on the servers-side that pushes updates to the client and which is periodically updated due to events on the client-side. All of the business logic sits on the server.

Each type has it's advantages -- client-side frameworks can be more responsive and function in the absence of connectivity, server-side frameworks don't leak business logic out to the client tier and can be made less susceptible to browser variations -- but they share a common advantage over their non-component GUI competitors: they reduce development time because the developer is working at a higher level of UI abstraction and is not concerned with low-level UI tasks such as drag-and-drop, asynchronous updates, etc., and the developer can work largely in one layer without having to repeat himself (DRY).

Client-Side Frameworks
The client-side frameworks we will look at are:

• Tibco GI
• OpenLaszlo -DHTML
• Backbase
• Bindows
• Plex

Server-Side Frameworks
The server-side frameworks we will look at are:

• Echo2
• ZK

Why not X?
Why not Tapestry? Why not ICEFaces? Why not Atlas? There are a number of frameworks that one could argue belong in the above two lists. It's my list, so that means I get to decide what goes on it. I'm looking at Java or Javascript solutions that don't involve mucking about in multiple layers with HTML, CSS or whatnot, and provide a full application framework, not just a library.

First on tap is ZK, the spiffy server-side framework with XUL. Stay tuned.

COMET: Socket Hungry AJAX

From back in late March, Alex Russel over at IrishDev writes about a new AJAX technique, calling it COMET. What is COMET? Basically the browser makes a request of the servers, but the server keeps the socket open over a long period of time.

[COMET applications] all use long-lived HTTP connections to reduce the latency with which messages are passed to the server. In essence, they do not poll the server occasionally. Instead the server has an open line of communication with which it can push data to the client.

Does it scale? We've talked about this stuff before when we spoke about Jetty Continuations. I wrote then that

I don't like this method because it is wasteful in terms of sockets and threads; also, it is likely to stress stateful firewalls, load balancers, etc., and may break in lots of client environments.

I stand by that statement. Beyond the issue of migrating these connections between nodes in a load-balanced cluster (yes, you could close the connection and have the client automatically reopen the connection), there are serious scaling issues.

One of the things that made HTTP based applications scalable was that they made use of small, stateless requests. This meant you could handle requests from an order of magnitude or more users than a comparable stateful application.

It's true that the typical AJAX polling for async updates also puts a burden on the server, firewall, load balancers, etc., but that depends partly on the frequency of the polling and the number of clients doing the polling. Even if I have 10,000 users polling the server every half second, I may still only have a few hundred sockets open at any one time if the request/response size is small and the user's network latency is low.

Modifications to server software like Apache and Jetty to conserve resources like threads and make use of IO multiplexing is a first and probably necessary step. Maybe I'm making too much of this stateful thing. We may have so much application state information floating around on the server side anyway that is will dwarf any OS and network resources that COMET and related technologies seek to spend.

Update 1: DWR's next release should have an implementation of COMET that they are calling "Reverse AJAX." More interesting, however, is the fact that they are releasing an API that allows one to write Javascript by writing Java.

How Cool an App in 300 Lines or Less?

I've always thought that one of the big advantages of a component GUI framework was that you are able to leverage all of those prewritten components to produce something rather spiffy with very little original code.

I gave a presentation on AJAX and Component GUI's this past Wednesday in Chicago and highlighted Echo2 as a framework worth investigating. To demonstrate it's power, I showed off an application that clocked in at 298 lines of code. That's including the code to pull the stock quotes from a web service via the Mule ESB (a very nice choice, IMHO if you need to do async background processing).

The app can be found here. It's on a somewhat underpowered server, so don't mention it on slashdot. :-)

The app allows you to drag stock symbols from a left column into a right, where they turn into market data grids. You can drag these grids back again. The quotes are updated every 15 seconds or so. It's of course much more interesting when the markets are open.

I've intentionally left it a limited demo, i.e. you can't add in other stock symbols, since I don't want people to be tempted to use this as a real stock ticker and burry me with traffic. I do plan to include this app as an example in my tutorial series.

I made use of Echo2, Echo2_Contrib and EPNG for the app. It caused quite a stir, since folks in the audience (designers and developers for the most part) had a good sense of what it might take to bang something like it out in DWR or some other framework.

So, the challenge: what can you do in 300 lines of code? Be honest, count Javascript, XHTML, Java, etc. Then let the best demo win.

Update 1: To determine "lines of code," I'm counting semicolons in Java and Javascript, CSS entries, and XHTML entities. Since I'm only writing Java, all the others sum to 0.

Ajax: The "Husky" Client

Scott Dietzen over at Zimbra has a post in a continuing series on AJAX scalability. Besides coining the humorous term "Husky" Client to describe AJAX -- not quite thin, but not quite fat -- he makes some excellent points about the importance of design and choosing the appropriate browser/server boundary for an application in order to minimize the impact on the server.

I thought the following early paragraph was a nice observation by someone who clearly has a bit of experience developing applications:

Traditional fat client applications, on the other hand, off-load all of the UI and most of the business logic (modulo stored procedures and triggers) from the server to the client. Fat client app's could nevertheless hammer their servers simply by not being sophisticated about how much and how often data was being requested---that is, data shipping to the client can be more expensive than function shipping to the server (with stored procedures, triggers, et al). With a reasonably smart design, however, fat client applications typically use more client and less server CPU per operation than a corresponding server-centric application.

I think the generation of RIA's (Rich Interaction Application) that are about to sweep the web are likely going to repeat many of the mistakes of the client/server age. As Scott points out, how poorly these applications perform is going to be in part dependent on how well they are designed. As Santayana wrote, "Those who cannot remember the past are condemned to repeat it."

Ajax and Leaky Business Logic

I gave my presentation last evening to a welcoming Chi2 audience. The attendees were a good mixture of developers, designers and business folks. They sat through my rantings on why I thought Rich Interaction Applications (RIA) in AJAX should be developed with server-side component based GUI's, though, in a pinch, I could see the argument for client-side component based GUI's that use the back-end as a dumb data web service. Then I showed them what 150 lines of Java code could do in the Echo2 framework with my special "why would you do things this way" stock quote app. Lot's of dragging and dropping ensued.

I'll put the presentation and the demo up when I get a chance.

One of the more interesting and probing questions after the talk was about business logic leakage, i.e. how does a server-side component GUI (SGUI) keep you from leaking business logic? The answer is simple: with the SGUI, the only "logic" that makes it to the browser is "turn this area blue," "move this button over here," and "make this element draggable." While I suppose it is possible to leak business logic in this way, I'd have to say that the possibility is pretty remote and esoteric, akin to sending smoke signals.

In the pseudo hand-coded world of traditional webapp development, you are dependent on developers following good practices and not making mistakes, such as leaking the secret sauce in their Javascript validation logic. At least you hope they do. If the last 50 years of software development practice have taught us anything, it's that hope is not a plan.

There are two kinds of information leak -- what and how. "What" is your customer data, your orders, your accounts receivable, your employee database. The "how" is your secret sauce, the special way of pricing or quoting or doing that gives you a competitive advantage. Reports can leak the "what," and many businesses can survive a leak of quite a bit of "what," but leak the "how," your secret sauce that makes you money, and you're cooked. Javascript can leak the "how" if you let it.

Michael Mahemoff feels it's sometimes OK to include business logic in the Javascript:

I realise there are plenty of problems with Javascript business logic, and it’s certainly not always applicable. Those problems include:

• Security - Exposes business logic algorithms and enables them to be changed.

That first bit applies to most all valuable services that a company might provide. If all you're providing is data, then no business logic would be leaked. If you are performing some sort of business logic on the data, it would have to be something pretty trivial to still have value and not be a divulging of the crown jewels. Can a business consist of a bunch of ultra trivial, obvious logic and still be competitive? Probably not. In short, I can't imagine the circumstances where that first item wouldn't just preclude exposing most any business logic.

Again on Scalability

Since my rant started flowing, I just thought I'd pull this out of the comments section at Ajaxian.com:

Beyond becoming multi-threaded, AJAX is beginning to open up the web to new types of applications, ones that are document centric (word processors, modeling tools, etc.) rather than data and transaction centric, i.e. all those rectangular CRUD applications that make up 99.9% of webapps. It also means that the sorts and types of rich client interactions are going to dwarf the traffic that we see today.

That means 1. abandoning the forms-and-reports way of writing webapps (which will break when you try to write something like rational rose as a webapp) and moving to the component GUI model (like Swing, Winforms, etc.) and 2. being very clever about the frequency and size of your XHR conversations with the server. From my unscientific tests (Yahoo mail and Google calendar) it seems that some are winning and some are losing the battle on fat XHR. I don’t think any amount of JSON or compressed XML magic will solve the problem of poor design.

I think the right way to achieve all of this is by moving AJAX/Webapp development to component GUI application frameworks. Properly done, they have the potential to hide all of the messy bits like exposing too much of your business logic on the client side, optimizing XHR requests for components that have empty server-side event listeners, reducing the impedence mismatch between the Javascript/CSS/XHTML world and the business logic.

Those who don’t move in this direction will be stuck building and maintaining ever more complex applications because they didn’t make the shift to a new design. It’s time to think of the browser simply as a display server.

X Windows and Ajax: Two Kinds of Display Servers

X11 is a client/server display system that realizes user interfaces by sending asynchronous messages back and forth between a display server -- that manages a display, mouse and keyboard -- and clients such as xterms, Firefox, GIMP, etc. Some of the drawing, windowing, events and other operations that the X protocol supports look suspiciously like some of the things flying around in Ajax these days.

Now there are some substantial differences between X and Ajax. For one, X clients (the equivalent of the http server) open up persistent connections to the X server (the equivalent to the browser), while the 'Ajax server", aka the browser, has to poll the "Ajax clients" (the apps on the http server) for messages. X is typically used in a LAN rather than a WAN setting, for this reason. Persistent connections usually don't hold up very well in a WAN context. Also, there's no embedded scripting language like Javascript in X.

One definite similarity is that both X and Ajax don't have any widget standards. In X you've got several different widget sets -- Motif, Qt, Gtk, etc. -- while in Ajax you've got a few early frameworks with their own widgets.

So, what's to be learned from all of this? First, while user interfaces may well head in the component GUI/widget directions, we'll likely have quite a number of different widget sets in the long run. Second, there are a few design lessons to be learned from X Windows. For example, the creation of windows with a specific look and feel is controlled by a window manager abstract factory.

Some of these design solutions may not be appropriate for Ajax, but I think it's worth mining this trove of design solutions. Might we some day have an Ajax desktop that unifies multiple independent Ajax applications?

Update 1: Bill Scott makes a similar point (though much earlier -- more coffee, I'm sure).

Jetty 6's Continuation Mechanism for Ajax

I've touched on the topic of updates and asynchronous processing before. My preferred method of performing updates between the browser and server is via a polling mechanism that returns quickly. An alternative is to open up an XHR connection and keep it open to wait for a response (or a timeout). I don't like this method because it is wasteful in terms of sockets and threads; also, it is likely to stress stateful firewalls, load balancers, etc., and may break in lots of client environments.

Nevertheless, if you want to keep a connection open for notification initiated by the server, this is the way for now. And the Jetty 6 server has at least addressed the thread issue with Continuations.

Behind the scenes, Jetty has to be a bit sneaky to work around Java and the Servlet specification as there is no mechanism in Java to suspend a thread and then resume it later. The first time the request handler calls continuation.getEvent(timeoutMS) a RetryReqeuest runtime exception is thrown. This exception propogates out of all the request handling code and is caught by Jetty and handled specially. Instead of producing an error response, Jetty places the request on a timeout queue and returns the thread to the thread pool.

When the timeout expires, or if another thread calls continuation.resume(event) then the request is retried. This time, when continuation.getEvent(timeoutMS) is called, either the event is returned or null is returned to indicate a timeout. The request handler then produces a response as it normally would.

Sockets are still consumed, though. Hopefully the next servlet specification will address some of these issues. Until that time, this may be a good workaround.

Still, my preference is to keep everything except for the display logic on the server side, and that includes handling complex communication with async processing.

Update 1: ActiveMQ can make use of Jetty 6's continuation mechanism.

Update 2: Greg Wilkins has some more extensive thoughts on using Jetty 6 to scale Ajax apps.

Webtop - I Already Hate It

A reader emailed me this old article from CNN Money discussing the concept of the webtop, i.e. that

A killer app no longer requires hundreds of drones slaving away on millions of lines of code. Three or four engineers and a steady supply of Red Bull is all it takes to rapidly turn a midnight brainstorm into a website so hot it melts the servers.

What has changed is the way today's Web-based apps can run almost as seamlessly as programs used on the desktop, with embedded audio, video, and drag-and-drop ease of use. Behind this Web-desktop fusion are technologies like Ajax (asynchronous JavaScript and XML), Macromedia's Flash, and Ruby on Rails. We'll spare you the technical details; suffice it to say that these technologies are giving rise to a new webtop that may one day replace your suite of desktop applications.

I already hate the term "webtop," though I've used it myself in the past. The article goes on to discuss the various webapps that are starting to move into areas once reserved for desktop applications, then lists of a few noteworthy apps, such as 37signals campfire chat client.

The conclusion? We'll all be doing our word processing over the web from now on.

Now I like a little bit of breathless hype as much as the next guy, but this is over the top. Yes, webapps are going to change, but there are certain limitations to the medium that will make the webtop a much tamer place:

• Reliability and performance - why aren't most desktop apps in corporate environments served up as client/server apps? The technology is there; the kinks of client/server have mostly been worked out. License sharing could save tons of money. The benefits of reliable, centralized storage and ease of collaboration seem pretty obvious. Yet the most we see is networked storage of documents. The reason? Even on a corporate network, performance and reliability are not high enough to make client/server computing for desktop apps attractive.
• It's more than just CRUD on speed - even after the widespread introduction of the WIMP (Windows, Icons, Menus, Pointing device) environments in the 80's, it took a while for programs to mature beyond GUI versions of Lotus 1-2-3. We didn't see precursors to Photoshop until a few years after the introduction of the Mac. Most webapps today are still glorified CRUD (Create, Read, Update, Delete) engines. Writing the more substantial applications will take a good bit of work, not just a few cans of Red Bull (or Jolt!, sniff).
• Writely ain't Word - more like Wordpad. If Writely was out as a desktop app, it wouldn't get a second look. Yes, there is a need for a Word-compatible, easier, less bloated, free word processor, but they never seem to make it. Yes, a web based word processor that saves your work more frequently than an occasional submit is kinda cool. But the truly cool part is the collaboration feature of Writely, and honestly, there are other, better solutions for that.
• Can I Use it Offline? - You're not going to be online all the time. The moment you have desktop versions that can function independent of the server, is it still Ajax or a Javascript/Browser app with save capability?

This hype around Ajax is really starting to remind me of the first dotcom boom (See FauxJAX for a good sendup of this). I had a few venture capitalists back then asking me to look at business plans that added "the web" to their business models. My rule for evaluating these was always the same: what does the web add? Most times it didn't change anything; it was just another marketing channel. For others, like online classifieds, it removed distribution costs. For the social networking type businesses, it made it easier and less costly to jumpstart the network effect.

So, for those going gaga over Ajax, ask yourself, what does Ajax add? If you can't come up with a good answer, odds are it doesn't add a thing.

Upcoming Talk - Back to the Future: Component GUI's and Ajax

I'll be giving a talk at the Chi2 monthly meeting on Wednesday, April 26, 2006. The highlights are:

• Why web applications are they way they are and how things are changing
• First attempts: frameworks and toolkits that extend current practice
• How Ajax has turned the browser into a desktop
• Component-based GUI's and how they cut down on Ajax Development time
• Which frameworks get it right

For more information see here. If there is a podcast, we'll try to make that available along with the presentation.

Asynchronous Processing in Ajax Apps

Most web applications are still request driven, i.e. the browser makes a request and backend state is updated as a response to that request. There is some backend processing, but usually that processing is very losely coupled with the webapp, updating a backend data store.

Many more advanced apps make use of web services, MDB's, JMS, and other approaches to perform asynchronous processing. The need for asynchronous processing in webapps has been mostly confined to some special cases, requiring extreme scalability or performance. But now with the advent of Ajax, many new webapps are going to have to perform ongoing background processing in order to update front end displays. Some of these processes are going to exceed the time you want an XHR to be open. Or maybe you want to perform some backend processing tightly coupled to the session and UI, rather than loosely tied to the persistent store.

I've used open source tools like Mule, ActiveMQ and the like for some of these things. It does make life a bit easier when doing async processing, but moving to these new technologies will involve a bit of a learning curve for most webapp developers. Sorry, guys, the pain isn't over.

DO NOT PRINT THIS FORM

A number of years ago I was part of a team that developed a workflow application for a company to replace a paper based process. The new workflow app was quite a success in testing and training, so we felt fairly optimistic about the rollout. On a Monday we stood in a bullpen area in the company's Manhattan headquarters and watched the application go live. One woman used the application to fill out a form and then, rather than hitting submit and sending it on its merry workflow way, printed it out and put it in her outbox.

I'm sure most people involved in systems development have experienced this sort of infuriating situation -- I've seen enough "DO NOT PRINT THIS FORM!!!" messages on the bottoms of pages to know I'm not alone. No matter how much testing and training is done, some people can't get their heads around a new way of doing things. They remind me of those stories of the industrial age, when new machines were introduced into traditional ways of doing things, often to comical results.

In order to avoid being stuck in the past like this, you have to remember why you do things in the first place and continually question if they are sensible or necessary. I remember when I started designing what now would be called web applications back in 1994 or so. Stateless searching and reporting was easy to do, but the major challenge came in chopping up your application into different "pages", retaining state across several page loads and dealing with the "Back" button, a sort of rogue "Undo" function that didn't play nice with the application design. You ended up doing lots of kludgy things that you wouldn't do in a GUI or command line application. You had to think differently in order to build successful web apps.

As I review the various web application frameworks, most of which have the page based concept at their core, I have an uneasy feeling that we're missing an opportunity to rethink how we build webapps. Isn't it time to discard the page model and go back to a component model that has been so successful and productive on the desktop? Imagine undo functions that don't depend on the "Back" button, Browser specific code that is concentrated in a few classes, powerful, rich client applications in a fraction of the code. Let's rethink and DO NOT PRINT THIS FORM.

Why Frameworks are Important

I've been beating the drum of component based GUI frameworks for Ajax for a while now. To understand why, I think it's useful to look at the evolution of the desktop GUI framework and understand what makes them so successful. Over at ACM's Queue publication, I came across an article that gives a nice overview of what an application framework does and the characteristics that make it successful. This following struck me as especially apropos with regard to most of the current Ajax frameworks.

A framework exhibits "inversion of control" at runtime via callbacks. These callbacks invoke the hook methods of application-defined components after the occurrence of an event, such as a mouse click or data arriving on a network connection. When an event occurs, the framework calls back to a virtual hook method in a preregistered application component, which then performs application-defined processing in response to the event. The hook methods in the components decouple the application software from the reusable framework software, which allows each to change independently as long as the interface signature and interaction protocols are not modified. Since frameworks exhibit inversion of control, they can simplify application design because the framework—rather than the application—runs the event loop to detect events, demultiplex events to event handlers, and dispatch hook methods on the handlers that process the events.

Inversion of Control, it's not just for Spring anymore. :-) Seriously, though, how many of the current Ajax toolkits -- I'm not sure that with the exception of appfuse it's correct to call them application frameworks -- give you IoC? I'll be watching to see if they make the transition to frameworks and will give credit where credit is due.

Echo2 a Cult?

Paul Browne has nice little survey post over at O'Reilly about Ajax frameworks. All's cool until I stumble across the following:

Echo2 - Evolution of original Echo Framework, can run in any Servlet container. Original has cult following, but doubt if it will become the number 1 web framework.

I hear you, Paul. I remember evaluating Echo1 a long while back and thinking to myself: "why would you want to build a web application the way you would a component based desktop GUI? The behavior is so different, the lack of control, layout, look and feel, etc., etc." My conclusion was that Echo1 was a nice design solution applied to the wrong problem.

Fast forward to today. I have DHTML, CSS, Javascript, XHR, etc. I have complete control over what shows up in the browser, anywhere, any time, anyhow. I've got people writing thousands of lines of rich client application code, business tier logic leaking into the browser, cat and dogs living together...you get the idea.

Now the Echo design solution makes plenty of sense. The simple report and forms beast of the early 90's has turned into a kind of GUI desktop. Now my reaction is "why wouldn't you want to write a rich client web app the way you would write a component based desktop GUI?" It's a proven design. Nobody twiddles the bits by hand anymore. And when the browser wars start up again, the standards start diverging, and your Ajax apps start breaking, then the problem starts resembling that of a cross platform GUI, i.e. isolating Ajax variations in browser specific peer classes, much like AWT.

You can easily imagine running the same application as a Swing desktop GUI or a browser embedded Flash app. That's if the design is right and makes use of what? That's right, browser or rendering layer specific peers.

Guess who has all that today? That's right, Echo2. Come on and drink the Kool-Aid.