[ThinkIT] 第4回：これからのリッチクライアント (3/4)

IdbAで構築する生産性が高いリッチクライアント
第４回：これからのリッチクライアント著者：サイオ柏貴光 2005/12/14

前のページ 1 2 3 4 次のページ

開発における生産性

   リッチクライアントに限らず、開発生産性を上げるのに最も効果的な方法は「汎用技術」を利用することです。新しくシステムを開発するにあたってベンダー独自の開発言語を採用すれば、その言語を知っている技術者を集めるか、1から教育する必要があります。

   また開発終了後に開発チームが解散するのは一般的ですが、システムが稼動する限りメンテナンスは発生します。このような際も汎用技術であればトラブル時の対応などに比較的容易に対応できますが、独自言語を使用したシステムとなるとそう簡単にはいきません。開発時と同じようにその言語を知っている技術者を呼んでくるか、ベンダーのサポートを受ける必要があります。

   IdbAは完全にJavaでの開発となるため、Javaの技術者の方であればすぐに開発することができますし、オープンスタンダートで広く普及している技術（XML、SOAPなど）もそのまま利用することが可能です。また、次期バージョンのIdbA R2.0ではテンプレートツールによるソースコード自動生成機能が追加され、IdbA独自のAPIを利用した部分の多くは自動的に生成されるようになり、さらに開発生産性は向上します。

   リッチクライアントに限ってみると、開発生産性のキーワードとしては次の点が考えられます。

外部リソースとの接続容易性
画面開発の容易性

表1：開発生産性のキーワード

   1つ目の外部リソースとの接続とは、リッチクライアントアプリケーションがサーバといかに簡単に接続できるかを意味します。リッチクライアントと呼ばれるアプリケーションはオフラインでも実行可能である必要がありますが、基本的にはオンラインでサーバと通信を行います。この通信の方式についても、SOAPなどのオープンな技術が容易に利用できれば、それだけ開発生産性は向上します。

   要求される仕様によっては接続先が1つとは限りません。多くのリッチクライアントは接続先が1つで、サーバ側はベンダーの流儀にあわせた作りこみが必要なのに対し、IdbAは既存のサーバをそのままいかしながらもリッチクライアントを利用することが可能です。

   例えば、現在最もポピュラーなHTMLベースのインターフェースを持つWebシステムに対しては、スクリーンスクレイピング（画面からデータを取得する）技術により、IdbAがブラウザの「ふり」をすることでサーバ側は何も変更せずにクライアント側のアプリケーションのみを「リッチ」なインターフェースにすることができるのです。

   2つ目の画面開発の容易性とは、アプリケーションの画面の作成がいかに楽にできるかということです。これについては、各ベンダーとも画面作成用の開発環境を用意しているのが一般的です。IdbA R2.0では、既存のJavaのGUI開発環境（例えばEclipse + Visual Editorなど）と連動することにより開発容易性を確保しています。Javaの開発者が使い慣れたGUI開発ツールをそのまま利用していただくことで、開発生産性の向上にも繋がります。

   IdbAでの開発による生産性の向上については、「第３回：コンポーネントの開発事例」でも紹介しましたが、「コンポーネント単位での開発が可能である」という点に大きな特徴があります。

   例えば前項であげたアカウントアグリゲーションの例では、新しく銀行や証券会社が増えた場合にその接続コンポーネントを作成する必要がありますが、これは接続コンポーネントとして必要なインターフェースを他のコンポーネントとあわせる形で実装すればよいだけです。

   このようにして作成されたコンポーネントは、プログラム全体に影響を与えることなく、機能としてアカウントアグリゲーションに追加することができます。このように時差のある開発でも柔軟に対応できるため、高いメンテナンス性を維持できます。

ブラウザ型とスタンドアロン型

   一言でリッチクライアントといってもその形態は様々です。ブラウザ型やスタンドアロン型があり、用途によって大別されます。

   現在、各リッチクライアント製品はその得意分野によりすみ分けができているため、業務特性は操作性重視なのか表現力重視なのか、市場はBtoCかBtoB、inBかという用途の区分により選択するのが一般的です。

   IdbAは、IdbAランタイムの上で各コンポーネントが結合して動くのでスタンドアロン型に分類されますが、ランタイム自体はJava Web Startによって配布することが可能（つまりブラウザ上でリンクをクリックすればインストール可能）なので、「ランタイムのインストールファイルをダウンロードして、インストーラを起動して…」といった手間はかかりません。

   また、ランタイム本体も約2MB程度と他のスタンドアロン型と比べるとかなり小さく、ナローバンドにも対応可能なリッチクライアントといえます。さらに表現性の部分については、一般に市販されているJavaライブラリなどを利用することにより、高度な表現性を提供することができます。つまり、BtoCでもinBでも使え、表現性の高いリッチクライアントなのです。

図2：IdbAの配布形態
（画像をクリックすると別ウィンドウに拡大図を表示します）

前のページ 1 2 3 4 次のページ

著者プロフィール
株式会社サイオ柏貴光
大阪の大学を卒業後、SI企業に入社。SEとしてオープン系システムの設計、開発から導入までを幅広く行う。2005年4月にサイオへ入社し、IdbAの可能性を世に広めるためライセンシング事業の立ち上げに尽力する。IdbA製品企画を担当する傍ら、同社のメールサービス「SCIO RHYTHM」の編集長も手がける。また、Linuxコンソーシアム・リッチクライアント部会リーダーを務める一方、運営委員メンバーとして広報を兼任し、同コンソーシアムが発行するメールマガジンの編集長を担当している。

INDEX
第4回：これからのリッチクライアント
	リッチクライアントの現状
	リッチクライアント選択のキーワード
	開発における生産性
	マルチプラットフォーム