さらにごたごた書きました

id:yellow_73:20100223 で、ごちゃごちゃ書いたら、id:hfu:20100224 で、反応していただきました。なんというか、すみません、読みきれてないし、何かもやっとした書きぶりだったもので。

私が必死になって噛み付いているのは、「良いアイデアをがんばって出して」というところですので、噛み千切りたくてウズウズしているわけではありません。見通しをよくするのは非常に重要だということは、同じ考えです。
なお、「がんばって出して」と他人事にしているところは、ごめんなさい、という他ないです。

しかし、私を含む、アプリケーション開発者としては「自分のアプリケーションの開発ができるかどうか」が問題のすべてです。
WMSがなんだかなーと思いながらも、ライブラリとかでなんとかしてしまったので、「わざわざ乗り換えることもない」と思っている、ってことになりません?
WMS捨てたら、すげー良くなった!」と言わせられるのかどうか、そこがポイントでしょう。
# 本気でGeoWebCache止めてTMSにした方が楽かも知んないと思った「事件」が、最近、ありました。現在はどうするか検討中。
# でも、WMSの廃止は、実際面を考えると、ありません;-)

2つの大きそうなシステムが生きていなければいけないようであるところが、ちょっと不安な場合がある気がします。

それは遠くない未来に解決されます、かなり高い確率で。
ていうか散々良い意味で裏切られてきてます:-)
ハードウェアの高性能化、低価格化で解決できる話で終わってたら、GeoServer + GeoWebCache から離れる人は多くないんじゃないかなと。

RPC->REST->RPC という変換をしているようなものであり、これは見通しが良くありません。

見通しの話としては、まさにおっしゃる通り。
計算量は大差ないという意味です。
# それこそ私の文の「見通し」が悪かったといったところか…。

話が前後したうえ、引用が長くなるのでさわやかに引用せずにしますが、お考えのモデルについて。
すみません、私はどうも読みきれていないです。
画像生成キューの要素はサーバが生成するのでしょうか?そうだとするなら、何がトリガとなって生成されるのでしょうか?
また、サーバが多数存在する場合、あるサーバは画像を画像生成PCから受け取りますが、他のサーバはどういう動きをするのでしょうか?
# 私の都合で、地図じゃなくて他のデータ加工・配送モデルを考えようかな、と思ってましてね…。