マッシュアップのビジネス・シナリオとパターン: 後編

この記事は、ビジネス・ニーズの解決に向けてエンタープライズ・マッシュアップをデプロイするために利用できる活用パターンとアーキテクチャー・パターンの関係について説明する 2 部構成の後編 です。(原文公開日 : 2009年2月3日)

Holt Adams, Executive IT Architect, IBM

Holt Adams は、IBMソフトウェアのEmerging TechnologyグループのExecutive IT Architectであり、現在、IBMのjStart ProgramおよびCustomer Innovation Teamをサポートしています。そのスキルにより、ソリューション・アーキテクトおよびエンゲージメント・マネージャーの役割を担い、お客様が最新のインターネット技術を採用するための支援に効果的かつ熱心に取り組んでいます。また、カスタマー・エンゲージメントに関してビジネスおよびテクニカルの両面で専門家としての経験もあり、リード生成、ビジネス的価値訴求、要求管理、ソリューション・アーキテクチャー、ソリューション設計、および契約交渉などに携わりました。さらに、ITアーキテクトとしてお客様の業務要件をIT要件に読み替え、それを最新のITを活用した最先端のソリューションとして構築、解決に導いています。jStart Programおよび他のサービス経験を通じて得た技術的バックグラウンドには、ワイヤレス/パーベイシブ・コンピューティング、インターネット・インフラストラクチャー、Java/J2EE、XML、Webサービス/SOA、オープン・ソース、Web 2.0、ソーシャル・ネットワーキング、およびエンタープライズ・マッシュアップなどのテクノロジーがあります。



2009年 6月 12日

この記事では、最初の記事「マッシュアップのビジネス・シナリオとパターン: 前編」で述べたビジネス・シナリオおよび活用パターンを実装するために用いられるソリューション・アーキテクチャーとアーキテクチャー・パターンについて解説します。

企業ニーズの解決に向けたマッシュアップの使用は採用曲線に沿って進展し、今では指数関数的な成長率を示しています。このテクノロジーは多くの業種で活用され、一般的な活用パターンとアーキテクチャー・パターンを利用して固有のビジネス・シナリオが解決されています。

また、ある業種に用いられたソリューションが、同様のニーズを持つ他の業種にそのまま応用されるケースもあります。マッシュアップ・ソリューションごとに異なるのは、ユーザーの役割と、集約されて固有な値を生み出すデータ・セットです。多くの場合、活用パターン(たとえば、検索条件の取得、ユーザー・インターフェース (UI) 内でのデータのレンダリング、1 次データ選択に基づく 2 次テーブルの更新、データの操作、および他の人々とのコミュニケーション) は類似していますが、達成するビジネス目標が顧客ごとに異なっています。

マッシュアップの設計およびアーキテクチャー・オプションは、実装用に選択されたマッシュアップ・プラットフォームによって決められます。一般的な活用パターンを数多く活用するビジネス・シナリオも、少数の設計またはアーキテクチャー・パターン (たとえば、RSS および ATOM フィードの使用、REST サービスの呼び出し、パブリッシュ/サブスクライブ・モデルを介したウィジェット通信、集中化されたハブを通じたデータ・ソースの集約、およびデータとサービス・ソースでのデータのフィルタリング) を使用するだけで実装できます。

はじめに

IBM® Emerging Technology チーム (jStart) は過去数年間、50 を超えるお客様およびビジネス・パートナーとともに作業し、ビジネス・ニーズの解決に向けて 検証・試行環境でさまざまなマッシュアップ・テクノロジー (たとえば、QEDWiki と IBM Mashup Center) を活用し、このテクノロジーの有用性を検証してきました。前編でも解説したように、jStart チームの経験により、このテクノロジーの一般的なシナリオとソリューションの実装が得られ、正式な研究成果として文書化されています。これらの成果物は初期採用者たちによって使用され、エンタープライズ・マッシュアップの価値提案を促進するとともに、この連載記事の基礎となっています。

すべてのソリューション開発の規律として、資産 (方法論、設計概念、コンポーネントなど) の再利用は一般的な手法であり、効率化を促進し、開発コストと期間を削減するために推奨されています。これらの資産を一般的で繰り返し可能な方法で再利用するとき、これをパターンと呼ぶことがあります。パターンという用語自体は一般的なものであり、ビジネス・シナリオを説明するために単独で使用したり、対話的な使い方、アーキテクチャー設計、および実装という用語と組み合わせて使用したりすることができます。


活用パターンとアーキテクチャー・パターンに対するビジネス・シナリオ

この連載の前編では、ビジネス目標とシナリオについて説明しました。これには、複数の業界で使用されるカスタマー・サービス、リソース管理、パーソナル・ダッシュボード、パーソナル・コミュニケーションズ、コンシューマー・サービス、エンタープライズ・リソース・ロケーター、フィールド・サービスのサポート、サプライ・チェーン・マネジメントなどのシナリオが含まれています。これらのシナリオは、特定のビジネス目標を達成するハイレベルのビジネス活動として記述されています。シナリオを実現するには、ビジネス・ユーザーがこの連載記事で活用パターンと呼んでいる一般的な方法を用い、特定のテクノロジーとの対話を通じてタスクを実行する必要があります。前の記事で概説した活用パターンには、個人がマッシュアップ・インターフェースの機能またはコントロールを使用しながら実行した一般的な手順 (たとえば、マッシュアップへのログイン、検索条件の入力、表からのデータ選択、イメージ上へのマウス移動、データ・レコードの更新と追加) が含まれます。ユーザーがマッシュアップ内に表示されたコントロールまたはデータと対話すると、実行したアクションによっては、マッシュアップによる処理が行われることがあります。この処理には、UI 自体のレンダリングの変更 (たとえば、ナビゲーションおよびコントロールの表示/非表示)、他のベンダーから取得したサービスまたはデータ・ソースの呼び出し、マッシュアップ内での追加情報およびイメージの表示などがあります。

図 1. シナリオとパターン
シナリオとパターン

マッシュアップ・アプリケーションによってサポートされている動作および対話の実装は、基盤であるアーキテクチャーの影響を受けます。マッシュアップ・アプリケーションはウィジェットと呼ばれるコンポーネントで構成されます。コンポーネントは相互にリンクされて UI とモデルを形成し、ユーザーによる表示および操作が可能なデータを集約します。これらのウィジェットは、UI をレンダリングするために表示することも、バックグラウンドの処理を実行するために非表示にすることもできます。同様に、表示されているウィジェットも、バックグラウンドの処理を実行または開始できます。

ウィジェット間のリンク (プログラマチックな結合または通信) は、マッシュアップ・アプリケーションが対話的で応答性のあるエクスペリエンスをユーザーに提供するメカニズムです (たとえば、あるウィジェットのコントロールをクリックすると、他のウィジェット内のデータが更新される、または UI 内に別のウィジェットがレンダリングされるなど)。リンクの定義および実装方法は、マッシュアップ・アプリケーションのプラットフォームに依存します。

アーキテクチャー・パターンの実装方法もプラットフォームの影響を受けます。このトピックについては、この記事で解説します。中心となるインフラストラクチャー・パターンには、パブリッシュ/サブスクライブ・メッセージングとセキュリティーが含まれます。他のアーキテクチャー・パターンにより、データの取得、集約、およびデータのフィルタリングを実装する一般的な方法が定義され、それ以外にも、外部システム (たとえば、認証用のユーザー登録) を統合するための設計の概要が決められます。

これらのアーキテクチャー・パターンがもたらす設計により、連載の前編 で説明した活用パターンが実装され、マッシュアップの動作とユーザー対話が有効になります。まとめると、前編の活用パターンは、図 2 に示す対話モデルをサポートするために、以下のように分類されます。

  • アクセス制御とパーソナライゼーションのパターン
  • マッシュアップ UI のレンダリングとデータ取得のパターン
  • データのレビューと操作のパターン
  • 他の人々とのコミュニケーションのパターン
図 2. 初期採用者の対話モデル

ほとんどのビジネス・シナリオは、ビジネス目標、ユーザーの役割、データ、または業種での焦点にかかわらず、図 2 に示す対話モデルで表すことができます。


アーキテクチャー・パターン

一般に、マッシュアップ・アプリケーションは、ブラウザー内にレンダリングされたアプリケーション・ウィジェット・コンポーネント (たとえば、WAR ファイルとしてパッケージ化された関連ウィジェットとともに HTML ページとしてデプロイされたもの) の軽量の統合として特徴付けられます。アーキテクチャー・パターンは、マッシュアップ・アプリケーションを構築するハイレベルの設計を提供し、ソリューション・コンポーネント間のイベントのフローを表示します。アーキテクチャー・パターンはプラットフォームにある程度依存し、前のセクションで説明した活用パターンを通じて実現される 1 つ以上のビジネス・シナリオを実装するフレームワークをもたらします。

IBM Mashup Center

IBM Mashup Center は、これまでに概説したビジネス・シナリオと活用パターンを実装するために使用されてきました。IBM Mashup Center は、IBM Lotus® Mashups、IBM InfoSphere™ MashupHub、IBM Lotus Widget Factory、および共有リポジトリー (カタログ) で構成されています (図 3 参照)。

図 3. IBM Mashup Center
IBM Mashup Center

Lotus Mashups および InfoSphere MashupHub のどちらにも、マッシュアップ・アプリケーションとそのコンポーネントを作成および管理するブラウザー・ベースのツールがあります。また、Lotus Widget Factory により、Lotus Mashups にデプロイし、InfoSphere MashupHub に登録するウィジェットを作成する環境が得られます。Lotus Mashups には、マッシュアップ・アプリケーション (ウィジェットはブラウザー内でマッシュされ、相互にワイヤリングされます) を作成するためのマッシュアップ・アセンブラーと、マッシュアップ・アプリケーションをデプロイおよび運用するための軽量マッシュアップ・サーバーが用意されています。マッシュアップ・サーバーは、マッシュアップ・ランタイムを提供するブラウザーにマッシュアップ・イネーブラーをロードします。マッシュアップ・ランタイムでは、稼働時にマッシュアップ・コンポーネントが実行および管理されます。InfoSphere MashupHub は、インターネット、企業システム、部門サーバー、および個人所有の各情報を共有する環境をマッシュアップ・アプリケーションにもたらします。ハブは、マッシュアップ・アプリケーションが使用するフィードとフィード・マッシュアップを作成する機能を持っています。これらの 3 製品は、いずれも HTTP、JSON、XML、Java™Script、Atom、およびRSS などの Web テクノロジーを使用し、関連するコンテンツをユーザーに提供します。

図 4. IBM Mashup Center のアーキテクチャー
IBM Mashup Center のアーキテクチャー

図 4 では、フィード作成、データ・マッシュアップ、およびカタログの各コンポーネントが InfoSphere MashupHub によって提供され、ユーザーはウィジェット、マッシュアップ・ページ、およびイントラネット内またはインターネット上でアクセス可能な既存のフィードを登録できます。同様に、InfoSphere MashupHub は、シンプルなブラウザー・ベースの UI を使用して構築されたフィードおよびフィード・マッシュアップの作成と登録を有効にします。この UI では、操作と機能が視覚的に定義され、企業、部署、および個人の各データ・ソースから抽出したデータを集約および変換できます。さらに、ブラウザー・ベースのツールにより、マッシュアップの作成者は登録済みフィードとウィジェットを発見および共有し、Lotus Mashups 内でのマッシュアップ・アプリケーションの作成に利用できます。作成したマッシュアップ・アプリケーションをカタログに保存することにより、他のユーザーがそのマッシュアップ・アプリケーションを発見し、使用できるようになります。

マッシュアップ・アプリケーションのデプロイに関し、Lotus Mashups には軽量のマッシュアップ・サーバーが含まれているのに対し、InfoSphere MashupHub にはフィード生成コンポーネントと変換エンジンが含まれています。マッシュアップ・サーバーは、マッシュアップ・アプリケーションにアクセスするためのマッシュアップ URL のターゲットであり、ページとそれに関連するウィジェットをブラウザーにロードします。ウィジェットが InfoSphere MashupHub に登録されたフィードにアクセスするときは、フィード・ジェネレーターがカタログにアクセスし、データ・ソースとのインターフェースのために必要なメタデータを取得します。フィード・ジェネレーターはこのメタデータを使用してデータ・ソースにアクセスし、1 つ以上のソースからデータが集約または変換された時点で変換エンジンを呼び出します。

jStart ソリューションのアーキテクチャー

図 5 は、jStart チームが初期採用者のマッシュアップ・ソリューションを実装するために使用した論理ソリューション・コンポーネントを示しています。緑色の陰影を付けたコンポーネントは、前の記事とアーキテクチャー・パターンで説明したコンポーネントに追加されたソリューション・コンポーネントを表します。

図 5. ソリューション・アーキテクチャーの概要
ソリューション・アーキテクチャーの概要

アーキテクチャー・パターンで使用される論理ランタイム・コンポーネントは以下のとおりです。

  • ブラウザー・マッシュアップ・ランタイム (マッシュアップ・イネーブラーを通じて実現されます)。ブラウザー内のマッシュアップ・ランタイムは、ウィジェットで構成されるマッシュアップ UI をレンダリングし、ウィジェット、データ・ソース (企業または公開)、および他のベンダーから取得したサービス間の対話とリンクを管理する JavaScript フレームワークを提供します。ウィジェットは、ブラウザー内でロードおよびレンダリングされた後、ブラウザー・マッシュアップ・ランタイム・コンポーネントの一部とみなされます。
  • マッシュアップ・サーバー (Lotus Mashups 軽量マッシュアップ・サーバーを通じて実現されます)。マッシュアップ・サーバー・コンポーネントは、マッシュアップ・アプリケーションをデプロイおよびホスティングするためのランタイム・インフラストラクチャーをもたらします。ブラウザーからサーバーにマッシュアップ・アプリケーションを呼び出した後、マッシュアップ・サーバー・コンポーネントはサーバー・サイドのコンポーネントをロードし、ブラウザー・マッシュアップ・ランタイム・コンポーネントおよび関連するウィジェットをブラウザーに送信します。

    マッシュアップ・サーバーの一部である 2 つのサブコンポーネントとして、仮想メンバー・マネージャー(VMM:Virtual Member Management)・サブコンポーネントとAJAX HTTP プロキシー・サブコンポーネントがあります。jStart の実装では、これらの 2 つのコンポーネントは、Lotus Mashups がデプロイされている WebSphere® Application Server によって実際に提供されます。

    • 仮想メンバー・マネージャー。このサブコンポーネントは抽象化のレイヤーを追加し、ユーザーの認証をセキュリティー・システム (たとえば、WebSphere Application Server セキュリティー) に委任します。セキュリティー・システムでは、仮想メンバー管理データベース、ローカル・オペレーティング・システム、LDAP、またはカスタム・ユーザー・レジストリーを使用して、ユーザーのクレデンシャルを認証できます。
    • AJAX HTTP プロキシー。このサブコンポーネントにより、ブラウザー・マッシュアップ・ランタイム・コンポーネントで実行されているウィジェットが、マッシュアップ・アプリケーションがロードされているドメインとは別のドメインにアクセスできるようになります。ブラウザーは「同一オリジン」ポリシーを実施することにより、JavaScript などのクライアント・サイドのスクリプト (ウィジェットのベースとなるスクリプト) が、異なるプロトコル、ドメイン名、またはポートを持つオリジンからコンテンツをロードすることを防止しています。この論理コンポーネントは、WebSphere Application Server HTTP プロキシーを使用して実現されます。
  • フィード・データ・ソース。RSS または Atom 形式がサポートされる XML データを提供するシステムは、フィード・データ・ソース・コンポーネントとみなされます。これらの形式および関連プロトコルは、頻繁に更新されるコンテンツをシンジケートするために使用されます。
  • エンタープライズ・データ・ソース。この記事では、シンジケーション・フィードをサポートしないエンタープライズ・システムは、シンジケーション・データ・ソースと区別するために、既存のシステムとみなします。これらのシステムは業務別または部署内で使用され、マッシュアップ・アプリケーションに統合される重要なデータソースです。これらのシステムの例として、Microsoft® Access、IBM DB2®、LDAP、IBM Lotus Domino®、IMS、および SAP があります。また、XML、CSV、および Microsoft Excel でフォーマットされたファイルも重要な情報のソースであり、マッシュアップ内で使用されます。
  • マッシュアップ・ハブ (InfoSphere MashupHub を通じて実現されます)。マッシュアップ・ハブ・コンポーネントは、IT およびビジネス・プロフェッショナルのために、エンタープライズ・データ (Web 2.0 アプリケーションおよびマッシュアップで使用される Web、部署、個人、および企業の各情報を含む) をロック解除し、共有するための情報管理環境を提供します。マッシュアップ・ハブ・コンポーネントはこれらのデータ・ソース (たとえば、RSS、Microsoft Access、IBM DB2 XML、LDAP、Lotus Domino、IMS、SAP、CSV、XML、および Microsoft Excel) とのインターフェースとして機能し、Atom フィードを作成します。同様に、ハブは 1 つ以上のデータ・ソースからデータを集約、変換 (つまり、フィルタリングまたは再構成のために演算子および関数を適用すること)、またはソートし、統合化された Atom フィードを作成できます。これをフィード・マッシュアップと呼びます。
  • ユーザー・レジストリー。このコンポーネントは、Web リソースへの認証および認可を付与するユーザー・アカウント情報 (ユーザー ID とパスワード、アクセス権、および役割など) を維持するためのリポジトリーです。
  • サーブレット。このコンポーネントは Java サーバー・サイド・コンポーネントです。このコンポーネントにより、ブラウザーで実行されているウィジェットが、マッシュアップ・アプリケーションの機能を拡張するために、Web サーバーにデプロイされているコンポーネントおよびアプリケーション (たとえば、IBM Lotus Sametime® サーバー) の Java API にアクセスできるようになります。

この記事で概説したビジネス・シナリオおよび活用パターンをサポートするために、次のアーキテクチャー・パターンが使用されています。

  • パターン 1: ユーザー・ログイン (認証と認可)
  • パターン 2: 2 次データ・ビューをともなう単純な問い合わせ
  • パターン 3: 集約された 2 次データ・ビューをともなう問い合わせ
  • パターン 4: 他のベンダーから取得したサービス集約をともなう問い合わせ
  • パターン 5: データ・ソースへのデータ更新をともなう問い合わせ
  • パターン 6: チーム・コラボレーション

以下のシーケンス図で参照されているのに、この記事では明確に触れていない 1 つのパターンとして、ウィジェット間のパブリッシュ/サブスクライブ・メッセージングがあります。この低レベルのパターンはマッシュアップ・ブラウザー・ランタイム・コンポーネント内に実装され、ウィジェット間をリンクするために、ウィジェットがイベントをパブリッシュおよびサブスクライブできるようにします。ウィジェット間の連続イベント (たとえば、イベント・ストーム) を最小限にする、または防止するときは、固有のパラメーターを持つ多数のイベントよりも、一般的な共有パラメーターを持つ少数のイベントを使うようにすることが重要です。また、ウィジェット間のイベント・フローの詳細なシーケンス図を開発し、イベントの使用と共通データの通知を最適化するとよいでしょう。

パターン 1: ログイン (認証と認可)

マッシュアップ・サーバーは、マッシュアップ・アプリケーションへのエントリー・ポイントとして、各ユーザーの認証と認可を行う役割を持ちます。このステップは、マッシュアップ・サーバーによって直接実行するか、マッシュアップ・サーバーがデプロイされているインフラストラクチャーで実行できます (図 6 参照)。Lotus Mashups の場合は、IBM WebSphere Application Server の仮想メンバー管理 (VMM) コンポーネントを使用して、ユーザーおよびユーザーのグループを VMM データベース内で定義できます。同様に、WebSphere Application Server によってサポートされているローカルのオペレーティング・システムのレジストリー、LDAP ディレクトリー、またはカスタム・ユーザー・レジストリーも、Lotus Mashups による認証と認可のために活用できます。

図 6. パターン 1 のシーケンス図

複数のユーザー・レジストリーを活用してマッシュアップ・アプリケーションをセキュアにする必要がある場合は、WebSphere Application Server のフェデレーテッド・リポジトリー機能を使用して、ユーザーとグループを管理できます。

マッシュアップ・アプリケーション自体へのアクセスをセキュアにすることに加え、マッシュアップ・アプリケーションによって使用される特定のデータ・ソースまたはサービスにアクセス制御を施すことができます。マッシュアップ・アプリケーションが、他のベンダーから取得した保護されたデータ・ソースまたはサービスを統合するとき、これらのシステムへのアクセスにはクレデンシャルが必要です。データ・ソースごとにユーザーを認証しなければならないことを防ぐために、シングル・サインオン手法を活用できます。WebSphere Application Server では、最初の認証時にセキュリティー・トークン (LTPA トークン) が生成され、ブラウザーに返されます。それ以降、ウィジェットからサーバー・サイドのデータ・ソースおよびサービスへの要求には、このトークンが使用されます。LTPA トークンにより、WebSphere Application Server はユーザーへの許可を実行し、WebSphere Application Server によって保護されている Web リソース (たとえば、RSS、Atom、サーブレット、REST サービス、Web サービス) へのアクセスを制御できます。

データ・ソースまたはサービスが WebSphere Application Server セキュリティー・ドメインの外部にある場合は、既存のフィードを登録するか、非シンジケーション・データ・ソース用の新規フィードを作成することにより、マッシュアップ・ハブでセキュリティー・クレデンシャル (たとえば、ユーザー ID とパスワード) を取り込めます。どちらの場合も、必要なクレデンシャルを含むフィード用のメタデータが作成されます。マッシュアップ・アプリケーション内のウィジェットがマッシュアップ・ハブを通じてフィードを呼び出すと、適切なクレデンシャルが要求に追加され、データ・ソースまたはサービスをホスティングしているバックエンド・システムが認証と許可を実行できるようになります。このレベルのセキュリティーについては、他のパターン図のところで後述します。

パターン 2: 2 次データ・ビューをともなう単純な問い合わせ

図 7 に示すアーキテクチャー・パターンは、複数のデータ・セットに対し単純な照会をできるという点で最も基本的なものです。ユーザーがマッシュアップ・サーバーにログインすると (詳細な対話は示されていません)、マッシュアップ・サーバーは、検索フォームを含むマッシュアップ・アプリケーションの UI をレンダリングするために必要なウィジェットを返します。ユーザーが検索条件を入力し (キーワード、ラジオ・ボタン、チェック・ボックス、またはメニュー選択)、検索要求を送信すると、1 つ以上の Atom/RSS フィード・データ・ソースから 1 次データ・セットと 2 次データ・セットの両方が取得されます。このアプローチは、取得するデータの量が比較的少ないときに有利です。これで、ユーザーは特定の 1 次データ・レコードを選択し、より詳細なデータを 2 次テーブルやチャートに生成したり、レビュー用にイメージやマップへと反映したりすることにより、以降の要求を遅延することなくデータ・セットをナビゲートできます。あるウィジェット (たとえば、表内) にレンダリングされたデータを選択すると、ブラウザー・マッシュアップ・ランタイム・コンポーネント内でイベントのパブリケーションが自動的に開始され、そのイベントを listen している他のウィジェットに通知されます。他のウィジェットはこれに調和して処理を進め、追加情報をユーザー・インターフェースにレンダリングします。

図 7. パターン 2 のシーケンス図

アクセス制御が必要な最も単純なケースでは、マッシュアップ・アプリケーションの作成者が、マッシュアップ・アプリケーションの使用を許可するユーザーまたはユーザーのグループを指定できます。このため、デプロイ後のマッシュアップ・サーバーは、WebSphere Application Server の VMM 機能の統合を通じて容易にアクセスを制御できます。図 7 に示したパターンでは、ログイン時に取り込んだユーザー・クレデンシャルは、1 次データおよび 2 次データの両方をホストするシステムへのアクセスに十分なものであると仮定しているため、シングル・サインオン機能をユーザーに提供できます。ログイン時に作成されたセキュリティー・トークン (LTPA) はデータ要求とともにバックエンド・システムに送信され、バックエンド・システムが許可を実行できるようになり、データへのアクセス制御が行われます。また、AJAX HTTP プロキシーを通じてデータ・ソースへ要求を送信することにより、マッシュアップ・サーバー・オリジンの外部にあるシステムへのアクセスが可能になります。

マッシュアップ作成ツール内のすぐに使える多くのウィジェットは、カスタマイズしたウィジェットを開発しなくても簡単にマッシュアップ・アプリケーションを作成できるフィードを活用しています。そこで、このパターンと以降のいくつかのパターンでは、シンジケーション・フィードの使用に焦点を当てます。ただし、パターン 4 と 5 では、非シンジケーション形式のデータにアクセスする他のオプションについても説明します。

パターン 3: 集約された 2 次データ・ビューをともなう問い合わせ

図 8 に示すように、このパターンは、2 つの既存のシンジケーション・フィードを 1 つのフィード・マッシュアップに集約し、2 次データを組み合わせたセットを得ることによってパターン 2 を拡張しています。最初の 1 次データ・セットでデータ・レコードを選択すると、マッシュアップ・ハブでフィード・マッシュアップが呼び出され、独立したフィード・データ・ソース (RSS または Atom) への 2 つの個別の要求が作成されます。マッシュアップ・ハブを使用してデータを変換 (フィルター、再構成、ソート) することにより、マッシュアップ・アプリケーションに Atom フィードとして返される集約フィードを作成できます。

図 8. パターン 3 のシーケンス図

マッシュアップ・ハブにデータの変換を実行させることにより、ブラウザーの負荷を軽減して稼働中のバックエンド・コンポーネントに処理を移し、パフォーマンスを最適化するよう構成できます。同様に、企業の内部または外部にある保護されたデータ・フィード (WebSphere Application Server にデプロイされていないもの) またはインターネット上の有料フィードにアクセスする必要がある場合は、マッシュアップ・ハブにフィードを登録することで、ログインおよびセキュリティー・クレデンシャルを取り込むことができます。マッシュアップ・アプリケーションはマッシュアップ・ハブを通じて、保護されたフィードにアクセスします。マッシュアップ・ハブはプロキシーとして機能し、適切なクレデンシャルをシステムに提供することにより、データ・ソースへのアクセスを可能にします。マッシュアップ・アプリケーションのユーザーに、保護されたフィードへのアクセス許可が付与されるようにすることは、保護されたフィードとそのクレデンシャルを登録するマッシュアップ・アプリケーションの作成者の役割です。

前のパターンでは、マッシュアップ・サーバーおよびマッシュアップ・ハブが同じシステムにインストールされているという前提のため、AJAX HTTP プロキシーは不要です。また、このパターンを使用すると 2 つよりも多くのデータ・ソースからの集約が可能であるため、関連性の高いデータ・セットをさまざまなソースからマッシュアップ・アプリケーションに提供できます。

パターン 4: 非シンジケーション・データ・ソースおよび他のベンダーから取得したサービス集約をともなう問い合わせ

図 9 に示すように、このパターンはパターン 3 と似ていますが、データ・ソースは必ずしも RSS または ATOM シンジケーション・フィードでなくてもよく、エンタープライズ・データ・ソースまたは他のベンダーから取得したサービス (たとえば、Microsoft Access、DB2 XML、LDAP、Lotus Domino、IMS、LDAP、SAP、CSV、XML、Microsoft Excel、および既存のフィード) を使用できる点が異なっています。

このパターンでは、シンジケーション形式をサポートしない既存のシステムとのインターフェースとしてマッシュアップ・ハブが重要な役割を果たすため、マッシュアップ・アプリケーションからマッシュアップ・ハブを容易に利用できます。マッシュアップ・ハブには、サポートされている既存のシステムごとにアダプターとプラグインがあります。これらは、既存のシステムの API を利用するために必要なログイン・クレデンシャル、パラメーター、およびメタデータを提供するようマッシュアップ作成者により構成されています。既存のシステムに個別にアクセスし、データ・ストリームごとに個別のフィードを作成できます。また、複数のシステムとやりとりし、データ・ストリームを組み合わせて 1 つの集約済みフィードを作成することもできます。

図 9. パターン 4 のシーケンス図

パターン 3 のように、マッシュアップ・ハブは、データの変換 (フィルター、再構成、またはソート) や保護されたデータ・ソースのアクセス制御に使用できます。マッシュアップ・ハブは、既存のシステムとマッシュアップ・アプリケーションとの間のプロトコル変換を行うゲートウェイとして機能し、データ変換を実行するよう構成できます。このため、UI の遅延を最小限にするようマッシュアップ・アプリケーションのナビゲーションを設計するときは、パフォーマンスとの関連を考慮することが不可欠です。たとえば、考慮すべき事項として、レンダリングするデータのダウンロードに先がけて既存のシステムとの対話を開始する、既存のシステム API を活用してデータ・ソースでフィルタリングする、既存の一般的なシステムにデータを移行して統合するシステム数を減らす、負荷の少ないサービスを呼び出して既存のシステムの処理能力を最大限に高める、などのこと挙げられます。

パターン 5: データ・ソースへのデータ更新をともなう問い合わせ

ほとんどのマッシュアップ・アプリケーションの最初のフェーズでは、意思決定の改善、生産性の最適化、および専門知識とコンテンツ検索の支援のために、検索とレビュー用の対話および動作を実装します。しかし、データ・レコードを更新または新規作成する機能が欠けていれば、形式によらないビジネス・プロセスやチーム・メンバー間でのコラボレーションを改善するためにもたらされた価値が大きく損なわれます。図 10 に示すこのパターンは、1 次および 2 次データ・セットの更新またはバックエンド・システムで維持される新規レコードの作成をユーザーに許可することにより、他のパターンを拡張したものです。

この時点までのパターンでは、シンジケーション・フィードを使用してデータ・ソースにアクセスするブラウザー・マッシュアップ・ランタイム・コンポーネント (つまり、ウィジェット) だけが表示されているため、変更なしに使えるウィジェットを使用することで、マッシュアップ・アプリケーションを迅速に作成できます。しかし、サーバー・サイドのコンポーネント (たとえば、サーブレット) とのインターフェースとして機能し、必要または利用可能な形式で情報を抽出するウィジェットを開発することもできます。

図 10. パターン 5 のシーケンス図

ウィジェットはマッシュアップ・アプリケーションの主たるビルディング・ブロックであるため、システム・サイドのコンポーネントの適切なプロトコルと API をサポートするウィジェットを作成し、これらのシステムによってホストされているリソースと直接やりとりすることができます。これを行うインターフェースとしては、シンジケーション・フィード・リソース用の Atom パブリッシング・プロトコル、REST サービスまたは WSDL (Web サービス記述言語) サービス、Java EE (Java Platform, Enterprise Edition) 上の Java API にアクセスする Java コンポーネント (サーブレットなど) の呼び出しがあります。更新とコラボレーションのための対話および動作をサポートするには、ウィジェット開発用の IT リソースの間に依存性が発生します。同様に、これらのインターフェースから抽出可能なすべての情報は、1 次および 2 次データ・ビュー (たとえば、コンタクト・リスト内の個人に関する在席情報など) の作成に用いるために、ウィジェットによって取得できます。

パターン 6: チーム・コラボレーション

ビジネス・プロセスの実行のために他のユーザーによって使用されるデータ・レコードの更新および新規作成に加え、チームのメンバーは、チーム内でのコミュニケーションが容易になるという利点を得られます。現在、コミュニケーション・オプションとツールは IT プロフェッショナルによって使用されていますが、これらをマッシュアップ・アプリケーションに統合すると、1 次または 2 次データにコンタクト情報 (たとえば、名前、電話番号、および電子メール・アドレスなど) が含まれている場合に付加価値が生じます。コミュニケーション・オプションをマッシュアップ・アプリケーションに組み込むことで、アプリケーションを切り替え、ユーザーのコンタクト情報をコピーし、それをアプリケーション (電子メール・クライアント、インスタント・メッセージング・クライアント、または電話キーパッド) に入力するという操作を必要とせずに、ユーザーはメッセージングまたはボイス・コールを開始できます。図 11 を参照してください。

図 11. パターン 6 のシーケンス図

簡潔にするために、このフローからは AJAX HTTP プロキシーが省略されていますが、ロード元のマッシュアップ・サーバー以外のデータ・ソースまたはシステムへのウィジェット呼び出しの流れは、すべて AJAX HTTP プロキシーを通じて実行されます。


まとめ

今日のマッシュアップ・アプリケーションは、検索、レビュー、共同作業、および更新の各動作をサポートするシンプルな対話モデルを使用して表現できます。ユーザーがアクションを実行すると、それに対してマッシュアップ・アプリケーションが 1 つ以上の応答を返す形で一般的な対話をサポートするため、マッシュアップはビジネス・シナリオに使用できます。今日、マッシュアップが使用されている各業種でのユーザーの役割とデータは異なり、それぞれが業種ごとのビジネス要件を解決する固有な値を持っています。しかし、重要な IT 要件は基本的には同じなので、活用パターンおよびアーキテクチャー・パターンは類似しています。ビジネス・シナリオは、少数のアーキテクチャー・パターンを使用して実装できる一般的な活用パターンを通じて実現されます。

この記事では、初期採用者の使い方に基づき、マッシュアップ・テクノロジーがもたらすいくつかの可能性について触れました。ビジネス・ユーザーが自分自身のニーズまたは問題を解決するために、独自の状況依存型アプリケーションを作成できるようになることが、マッシュアップ・テクノロジーおよび IBM Mashup Center を使用して実現され始めた価値提案なのです。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

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

ディスプレイ・ネームを選択してください



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

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

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


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


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus
ArticleID=395473
ArticleTitle=マッシュアップのビジネス・シナリオとパターン: 後編
publish-date=06122009