マッシュアップは Web 2.0 の新しい魅力的な側面です。新しいテクノロジーやアプローチが登場すると、新たに出現した価値を広めようと業界が躍起になる傾向があります。この過剰な宣伝は、新しいテクノロジーで作成できるものの価値と、現存するものの価値の違いを不明瞭にしがちです。マッシュアップの場合、既存の Webアプリケーションと、ブラウザーでデータをマッシュアップするという革新的なアプローチとの違いが、IT プロフェッショナルにとってあまり明確でないようです。

お客様からよく問われる質問の 1 つに「いま社内で使用している Web アプリケーションと、マッシュアップとの違いは何ですか?」というものがあります。テクノロジーまたはシステム統合に関しては、違いはほとんどありません。むしろ、ユーザーがアプリケーションを作成するときの容易さ、アプリケーションの使用目的、マッシュアップまたは Web アプリケーションのデプロイ後に解決しなければならない機能面以外の要求 (たとえば、信頼性、可用性、およびパフォーマンス) の有無となって現れます。

この記事では、Web アプリケーションとマッシュアップというより新しいスタイルを比較します。マッシュアップは、エンタープライズ・シチュエーショナル・アプリケーション (enterprise situational applications) と呼ばれることもあり、ビジネス目的で使用されます。マッシュアップは特定の状況(situation)のために作成され、その状況が存続している短期間だけ使用されることがあります。マッシュアップと従来の Web アプリケーションの違いを正しく理解するために、まず共通点から見ていくことにしましょう。

先ごろ、Lotus® Mashups と InfoSphere™ MashupHub で構成される IBM® Mashup Center の提供が発表され、IT アーキテクトおよびビジネス・アナリストは、この製品のコンポーネントと機能をどのように活用すれば、状況に応じたニーズをより適切に解決し、今日の市場における自社の競争力を改善できるかを考えられるようになりました。

マッシュアップと Web アプリケーションの共通点

一般に、マッシュアップと Web アプリケーションのどちらも、クライアント・サイドのソリューション・コンポーネントとしてブラウザーを使用し、特定のアプリケーションにユーザー・インターフェース (UI) を提供します。どちらも社内のサーバーから一元的に管理され、サーバー上の Web リソース (たとえば、HTML、JSP、Java™ サーブレット、ASP、CGI、または PHP リソース) にアクセスする URL が使用されたときに、ユーザーのブラウザーにデプロイされます。また、マッシュアップと Web アプリケーションのどちらも、ビジネス・ロジックを社内システムに実行でき、社内データベース、パブリック・データ・ソース、または外部サービスからデータを取得できます。UI と内部または外部のビジネス・システムから抽出した情報を定義および構築するコードはブラウザー内でレンダリングされ、データを表示および操作する手段をユーザーに提供する点も同じです。さらに、ブラウザーに送信するコンテンツには、ブラウザーのランタイムに実行される JavaScript™ およびスクリプト・ライブラリーを含めることができるため、カスタム・ロジックをブラウザーでローカルに実行できます。 多くの場合、JavaScript およびスクリプト・ライブラリーは、簡単なフィールドの検証や、対話的で機能が豊富なユーザー・インターフェースを持つ複雑な UI コントロールの実装に使用されます。

上に戻る

従来の Web アプリケーション: すべてが相対的

では、この2種類のアプリケーションの違いを見ていきましょう。従来の Web アプリケーションという言い方には、多くの主観的な基準が漠然と用いられています。Web アプリケーションの現在の開発方法による、という見方もあります。一般に、従来型という分類は、正式な開発およびデプロイメント手法を使用している点により多く基づいています。従来の Web アプリケーションという分類には、ユーザーとの対話 (たとえば、フォームの送信やリンクのクリックなど) に基づいてコンテンツを動的に生成するアプリケーションが含まれることを意味しますが、UI 内での情報の集約と UI コントロールのリンクはサーバー上で行われます。このため、Java Server Pages (JSP)、Active Server Pages (ASP)、および IBM WebSphere® Portal の各テクノロジーに基づいて作成されたアプリケーションは、従来の Web アプリケーションと考えられます。ページ単位のナビゲーションをサポートする Web ベースのアプリケーションも、データを効率よく表示および操作するためのユーザー機能が制限されているため、従来の Web アプリケーションです。高度な対話型インターフェースを持つ Adobe® Flash テクノロジーを活用する Web アプリケーションでさえも、構築およびデプロイ方法に注目すると、従来の Web アプリケーションと考えられます。

企業の基幹業務で利用されるWeb アプリケーションは、正式な開発チームおよび運用サポートを必要とすることが通例です。まず、開発とサポートのコストは、それによって利益を得るユーザー数が多数である場合、またはアプリケーションが業務上不可欠である場合にのみ正当化できます。どちらのケースでも、投資による見返りを最大限に高めるために正式なプロセスが必要です。

次に、リソースの活用を最適化するために、通常、固有のスキルは業務組織と連携しています。多くの場合、開発とデプロイメントのスキルを持つ人々と、業務分野に関する知識を持つ人々は異なります。一般に、基幹業務には、ビジネス・プロセスまたは顧客関連の営業およびサービスの優位性をサポートするために解決しなければならない一連の要求事項があります。これらの要求事項は、UI の設計と開発、アプリケーションの動作方法を管理する制御ロジック、業務データを活用および操作するコードを通じて解決されます。

通常、エンタープライズ Web アプリケーションの開発作業は、要件定義、設計、開発、機能とシステムのテスト、およびデプロイメント・ステージをともなう非常に正式なものです。このため、エンドツーエンドのソリューション・プロセスは、1 年を超えないまでも、完了までに何カ月もかかることがあります。このアプローチでは、業務別の組織は社内の IT およびプログラミング部門に依存しています。一方、正式なプロセスに従うと、結果として、対象とするユーザーに最適化された、総合的で安定したソリューションが得られます。また、そのトレードオフとなるのは、Web アプリケーションの開発およびデプロイにかかる時間と､アプリケーションの配布と維持にかかる総コストです。場合によっては、Web アプリケーションを作成するサイクル・タイムが長引くと、アプリケーション対するビジネス要求が変化する、または不要になることがあります。

上に戻る

マッシュアップ: Web 2.0 チャイルド

前述のように、マッシュアップは、エンタープライズ・サーバー側でもブラウザー側でも、従来の Web アプリケーションと同じテクノロジーを多く使用しています。マッシュアップの概念は新しいものではなく、業務および Web 開発者は過去 10 年にわたり、Web をプラットフォームとしてデータを集約および統合してきました。混乱を最小限にするために、マッシュアップについて、いくつかの点を整理してみましょう。多くの人々にとって、マッシュアップは、異種データを組み合わせて新しくて興味深いものを生成することを意味する技術用語だと考えられています。状況依存型アプリケーションは、戦術的なアプリケーション、つまり使用者が作成した一時的なアプリケーションと考えられます。この観点から、マッシュアップは状況依存型アプリケーションであり、状況依存型アプリケーションはマッシュアップであるといえるでしょう。この記事では、マッシュアップは、マッシュアップとして実装される状況依存型アプリケーションを意味します。概要を図 1 に示します。

マッシュアップと従来の Web アプリケーションの主な違いは、マッシュアップ・アプリケーションのライフ・サイクルとマッシュアップの傾向に関係します。つまり、複数のパブリック・ソースからの関連がなさそうなデータを、データ提供者の正式な同意をほとんど、あるいはまったく得ずに、意味のある方法で結合するという傾向です。

いくつかの理由から、マッシュアップは Web アプリケーションの特殊なジャンルであると考えられます。マッシュアップは、ユーザーまたは業務アナリストによって、IT リソースをカバーするために、コストをほとんど掛けず、または追加コストなしで比較的短期間に作成されます。同様に、企業で使用されているマッシュアップでは、企業データとパブリック・ソースからのデータの双方のデータが集約されていることがよくあります。これらのマッシュアップは、複数のソース (多くの場合、無関係に見えるパブリック・データ・ソース) からのデータを、ビジネスまたは個人のニーズを解決する意味のある形に統合し、価値を創造します。集約されたデータは、適切なコンテキストに置くことにより、関連した情報になります。新しくて興味深い何かを創造することが、役に立つマッシュアップを作成するときの秘訣です。

たとえば、サプライ・チェーン・マネジメントの例として、地域の担当マネージャーは、台風などの災害時の製品物流を管理する目的で、天気予報のフィード、Yahoo!地図、および社内在庫データが含まれる Web ページ (マッシュアップ) を作成できます。また、価値のある情報を個人にもたらす例として、Web を熟知した社員 (営業担当員) が、仕事の都合で転勤するにあたり、住宅資産を購入するケースを考えてみましょう。この社員は、Google マップを使用して Web ページを作成し、公的な納税記録、公的な事件記録、顧客リストなどとともに画像付きの不動産のリストをそのマップに統合します。社員はこのタスクを実現するために、各データのリストをパレットからドラッグし、地図上にドロップします。これによって、住所情報を持つ各エントリーが、ピンのマークで地図上に表示されます。結果として得られるマッシュアップは、複数のソースからの異種データを共通のビューに集約します。このマッシュアップは、妥当な価格で、顧客に近く、近隣が安全な住宅を購入するための決断に寄与し、社員への価値を作り出しています。

従来の Web アプリケーション (たとえば、ポータル) もデータを集約できます。しかし、通常、業務に欠くことができない重要なアプリケーションは、可用性とデータの正当性に関する理由から、パブリック・データ・ソースに依拠することはありません。同様に、業務アナリストは、そのようなアプリケーションを構築するスキルを持っていません。

実装面での違いの 1 つとして、マッシュアップは Web 2.0 チャイルドとして、Ajax アプリケーション・モデルをインプリメントします。このモデルはコンテンツを非同期的にロードおよび表示し、サーバーの要求と UI 対話での特有の遅延を最小限にします。同様に、マッシュアップ・ウィジェットは JavaScript とスクリプト・ライブラリーを活用して、サーバーだけでなく、ブラウザー内にデータを集約できます。その結果、マッシュアップは、従来からの多数の Web アプリケーションが採用しているページ全体の更新モデルよりも、より自然で応答性の高いユーザー対話を提供できます。

ビジネス・ユーザーがマッシュアップを作成する際は、マッシュアップ・メーカー、エディター、またはアセンブラーなどがよく使用されます (たとえば、Lotus Mashups、IBM Lotus Widget Factory など)。マッシュアップ・メーカー自体は、簡素化されたブラウザー・ベースの開発環境といえます。ユーザーは、マッシュアップ・メーカーのパレットからウィジェットを選択し、ワークスペースに配置します。次に、ウィジェットのカスタマイズとリンク作成のために若干の設定手順を実行すると、簡単な Web アプリケーション、つまりマッシュアップ、あるいはより具体的に言うと状況依存型アプリケーション・マッシュアップが作成されます。また、同様のツール (たとえば、InfoSphere MashupHub) を使用して、既存の一連のフィードをマージ、フィルター、および変形し、ウィジェットによって消費される新しいフィードに仕立てることにより、マッシュアップ・フィードを作成できます。ウィジェットそのものは、正式なインターフェースとカスタマイズ可能なプロパティーを持つ独立したアプリケーション・コンポーネントであり、データの UI ビュー、UI コントロール、およびバックグラウンドでのデータ処理 (たとえば、サーバー・サイド・サービスの呼び出し、データベースの CRUD オペレーション、スクリーン・スクレーピング、ウィジェット間でのデータのトランスコーディングとマッピングなど) を提供します。マッシュアップの作成と他のユーザーによる使用に向けたデプロイメントはマッシュアップ・メーカー内で行われ、正式な IT 運用チームに依存することはありません。しかし、初期の段階では事業と IT組織の間にある程度の依存関係がまだ存在します。つまり、一方ではツールのデプロイ、セットアップ、およびマッシュアップ・システムの有効化を行い、もう一方では Web アプリケーションのマッシュアップ・スタイルを作成するためにビジネス・ユーザーにツールを利用できるようにします。

従来の Web アプリケーションで必要であるように、IT組織は実稼働環境でシステムをセットアップおよび構成する必要がまだあります。また、ファイアウォール背後での内部的な作業が必要な場合もあります。ポータル・ベースの Web アプリケーションでポータル・エンジンが必要なように、特定のマッシュアップ・システム・コンポーネントはサーバー上にデプロイしなければなりません。さらに、標準のシンジケーション・フィード (RSS または ATOM)、Representational State Transfer (REST) API、または単純な Web サービス API を使用してビジネス・データにアクセスできない場合、IT組織はそのようなインターフェースを作成する必要があります。

企業データ・ソースへのシンジケーション・フィード対応機能の作りこみの1つの簡単な代替手法として、マッシュアップ・ハブ・コンポーネント (たとえば、InfoSphere MashupHub) を利用する方法があります。マッシュアップ・ハブ・コンポーネントは、バックエンドの企業システムとのインターフェースとして機能しながら、各システムの個々のシンジケーション・フィードや、マッシュアップ・システムで使用できるシステムのシンジケーション・フィードを集約します。同様に、ウィジェットで許可されているプロパティーに基づいてデータのビューをカスタマイズする必要がある場合、またはユーザーとの対話にカスタム・ウィジェットが必要な場合、情報システム部門は新しいウィジェットを作成するか、手持ちの既存のウィジェットをカスタマイズするかを選択できます。標準化された API を通じてビジネス・データとロジックを外部対応可能にし、カスタマイズしたウィジェットをウィジェット目録に追加すると、情報システム部門への依存は大幅に削減されます。情報システム部門は、適切なミドルウェアによってシステムが維持され、システムの可用性を確保するためにモニタリングとサポートが提供されていることを確認するためだけに必要となるかもしれません。ウィジェットは再利用可能なアプリケーション・コンポーネントであり、特定のビジネス機能を提供するためにその場の必要性に応じて組み立てられるため、トレードオフが生じます。トレードオフとしては、UI のカスタマイズ性が削減される、パフォーマンスを調整する機能が少ない、マッシュアップ・アプリケーション自体を構成している集約済みのウィジェット群への正式なサポートが少ないか、まったくない点などが挙げられます。

上に戻る

どのアプローチが適しているか

いくつかの明確な違いがありながらも多くの類似点があるため、どちらか一方のアプローチを採用する明らかな利点を見つけるのは難しいかもしれません。以下のポイントを考慮して、従来の Web アプリケーション開発およびデプロイメント・モデルを使用することが最良の選択になるか検討します。

• アプリケーションは、ビジネスの成功に不可欠である。
• 大規模なユーザー・コミュニティーで、アプリケーションの高可用性と正式なサポートを必要としている。
• アプリケーションは、高度なインテグレーションとカスタマイズ可能な UI が不可欠な複雑なな要件を満たす必要がある。
• 複雑な文書ワークフローまたはプロセス・ワークフローを管理する必要がある。

上記の考慮事項が従来の Web アプリケーションによるアプローチにあてはまらない場合は、以下のポイントを考慮して、状況依存型アプリケーション・マッシュアップが最良の選択であるか検討します。

• ビジネス・ニーズは差し迫ったもので、短期間である。
• ユーザーまたは業務アナリストは Web に詳しい。
• ビジネス・データを、複数のソース (企業の内部または外部) からのデータと意味のある方法で関連付けることができる。
• ビジネス・ニーズを IT組織にデモンストレーションするために、迅速なプロトタイプ作成が必要。
• ユーザー自身によるビジネス・データの集約と統合を可能にすることで、ユーザー・コミュニティー内での生産性を高められる。
• ビジネスおよび個人のニーズを解決するために、「ほどほどの品質の」ソリューションで十分である。
• データ・ソースがシンジケーション・フィードをサポートしている。
• データ・サービスが REST スタイルのインターフェース、単純な Web サービス・インターフェースをサポートしている。
• 多数のビジネス・ユーザーが同じデータへのアクセスを必要とするが、その理由はさまざまである。

上に戻る

まとめ

状況依存型アプリケーション・マッシュアップが提案する価値は、標準化されたインターフェースを通じて企業がビジネス・ロジックとデータへのアクセスを有効にすることで、ユーザー自身が容易にアプリケーションを作成できるようになる点にあります。アプリケーションは、企業データの表示とアクション実行ができるウィジェットを使用して構成されるため、ユーザーは SOA への企業投資や他の標準機能を直接活用できるだけでなく、セルフ・サービス型で組み立てることにより、ユーザー固有のニーズを解決し、生産性を最適化することができます。個人またはチームによるこれらの生産性の向上は情報システム部門にほとんど依存しないため、これらの利点が情報システム部門のリソースのコストと引き換えになることもありません。

参考文献

• developerWorks® の記事 「Mashups: The new breed of Web app」 を参照してください。
  
  
• developerWorks の記事 「IBM Mashup Center and the InfoSphere MashupHub, Part 1: Get started with InfoSphere MashupHub」 を参照してください。
  
  
• developerWorks の記事 「SOA Meets Situational Applications, Part 1: Changing computing in the enterprise」 を参照してください。
  
  
• developerWorks の記事 「Mashups -- The evolution of the SOA, Part 2: Situational applications and the mashup ecosystem」 を参照してください。
  
  
• 状況依存型アプリケーションについて解説されています。
  
  
• マッシュアップ について解説されています。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• マッシュアップと Web アプリケーションの共通点
• 従来の Web アプリケーション: すべてが相対的
• マッシュアップ: Web 2.0 チャイルド
• どのアプローチが適しているか
• まとめ
• 参考文献
• 著者について
• コメント