A while back I wrote down some of my hesitations about using WSGI middleware as components in a poor-man's component architecture .

Since I wrote that, it seems like the lure of logically coupling WSGI middleware with the application it sits in front of is a pattern which is just too seductive to resist, so rather than ignore this pattern, we might as well acknowledge it. As such, I think it's useful to give this sort of middleware a name. For lack of a better term, I'm going to call it "endware". "Endware" is middleware which, when removed from the WSGI pipeline, will cause the application to either a) not work or b) behave significantly differently. As such, it's logically more a part of your application than it is a part of the pipeline that invokes your application. It seems to usually sit quite close to the application (aka the "right hand side") of the pipeline, and often it bumps up right against the application itself (the "end" of the pipeline).

I've created my share of middleware which is more logically "endware": repoze.tm2 which manages transactions, and repoze.who which provides authentication services to applications are two examples. Beaker is a sessioning and caching component that can act as middleware and is also "endware".

I think if you put "endware" in your WSGI application stack, you should probably mark it clearly as such. It might make sense to make its configuration separate from that more purely-isomorphic-middleware that Phillip had in mind when he documented the concept. Maybe in a different configuration file, or maybe in pure Python.