ICEbrowser SDK 6.0 and Nexaweb 3.2 leverage the power of Web standards while overcoming their limitations
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.
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.
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.
Ease of development (15.0%)
Overall Score (100%)
|ICEbrowser SDK 6.0||8.0||6.0||8.0||8.0||9.0||8.0|
Supreme Court's decision is bad news for developers targeting the U.S. market, who will now have to...
Siri gets smarter. Apple Watch gets much more useful. And is Apple Music poised to kill other streaming...
People who have it don’t want it. People who want it don’t have it. Here's how to go from iconed to...
The transition from command line to line of command requires a new mind-set -- and a thick skin
IT pros share their reading plans for the summer and recommend their all-time favorite books for...
Package ecosystem and graphics are strengths; security and memory management are weaknesses
Off the beaten path doesn’t mean offline, as long you take these mobile essentials with you