[論文レビュー] IVOA Recommendation: SAMP - Simple Application Messaging Protocol Version 1.3

Mark Taylor, T. Boch+5 more|arXiv (Cornell University)|Oct 3, 2011

Web Application Security Vulnerabilities参考文献 4被引用数 20

ひとこと要約

この IVOA の勧告では、SAMP 1.3 を規定しており、中央ハブを介して非同期的・イベント駆動的・RPCに類似した通信を可能にするメッセージングプロトコルを提供する。これは、前回の PLASTIC と比較して、名前付きパラメータ、構造化されたデータ型（文字列、リスト、マップ）、およびデスクトップおよびウェブ環境におけるハブ発見およびクライアント登録のための標準化されたロックファイルメカニズムを用いることで、セキュリティ、拡張性、型安全性を向上させている。

ABSTRACT

SAMP is a messaging protocol that enables astronomy software tools to interoperate and communicate. IVOA members have recognised that building a monolithic tool that attempts to fulfil all the requirements of all users is impractical, and it is a better use of our limited resources to enable individual tools to work together better. One element of this is defining common file formats for the exchange of data between different applications. Another important component is a messaging system that enables the applications to share data and take advantage of each other's functionality. SAMP builds on the success of a prior messaging protocol, PLASTIC, which has been in use since 2006 in over a dozen astronomy applications and has proven popular with users and developers. It is also intended to form a framework for more general messaging requirements.

研究の動機と目的

• 独立して開発された天文学ソフトウェアツール間のシームレスな相互運用性を実現し、モノリシック統合を必要としないこと。
• PLASTICプロトコルの限界、特に弱い型付け、セキュリティの低いアイデンティティ管理、拡張性の欠如を是正すること。
• デスクトップおよびウェブベースのアプリケーションの両方をサポートする、標準化され、言語に依存しないアプリケーションメッセージングフレームワークを提供すること。
• 公開IDと非公開IDの分離および構造化エラーハンドリングを通じて、セキュリティを強化すること。
• 標準化された MType（メッセージタイプ）語彙と拡張可能なデータ構造を用いた拡張性の向上。

提案手法

• クライアント間の発行/購読およびRPCスタイル通信のためのメッセージブローカーとして中央ハブを用いる。
• 文字列、リスト、マップの3つのコア型のみを用いる最小限で拡張可能なデータモデルを定義し、数値および論理値を文字列としてエンコードする規則を設ける。
• ハブ発見のための標準化されたロックファイル（.samp）を導入し、言語およびOSに依存しない場所とパース規則を定義する。
• 標準（デスクトップ）およびWeb（ブラウザベース）の2つのプロファイルをサポートし、それぞれ異なる通信パターンとセキュリティ上の配慮を要する。
• 位置パラメータ（リスト）ではなく名前付きパラメータ（マップ）を採用することで、明確性、拡張性、オプション引数のサポートが向上する。
• メッセージの意味論を形式的に定義する MType システムを定義し、拡張可能な語彙と予約済み名前空間（x-samp）を用いて将来的な拡張を可能にする。

実験結果

リサーチクエスチョン

• RQ1 モノリシック統合を要しないで、緩く結合された天文学ソフトウェアツールが効果的に相互運用できるようにするにはどうすればよいか？
• RQ2 PLASTICプロトコルの限界、とりわけセキュリティ、型付け、拡張性の面で、どのようなアーキテクチャ的およびプロトコルレベルの改善が必要か？
• RQ3 メッセージングプロトコルが、一貫した意味論と安全な通信を備えたデスクトップおよびウェブベースのアプリケーションを両方サポートするにはどうすればよいか？
• RQ4 異なるオペレーティングシステムおよびプログラミング言語間で、信頼性の高いハブ発見およびクライアント登録を保証するメカニズムは何か？
• RQ5 天文学ソフトウェア統合の進化するユースケースをサポートするため、メッセージの意味論を標準化し、拡張可能にするにはどうすればよいか？

主な発見

• SAMP 1.3 は、中央ハブを介して独立して開発された天文学アプリケーション間の相互運用性を実現する、安全で拡張可能なメッセージングフレームワークを導入した。
• プロトコルは、位置パラメータ（リスト）の代わりに名前付きパラメータ（マップ）を採用することで、PLASTIC に比べて可読性が向上し、オプション引数のサポートも向上した。
• 表示用の公開IDとルーティング用の非公開IDを分離することで、アプリケーションスプーフィングを防止し、セキュリティが著しく向上した。
• 標準化された .samp ロックファイルの導入により、Windows を含むあらゆるプラットフォームで一貫したハブ発見が可能になり、言語に依存しないパースが可能になった。
• Web プロファイルにより、HTTP および URL ベースのメッセージルーティングを用いた安全なブラウザベース通信が可能になり、SAMP の適用範囲がデスクトップアプリケーションを越えて拡張された。
• ハブがクライアントの代わりにエラー応答（例：samp.noresponse）を生成および転送できるようになったことで、分散通信におけるエラーハンドリングと信頼性が向上した。