コンポジット・アプリケーション連載: 第0回 コンポジット・アプリケーションを取り巻く技術

ページオプション JavaScript を要するドキュメントオプションは表示されません

レベル: 初級

森谷 直哉, ソフトウェア事業 Lotusテクニカルセールス, IBM

2007年 12月 07日

コンポジット・アプリケーションとは、複数の画面を集約し、さらに連携させることによって既存の資産を再利用しながら作業効率のよい新しいアプリケーションを作るモデルです。 この概念自体は決して新しいものではありません。しかしながら適用された場はまだまだ少ないのではないかと思います。IBMではコンポジット・アプリケーションを作業効率のよいユーザー・インターフェースを実現するための重要な概念と位置づけ、このモデルを採用したアプリケーション、ミドルウェア、開発ツールを提供しています。 本連載ではデベロッパーの皆様がお持ちの資産や技術をどのようにコンポジット・アプリケーションに適用できるのか、どのように新規にコンポーネントを作ることができるのか、サンプルコードを交えてご紹介する予定です。

初回となる今回はその準備として下記の項目について説明していきます。

• コンポジット・アプリケーションの意義
• コンポジット・アプリケーションの開発
• コンポジット・アプリケーションに関連する技術、用語とその情報源

コンポジット・アプリケーションの意義

どのようなメリットをもたらすのか？

ある業務をこなすために、システムＡのウェブ画面でまずフォームを入力・送信して検索し、その結果を次のシステムＢの必要項目として再入力する。業務を拡張するたびにシステムを追加してきた結果、エンドユーザーは複数の画面を使い分けることを強いられている、こうした状況はどこでも目にすることができます。

こうした業務オペレーションでは、本来はシステム間が整合性をとって連携しているべきところをエンドユーザーの手作業（コピー・ペースト）などによってつながれていることになります。システムに手を入れて改善しようにも、それぞれのシステム設計やオーナーが異なっていたり、双方を知る人材がなかなかいなく体制作りが難しいなど、リスクもコストも高くなりちょっと操作性を改善するためだけに動くことはできず、結局次の更改のタイミングを待つということになりがちです。

コンポジット・アプリケーションはこのような状況を打開するための1つの解となりえます。既存ユーザー・インターフェースを組み合わせるということは、ユーザー・インターフェースとサーバー間には手を入れなくてすみます。多くの場合、サーバーはそのままで構わないのです。ユーザー・インターフェースがこれまで他のアプリケーションと連携することを想定していなかった場合（多くの場合はそうだと思います）、この部分に最小限の手を加えて外部連携するためのインターフェースの追加は必要かもしれません。しかしながら多くのリスクとコストを抑えるられるのです。

これまではエンドユーザーが各システムに対して個別に行ってきた操作をコンポジット・アプリケーションが自動的につなぐ、あるいはユーザーの入力支援を行うなどして最小限にとどめることができます。大幅な作業時間の短縮だけでなく、正確で品質の高い処理が期待できます。

参考までに、このような形態のシステム連携はフロントエンド・インテグレーションとも呼ばれます。フロントとはユーザー・インターフェースです。基幹システムに手が加えられないときに、各システムのユーザー・インターフェースを連携させることで連続した作業を実現するというモデルです。

類似概念との比較

ここでは、Web2.0用語としても良く使われるいわゆるマッシュアップという概念と比較してみましょう。一般的に言われているマッシュアップという手法は以下のような形で活用されています。

• 複数のサービスAPI(RSS/ATOM,REST,SOAP等)より取得・融合・加工したデータを1つのユーザーインターフェースで表現する
• 複数のサービスAPIを連続的に接続して新しいサービスを作り出す

この時、利用する個々の機能はサービスとして切り出されていることが前提となります。既存資産を再利用するという点では同じなのですが、コンポジット・アプリケーションではサービスではなくユーザー・インターフェースを最大限再利用します。つまり、サービスAPIとして整備されていないような資産をも取り込むための手法です。例えば、有用な情報を提供してくれるインターネット上のサイトがあったとします。これを自分のアプリケーションに取り込むことを考えたとき、サービスAPIが提供されておらず管理対象でもないそのサイトを利用するには画面そのものを取り込むのが効率的でしょう。

サービスAPIの再利用とユーザー・インターフェース（画面）の再利用は必ずしも役割が重複するものではなく、どちらか一方に絞り込む必要はありません。両者を要件や既存の資産・環境に応じてうまく組み合わせることでより効率的にアプリケーション開発ができるはずです。

例えば、ある既存アプリケーションのデータ一覧から項目を選択（クリック）すると、インターネット上の複数のサービスから収集した関連情報が横の領域にビジュアルに表現される　といった利用が考えられます。

上に戻る

コンポジット・アプリケーションの開発

実装における選択肢

複数の既存ユーザーインターフェースを組み合わせかつ連携させられるアプリケーションの実装形態にはさまざまな選択肢が存在し、下記の大きなポイントで分類することができます。

• ユーザー・インターフェースの選択肢
  • ブラウザベース：HTML/CSS/JavaScript/AJAX/ブラウザ拡張プラグイン(Java Applet, Flash,etc)を使用します。昨今のWeb20技術により表現能力はかなり改善されてきていますが、ブラウザの表現能力・セキュリティモデルの制約の範疇でのみ実装が可能です。
  • クライアント・アプリケーション：Webブラウザの制約にとらわれず、特定のOSやプラットフォームに固有のユーザーインターフェースを実装できます。ブラウザ以外の実装は一般的によりレスポンスが早くキーバインドなどのカスタマイズも比較的容易です。ファイルシステムや接続デバイスへのアクセスも可能です。なお、Webブラウザも画面構成部品として取り込めるため、ブラウザベースの実装技術も活用できます。
    
    
• アプリケーション実行場所の選択肢
  • サーバー：一元管理が可能な反面、通信環境に強く依存しておりサーバーに接続できないと何も行うことができません。
  • クライアント：通信を必要最小限にとどめることができるため、一般的に早いレスポンスを得ることが可能です。通信が必要ないアプリケーションであれば非接続環境でも利用できます。一方で実行環境の配布・インストール・管理の手段が必要となります。

上記の選択肢はアプリケーションの要件や運用のポリシーに応じて選択することとなります。一般的に、サーバーサイドで実行されるコンポジット・アプリケーションはブラウザベースのユーザー・インターフェースを、クライアントサイドのコンポジット・アプリケーションではブラウザ以外（以上）の実装をすることが多いです。

コンポジット・アプリケーションを実現するフレームワーク

コンポジット・アプリケーションという概念はIBM固有のものではありませんが、この概念のための万能な標準仕様が存在するわけではありません。（一部、Webアプリケーションのコンポーネント化についてはJava Portlet仕様が存在しますが、Java EEのWebアプリケーションの拡張であり、ブラウザベースでないアプリケーションには適用できません。）そこで、IBMはコンポジット・アプリケーションを実現するためのフレームワークを規定・実装し、それをサーバー製品・クライアント製品に組み込んで提供しています。

集約される個々のユーザー・インターフェースを"コンポーネント"、そしてコンポーネント間の連携を"ワイヤ"と呼びます。ワイヤ定義をもとにコンポーネント間のイベント・データ中継行う"プロパティ・ブローカー"が非常に重要な役割を果たします。コンポーネントは互いを意識する必要があってはいけません。連携相手を意識したのでは依存関係が生まれ、再利用性に欠けるからです。各コンポーネントは共通フレームワークであるプロパティ・ブローカーへのイベントやデータの渡し方、呼ばれ方を適切に実装します。これにより画面レイアウトや実行時の連携（ワイヤ）とコンポーネントの実装を切り離され、コンポーネント開発者、画面レイアウト・ワイヤ作成者、利用者は互いに独立して作業することができるようになります。

本連載では、コンポジット・アプリケーションに対応している、つまりプロパティ・ブローカーが提供されている下記環境をターゲットにコンポーネントを作っていきます。

• クライアント実行環境(IBM Lotus Expeditor またはその派生系の製品)
• サーバー実行環境(IBM WebSphere Portal またはその派生系の製品)

また、開発環境としてはEclipse SDK(IDE)にプロパティ・ブローカー対応機能をはじめ各種ツールを追加する（プラグインを提供する）下記を使用予定です。

• IBM Lotus Expeditor Toolkit
• IBM WebSphere Portlet Factory

開発のフロー

コンポジット・アプリケーション開発の流れは以下のようになります。

1. コンポーネントの開発：必要となるコンポーネントを開発します。既存のユーザー・インターフェースがあるならば、実行環境に合わせてそれをラップし、フレームワークとのインターフェースとなる実装を追加します。目的に合致した再利用できるコンポーネントがある、または外部から購入するといった場合にはスキップ可能です。
2. 画面レイアウトの作成：コンポーネントを画面上に配置します。
3. ワイヤの設定（ワイヤリング）：コンポーネント間のデータ連携を設定します。フレームワークはこの情報をもとにデータを受け渡しを行ってくれます。
4. 配布：クライアント・アプリケーションであれば必ずアプリケーションの配布方法を考慮します。

本連載では、これらのうち1のプロセスを中心に取り扱っていきます。2～4はどのようなコンポジット・アプリケーションにも共通の手順ですが、実行モデル（クライアントまたはサーバー）や運用管理形態（ユーザー主導管理、サーバー管理、等）によって利用可能なツールが異なります。詳しくは以降ご紹介するサイト・資料を参照ください。

コンポーネント開発

コンポジット・アプリケーションの一部として利用できるコンポーネント、それが満たさなければならない必要最低限の条件は実は多くありません。画面を再利用するモデルですから、ユーザー・インターフェースを持つことが必須です。（※見えない画面を作るというテクニックはありますが、画面を作るという意味では同様です。これについては連載の中で改めて触れたいと思います）　実装方式によってその条件は異なり、以下のようになっています。

• ブラウザベースの場合：ポートレットとしてのUIを持つこと
• クライアントアプリの場合：RCPのViewとしてのUIを持つこと

ポートレット開発もRCP開発も経験がない方は敷居が高いと思われるかもしれませんが、結果的に上記を満たしていればよいのです。例えば、あるシステムがRSSでフィードを提供できるとします。WebSphere PortalはRSSを閲覧するためのポートレットを、Lotus Notes 8であれば同様のViewを製品として提供しています。提供されるコンポーネントを新しいアプリケーションの画面上に配置するだけで利用可能です。開発する必要があるのは、適切なコンポーネントがまだ提供されていない場合　ということも言えるでしょう。

ただし、連携が可能なコンポーネントに仕上げるためには、前述の通りコンポジット・アプリケーションのフレームワークとのインターフェースをとる必要があります。実装形態によってここで取れる選択肢もことなってきます。本連載でアプリケーション開発をする中で都度ご紹介するとします。

上に戻る

コンポジット・アプリケーション関連の技術・用語とその情報源

ここでは、本連載を進めていく上で是非知っておいていただきたい技術・製品とその相互関係についてまとめておきます。これらをすべて理解しなければコンポジット・アプリケーション開発ができないということではありません。しかしながら、全体像を把握し、実装の選択肢を増やしていくことで個々のコンポーネント要件を満たす最適な実装技術を選べ、それは開発効率や品質にも表れます。ここですべてについて解説することは不可能ですが、参照可能な資料のリンク集を提供できればと思います。新たな領域を学ぶ際には新しい言葉が出てくるものです。そうしたときにそれが何の用語なのか、なかなか分からないことがあります。そうした時の一助になれば幸いです。

上図をご覧ください。IBMではコンポジット・アプリケーションのためのフレームワークをクライアント側、サーバー側の実行環境にて提供しています。ハードウェアやOSを選ばないJavaベースのこれらの環境は企業システムにおけるJavaの標準仕様であるJavaEE、そして、その一部の拡張であるPortlet仕様をともにサポートしています。（注：環境によっては仕様のフル実装ではない点にご注意ください。差異については連載の中で必要に応じて触れていきます）

開発環境についても、Java開発環境として標準ともいえるEclipseをベースに、JavaEE/Portlet開発のための機能追加するだけでなく、コンポジット・アプリケーションの開発に有用なエディターやウィザードも提供する製品郡を提供します。EclipseIDEでおなじみのプロジェクトやパースペクティブの概念は同じですので違和感なくお使いいただけます。

また、クライアント/サーバー/開発環境と全体を通してEclipseとの関係が深い点もお分かりいただけるかと思います。特にクライアント側ではEclipseが提供する汎用アプリケーション実行環境Eclipse RCPをそのまま踏襲しています。Eclipseプラグインに対する理解が実装工数に直接影響するといってもいいでしょう。クライアント/サーバー/開発環境に共通するEclipseのプラグインフレームワーク、そしてそのベースとなっているOSGi仕様に関する資料についても是非一読ください。

以下、図中の主要キーワードについてご紹介します。

上に戻る

まとめ

本連載初回となる今回はコンポジット・アプリケーションという選択肢のメリット、実装形態の概観、そして関連技術・製品へのリンク集をお届けしました。次回以降、いよいよコードを交えてアプリケーション開発例を紹介していきます。

著者について

		2002年頃よりパーベイシブ・コンピューティング分野（音声、モバイル、etc.）のソフトウェア製品の技術支援に従事。ここ数年はEclipseベースのリッチクライアントテクノロジーであり、Notes8のベース技術ともなっているLotus Expeditorを中心にLotusブランドにてテクニカル・セールスとして活動中。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

上に戻る