Thursday, March 26, 2015

Handle Cross Cutting Concerns with an OWIN MidFunc

This post picks up where my post Why Write (OWIN) 'Middleware' in Web Applications? left off, and starts digging into writting OWIN middleware.

OWIN Middleware is a Function

OWIN middleware is a function, which makes perfect sense considering this Pipes and Filters like diagram from the last OWIN port:


The pieces of middleware are functions that request and response data flow through.

Middleware is a Curried Function

The traditional way of looking a the function signature of OWIN middleware a bit daunting1. I find it easier to think of middleware as curried functions that takes two arguments - one at a time - the first argument being the next piece of middleware in the pipeline and the second a dictionary containing the request and the response data:



The middleware function can do whatever it wants to the request and response data before and after calling the next part of the pipeline - which is the function passed into the 'next' argument.

Handling a Simple Cross Cutting Concern

A simple thing that most people building an SOA system want to do across all services is request logging. A simple piece of OWIN middleware can handle this quite niicely like this:



Put this middleware at the beginning of the OWIN pipeline and all requests and all request execution times will be logged.

Summing up

OWIN middleware is most easily (I find) understood as simple curried function taking two parameters: The next step in the pipeline and an environment dictionary containing all request and response data.
Next time we will look a packaging this up nicely in a library that makes it easy to drop this middleware into your pipeline.




1. The middleware function is usually presented as

or this shorthand version