レベル: 中級 Stephen Watt (swatt@us.ibm.com), Certified IT Architect, IBM
2007年 11月 08日 この記事は 3 回シリーズの第 2 回として、状況依存型アプリケーションとマッシュアップ・エコシステムについて説明し、それらが IT 業界でのソフトウェア開発の現状と SOA (Service-Oriented Architecture) にどう関係するかを説明します。このシリーズの最初の記事では、Web 2.0 に関連した特長と技術を定義しました。そしてシリーズの最後の記事では、IBM Mashup Starter Kit についてと、IBM Mashup Starter Kit を使って状況依存型アプリケーションを開発する方法について説明します。
状況依存型アプリケーションとソーシャル・ネットワーク
ソーシャル・ネットワークは、特定の共通する特徴で結びつけられた、個人の集団の関係を表すモデルです。個々の人は、複数のソーシャル・ネットワークに属すことができます。例えば、Joe Soap は University of Texas の卒業生のソーシャル・ネットワークに属し、オースチン (Austin) でマウンテンバイクを楽しむ人達のソーシャル・ネットワークに属し、Whole Foods という店でしか食料品を買わない人達のためのソーシャル・ネットワークに属し、等々とリストが続きます。Joe Soap は、非常にさまざまなソーシャル・ネットワークに属しているのです。
特定のソーシャル・ネットワークの特徴に関する知識は貴重なツールであり、アプリケーション開発者はそれを使ってソーシャル・ネットワークのニーズや要件を詳細に検証し、アプリケーションを適切に調整することができます。例えば、便利な機能を追加し、便利でない機能を削除することができ、それによってこのアプリケーションは、対象とする特定のコミュニティーにとって、より魅力的なものになります。さらに、その同じコミュニティーに対してアプリケーションの改訂版を複数提供し、それに対するフィードバックを求めて取り入れることで、そのコミュニティーと密接に協力することができます。これは第 1 回で触れた、コミュニティーとの緊密なフィードバック・ループを示しています。広範囲のユーザーを対象にソフトウェアを設計する場合には、使われても使われなくても、さまざまな機能を追加する必要がありますが、それとは対照的です 。
Clay Shirky による記事 (「参考文献」にリンクがあります) には、ニューヨーク大学 (New York University) の学生達が特定のユーザー (ニッチではないかもしれませんが) をアプリケーション作成の対象とすることで、どのようにして便利で人気のあるアプリケーションを設計したのかについての思わず引き込まれる例がいくつか掲載されています。彼はさらに、もしこれらのアプリケーションがもっと広範囲のユーザー向けに位置付けられたとしたら、価値も人気もなかったろうとも言っています。つまり要約すると、状況依存型アプリケーションは特定の状況でのニーズに応えるために作成されたアプリケーションであり、特定のソーシャル・ネットワークのために設計され、そして特定のソーシャル・ネットワークと協力して開発されています。
もう 1 つ、興味深い要素として、マーケットの動勢は急速に変化しているため、ビジネス連携の大部分は 12 カ月も継続しないという傾向に注意する必要があります。アプリケーション統合の作業が平均して 3 カ月から 6 カ月を要することを考えると、ROI (return on investment: 投資収益率) のために残された余地はほとんどありません。業界が必要としているソリューションは、差し迫っている特定のビジネス問題を解決するために (ビジネス連携している期間にわたって作成するのではなく) 迅速にコスト効率よく作成できるソリューションで、なおかつ (マーケットの移り変わりに合わせて) 使い捨て可能と見なされるソリューションです。状況が、短命のアプリケーションを必要としていることもよくあります。そのため状況依存型アプリケーションは、もう 1 つの特徴を持っています。つまり製品レベルの品質を実現する機能や特徴を示す必要がないため、最終的な結果は非公式で『とりあえず十分』というレベルなのです。
状況に応じたソフトウェアを作成する方法
情報を開放して利用しやすくすることで、SOA が進化し、改善されて、ユーザーがさまざまなことをできるようになれば、この SOA を活用してユーザーが状況依存型ソフトウェアを迅速に作成できるマッシュアップ・エコシステムを構成することができます。これは非常に興味深いことですが、当然ながらそうした目標の達成は容易ではありません。以下のセクションでは、そのための方法を詳細に説明します。
SOA の進化
IT 業界は大きな一歩を踏み出し、IT インフラをモジュール化し、再利用可能なサービスに分解しました。これにより他の分野にも価値が提供されるようになりましたが、それでもなお、これらのサービスを使ってアプリケーションを統合し、構築するためには、開発者のスキルが必要です。IT はビジネスのニーズを満たすために存在するので、SOA の、次の進化は、これらのサービスをユーザー (開発者ではない人達) の手に渡せるようにすることであるのは当然のことです。そうすることで、ユーザーは、この前のセクションで説明した ROI の問題を克服できる方法でソリューションを構築することができます。
さらに、状況依存型アプリケーションの要件を実現するために、開発は現在よりもずっと手頃で状況に見合ったものになる必要があります。それには SOA の中にある現在のサービスにアクセスし、それを活用し、そしてエンド・ユーザーまたはビジネス・ユーザーがサービスの統合を迅速に行えるようにする、新しい方法が必要です。この方法によってユーザーは、彼らの置かれた状況のニーズを満たすアプリケーションを迅速に作成することができます。
そうしたモデルを実現するために、サービスはユーザー向けに視覚的な要素を持つ必要があります。各サービスの表面、つまり視覚的な表現によって、サービスのプロパティーや機能にアクセスすることができ、またサービス間の関係 (ワイヤリング) を反映させることができます。これが実現できると、サービスの視覚表現と内容を含むサービス・カタログを作成することができ、それをパレットから引き出してキャンバスの上で使うことができます。サービスのプロパティーに視覚的にアクセスすることができれば、プログラムを介在させなくてもワイヤリング・フェーズを完了することができます。ビジネス・ユーザーは既にサービスの機能と内容に慣れているという事実を考えると、これによってアプリケーションの作成を非常に迅速に行うことができます。
サービスを使用する人達がビジネス・ユーザーであれば、そのサービスで提供される情報の粒度に関して、彼らは有効なフィードバックを提供することができます。これまで、サービスの中で提供される情報の粒度は、古いレガシー・インターフェースのパフォーマンスや現状維持などの要因で決まることがよくありました。そうしたサービスを使ってビジネス・ユーザーがアプリケーションを作成できれば、彼らは自分たちのアプリケーションの中で実際に情報をどう使用しているかを基に、情報の粒度に関する貴重なフィードバックを提供することができます。
図 1 は、状況依存型アプリケーションのインフラとして SOA がどのように使われているか、その構造を示しています。
図 1. SOA の表面
Shirky の論文に見られるソーシャル・ネットワークよりも広範な例が、最近のビジネス・エンド・ユーザーやパワー・ユーザーのソーシャル・ネットワークです。このような特定のネットワークを構成している個々のユーザー達は、Web や Web に使われている技術をよく理解しており、また基本的なプログラミング・スキル (Microsoft® PowerPoint® のオートメーションや Microsoft Excel® のマクロなどを作成できる能力) を持っているという特徴があります。こうしたユーザー達は、彼らのユーザー (通常は、もっと小さなソーシャル・ネットワーク) のことをよく理解しているので、その知識を使って彼らのユーザーが本質的ではないと見なす機能を時間をかけて追加する無駄を省きます。こうしたユーザー達がさまざまなことをできるようにするためには、彼らが持っているスキルを使って、(企業内の、そして Web 上の) コンテンツ・ソースや、ツール、製品、そしてサービスに関して彼らの持つ知識を活用する必要があります。これにより、彼らが担当するビジネス部分を駆動する状況依存型アプリケーションを、彼らが構築できるようになります。以上のことを実現するためには、マッシュアップ・エコシステムを採用する必要があります (図 2)。
図 2. 目標は状況依存型アプリケーションをユーザーが構築できること
マッシュアップ・エコシステム
図 3 は、マッシュアップ・エコシステムの垂直スタックを示しています。各要素は、その下にある要素の上に構築され、最終的な結果としてマッシュアップが作成されるまでそれが続きます。マッシュアップはこのエコシステムの最上部に位置しますが、このエコシステムの他の要素が用意できない限り実現することはできません。
図 3. マッシュアップ・エコシステムの垂直スタック
マッシュアップ
マッシュアップは一種の状況依存型アプリケーションであり、新たな統合エクスペリエンスを実現するために接続された本質的に異なる 2 つ以上のコンポーネントから構成されます。その一例が zillow.comです (「参考文献」にリンクがあります)。zillow.com は指定された場所の不動産に対する行政区の課税情報 (コンポーネント A) を同じ場所の地図 (コンポーネント B) と統合し、ある地図の特定区域内のすべての不動産に対する課税額を表示します (新たな統合されたエクスペリエンス)。オリジナルの状況依存型アプリケーションは主にシェルと Perl スクリプトでしたが、状況型へのニーズが増加するにつれ、そうしたニーズにすぐに安価に対応するために開発者が使うようになりました。残念なことに、これらの技術は開発者のスキルを必要とし、ビジネス・ユーザーのスキルを活用して対応することはできません。しかし今や、SOA を進化させ、サービスにファサードを持たせるための方法があるため、ユーザーがマッシュアップの形で視覚的に状況依存型アプリケーションを開発するためのマッシュアップ・エコシステムを採用する基礎は用意できています。SOAP Web サービスが SOA を実現するための単なる 1 つの方法にすぎないのと同じように、マッシュアップは状況依存型アプリケーションの単なる 1 つの形式にすぎません。今日の Web でマッシュアップが普及していることからもわかるように、状況依存型アプリケーションを作成するための方法として、マッシュアップは他のどのような方法よりも一般的です。
マッシュアップ・メーカー
マッシュアップ・メーカーは、マッシュアップを作成するための環境であり、マッシュアップを実行するための環境でもあります。マッシュアップ・メーカーによって、ユーザーは公開されている情報やサービスを会社内の機密情報やサービスと混在させ、視覚的な方法でマッシュアップを作成することができます。そしてユーザーは、そのコンテンツを視覚的に操作することができ、またそのコンテンツが Web ページなどの静的コンテンツであっても、SOAP や REST (Representational State Transfer) サービス、あるいは RSS フィードなどの動的コンテンツと統合することができます。QEDWiki は IBM Mashup Starter Kit に含まれているマッシュアップ・メーカーです (このキットをダウンロードするためのリンクが「参考文献」セクションにあります)。
マッシュアップ・メーカーを利用すると、マッシュアップを迅速に視覚的な方法で作成することができます。これは、マッシュアップ・メーカーには 1 つ以上のサービスやコンテンツに (通常は粗い粒度で) アクセスするためのソフトウェア・コンポーネントである、ウィジェットの集合が用意されているためです (この記事ではコンテンツと情報は同じ意味です)。ウィジェットは使いやすさとカスタマイズしやすさに焦点を当てて設計されていることが多く、そのため非常に柔軟です。これは、Web 2.0 の基本的な特徴の 1 つとして、コンテンツがどう利用されるかを予測できないからです。ウィジェットは (図表など視覚的なコンテンツを描画するという意味で) 視覚的なものもあれば、(何らかの形式の独立した機能や、サービスへのアクセスを提供するという意味で) 視覚的ではないものもあります。マッシュアップ・メーカーによって、ウィジェットをパレットからキャンバスに引き出すことができます。キャンバスではウィジェットのプロパティーに視覚的にアクセスすることができ、そのプロパティーを使用してさまざまなウィジェットの間で入力と出力を接続することができます。そしてその結果としてマッシュアップを作成することができます。
実際にマッシュアップを作成できるほど十分な数のウィジェットを用意するためには、そうしたウィジェットで表現できる広範な種類のデータ・サービス・インターフェースを利用できなければなりません。データ・サービス・インターフェースは汎用の用語であり、サービス・プロバイダーが彼らのコンテンツ (マッシュアップで使う必要がある情報や、マッシュアップで提供する情報) へのアクセス用に提供する技術的手段を表現するために使われます。通常、そうした手段としては、フィードや REST、SOAP/WSDL (Web Services Description Language)、Ajax (Asynchronous JavaScript + XML) または XML-RPC (XML Remote Procedure Calls) などがあります。Mashup Hub はフィード管理サーバーであり、マッシュアップがコンテンツを利用しやすいように、数多くの強力な手段を提供しています。Mashup Hub は IBM Mashup Starter Kit に含まれています (このキットをダウンロードするためのリンクが「参考文献」セクションにあります)。
マッシュアップ・エコシステムの中で状況依存型アプリケーションを作成する
マッシュアップ・エコシステムが用意できると、アセンブル、ワイヤー、そしてシェアというモデルを使って、マッシュアップ・メーカーで状況依存型アプリケーションを作成することができます。これを、各アクションに分解してみましょう。
-
アセンブル: 企業は、マッシュアップ・メーカーが利用できるウィジェット・カタログを作成することができます。このカタログには、指定のビジネス領域で使用可能な、企業内で作成されたウィジェットと企業外で入手できるすべてのウィジェットが含まれています。これによってユーザーは、マッシュアップを作成する過程の中で必要となるサービスやコンテンツを素早く見つけ、活用することができます。
-
ワイヤー: アセンブラーは、サービス・カタログの中に提供されているサービスを選び出し、それらをマッシュアップ・メーカーで接続することによって、視覚的な方法で迅速にマッシュアップを作成することができます。例えば、ユーザーがデータを入力できるようにフォーム・ウィジェットをページ上に置くことができます。この入力されたデータを Web サービスの呼び出しを行うウィジェットの入力に接続し、その Web サービスのレスポンスの出力を、視覚的な表示を行うウィジェットに接続することができます。
-
シェア: アセンブラーは次に、ナレッジ・ワーカーが使用できるように、そのマッシュアップを共有し、公開アクセスできるようにします。そこにはコミュニティーの機構を使うことができます。
このプロセスには下記の 3 つの明確なロールがあります。
-
マッシュアップ・イネーブラー: マッシュアップ・イネーブラーはウィジェットを作成し、それらをカタログに追加します。また、アセンブラーと対話することでアセンブラーのニーズを予想し、適切なサービスを (先んじて、また後からでも) 追加します。マッシュアップ・イネーブラーは通常、IT 部門の誰か、あるいはソフトウェアを作成するための十分な技術スキルを持った人です。
-
マッシュアップ・アセンブラー: マッシュアップ・アセンブラーは通常、プログラマーではなく、基幹業務のユーザーか、または対象とする内容のエキスパートで、マッシュアップ・イネーブラーが作成した、マッシュアップに利用するためのブロックをつなぎ合わせ、マッシュアップを作成します。
-
ナレッジ・ワーカー: ナレッジ・ワーカーはアプリケーションを本来の目的に使用するコミュニティーで、アプリケーションに対してコミュニティーの機構 (例えばレーティングやコメントなど) を適用し、アプリケーションが次の機会に改善されるようにフィードバックを提供します。
下記の図は、さまざまなフェーズでの、このモデルのロールの責任範囲を示しています。
図 4. アセンブル、ワイヤー、そしてシェアのモデル
なぜマッシュアップ・エコシステムは効果的なのか
第 1 に IT 業界は、SOAP や REST、Ajax などの重要な技術の標準化に関して大きく進歩しました。そのため、Web 上にも企業内にも SOA の採用が爆発的に増えています。これによって技術がクリティカル・マスに達し、ごく手近な Web サイトに再利用可能な Web ベースの API やマッシュアップが豊富に存在しています。そこでは、このモデルを使ってアプリケーションを開発しようとする人々が利用できるコンテンツやデータ、そしてサービスが、これまで例を見ないほど拡大し続けています。機は熟しているのです。
第 2 に、マッシュアップ・エコシステムは非常に利用しやすいプログラミング・モデルです。インターネット・ベースのアプリケーション (そして PHP などの単純なスクリプト言語) に慣れ、また Excel のマクロ作成などの作業を行えるビジネス・ユーザーやパワー・ユーザーの数は非常に多いため、このモデルを使い始めるための障害はほとんどありません。
最後に、今日のインターネットでは既に一般的な協力作業の機構を活用することで、このモデルを使って迅速なアプリケーション開発を実現することができます。
まとめ
この記事では、ビジネス連携は状況に即応した対応が求められるため、既存のアプリケーション開発のプロセスと方法を利用すると ROI が低くなることを学びました。さらに、マッシュアップ・エコシステムのコンテキストでは、ビジネス・ユーザーとパワー・ユーザーが持つ専門領域のスキルや技術関連のスキルを活用することができるので、ユーザーが迅速かつ視覚的な方法で状況依存型アプリケーションを作成できること、その結果 ROI も改善されることを見てきました。このシリーズの次回の記事では、IBM Mashup Starter Kit と、それを使ってマッシュアップを作成する方法について解説します。
謝辞
この記事をレビューしてくださり、また協力くださった Stew Nickolas と Dan Gisolfi の両氏に感謝いたします。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | 
| | Stephen Watt は、テキサス州オースチンの研究所にある IBM Software Group の戦略組織で新興技術に携わるソフトウェア・アーキテクトです。IBM に入社前には中東で数年間コンサルティングを行ったことがあり、またアメリカと彼の出身地である南アフリカで、設立されたばかりの会社にも勤務していました。彼は何冊かの技術書と技術記事を出版、発表しており、それらは Wrox Press と IBM developerWorks で入手することができます。 |
記事の評価
| 
