TOP
＞
設計・移行・活用
＞ マルチプラットフォーム
IdbAで構築する生産性が高いリッチクライアント
第４回：これからのリッチクライアント
著者：
サイオ 柏 貴光
2005/12/14
前のページ
1
2
3
4
マルチプラットフォーム
多くのリッチクライアント製品はWindowsへの対応をベースとしており、その他のOSへの対応については片手落ちの状態となっているものがほとんどです。BtoC市場を見据えた場合、LinuxまたはMac OSへの対応が不可欠です。JavaベースのIdbAは、Java VMが提供されているOSでは同一のプログラムが動作可能であるため、LinuxはもちろんMac OSでも動作可能です。
図3：対応プラットフォーム
ライセンス体系
リッチクライアント製品を導入する際、現実問題として直面するのがライセンスとサポートのコストではないでしょうか。製品によってライセンス形態に様々な制限があります。
今後のPDAなどの携帯端末も視野に入れると、利用者は「無限」に近い状態で広がると予測できます。その際でも柔軟に対応できるよう、IdbAでは無制限ライセンスを用意しており、サーバ接続については接続数による制限は基本的にありません。また、エンジン本体を含めすべて国内製ですので、サポートについても迅速な対応が可能となっています。
サーバが必要か否か
リッチクライアント製品の多くは、サーバ側にも専用インターフェースをもつアプリケーションサーバを必要とします。1から作るシステムであれば必要な投資といえますが、「既にあるシステムのクライアント環境をリッチにしたい」という要求に対し、サーバ側もクライアント側にあわせてカスタマイズするのは本末転倒かもしれません。
オープンな技術やスクリーンスクレイピング機能を装備するIdbAは、クライアント側のみで対応できます。これはつまり、「一般的に公開されているサーバであれば連携できる」ということを意味しています。サーバ側において連携用の準備や変更作業が発生することはありません。このようにIdbAは連携先を選ばないため、サービスの幅は大きく広がります。
図4：オープンな技術の採用
（画像をクリックすると別ウィンドウに拡大図を表示します）
これからのリッチクライアントに求められるもの
リッチクライアント製品は今後もさらに進化を続けていくでしょう。そこで、これからのリッチクライアントの進化の方向性をふまえた上でIdbAが目指している方向性のキーワードを以下にまとめてみました。
C=S
Webシステム以前の主流であったC/S（クライアント／サーバ）システムは、クライアントとサーバで負荷を分散する技術でした。つまりクライアントとサーバで役割が明確に分かれていた形態であり、これにより、「アプリケーションができること」の自由度も制限がありました。つまり、「クライアント」「サーバ」といったRim（ふち）がある状態です。
これからのキーワードとしてリッチクライアントに求められるものは、C=S、つまりクライアント＝サーバの環境です。これは決してサーバ不要な環境というわけではなく、コンセプトとしてはクライアントとサーバのRim（ふち）をなくすことで、「利用者にサーバを意識させない環境」あるいは「サーバが提供するサービスをクライアントの手元にあるように感じることができる環境」を利用者に提供するということです。
サーバは基本的にサーバとしての役割を持ちながら状況に応じてクライアントにもなりえる、逆にクライアントがP2Pでサーバの役割を果たすこともある、といったようにグリッド的に各サーバや端末が連携し、利用者はその中で使いたい機能や情報、あるいはその2つをカプセル化したコンポーネントを組み合わせることによって目的を果たすという状態が、本当に「リッチ」なクライアントといえるのではないでしょうか。
IdbAは、製品ロードマップにこの「C=S」をキーワードとして盛り込み、さらなる機能拡張を予定しています。
リッチクライアント「プラス・アルファ」
現在、リッチクライアントはそれぞれが得意分野をもち、その製品単体で1つのソリューションを提供するのが一般的です。しかし今後は、サーバならではの得意分野をもった「アプリケーションサーバ」とリッチクライアントが連携して、リッチクライアントに「プラス・アルファ」したソリューションを提供する形がでてくるでしょう。
単一のベンダーから提供されるものだけではなく、複数ベンダーが提供するソリューションを効果的に繋ぐことにより、新しい「情報インフラ」が誕生する可能性もあります。そのためにはオープンな汎用技術により接続できる必要があります。SOAPなどの汎用技術を容易に組み込むことができ、コンポーネントとして同一実行環境の中で動作させることができるIdbAは、「ベンダー」というRim（ふち）すらなくすことが可能です。
現行のコンポーネント配信・動的結合という特徴的なアーキテクチャに、「C=S」やリッチクライアント「プラス・アルファ」といった拡張機能を実装してRimless Computingを実現することで、企業内における所属部署や役職といった情報を利用して、部門内での連携や、組織体系に応じた連携、部門間を効果的に繋ぐ連携ソリューションが生まれてくるでしょう。
もちろん、Rimless Computingはコンピュータを利用するあらゆるシーンにおいて適用される概念なので、企業内などといった範囲にはとどまらず、あらゆるサービスや、サービスを提供するベンダーのRim（ふち）がはずれた、本当にユーザにとって利便性・生産性の高い究極の「リッチ」な世界が展開されるでしょう。
前のページ
1
2
3
4
著者プロフィール
株式会社サイオ 柏 貴光
大阪の大学を卒業後、SI企業に入社。SEとしてオープン系システムの設計、開発から導入までを幅広く行う。2005年4月にサイオへ入社し、IdbAの可能性を世に広めるためライセンシング事業の立ち上げに尽力する。IdbA製品企画を担当する傍ら、同社のメールサービス「SCIO RHYTHM」の編集長も手がける。また、Linuxコンソーシアム・リッチクライアント部会リーダーを務める一方、運営委員メンバーとして広報を兼任し、同コンソーシアムが発行するメールマガジンの編集長を担当している。
INDEX
第4回：これからのリッチクライアント
リッチクライアントの現状
リッチクライアント選択のキーワード
開発における生産性
マルチプラットフォーム
