WSGI/Rack/PSGIの登場の背景
何番煎じ変わりませんが、WSGI/Rack/PSGIに関して、何でこれらが必要とされるようになったのか、歴史的経緯を踏まえて色々調べたので、記録しておきます。ただし、特に歴史的な話に関しては、ネットで自分が納得できるまで探りはしましたが、正確性を欠くかもしれません*1。間違っていたらご指摘下さい。
実行環境の多様化とWAFの乱立
結論としては、この見出しがWSGI/Rack/PSGIが生まれることとなった動機といえます。
実行環境の多様化
私が小学生ぐらいの頃、20世紀終盤でしょうか、通信速度も今に比べ格段に遅く、多分スケーラビリティなんて考えも浸透していなかった頃、WebアプリといえばCGIでPerlな時代がありました*2。そんな頃の実行環境はレガシーなApacheとmod_cgiでした。
しかし、時代と共に、数多くのリクエストを捌くことが要求されるようになると、CGIでリクエスト時に毎回行われるインタプリタ起動〜セットアップのオーバーヘッドが馬鹿にならなくなりました。それを改善しようと現れたのがFastCGIとmod_perlです。
FastCGIはCGIと同様にインターフェース仕様で、バージョン1の仕様は、1996年にFixしているようです。CGIは標準入出力をI/Oとしたインターフェースで、サーバーとアプリケーションがかなり疎結合なので、実行可能*3にする以外に言語側で特別な対応をする必要はありません。一方、FastCGIは、一度メモリ上に展開したプロセスを殺さず何度も使おうという方針で、プロセス間でTCP通信を行うようなので、言語ごとに仕様を実装する必要があります。実装例としては、Perlの場合はFCGI、Pythonの場合はflupが挙げられます。
mod_perlは、Apacheに直接インタプリタを組み込んでしまえ、というアプローチで、公式サイトの概要によると、最初の実装はFastCGIと同様に1996年となっています。少し細かい話になりますが、mod_perlを使う場合は、Apache2系モジュールを使う必要があるようです（参考1, 参考2）。そして以後、Perl以外についてもmod_pythonやmod_rubyなどが実装されることとなります*4。
ここまで実行環境に関する変遷に触れてきましたが、重要なのは、実行環境が変わると、Webアプリケーション側も何かしらの対応が必要という点です。CGIなら先頭行、FastCGIならFCGIモジュール、mod_perlならApache2系モジュール、といった感じです。これは、他の言語においても同様です。
WAFの乱立と実行環境依存、からのWSGI/Rack/PSGI
またまたその昔、Pythonでは大量のWAF（Web Application Framework）が乱立した時期があったようです。その数は100を超えたのだとか（参考）。
この時、問題となったのが、前述の実行環境の問題です。全てのWAFがあらゆる実行環境に対応してくれれば良いのですが、当然そんなはずもなく、また、その接続部分は完全に車輪の再発明状態になってしまいます。
そこで現れたのが、WAFと実行環境の接続部分の統一的なインターフェースを定めたWSGIです。読みはウィズギーらしいです（汗。図を見ればWSGIの概念は一発で分かるかと思うのですが書くのが面倒なので、このサイトの2つの図*5を参照してください。双方がWSGIに対応すれば、任意のWAFが任意の実行環境で実行出来るようになるわけですね。素晴らしい。
その後、WSGIはRubyのRack、PerlのPSGIへとインスパイアされていくこととなり現在に至りましたとさ。めでたしめでたし。
