Curlとアーキテクチャ（１）〜リッチクライアント〜

curlアプリケーションの設計方法などといったテーマについてなかなか書けずにいます。その理由が、自分にとって単に難し過ぎるからなのか、それともただ億劫なだけなのか、はっきり自覚のないまましばらくモヤモヤしていました。

しかし最近徐々に、別の大きな理由があると思うようになってきています。それは、curlを使ったシステム全体におけるアーキテクチャや、それを説明するための用語といったものが（少なくとも身の回りでは）まだまだ曖昧なことです。そもそも議論の前提となるコンテキストについて、curl開発者の間でも理解が不十分かもしれません。

そこで今回から数回に渡り、アーキテクチャの側面からcurlについて整理、おさらいをしてみたいと思います。今後、より有意義な議論を展開するための足場固めの意味を込めて。

そもそもcurlはリッチクライアントの技術だと説明されます。これはシステムの特徴をクライアント端末に着目して見た場合の用語です。
まず、システムのアーキテクチャがクライアントサーバ時代のアプリケーションがファットクライアントと呼ばれます。この名前は、クライアント上でビジネスロジックが処理され、ユーザに豊かな操作性を備えたインターフェースを提供する一方、アプリケーション配布の困難さが保守コストに重くのしかかってくることに由来します。

これに対し、アプリケーションがサーバ上で一元管理でき、保守コストが抑えられるWebアプリケーションのことをシンクライアントと呼びます。WebアプリケーションのユーザインターフェースはWebブラウザ上のHTMLであり、クライアント上では基本的に表示と入力の受け付けのみしか行えません。

そしてリッチクライアントです。クライアント上での高度な処理と優れたユーザインターフェースというファットクライアントのメリットと、サーバ上での一元管理というシンクライアントのメリットを兼ね備えるとされています。

これらの分類とその説明は、クライアント、つまりユーザが直接操作する端末に着目しているという点で、どちらかとゆうとユーザよりの視点になっています。

一方で、リッチクライアントとゆうのは開発者にとっても新しい形態のアプリケーションです。その開発においては、少なからず新しい考え方が要求されるわけです。

とりわけ、1990年代から始まって今なお主流であるシンクライアント（Webアプリケーション）との違いが混乱のもとになっている場面によく出くわします。（過去の日記でもこれについて一部触れていますので見てみてください）

そこで次回からは、Webアプリケーションとcurl（リッチクライアント）の違いに焦点をあてていこうと思います。

余談
ファットクライアントに対する「クライアントサーバ」、シンクライアントに対する「Webアプリケーション」のような、開発者視点での用語はリッチクライアントに対してはないんでしょうか？出来ればRich Internet Application以外希望･･･