ZK製品概要

Executive Summary

ウェブがわれわれの日常生活に浸透しつつある中、伝統的なページをベースにしたウェブアプリケーションは、アプ リケーションの複雑さを視覚的に表現できないという本質的な問題に直面しています。その結果、ユーザが不愉快な経験をしたことと、膨大なコストの二つの大 きな問題が発生しました。

10年の発展を終え、ウェブアプリケーションは静的なHTMLページから動的なページへ、さらにアプレットとフラッシュへ、そして、最終的にはAjax技術へと進化してきました。Ajaxはウェブの”reach”という遍在する特性と、デスクトップの”rich”という使いやすさを結びつけ、ウェブアプリケーションに新たな生命を吹き込みました。GoogleマップやNetflexsは最も知られているその例です。

しかし、AjaxでリッチなUIを盛り込むことは、元々コスト高のウェブ開 発に、さらに費用やリスクを増やすに違いありません。ま た、Ajaxを使用するのにJavaScriptや非同期プログラミングの技術は必要です。 数多くのクライアントにビジネスロジックを適用し、メンテナンスするのも手間がかかります。

この問題を解決するため、Potixは”リッチUI”と”低コストの開発費用”を兼ね備えるウェブアプリケーションのでき るツールを開発しました。コアソリューションZKは、Ajaxをベースにしたイベント駆動型エンジンで対話機能を自動的に実現してくれます。また、豊富なXUL・XHTMLコンポーネンツはツールの便利さを実感させます。さらに、UIのデザインはマークアップ言語を使用するため、プログラミングの必要がなくなりました。

ZKを使えば、アプリケーションを豊かで特徴的なXUL・XHTMLコンポーネンツで表現することができます。また、デスクトップアプリケーションと同様に、ユーザー側の操作が行 われた場合、その操作はイベントトリガーの形で通知されます。すべてのアプリケーションコードはサーバー側で実行され、ユーザー側の情報の更新はサー バー・クライアント間の同期を通してZKより行います。

ZKはデスクトップアプリケーションを作成する簡素さでデスクトップアプリケーションの対話と応答性を 実現できます。また、 ウェブデザイナーはマークアップ言語ですばらしいユーザーインターフェースを作成できます。プログラミングはいりません。HTMLページを編集する程度のレベルで実 現できます。

ZKで作成したアプリケーションは広く使用できます。スタンダードバージョンでし たら、HTMLとJavaScriptに対応できるブラウザならどれでも使 用できます。また、ZKモバイルは、J2MEに対応できるPDA、携帯、ゲームコンソールなどが使 えます。さらに、今開発したZKアプリケーションはほぼそのまま^[1]モ バイルのプラットフォームにても使えます。

ZKの可能性を最大化にし、 ベンダーロックインの心配を最小化にするため、PotixはGPL^[2]の形でZKのソースコードを開示し ます。世界中の使用者が検証し、認定します。コードにご自分が開発したものを自由に盛り込めるし、他のベンダーのものを統合することもできます。

はじめに

ウェブが普 及してきた今日では、ウェ ブアプリケーションを通してコミュニケートする効率の向上と、複雑のアプリケーションを簡単に開発できることは重要になってきました。

この試練を乗り越えるため、Potix社は”リッチなUI”と”簡単なプログラミングモデル”を兼ね備える技術やツール を開発しました。

従来のウェブアプリケーション

ウェブが職場・家庭・日常生活に入ってきたことで、ウェブがアプリケーションを開発する際欠かせない土 台になっただけではなく、ウェブの普及はIT産業を推進する力にもなりました。海外との業務連絡・オンラインショッピング・写真などファイルの共 有・仕事関係・コンシューマ・テクノロジー・文化はすべてウェブに関わっています。IDC^[3] によれば、EIP、B2B＆B2C アプリケーション、E-コマース市場のそれぞれ2006 年のCAGR は41.2％、20％、57.2％に成長する見込みです。

ウェブアプリケーションの普及に伴い、従来のウェブアプリケーションは、アプリケーションの複雑さを視覚的に 表現できないという本質的な問題に直面しています。それはページをベースにした構造とステートレスモデルによる問題です。

このモデルでは、ペー ジは独立したものであり、クライアントとサーバーの間の最小のコミュニケーション単位でもあります。デザインがシンプルで情報交換をしやすいものの、近代的なアプリケーションを開発するにはとても複雑で 厄介です。

たとえば、ユーザーに見積もりを見せるた め、他のページを開いて自分の取引の記録探す、または最近の値段のページを開く、ある いは現在の株価のページを開かなければなりません。ユーザーは現在作業しているページをそのままにし、いくつものページ間を移動しなければなりません。 ユーザーはページ間で簡単に迷子になるし、混乱します。結果として、ユーザーは機嫌を損ね、売り上げが落ち、生産力も下がります。

このモデルではサーバー上で作動しているアプリケーションは全てを見なければいけません。リクエストに 応えること、返答を送付すること、ユーザーをページと他のページに結び付ける過程を順番付けること、エラーを処理することなどです。そこでStruct・Tapestry・JSF など多数のフレームワークが進化過程を簡単にするため開発されました。ページ方式と近代のアプリケー ションとの大きな差によって、これらの構造は理解しにくいし、使うことは楽しいものではなく、簡単でも直感的なものでもありませんでした。

Ad-hoc Ajax アプリケーション

進化期間を終え、ウェブアプリケーションは 静的なHTML のページから動的なHTML へと、さらにアプレットとフラッシュへと、そして、最後にはAjax^[4] 技術(非同期、Java スクリプトとXML)まで至りました。Google マップ とSuggest によって示されているように、Ajax は対話と返答機能を提供することにより、新 しい生命をウェブアプリケーションに吹き込みました。アプレットやFlash とは違ってAjax は標準的なブラウザとJavaScript を基盤としており、Ajax だけのプラグインは必要ありません。

Ajax はDHTML のような新しい世代です。というのはDHTML のように、JavaScript に深く依存しています。ユーザーの操作に よって行われるイベントを監視し、ブラウザの中で動的にページ(aka.DOM)の視覚表現をうまく処理します。ページをそ のままにしたり、再び送付したりすることなく、非同期でサーバーとのやり取りするを可能にすることで、更に進化をさせます。クライアントとサーバーの間の 簡単なやり取りでページ方式を変えています。適切なデザインで、Ajax はデスクトップアプリケーションのように豊 富な内容をウェブウェブアプリケーションに提供し、全ての内容はアプリケーションのコントロールの下、動的に更新されます。

試練

Ajaxでユーザーが期待する対話機能を達成するのは元々コスト高のウェブアプリ ケーション開発にさらに開発費用を増やします。

1. 複雑で互換性のないJavaScript　API

ブラウザ側でDOMを処理し、サーバーと同期することで複雑なコンポーネントを実現させることは決して簡単ではありませ ん。不完全でバグだらけDOM　APIはよく見られるし、異なるブラウザおよび異なるバージョンによる互換性がない問題は開発する期間を伸び かせ、開発者に挫折感をさせてしまいます。

2. ブラウザ側でアプリケーションデータモデルとビジネスロジックを適用

Ajaxは、主にクライアント・サーバー間のデータ交換に使うか、ビジュアルを表現します。交換は全てアプリ ケーションがします。Ajaxは、クライアント・サーバーモデルと同様に、ビジネスロジックをクライアント側に適用することでクライ アント・サーバー間の通信を省き、パフォーマンスを向上させますが、開発やメンテナンスのコストは膨大になります。

3. クライアント・サーバー間の同期

Ajaxクライアントは非同期の形でサーバーと通信 します。サーバーから見れば、Ajaxクライントのリクエストは普通のHTTPリクエストとは同様で、平行に処理されてい ます。そのため、順番問題が発生し、アプリケーションの開発者は順番に注意して処理しなければなりません。たとえば、使用者は製品番号を入力したら、Ajaxリクエストは自動的に送信され、サーバー側に価格の情報 を要求します。しかし、価格の情報が帰ってくる前に、使用者が「送信」ボタンを押すと、アプリケーションは混乱してしまいます。

現時点での解決方法

コントロール可能なAjaxソリューションを提供するため、たくさんのフレームワークやライブラリーが開発されました。大きく分け て三種類あります：

1. JavaScriptコンポーネンツとライブラリー

一番ストレートな方法^[5]は、既製のJavaScriptコンポーネンツを提供します。そうすることで、開発者は複雑なユーザーインターフェースを処理しなくて 済みます。しかし、開発者はJavaScriptでこれらのコンポーネンツを加工し、自分でクライアント・サーバー間の動的なデータ交換を処理しな ければなりません。一部のソリューションで異なるブラウザ間でも使えるライブラリーを提供できるのがこの方法のメリットです。

2. 特別なタグでHTMLを拡張する

もう一つの方法は、JavaScriptを使わず、HTMLで独自仕様のタグを提供^[6]し ます。JavaScriptで作られた特別のエンジンはブラウザ側で実行され、そのエンジンはHTMLのコンテント(特別なタグ)を翻訳し、処理します。確かにJavaScriptは使いませんが、動的にクライアント・サーバー間情報の交換は必要となります。

他の宣言式のプログラミングと同様に、この タグはプログラマーでなくても簡単に習得できます。しかし、条件付きのループなど複雑なロジックの場合はとても厄介かもしれません。ブラウザ側のエンジン に頼っているので、複数のクライアント・サーバー間の往復でページを更新するのも問題になります。

3. Ajaxで既存のフレームワーク機能を高める

三番目の方法もよく使われています：既存のフレームワーク^[7]にてAjaxを適用します。この方法を使用したら、結果は既存のフレームワークの構造によって変わります。ほとんど の場合は、JavaScriptを使わなくても結構ですが、動的なデータを交換するためのサーブレットを開発しなければなりません。

しかし、確認した結果、それらの解決案は、すべてひとつの問題、つまりJavaScript の使いにくいという問題しか解決していませ ん。サーバー・クライアント間の非同期の通信は、依然として、アプリケーション開発者が自分で処理しなければなりません。

ZK: Simple and Rich

Ajaxはテクノロジーより、構造だと、Potixは思います。

1994年、zAppとOWLを手本としインフラを構築しました。 それはウインドウズ用の会計システムでした。 そして、2000年、　StructとWebWorksの成功例を見てJ2EE用の会計システムを開発しました。 この二つの経験からウェブアプリケーションが高い技術や条件が必要であることを痛感しました。また、開発コストもクライアント・サーバ方式と比べ、４倍も 掛かります。最も厳しいのはCSSや画像を使用したにもかかわらず、ユーザーインターフェースの使いにくさは60年代科学用のコンピューター画面を彷彿さ せました。

そこでわれわれは考えました。それはウェブ ア プリケーションの本質的な問題なのか、それともプログラミングモデルが不適切だったからなのか。90年代デスクトップアプリケーションの成功を 振り返って みると、イベント駆動型コンポーネンツをベースにしたモデルが成功の鍵を握っていました。簡単に使用・開発できるというメリットで、このモデルは対話性を 実現する最も適当な方法でした。果たしてこの方法はウェブアプリケーションにも適用できるのでしょうか？

この問題を解決するため、Potix は”リッチUI”と”低コストの開発費用”を兼ね 備えるウェブアプリケーションのできるツー ルを開発しました。コアソリューションZK は、Ajax をベースにしたイベント駆動型エンジンで対話機能を自 動的に実現してくれます。また、豊富なXUL・XHTML コンポーネンツはツールの便利さを実感させ ます。さらに、UI のデザインはマークアップ言語を使用するた め、プログラミングの必要がなくなりました。

ZK を使えば、アプリケーションを豊かで特徴的 なXUL^[8] ・XHTML コンポーネンツで表現することができます。また、デスクトップアプリケーションと同様にユー ザー側の操作が行われた場合、その操作はイベントトリガーの形で通知されます。ウェブデザイナーはZUML^[9]というマークアップ言語ですばらしいユーザーインターフェースを開発できます。プログラミングは不要で、HTMLを編集する程度のレベルで作成できます。

60年代のような不便なコンピューター画面や、 不愉快な使用者経験はもはや存在しません。JavaScriptによる発生した問題もなくなります。非同期の問題も 消えました。クライアント側でのビジネスロジックの適用も必要ありません。

シームレスな進化

Ajaxにより実現されたリッチなユーザーインターフェースと人々がウェブとの対話方式を変えつつある中、今まで力を入れ ていた既存のウェブアプリケーションをいかに有効に利用するのかが重要な課題になりました。既存のアプリケーションと同時に存在するため、ZKはプレゼンテーション層ソリューションとして作られました。ロジック層やデータ層はそのままです。さらに、全て のコードはサーバー側で実行され、RMI・RPC・ウェブサービスを使用する必要はまったくありません(使用しても結構 ですが)。JDBC・Hibernate・Javaメール・JMS等のミドル ウェアは今まで通り動きます。

ZKはポータル・JSP・ダッシュボードなどの技術と共存できます。ZUMLページを入れれば高度な対話をす ぐ実現できます。ZUMLページは全 てのサーブレットや他のZUMLページを含 むことができます。開発者はアプリケーションと使用者との対話の速度や順序付けの効率向上について完全にコントロールできます。

JSPをそのまま使ってHTMLを生成する場合、ZKフィルタを使用してZUMLタグを追加すると便利です。こうすることで、フィルタは動的に生成されたページを静的なZUMLページに変換します。

構造について

PotixのコアソリューションはZKです。ZKはAjax方式の構造を用いて対話を自動化し、XUL方式のコンポーネントのセットにより使い勝手を良くし、マークアップ言語を使用することで開発を簡単化してい ます。

Ajaxをベースに

Ajax方式は下にかいてあるように三つの構造から なっています。ZKローダー、ZK AUエンジン、ZKクライアントエンジン。ZKローダー はZUML ページ^[10] を読み込み、HTMLページに変換し、URLのリクエストに応答します。

ZKクライアントエンジンとAUエンジンはピッチャーとキャッチャーのよう な関係です。クライアントエンジンはブラウザ側で実行されますが、AUエンジンはサーバ側で実行されます。ブラウ ザ側で発生したイベントをサーバー側にあるアプリケーションに送信し、そしてアプリケーションの処理によりブラウザ側のDOMツリーを更新します。

• クライアントエンジンはブラウザ側にあり、 ユーザーの操作(マウスの移動や値の変更)を検知します。操作を検知したらAUエンジンに送信します。

• クライアントエンジンからのリクエストが届 いたら、AUエンジンは関連するコンポーネントを更新します。次に、AUエンジンはイベントハンドルでアプリケーションに通知します。

• アプリケーションがコンポーネントの内容を 変更したり、移動させたり、付け足したりしたら、AUエンジンは変更されたコンポーネントの新しい内容をクライアントエンジンに送ります。クライアントエンジンはそ れに基づいてDOMツリーを更新します。

シンプルなスレッドモデル

Ajaxリクエストは前のリクエストが処理される前 に送信される可能性があります。つまり、ad-hoc　Ajaxアプリケーションには同期の問題がありま す。ZKの場合では、リクエストやイベントはページ 別で独立の待ち行列に入れられ、順番に処理されます。ZKは他のページのAjaxリクエストを同時に処理し、パフォーマンス を最大化にします。

そのメリットは、開発者はスレッドや同期等 問題を心配する必要はなくなります。もちろん開発者はスレッドを使用しても構いません。よく使われるのは、一つのスレッドでロングオペレーションを実行す ると同時にもう一つのスレッドでプログレスバーとキャンセルボタンを表示します。

一旦停止・再開・モーダルダイアログ

リクエストを処理する際、条件を満たすまで 一旦停止することがよくあります。たとえばウィンドウをポップアップし、ユーザーの確認を待ちます。しかし、リクエスト－レスポンスという方式の制限によりこれは ウェブアプリケーションではとても難しいことです。

ZKのイベント駆動型モデルを使えば、開発者はいつでもイベントハンドルを一旦停止させたり、再開させたりします。モーダルダイア ログはこの特徴を使用する一つの例です。

ネットワークトラフィック及び通信時間の短縮

複数のイベントが同じネットワークパケット で送信されるため、クライアント側のイベントは必要とされる前に待ち行列に入れられます。さらに、同じ値を二回変更するような重複したイベントは省略されま す。

XULをベースにしたコンポーネンツ

独自仕様のコンポーネントを作成するのではなく、ZKは豊かなXULをベースにしたコンポーネントを提供します。XUL（XMLユーザーインターフェース言語）は、Mozillaファイヤフォックスやサンダーバード等デスクトップアプリケーションに対応するため作られたユーザーインター フェースのマークアップ言語です。他のXULアプリケーションとは違って、ZKはインターネットでのパフォーマンスを考えて作成された ものです。

バラエティーに富んだコンポーネンツ

メニュー・タブボックス・リストボックス・ ツリー・スライダ・グループボックス・グリッド・データボックスなどなど70以上のコンポーネンツを提供しています。

コンポーネンツのガーベージコレクター

コンポーネンツの生命周期は自動的に決めら れます。コンポーネントはページに添付されたら、ビジュアル的にブラウザで表示され、ページから削除されたらブラウザからも消えます。また、コンポーネン トが使われなくなったら、ゴミコレクターはそれのメモリーを自動的に開放します。ZKコンポーネンツを取り扱う方法は他のJavaオブジェクトと同様です。

ZK ユーザーインターフェースマークアップ言語(ZUML)

ZUMLはXMLをベースにしたマークアップ言語であり、 ユーザーインターフェースの表現を表します。開発者はZUMLページにてXUL・XHTML等多種類のタグセットを同時に使用すること ができます。

柔軟なユーザーインターフェース記述

最も簡単な方法ZUMLでユーザーインターフェースを一つのファイ ルに記述します。そのファイルを適当な場所にコピーしたら、ユーザーは対応するURLでユーザーインターフェースにアクセスする ことができます。

そのファイルはZUMLページと呼ばれ、ユーザーがリクエストを出 したら翻訳されます。ファイルが修正された場合は自動的に再翻訳されます。

それぞれのZKコンポーネントはJavaクラスのインスタンスです。Swingのように、Javaコードで直接処理することができます。

もう一つの例です：他のZUMLページからコンポーネントを生成します。

ZUMLページを動的に作り出されることもあります。

適当な編集ツールがあれば、ユーザーは ページのビューを変更することができます。

Javaでパワフルなスクリプトを作成

BeanShellをうまく使えばJavaコードをZUMLページに埋め込み、初期化やイベントを処理 させることができます。JavaコードやEL表記でコンポーネントにアクセスする場合、 指定したIDを使用すると便利です。

EL 表記

JSPと同様に、ZUMLのページにてEL表記を使用することが可能です。ELはエレガントでどなたでも簡単に習得できます。

プロトタイピングとMVC

JavaコードをZUMLページに埋め込む理由は、大抵、プロトタイ ピングかカスタマイズ化を加速するためです。リリースする際には、MVC（モデル、ビュー、コントローラー）を使用 すると良いでしょう。以下のuse属性を使って、コンポーネントをクラスに連 結させることができます。そうすることで、そのクラスは子コンポーネンツを管理するコントローラーになります。

イベントハンドル

イベントを検知し処理するにはそのイベント 専用の属性（例：onClick）を宣言し、そのイベントが検知されたら実 行するメソッドを定義します。さらに、イベントハンドルは動的に追加や削除ができます。

ライブデータとデータ・ビューの分離

リストボックスなど一部のコンポーネンツは ライブデータをサポートします。まず、アプリケーション別の翻訳者によりビジュアルとデータを分けます。次に、ユーザーが画面をスクロールし、見える状態 になったら、翻訳者は自動的に且つ動的に取得し翻訳します。この方法によって、データ量が多い場合表示する効率があがります。

HTMLを使用

今日のウェブアプリケーションは複数の技術 の集合ともいえます。例えばポータル・JSP・JSFの集合です。そのため、ZUMLページは他のウェブ技術とうまく連携できる ように設計されています。

まず、どのHTMLページやポートレットは何ページものZUMLをも含む ことができます。

さらに、ZUMLは何ページものサーブレット(JSPやZUMLページ）でをも含むことができます。

HTMLタグをZUMLページに直接埋め込むのに、XMLネームスペースでHTMLタグとXULタグを分けなければなりません。

なお、HTMLタグとXULタグが同時に存在しない場合、ZUMLは簡単な方法を提供します。

特徴＆メリット