Webアプリケーションのマッシュアップおよびクロスドメイン通信のアーキテクチャ、分類
あらかじめ、結構勝手な観点から語った内容なので、その辺ご容赦ください。
Webアプリケーションのマッシュアップおよびクロスドメイン通信のアーキテクチャについて、一度文章として整理してみたほうがよいかなと思ったので、まとめてみる。まず前提として、この議論における主体は３種類に分類されている。*1
- マッシュアップWebアプリケーション
- Webサービスプロバイダの提供するデータを利用したサービスを提供する主体。
- Webサービスプロバイダ
- 元となるデータをWeb経由で配信するサービス主体。マッシュアップWebアプリとは異なるサイト（ドメイン）で提供されるものとする。
- ユーザ
- 実際にWebブラウザを開いて上記のサービスを利用する主体。
マッシュアップ実現のためには、このうちのどれか１つがクロスドメイン通信に協力的である必要がある。
以下、それぞれの場合について詳細および利点／欠点を挙げる。
マッシュアップWebアプリケーションがクロスドメイン通信に協力的である場合
いわゆる、Cross-Domain Proxyを設置する方法による。ユーザからのリクエストを受け取り、代理でWebサービスプロバイダに送信し、レスポンスを返す。ここでは広義にプロトコルおよびデータ変換が含まれるものも含める。
利点
Webサービスプロバイダがクロスドメイン通信に協力的である場合
ここで「協力的である」とは、マッシュアップWebアプリケーションにクロスドメイン通信のために特殊な実装／運用負荷を与えないための配慮がなされているという観点で語る。具体的にはマッシュアップサービス側のサーバを介さず、ブラウザから直接マッシュアップするクライアントサイドマッシュアップを可能にするインターフェースを実装しているものとする。
ブラウザ上でのクライアントサイドマッシュアップの実現方法として、JSONP、crossdomain.xml、iframe fragment identifier、window.name などがある。その他 XMLHttpRequest level 2, XDomainRequest, Cross-document messaging、などがあるが個々については省略する。
欠点
- 実現方式が多様で一定していない。
- 各実現方式は、現状 ugly hackであるか、将来の規格であるためブラウザの対応およびその普及が未知数
ユーザ側がマッシュアップに協力的である場合
クロスドメインのマッシュアップ実現のために標準ブラウザ以外の機能、具体的にはGreasemonkey, AIR, Gearsなどを利用する。この場合、Webサービスプロバイダ、マッシュアップWebアプリの双方が非協力的であっても、マッシュアップは可能になる*2（例：はてなブックマークやdel.icio.usコメントをページに埋め込むGreasemonkeyスクリプト）
ユーザ側が協力するべきこととして、ブラウザ拡張のようなソフトウェアをクライアントに事前インストールする形式が予期されるが、そこまで行かない場合もある。たとえばWebサービスプロバイダ側が協力的であるような場合においては、マッシュアップWebアプリが非協力的であってもユーザ側の若干の協力によりマッシュアップが達成できる場合がある。具体的にはブックマークレットが用いられる。（例：iKnowブックマークレット）
利点
欠点
- ユーザ側の事前準備に対する協力が必要になる（Greasemonkey, AIR, Gearsのインストール、ブックマークレット登録など）ため、サービスとしてのスケール力が弱い。
- マッシュアップできるデータの対象はユーザ自身がアクセス権限をもつ情報のみに限定される*3。
