Microsoft’s new Web Server, Katana, Hits Version 3
Katana is Microsoft’s stand-alone implementation of OWIN, the Open Interface for .NET standard. It provides a lightweight alternative to IIS and System.Web when those features are not needed or desirable. With the release of version 3, Kanata is wholly to the asynchronous model offered by .NET 4.5.
Microsoft’s deprecation of .NET 4.0 support in Katana is not surprising. Whilst .NET has had asynchronous support since NET 2.0’s IAsyncResult model, Node.js appears to have gained all the mindshare. Microsoft may well be hoping to reverse the trend with .NET 4.5's async/await model.
Furthermore, Microsoft is trying to dramatically reduce its maintenance burden by moving developers off older versions .NET by early 2016. Making it clear that new APIs won’t be offered for .NET 4.0 goes a long way to accomplishing that goal.
In terms of new functionality, mostly they concentrated on “enterprise grade authentication and claims based identity”. Vittorio Bertocci of the Katana 3 project mentioned these three protocols specifically:
- OpenId Connect (id_token and id_token+code, via form_post)
- OAuth2 bearer token authentication for Web API
Vittorio also wrote,
This release includes fixes for issues related to Twitter and Google API changes. If you have an app using Google authentication and you are updating to Katana 3, please make sure you read this post!
Katana is available via NuGet. According to the Katana website, there are over 20 packages to choose from depending on which features you need. (Contrast this to classic ASP.NET where almost everything was crammed into one massive assembly.)
- Microsoft.Owin - Provides a set of helper types and abstractions for simplifying the creation of OWIN components.
- Microsoft.Owin.Diagnostics - Provides middleware components to assist in developing OWIN-based applications.
- Microsoft.Owin.FileSystems - This package contains file system abstractions and implementations.
- Microsoft.Owin.Testing - Provides helper classes for unit testing OWIN components.
- Microsoft.Owin.SelfHost - Includes components needed to host an OWIN-based application in a custom process.
- Microsoft.Owin.Hosting - Provides default infrastructure types for hosting and running OWIN-based applications.
- OwinHost - Provides a stand-alone executable (OwinHost.exe) which can be used to host an OWIN-based application.
- Microsoft.Owin.Cors - This package contains the components to enable Cross-Origin Resource Sharing (CORS) in OWIN middleware.
- Microsoft.Owin.StaticFiles - This package contains OWIN middleware that handle requests for file system resources including files and directories.
- Microsoft.Owin.Security - Common types which are shared by the various authentication middleware components.
- Microsoft.Owin.Security.ActiveDirectory - Middleware that enables an application to use Microsoft's technology for authentication.
- Microsoft.Owin.Security.Cookies - Middleware that enables an application to use cookie based authentication, similar to ASP.NET's forms authentication.
- Microsoft.Owin.Security.Facebook - Middleware that enables an application to support Facebook's OAuth 2.0 authentication workflow.
- Microsoft.Owin.Security.Google - Contains middlewares to support Google's OpenId and OAuth 2.0 authentication workflows.
- Microsoft.Owin.Security.Jwt - Middleware that enables an application to protect and validate JSON Web Tokens.
- Microsoft.Owin.Security.MicrosoftAccount - Middleware that enables an application to support the Microsoft Account authentication workflow.
- Microsoft.Owin.Security.OAuth - Middleware that enables an application to support any standard OAuth 2.0 authentication workflow.
- Microsoft.Owin.Security.OpenIdConnect - Middleware that enables an application to use OpenIdConnect for authentication.
- Microsoft.Owin.Security.Twitter - Middleware that enables an application to support Twitter's OAuth 2.0 authentication workflow.
- Microsoft.Owin.Security.WsFederation - Middleware that enables an application to use WsFederation for authentication.
- Microsoft.Owin.Host.HttpListener - OWIN server built on the .NET Framework's HttpListener class. Currently the default server used for self-hosting.
- Microsoft.Owin.Host.SystemWeb - OWIN server that enables OWIN-based applications to run on IIS using the ASP.NET request pipeline.
Composability is key
The Task model is composable in C# (OO + language extensions) but there are still some differences between the two.
IAsyncResult fairs better in many cases. See tomasp.net/blog/csharp-async-gotchas.aspx/
Re: Composability is key
#1. The author seems to be confused about the difference between asynchronous and concurrent.
Thankfully there is a compiler warning to let you know something is wrong with that pattern.
#2. Ok, this one makes no sense to me. He praises F#'s compiler warning, then ignores the same warning that C# offers?
#3. Using asynchronous actions from event handlers such as Button_Click is a really important use case. And that use case requires supporting void return types or a bunch of boiler-plate code (F# Async.Start) that amounts to the same thing.
#4. This one is marginal. I agree that it can be a bit of pitfall, but the fact that you can't await the result of Parallel.For is a pretty big hint that you shouldn't be trying to use it for Async.
Thankfully it is pretty easy to write a ForAsync and ForEachAsync function that is awaitable.
#5. An interesting trick, but really it is so contrived I can't imagine anyone writing that by mistake.
Really, why would anyone intentionally try to await a method that semantically means "run this concurrently on the thread pool"?
#6. So he's complaining that the method for waiting for a task to complete is called Wait instead of RunSynchronously?
I would be more inclined to complain about he opposite. The operation is, from its own perspective, still running asynchronously. The fact that a thread is blocked waiting for it doesn't change that, though it does introduce possible deadlocking issues.
Re: Composability is key
Thomas is just pointing out that F# async does not suffer from the same issues (agree some points could be a bit moot).
Another C# issue is that await cannot be used in catch blocks which leads to awkward code, sometimes. Again no such issues with F# async (which is really just monad++ function composition under the covers).
I think its great that C# is getting many of the F# features. However more C# developers should be made aware that better-integrated versions of such features already exist in F# so that they can make more informed decisions.
The reverse is also true. F# has benefitted from many C# / .Net enhancements such as LINQ and Reactive Extensions but the overall experience remains at par or better in almost all cases (although there are some exceptions).