お客様が developerWorks に初めてサインインすると、プロフィールが作成されます。プロフィールで選択した情報は公開されますが、いつでもその情報を編集できます。お客様の姓名（非表示設定にしていない限り）とディスプレイ・ネームは、投稿するコンテンツと一緒に表示されます。

送信されたすべての情報は安全です。

developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

送信されたすべての情報は安全です。

My developerWorks：

通知：

サイン・アウト

言語を選択する：

コンポジット・アプリケーションの設計: デザイン・パターン

Jo Grant, Senior Software Engineer, IBM

Jo Grant is a Senior Software Engineer for IBM Lotus, specializing in Eclipse-based technology.

Craig Wolpert (cwolpert@us.ibm.com), Senior Software Engineer, IBM

Craig Wolpert is a Senior Software Engineer for the IBM Lotus Software ISV Technical Enablement program.

概要： コンポジット・アプリケーションを設計するときのデザイン・パターンの識別と最適化の方法について解説します。

タグを付ける!

日付: 2008年 2月 05日 (公開: 2007年 12月 11日)
レベル: 初級
この記事の原文: 英語
アクティビティー： 1930 ビュー
お気軽にご意見・ご感想をお寄せください：

注意事項: この記事は、developerWorks Lotus US で公開予定の一連のコンポジット・アプリケーション関連記事の 3つ目となります。先行の記事「IBM Lotus Notes 8 を利用した Lead Manager アプリケーションの概要」および「コンポジット・アプリケーションの設計: コンポーネントの設計」を参照してください。

コンポジット・アプリケーションは、サービス指向アーキテクチャー (SOA) およびコンテキスト・コラボレーション戦略における主要な要素であり、競争の激しい今日の市場で、絶えず変化する需要に迅速に対応しなければならない企業や組織のビジネスの柔軟性を支援します。コンポジット・アプリケーションは疎結合されたユーザー・インターフェース・コンポーネントの集合体であり、コンポーネント間のコミュニケーションを支援します。

コンポーネントは複数のコンポジット・アプリケーションで再利用できます。複数のテクノロジーを組み合わせて単一のアプリケーションを構築できることは、多大なビジネス価値をもたらします。このような能力によって、企業は自社の既存資産の柔軟性を高めながら保護および拡張することができます。また、複数のアプリケ-ション開発環境を使用する場合よりもアプリケーションの開発がはるかに容易であるため、新たなビジネス要件に対しても迅速かつコスト効率に優れた対応が可能になります。

この疎結合されたコンポジット・アプリケーション・アーキテクチャーにより、分散する複数グループが互いの成果を活用したり、連携したりすることも可能になります。例えば、ある部門では会計アプリケーションで作業し、別のグループではセールス・リード・トラッキング・アプリケーションで作業している場合を考えてみます。コンポジット・アプリケーションでは、セールス・リード・トラッキング・アプリケーションのコンポーネントの一部を会計アプリケーションに追加して、資産の関連ビューを経理のコンテキストで表示することができます。同様に、セールス・リード・トラッキング・アプリケーションでは、会計アプリケーションから一部のコンポーネントを組み込み、資産コンテキストで会計情報を見ることができます。開発するコンポジット・アプリケーション数の増加にしたがって、統合の可能性が飛躍的に向上します。最終的には、コンポジット・アプリケーション全体が、単にパーツの集合体としての機能を上回る成果を発揮することを目指します。

コンポジット・アプリケーション・モデルは、IBM WebSphere Portal の開発者にとってはすでに馴染みのあるものです。このアプローチは IBM Lotus Notes 8 にも拡張されており、Lotus Notes の開発者は Lotus Notes アプリケーションをコンポジット・アプリケーションの 1 つ以上のコンポーネントとして使用することができます。IBM Lotus Domino Designer 8 では、機能拡張によりプロパティー・ブローカーの使用と、より直観的なユーザー環境の提供が可能になりました。Lotus Notes 8 では、Eclipse コンポーネントの使用もサポートされているため、コンポジット・アプリケーションでは Lotus Notes コンポーネントと Eclipse コンポーネントをさまざまに組み合わせることが可能です。これらのコンポジット・アプリケーションは、単一のユーザー・インターフェースで提供して画面上での統合を行うことができ、さらに機能を拡張すれば、プロパティー・ブローカーを使用してコンポーネント間の連携も可能になります。コンポジット・アプリケーションの定義は、Composite Application Editor または WebSphere Portal Application Template Editor を使用して行うことができます。

コンポジット・アプリケーション用コンポーネントの開発は、従来の Eclipse または Lotus Notes アプリケーションの開発とは異なります。十分な柔軟性を備えたコンポーネントを開発し、大幅な手直しをせずにアプリケーションにデプロイできることが極めて望ましいと言えます。この記事では、そのようなコンポーネントの設計のためのアプローチと、考えられるベスト・プラクティスについて論じます。

前提条件

この記事では、読者が IBM Lotus Notes のコンポジット・アプリケーションに精通していることを前提としているため、IBM Lotus Domino Designer ヘルプ(US)のコンポジット・アプリケーションの概要のセクションを復習すると良いでしょう。

次に、developerWorks Lotus に掲載されている記事「IBM Lotus Notes 8 を利用した Lead Manager アプリケーションの概要」および「コンポジット・アプリケーションの設計: コンポーネントの設計」を参照してください。これらの記事で、コンポーネント設計の概要を解説しています。また、ドメイン・セントリックのコンポーネントおよびドメイン・コンテキストに沿ったコンポーネントについても説明しています。これらのコンポーネントはそれ自体でメタパターンとなります。

上に戻る

開発パターン

これまでは、開発過程において類似の問題が発生した際、多くの場合、類似の方法で解決できるというのが主流の考えでした。この考え方はもともとオブジェクト指向プログラミングに取り入れられたものですが、完了した作業をパターンという観点から見る、つまり、一般的な問題に対しては、幅広い応用が利く一般的な解決策で対応するほうが効果的となる環境が、多くあることがわかってきました。このことは、コンポジット・アプリケーションの設計と開発にもあてはまりますので、この記事ではパターンについて見ていきます。

ここでは便宜上、パターンのタイプを次のようにいくつかのカテゴリーに分類します。

共通のコンポーネント・タイプを定義するパターン
コンポーネント・グループを、レイアウト形式および連携方法によって定義するパターン
コンポジット・アプリケーション全体またはコンポジット・アプリケーション・スイートの構成に使用される、アプリケーションまたは全体的な設計手法のパターン

上に戻る

コンポーネント・パターン

このセクションでは、さまざまな共通のコンポーネント・パターンについて解説します。

選択コンポーネント

選択コンポーネントは、情報ドメイン間での値のやり取りを可能にします。例えば、出張申請を送信すると、そこには人事アプリケーションの記録を参照する従業員番号や会計アプリケーションのコントロール・センターを識別するためのコスト・センターが含まれることがあります。出張申請アプリケーションでは、これらの値を参照する目的でのみビジネス・ロジックに従ってトラッキングし、その他の情報ドメインと交差します。UI レベルでは、この情報ドメインで定義されない値のフィールドは単にボックスとしてのみ提供されることが多く、そこにはユーザーが値を入力しなければならないため、入力ミスが発生する可能性があります。

各アプリケーションは、そのドメイン内の情報に適した選択コンポーネントを多数作成することができます。アプリケーションはドメインを完全に把握しているため、選択に適したメソッドをすべてユーザーに提示することが可能です。これは、developerWorks Lotus の記事「コンポジット・アプリケーションの設計: コンポーネントの設計」で解説したドメイン・コンテキストに沿ったコンポーネントの典型的な例です。前述の例では、人事アプリケーションで従業員を選択する選択コンポーネントを作成できます。これにより、従業員名、電子メール・アドレス、電話番号、所在場所によって、あるいはこのアプリケーションがトラッキングするどのフィールドを使用しても、従業員の検索が可能になります。コンポーネントの出力は、これらのフィールドのどれか、または従業員番号となります。これが出張申請に必要なものです。

コンポーネントは次の 2 つのうち、いずれかの方法でレンダリングを行うことができます。

基本レコードの複合が行われるアプリケーション・ページの周辺またはダッシュボード内に存在するように UI を設計できます。複合領域の編集フィールドは選択コンポーネントと連動します。既知の値の場合、その値がエディターに入力されます。未知の値の場合には、選択コンポーネントを使用して選択や検索を行うことができ、その後、値がエディターに戻されます。
最小限の UI を持つ、見えないコンポーネントを作成できます。該当する索引付き値を取り込んでブロードキャストするプロパティーとアクションの他に、コンポーネントに UI の表示を指示する値が別にあります。これは、コンポーネントのレンダリングと同一の検索項目を含むポップアップのダイアログ・ボックスです。この場合は、親コンポーネントの「Lookup」ボタンが必要となりますが (したがって、疎結合のレベルがやや低下します)、UI をより効率的に使用することができます。検索パレットは必要な場合のみ表示されます。

情報コンポーネント

このコンポーネント・スタイルは、単一のデータ・レコードについての詳細を提供します。レコード内のすべてのデータ要素を表示する完全な詳細ビューの場合もあれば、概要情報のみを表示するサマリーの場合もあります。また、レコード内の特定の情報サブセットを対象とすることもあります。現在 developerWorks Lotus で入手可能な Lead Manager のサンプル・アプリケーション(US)には、Companies および Leads 用の情報コンポーネントがあります。また、それぞれについて、元の完全な Lotus Notes 形式を含む Detail コンポーネントと基本情報のみを含む Summary コンポーネントがあります。

選択コンポーネントと同様、情報コンポーネントでも最小限のページ表示しか行われないようにすることが可能です。このコンポーネントを起動すると、プログラムまたは UI を使用し、含まれる情報によってポップアップ・ダイアログ・ボックスが作成されます。そのため、画面上の目に見えるスペースを節約でき、機能が損なわれることもありません。Lead Manager サンプル・アプリケーションでは、このようなポップアップ・ウィンドウが頻繁に使用されます。

ランチャー・コンポーネント

ランチャー・コンポーネントもやはり、ドメインのコンテキストに沿ったコンポーネントです。このコンポーネントで機能を拡張するには、このコンポーネントが含まれるアプリケーションに、情報ではなく機能を追加します。ランチャー・コンポーネントをワイヤリングすることにより、このコンポーネントが含まれるアプリケーションのコンテキストからデータ要素を受け取って、その情報に基づいてコンポーネント自体のドメインからのプロセスとともに、動作するオプションを表示できます。ランチャー・コンポーネントは、ユーザーがそのコンポーネントからのアクションを選択するための UI を提示したり、アクションを取り入れたりすることができます。これにより、別のドメイン・セントリックのコンポーネントが、ポップアップ・モードにおける選択コンポーネントと同様のアクションを取るようランチャー・コンポーネントに指示することが可能になります。また、疎結合のレベルはやや低下しますが、UI の結合はより緊密になります。ランチャー・コンポーネントが直接アクションを使用して動作する、またはユーザーとの対話により動作することが可能である場合、どちらを使用するかはアプリケーション・アセンブラーの判断に委ねられます。

例えば、Lead Manager アプリケーションでは今後、セールス・リード情報ドメインと、電子メールおよびインスタント・メッセージング・ドメインがブリッジされる予定です。メール・コンポーネントがユーザーに対して電子メール作成のアクションを提示し、このアクションが起動されると、新規電子メール・メッセージの作成が開始されます。セールス・リードまたは企業情報レコードを表示すると、そのリードまたは企業の連絡先にメールを送信するオプションが UI に表示されます。これは、ランチャー・コンポーネントがメール・コンポーネントへのワイヤリングを行うことによって表示されるものです。インスタント・メッセージング・セッション開始のオプションの表示にも、同様の手法が使用されます。

セールス・リードの出発点は電子メールであることが多いため、新規セールス・リードの入力エントリーに対応する多数のプロパティーを取り入れて単一の「Create Sales Lead」 (セールス・リード作成) ボタンを表示するランチャー・コンポーネントを作成することができます。このボタンをクリックするとコンテキストがセールス・リード・アプリケーションに切り替わり、コンポーネントによって新規セールス・リード作成用の UI が呼び出され、該当する情報がそこに入力されます。このコンポーネントはメール・テンプレート (または開始点に該当する他のデータベース) にデプロイできます。その場合、現時点で選択されている電子メール・メッセージの「To」フィールドはランチャー・コンポーネントの「Salespserson」プロパティーと、また「From」フィールドは「Customer」プロパティーと連動します。ある電子メール・メッセージを表示中に「Create Sales Lead」オプションをクリックすると、新規セールス・リード作成用の UI が表示され、「Salesman」および「Customer」フィールドはすでに入力済みの状態となります。

計算コンポーネント

計算コンポーネントの目的は、1 つ以上の値を入力値として受け取り、それをもとに 1 つ以上の派生値を出力値として生成することです。単純で一般的な演算からコンテキストによるドメイン検索まで、さまざまな形態があります。多くの場合、これらのコンポーネントには対話式 UI はありません。ブランクにして、アプリケーション内の目立たない領域への配置や、ロゴやその他のブランド表示の使用をすることが可能です。

演算コンポーネントの単純な例としては、値のコンマ区切りリストを入力値として受け取り、その全体を出力値としてレポートするものがあります。その場合、値のリストとして列をエクスポートできるリスト・コンポーネントがあれば、そのリスト・コンポーネントが合計コンポーネントにワイヤリングされ、結果は別のコンポーネントに返されて合計が表示されます。

このタイプのコンポーネントのもう 1 つの目的は、特殊形式の選択コンポーネントとしての用途です。購買アプリケーションの場合を考えてみましょう。一定額以上の発注にはマネージャーの承認が必要です。購買申請の一環として、マネージャーの氏名と電子メール・アドレスの入力が要求されます。ここで選択コンポーネントを使用することは可能ですが、ユーザーが間違った人をマネージャーに選択するのを防ぐことはできません。別の方法として、従業員データベース・アプリケーションを基にドメイン・セントリックのコンポーネントを開発し、そのコンポーネントで従業員の氏名を含むアクションを受け取ってその従業員の各種詳細情報をパブリッシュするという手法があります。この手法であればアプリケーション・アセンブラーはマネージャーの情報をそのフォームの入力部分にワイヤリングできます。また、フォームを入力フィールドから計算フィールドに変更することも可能であり、これによりユーザーの入力ミスを防ぐことができます。

これらのコンポーネントは、データだけではなくビジネス・ロジックにも対応できます。前述の例で、発注限度額は従業員ごとに異なり、また、地域などの社内規定によって異なると仮定します。この会計情報ドメインを基に作成された計算コンポーネントは、従業員名を検索してその従業員の発注限度額の値を返すことができます。購買アプリケーションのドメイン・セントリックのコンポーネントは、この限度額をリアルタイムでチェックできるようになるため、バックエンド・プロセスによってフラグが立てられるまで待つ必要はありません。

このコンポーネントの特殊形式の 1 つは、データ・タイプの変換と連携して機能します。コンポーネントのプロパティーとアクションに強いデータ・タイプを定義すれば、アプリケーションのアセンブリーをより容易かつ正確に進めることが可能になります。しかし、弱いタイプのプロパティーとアクションを使用する汎用コンポーネントを使いたいという場合もあるかもしれません。単純な計算コンポーネントは、1 つのタイプのアクションを取り込んで同一データのプロパティーをパブリッシュしますが、別のタイプとして記述することが可能です。このようなユーティリティー・コンポーネントは目に見えないように、あるいは最小限の UI でデプロイすることができ、変換されなければ互換性のない 2 つのコンポーネント間のフォーマット・コンバーターとしてワイヤリングできます (例えば、郵便番号を取り込むアクションを有し、都市名と州名を含む文字列をパブリッシュするコンポーネントなど)。

集約コンポーネント

コンポジット・アプリケーションの中には、複数ページで構成されるものがあります。ページ間ワイヤーを使用することで、複数ページにわたってシンプルなアプリケーション・コンテキストを維持することができます。ページ間ワイヤーは、プラットフォームによって提供され、Composite Application Editor がこれをサポートします。ページ・コンテキストを変更したい場合には、ページ間ワイヤーにより、プロパティーを別のページ上のアクションに接続します。プロパティーを投入することによってページ変更が実行され、新しいページにコンテキストが与えられます。より複雑なシナリオでは、単一項目のコンテキストを保持して、コンテキストの伝送と連動してページの移動が行われるように要求するだけでは不十分な場合があります。コンテキストには複数の値のトラッキングが伴うことがあり、ページの移動はユーザーの他のアクションによって起動される場合があるからです。

集約コンポーネントは、データウェアハウス・コンポーネントです。多数の値と、それぞれの値に対称的なプロパティーおよびアクションを保持します。アクションによってある値が設定されると、それに対応するプロパティーが投入されます。さらにこのコンポーネントは、このコンポーネントが属するページが表示されたことを認識すると、既知のプロパティーをすべて投入します。この場合に鍵となるのは、集約コンポーネントではアプリケーション内のすべてのインスタンスに対して単一のデータ・モデルが維持されるという点です。つまり、1 つのページで設定された値が複数のページ上に提供され、別のページ上で検索可能になるということです。

集約コンポーネントを使用する場合、あるコンポーネントの値を別のコンポーネントに直接ワイヤリングするという通常の方法は使いません。代わりに、コンテキスト上重要な値を最初のコンポーネント上のプロパティーから集約コンポーネント上のアクションにワイヤリングし、次に集約コンポーネント上の対応するプロパティーから宛先コンポーネントのアクションにワイヤリングします。単一ページ上で行われる通常の操作はすべて、同様に進行します。最初のコンポーネント上でのプロパティー変更は、集約コンポーネントを介してターゲット・コンポーネントに伝搬されます。ただしページ移動中に宛先ページが表示されると、集約コンポーネントは既知の値をすべてパブリッシュします。これにより、宛先ページ上のすべてのターゲット・コンポーネントは集約コンポーネントから接続されるワイヤーとともに更新されます。

例えばセールス・トラッキング・アプリケーションでは、現在の会社名、セールス・リード、営業担当員をトラッキングする必要があります。あるページでは、会社の詳細情報と営業担当員のリストを表示します。営業担当員を選択するとポップアップ・ウィンドウが開き、電話番号や電子メール・アドレスなど、その担当員の詳細情報が表示されます。新規セールス・リードの作成を選択することも可能です。これを選択すると同一コンポジット・アプリケーション内の別のページに移動します。しかし、会社名と関連する営業担当員のフィールドを、現在の値を基に定義済みの状態で表示させたい場合、単純なページ間ワイヤーでは対応できません。

このような要求に対応するためには、最初のページに集約コンポーネントを導入します。会社名と営業担当員の選択を受け持つコンポーネントは、集約コンポーネントを介した経路でワイヤリングします。次に、同一集約コンポーネントにある別のインスタンスを 2 番目のページに設定し、そのページ上でセールス・リードを作成します。次に、現在選択している会社および営業担当員のプロパティーを対応する入力フィールドにワイヤリングします。ページが切り替わると、集約コンポーネントがそれを検知してプロパティーを投入し、フォームを定義済みの状態にします。

その他のコンポーネント・パターン

今後数カ月にわたって掲載が予定されているこのシリーズ記事で、情報コンポーネント、編集モード・コンポーネント、概要コンポーネント、リスト・コンポーネント、コンストレインド・リスト・コンポーネントについて、詳しく解説します。その記事は Lotus Notes のコンテキストを基に解説するものですが、ここで取り上げるパターンはあらゆる形態のコンポーネント開発に応用できます。

上に戻る

レイアウト・パターン

このセクションでは、レイアウト・パターンについて解説します。

拡散型ダッシュボード

コンポジット・アプリケーションでは、現在作業しているプロセスのコンテキストに関連情報を追加することが可能ではあるものの、中央のアクティビティーに注意を集中できるようになることも必要です。この 2 つの必要性のバランスを取るためには、このページの主要アクティビティーに必要な主要コンポーネントをページの中央スペースに配置するパターンを使用するというのが 1 つの方法です。これらの主要コンポーネントは、通常はドメイン・セントリックのコンポーネントであり、個々のレコードおよびデータの集合体の表示、操作、処理を行います。

次にドメイン・コンテキストに沿った他のコンポーネントを画面の周辺に配置し、中央の操作に追加の情報やコンテキストを提供します。このダッシュボードは、設計上のニーズに応じて中央の主要エリアの左側、最下部、右側、あるいは最上部などにまとめることができます。複数のコンポーネントをフォルダーに収めることもできます。これは、画面上の表示面積を管理し、すぐにアクセス可能なさまざまな情報を提供する有効な方法であり、レイアウト上で広い面積を占有することもありません。また、必要になるまでは最小限の UI しか表示しないポップアップ・コンポーネントを使用することもスペースの管理に効果的です。

このような拡散型ダッシュボード・ページのワイヤリングは、比較的単純です。一般的には、一部のデータ・ソースをコンテキストが確立されている場所 (例: ユーザーの選択、ページ間ワイヤー、集約コンポーネントなど) からドメイン・セントリックの主要コンポーネントへワイヤリングすることができます。さらに、その主要コンポーネントからダッシュボードへと多数のワイヤリングが行われ、表示するデータのインデックスに必要なキーを提供します。

Lead Manager アプリケーションにもこのレイアウトで配置されているページがいくつかあり、特に「Sales Lead Details」および「Company Details」ページは顕著です (図 1 参照)。画面中央のエリアには、注目している基本レコードの詳細を表示するコンポーネントが配置されています。ダッシュボードにはタブ付きフォルダーが格納され、その中には基本レコードに関連する追加情報セットが含まれています。

図 1. 企業の詳細情報

読み取り専用モードで「Info」ボタンをクリックすると、詳細情報を表示するポップアップ・コンポーネントが起動されます (図 2 参照)。編集モードではポップアップ・コンポーネントは選択コンポーネントになり、作成を補助します。

図 2. 「Company Details」ページでポップアップ・コンポーネントが起動されている状態

リスト・ページ

リスト・ページは、さまざまなデータ・レコードに基づいて集約情報を表示するよう設計されています。このページの中央エリアは、通常リストまたはコンストレインド・リスト・コンポーネントで構成され、データ・レコードのリストをソートまたは表示するための多様な手法を提供します。また、これを補うために追加の情報コンポーネントがあり、表示あるいは選択されているレコード全体について概要情報を提供します。Help Desk アプリケーションでは、リスト・コンポーネント中の特定の従業員についてコール・ログを表示することができ、また情報コンポーネントによって、表示されているコールの平均コール回数をリストで表示できます。会計アプリケーションでは、あるアカウントの取引リストを作成でき、概要コンポーネントにより、表示されている取引の取引総額をリスト表示できます。

選択ページ

選択ページはリスト・ページを変形したものです。リスト・ページでは集約情報が表示され、情報セット全体を把握することができます。選択ページでも、特定のデータ要素のズームインへのステップとして、集約情報を表示することができます。そのために、他のエリア (拡散型ダッシュボードなど) に関する詳細情報を表示するページへ誘導する UI のページを作成することが可能です。

選択ページは、1 つ以上の選択コンポーネントで構成されることがよくあります。これらのコンポーネントにより、ユーザーはコンストレインド・リスト・コンポーネントを使用してデータ・セットを表示するための基準を選択できます。さらに、コンストレインド・リスト・コンポーネントでの選択またはフォーカスの状態が情報コンポーネントのダッシュボードに与えられ、より詳しい情報の提供やより詳細な選択を可能にします。このように十分な情報に基づき、詳細表示するデータの”インフォームド・チョイス”が完了したら、ボタンのクリック、またはマウスの左ボタンのダブルクリックなどによって選択内容をアクティブにし、コンテキストを設定して適切なページに切り替えます。単純なコンテキストの場合はページ間ワイヤーによってこの設定を行うこともできますが、そうでない場合には集約コンポーネントとページ切り替えコンポーネントを使用してこのアクションを実行します。

選択ページのワイヤリングは、拡散型ダッシュボードのページのワイヤリングよりも多少複雑です。選択コンポーネントはコンストレインド・リストにワイヤリングされている必要があり、そのリストがダッシュボード・コンポーネントにワイヤリングされます。複数の選択肢あるいは複数のリストが存在する場合には、並列ワイヤーを多数作成し、制御がアクティブ化されたときのデータ・フローが正しくなるようにしなくてはなりません。

注: タブ付きのフォルダーを使用するときには注意が必要です。例えば、タブなしの情報コンポーネントがタブ付きのコンストレインド・リストにワイヤリングされている場合、情報コンポーネントが表示された選択に関連する情報を確実に表示するために、リストの選択が変更されたときだけではなく選択が表示されたときにも、それらのリストによって選択状態がブロードキャストされなければなりません。

Lead Manager アプリケーションでは、「Sales Leads」ページ (図 3 参照) は「Selection Page」のレイアウトを使用して配置されています。画面左側に Lead Browser コンポーネントが配置され、複数の選択モードを表示できるようになっています。企業 (売上高や活動分野などでソートおよび選択されたもの) をリストで表示でき、特定の企業のセールス・リードをリストで表示することも選択できます。また、営業担当員をリスト表示して、各担当員が担当するセールス・リードをリストにすることも可能です。これはすべて右側のコンストレインド・リスト・コンポーネント群に送られ、このコンポーネント群が処理中および終了したセールス・リードを表示します。これらリードの表示は、リード・ブラウザーでの選択により制約され、さらにリードの状態によっても制約されます。

これらのコンポーネントで選択が更新されると、画面最下部の情報コンポーネントが、選択されたリードとそのリードが属する企業の概要を提供します。あるリードをダブルクリックすると、ページ間ワイヤーによってそのリードの情報が伝搬され、リードの詳細情報のページへのページ変更が起動されます。

図 3. 「セールス・リード」ページ

レコード表示ページ

これは、特定のレコード・タイプの詳細情報専用のページです。主要表示エリアに、そのレコード・タイプの詳細情報が表示されます。ダッシュボード・エリアには追加のコンポーネントが配置され、そのデータ・レコードに関連する補足情報を提供します。

Lead Manager アプリケーションでは、「Company Details」画面がこのパターンで配置されています (図 1 参照)。画面の中央エリアに、企業レコードの完全な詳細が表示されます。ダッシュボードにはタブ付きのフォルダーが格納され、そのフォルダー内に、その企業のリード、同社に関するディスカッション、同社の企業 Web ページなどを表示するコンポーネントが含まれています。「Info」ボタンをクリックすると、さらに詳しい情報を格納するポップアップ・コンポーネントが起動されます (図 2 参照)。

レコード編集ページ

このページは、当該レコードが準備中である点を除けば、レコード表示ページと同じです。レコードの値が不完全あるいは作成中であるため、関連データのダッシュボードはこの時点では意味がありません。代わりに、ダッシュボードにはレコードの作成を補助するコンポーネントが含まれています。例えば、企業データベースにインデックスを付け、従業員が入力されるよう要求するフィールドにリンクさせる選択コンポーネント、最近の電子メールを表示して連絡先フィールドの作成を可能にするコンポーネント、現在の Web アドレスを該当するフィールドにインポートする機能を備えた一般検索用 Web ブラウザーなどがあります。

必要に応じて、レコード表示ページとレコード編集ページを 1 つのページに作成することが可能です。この方法にはレコードの詳細を固定形式で常に表示しておけるという利点がありますが、一部の情報コンポーネントが読み取り専用モードまたは編集モードにのみ関連している場合には、それらのコンポーネントの有効化や表示が正しく行われるように注意する必要があります。

上に戻る

アプリケーション・パターン

このセクションでは、アプリケーション・パターンについて解説します。

データ中心

データ中心のアプリケーションは、管理されているデータに焦点を置きます。このアプリケーションを設計するには、対象となる情報ドメインから多数の基本データ・レコードを選択します。リスト・ページを構成して、データ・レコード群についての集約情報を表示します。レコード表示ページは、対象となるレコード・タイプごとに作成でき、またレコード編集ページも作成または編集されるレコード・タイプごとに作成できます。これらのページをまとめて 1 つのツリーとして構成できます。リスト・ページがブランチとなり、レコード・ページがリーフとなります。組み込みのコンポジット・アプリケーション・ナビゲーターを使用すればページを切り替えることができ、ページ間を移動しても集約コンポーネントではコンテキストを維持できます。また、ページをアクティブ化してコンテキストを確立するページ間ワイヤーを使用することにより、リーフ・ページをナビゲーションから隠すこともできます。

Lead Manager サンプル・アプリケーションは、主にこのパターンに従って設計されています。編集モードを利用できるため、「Sales Leads」、「Companies」、「Contacts」、「Discussions」、「Contracts」をリスト (例えば、選択ページなど) または個々のエンティティー (例えば、レコード表示ページなど) として表示することが可能です。これらの主要エリアには最高水準のアクセスが提供されており、このエリアからさらに掘り下げて詳細情報にアクセスできます。相互リンクもサポートされ、必要に応じてある詳細コンテキストから別のコンテキストに移動することが可能です。Lead Manager サンプル・アプリケーションでは、「Leads/Companies」、「Discussions」、「Contracts」、「Contacts」というまったく異なるアプリケーション・ドメイン間で相互リンクが可能になっています。

プロセス中心

プロセス中心のアプリケーションは、個別のデータではなく、あるタスクの遂行に焦点を置きます。各従業員の役割のワークフロー・シナリオに従ってアプリケーションの一連のページを作成し、従業員が割り当てられた業務を遂行できるようにします。例えば、販促用カタログ作成を管理するアプリケーションでは、目的や定義の設定、制作代理店の選定、代理店の作業の管理と承認、制作物のアーカイブなど、さまざまな段階を追ってワークフローが進行します。

すべてのケースについて、同一のデータ・レコード・セットを使用できます。目的と定義の設定段階では、関係者がキャンペーンの定義を検討する場であるディスカッション・エリアまたはアクティビティー・セットに、キャンペーン・レコードをリンクできます。代理店検索段階では、過去に定義済みの目的を検索のキーワードに取り入れるコンポーネントを使用や、過去に使用したことのある代理店についてのフィードバックをリスト表示するディレクトリー・コンポーネントを使用できます。プロジェクトの管理では、メール・データベースを使用して、やり取りのトラッキングや承認の管理が可能です。最後にアーカイブ段階では、過去のキャンペーンの集約リストや、それらのキャンペーンで制作された資産との連携が必要になることがあります。

プロセス中心のアプリケーションの場合、一連のページは現在行われている作業や基本レコードのワークフローの状態に合わせたものとなります。それぞれ役割が異なる従業員は、各自に関連するページのみを閲覧します。これは、WebSphere Portal でデプロイされたアプリケーション上で、コンポジット・アプリケーションのページに対するアクセス権を設定することによって可能になります。この方法は、NSF でデプロイされたコンポジット・アプリケーションでは使用できません。そのようなアプリケーションでこれを可能にするには、役割ごとに別のコンポジット・アプリケーションを作成し、その役割に必要なページのみをそのコンポジット・アプリケーションに含める、というのが最も簡単な方法です。

実際、コンポジット・アプリケーションが優れている点の 1 つとして、比較的少ない作業で、特定のエリアに焦点を絞ったさまざまなアプリケーションを作成できるということがあります。コンポーネントを再利用できるため、再開発や再デプロイの多くの作業をせずに、生産性を向上させる関連アプリケーションのメリットを享受できます。

ここで解説したとおり、Lead Manager サンプル・アプリケーションではデータ中心のアプリケーションのパターンを利用しています。また、Lead Manager サンプルの多くのコンポーネントを再利用して、プロセス中心のアプリケーション・パターンを活用した新しいコンポジット・アプリケーションを作成することも可能です。例えば、契約関連プロセスを管理するアプリケーションなどを作成できます。あるセールス・リードの所有者がそのリードについての契約書を作成すると、法務部門がそれを検討し、次に顧客が検討します。コンポジット・アプリケーションでこの検討プロセスを定義および支援できます。

集約モデル

集約アプリケーションは複数のプロセスを 1 つにまとめるアプリケーションですが、ほとんどの場合、それらは画面上に集約されます。その利点の 1 つとして、ユーザーの業務遂行に必要なすべてのツールを 1 カ所で提供できるという点があります。これは相互協調処理をほとんど必要としない軽度の統合ですが、素早く容易に開発でき、ユーザー用ツールの統合計画の第一段階となります。コンポジット・アプリケーションについてチームの習熟度が高まれば、集約アプリケーションを利用してコンポジット・アプリケーションの利点を広範なユーザーに提供することができます。

相互協調処理をどの領域に導入すれば有効であり、ユーザーのプロセスに役立つかという点について、ユーザーのフィードバックを求めるとよいでしょう。これにより、一連の分割手法を進めることができます。まずアプリケーション全体をカプセル化する単一のモノリシック・コンポーネントを作成し、ユーザーのニーズに応じて、このコンポーネントのパーツをどこにでも表示できるより小規模な複数コンポーネントに分割します。

集約パターンは、Lead Manager サンプル・アプリケーションの開発にあたり最初に使用されています。ユーザーは「Leads/Companies」、「Discussions」、「Contracts」、「Contacts」という 4 つのアプリケーションと対話します。コンポジット・アプリケーションのメリットが最初に発揮されたのは、これら個別の NSF アプリケーションを複数ページ持つ単一のコンポジット・アプリケーションにアセンブリーしたときです。それまで個別のものであった複数アプリケーションが、コンポジット・アプリケーションによりグループ化されました。

上に戻る

まとめ

この記事で解説したパターンは、作成される可能性のあるコンポジット・アプリケーションおよびコンポーネント・パターンのサブセットにすぎません。コンポーネント、レイアウト、アプリケーション別に分類されていますが、ユーザーの役割によっては、すべてを適用できるとは限りません。すべてのパターン・カテゴリーの概要をまとめ、どうすれば他の人々がコンポーネントを使用してアプリケーションをアセンブリーできるかを理解するとよいでしょう。

これらのパターンの多くは Lead Manager サンプルや他のコンポジット・アプリケーションの開発に役立つことが理解できたと思います。すでによく知っているパターンもあるかもしれませんが、さまざまな開発パターンを学習することは、一貫性のあるルック・アンド・フィールを備えた、テスト済みの手法とコンポーネントに基づくアプリケーションの作成に役立ちます。

コンポジット・アプリケーションの分野を研究することで、自分が直面する問題に対して別の解決方法が見つかることもあります。そのことに注意して、同様の問題の解決に何度も利用されて効果をあげている手法を探し、自分自身のパターン・ライブラリーの作成に取り組んでください。

参考文献

学ぶために