はじめに
前回は，メッセージボードアプリケーションを作成し，実際のWSGIアプリケーションについて見てきました。 WSGI を使用した Web アプリケーションの作成がどのようなものかわかって頂けたかと思います。
今回は， WSGIの仕組みの中でも重要な，「ミドルウェア」という概念を取り上げます。「ミドルウェア」はアプリケーションの機能をコンポーネント化し，コードの再利用性を高めるための概念です。このように書くと，少し難しいもののように思えるかもしれませんが，その仕組みは非常に簡単なものです。
まずは，「ミドルウェア」の概念について説明します。
ミドルウェアとは
ミドルウェアとは，サーバとWSGIアプリケーションの両方のインターフェースを持つオブジェクトです。そのため，Webサーバ側からはWSGIアプリケーションのように見え，WSGIアプリケーション側からはWebサーバのように見えます。ミドルウェアは図1のようにサーバとアプリケーションの中間に位置し，Webサーバからのリクエストに対する処理と，アプリケーションからのレスポンスに対する処理を行います。
たとえば
- リクエストURLに応じたアプリケーションのマッピング
- ユーザ認証
- レスポンスヘッダへの情報追加
- アプリケーションで生成された動的コンテンツのキャッシュ
といったような処理です。
図1 ミドルウェアの動作概念
図1では，WebサーバとWSGIアプリケーションの間にミドルウェアの層が幾つも重なっています。ミドルウェアは，それ自身がWSGIアプリケーションのように振る舞うため，「ミドルウェアが呼び出したアプリケーションがミドルウェアで，そのミドルウェアが呼び出したアプリケーションがまたミドルウェアで…」と最終的にWSGIアプリケーションが呼び出されるまで続きます。このミドルウェアの連鎖をミドルウェアスタックといいます。
実際のミドルウェア
ここで，簡単なミドルウェアを例に，処理の流れを追ってみます。
今回は，
- 何もしないミドルウェア
- URLマッピングを行うミドルウェア
の2種類です。
今回使用するサンプルのソースはmiddleware.zip（ZIP圧縮）にあります。適宜ダウンロードしてください。
今回は，第1回，第2回で使用したsample1.pyとmessage.pyを使用しています。middleware.zipにはそれらも含まれているので，展開して同じディレクトリに置いてください。
実行は前回と同様に
$ python middleware.py
とします。
実行した後に，http://localhost:8080/の/helloと/messageにアクセスすると，それぞれ第1回，第2回で作成したアプリケーションが実行されます。それ以外のURLにアクセスした場合は，404エラーが返ってきます。
図2 /hello にアクセスしたとき
図3 /message にアクセスしたとき
図4 それ以外にアクセスしたとき
何もしないミドルウェアも使用していますが，文字通り何もしないので変化がなく，ブラウザからアクセスしても変化はわかりません。確認はソース上のみで可能です。
それでは，それぞれのミドルウェアのソースを見ていきます。
