アーカイブ

第8章 8.サーバ側マッシュアップ

公開日：2007年6月28日

独立行政法人情報処理推進機構
セキュリティセンター

本ページの情報は2007年6月時点のものです。
記載の資料は資料公開当時のもので、現在は公開されていないものも含みます。

サーバ側マッシュアップには、クライアント側マッシュアップと比べたとき、長所と短所がある。

クライアントデバイスが行うネットワーク通信を必要最小限にとどめることができる。クライアントデバイスが性能の高くない場合、特に有利にはたらく。

クライアント側JavaScriptコードから素材サーバに直接アクセスする場合に生じる「他源泉リクエスト」の制約は、サーバ側マッシュアップにおいては存在しない。ただし、素材サーバと通信するリスクの考慮と対策は必要である。

主催者サーバ上において、素材サーバのひとつからの悪意あるデータの供給を検出・排除して、関連する他のブラウザ、ユーザ、別の素材サーバ等を保護する仕組みを構えることができる（保護策を不特定多数のクライアントデバイスに委ねる方法に比べて確実性が高い）
クライアントデバイスにロードされるJavaScriptコードの量を抑えることができる（これによって、ユーザに暴露されるソースコードの量が少なくなる）
素材サーバの運営者から発行を受けた「APIキー」を、ユーザに知られずに済む

ゲストリソースを取得する形態が、Webサービスの呼び出しや、WebページのHTMLから情報を抜き出す「Webスクレイピング」の手法に限定される
クライアント側JavaScriptコードで供給される形態のマッシュアップAPIや、HTMLで記述された画面の構成部品が供給される形態のマッシュアップAPIの呼び出しには適さない

クライアント側マッシュアップよりも高度な知識を要する案件もあれば、より簡単な案件もありうる。
高度な知識を要する論点として、「セキュリティトークンとOAuth 2.0」等がある。

サーバ側においてゲストリソースが統合される度合いは、次の4段階に分けることができる。

これらのうち中央の「ダッシュボード」「リソース間連携」の二種類は、「マッシュアップ」と呼ぶのにとくに適している。反面、「プロキシ」は統合の度合いが低すぎ、逆に「融合」は高すぎるため、「マッシュアップ」と呼ぶのは必ずしも適当でない。

これら4段階は次のようなものである。

統合を全くせず中継のみ行うもの
クライアント側コードが、他源泉リクエストを発行せずに異なる複数の源泉からゲストリソースを取得できる仕組みのみ実現したもので、各源泉から取り込まれたゲストリソースは、サーバ上における統合が一切行われることなくクライアントへ渡される

ゲストリソースを原型に近い形で複数並べ、それらの間にユーザインタフェースの動作の連携の仕組みをもたせるもの
複数源泉から取り込まれるゲストリソースを、同時に目視できるよう並列に配置もしくは、段階的に閲覧できるよう階層的に配置したコンテンツにするとともに、それらの相互間で意味のあるユーザインタフェースの動作の連携が行われる
各ゲストリソースは、見た目が変えられないか、元の形を著しく変えない範囲で整形されて表示される
ユーザインタフェースの動作の連携の仕方には、例えば、次のようなものが考えられる──リストのエントリを選ぶと別の源泉から得られた地図/主題図の上の該当する複数地点がプロットされる、地図/主題図上のポイントを選ぶとその地点の詳細情報が別の源泉から取り出されて表示される、等

サーバ側マッシュアップを行う手段には、次の複数のものがあり、難易度も多様である。

インターネットに公開されているマッシュアップエディタWebサイトを用いる
- 例：
  Yahoo Pipes
企業内向けのマッシュアップ支援製品のマッシュアップエディタを用いる
- 例：
  Oracle社の WebCenter Portal
  富士通社のマッシュアップフレームワーク
一般的なWebアプリケーション開発環境で開発する（例： Geronimo上のSpringフレームワーク）