連載 Magic V10リッチクライアント

第2回 リッチクライアントとは何か（その2）

前号では、ブラウザの独自拡張を利用したJavaアプレットの実行例と、Javaネイティブアプリケーションとして動作するアプレットの実行例をそれぞれ見てきました。また、アプレットと呼べど、これらの実行画面が限りなくWindowsネイティブアプリケーションに近い様相を呈していることも確認できました。

しかしながら、実はこれから私たちが携わろうとしているMagicリッチクライアントの世界は、これらより更に一歩進んで、Javaの最新テクノロジーとともに開発者とエンドユーザの両者に最小のエネルギーで最大の効果を発揮しうるアプリケーションの開発・実行環境を提供しようとするものなのです。

丹田 昌信　（プロフィール）

Javaアプリケーションを実行するには、パソコンにサン・マイクロシステムズ社のJava（JRE）がインストールされていることが前提条件になります。これはWebブラウザのオプション設定などにあるJavaプラグインの設定とは異なり、Windowsのコントロールパネルに登録されるJRE（Java実行環境）本体の実装を意味します。

JRE（Java実行環境）の実装確認

JREがインストールされているかどうかは、Windowsのコントロールパネルを開いて、Javaのアイコンが登録されているかどうかで確認できます。画面1はJava 1.5のアイコンの例です。

画面 1　Javaコントロールパネルの確認

このアイコンがJavaの「コントロールパネル」であり、Java実行環境の制御をここで行うことができるようになっています。

JREがインストールされていない場合はこのコントロールパネルは存在しませんが、JRE自体は必要に応じてインターネットから任意にダウンロードしたり、自動でインストールされるようになっていたりします（画面2）。

画面 2　JREのインストール画面

インストールされているJavaのバージョンを確認するにはJavaのアイコンをダブルクリックしてJavaコントロールパネルを開き、「基本」タブにある「バージョン情報」ボタンを押します（画面3）。

画面 3　Javaのバージョン情報の確認

大方の皆さんのパソコンにはJava 1.5のマイナーアップデート版がインストールされているかと思いますが、MagicリッチクライアントはJava 1.5でもJava 1.6でもどちらでも動作します。ちなみに、この原稿を書いている時点での最新バージョンはJava 1.6のUpdate 3となっています。

さて、冒頭で述べたJavaの最新テクノロジーというのは、すでにお気付きの方もいらっしゃるかと思いますが、「Java Web Start」という、新しい形のアプリケーション実装テクノロジーのことを表しています。従来のJavaアプレット方式との違いは、Javaのコントロールパネルを開き、キャッシュがどのような形式で保存されているかを見ることでも確認することができます（画面4）。

画面 4　Java一時ファイル（キャッシュ）の設定確認

アプレットとして保存されていれば「アプレットの表示」に登録され、アプリケーションとして保存されていれば「アプリケーションの表示」に登録されます。ちなみに、前号で見た2つのアプレットは「アプレットの表示」ボタンを押すことで、そのキャッシュの一覧を見ることができます（画面5）。

画面 5　Javaアプレットのキャッシュ一覧

「アプリケーションの表示」には、Java Web Start方式で起動されるJavaアプリケーションが登録されます。Magicで作成するリッチクライアントのアプリケーションは、このカテゴリーに登録されることになります（画面6）。

画面 6　Javaアプリケーションとして登録されたMagicリッチクライアント

なお、ここで管理されるアプリケーションは、このテーブルからも直接、アプリケーションを実行したり、アプリケーションの削除を行ったりすることができます。デスクトップやWindowsスタートメニューへの登録や削除も行うことができます。

また、ここにキャッシュされたアプリケーションはWindowsコントロールパネルの「プログラムの追加と削除」欄にも正式に登録され、エンドユーザによって任意に削除することも可能となります（画面7）。

画面 7　プログラムの追加と削除でもコントロール可能

ちなみに、画面4の表示はJava 1.6 ではパネル構成が再編されており、「アプリケーション」と「リソース」というカテゴリーで分類されるようになっています。「アプレット」という表現はもはや用いられていないようです（画面8）。

画面 8　Java 1.6のキャッシュビューア

察するに、もはや巨大化するアプレットはアプレットと呼ぶには相応しくないという判断なのかもしれません。

なお、Java 1.6ではこのキャッシュビューアからプルダウンメニューが無くなり、アイコン表示のボタンでアプリケーションの実行やショートカットの作成が行えるようになっています（画面9）。

画面 9　Java 1.6のキャッシュビューアからMagicアプリケーションを実行

さて、JREの実装が確認できましたら、次に、Magicリッチクライアントを起動させるためのJava Web Startの仕組みについて調べてみたいと思います。

Java Web Startの起こり

Java Web Startという用語をGoogleで検索すると、2001年頃にJava のバージョン1.4から組み込まれた技術であることが分かります。

サン・マイクロシステムズ社がこのテクノロジーを開発した動機は、アプリケーションをデスクトップ環境からでもインターネット環境からでも、どちらからでも起動できるようにしたいという願望にあったようです。

つまり、アプリケーションの起動をWindowsのスタートメニューやデスクトップ上のアイコンから行うか、あるいはWebブラウザ上のハイパーリンクから行うかを気にしなくても良いようにしたいという発想です。

このような環境が実現されれば、従来のようにデスクトップ環境にアプリケーションを明示的にインストールしなくとも、Webブラウザ上でハイパーリンクをクリックするか、あるいはBATファイルのようなアイコンをダブルクリックするだけでアプリケーションが起動できるようになるわけです。

このBATファイルのような役割を担うのが、JavaのJNLP（Java Networking Language Protocol）というファイルになります。このファイルの中身はXML形式になっており、Magicが生成するJNLPファイルをテキストエディタで覗くと、従来のWebアプリケーションと同じ書式でMagicサーバ上のタスクをコールしていることが分かります（画面10）。

画面 10　JNLPファイルからタスクをコール

つまり、このJNLPファイルをWebページ上にハイパーリンクとして配置するか、あるいはデスクトップ環境にショートカットとして登録しておくだけで、ここからMagicのタスクを起動することができるわけです。ショートカットからの起動なら、Webブラウザも不要となります。

起動の経路は、JNLPファイル→Webサーバ→Magicインターネット・リクエスタ→Magicリクエスタ・ブローカ→Magicアプリケーション・サーバという、従来のWebアプリケーションとほぼ同一の経路になります。

また、コールされたタスクは画面6や画面8のJREキャッシュに残りますので、次回からは短時間で起動されるようになります。アプリケーションの更新確認とアップデートも自動で制御されます。

Java Web Startがもたらすメリット

では、Java Web StartのテクノロジーがMagic eDeveloperに適用されると一体何がどう変わるのでしょうか。読者の中には、従来のブラウザ・クライアントやマージ型Webアプリケーションと、結局は同じ理屈ではないかと思われている方もいらっしゃるかもしれません。

実は、Magicリッチクライアントの開発・実行環境が従来のWebアプリケーションの概念と根本的に異なるのは、プログラムの開発手順とプログラムの実行画面の両方が、これまでのオンラインタスクと同じような作法で実現できるようになったという点にあるのです。

つまり、プログラムリポジトリからAPG一発で作成したタスク（画面11）であっても、あるいはサブフォームを使用した階層構造の複雑なプログラムであっても、地球の裏側からでもオンラインタスクと同様なイメージでアプリケーションを実行できることです（画面12）。これがMagicのリッチクライアントです。

画面 11　APGでリッチクライアント・タスクを作成

画面 12　リッチクライアント・タスクの実行

これらのメリットをあらためて具体的に列挙すると、次のようになります。

1. Magic実行版のインストールが要らなくなります。Magic実行版の代わりを成すのが、JRE（Java実行環境）とWebサーバ、Magicインターネット・リクエスタ、Magicリクエスタブローカ（MRB）、およびMagicアプリケーションサーバです。これらの環境は、これまでのブラウザ・クライアントやWebアプリケーションの動作環境とほぼ同じです。Webアプリケーションのノーハウがそのまま活かせます。
2. Magicアプリケーション（MCF、ECF等）のインストールが要らなくなります。個々のタスクは必要に応じて、XML形式でWebサーバからJREに渡されます。JREでは受け取ったタスクをJavaネイティブアプリケーションに変換して実行します。エンドユーザから見ると、このタスクがどこからロードされて、どこで実行されているのかを意識する必要はありません。また、純粋なJavaアプリケーションの形で実行されますので、従来のWebアプリケーションやブラウザ・タスクのようにWebブラウザの動作仕様に依存することもありません。
3. データテーブル（データソース）はMagicアプリケーションサーバ側で管理されますので、従来のクライアントサーバ同等の一元管理が可能です。データソースへのアクセスはWebアプリケーションのようなバッチアクセスのみならず、オンラインタスク同等のリアルタイムアクセスが可能です。これは、Magic独自の遅延トランザクション機能を用いて処理されます。遅延トランザクションですから、データの編集中にセッション障害等が発生してもデータソースは正常にロールバックして整合性が保たれます。
4. Magic実行版やMagicアプリケーションの保守作業を、クライアント毎に行う必要がなくなります。アプリケーションサーバ側で更新されたプログラムは、Magicの実行エンジンであるかユーザアプリケーションであるかにかかわらず、JRE側のキャッシュと常に比較され、必要に応じて自動的にダウンロード・更新されます。JRE自身もアップデートは自動ですので、クライアント側の保守の手間が大幅に省けます。
5. WANアプリケーションを容易に構築することができます。ターミナルサービスの配備やSQLリモートアクセスのような運用が不要となります。また、これまでのWebアプリケーション構築の障壁となりやすかったHTMLやCSSの知識、JavaScriptの知識も不要となります。

これらがMagicリッチクライアント導入の主なメリットになりますが、何といってもクライアント側の導入・保守が不要になるというメリットは、数多くのパソコンを抱えた企業やWANアプリケーションを必要としているユーザ、あるいはBtoCのサービスをネイティブアプリケーションでと考えている開発者にとっても、このうえない朗報となるはずです。

（以上、2007年11月15日号）