サーバーサイドのプログラムを構築するための、下地となるプログラム単位(とすべきものとして(Sunによって?)位置付けられてる)であるクラス。それ自体は、「要求(Request)」を寄越されたら「返答(Response)」を返す、というプログラムモデルであり、そういう処理をするメソッド1つを、自分が望む処理でオーバーライドすれば、おおまかに言えば、やる(やれる)ことはそれでおしまいである。オブジェクト指向っぽさは希薄。Servletは星の数ほど有るであろうサーバーサイド用アーキテクチャのうちの1つをサポートしてるだけであり、しかもそれはCGIっぽい非オブジェクト指向的な(入力→処理→出力という)アーキテクチャである。特定のオブジェクトの世間とのお付き合いを制御(=Controller)するわけでもない。羊頭狗肉というかなんというか、間違いであるような気しか、(俺には)しない。Servlet自体は、MVC(もし作りたいならば)の、足回りの更に足回り(笑)くらいの非常に低レベルな位置付けのものだろう。実際、JSPやその他の多くの上位(?)技術の土台になってる。JSPは、内部的にServletクラスを直接継承して作られるクラスなので、ServletのMVCからの遠さと同じくらいに、JSPもまたMVCから遠い、と思う。MVC(のView?)の下地の下地だ。--戯こんなプログラムモデルなのだが、上記のオーバーライドされるメソッドはクラスメソッドではなくインスタンスメソッドである。JavaServletは、状態を持たない(ことが期待される)のに、インスタンスをわざわざ作るのである。(作る行為自体はServletエンジンが自動的にやってくれる、とはいえ...)どうにも恰好悪い。Javaの限界(笑)のせいだろう。APIを明示的に呼ばない限り)多態できない」せいだろう。「Request」や「Response」、あるいはユーザがサーバにコンニチワしてる単位である「Session」、などといったオブジェクトである。それらに束縛しておく(ユーザ任意の)オブジェクト。Servlet「が」世界(MVC、特にModel)を持っているわけではない。Servlet自体はあくまで、要求に応じて一瞬の処理を受け持つだけだ。この「ユーザ任意」の部分に色々なオブジェクトを乗っけることで、Servlet上に構築された各種技術は、MVC(あるいはモドキ)を実装することになる。ModelやViewやControllerを乗っけようとするフレームワークが色々有る。--戯Servletでは、要求とかがHttpに根ざしているかどうかは別問題。Httpを捌くように仕込まれたHttpServletというクラスがあり、それを使えばプログラムはHttp対応版だ、というわけだ。実際には、こんな風にあたかも「お気軽にPluggableに差し替え可能」であるかのような誤解(笑)を招く文を書いてしまうと、大嘘なのだが。そこまで柔軟ではない。ページから参照されています。