Overview

Nexaweb is a software platform for building and deploying Enterprise Internet Applications. Nexaweb-powered Ajax and Java applications offer the richness of a desktop application with the flexibility of the Internet, while leveraging existing investments in technology and resources. Nexaweb applications include client and server components. The following table lists some highlights of these components.

Nexaweb Component	Highlights
Client	Runs inside all popular web browsers on all major operating systems, without requiring installation. Includes built-in user interface functionality that processes many UI operations locally that a traditional web application would require a page refresh for, such as table sorting and column swapping. In addition, customized code can be transported to and run on the client, allowing client-side code to validate information or even update the UI without a round trip to the server. Maintains application state information during the session, eliminating the need to completely reconstruct the client state for every request/response. Only small, incremental updates are necessary, not full page refreshes. Conducts state synchronization with the server through infrequent exchanges of short, compressed messages - typically only several hundred bytes per message. By combining this feature with a much higher level of intelligence on the client side, Nexaweb significantly lowers server load and network bandwidth consumption. The Nexaweb development environment provides you with the ability to configure the look and feel of the application through the use of XML based UI style-sheets, similar to HTML Cascading Style Sheets, making it easy to maintain and update the look of an application separate from the logic and workflow.
Server	Runs within a J2EE Application Server. Nexaweb and Nexaweb enabled applications are developed and deployed in the same manner as traditional J2EE applications. Routes HTTP requests to applications, caching client-side state information, and providing network communication support transparently.

Nexaweb Platform

In a typical Web application deployment, in which the Web application is deployed as a WAR file, Nexaweb-enabled applications require only a J2EE Java Servlet container version 2.3 or higher, such as Apache Tomcat 4.x. Although you can also deploy a Nexaweb-enabled application to a full J2EE application server (such as BEA WebLogic or IBM WebSphere) as it supports the Java servlet technology, a Nexaweb-enabled application doesn’t require the additional capabilities of a full J2EE application server (for example, Nexaweb doesn’t require any Enterprise Java Bean (EJB) programming).

Steps to create a Nexaweb-enabled application

To create a Nexaweb-enabled application, you specify the UI in XML and application logic in Java classes or JavaScript statements, using the tools of your choice to edit, compile, build, and package the application.

Note: In the interest of simplicity, this account of the development cycle is deliberately oversimplified, as it omits the description of substeps and overlooks many options the Nexaweb Platform provides. Subsequent sections drill down further into the details and nuances of Nexaweb Platform application development.

1. Create the user interface (UI)

Nexaweb-enabled applications use XML to define their UI, referred to as UI XML. Within the Web application’s directory structure, you put the UI XML files in the same standard places where HTML files would usually reside.

2. Write event handlers

As with any Web application, you can write server-side event handlers as servlets and JSPs.

In addition, when developing a Nexaweb-enabled application, you can write:

Client-side event handlers (called MCOs, within the Nexaweb Platform), as Java classes or JavaScript statements that are downloaded from the server on demand.
Event handlers that directly reference flat files containing UI-modifying XML directives using XModify. These files reside on the server, and are referred to directly via URLs.

3. Nexawebify the application

Without Nexaweb Studio

Nexaweb provides the nexawebify utility, an Ant task you can invoke during your build, to Nexaweb-enable the application. The utility copies all of the Nexaweb Platform components and resources into the application’s deployment directory structure. It performs an intelligent unzip of the file, nexaweb-platform.zip, into the application directory. The intelligent unzip ensures that the appropriate Nexaweb components are merged into your application's web.xml file.

With Nexaweb Studio

You can also run this utility from Nexaweb Studio for existing projects that you import into Nexaweb Studio by selecting Project > Upgrade Nexaweb Platform. See the Studio Documentation for more information.

For new projects that you create with Nexaweb Studio, Nexaweb Studio automatically adds Nexaweb support.

Deploying a Nexaweb Application

1. Package the application into a WAR file

A Web application has a standard deployment directory structure. All files and subdirectories within this directory structure are visible to the Web browser, except
for the special standard subdirectory, WEB-INF.

The Java Servlet specification requires the presence of a registration file, termed the application’s deployment descriptor in the WEB-INF subdirectory. The application’s deployment descriptor is an XML file named web.xml, which contains various application configuration settings and declarations of the application’s servlets and JSPs for the benefit of the servlet container.

Beneath .nexawebcontent\WEB-INF are two subdirectories:

classes - where Java classes reside;
lib - where .jar files reside.

Directories containing application-specific resources can also appear beneath nexawebcontent\WEB-INF.

Typically, you package the entire directory structure as a Web archive or WAR file, a zip archive with the file extension .war. To deploy the WAR file, you follow the appropriate procedure for the container where the application will run. The Nexaweb Platform's components run on any Java Servlet container version 2.3 or greater.

Runtime Architecture of a Nexaweb-Enabled Application

This section provides an overview of a Nexaweb-enabled application at runtime, describing the components involved, where they reside and execute — on clients and on the server — and how they interact. Subsequent sections discuss aspects of the Nexaweb Platform from a more conceptual perspective.

On the Client Side

Ajax

You deploy Nexaweb-enabled Ajax applications on the client-side as an Ajax client.

Java

You can deploy Nexaweb-enabled Java applications on the client-side to run either as a:

Java applet within a browser
Standalone Java application installed on user machines.

At run time, the Nexaweb client engine manages the application's presentation — both the rendering of its UI and the management of UI events — and ensures that it runs the current version of the Nexaweb-enabled application, downloading the latest version from the server as needed.

User Interface (UI)

Defining State

The Nexaweb client engine maintains an in-memory document object model (DOM) that defines the state of the user interface. Unlike an HTML page-based model, the Nexaweb Platform UI document is maintained across requests to the server. This model is manipulated either programmatically by Java APIs, or by UI XML markup language.

Modifying State

The state of the UI changes when a specific DOM, the UI document, is modified. Because the UI document can be searched, and because all its elements have unique IDs, the UI is updated incrementally (unlike the HTML situation). The state of an individual UI element can change without all other UI elements refreshing. The Nexaweb client engine renders to the end-user screen the current “instructions” contained within the UI document. These “instructions” include elements specifying UI widgets such as buttons, labels, tables, and charts. For example, the Nexaweb client engine renders a button to the end user’s screen whenever it encounters a button tag (i.e., <button … />) within the UI document.

UI document is modified either:

Programmatically -
Through Nexaweb Platform Java APIs supplemented by developer-supplied Java classes. The Nexaweb client engine donwloads the classes containing client-side event handlers that are used and declared in the UI XML from the server as needed (on demand).
Declaratively -
Using XModify, an XML document that uses XModify tags (insert-before, insert-after, append, replace, and the like), which specify how to modify another XML document. These changes are incremental — for example, a stock-watching application can update the value of a single field, rather than having to re-specify the entire UI definition. All of the UI XML documents that the Nexaweb client engine accesses — such as the initial start page, and UI XML accessed from flat files, JSPs, and servlets via event handlers — are change instructions for the in-memory UI document.

On the Server Side

At runtime, the only server-side infrastructure required by the Nexaweb Platform is a version 2.3 or greater Java Servlet container which hosts the deployed Nexaweb-enabled application. The Nexaweb Platform’s server-side components support clustering, failover, Web services, and real-time push from server to client. Since a Nexaweb-enabled application is a standard Web application, all of the existing capabilities of a J2EE application server (Enterprise Java Beans (EJBs), Message Driven Beasn (MDBs), and so on) are available for use by a Nexaweb-enabled application.

Servlets and JSPs may provide additional server-side functionality. An existing Web application ported to the Nexaweb Platform, likely reuses existing servlets and JSPs.

The Nexaweb Platform lets an application maintain data on the client, on the server, or on both. It can even synchronize copies of XML documents stored on both the client and server, so that when one copy of the data changes, the other is automatically updated. You can also register listeners to be notified of those changes.

Communication Framework

All tiers of a Nexaweb-enabled application communicate by means of the Internet Messaging Bus (IMB), the most unique and powerful part of the Nexaweb Platform. The IMB provides Nexaweb-enabled applications messaging capabilities not normally available to Web applications, such as two-way messaging, pushing data to clients, publish and subscribe messaging, and guaranteed order of delivery for application messages — all in a secure and reliable way.

The IMB supports:

Bidirectional communication between client and server
Inter-server communication (in the case of clustered servers, for example)
Inter-client communication (through the server, however, does not require you to write any server-side code)

The IMB uses existing standard Internet technologies such as HTTP and HTTPS to ensure maximum compatibility with existing infrastructure.

Client Deployment Options

You can deploy Nexaweb-enabled applications either as:

A small browser-based Java applet
An installable, browser-free desktop client

Browser-based Java Applet

The most common method for deploying a Nexaweb-enabled application is as a small browser-based Java applet that requires no applet-specific programming to develop. The browser-based client provides:

Applet security - provided by the secure sandbox in which a Java applet runs
Ease of deployment - the browser-based client doesn't require any installation on client machines, thus eliminating many support headaches.

The Nexaweb Platform takes on the burden of ensuring compatibility across:

Browsers (Internet Explorer versions 4, 5, 5.5, and 6; Firefox, Safari, Mozilla, Netscape)
Java virtual machines (from Microsoft, JVM version 1.1; and from Sun, JVM version 1.3 and later)
Client operating systems
Client hardware platforms

in short, all the variations in client desktop enivornments on which an application might be run — so that developers don't have to do so themselves.

The Nexaweb Platform ensures that the applet gets loaded and runs in all these various runtime environments, so that developers can concentrate on writing Java classes or JavaScript functions to handle events and implement business logic. The application developer makes the design decision, based on the needs of their application, as to what version of Java will be required for their application users’ machines; the Nexaweb Platform handles dynamically downloading and executing that application logic on the user machines.

Installable, Browser-free Desktop Client

Some applications are more appropriately run offline. To accommodate these situations, Nexaweb offers the installable, browser-free desktop client. The desktop client replaces the combination of the browser and applet. For example, a client application that is running disconnected from the server for a long time doesn't require Web browsing features. The desktop client allows a Nexaweb-enabled application to start and run in a disconnected state, store information locally, and integrate with local desktop applications.

Application Event Routing

To provide Nexaweb client requests to a web application, the Nexaweb Server acts as an application event router. It routes requests to the corresponding web application instance using the Application Server’s (more precisely, the Servlet Container’s) RequestDispatcher. From the viewpoint of the web application, there is no difference between an HTTP request coming directly from a client-side web browser and a request forwarded by the Nexaweb Server.

For example, the Nexaweb server uses the Application Server’s Servlet Engine, Java Server Page (JSP) engine or EJB container to process the request. All Application Server infrastructure support such as security, HTTP session, database connectivity, messaging, and component management is available to Nexaweb-enabled applications in the same way as they are to native web applications.

Network Communications Management

The Nexaweb Server transparently maintains a reliable, persistent, bi-directional communications channel with the Nexaweb Client. This communications channel:

Operates through firewalls
Can use the standard port 80 employed by web browsers
Allows for real-time server-push and secure HTTP connections.

Nexaweb extends standard based Java web development architecture for rich enterprise internet applications. The Nexaweb programming model includes:

Using XML for the Nexaweb client user interface
Using Managed Client Objects for client-side programming: event processing, business logic, data processing, etc.
Using JSP/Servlet/Struts standard Java web technologies to serve XML UI or data to the client side

A Nexaweb-based application is developed as a standard J2EE application and supports the Servlet 2.3 or higher specification. The server-side of a Nexaweb application is a standard Java web application, except that the JSPs/Servlets generate XML instead of HTML. Nexaweb applications differ from traditional web applications in that web applications use HTML for the user interface description while the client side of a Nexaweb application use XML. All database, EJB, and business logic code remains the same. Converting a web application to a Nexaweb application involves replacing the HTML presentation layer only.

Nexaweb Client UI

XML provides the Nexaweb client a high level description of the user interface, reducing not only network traffic, but also giving the client flexibility for presentation. With XML UI, you can create all of the common elements found in modern graphical interfaces. It is powerful enough to enable non-developers to quickly create sophisticated interfaces. Elements include: input controls (textboxes, drop down lists), toolbars and menu bars, tabbed dialog boxes, trees and tables for hierarchical or tabular information, keyboard shortcuts and accelerators, full keyboard navigation, drag and drop support, context sensitive popup menus and tooltips.

The following shows an example of code that creates a simple window with two buttons:

<!--this is a simple Window with two buttons inside of it -->
<window title="Example" width="150" height="70" x="10" y="10">
  <button text="Button 1"/>
  <button text="Button 2"/>
</window>

Figure 1. Window Code Example

Nexaweb Client Business Logic

Nexaweb enables developers to write client side business logic using the standard Java programming language or JavaScript. Developers can use the powerful JDK APIs supported by the client Java Virtual Machine (JVM) and Nexaweb Client API for client side development. The Nexaweb Client API includes classes for:

Manipulating the user interface
Communicating with the server
XML parsing
DOM manipulation
Screen capturing
Client side business logic
Pblish/subscribe messaging, and more.

Nexaweb calls these object oriented business logic components Managed Client Objects (MCOs). Nexaweb takes care of the deployment, instantiation and life cycle management of MCOs.

MCOs enable an entirely new class of applications that combine the performance and functionality of locally installed software with the deployment advantages of normal web applications. Compared with today's popular client-side technology like Javascript, MCOs are object oriented, easier to maintain and manage, and can scale to large projects and large teams.