Read the Original Article at http://www.informationweek.com/news/showArticle.jhtml?articleID=50500819
Some companies market integrated development environments (IDEs) to be "all Java," "data oriented," or "driven by business process management." Nexaweb Technologies' Nexaweb is built on a different kind of premise (I'm taking liberty with characterization here): "The Web environments for applications and most Web applications suck." More specifically, most Web applications are slow and unresponsive to the user. They also lack the richness of user interface people are accustomed to from their desktop software. Insofar as these assertions are true, Nexaweb offers a significant solution.
I'll go into some detail on the technology behind Nexaweb because it's a young company with bright ideas, and the ideas are interesting even when the implementation has yet to be fully realized.
Nexaweb's model for a Web application deployment platform has three main elements: a Nexaweb Server running in a Java application server; a messaging system based on XML; and an intelligent Java thin client running in a browser. In this tiered Java-XML-Java approach, there's no HTML and no scripting language. The innovation is using XML to transmit data, logic, and user interface (UI) instructions from server to client (and vice versa), all in the service of better performance and a better user experience.
The server side of Nexaweb is relatively traditional, if Java can now be said to be traditional. The operational environment is a J2EE application server, which can be IBM WebSphere, BEA WebLogic, Oracle 9 Application Server, JBoss, or Apache Tomcat, the last of which ships with Nexaweb Studio. The Nexaweb Server is loaded into the application server and performs the heavy lifting for Nexaweb-enabled applications. Its main task is the transformation and management of data, business logic, graphics, and UI descriptions to and from the Nexaweb clients. It uses servlets, JSP, and EJBs to do this work, and much of a Nexaweb application is programmed into similar components.
PRODUCT SPEC SHEET
Minimum Requirements: JRE (Java Runtime Environment) 1.3; a Java Servlet Container supporting JSS (Java Servlet Specification) 2.2; 256MB RAM (1GB recommended); 400MHz CPU (1GHz recommended); JVM (Java Virtual Machine) 1.1.5 for the client browser.
Platforms: Windows 2003 Server (with Apache Tomcat) or Windows 2000 (with IBM WebSphere, BEA WebLogic, Tomcat, or Oracle AS).
Pricing: Based on server CPU and number of sessions. Starting price is $20,000 per deployment.
This version of Nexaweb supports server clusters — multiple instances of the Nexaweb Server, each of which can theoretically support up to 1,000 client sessions — and each of those sessions can process hundreds of transactions per second. I say theoretically because Nexaweb's architecture makes benchmarking this system difficult, and performance is obviously tied to the capabilities of the host application server. What I can say is that while clustering is supported, Nexaweb doesn't provide much in the way of cluster management or monitoring tools.
As I mentioned earlier, the main task of the Nexaweb Server is transformation and management of data, business logic, graphics, and UI descriptions to and from the client — the messaging system. The transformation is largely to repackage the information into XUL (pronounced "zool") and graphics into Scalable Vector Graphics (SVG), a W3C standard for describing 2D graphics in XML. By reducing complex graphical and UI commands into terse, compressed XML and updating with incremental changes, the amount of communication between the client and server is kept to a minimum. The workload, especially with MCOs, is allocated between client and server to maximize speed and responsiveness. This is how the "magic" in Nexaweb is performed.
The Nexaweb client is installed at run time within a browser and, at around 165K, loading usually isn't perceived by the user. Essentially, the client handles its end of network communication, executes MCO business logic, displays the UI, and manages client-side events. Nexaweb is insistent that developers stay within the limits of JDK 1.1 (an early version of Java) for client-side programming so that applications can run on any platform and any browser. The goal is to provide the widest possible deployment, with the greatest benefit from central storage of the application, and enhanced performance.
Figure 1: Nexaweb Studio provides the visual surface for developing Web applications that use XUL (XML user interface language) for the client program.
Because of the transformation of UI elements into XUL and other message-oriented optimization, elements of a Nexaweb application destined for the client side are different. For that reason, Nexaweb created Nexaweb Studio as the IDE to develop most of the client UI, to develop the business logic (MCOs), and to integrate other programming elements. Nexaweb Studio is built on the Eclipse IDE, wedding that environment to the requirements of Nexaweb's runtime scheme.
In most respects the development surfaces, available widgets, and plenitude of wizards (Component Wizard, Event Wizard, Application Wizard, Data Service Wizard, Layout Wizard, Data Connection Wizard) should be familiar to any developer that has used a major Java IDE. In fact, Nexaweb Studio expects that developers will be using other tools to provide application components that aren't created using Nexaweb Studio, especially Web services, EJBs, and some kinds of servlets. It provides explicit instructions for integrating with IBM WebSphere Studio Application Developer.
The following may be a key point for a lot of shops: Nexaweb uses the existing Java infrastructure — application server, security systems, database connectivity, JSP engine, EJB containers, and Java Servlet Engine. What needs to be changed (and Nexaweb can import Java code from other applications) are the UI, business logic, and perhaps some servlet action.
While most developers will have little problem adapting to Nexaweb for the UI or business logic, data management may be problematic. The current version of Nexaweb data service provides data to the Nexaweb client by transforming XML data with an XSL stylesheet into XUL. XML, Stream, and JDBC data providers are supported. The most common business end of this will be JDBC (and the JDBC/ODBC-bridge), which requires many steps to name and qualify the driver, qualify the data source, and finally to use a crude query builder for the SQL statement. What Nexaweb recommends is that JDBC/ODBC, EJB/Entity Beans, or JDO/JCache approaches be used, which means creating them in another development system.
This works, to a point, but it doesn't provide the kind of control over data typical in other IDEs where making data available to applications is emphasized. Data can be managed within Nexaweb Studio, but the relationship to data is murky and not optimized. (Anything that travels over the JDBC/ODBC bridge is suspect.) Nexaweb should be carefully tested before using it with applications such as analytics or reporting where large amounts of data need to be sent to the client either for processing or user interaction.
Figure 2: Nexaweb Studio uses numerous wizards to help the developer create an application for the Nexaweb method of deployment.
The clever use of XML (XUL/SVG) and incremental updating of the UI to create an ultra-thin messaging system makes it possible to have a rich — but thin — client. This is no mean achievement, but it's not necessarily easy for the average developer to understand. There are loose ends, in the documentation, in database management, and component integration. As a general impression, Nexaweb, more than many IDEs, is a work in progress. At this stage, it may be difficult to figure out the "road map" to using existing Java components and adapting applications for Nexaweb deployment.
The question is, then, is it worth the extra, or at least different, effort? Is this approach actually faster than HTML? Can users get a better application experience? Yes, they can. Timings with a couple of applications convinced me that the Nexaweb applications respond more quickly. Unfortunately, that was only two applications with a user base of one. The limit to scalability of a Nexaweb application is still an open question in my mind. I will say it's great to be rid of the screen blipping that's the curse of so many HTML applications.
Nelson King is a 25-year veteran of the coding wars. He has written nine books on application development, and his tool evaluations are widely published.