リッチクライアントよりもステートレスクライアント

＠ITのリッチクライアントコンファレンスのパネルに出てからちょっとこのテーマについて考えています（出る前に考えろよ＞自分 ＾＾;）。

クライアントのアーキテクチャ（ここでは、ソフトウェアの構築方式のこと）で、シンvsファットvsリッチという区分は実はあんまり本質的ではないのではと思ったりします。本当に大事なのはステートレスなのかステートフルなのかということであって、可能な限りクライアントはステートレスにすべきと思うわけです。ステートフルであると、サーバ側とのデータ不整合の問題を常に考えなければいけないわけで、システムの設計や運用が一気に難しくなります。ファット・クライアントがまずいのはファットであることが理由というよりも、ステートフルであることが理由で、これによりクライアント側のプログラム管理というきわめてやっかいな問題が生じてしまったわけです。逆の言い方をすれば、シン・クライアントの良さはシン（軽量）であることよりも、ステートレスであることから来るわけです。

リッチクライアントを構築する時も可能な限り、ステートレス性をめざさないと、名前が違うだけで実はファット・クライアントと同じになってしまいますよね。もちろん、例外的にステートフルにしなければならないケースもあるとは思いますが（たとえば、オフラインでも稼働させたい場合）、基本はステートレスに作るべきだと思います。

ステートレスかステートフルかの問題はデータベース処理なんかでも結構重要です。広域分散でステートフルな処理をするのは、レイテンシ（遅延）と障害対応の点で非常につらいものがあると思います。

ちょっと前に、サンのCIOのBill Vass氏にアナリストのイベントでインタビューした時もグリッド関係でこの辺の話になりました。「そもそもグリッドにはステートレス型とステートフル型があって...」というところから話が始まって、さすがにわかってらっしゃると思いました。OLTPなんかのステートフルな処理は密結合のクラスタ型で（それをグリッドと呼ぶかどうかは別として）行い、余剰の能力を広域ネットワーク経由でステートレスな処理（典型的には計算中心処理）向けに販売するというモデルがサンのグリッドの実装方式のようです。前から、こういう風に実装するしかないんだろうなーと思っていましたが、まさにその通りだったわけです。