It is now more than two years since the AJAX (Asynchronous JavaScript and XML) buzzword swept through the world of client-server applications, up-ending the old architectures and spurring us to rethink how we can make the browser the center of our world. But long before the coinage of AJAX, rich-client framework vendors JackBe and Nexaweb had already embraced and extended what has become the AJAX ideal.

[ See also: InfoWorld Technology of the Year Awards Application Development winners ]

JackBe became known for distributing a full, browser-based IDE for JavaScript applications before the AJAX buzzword was coined. Their engineers understood AJAX before most of us. Now, their system has grown dramatically to mesh with a new server-side data mechanism for mashing together HTML, RSS feeds, WSDL calls, and SQL calls into one data feed for clients. This big, bold brand, known as Presto, has eaten the old JavaScript development plug-ins for Eclipse, now known as Presto Studio.

Nexaweb, on the other hand, began as a Java-based framework for building client-server applications that connected a set of XML-defined widgets to a set of data sources through a J2EE server. It offered the kind of client-server framework that Presto now offers -- but it sent this information to a Java-based tool on the client. Now, the company has built an AJAX version for deploying the client, giving developers another pathway for your application.

Both show how far the world of AJAX -based clients have come while illustrating just how lost they can be without adequate server support. JavaScript is a good language for building robust user interfaces. But the Web is a dangerous place, and these applications need a good back end. Both JackBe Presto and Nexaweb Enterprise Web 2.0 Suite give this support.

Click for larger view.

The Presto approach
The Presto back end is a robust octopus of an application designed to live on the server, collect data from all possible sources, and repackage it for the JavaScript client. It is the kind of application that a JavaScript developer starts dreaming of writing after discovering that XMLHttpRequest can call only the original domain that delivered the JavaScript. This cross-domain scripting limitation means that the server must do all of the proxying for the client.

The Presto developers point out that there are a number of advantages to this approach, and they've built many of them into their code. This server, called the Presto Edge, can cache the data, translate the information into a common format, and even mash it up with some basic transformations. It also can straddle the security line and act as a firewall between the JavaScript clients in the wild and the pampered servers inside.

Presto Edge can suck data from WSDL, REST (Representational State Transfer), Atom, RSS, SQL, KML (Keyhole Markup Language), WMS (Web Map Service), and POJO (plain old Java objects) calls before translating this data into JSON (JavaScript Object Notation) or XML for the clients. The information can be mixed together by creating views that, in turn, can be joined together, sorted, filtered, or annotated. This federated approach also contains all of the logic for dealing with the security of distant data sources such as an LDAP directory. It offers an additional layer that lets you give users access to certain mashups of data without giving them complete access to the data source. Given that many of the most egregious security holes come from giving the browser too much power to craft pure SQL, this is a good design practice.

Click for larger view.

I tested the mechanism by building a few mashups that pulled data from RSS feeds and a database. The tool is a pretty nice Swiss Army Knife for mixing together different data sources. The JackBe folks argue that putting so much security control into the server is a logical approach for cautious developers. Presto Edge can poll servers behind the firewall and clean up the data before sending it out to the client. Without it running interference, the only solution would be bolstering the security of each and every service you wanted to expose to the outside world.

Nexaweb's way
The Nexaweb application began as a pure Java-based tool, but now it's expanded to offer a JavaScript version for the client. The applications are still built in a collection of Eclipse plug-ins, but now you can choose whether you want the XML that describes the locations of the widgets to be interpreted by a JVM or by a browser. The XML itself remains the same, making it possible to switch freely between the two options.