WebDAVより高機能でACAPより軽量

2007.12.18

　前回で述べたように，XCAP以外にもサーバーのデータを書き換えるプロトコルはいくつか存在する。なぜ，これらのプロトコルではなく，わざわざ新プロトコルのXCAPが考えられたのだろうか。疑問に思うのが普通だろう。答えは，今のネットワークが求める仕様を過不足なく満たすプロトコルが他になかったからである。

　最も普及したデータ操作プロトコルとして，HTTPを拡張したWebDAVがある。WebDAVは，サーバー上のファイルやフォルダを操作するためのプロトコルであり，サーバー上でのファイルコピーなどの機能を備えるものの，ファイル内部の部分的な参照や書き換えはできない。そもそもWebサーバー上のコンテンツ・ファイルの更新を目的として生まれたWebDAVは，ファイル内の一部の項目だけを参照したり変更したりする用途を想定していなかったのである。

　一方，普及はしなかったものの，WebDAVより高機能なプロトコルとして一時注目を集めたものにACAPがある。その歴史は古く，1990年代からIETFのACAP WGにて議論が進められてきた。アプリケーションの設定情報を遠隔で操作するプロトコルを目指したものだ。

　実のところ，ACAPはXCAPのモデルとなったプロトコルである。ACAPは，“重い”プロトコルとして知られる「IMAP」を基本としていた。IMAPはサーバー上にあるメール・データの閲覧や削除，検索などが可能なプロトコルだが，1990年代のハードウエアには重すぎた。すべての機能を実装するのは大変な作業で，パフォーマンスを確保するのも一苦労。事実，製品での採用はなかなか進まなかった。今でこそIMAPも多くのメール・サーバー/クライアントが実装しているが，そのIMAPを手本としたACAPはIMAPと同じ弱点を抱えたままだった。

　また，ACAPが出現した当時にわき起こったシン・クライアント・ブームが，ACAPにとって逆風となった面も否めない。ACAPはサーバーにアプリケーションの設定ファイルなどを置くことで，どこからでも同じ環境が利用できるのが最大のメリット。ところがサーバー上にアプリケーションの設定データを置くより，アプリケーションそのものをサーバー上に置くアプローチが脚光を浴びてしまった。

　多機能だが実装が難しく処理も重いACAPは，1990年代後半のシン・クライアント・ブームの前に，結局盛り上がりに欠けたまま，忘れられていった。

XMLとHTTPの採用が単純化のカギ

　WebDAVより高機能，ACAPより軽量なプロトコルであることに意義があるXCAPは，IMAPをベースとしたACAPが複雑となった反省を踏まえ，シンプルなやり取りでデータ操作を過不足なく実装できるプロトコルとして策定された。

　まずデータ転送については，HTTPが持つ機能のうち，わずか3種類のリクエストを使用するシンプルな方式とした（表1）。XCAPのシステムは，XCAPドキュメントの変更リクエストを送るXCAPクライアントと，リクエストを受け付けてレスポンスを返すXCAPサーバーから成る（図1）。XCAPクライアントは，ドキュメントの変更個所をURIにより指定し，変更内容をHTTPのBODY部として送る。サーバーは変更が成功/失敗した旨を伝える応答を返す。

表1●XCAPで利用するHTTP 1.1メソッド

図1●XCAPによるプレゼンス管理システム
HTTPとXMLでプレゼンス・リストを管理する。

　データ形式については，XMLを採用した。構造化されたテキスト・データであるXMLドキュメントは，共通的な方法でアクセスすることが容易だからだ。また今日では，アプリケーションのデータや設定情報においてXML形式を採用するケースは珍しくない。

　こうしてXCAPは，アプリケーション設定情報となるXMLドキュメント（XCAPドキュメントと呼ぶ）の全体，あるいは一部を参照・更新するプロトコルとして設計された。その適用範囲は，データをXMLとして持つアプリケーションすべてに及ぶ。

アプリケーションごとにXML構造を定義

　XMLは，データだけでなく，その構造や意味をタグという形で記述することで，データ交換や処理における柔軟性を高めた言語である。構造や意味を定義する方法は定めているものの，そのアプリケーションに依存したデータ構造や各項目のルールはアプリケーションやシステムの間で共通化する必要がある。仕様としてはシンプルなXCAPだが，XMLファイルの構造の定義が必要になる。

　XCAPにおいては，アプリケーション固有のルールを「アプリケーション用法」（Application Usage）と呼ぶ。アプリケーションごとに固有のXMLスキーマを用意して定義する。これはXMLデータ操作としては一般的な手法だ。

　アプリケーション用法は，アプリケーションごとに固有のIDである「AUID」（Application Unique ID）によって一意に識別する。AUIDとしては，XCAPサーバーが持つ機能の一覧やプレゼンスのリソース・リストなどがRFC4825～4827で規定されており，インターネット資源の割り当てと調整を行うICANNの下部組織であるIANAに登録されているものが利用できる（表2）。企業内などでは独自アドレスの使用も可能だ。ベンダー独自のAUIDは，AUIDを作成する組織名称の逆ドメイン名から始まる文字列である。たとえば，「softfront.co.jp」が「foo」というアプリケーション用に定めたAUIDは，「jp.co.softfront.foo」となる。

表2●IANAに登録されているアプリケーション固有のID（AUID）
http://www.iana.org/assignments/xcap-parametersで公開されている。