ICEsoft and Nexaweb wax where the browser wanes

Web browsers are wonderfully ubiquitous, but they offer substandard user interfaces because they do little to anticipate what the user might want. Most clicks require a round-trip to some distant server over a sometimes dodgy Internet. To make matters worse, the browser is beholden to the user, not the developer. It often prevents the server from doing much except displaying images, a bit of text, and maybe a fancy bit of multimedia -- and then, only if the right plug-in is installed.

Two companies, ICEsoft Technologies and Nexaweb, offer Web application developers another option. Both offer tools for building more fully powered Web clients that behave similar to browsers but offer developers deeper control. Their tools take radically different approaches and aren’t direct competitors, although they might be used to solve some of the same problems.

ICEsoft’s solution offers the developer the complete Java source code to a browser. Developers can clone Netscape with a few lines of code and then use the hooks to turn the right features on or off.

Nexaweb also offers a client, but it isn’t a full-fledged, standards-compliant browser. Instead, Nexaweb integrates a rich collection of widgets into a server, offering performance and behavior similar to traditional client/server applications. Both solutions are aimed at the Java developer community.

ICEbrowser SDK 6.0

To test ICEsoft’s version of the browser, I decided to build my own application, PeteZilla, that would offer a bit of digital rights management. This browser would display standard HTML but would disable caching, saving, or printing the file. Furthermore, it would use SSL encryption to secure the Web traffic and use standard authentication to control access to the server.

This browser was easy to create, in part because one of the dozen or so examples included with the ICEbrowser SDK accomplished most of it. Displaying HTML in a window requires approximately eight lines of code to create the frame and add the standard ICEsoft component to it. The code works with both the AWT (Abstract Window Toolkit) and Swing frameworks, making it easy to start up.

The toolkit comes with a fairly impressive collection of hooks that tap into most stages of the HTTP process. Authentication, for instance, generates events that can be caught and handled by an AuthenticationListener. If you want to add your own layer to handle the passwords and the interaction, it’s simple to hide this from the user. The events are the developer’s to grab, not the browser’s.

The rendering engine also generates a number of events as the document is parsed and the images are loaded. It’s easy, for instance, to include a status line that shows the progress toward building the entire display.

ICEsoft’s toolkit made building PeteZilla easy. Separating the content from the controls -- for example, leaving the content markup in HTML -- made it possible to delegate some of the work to Web designers so I could concentrate on coding the encryption to protect the content. Apple’s iTunes application is a great example of how a Web-browser model can be expanded with additional features without abandoning all the richness of existing tools.

Indeed, the biggest competitors to ICEsoft’s product may be open source projects such as KDE’s Konqueror and Mozilla’s Gecko. They cost nothing but do come with open source licenses that limit how you may use the result. They are also written in C, a limitation if you or your shop wants to use Java.

Another big competitor will always be plain-old Web applications that don’t require any special modifications on the client side. It may be possible to live without the extra features of the ICEsoft browser while making do with a few cookies and some fancy JavaScript. ICEsoft’s browser works best when you want the basic features of the HTTP world but can’t live with the structural limitations of the current browsers.

Nexaweb 3.2

Nexaweb’s toolkit is another good example of how Web standards can be bent to your needs without being broken. Nexaweb’s solution offers a world of rich clients synchronized with rich servers.

As opposed to ICEbrowser’s, the Nexaweb client isn’t a full clone of a browser, but it does offer many of the standard widgets. It runs in versions of JVM back to 1.1 and offers fast, local interaction for the user. Some of the best applications for Nexaweb are Web applications that need better performance than that found in a standard browser.

The Nexaweb toolkit offers a simple framework for building client applications and for linking them to a distant server with packets of data known as MCOs (Managed Client Objects). Nexaweb shuttles these objects back and forth between the client and the server, compressing and encrypting them as necessary. Most of the transit details are hidden from the programmer, who is freed to concentrate on processing events generated whenever the MCOs complete their trip.

To test the system, I tried building a simple sports scoreboard that would update itself, a throwback to the days of the push client. The framework is simple to use, offering the standard widgets bundled with the AWT.

Nexaweb Studio, built on top of the Eclipse open source IDE, comes with several plug-ins for building these clients by dragging and dropping the components. The plug-ins produce an XML-encoded file -- similar to XML User Interface Language -- that carries the details about the interface, and the Nexaweb client handles the details of decoding and displaying it.

Encoding the business logic for the system requires creating the MCOs. These are written in Java but are invoked by links coded in the XML describing the application. After they are created, the MCOs have access to the local client and the server.

I found that my simple sports scoreboard wasn’t good enough to push the Nexaweb framework. Several of the examples included with the system do a better job showing off the advantages of building a rich client. One of the order processing examples, for instance, has a snappy interface that clicks you through a large stack of orders, eliminating the wait for a distant server to process the request and send back a pile of HTML.

The full Nexaweb installation comes with a complete version of Eclipse as well as a version of Tomcat. If you’re familiar with Eclipse, the product is easy to use, although it may seem a bit like cribbing. If Eclipse is new to you, you’ll be amazed what a little company can offer simply by building on top of an open source toolkit.

Nexaweb Studio’s wizards make it easy to get started. A few clicks create a project, and a few more finish off the configuration of the Tomcat server. In minutes, the JSP and XML files you create are defining data fields and interfaces for a user in a distant browser. Many of the configuration headaches of integrating these pieces are handled for you. The packaging is nice, too.

I think the greatest competitor to Nexaweb will be JavaScript itself. Although I continue to be a believer in the capabilities of Java applets and Java clients launched by Web Start, there’s no doubt that JavaScript-based tools such as Google’s Gmail are impressive. The language that was once responsible for a few display hacks is now handling complex desktop applications with real success.

This success, however, must be the result of long, hard hours of debugging. Thousands if not millions of differences among JavaScript implementations provide little consistency to help the developer. Java, on the other hand, is a well-designed language created by programming professionals with experience building large systems. Nexaweb’s toolkit leverages this and adds a great deal of functionality for carrying these objects back and forth.

Still, the competition from the standard browser and increasingly standardized JavaScript highlight the limitations of choosing something other than HTML/HTTP. As a result, Nexaweb’s tool will appeal to a different developer than will ICEsoft’s product. Nexaweb is fixing some of the basic problems with the HTTP protocol, at the cost of forcing you to abandon standard HTML. It would be silly, for instance, to create a PeteZilla browser using Nexaweb’s framework.

Conversely, ICEsoft’s solution stays safely in the harbor of the HTML standard, but that means it can’t fix all the problems with HTTP. You could use it to create a push-based tool to display sports scores or offer more interactivity, but it wouldn’t be easy.

These tools inhabit different development niches, yet both offer useful ways to leverage today’s Web standards and overcome their limitations.