A lot of bits have been pushed around the blogosphere on the topic of
Ajax over the last few months. This includes
my own post back in March, which gave a general overview of what Ajax was and what it does. A lot of exciting stuff has happened since then, and Ajax has rapidy matured into a development of major significance. Coverage has been all over the map and runs the gamut from
Rasmus' been-there-done-that 30 second Ajax tutorial to Alex Bosworth's list of
Ajax Mistakes to the uber-repository of Ajax knowedge,
Ajax Matters.
Many of you already know that Ajax is a web client programming style which eschews traditional HTML web pages, which are only sprinkled lightly with JavaScript and reload pretty much every time they are updated or clicked on. Instead, an Ajax web client receives an Ajax JavaScript library into a hidden frame which provides run-time visuals on the main browser window that look and feel very much like a native application. Ajax web clients, once loaded, communicate with XML services on the back end (via a browser's built-in powerful XMLHttpRequest API), and then use JavaScript to manipulate what the users sees programmatically via DHTML.
All of this allows Ajax to provide a compelling user experience because 1) it doesn't reload the web page, and 2) it runs asynchronously allowing background server-side requests for information to be issued, all while the users clicks, types, and otherwise interacts with the application in the foreground. Google Maps is the pre-eminent example of a modern Ajax application: rich, interactive, easy-to-use, and predictive in that it loads the map tiles that are just offscreen in case you need them. This is all very good for web client client development, but why all the attention across the board?
Figure 1: Ajax: The first compelling new client application model since the modern web browser
Because Ajax is a sincerely compelling synthesis of the ubiquitous features found in the most popular Internet browsers is why. Practitioners of Ajax get high-intensity user interaction (end-user productivity), asynchronicity (efficient backround processing), web browser access to web services (web service access, reuse, and interoperability, as well as SOA integration), platform neutrality (browser and operating system agnosticity), and the Ajax feature set can be delivered as a framework you don't have to create yourself (developer productivity).
Individually, these items are very nice, but taken as a whole, working solution and you have something extremely special. While many folks thought the web browser story had stopped around the year 2000, Ajax takes us to a whole new place. Slashdot recently highlighted a notable new article in Wired that claims that the industry, mostly on the basis of Ajax, "has affirmed the viability of the web as a standalone software development platform."
This is no small thing, and has the potential to repave the modern application development landscape. Why? Because Ajax creates a rich and fertile new space for developing software solutions that can reach almost anyone, anywhere whatever they're browsing with. It doesn't require anything more specific than your local browser, is based on standards, and leverages all the services that most organizations have in place in their back office, especially if they have been building service-oriented architectures.
Of course, there are some problems with Ajax, as there inevitably are with any major new approach. One is testing. You not only still have to test your applications, but even more thoroughly. Given that JavaScript, DHTML, XmlHttpRequest, and DOM support all vary slightly between browsers, you need to test your Ajax applications in all supported browser versions and in multiple screen resolutions to make sure you have all the kinks out. This is a pain and can be expensive, but can be dealt with by establishing good test procedures and automated test processes when possible.
The full test of a new application platform of course, is ready support in the form of available frameworks and development toolkits in both the commercial space and open source communities. And this shows us that interest in Ajax is high indeed. Everyone from TIBCO (General Interface) to Microsoft (Atlas) has Ajax development environments and frameworks rapidly on the way to market in the commercial space, while the open source world has already delivered numerous smaller tools. While Ajax Matters lists over 30 different Ajax tools and utilities that are already available, SourceForge lists significantly fewer active Ajax projects, which tend to be more serious, larger scale efforts. These include such offerings as ThyAPI, the Ajax Framework project and the Simplifying Ajax in Java projects, which appear to be the top three Ajax development kits currently listed on SourceForge. Also particularly notable in open source is SAJAX, which has nice support for Python and Ruby that claims to do "99% of the work for you." In fact, the newer, cooler languages are getting great support for Ajax, see here for a detailed post that affirms Ruby on Rails to be excellent for Ajax development.
As for blogoshere mindshare, Ajax is currently listed as the #6 overall blog search term on Technorati in popularity, right after "xbox 360". This implies that you'll see a lot of Ajax in web sites near you since developers appear to be vacuuming up the patterns, practices, and toolkits for creating Ajax applications. Unfortunately, there are few books out yet about Ajax, though Dave Crane and Eric Pascarello's Ajax in Action
will apparently be out soon.
So all this activity points to the relative seriousness in which the software industry takes the Ajax movement, an approach which was only described tacitly earlier this year. What does this mean for SOA architects? A number of things...
SOA Implications
One: Ajax clearly embraces XML as the service payload of choice (though many Ajax users leverage JSON instead of XML, which is not technically Ajax, of which the last letter represents the X in XML). This clearly aligns very well with XML web services and open-standard SOAs.
Two: Lightweight SOAP and REST services are in and WS-* services may be on the rocks. Since Ajax applications can and will frequently call backend XML web services as the user interacts with the front-end, having lightweight, easy-to-consume, high performance/availability SOAP and REST web services will only become more important. Of course, the implication is that since Ajax applications live in a fairly austere JavaScript sandbox, this means heavy-duty WS-*-style SOAP stacks probably won't play well with the lightweight XML/JSON service interactions that Ajax prefers. This doesn't mean WS-* is broken for Ajax, but at this time there are no Ajax frameworks yet that support more than basic SOAP service interaction. This certainly will affect SOA architecture since it's likely that Ajax will increasingly push back-end services to be extremely scalable, high-intensity, and atomic instead of the more pastoral XML document routing and orchestration view that many SOA architectures promulgate. In fact, Ajax is really more REST friendly since the interaction model is highly stateful, more resource-oriented, and can leverage the HTTP scalability and reliability mechanisms that most organizations already have. And that REST services automatically take advantage of.
Three: Beyond basic questions of load and message exchange pattern (document routing vs. atomic/state-like data transmission), there is a question of whether your SOA will be used more for integration between monolithic applications or as an access enabler. The simple answer is both. But the problem is that it's a classically hard problem to merge two architecture styles together into one solution. Just look at the tension between transaction processing and reporting for a particularly famous example of the problem. Using the same database for both is virtually impossible and the architecture has to get fairly messy to have up-to-date information from the transaction processing side available for reporting. SOAs have to grapple with this issue increasingly and Ajax applications flowering within your organization's walls will force your SOA down a path you may not be ready to go down. So consider this a warning, Ajax adoption in your organization has the potential to drive your SOA for you as web app developers decide they like the services they find. For a good example of some of the thinking that will have to go into SOAs as Ajax grows in popularity, see this excellent post by Joseph Scott.
All this being said, Ajax has a long way to go to be ready for prime-time, white collar, Fortune 1000 usage. Until solid commercial development options from major vendors are available and reasonably mature, larger organizations will probably wait. But as Jeff Schneider so succinctly pointed out recently, "casual services, dynamic scripting, and remixing are clearly the theme for 2005", and the rest of the industry isn't waiting. As Ajax proves to be the application model that allows compelling composite applications to be developed quickly, I expect that 2006 will be the year that Ajax emerges as both a key driver of SOA architecture (important: because, without a SOA, there can be no Ajax applications, by definition) and a must-have application development model.
Update: Dare Obesanjo recently enumerated some key points that Ajax application architects have to contend with and a few of them are particularly worthy of note including how to deal with the need for permalinks, the Back button, and others. Please check it out. He also notes that MSN will be talking about their best practice Ajax techniques at Microsoft's PDC developer's conference next month, which it looks like I will attend. Since a prerelease version of Atlas will be available there as well, expect some updates here on this blog on the latest.
SDL Survey Update: I'm simultaneously working on the REST version of the order service as well as the SSDL service description and clients. Expect these shortly!
mp3
Update: December, 2005 - The Incredible Ongoing Story of Ajax. All the latest tools and techniques to build great Ajax software.
Update: January, 2006 - Why Ajax is So Disruptive
Update: February2006 - The Ajax Spectrum: Some design issues I've discovered with Ajax.
Update: March, 2006 - My
Real-World Ajax experiences with Jesse James Garrett, David Heinemeier Hansson, and others.
Update: March, 2006 - Lots more Real-World Ajax including video dicussions with Ajax luminaries Bill Scott, Kevin Hakman, and others.
Technorati:
Enterprise Architecture,
Computers and Internet,
Programming,
Web Services,
Ajax