locked
Difference between OWIN spec and ASP.NET vNext! RRS feed

  • Question

  • User-329865136 posted

    There are the following two "interface" according to OWIN spec:

    • Environment Dictionary: IDictionary<string, object>
    • AppFunc: Func<IDictionary<string, object>, Task>

    In Microsoft.AspNet.Hosting, it seems they two are replaced with the following:

    • HttpContext (Not the one in System.Web.dll)
    • RequestDelegate: delegate Task RequestDelegate (HttpContext context);

    Why is the hosting related API not designed following OWIN spec, like Katana.

    Wednesday, November 26, 2014 9:36 PM

All replies

  • User-782232518 posted

    The author of "OWIN and Microsoft Katana 101" left a few hints on his blog,

    PS. With Katana, there are a couple of ways of writing a middleware class: using AppFunc, which is the recommended way and using OwinMiddleware class. Although using OwinMiddleware class is not a recommended practice, even the out-of-box middleware from Katana does use this. But with ASP.NET vNext, all middleware consistently use RequestDelegate and HttpContext.

    https://lbadri.wordpress.com/2014/11/01/asp-net-vnext-middleware-versus-owinkatana-middleware/

    Thinktecture Identity model has support for Eran Hammer’s Hawk authentication in the form of OWIN middleware. With ASP.NET vNext introducing a new but very similar middleware concept (changes only on the API surface and OWIN middleware can be used as-is in ASP.NET VNext apps), I took the opportunity to completely rewrite the middleware. As ASP.NET vNext is being actively developed, there could be changes and this middleware will change to react to those changes. Hence, at this point, this middleware is just for review only. Since Linus had said “Talk is cheap. Show me the code.”, I keep this blog post very short and just link to github. Your feedback is welcome.

    https://lbadri.wordpress.com/2014/10/28/asp-net-vnext-middleware-for-hawk-authentication-an-experiment/

    Thus, Microsoft is not completely throwing away OWIN, but just carries out a few changes on the API surface. I personally think the changes are in favor of legacy code migration (to minimize code changes in existing code), but that's only my guess.

    Wednesday, November 26, 2014 10:26 PM
  • User-329865136 posted

    From Eilon Lipton @Microsoft:

    Hi Jiang Jin Nan,

     

    The middleware pipeline in ASP.NET 5 (formerly called ASP.NET vNext) is not based on OWIN, but is considered an *evolution* of Katana. Katana was based on OWIN. However, despite this difference, it is important to note that the pipeline in ASP.NET 5 is *inspired* by OWIN and Katana. We received feedback after Katana and decided to take a similar, but different approach in ASP.NET 5. One of the difficulties in OWIN was that there were no “strong” types for most common concepts, though Katana tried to simplify that by adding “strong” types. But this then caused some compatibility issues between “pure” OWIN and Katana.

     

    In ASP.NET 5 the approach we took was to have a very similar *model* for the middleware pipeline, but to use new strong types to represent the request, response, and related HTTP concepts. We think that this is easier to understand and easier to use. And for anyone wanting to use existing (or new) OWN middleware, we built a compatibility layer to allow OWIN middleware to be used in ASP.NET 5.

     

    Our team has written a couple of blog posts regarding OWIN, Katana, and ASP.NET 5. Hopefully the content in these blog posts will provide you with even more information and background.

     

    The first is a blog post from Louis, one of the developers on ASP.NET 5: http://whereslou.com/2014/06/10/asp-net-vnext-moving-parts-owin/

     

    The second is a blog post from Chris, another developer on ASP.NET 5: http://blogs.msdn.com/b/webdev/archive/2014/11/14/katana-asp-net-5-and-bridging-the-gap.aspx

     

    Please let me know if you have further questions!

     

    Thanks,

    Eilon

    Thursday, November 27, 2014 4:16 AM
  • User-1611549905 posted

    Unfortunately Badri's post contains one or two outdated statements. In particular, he says that IAppBuilder is the recommended way of building OWIN applications. It isn't.

    The reason that Katana uses IAppBuilder is that it was included in an old, pre-release version of the OWIN specification. It was removed from the spec after version 0.12.0 and is now considered deprecated. Its repo on GitHub contains a specific instruction that new OWIN applications should not use it.

    The reason for this is that the intent of the OWIN specification is to make it possible to build an OWIN application without referencing any external dependencies whatsoever other than the base class libraries. You should just be able to pass an AppFunc (that is, Func<IDictionary<string, object>, Task>) to the OWIN host and leave it to do the rest.

    What Katana -- and the new ASP.NET middleware -- gives you is a bunch of strongly typed wrappers around the OWIN specification.

    The problem is that Microsoft's introductory OWIN tutorials don't make this clear. Because it's all introduced in terms of Katana, you'd be forgiven for thinking that OWIN and Katana are one and the same. It took me quite a while to figure this one out.

    Here's a blog post I wrote about my understanding of it once I'd somehow managed to unpick it:

    Thursday, November 27, 2014 4:41 AM