Refining the art of enterprise Web apps

JackBe Presto and Nexaweb Enterprise Web 2.0 Suite converge on a powerful and productive model for server-side mashups supporting AJAX clients

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.

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.

Click for larger view.

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.

The freedom starts to fade as you add enough of your own logic for gluing together the widgets, validating the inputs, or doing any other housekeeping. The JVM wants to speak Java and the AJAX layer wants JavaScript. There's no automatic way to push a button and make your application move from the Java client to the browser or back again, but the APIs are very similar. If you're writing code, the design patterns and structures are pretty equivalent. It makes me wonder if Nexaweb could incorporate a Java-to-JavaScript translator like the one used in Google Web Toolkit.

There are subtler differences that can be important. The Java version can offer a pure push option to the server because the Java code on the client can open a continuous connection. The AJAX code can only poll the server every so often. This may be an important distinction in some applications demanding heavy connectivity, such as apps for trading desks and other fast-paced realms. JackBe's JavaScript, by the way, can come close to approximating this by tricking the HTTP connection by sending down a bit of data every so often. It's not the same thing, but it can be just as effective.

Click for larger view.

A Java client is also useful in other ways. The Java APIs are rich with code for doing simple things such as loading local files and arcane things such as parsing image files. The Nexaweb Java client leaves these options open to you -- if you have client computers that are happy to open themselves up to the software. You can just link them into your code.

I tested the Nexaweb toolkit (Nexaweb Platform 4.5 and Nexaweb Studio 3.5) by building another tool that would mash up RSS feeds and display them in a browser. Nexaweb's back end offers many of the same features as Presto in different packaging. You can grab information from Web services, Web sites, and databases and then send them back over the "Internet Messaging Bus" to the client. The server can poll most of the same basic sources as Presto, but it can't manipulate the information as readily. Nexaweb's server doesn't have the same support for quick manipulation. You could certainly whip up most of this on your own, but it isn't as simple.

Click for larger view.

Drag and drop, you say
One of my pet peeves is that the marketing forces for both of these packages tend to suggest that building an application with Nexaweb or Presto Studio can be done without requiring any code to be written. Ha. Just because both applications include neat drag-and-drop tools that construct XML to describe the widget layout doesn't mean that you don't need to think abstractly and try to guess what the API wants to do. In both cases, I admit I was charmed by the quick ways to drag an RSS data source onto a table to produce a nice feed reader; I was also driven to tears by nasty little glitches that were the visual equivalents of sign errors. These are sophisticated systems that make life far easier, but you still have to think like a programmer.

The biggest competitor for both of these applications may be services like Yahoo Pipes, Google Gadgets, Metaplace, and any of the other mashup tools for the worlds of Facebook or These tools can similarly pull data from a number of sources, mix it up, and then deliver it to Web pages. They're simple and often free, or close to free.

Most IT professionals may be scared of such freedom, and with good reason. If the Nexaweb or Presto server does the mashing, it can decide on the rules for sharing information with the world. Control remains behind the firewall, not with some distant server farm owned by someone else. The downside of this tightfisted approach is that your customers will never surprise you with cool new applications or mashups, something that can be exciting until the so-called customers discover a way to embarrass or rob you. The obvious solution is to open up as many databases as practical but use tools such as JackBe Presto or Nexaweb to do the heavy lifting for more proprietary things.

The biggest customers for these products will be IT professionals with a deadline and a need to integrate a number of internal data sources. If the boss says that the customers need a single place to pull data and reports that tap disparate systems from different parts of the organization, then these are both good tools for creating a rich and usable application that hides some of the confusion going on in the background. They are even more valuable if the hidden sources can't be changed because the developer is long gone, too busy, or uncooperative. Scraping information from the other sources and integrating it all into one front end is quite useful. Both Nexaweb and JackBe Presto are ideal tools for the folks responsible for moving an enterprise's Web presence into Web 2.0 and beyond.

InfoWorld Scorecard
Value (10.0%)
Ease of development (30.0%)
Documentation (15.0%)
Performance (15.0%)
Capability (30.0%)
Overall Score (100%)
JackBe Presto 1.3.1 7.0 9.0 7.0 8.0 9.0 8.4
Nexaweb Enterprise Web 2.0 Suite 8.0 8.0 8.0 9.0 8.0 8.3