目次


コンポジット・アプリケーション連載

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

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: コンポジット・アプリケーション連載

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:コンポジット・アプリケーション連載

このシリーズの続きに乞うご期待。

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

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

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

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

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

図1. 個別ユーザーインターフェースの利用
図1. 個別ユーザーインターフェースの利用
図1. 個別ユーザーインターフェースの利用

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

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

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

図2. コンポジット・アプリケーション
図2. コンポジット・アプリケーション
図2. コンポジット・アプリケーション

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

類似概念との比較

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

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

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

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

図3. コンポジット・アプリケーションとマッシュアップ
図3. コンポジット・アプリケーションとマッシュアップ
図3. コンポジット・アプリケーションとマッシュアップ

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

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

実装における選択肢

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

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

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

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

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

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

図4. コンポーネント間の連携
図4. コンポーネント間の連携
図4. コンポーネント間の連携

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

  • クライアント実行環境(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を持つこと
図5. コンポーネントの実装方式
図5. コンポーネントの実装方式
図5. コンポーネントの実装方式

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

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

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

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

 

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

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

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

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

1. OSGi仕様

コンポジット・アプリケーションに限らず、サーバー/クライアント/開発ツールなど、アプリケーションを動かすための実行環境にはある程度共通して求められる理想像があります。以下、主なものを列挙しました。

  • 計算資源を効率的に利用できる、コンパクトな実行環境である
  • 実行環境上で複数のモジュールを動作させられ、
    • 実行環境の再始動など互いに影響を及ぼすことなくモジュールのインストール・アンインストール・開始・停止ができる
    • 必要に応じて互いの機能を呼び出せる(コンポーネント化が容易)
    • 相互の依存関係を判別して必要なモジュールを連鎖的に実行できる
  • モジュールは実行環境となるべく依存関係をもたないように設計できる
  • ただし、必要に応じて実行環境に依存した実装をも許容する必要もある

上記のあるべき姿を実現できる標準仕様として策定しているのがOSGi仕様です。"OSGi"という言葉はOSGi Allianceという標準化団体の名称を指すこともOSGi仕様を意味することもあります。特定のプラットフォームに依存しない(ハードウェアやOSに依存しない)ことも重視されていますのでJavaベースであることも自然な流れといえるでしょう。小さな環境でも動作することができるよう前提Java環境はJava ME CDC以上となっています。SOAという言葉が普及する以前からサービス指向という考えを取り入れています。最新はR4.1です。この優れたフレームワークをJavaSEに取り込むべくJCPでもJSR277や294がディスカッションされています。

用語:
OSGiフレームワーク、バンドル(Bundle)、サービス、バンドルアクィベーター(Bundle Activator)、マニフェスト(Manifest)、バンドルコンテキスト(Bundle Context)
情報源:

2. Portlet

Java EEには含まれていませんが、ポータルサイトを構成する単位となっている小さな矩形領域のコンテンツを生成する、JSP/Servletを拡張したWebアプリケーションのためのJavaの標準仕様です。JSR 168として規定されており、現在は後継のJSR 286も策定中となっています。ネットワーク上のポートレットをリモートから呼び出すためのWSRPというWebサービスベースの仕様の普及も進んでいます。IBMではIBM WebSphere Application ServerやIBM WebSphere Portalといったサーバー製品の他、クライアント側の実行環境であるIBM Lotus Expeditorでもサポートしています。ポートレットはコンポジット・アプリケーションのコンポーネントとして利用することができます。

用語:
ポートレット(Portlet)、ポートレットコンテナ、JSR 168、WSRP
情報源:

3. Eclipse Equinox

Eclipse EquinoxはオープンソースコミュニティEclipseによるOSGi仕様のリファレンス実装です。 プラグインフレームワークという独自の拡張を加えることで実行環境への機能追加を容易にしているのが大きな特徴です。機能を追加するモジュールをプラグインと呼んでいます。Eclipseベースの技術はEquinoxで提供される最小限の実行環境へのプラグインの追加という形で実現されていると言え、Eclipse系の開発者にはこれらの用語・考え方の理解がとても重要です。プラグインはOSGiバンドルの拡張であるため、フレームワークを使いこなすにはOSGiバンドルの理解が必要となります。

用語:
プラグイン(plugin)、フィーチャー(feature)、更新サイト(update site)、plugin.xml、拡張ポイント(Extension Point)
情報源:

4. Eclipse RCP (Rich Client Platform)

Eclipse Equinoxはコンソールを除けばUIを持たない実行環境であったのに対し、Eclipse RCPではそこにクライアントアプリケーションが必要とする多くの汎用機能、特にユーザー・インターフェースが加えられています。基本ウィンドウとなるワークベンチ、そこへの画面レイアウトの定義(パースペクティブ)、構成要素(ビュー、メニュー項目、等)の追加などはすべてプラグインの追加という形で行われます。AWT/Swingといった従来からあるJavaのGUI部品の欠点を克服したSWT/JFaceというGUI部品(ウィジェット)ライブラリ・フレームワークも取り込まれています。クライアントサイドのコンポジット・アプリケーションでは"コンポーネント=RCPビュー"が基本的な考え方となります。

用語:
RCP、ビュー(View)、パースペクティブ(Perspective)、ワークベンチ(Workbench)、プリファレンスページ(Preference Page)、SWT、JFace
情報源:

5. IBM Lotus Expeditor

IBM Lotus ExpeditorはIBMがEclipse RCPというクライアントアプリケーション用の汎用基盤を企業システムへの適用にあわせて拡張した製品・テクノロジーです。企業での利用を意識しサーバーサイドで利用されているJavaEEやPortlet仕様のサポートを追加しており、これまでのサーバーサイドでの資産を再利用しやすいのが特徴です。そのほか、企業ユースで必ず課題となるセキュリティ・管理・配布などに対するソリューションを提供します。クライアントサイドのコンポジット・アプリケーションの動作基盤です。IBM Lotus Expeditorはパソコンの他、スマートフォンやPDAをターゲットとしてより小さな実行環境も提供します。こちらはEclipse RCPの組み込み版であるEclipse eRCPベースです。

用語:
コンポジット・アプリケーション、JavaEE仕様(JSP/Servlet, JDBC, JMS, JNDI, EJB,等)、キーストア、組み込みブラウザ、ロックダウン、jclDesktop、jclDevice
情報源:

6. IBM Notes 8.x

最新のV8よりIBM NotesはIBM Lotus Expeditorベースとなりました。その結果、IBM NotesはJava/OSGi/Eclipse/LotusExpeditorスキルを組み合わせて自由に拡張できるプラットフォームとして生まれ変わっています。これまでのNotes/Dominoでの資産であるNSFアプリケーションの要素をコンポジット・アプリケーション内に取り込み、非NSFコンポーネントと連携させることができます。

用語:
プロパティ・ブローカー・エディター、コンポジット・アプリケーション・エディター、NSF、ノーツ・ビュー、ノーツ・データベース、ノーツ・テンプレート
情報源:

7. IBM Lotus Symphony (beta)

Lotus Symphonyは無償のオフィススイートとして公開・提供しています(現在はベータ2)。 技術的にはLotus ExpeditorのサブセットにOpenOfficeベースのオフィス機能を搭載しています。Lotus Symphony提供のコンポーネント/APIにより、コンポジット・アプリケーションのコンポーネントとしてこれまでのオフィス系資産も再利用できるようになります。IBM Notes 8.x 内のプロダクティビティ・エディターと同様の機能です。

用語:
ODF
情報源:

8. Eclipse SDK(IDE)

開発環境としてのEclipseです。Javaの開発環境としては標準といってもよいでしょう。これについてはここで特に詳細を取り上げることはしません。

情報源:

9. IBM Lotus Expeditor Toolkit

Eclipse RCPの開発環境はEclipse SDK付属のPDEです。Eclipse RCP を拡張したLotus Expeditorでは、Eclipse SDK/PDEをLotus Expeditor固有のウィザードやドキュメント、サンプルコードなどで補間する開発ツールキットであるLotus Expeditor Tookitが提供されています。評価版を無償ダウンロード可能ですのでご利用ください。クライアントサイドのコンポジット・アプリケーションの基本ツールとなります。 Lotus Expeditorだけでなく、Lotus ExpeditorベースのIBM SametimeやIBM Notesの開発環境としてもお使いいただけます。

用語:
プロパティ・ブローカー・エディター

10. IBM WebSphere Portlet Factory

IBM WebSphere Portlet FactoryはJava EEのWebアプリケーション、またはポートレットを開発するための開発環境です。設定画面も提供するビルダーと呼ばれる部品と組み合わせ、プログラムコードを極力書かずに開発できるのが特徴です。コンポーネントをポートレットとして実装する際の基本開発ツールとなります。

用語:
ポートレット、ビルダー、モデル

11. IBM WebSphere Application Server

IBM WebSphere Application ServerはサーバーサイドのJava仕様であるJava EEをフル実装したIBMのアプリケーションサーバーです。ポートレットの動作もサポートしております。 ポートレットのテスト環境としてはお使いいただけますが、コンポジット・アプリケーションのフレームワークは搭載されていません。バージョン6.XよりOSGiのクラスローダーの仕組みも取り入れています。サーバーサイドでのOSGi利用が進んでいることを垣間見ることができます。

用語:
Java EE
情報源:

12. IBM WebSphere Portal

IBM WebSphere PortalWebSphere Application Serverを元に、ポータルフレームワークを搭載・拡張しています。サーバーサイドのコンポジット・アプリケーションの基本実行環境となります。Webブラウザに対してWebベースのコンポジット・アプリケーションを提供するだけでなく、Lotus Expeditorベースのクライアント実行環境にクライアントアプリ型のコンポジット・アプリケーションを配信することも可能です。

用語:
ポートレット、JSR 168、ロールベース、パーソナライズ
情報源:

その他、コンポジット・アプリケーション全般

まとめ

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


ダウンロード可能なリソース


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus, WebSphere, Java technology, Open source
ArticleID=273259
ArticleTitle=コンポジット・アプリケーション連載: 第0回 コンポジット・アプリケーションを取り巻く技術
publish-date=12072007