It seems that AJAX (Asynchronous Javascript And XML) has gained an extensive momentum since Jesse James Garrett from Adaptive Path has coined the term back in February 2005. I take as another proof the fact that O'Reilly and Adaptive Path have teamed up for organizing the first AJAX Summit that took place in San Francisco on May 9-10, 2005 and whose main goal was to bring together a group of top developers and designers who were supposed to start shaping the future of AJAX. You can find a couple blog entries summarizing the highlights of the summit on the Ajaxian blog.

For the novices, two facts about AJAX are worth noting right away. First, AJAX is not a standalone technology, but more a term for refering to a group of several different technologies (Javascript, XML, CSS, HTML, XSLT, DHTML, etc.) that leverage each other's value in order to provide a bigger return than what would be achievable by each single technology in isolation. Secondly, the AJAX acronym is relatively new, but the technologies that make up the AJAX infrastructure are not. They have been around for quite some time now and people are discovering every day how well they complement each other and what wonders they can achieve when used efficiently. Judging by how much resources Google (Google Suggest, Google Maps, etc.) and Amazon (A9 search engine) have invested on the AJAX technology set for bringing Rich Internet Applications to the market, we can only wonder how big the full potential of AJAX is. The future will tell.

Recently, Backbase published a white paper titled "AJAX and Beyond" whose primary goal was to announce the first full-fledged commercial AJAX implementation. Judging by the information available in this white paper, it seems that their AJAX solution is quite mature and powerful. They provide both a Java and a .NET edition as well as a community edition that can be downloaded free of charge for any non-commercial use.

A dedicated entry for AJAX has also been created on Wikipedia and is being updated quite frequently from what I know. The open-source movement is not sleeping either. On Sourceforge, there are more than a dozen ongoing projects aiming at providing some sort of AJAX support for a great diversity of purposes, such as content management systems, asset management systems, Java widgeteries, tag libraries, web services support, and so on. Note that there are a few projects on Freshmeat as well. The JavaRSS syndication site has also provided an explanation page on how AJAX is used on their web site for bringing dynamic content live in an efficient way. Java.net have also updated their blueprint catalog in order to include some insightful information on how to integrate AJAX in a J2EE environment.

Finally, as it is usually the case, emerging trends have their proponents and opponents. In the latter group, we can find Macromedia Flash freaks who see AJAX as a threat to their Rich Internet Application solution. Johnnie Manzari's "Ajax: 99% bad" blog entry tries to demonstrate how bad AJAX is compared to Flash. My opinion is that at least AJAX is made up free and open technologies that are not evolving under one single corporate umbrella. This independence is one of the keys to a successful adoption. Flash is not bad and neither is AJAX. Both bring value and none of them are silver bullets. Smart people will just have to figure out which solution to use for solving the problem at hand. Let's not start another endless crusade about which technology is better or worse. Let's keep in mind that the technology is just there to support the business that runs on top of it and this is what really matters.

This being said, I'm convinced that AJAX is definitely here to stay and that it has most certainly not yet unleashed its full potential. If you want to get acquainted with this new trend that will heavily contribute to bridging the gap between the lightweight web applications and the rich client applications, you better don't wait too long in the starting blocks and start browsing a little bit. You can start from my Blogroll whose AJAX feeds are enumerated below:

Since its inception in 1998, XML has gained a lot of popularity and a broad acceptance in the industry and academia. I take as a proof the increasing number of standards and vocabularies based on XML as well as the growing number of software houses and independent software development groups that have adopted XML as the base language for the support files of their products (deployment descriptors, configuration and property files, preferences, etc). Undeniably, the members of the W3C XML Activity, such as Microsoft, BEA, Sun, etc, have managed to erect XML as the de facto standard for interoperability. Of course, some will object that XML-based applications are not always (often?) 100% interoperable because of the legacy stuff each party throws into the mix, but this is another debate.

Together, the pervasiveness and the ubiquity of XML have triggered another problem that is serious enough to have warranted the creation of a new working group. The ever increasing use of XML for exchanging data and invoking remote services has had an enormous incidence on the network bandwidth and the processing power of the computers and devices that take part such XML interactions. If we just start to feel the embryonic effects of XML's fame today, this will eventually become more perceivable by the time web services will have truly taken off (if ever) and when XML will have become unavoidable because standard-setting industries will have started shipping XML based products and stopped providing support for alternative technologies.

The new XML Binary Characterization (XBC) working group that has been created in 2003 as part of W3C's XML Activity is chartered to create a recommendation for a binary format for XML. It is worth noting that the essence of this new recommendation will be different from the XML-binary Optimized Packaging recommendation created under the Web Services Activity umbrella. This new format shall drastically lower the bandwidth and processing power needs for processing XML communications, but as nothing comes for free, this will happen at the cost of human readability. Some companies, such as Microsoft, have already devised some binary format for XML that they use internally mainly for efficiency purposes. The goal of this new XML standard is not to deprecate current XML standards, but to interoperate with them and with other related technologies in the XML Stack. After careful considerations, the XBC working group has concluded that: 1) Binary XML is needed (see the use cases below); 2) Binary XML is feasible; 3) Binary XML must be produced by the W3C in order to preserve XML interoperability; and 4) Binary XML must integrate with XML.

Furthermore, the XBC working group has identified 18 use cases where Binary XML will most surely bring huge benefits:

1. Metadata in Broadcast Systems
2. Floating Point Arrays in the Energy Industry
3. X3D Graphics Model Compression, Serialization and Transmission
4. Web Services for Small Devices
5. Web Services within the Enterprise
6. Electronic Documents
7. FIXML in the Securities Industry
8. Multimedia XML Documents for Mobile Handsets
9. Intra/Inter Business Communication
10. XMPP Instant Messaging Compression
11. XML Documents in Persistent Store
12. Business and Knowledge Processing
13. XML Content-based Routing and Publish Subscribe
14. Web Services Routing
15. Military Information Interoperability
16. Sensor Processing and Communication
17. SyncML for Data Synchronization
18. Supercomputing and Grid Processing

As we can see, these use cases cover pretty much 80% of the areas where XML is already in use today. The question is: can we do better than what we are already doing? The XBC members tend to agree that conventional XML leaves much room for improvements in the context of the above mentioned use cases. According to W3C's track record, I'm pretty much sure that a majority of people will benefit from whatever comes out of the pipe. In a couple days, I'll try to come up with some concrete example in order to delve a little more into this binary mud.

Other interesting resources:
- David Geer: Will Binary XML Speed Network Traffic?, Computer Magazine, April 2005.
- Sun's Fast Infoset project.
- International Telecommunication Union's Fast Infoset project.