構造概要

プレフィックス

10年間の発展を終え、ウェブアプリケーションは静的なHTMLページから動的なページへ、さらにアプレットとフラッシュへ、そして、最終的にはAjax技術へと進化してきました。

Ajaxの試練

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

• 複雑で互換性のないJavaScript　API・ブラウザの違いによる問題
• ビジネスロジックをクライアント側で適用、メンテナンスが手間がかかる
• ビジネスロジック、ビジネスデータの情報漏洩
• サーバー・クライアント間の同期問題

現時点での対策方法

上記の問題を解決するため、たくさんのフレームワークやライブラリーが開発されました。その中、一番ストレートな方法は、既製のJavaScriptコンポーネンツを提供することです。そうすることで、開発者は複雑なユーザーインターフェースを処理しなくて済みます。しかし、開発者はJavaScriptでこれらのコンポーネンツを加工し、自分でクライアント・サーバー間の動的なデータ交換を処理しなければなりません。

つまり、それらの解決案は、JavaScriptが使いにくいという問題しか解決していません。サーバー・クライアント間の非同期通信などの問題は、依然として、アプリケーション開発者が自分で処理しなければなりません。そのため、従来のウェブアプリケーションモデルはそもそも適切でない？と疑問を持ち始めました。

ZKの構造

それらの試練を乗り越えるため、ZKは直観的なデスクトップモデルをウェブアプリの世界に導入しました：イベント駆動型、コンポーネントをベースに、そしてサーバー中心の構造を採用します。さらに、ZKはマークアップ言語を提供し、プログラミングを簡単にして、アノテーション・データバイディングを提供して、データベースへのアクセスをシンプルにしました。

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

すべてのアプリケーションコードはサーバー側で実行されます。ユーザーの操作による発生したイベントは、ZKより、自動的にサーバー側にあるアプリへ送信されます。また、サーバー側にて変更したコンポーネンツは自動的にブラウザで反映されます。ブラウザではプレゼンテーションレアのものしか表示されません。データモデル・ビジネスロジックなどの情報は一切表示されませんので、セキュリティーの心配はありません。さらに、アプリケーションがサーバー側にあるため、データベースやWebサービスなどのバックエンドサービスへのアクセスは簡単になります。クライアント・サーバー間の非同期問題やセキュリティー問題を考えしなくて済みます。

Ajaxを使用する最もいい方法は自然に使うことです。

実行の流れ

• クライアントエンジンはブラウザ側にあり、ユーザーの操作(マウスの移動や値の変更)を検知します。操作を検知したらAUエンジンに送信します。
• クライアントエンジンからのリクエストが届いたら、AUエンジンは関連するコンポーネントを更新します。次に、AUエンジンはイベントハンドルでアプリケーションに通知します。
• アプリケーションがコンポーネントの内容を変更したり、移動させたり、付け足したりしたら、AUエンジンは変更されたコンポーネントの新しい内容をクライアントエンジンに送ります。クライアントエンジンはそれに基づいてDOMツリーを更新します。

補足：

• クライアント・サーバー間の通信データを最小にするため、リアルタイムでないイベントはまとめて送信されます。
• 視覚効果をよくする、パフォーマンスを向上させるため、ZKはJavaScriptをクライアント側で実行させるオプションメカニズム（Client Side Action）を提供します。