RESTと比べて、RPCはシステムの柔らかな下腹部を曝しがちなモデルなのではないか

d:id:yellow_73:20100223 ありがとうございます。これに触発されて、私の考えをいくつか補完してみたいと思います。

サーバとクライアントの役割をひっくり返す話は安全地域での画像生成に限定した話のつもりでした

画像生成のキューがサーバから提供されていて、中断可能な分散クライアントが適宜キューからタスクを取得し、クライアントがサーバからソースデータを取り込んで分散して画像生成し、サーバに地図画像を戻すモデル
http://d.hatena.ne.jp/hfu/20100218/1266437151

について、

クライアントを信用できるかどうかが重要です。
http://d.hatena.ne.jp/yellow_73/20100223#p1

とありますが、これはおっしゃるとおりです。上記のモデルは、サービスの完全に後方で、スタティックに提供する画像を生成する「地図画像生成」の際に適切なモデルとして、考えたものでした。そのあたりの私の説明が不足していたと思います。
後方での「地図画像生成」においては、閉じた LAN の中で自分が用意した画像生成クライアントをぶら下げる訳ですから、「クライアントが信用できる」ことは、前提条件となります。

そもそも一方向の流れをぶった切ると、そうとう話がややこしくなります。
http://d.hatena.ne.jp/yellow_73/20100223#p1

とありますが、「地図画像生成」において、あえて一方向のバッチ的な流れをぶった切ることが、このモデルの目的なのです。キューはクライアントがタスクを取りに来るまではひたすらクライアントを待ち、クライアントがタスクを求めてくればタスクを渡し、タスクの結果が戻されればタスクを消し、一定時間以上戻されなければキューにタスクを戻します。タスクとタスクの間は独立なので、多数のクライアントが、分散してタスクを処理することができます。このようにして、処理の流れをぶった切り、キューという「ため」を作ることで、サーバが知らないうちにクライアントを増やしたり減らしたりしやすくなります（サーバのアドレスを知る必要があるのはクライアントであって、クライアントのアドレスをサーバが把握する必要はありません）。
キューの減り具合を見て、画像生成に思いのほか時間が掛かることが判明し、その対策として画像生成クライアントを増やしたりしたいわけですが、この方式だと、「増やさなければ」と思ってからクライアントを用意しはじめることすら可能です。WMS を常識的に使う方式では、画像要求クライアントをいったん止めて、WMS サーバリストを更新してからクライアントを再起動するという流れになり、クライアントを増やすごとに全タスクを止めることになります。
この違いは、画像生成PCを２台から3台に替えるときには小さいかもしれませんが、12台を13台に替えるときには大きいです。というのは、WMS を常識的に増やす方式では、1台を増やすために、12台を止める必要がある恐れが大きいからです。

「地図画像生成とそれの配送を分離すれば十分」はまさに本質

地図画像生成とそれの配送を分離すれば十分
http://d.hatena.ne.jp/yellow_73/20100223#p1

というのは、まさに本質だと思います。ちょうどタイムリーに arton さんがお歌いになっているように、

ソウ
ヒットミーヒットミーヒットヒットヒット
ヒットヒット
バットレスタマンフィールズノーペイン
コズ
キャッシュミーキャッシュミーキャッシュキャッシュキャッシュ
http://www.artonx.org/diary/20100223.html#p01

という、ところだと思います。

ただ、GeoServer と GeoWebCache という二匹の象がともに生きていなければインターネットサービスが動かない（想像）というのは制約なのではないか

ただ、GeoServer + GeoWebCache システムだと、インターネットに曝されるサービスの真裏で、GeoServer と GeoWebCache という２つの大きそうなシステムが生きていなければいけないようであるところが、ちょっと不安な場合がある気がします。
GeoWebCache で GeoServer をインターネットから間接的に切り離すくらいであれば、TMS のように完全スタティックなファイル（リソース）を介して画像生成システムをインターネットから完全に切り離すほうが思い切りが良いように見えます。
もちろん、GeoServer で提供する情報が頻繁に書き換わるようなもので、その書き換えが、GeoServer が得意とする RDBMS 等で行われているのであれば、GeoServer + GeoWebCache のほうが TMS よりも運用しやすいかも知れないと思います。

RPCとRESTはたぶん等価書き換えが可能。ただしアフォードするものが違う。

REST的アプローチとRPC的アプローチとのどちらを選ぶかは、あくまで設計思想の差、サービスの見通しやすさのための選択なんでないかと。計算量ではないんじゃないかと。
http://d.hatena.ne.jp/yellow_73/20100223#p1

RPC 的アプローチである WMS にキャッシュの概念を後付けしたもの(GeoWebCache的構成)と、画像生成→静的ファイルという構成（TMS的構成）は、使用する CPU time を等価にすることができると思います。
違いはまさに「見通しやすさ」だと思います。GeoWebCache 的構成は、その成り立ちの時点でひねり（キャッシュという HTTP=REST 的層の挿入）が入っています。せっかくいったんキャッシュにしているのに、外から見ると WMS に見えるように RPC のインタフェースを守り抜いていて（ですよね？）、RPC->REST->RPC という変換をしているようなものであり、これは見通しが良くありません。

RESTは外に対する約束が小さいので、RPCと比べてまさに気楽なのでは？

追加の問題点として、RPC、特に WMS くらいにパラメータ数が増えてしまった RPC では、サービスの実装者がケアしなければならない項目が多くなるという問題点があるのではないでしょうか。例えば、WMS で CRS/SRS という座標系を示すパラメータがありますが、HTTP GET Request としてはあそこに任意の文字列が入ることが許されます。リクエストに入ってきたパラメータが想定される文字列であるかどうかを判断し、想定される文字列であればそれに合わせた処理をし、そうでなければエラーメッセージを出す、ということをサービスの実装者がケアしなければなりません（しかも全てのパラメータ、さらにはその組合せについて）。
一方、TMS であれば、そもそも CRS/SRS はリクエスト時点で合意されていることが前提なので、例外のハンドリングは、素の HTTP サーバか(404 NOT FOUND, 400 BAD REQUEST etc.)、又は妙な場合にはクライアントが、実施することになります。
例えば、SRS=EPSG:900913 と来たときにどう反応すべきかを考えることは、すべての WMS サーバの義務ですが、TMS サーバの義務ではありません。
REST は、想定される入力は全てリソースとしてあらかじめ（必ずしもあらかじめではないかもしれませんが、基本的な考え方としてあらかじめ）決めておく思想であり、RPC は、想定される入力に対して動的に（必ずしも動的ではないかもしれませんが、基本的な考え方として動的に）備えておく思想なのかなと思います。
REST には、「あらかじめ決めておき、決めていないものは単に見つからない」という気楽さがあり、RPC には「想定されているものに対しては、全て備えておかなければならない」という悲壮さがあるような気がします。
この「見通しやすさ」の違いが積み重なれば、単なる「見通しやすさ」の違いだったものが、システムが実現できるサービスの「規模」なり「高度さ」なりの「できる・できない」の違いに転化してしまうのではないかと思っています。
このあたりも考慮して、サービスのビルディングブロックとして RPC モデルのものを選ぶか REST モデルのものを選ぶかを考えるべきではないかと思っています。