リソース指向なgeo+webのサブクラス - Relevant, Timely, and Accurate

リソース指向なgeo+webのサブクラスの定義を試みます。
convivial-weblog さんから。

RESTfulは、リソース指向的な考えに基づいたアーキテクチャなので、何かしらの処理を関数的に実行させたい場合などは、RPC（Remote Procedure Call）的に呼び出せる「なんちゃってREST」の方が適しているケースも多いように思います。
http://convivial-web.com/blog/2009/03/restrestful.html

関数的に呼び出す形のものはやはり RPC 的にしておくのがよさそうだと思っています。OGC の規格でよくある、引き出し対象を任意の矩形で指定するようなパターンは、典型的に RPC 的なパターンであると考えており、あのパターンを RESTful にすることは至難だと思います。

geo+web の特徴の分析から、そのような RPC パターンを使わないですむ問題のクラスがあると思っています。具体的には、次のような条件が満たせる場合、地理空間情報をRPC的にインタフェースする必然性は薄く、RESTful にインタフェースしておいたほうが嬉しいことが多いと思っています。

情報をキー・バリューペアとしてアクセスできるように*1まとめておくこと
表現の更新は書き込み時に行うこと

前者は、範囲を任意矩形で呼び出すようなことはやめて、適切にサイズ設計されたタイルによって地理空間情報を空間的に束ねておくことで実現できます。

後者の根拠は、地理空間情報はブログエントリや価格情報、ブックマークエントリなどと比べて、データ内容の更新頻度がはるかに低く、逆に表現の作成に時間コストがかかるため、リソース要求時に表現を作成するよりは、ソースデータが更新されたときに表現を作成しておく方が格段に合理的と考えるためです。書き込み時に表現を作成するよう考える*2ことで、RPC 的ではなくて RESTful に考えることが容易になってきます*3。

でもこれは当たり前のこと

なんだか高度なことを言っている・未来的なことを言っているように聞こえる人もいるかもしれませんが、それは業界の文化の影響を受けていることが原因かもしれません。一般のアクセスにさらされている「ふつうの」地図サービス*4は、必ず、しかも昔からこの形式の実現方法をとっているように見えます。

ではなぜ INSPIRE は SOAP (RPC) を捨てないのか

INSPIRE は基本的に行政内部利用だけの GeoWeb であり、そのため、目指しているのはたぶんユーザ数が30,000くらいまでなので、RPC的で十分であると考えているのではないでしょうか。また、情報の更新頻度が高くて秘匿性もある情報もたぶん含まれるので、そうすると enterprisey にがっちりしたデータベースで地理空間情報を一元管理して、表現は都度生成したいという誘惑があると思います。
INSPIRE が一般アクセスを考え始めるころに、問題が出てくるかも知れません。システムが複雑化することになると思います。そのため、一般アクセスを少しでも考えるシステム担当者は、INSPIRE のアーキテクチャ設計を盲目的には参考にすべきではないと思っています。

*1:たぶん、RESTful の文脈で「リソースとしてアクセスできるように」というのと同じだと思います

*2:即物的には、Apache の DocumentRoot の下のディレクトリに、ソースデータの更新をトリガーにして画像ファイルを作っておく。lazy evaluation の逆ですが、アクセスが多い場合には、勤勉に表現を on-write に作っておく方がシステム全体としては怠惰になります。

*3:HTTP のレベルでリソース指向なのと、サーバ上でほんとにファイルベースであることとは独立したものであるとも思うのですが、リソース指向とファイルベースが同時に成立している状況が、思考実験のためにはとても考えやすいとも思っています。

*4:MapionとかGoogle MapsとかYahooの地図とか電子国土とか