Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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.

 

...

  • 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.

...

Overview

Nexaweb は、エンタープライズ インターネット アプリケーションのビルドとデプロイに使用されるソフトウェア プラットフォームです。Nexaweb に対応したアプリケーションは、標準の J2EE Web アプリケーションです。Nexaweb で作成されたアプリケーションは、テクノロジやリソースなどの既存の資産を活用すると共に、デスクトップ アプリケーションの豊かな機能とインターネットの柔軟性を提供します。Nexaweb アプリケーションには、クライアント コンポーネントとサーバー コンポーネントが含まれています。次の表で、これらのコンポーネントの重要な特徴をいくつか示します。

Nexaweb のコンポーネント    特徴
クライアント
  • すべての主要オペレーティング システム上で動作するすべての 標準 Web ブラウザで実行されるため、インストールの必要がありません。
  • 従 来の Web アプリケーションでは、テーブルのソートや列の交換などを行う場合にページを更新する必要がありますが、Nexaweb は組み込みのユーザー インターフェイス機能を備えているため、多くの UI 操作をローカルで処理できます。さらに、カスタマイズしたコードをクライアントに転送して実行することもできます。そのため、クライアントサイド コードによって、情報を検証したり、サーバーへの往復を行わずに UI を更新することも可能です。
  • セッション中のアプリケーションの状態に関する情報が保持されるので、リクエストまたはレスポンスごとにクライアントの状態を完全に再構築する必要はありません。すべてのページを更新するのではなく、変更部分のみの小規模な差分更新で済みます。
  • 通 常 1 つのメッセージにつき数百バイトほどの短い圧縮メッセージを低い頻度で交換することにより、サーバーとの状態の同期化を行います。Nexaweb は、この機能をクライアントサイドの高度なインテリジェンスに統合することによって、サーバーの負荷とネットワーク帯域幅の使用量を大幅に軽減します。
  • Nexaweb の開発環境では、HTML のカスケーディング スタイル シートに類似した、XML ベースの UI スタイルシートを使用してアプリーションの外観と操作性を設定できます。これにより、ロジックやワークフローに関係なく、アプリケーションの外観を容易に 維持したり、更新することができます。
サーバー
  • J2EE アプリケーション サーバー内で実行されます。Nexaweb と Nexaweb に対応したアプリケーションは、従来の J2EE アプリケーションと同じ方法で開発およびデプロイされます。
  • HTTP リクエストをアプリケーションに送信して、クライアントサイドの状態情報をキャッシュし、ネットワーク通信サポートを透過的に提供します。

 


 

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. 

...

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>	

Image Removed

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.

...

通常、Web アプリケーションは WAR ファイル形式でデプロイされます。この場合、Nexaweb に対応したアプリケーションには、Apache Tomcat 4.x など、J2EE Java Servlet コンテナのバージョン 2.3 以降のみが必要です。また、Nexaweb に対応したアプリケーションは Java のサーブレット方式に対応しているため、フル機能を備えた J2EE アプリケーションサーバー (BEA WebLogic や IBM WebSphere など) にデプロイすることもできます。ただし、このような J2EE アプリケーションサーバーの追加機能は必要ありません (たとえば、Nexaweb に EJB プログラミングは不要です)。

Nexaweb に対応したアプリケーションを作成するには、アプリケーションの編集、コンパイル、ビルド、およびパッケージ化を行うために選択したツールを使用して、XML で UI を、Java でアプリケーションロジックを指定します。

Nexaweb に対応したアプリケーションの作成手順

注: 便宜上、開発サイクルに関する説明は非常に簡略化されています。ここでは、手順についての細かい説明を省略し、Nexaweb Platform で利用できる多くのオプションについては触れていません。以降のセクションでは、Nexaweb Platform アプリケーション開発の詳細や微妙な差異についてさらに掘り下げて説明します。
1. ユーザーインターフェイス (UI) の作成

Nexaweb に対応したアプリケーションでは、XML を使用して UI が定義されます。これを UI XML と呼びます。この UI XML ファイルは、Web アプリケーションのディレクトリ構造内にある、通常 HTML ファイルが置かれる標準的な場所に配置されます。

2. イベントハンドラの記述
 

他の Web アプリケーションと同様に、サーバーサイドのイベントハンドラはサーブレットや JSP として記述できます。
また、Nexaweb に対応したアプリケーションを開発する際に、次のイベントハンドラを記述することができます。
  • クライアントサイドの Java イベント ハンドラ。このイベント ハンドラは、Nexaweb Platform で MCO (Managed Client Object) と呼ばれており、要求に応じてサーバーからダウンロードされる Java クラスです。
  • XUpdate を使用して、UI を変更する XML ディレクティブを含むフラット ファイルを直接参照するイベント ハンドラ。これらのファイルはサーバー上に配置され、URL によって直接参照されます。
3. アプリケーションのNexawebify (Nexaweb 対応化)

Nexaweb では、Nexawebify ユーティリティとして Ant タスクが提供されています。ビルドの際にこのタスクを呼び出して、Nexaweb に対応したアプリケーションを作成します。このユーティリティは、Nexaweb Platform のすべてのコンポーネントとリソースをアプリケーションのデプロイ用ディレクトリ構造にコピーして、nexaweb-platform.zip ファイルをこのアプリケーションディレクトリにインテリジェントに解凍します。このインテリジェントな解凍機能により、適切な Nexaweb コンポーネントがアプリケーションの web.xml ファイルに結合されます。このユーティリティは、Nexaweb Studio で [Project]、[Add / Upgrade Nexaweb Support] を選択して実行することもできます。詳細については、Nexaweb Studio のマニュアルを参照してください。

4. アプリケーションの WAR ファイルへのパッケージ化

Web アプリケーションには、デプロイに使用する標準のディレクトリ構造があります。WEB-INF という特殊な標準サブディレクトリを除いて、このディレクトリ構造内にあるすべてのファイルとサブディレクトリは Web ブラウザで表示できます。

Java Servlet 仕様では、アプリケーションのデプロイメント記述子と呼ばれる登録ファイルが WEB-INF サブディレクトリに存在する必要があります。アプリケーションのデプロイメント記述子は web.xml という XML ファイルです。このファイルには、アプリケーション構成の各種設定や、サーブレットコンテナで使用されるアプリケーションのサーブレットおよび JSP の宣言が含まれています。
WEB-INF ディレクトリには、次の 2 つのサブディレクトリがあります。
  • classes - Java クラスを配置するディレクトリ
  • lib - .jar ファイルを配置するディレクトリ
また、アプリケーション固有のリソースを含むディレクトリがここに含まれる場合もあります。
通常の場合、この ディレクトリ構造全体を Web アーカイブまたは WAR ファイルとしてパッケージ化します。WAR ファイルは、.war というファイル拡張子を持つ zip アーカイブです。WAR ファイルをデプロイするには、アプリケーションを実行するコンテナで指定されている適切な手順に従います。Nexaweb Platform のコンポーネントは、Java Servlet コンテナのバージョン 2.3 以上で実行されます。

Nexaweb に対応したアプリケーションの実行時アーキテクチャ

こ こでは、Nexaweb に対応したアプリケーションの実行時アーキテクチャの概要を示します。使用されるコンポーネントの種類、それらのコンポーネントがクライアントまたはサー バーのどちらに配置され、どちらで実行されるか、さらにコンポーネント間の相互作用について説明します。以降のセクションでは、Nexaweb Platform の特徴をより概念的な観点から説明します。

クライアントサイド

Nexaweb に対応したアプリケーションをクライアントサイドにデプロイするには、2 つの方法があります。次のいずれかを使用してアプリケーションを実行できます。

  • ブラウザ内の Java アプレット
  • ユーザーのマシンにインストールされた、スタンドアロンの Java アプリケーション
実行時に、 Nexaweb クライアントエンジンはアプリケーションのプレゼンテーションの管理、つまり UI のレンダリングと UI イベントの管理を行います。また、Nexaweb に対応したアプリケーションの現在のバージョンが実行されるように、必要に応じてサーバーから最新バージョンをダウンロードします。

ユーザーインターフェイス (UI)


状態の定義

Nexaweb クライアントエンジンは、ユーザーインターフェイスの状態を定義するメモリ内の DOM (Document Object Model) を管理します。HTML ページに基づくモデルと異なり、Nexaweb Platform の UI ドキュメントはサーバーへのリクエスト全体にわたって維持されます。このモデルは、プログラムを使用して Java API から操作することも、UI XML マークアップ言語を使用して操作することもできます。
状態の変更
UI ドキュメントという特定の DOM に変更が加えられると、UI の状態は変化します。HTML の場合と異なり、この UI ドキュメントは検索可能で、すべての要素に固有の ID があるため、UI の差分更新が行われます。個別の UI 要素の状態は、他の UI 要素をすべて更新せずに変更することができます。Nexaweb クライアントエンジンは、UI ドキュメント内に含まれている現在の「命令」をエンドユーザーの画面にレンダリングします。この「命令」には、ボタン、ラベル、テーブル、グラフなどの UI ウィジェットを指定する要素が含まれています。たとえば、Nexaweb クライアントエンジンは、UI ドキュメント内でボタンタグ (<button … />) を検出すると、ボタンをレンダリングしてエンドユーザー
の画面に表示します。

UI ドキュメントへの変更は、次のいずれかの方法で行われます。
  • プログラミングを使用する場合 -
    開 発者独自の Java クラスを追加した Nexaweb Platform Java API を使用します。Nexaweb クライアント エンジンは、必要に応じて (オン デマンドで) クライアントサイドのイベント ハンドラを含むクラスをサーバーからダウンロードします。これらのクラスは UI XML で使用され、宣言されます。
     
  • 宣言的に行う場合 -
    XUpdate を使用します。XUpdate タグ (insert-before、insert-after、append、replace など) を使う XML ドキュメントで、別の XML ドキュメントを変更する方法を指定します。このような変更は差分的に行われます。たとえば、株価表示アプリケーションでは、1 つのフィールドの値だけを更新することができ、UI 定義全体を改めて指定する必要はありません。最初の起動ページ、フラット ファイルからアクセスする UI XML、JSP、イベント ハンドラを使用するサーブレットなど、Nexaweb クライアント エンジンがアクセスする UI XML ドキュメントはすべて、メモリ内の UI ドキュメントに対する変更命令です。

サーバーサイド

実 行時に Nexaweb Platform が必要とするサーバーサイドのインフラストラクチャは、バージョン 2.3 以上の Java Servlet コンテナだけです。このコンテナは、デプロイ済みの Nexaweb に対応したアプリケーションをホストします。Nexaweb Platform のサーバーサイドコンポーネントは、クラスタリング、フェイルオーバー、Web サービス、サーバーからクライアントへのリアルタイムプッシュをサポートしています。Nexaweb に対応したアプリケーションは標準の Web アプリケーションであるため、EJB (Enterprise Java Beans) や MDB (Message Driven Beans) など、J2EE アプリケーションサーバーの既存の機能が使用できます。

また、サーブレットや JSP がサーバーサイドの追加機能を提供している場合があります。既存の Web アプリケーションを Nexaweb Platform に移植すると、既存のサーブレットや JSP を再利用できる可能性があります。
Nexaweb Platform では、アプリケーションのデータがクライアントまたはサーバーで、あるいはその両方で維持されます。クライアントとサーバーの両方に保存されている XML ドキュメントのコピーを同期化することもできます。いずれかのコピーのデータに変更が加えられると、他方のコピーも自動的に更新されます。また、リスナを 登録して、このような変更を通知することも可能です。

通信フレームワーク


Nexaweb に対応したアプリケーションのすべての層は、Nexaweb Platform の最も独創的で強力な機能である IMB (Internet Messaging Bus) を使用して通信を行います。IMB により、Nexaweb に対応したアプリケーションは、Web アプリケーションでは通常利用できないメッセージング機能を使用することができます。たとえば、双方向メッセージング、クライアントへのデータのプッ シュ、publish および subscribe メッセージング、アプリケーション メッセージの正しい配信順を保証する機能などがすべて、信頼性の高いセキュアな方法で提供されます。
IMB は次の機能に対応しています。
  • クライアントとサーバー間の双方向通信
  • サーバー間通信 (たとえば、クラスタ化されたサーバーの場合)
  • クライアント間通信 (サーバー経由、ただしサーバーサイド コードの記述は不要)
IMB は、HTTP や HTTPS など、既存の標準的なインターネットテクノロジを使用して、既存のインフラストラクチャとの最大の互換性を保証します。
クライアントにデプロイする場合のオプション
Nexaweb に対応したアプリケーションをデプロイするには、次のいずれかの方法が使用できます。
  • ブラウザベースの小さな Java アプレット
  • ブラウザを使用しない、インストール可能なデスクトップ クライアント
ブラウザベースの Java アプレット
 
Nexaweb に対応したアプリケーションのデプロイで最もよく使用される方法は、ブラウザベースの小さな Java アプレットとしてデプロイすることです。ただし、アプレット専用のプログラミングを行う必要はありません。ブラウザベースのクライアントを使用すると、次 のようなメリットがあります。
  • アプレットのセキュリティ - Java アプレットは、保護されたサンドボックスを使用して実行されます。
  • デプロイの容易性 - ブラウザベースのクライアントの場合、クライアント マシンへのインストールが不要なため、サポートに関わる多くの問題を解消することができます。

Nexaweb Platform は、次の項目に対する互換性を保証します。
  • ブラウザ (Internet Explorer versions 4、5、5.5、および 6、Firefox、Safari、Mozilla、Netscape)
  • Java 仮想マシン (Microsoft の JVM バージョン 1.1、Sun の JVM バージョン 1.3 以降)
  • クライアントのオペレーティング システム
  • クライアントのハードウェア プラットフォーム
要するに、Nexaweb Platform は、アプリケーションを実行する可能性のある、あらゆるタイプのクライアントデスクトップ環境に対応しているため、開発者は互換性について心配する必要はありません。
Nexaweb Platform では、どのような実行時環境においても、アプレットが確実にロードされて実行されるので、開発者は、イベントを処理してビジネスロジックを実装するための Java クラスの記述に専念できるようになります。アプリケーションの開発者は、作成するアプリケーションの必要性に基づいて、Java のどのバージョンがユーザーのマシンに必要であるか、デザイン上の決定を行います。Nexaweb Platform では、そのアプリケーションロジックが動的にダウンロードされてユーザーのマシンで実行されます。
ブラウザを使用しない、インストール可能なデスクトップクライアント
アプリケーションの中には、オフラインで実行するのにより適したものもあります。このような状況に対応するため、Nexaweb は、ブラウザを使用せず、インストール可能なデスクトップクライアントを提供しています。こ のデスクトップクライアントは、ブラウザとアプレットの組み合わせに代わるものです。たとえば、長時間サーバーに接続しないで実行されるクライアントアプ リケーションに Web ブラウザの機能は必要ありません。このデスクトップクライアントを使用すると、接続しない状態で Nexaweb に対応したアプリケーションを起動および実行でき、情報をローカルに保存し、ローカルのデスクトップアプリケーションと統合することができます。

アプリケーションイベントのルーティング

Nexaweb クライアントのリクエストを Web アプリケーションに提供する場合に、Nexaweb Server はアプリケーションイベントのルーターとして動作します。アプリケーションサーバー (より正確にはサーブレットコンテナ) の RequestDispatcher を使用して、サーバーは対応する Web アプリケーションのインスタンスにリクエストを送信します。Web アプリケーションから見て、クライアントサイドの Web ブラウザから直接送信される HTTP リクエストと Nexaweb Server から転送されるリクエストの間に違いはありません。

たとえば、 Nexaweb サーバーは、アプリケーションサーバーのサーブレットエンジン、JSP (Java Server Page) エンジン、または EJB コンテナを使用してリクエストを処理します。標準的な Web アプリケーションと同様に、セキュリティ、HTTP セッション、データベース接続、メッセージング、コンポーネントの管理など、アプリケーションサーバーのインフラストラクチャに関するすべてのサポート機 能が Nexaweb に対応したアプリケーションでも利用できます。
ネットワーク通信の管理

Nexaweb Server は、信頼性の高い、永続的な双方向通信チャネルを Nexaweb Client に対して透過的に維持します。この通信チャネルには次のような特徴があります。

  • ファイアウォールを通して動作する
  • Web ブラウザで使用される標準ポート 80 が使用可能
  • リアルタイム サーバー プッシュとセキュリティ レベルの高い HTTP 接続が可能

Nexaweb アプリケーションの開発

Nexaweb は、豊かなエンタープライズインターネットアプリケーションを開発するために、標準に基づく Java の Web 開発アーキテクチャを拡張します。Nexaweb のプログラミングモデルには次のものがあります。
  • Nexaweb クライアント ユーザー インターフェイスに XML を使用
  • クライアントサイド プログラミングに MCO (Managed Client Object) を使用 (イベント処理、ビジネス ロジック、データ処理など)
  • XML UI またはクライアントサイドへのデータ提供に JSP、Java Servlet、Struts の標準 Java Web テクノロジを使用
Nexaweb ベースのアプリケーションは、標準の J2EE アプリケーションとして開発され、Java Servlet 2.3 以降の仕様に対応しています。サーバーサイドの Nexaweb アプリケーションは標準の Java Web アプリケーションです。ただし、JSP または Java Servlet が HTML ではなく、XML を生成する点が異なります。ユーザーインターフェイスの記述に HTML を使用する従来の Web アプリケーションと異なり、クライアントサイドの Nexaweb アプリケーションは XML を使用します。データベース、EJB、およびビジネスロジックコードについてはすべて同じです。Web アプリケーションを Nexaweb アプリケーションに変換すると、HTML プレゼンテーション層のみが置き換えられます。
 

Nexaweb クライアントの UI

Nexaweb クライアントで XML を使用すると、ユーザーインターフェイスの記述を高水準なものにすることができます。これにより、ネットワークトラフィックが軽減されるだけでなく、プレ ゼンテーションで高い柔軟性が得られます。XML UI では、今日のグラフィカルインターフェイスに見られる共通の要素をすべて作成できます。また、XML UI の強力な機能により、開発者以外のユーザーも高度なインターフェイスをすばやく作成することができます。ユーザーインターフェイスの要素には、入力コント ロール (テキストボックス、ドロップダウンリスト)、ツールバーとメニューバー、タブ付きダイアログボックス、階層または表形式の情報を表示するツリーとテーブ ル、キーボードショートカットとアクセラレータ、フル機能のキーボードナビゲーション、ドラッグ&ドロップのサポート、コンテキストポップアップメニューとツールチップなどがあります。
次に、2 つのボタンを備えた、シンプルなウィンドウを作成するコードの例を示します。
 
 
<!-- これは、2 つのボタンを含むシンプルなウィンドウです。-->
<window title="Example" width="150" height="70" x="10" y="10">
        <button text="Button 1"/>
        <button text="Button 2"/>
</window>

図 1: ウィンドウを作成するコードの例

Nexaweb クライアントのビジネスロジック

Nexaweb では、開発者は標準の Java プログラミング言語を使用して、クライアントサイドのビジネスロジックを記述することができます。開発者は、クライアントサイドの開発に、クライアントの JVM (Java Virtual Machine) に対応する強力な JDK API と Nexaweb Client API を使用できます。Nexaweb Client API には、次の機能を提供するクラスが含まれています。
  • ユーザー インターフェイスの操作
  • サーバーとの通信
  • XML の解析
  • DOM の操作
  • 画面のキャプチャ
  • クライアントサイドのビジネス ロジック
  • publish/subscribe メッセージングなど
Nexaweb では、これらのオブジェクト指向のビジネスロジックコンポーネントを MCO (Managed Client Object) と呼びます。Nexaweb は MCO のデプロイ、インスタンス化、およびライフサイクル管理を行います。
MCO の使用により、ローカルにインストールされているソフトウェアのパフォーマンスと機能に加え、通常の Web アプリケーションのデプロイに関するメリットを備えた、まったく新しいレベルのアプリケーションの開発が可能になります。JavaScript などの現在広く使用されているクライアントサイドテクノロジと比べ、オブジェクト指向の MCO は維持管理が容易で、大規模なプロジェクトやチームの規模に合わせて拡張することができます。