［タイプ2］プラグイン＋サーバー型の製品は，クライアント側のプラグイン・ソフトと，サーバー側のフレームワークから成る。クライアント・アプリケーションはダウンロード直前にサーバー側のフレームワークで動的に生成され，クライアントのプラグイン・ソフト上で動作する（図1）。
 |
| 図1●［タイプ2］プラグイン＋サーバー型の仕組みと特徴 クライアントにインストールしたプラグイン・ソフトで動作するアプリケーションを，サーバー上のフレームワークで動的に生成する。サーバー上のフレームワークとリアルタイムに同期可能である。図示したのは米Adobe Systemsの「Flex 2.0」の仕組み [画像のクリックで拡大表示] |
代表的な製品は，Adobe Systemsの「Flex」と米Nexaweb Technologyの「Nexaweb Platform」。Flexのプラグイン・ソフトは「Flash Player」，Nexaweb Platformのプラグイン・ソフトは「JVM（Java Virtual Machine）＋JavaApplet」である。
第1回で示したとおり，ベルシステム24のシステムやひまわり証券のシステム（画面1）で，各担当者はFlexを選択した。日本電子計算の金融機関向けパッケージ・ソフト（画面2）の担当者は，その基盤にNexaweb Platformを選んだ。
|
プラグイン＋サーバー型の特徴は，サーバーからクライアントへデータをリアルタイムにプッシュできること。クライアントのプラグイン・ソフトとサーバーのフレームワーク（図1の同期フレームワーク）が連携する。
こうした特徴を備えるので，リアルタイム通信が必要なシステム（例えば株式や為替の売買システム）の担当者に注目されている。ひまわり証券の中野和彦氏（システム部 開発部長）は，「リアルタイム処理を実現することは必須に近い要件だった。Flex 2.0でリアルタイムのデータ同期機能（Flex Data Service）がサポートされることが分かっていたので選択した」という。もっとも同社の場合，システムのリリース予定日とFlex 2.0の出荷予定日との兼ね合いで，最終的にデータ同期機能の利用は見送った。その結果Part 2で説明したように，同社はリアルタイム性を高める代替策を工夫した。
リアルタイムに通信する場合，サーバーのリソースを多く消費するので注意しなければならない。リアルタイム通信の仕組みは，クライアントとサーバー間で張りっぱなしにしたTCPコネクションを使って，サーバーからデータを送り込むというものだ。それゆえ，TCPコネクションごとにサーバー側の一つのスレッドを占有することになり，メモリーを多く消費する。
リアルタイム通信を使用した三菱東京UFJ銀行のシステム担当者は，事前のキャパシティ設計を入念に実施した（図2）。サーバー1台当たりのTCPコネクション数や，サーバー側JVMのヒープ（メモリー）サイズ，サーバーの台数などをそれぞれ変更してテストし，最適な値や台数を探った。
 |
| 図2●リアルタイム通信時には事前のキャパシティ設計が必須 三菱東京UFJ銀行は企業向けの為替取引システムの構築に当たり，リアルタイムに画面更新できるようにした。リアルタイム通信を可能にするには，クライアントから張ったTCPコネクションを維持し，サーバーから最新為替データをプッシュ送信する必要がある。クライアントの台数分のスレッドを消費することを考慮し，プロトタイプ時にキャパシティの設計とテストを実施。サーバー当たりのコネクション数などを決定した [画像のクリックで拡大表示] |
プラグイン＋サーバー型の利用を見送ったエンジニアの多くは，プラグイン・ソフトのバージョン管理の煩わしさを指摘する。Flash PlayerとJVMはどちらも普及率は高いが，複数のバージョンが存在するのでその点が課題になる。インターネット上に公開するシステムでは，利用者のプラグイン・ソフトのバージョンを統一するのは非常に困難である。さまざまなバージョンが混在すると，テスト工数が多くなり利用者からの問い合わせも増えることが容易に予想される。そうしたケースでは選択しづらいタイプと言える。
