目次


マッシュアップ: 新種の Web アプリケーション

マッシュアップ入門

Comments

はじめに

インターネットの世界全体で、Web ベースのデータ統合アプリケーションの新種が続々と芽を出しつつあります。こうしたアプリケーションはよくマッシュアップと呼ばれますが、その人気は、対話型のユーザー参加が強調されていること、そして、まるでフランケンシュタイン博士の怪物のように、サードパーティーのデータをつなぎ合わせて作られることから生まれています。芽を出すという比喩は、当を得たもので、マッシュアップWeb サイトの特徴は、そのサイトが Web 全体に渡って根を広げていく、その様子にあります。つまりこうしたWeb サイトは、そのサイトの構成外にあるデータ・ソースから取得したコンテンツや機能を元に描画を行うのです。

この、データ統合というマッシュアップの定義は曖昧であり、当然ながら厳密さに欠けています。マッシュアップとは一体何かをよく理解するためには、この言葉の語源を調べてみることです。この言葉は、ポップ・ミュージックから借用したものなのです。ポップ・ミュージックの世界でのマッシュアップは、ソースとなる2つの別々の曲 (通常は異なるジャンル) から、ボーカル・トラックとインストゥルメント・トラックとをミックスして作られた新しい曲を言います。マッシュアップは、こうした「でっち上げポップ」の曲と同じように、コンテンツ(多くの場合は相互に無関係なデータ・ソースからのコンテンツ) を、風変わりに、あるいは革新的に合成し、(コンピューターではなく)人が利用することを目的に作られたものです。

では、マッシュアップは、どんな風に見えるのでしょうか。ChicagoCrime.orgの Web サイトは、地図のマッシュアップ (mapping mashup) と呼ばれるものを直感的に理解するための例として好適です。報道に登場した中で最初に幅広い人気を得たマッシュアップの1 つは、シカゴ警察 (Chicago Police Department) のオンライン・データベースからの犯罪データとGoogle Maps の地図とをマッシュする Web サイトです。ユーザーは、このマッシュアップ・サイトと対話動作を行うことができます。例えば、このサイトに指示を与えると、南シカゴで最近発生した強盗事件すべての詳細を虫ピンで示した地図がグラフィカルに表示されるのです。考え方と表示方法は単純ですが、犯罪データと地図データの合成は視覚的に強力です。

この先の、「マッシュアップのジャンル」のセクションでは、地図のマッシュアップを含めて、マッシュアップの一般的なジャンルについて調べます。「関連する技術」では、マッシュアップの構築とオペレーションに関係する技術的な展望の概略を説明します。「技術的な課題」「社会的な課題」では、マッシュアップに影響を与える、差し迫った技術的、社会的課題をそれぞれ取り上げます。

マッシュアップのジャンル

このセクションでは、主なマッシュアップのジャンルについて簡単に調べます。

地図のマッシュアップ

この情報技術の時代、人は、様々なモノや活動についての膨大な量のデータを収集しています。モノに関するデータも、活動についてのデータも、場所に関する注記を伴う場合が多いものです。こうした、位置データを含んだ多様なデータ・セットは、地図を使ってグラフィカルに表示されることを望んでいるのです。マッシュアップ登場の引き金となったものの1 つが、Google が導入した Google Maps API です。これによって、まるで堰を切ったかのように、Web開発者 (それに加えてホビーストや、何かをいじるのが好きな人達など) が、あらゆる種類のデータ(核による被害からボストンのカウパレードなど、何から何まで) を地図に結びつけたのです。対抗して、すぐに後から同様のAPI が、Microsoft (Virtual Earth) やYahoo (Yahoo Maps)、AOL (MapQuest)などから続きました。

ビデオと写真のマッシュアップ

最近登場してきた、写真のホスティングとソーシャル・ネットワーキングのサイト(Flickr など) は、写真を共有するための API を公開しています。これによって様々な興味深いマッシュアップが作られるようになりました。こうしたコンテンツのプロバイダーは、自分達のホストする画像に関連したメタデータ(誰が撮影したか、何の写真か、どこでいつ撮影されたか、など) を持っているため、マッシュアップの設計者達は、そうした写真と、そのメタデータと関連付け可能な他の情報とを結びつけることができます。例えば、マッシュアップが曲や歌詞を分析し、対象とする写真群のモザイクやコラージュを作成したり、あるいは写真の持つ共通メタデータ(主題やタイムスタンプ、他のメタデータなど) に基づいてソーシャル・ネットワーキングのグラフを表示したりする、などです。また別の例としては、Webサイト (例えば CNN のようなニュース・サイト) を入力し、タグ付けされた写真とニュースで使われている言葉との一致を検出して、そのテキストを写真の中に描画する、などがあります。

検索と買い物のマッシュアップ

検索と買い物のマッシュアップは、マッシュアップという言葉が作られるずっと前から存在していました。WebAPI が登場する前には、買い物用の価格比較ツール (BizRate や PriceGrabber、MySimon、そしてGoogle Froogle など) は、B2B (business-to-business) 技術の組み合わせ、あるいはスクリーン・スクレーピングを利用して、比較用の価格データをアグリゲートしていました。eBayや Amazon など、コンシューマー向けのマーケットは、マッシュアップを含めた興味深いWeb アプリケーションの導入を促進するために、自分たちの持つコンテンツにプログラムでアクセスするためのAPI をリリースしています。

ニュースのマッシュアップ

ニュース・ソース (New York Times や BBC、Reuters など) は 2002 年以降、RSSや Atom (次のセクションで説明します) などのシンジケーション技術を使って、様々な話題に関連したニュース・フィードを配信していきました。シンジケーション・フィードによるマッシュアップはユーザーのフィードをアグリゲートしてWeb 上に表示できるため、読者の、ある特定の関心事項に合わせてパーソナライズされた新聞を作成することができます。その1 つの例が Diggdot.us です。このサイトは、Digg.com や Slashdot.org、Del.icio.usなど、技術関係の人向けのニュース・ソースからのフィードを組み合わせています。

関連する技術

このセクションでは、マッシュアップの開発を促進する技術について概要を説明します。さらに詳細な情報については、この記事の最後にある参考文献を見てください。

アーキテクチャー

アーキテクチャー上は、マッシュアップ・アプリケーションは、API/コンテンツ・プロバイダーとマッシュアップ・サイト、そしてクライアントのWeb ブラウザーという、論理的にも物理的にもつながりのない 3 つの異なる要素から構成されています(これらの要素は多くの場合、ネットワークと構成上の両方の境界で分離されています)。

  • API/コンテンツ・プロバイダー。これらはマッシュアップの対象となるコンテンツを提供します(場合によると、自分では意識せずに提供していることもあります)。ChicagoCrime.orgのマッシュアップの例で言えば、プロバイダーは Google とシカゴ警察です。プロバイダーは多くの場合、データを取得しやすいように、自分たちのコンテンツをREST や Web Services、RSS/Atom などの Web プロトコル (下記で説明します)を通して公開しています。しかし、興味深いデータ・ソースとなりそうなソースの多くは、(まだ)手軽なAPI を公開していません。Wikipedia や TV Guide などのサイト、また政府関係やパブリック・ドメインのWeb サイトからコンテンツを抽出するマッシュアップではほぼ必ず、スクリーン・スクレーピングという手法を使ってコンテンツを抽出しています。この場合のスクリーン・スクレーピングが意味していることは、あるツールが、元々は人が利用すること前提にコンテンツ・プロバイダーが用意したWeb ページを構文解析して情報を抽出しようとするプロセスのことです。
  • マッシュアップ・サイト。マッシュアップは、ここでホストされます。興味深いことに、マッシュアップのロジックはここに置かれますが、その実行は必ずしもここで行われるとは限りません。マッシュアップは、一面では通常のWeb アプリケーションと同じように、サーバーサイドの動的コンテンツ生成技術(Java サーブレットや CGI、PHP、ASP など) を使って実装されます。

    また別の一面として、マッシュアップで作られるコンテンツは、クライアントサイドのスクリプト(つまり JavaScript) あるいはアプレットを使って、クライアントのブラウザー内で直接生成されます。クライアントサイドのロジックは多くの場合、マッシュアップのWeb ページに直接埋め込まれたコードと、こうした Web ページから参照される、(コンテンツ・プロバイダーが用意した) スクリプト API ライブラリーまたはアプレットの組み合わせです。この方式を使ったマッシュアップは、対話型のユーザー・エクスペリエンスを重視するという意味合いから、RIA(rich internet application) と呼ばれています。(RIA は、現在「Web 2.0」と呼ばれている、WorldWide Web で利用可能となる次世代サービスの重要な特質の1 つです。) クライアントサイドでのマッシングの利点として、マッシュアップ・サーバーのオーバーヘッドが少ないこと(データはコンテンツ・プロバイダーから直接取得できます)、シームレスなユーザー・エクスペリエンスが実現できること(ページ全体の更新を必要とせずに、そのページの一部分のコンテンツ更新をリクエストできます)があげられます。Google Maps API はブラウザー側の JavaScript からアクセスされることを想定しており、クライアントサイド技術の一例と言うことができます。

    マッシュアップは多くの場合、必要なデータのアグリゲーションを行うために、サーバーサイドとクライアントサイトのロジックを組み合わせています。多くのマッシュアップ・アプリケーションでは、自分たちのユーザー・ベースから直接与えられるデータを使い、データ・セットの(少なくとも) 1 つはローカルにしています。また、複数ソースにまたがるデータに対して複雑なクエリーを実行するためには(例えば「映画で Kevin Bacon と共演した俳優が購入した不動産の平均購入価格を見せる」など)、クライアントのWeb ブラウザー内では実行が不可能な計算を必要とします。

  • クライアントの Web ブラウザー。ここでアプリケーションがグラフィカルに描画され、ユーザーとの対話動作が行われます。上で説明した通り、マッシュアップは多くの場合、クライアントサイドのロジックを使って、マッシュアップの対象となるコンテンツを組み立て、合成します。

Ajax

Ajax という言葉が頭文字の組み合わせなのかどうかに関して、少しばかり議論があります(一部の人は、「Asynchronous JavaScript + XML」を表すのだと主張しています)。その議論は別として、Ajaxは特定な技術と言うよりは、Web アプリケーション・モデルと言うべきものです。Ajaxは、非同期なローディングとコンテンツ表示に焦点を当てた、次のようないくつかの技術から構成されています。

  • スタイル表示のための XHTML と CSS
  • 動的表示と対話動作のためにブラウザーが公開する DOM (Document Object Model) API
  • 非同期データ (通常は XML データ) の交換
  • ブラウザー側での (主に JavaScript を使っての) スクリプト記述

目標は、こうした技術を組み合わせることによって、ユーザーにとってスムースで一貫性のあるWeb 体験を実現することです。つまり何らかのユーザー・アクションが行われた後にページ全体をリロード、再描画するのではなく、少量のデータをコンテンツ・サーバーと交換するようにするのです。マッシュアップ用のAjax エンジンは、通常は JavaScript で実装される様々な Ajax ツールキットやライブラリー(例えば Sajax や Zimbra など) から構築することができます。Google Maps APIには独自の Ajax エンジンが含まれており、それによってユーザー・エクスペリエンスが大きく改善されています。つまりこのアプリケーションはまったくのローカル・アプリケーションのように動作し、操作用のスクロールバーや、強制的にページのリロードを行うための、変換の矢印もありません。

Web プロトコル: SOAP と REST

SOAP と REST は共に、リモート・サービスとコミュニケーションするための、プラットフォームに中立なプロトコルです。クライアントは、サービス指向アーキテクチャーという仕組みの一部としてSOAP と REST を使うことによって、リモート・サービスの基礎にあるプラットフォームの実装を知らなくてもリモート・サービスと対話動作することができます。つまりサービスの機能は、クライアントがリクエストし、またレスポンスとして受け取るメッセージの記述のみによって運ばれるのです。

SOAP は、Web サービスの基本的な技術です。SOAP という言葉は、元々は SimpleObject Access Protocol の頭文字をとったものでしたが、その後、Services-OrientedAccess Protocol (あるいは単に SOAP) と変えられました。これは、SOAP の焦点が、オブジェクト・ベースのシステムからメッセージ交換のインターオペラビリティーに移ったためです。SOAPの仕様には、2 つの重要な要素があります。その第 1 は、XML メッセージ・フォーマットを使うことでプラットフォームを意識しないエンコーディングを行うこと、そして第2 は、ヘッダーと本体から成る、そのメッセージ構造です。ヘッダーは、アプリケーションのペイロード(メッセージ本体) に固有ではない、コンテキスト情報 (認証情報など) の交換に使用されます。SOAPメッセージ本体は、アプリケーション固有のペイロードをカプセル化しています。Webサービスのための SOAP API は、WSDL 文書によって記述されます。WSDL 文書そのものは、そのサービスが公開するオペレーションの内容や、サービスが(XML Schema を使って) 受け付けるメッセージのフォーマット、そのサービスへの送付方法などを記述します。SOAPメッセージは通常、HTTP トランスポートを介して送られますが、他のトランスポート(JMS や E メールなど) も同じように使用することができます。

REST は、Representational State Transfer の頭文字をとったもので、Web ベースのコミュニケーションのための手法ですが、単純にHTTP と XML のみを使います。REST は単純であることや、厳密なプロファイルがないことなどからSOAP とは大きく異なりますが、それが魅力でもあります。最近のプログラミング言語に通常見られる動詞ベースのインターフェース(getEmployee() や addEmployee()、listEmployees など非常に多様なメソッドから構成されます)とは異なり、REST は基本的に、あらゆる種類の情報に適用可能な、ほんのいくつかの操作(つまり、POST、GET、PUT、DELETE) しかサポートしていません。REST が重視するのは、リソースと呼ばれる、情報そのものです。例えば、ある従業員に関するリソース・レコードはURI によって識別され、GET 操作によって取得され、PUT 操作によって更新され、という具合です。こうした点で、RESTは SOAP サービスのドキュメント・リテラル・スタイルと似ています。

スクリーン・スクレーピング

先ほど触れた通り、コンテンツ・プロバイダーが API を提供していない場合、マッシュアップの開発者は通常、スクリーン・スクレーピングという手段を使って自分たちがマッシュしようとする情報を取得します。スクレーピングは、元々は人が使用することを前提に書かれたコンテンツを、ソフトウェア・ツールを使って構文解析し、分析するプロセスです。このプロセスによって、そのコンテンツ情報を表現するセマンティック・データ構造や、プログラム的に使用、操作可能なデータ構造を抽出するのです。いくつかのマッシュアップは、特にパブリック・セクターから情報を引き出す場合には、データ取得のためにスクリーン・スクレーピング技術を使っています。例えば不動産用の地図マッシュアップでは、地図情報プロバイダーからの地図と、販売物件あるいは賃貸物件のリストを、その地域の記録保管オフィスから取得したデータをスクレープした「comp」データをマッシュアップします。データをスクレープしてマッシュアップを行う、もう1 つのプロジェクトとして、XMLTV があります。XMLTV は、世界中のテレビ番組表をアグリゲートするツールの集まりです。

スクリーン・スクレーピングは通常、あまり美しくないソリューションだと考えられており、それには十分な理由があります。つまりスクリーン・スクレーピングには、本来的に2 つの基本的な欠陥があるのです。その第 1 は、インターフェースを備えた APIとは異なり、スクレーピングの場合にはコンテンツ・プロバイダーと利用者との間にプログラムの契約が何もありません。スクレーパーは、ソース・コンテンツのモデルを前提にツールを構築しなければならず、またプロバイダーが常にこの表示モデルに従うであろう、と望むしかありません。しかしWeb サイトは新鮮さとカッコよさを維持するために、定期的にルック・アンド・フィールを全面変更することがあるものです。これが行われると、スクレーパーのツールは失敗してしまう可能性が高いため、スクレーパーにとっては維持管理が大きな頭痛の種になります。

2 番目の問題は、高度で再利用可能な、スクリーン・スクレーピング用のツールキット・ソフトウェア(よく scrAPI と呼ばれます) がないことです。このような API やツールキットが不足している大きな理由は、スクレーピング・ツールに要求されるものが、各アプリケーションによって大幅に異なるためです。これはつまり、設計者がコンテンツをリバース・エンジニアリングし、データ・モデルを開発し、プロバイダーのサイトからの生データを構文解析してアグリゲートせざるを得ないことを意味し、開発に大きなオーバーヘッドが要求されることになります。

セマンティック Web と RDF

スクリーン・スクレーピングが美しさに欠ける理由の根源は、人が利用することを前提に作成されたコンテンツは機械での自動利用に適していない、という点にあります。そこにセマンティックWeb が登場します。セマンティック Web では、既存の Web で人のために設計されたコンテンツを、それと等価な機械読み取り可能な情報で補強するという考え方をします。セマンティックWeb では、情報とデータとは異なります。つまりデータは、意味を伝える場合に(つまり理解可能なものとなった場合に)、初めて情報となります。セマンティックWeb の目標は、メタデータでデータを補強して意味を与える Web インフラを作成し、それによってデータを自動化や統合、推論、再利用などに適したものにすることです。

W3C の仕様ファミリーは 1 括りに RDF (Resource Description Framework) として知られていますが、こうした仕様は、データ記述用の構文構造の確立手段を提供するという、セマンティックWeb の目的に合致するものです。XML は、同じデータを記述するためにさまざまな方法でコーディングでき、自由度がありすぎるため、それ自体は十分なものではありません。RDF-Schemaを利用すると、機械読み取り可能な形で概念をエンコードする機能を RDF に追加することができます。データ・オブジェクトがデータ・モデルで記述できさえすれば、RDFは主語 (subject) - 述語 (predicate) - 目的語 (object) のトリプルを使って、データ・オブジェクト間に関係を構築することができます(例えば「主語 S が目的語 O と R という関係を持つ」など)。データ・モデルと関係のグラフを組み合わせると、オントロジー(ontology) を作成することができます。オントロジーは、検索可能で正式な推論の対象となる、知識の階層構造です。例えば、「肉食型」は他の「動物型」を「食べる」という制約を使って、「肉食型」を「動物型」のサブクラスとするモデルを定義し、このモデルのインスタンスを2 つ作ることができます。例えば、1 つのインスタンスはチーターとシロクマと、その生息地のデータを持ち、もう1 つのインスタンスはガゼル (訳注: ウシ科の動物) とペンギンと、その生息地のデータを持つようにします。そうすると推論エンジンは、こうした別々のモデル・インスタンスを「マッシュ」し、チーターはガゼルを食べるかもしれないがペンギンは食べないだろう、と推論します。

RDF データは、ソーシャル・ネットワーキングのアプリケーション (FOAF つまりFriend of a Friend など) や、シンディケーション (例えば次に説明する RSS)など、様々な領域で急速に採り入れられています。また、RDF に関するソフトウェア技術やコンポーネントは、特にRDF クエリー言語 (RDQL や SPARQL など) やプログラム的なフレームワーク、推論エンジン(Jena や Redland など) の領域では、成熟レベルに達しつつあります。

RSS と ATOM

RSS は、XML ベースのシンディケーション・フォーマットの一群です。ここで言うシンディケーションの意味は、コンテンツを配布しようとするWeb サイトが RSS 文書を作成し、その文書を RSS パブリッシャーに登録することです。そうするとRSS 対応のクライアントは、パブリッシャーのフィードをチェックして新しいコンテンツを探し、そして適切な方法で反応します。RSSは、ニュースの記事や見出しから CVS チェックイン用の変更ログ、wiki ページ、プロジェクトの更新、さらにはラジオのプログラムなどのAV データに至るまで、非常に幅広いコンテンツのシンディケートに採用されています。バージョン1.0 は RDF をベースにしていますが、最新のバージョン 2.0 は RDF ベースではありません。

Atom は RSS よりも新しいものですが、RSS に似た配信プロトコルです。Atomは IETF (Internet Engineering Task Force) で提案されている標準として、RSSよりも優れたメタデータを維持し、より優れた、より厳密なドキュメンテーションを提供しようとしており、共通データ表現のための構成体という概念を採り入れています。

こうしたシンディケーション技術は、ニュースやウェブログのアグリゲーターなど、イベント・ベース、あるいはアップデート・ドリブンのコンテンツをアグリゲートするマッシュアップにとって、素晴らしい技術と言うことができます。

技術的な課題

他のデータ統合分野の場合と同様、マッシュアップの開発にも技術的な課題が山積しており、特にマッシュアップ・アプリケーションの機能が充実するにつれ、その課題も増大しています。このセクションでは、こうした課題のいくつかに触れることにします。こうした課題の一部は対応可能であり、また問題を緩和することもできますが、現状では解決方法がないものもあります。

データ統合に関する課題: セマンティックな意味合いとデータの品質

定性的な調査によると、エンタープライズ IT にとって最大の懸念事項は、企業の仮想組織内でのデータ統合です。(この場合の仮想組織は、それぞれが独自の管理ドメインに含まれるビジネス・ユニットを連合させた組織、という意味です。)レガシー・データ・ソースの統合という作業 (例えば現在のビジネス状況を反映したコーポレート・ダッシュボードを作成する、など)に携わる多くのエンタープライズ IT マネージャーと同様、マッシュアップ開発者も、異種混成のデータ・セットの間に共有されているセマンティックな意味を引き出すという、似たような問題に直面しています。従って、マッシュアップ開発者が抱えている課題の感覚をつかむためには、これまで繰り返し語られてきた、エンタープライズITが直面する統合への課題を調べれば十分なのです。

例えば、データ・モデル間での変換システムを設計する必要があります。データを共通の形式に変換する際、マッピングが完全ではない場合には、適切な想定を行わざるをえないことが多いものです(例えば、ある 1 つのデータ・ソースは住所型に国フィールドが含まれるモデルを持っており、別のデータ・ソースのモデルはそれとは異なるかもしれません)。さらに困難さを増す要因として、マッシュアップ開発者はソース・データ・モデルのドメイン・エキスパートではないかもしれないのです。彼らにとってそのモデルはサード・パーティーであり、適当な想定と言われても、直感的、明確には分からないかもしれません。

データが不足している、あるいはマッピングが不完全であることに加えて、統合しようとしているデータが機械による自動化に向いていないこと、つまりデータ・クレンジングが必要であるということが、判明してしまうかもしれません。例えば、警察による逮捕記録は一般的な名前を省略する場合があるため、入力に一貫性が欠けているかもしれません(例えば、ある記録では「Market Square」と入力されており、別の記録では略して「mktsqr」と入力されているなど)。そのため、適切なヒューリスティックを使ったとしても、それらが等価なものであることを自動推論することは難しいかもしれません。RDFのようなセマンティック・モデリング技術は、データ・ストアに組み込まれてさえいれば、異なるデータ・セット間での自動推論の問題を緩和できる可能性があります。レガシー・データ・ソースをセマンティック・モデリング技術で利用できるようにするまでには、分析やデータ・クレンジングの面で、人による努力が大きく要求される場合が多いと考えられます。

またマッシュアップの開発者は、IT 統合のマネージャーには無縁な、いくつかの問題に対処する必要があるかもしれません。その1 つがデータ汚染 (data pollution) です。マッシュアップでは多くの場合、アプリケーション設計の一部として、公開のユーザー入力を要求します。Wikiアプリケーションの場合に見られるように、これは両刃の剣です。誰もが貢献でき、最高のデータ進化が期待できることから非常に強力である一方、一貫性のない、不正確な、意図的に誤解を招くデータが入力される可能性もあります。後者はデータの信頼性を揺るがす元になり、最終的には、そのマッシュアップが提供する価値を損なうことになります。

スクリーン・スクレーピング技術を使ってデータ取得を行おうとする場合にも、マッシュアップ開発者は統合に関して山のような問題に直面します。この前のセクションで説明した通り、構文解析やデータ取得用のツールやデータ・モデルを作り出すためには、大がかりなリバース・エンジニアリング作業が必要です。そうしたツールやモデルを運良く作成できる場合でも、ソースとなるサイトがコンテンツの提示方法を変更してしまえば(あるいはコンテンツを廃止したり破棄したりすれば) 、統合プロセスは破壊され、マッシュアップ・アプリケーションは失敗してしまいます。

コンポーネントに関する課題

Ajax モデルによる Web 開発では、これまでのようなフルページの更新よりも表現力豊かな、よりシームレスなユーザー・エクスペリエンスを実現できますが、同時にいくつかの問題も起きてきます。基本的にAjax は、その DOM モデルと共にブラウザーのクライアントサイドのスクリプティング機能を使うことによって、ブラウザーの設計者が想定したものと完全に同じではないコンテンツ配信を実現します。(この、ハッカーのような性格が Ajax の魅力かもしれません。) しかしこのためにAjax ベースのアプリケーションは、Microsoft が Internet Explorer を作成して以来Web 設計者を悩ませてきた、ブラウザーの互換性問題に直面することになります。例えばAjax エンジンは、XMLHttpRequst オブジェクトを使ってリモート・サーバーと非同期にデータを交換します。しかしInternet Explorer 6 の場合、このオブジェクトはネイティブの JavaScript ではなくActiveX を使って実装されています。つまり ActiveX が有効になっている必要があるのです。

もっと基本的な問題として、Ajax では、ユーザーのブラウザーで JavaScriptが有効になっている必要があります。これは、大部分の場合には妥当な想定かもしれませんが、JavaScriptをサポートしていない、あるいは有効にしていないブラウザーや自動ツールを使うユーザーが必ずいるものです。そうしたツールの中には、インターネットやサーチ・エンジン用にデータをアグリゲートするロボットやスパイダー、Webクローラーなどもあります。Ajax ベースのマッシュアップ・アプリケーションは、何も不手際がなかったとしても、ほとんど使う人がなく、サーチ・エンジンからも見えなくなってしまう可能性があります。

JavaScript を使ってページ内のコンテンツを非同期に更新しようとすると、ユーザー・インターフェースの問題も起きてきます。コンテンツは必ずしもブラウザーのアドレス・バー上のURL にリンクされているとは限らないため、ユーザーが「戻る」ボタンや「ブックマーク」機能を使用した場合、通常それらを使用した場合とは異なる動作になるかもしれません。また、Ajaxではコンテンツの更新をインクリメンタルに要求することで待ち時間を短縮できますが、設計が悪いと更新のキメが細かくなりすぎ、利用可能なリソースが更新の量やオーバーヘッドによって飽和してしまうため、実際にはユーザー・エクスペリエンスが悪化する可能性があります。また、インターフェースがロードされる際やコンテンツが更新される際には、ユーザーを十分サポートするように注意する必要があります(例えばプログレス・バーを使って視覚的なフィードバックを与える、など)。

分散型でクロスドメインの他のアプリケーションの場合と同様、マッシュアップの開発者やコンテンツ・プロバイダーは、セキュリティーの問題にも対応する必要があります。これまでのWeb は基本的に匿名アクセスを前提に構築されているため、ユーザー識別 (identity)という概念は面倒です。シングル・サインオンは望ましい機能ですが、 (MicrosoftPassport から Liberty Alliance に至るまで) 互いに競合する無数の技術があるため、互いに無関係な、ユーザー識別のための名前空間が作られてしまい、これも統合しなければならなくなります。コンテンツ・プロバイダーは多くの場合、認証と承認のための仕組みをAPI に採用することによって、有償購読や重要なデータを含むビジネス・モデルを強制しています(こうした仕組みは、セキュアなユーザー識別や、セキュアに識別できる属性を要求します)。重要なデータには、機密性(つまり暗号化) も要求される可能性が高いものです。従って、他のソースとマッシュする場合には、そうしたデータを危険にさらさないために十分な注意が必要です。また、監査や規制準拠のためにも、ユーザー識別は必須です。さらに、データ統合はサーバーサイドとクライアントサイドの両方で起こるため、ユーザー識別情報と資格情報をユーザーからマッシュアップ・サービスに委譲するように要求される可能性もあります。

社会的な課題

マッシュアップがさらに一般的になるにつれ、前のセクションで説明した技術的な課題の他に、社会的な問題が表面化しています(あるいは表面化してくるでしょう)。

マッシュアップ開発者が直面する最大の社会的課題は、知的財産と利用者のプライバシーに対する保護を、情報の公正利用と自由な流通と、どのようにバランスをとるか、という問題です。知らないうちにコンテンツ・プロバイダーとなっているもの(スクリーン・スクレーピングの対象が正にそうです) や、あるいはデータが容易に取得できるようAPI を公開しているコンテンツ・プロバイダーでさえ、自分たちが承認しがたい形でコンテンツが使用されている、と判断するかもしれません。Webアグリゲーションと規制に関して知るためには、参考文献にあげた資料を見てください。

マッシュアップ Web アプリケーションはまだ幼児期の段階にあり、ホビイスト開発者が暇な時間を利用して多くのマッシュアップを作成しています。こうした開発者は、セキュリティーなどの問題を意識していない(あるいは気にしていない) かもしれません。またコンテンツ・プロバイダーは、機械ベースのコンテンツ・アクセス用にAPI を提供する価値を理解し始めたばかりであり、多くのプロバイダーは、そうしたアプリケーションを中核的なビジネスとして考慮していません。こうした条件が組み合わさると、ソフトウェアの品質はお粗末なものになります。概念検証や革新に重きを置かれてしまうと、テストや品質保証は末席に控えざるを得ません。成熟したソフトウェア開発プロセスを実現し、またオープンな標準や再利用可能なツールキットを作るためには、コミュニティー全体が協力して取り組む必要があります。

マッシュアップが、カッコ良いオモチャの段階から高度なアプリケーションに移行するためには、しっかりとした標準やプロトコル、モデル、ツールキットなどを作り上げるための、大きな努力が必要です。そのためには、ソフトウェア開発業界の主要リーダーやコンテンツ・プロバイダー、起業家などが、有力なビジネス・モデルとしての価値をマッシュアップに見いだす必要があります。APIのプロバイダーは、自分たちのコンテンツに課金するのか否か、もし課金する場合にはその方法(サブスクリプション課金か使用毎の課金か) を決定する必要があります。恐らく彼らは、様々なレベルのサービス品質を提供するでしょう。eBayや Amazon など一部のマーケット・プロバイダーは、自分たちの API を無料で使わせた方が製品の動きを活発にできると思うかもしれません。またマッシュアップ開発者は、広告に基づく収入モデルを模索するかもしれず、あるいは買収されることを目標に、興味深いアプリケーションを構築するかもしれません。

まとめ

マッシュアップは、確かに興奮すべき新ジャンルの Web アプリケーションです。セマンティックWeb の領域から生まれたデータ・モデリング技術を組み合わせることによって、また、疎結合でサービス指向、プラットフォームを意識しないコミュニケーション・プロトコルが成熟したことによって、Web上で利用可能な膨大な情報を活用、統合するアプリケーションの開発に必要なインフラが、いよいよ整い始めました。マッシュアップ・アプリケーションの可能性が明確になるにつれ、公正な使用や知的財産といった社会的な問題に対して、またグリッド・コンピューティングや企業間ワークフロー管理など、組織境界にまたがってデータを統合する他のアプリケーション・ドメインに対して、このジャンルがどのような影響を与えるのか興味があるところです。

マッシュアップ開発に関してさらに詳しく知るためには、developerWorks でこれから始まる新しいチュートリアル・シリーズに期待してください。そこでは、皆さん独自のマッシュアップをどのように構築するかについて解説します。またこのシリーズでは、セマンティックWeb 技術とオントロジーを使うことによって、他の人も独自のマッシュアップを作成できることを解説する予定です。


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


関連トピック


コメント

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=XML, Web development
ArticleID=239896
ArticleTitle=マッシュアップ: 新種の Web アプリケーション
publish-date=07242009