Are you looking for an online tutorial on Asynchronous JavaScript And XML? This is not the place for you then, but Max Kiesler's round up of Ajax online courses might be. Nevertheless, before reading on you should be aware of what AJAX is all about. Here's the quote from Jesse's original paper:

Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:

• standards-based presentation using XHTML and CSS;
• dynamic display and interaction using the Document Object Model;
• data interchange and manipulation using XML and XSLT;
• asynchronous data retrieval using XMLHttpRequest;
• and JavaScript binding everything together.

Strangely enough, communication via JavaScript's XMLHttpRequest object is - despite its name - not limited to XML contents. You can send and receive anything which can be transmitted via HTTP.

Ajax techniques can be used in a billion ways to embellish traditional flow-oriented web apps. However, more interesting for me is the foreseeable shift to web-based SPAs (single page applications), yet another acronym that tries to manipulate our subconscious mind with its standard English meaning.

As for the connection between domain and presentation logic SPAs resemble much more rich client applications than web apps. One of the more complex decisions you have to make when distributing a program between two computers (the client and the server) is: What code should we have on the server and what code should we develop for and deploy on the client.

On the extreme ends of the imaginable solution space you have the "SOA-infected guys" and the "composable widgets people". The first group advocates to have all integrating business logic, i.e. the application logic, on the client and to only invoke application-independent "service calls" on the server. The latter crowd even compose the user interface layout on the server - usually doing some JavaScript generation behind the scenes - and wire the individual widgets living on the client to their counterparts on the server.

Personally, I have issues with both ends:

• Building user interface experiences with Html, CSS, JavaScript and DOM does not lend itself very well to the composable widgets perspective. Moreover, the tight coupling between client- and server-side widgets leads to high-frequency communication; in many cases this communication is conceptually synchronous.
• "Just" calling services and aggregating their results into application-specific behaviour, however, requires that you have (at least large parts of) the domain model available on client-side, i.e. you have to do some non-trivial mapping from your server-side language to and from JavaScript. The generic kind of services often delivers more information than actually needed for display, thus bandwidth becomes more of a problem. Additionally, interpreted JavaScript is not fit for large amount of computation.

So, I decided to search for an approach that allows me to have all *presentation* logic and code in the browser but all *application* and domain logic on the server. As a surplus gift I'd get testability of application logic for free! I didn't have to look for long, though. Hiding all application logic behind an application facade has been my favourite architectural refactoring for years. There are two basic forms of application facades (see e.g. Martin Fowler's presentation patterns):

• Presentation Model
• Model View Presenter

Common to both is their strong ambition to decouple user interface from logic. And both can - in theory and praxis - be used for Ajax-driven SPAs...

I hope that's enough of a cliff-hanger to keep you tuned.

Johannes