OWIN and Katana: What the Func <T>?
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 170 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/50538 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Focus (optics)Information securityOpen sourcePhysical systemSoftware frameworkCodeServer (computing)AbstractionExtension (kinesiology)Software frameworkWeightForm (programming)CodeRight angleInternetworkingProgramming paradigmCartesian coordinate systemEndliche ModelltheorieShift operatorWeb applicationSoftware developerProjective planeState of matterPhysical systemLocal ringLimit (category theory)Web 2.0Wave packetTexture mappingComputing platformBitMathematicsQuicksortRevision controlMultiplication signOrientation (vector space)Ocean currentComputer programmingModule (mathematics)Server (computing)Library (computing)CASE <Informatik>Source codeEuler anglesSet (mathematics)Connectivity (graph theory)Enterprise architectureMessage passingArithmetic meanNatural number1 (number)Software bugInternet forumText editorMechanism designNumberTerm (mathematics)WritingLine (geometry)Slide ruleComputer fileOpen setGoodness of fitApplication service providerObject (grammar)Context awarenessVisualization (computer graphics)Configuration space2 (number)Open sourceComputer animation
07:55
Dependent and independent variablesOpen setInterface (computing)WeightSanitary sewerStandard deviationSource codeServer (computing)FAQData structureTerm (mathematics)Similarity (geometry)Function (mathematics)Representation (politics)Computer fontInformationData dictionaryIntegrated development environmentTask (computing)Process (computing)Key (cryptography)Table (information)Free variables and bound variablesEmailError messageException handlingStreaming mediaString (computer science)Level of measurementRootCommunications protocolHost Identity ProtocolSheaf (mathematics)Default (computer science)CodeSocial classAuthenticationImplementationServer (computing)ImplementationIntegrated development environmentLibrary (computing)Line (geometry)MiddlewareCodeLatent heatQuicksortWeb 2.0Endliche ModelltheorieGoodness of fitComputer architectureSoftware frameworkWritingBitInterface (computing)Data dictionaryCartesian coordinate system2 (number)Run time (program lifecycle phase)Direction (geometry)Connected spaceOcean currentWeightString (computer science)EmailTerm (mathematics)Dependent and independent variablesAbstractionRight angleApplication service providerKey (cryptography)Streaming mediaLevel (video gaming)Mobile appParameter (computer programming)Operator (mathematics)Traffic reportingObject (grammar)Query languagePoint cloudFigurate numberOrder (biology)Electronic signaturePerimeterMultiplication signTask (computing)Physical systemComponent-based software engineeringComputer networkNatural numberInteractive televisionComputer animation
15:50
ImplementationServer (computing)Social classAuthenticationArchitectureProcess (computing)MiddlewareComponent-based software engineeringCodeSoftware frameworkDependent and independent variablesIntegrated development environmentVideo game consoleProjective planeFunctional (mathematics)Cartesian coordinate systemCodeMobile appMultiplication signSoftware frameworkWeb 2.0WindowComputer architectureChainServer (computing)MiddlewareApplication service providerBitMultilaterationSystem callDependent and independent variables2 (number)Data dictionaryInformation securitySet (mathematics)Level (video gaming)Context awarenessIntegrated development environmentRevision controlMereologyPhysical systemProcess (computing)Latent heatConnected spaceNetwork socketGame controllerDigital electronicsTerm (mathematics)Structural loadElectronic mailing listOrder (biology)Core dumpMechanism designAuthorizationProgramming paradigmReading (process)Connectivity (graph theory)Social classType theoryWritingWordMathematicsResultantQuicksortLink (knot theory)Perfect groupLibrary (computing)View (database)Open setSineRight angleEndliche ModelltheorieWeightAnalytic continuationForm (programming)Computer animation
23:45
Maxima and minimaHost Identity ProtocolPhysical systemOvalFluid staticsComputer programExecution unitSpacetimeVideo game consoleGamma functionCNNDrop (liquid)TrailGeneric programmingTask (computing)NamespaceThread (computing)Configuration spaceConvex hullDependent and independent variablesInterface (computing)Server (computing)Integrated development environmentData dictionaryEmailError messageComputer iconVideo game consoleServer (computing)WindowMathematicsRevision controlProjective planeRadical (chemistry)Context awarenessParameter (computer programming)ImplementationWrapper (data mining)Web browserMiddlewareInternet service providerGraphical user interfaceIntegrated development environmentVisualization (computer graphics)Process (computing)Query languageConfiguration spaceComputer iconBitLine (geometry)C sharpError messageEmailFunctional (mathematics)Programming paradigmFlow separationDependent and independent variablesDifferent (Kate Ryan album)CodeGoodness of fitStandard deviationInstallation artInterface (computing)Structural loadSubsetGeneric programmingWeb applicationSocial classCartesian coordinate systemMereologyControl flowFigurate numberDirected graphVirtual machineEndliche ModelltheorieFamilyRoutingNumberElectric generatorIntercept theoremTask (computing)Cellular automatonRight angleWritingComputer animation
31:00
Video game consoleDependent and independent variablesOvalPhysical systemCore dumpGamma functionTask (computing)SynchronizationExecution unitCompilation albumCommutative propertySpacetimeInclusion mapLevel (video gaming)MiddlewareIntegrated development environmentResultantCodeVariable (mathematics)Direction (geometry)Order (biology)WindowParameter (computer programming)Uniform resource locatorConstructor (object-oriented programming)BitGoodness of fitConfiguration space1 (number)Level (video gaming)Application service providerDependent and independent variablesString (computer science)Functional (mathematics)Data dictionarySoftware bugDifferent (Kate Ryan album)Mobile appChainRight angleInformation securityVideo game consolePattern languageType theoryComputer clusterWeb browserContext awarenessBranch (computer science)Object (grammar)QuicksortLine (geometry)LinearizationOperator (mathematics)Token ringMultiplication signIntercept theoremTask (computing)Social classOnline helpAmsterdam Ordnance DatumOffice suiteFlash memoryProcess (computing)ImplementationServer (computing)Link (knot theory)Forcing (mathematics)Windows RegistryWordGeneric programmingBuildingRing (mathematics)Directed graphComputer animation
38:05
Video game consoleDependent and independent variablesTask (computing)Inclusion mapComputer virusGamma functionExecution unitLevel (video gaming)OvalMessage passingData dictionaryMach's principleMaxima and minimaServer (computing)MiddlewareWeb 2.0Cartesian coordinate systemIntegrated development environmentPhysical systemUniform resource locatorRevision controlGoodness of fitSoftware testingQuicksortSoftware frameworkApplication service providerBranch (computer science)Functional (mathematics)Mobile appCodeWeb applicationComputer programmingProjective planeExtension (kinesiology)2 (number)HookingEntire functionMessage passingConfiguration spaceDifferent (Kate Ryan album)Endliche ModelltheorieProduct (business)Beta functionOpen sourceGame controllerRoutingReal numberNormal (geometry)HypermediaType theorySet (mathematics)Multiplication signSpeech synthesisTask (computing)System callAttribute grammarRight angleTemplate (C++)Internet forumDreizehnWeightComputer animation
45:10
Task (computing)Dependent and independent variablesMessage passingPhysical systemComputer programVideo game consoleNormed vector spaceGamma functionSpacetimeConvex hullSocial classConfiguration spaceError messageServer (computing)Maxima and minimaSocial classConfiguration spaceWeb 2.0Error messagePhysical systemApplication service providerWeightComputer animation
46:02
AdditionVideo game consoleComputer fileMiddlewareFluid staticsInstallable File SystemBuildingImplementationWeb 2.0Computer fileMiddlewareCartesian coordinate systemCode2 (number)WebsiteFluid staticsAlgebraPhysical systemCore dumpExtension (kinesiology)Link (knot theory)Server (computing)ImplementationApplication service providerQuicksortEnterprise architectureSet (mathematics)Library (computing)Slide ruleIntegrated development environmentSampling (statistics)AdditionOvalRevision controlDemo (music)Software testingNamespaceFlagPoint (geometry)BenchmarkNormal (geometry)Open sourceFile systemWeb serviceDebuggerScalabilityContext awarenessSemiconductor memoryGoodness of fitOverhead (computing)Dynamical systemSocial classMedical imagingRouter (computing)Configuration spaceTerm (mathematics)Web pageLevel (video gaming)Direction (geometry)Projective planeSoftware frameworkException handlingReal numberMobile appElectronic mailing listBeta functionAlpha (investment)Installation artStructural loadRight angleProfil (magazine)Product (business)Internet service providerComa BerenicesVideo gameMultiplication signRange (statistics)Focus (optics)Scaling (geometry)Process (computing)Front and back endsScripting languageDifferent (Kate Ryan album)Binary codeComputer animation
Transcript: English(auto-generated)
00:00
Can you hear me in the back? It's OK? OK, good. Well, I think since we only have one hour, we should start. So welcome. Thanks for coming to this session on Owen and Katana. We are in sort of an interesting time with Microsoft and their approach
00:21
to hosting web applications written in .net. This session is going to talk a little bit about, well, actually focus mainly on the current version of Owen and Katana that was recently shipped with Visual Studio 2013 in October of last year, along with Web API version
00:40
2 and MVC 5. But it's going to provide you guys a little bit of a preview of where Microsoft is going with their big changes that they are undergoing with ASP.net, vNext, I suppose is what they're calling it, and Project K. I'm not going to be talking
01:03
about those specifically. There are a couple sessions tomorrow about those. But this will provide you with the understanding of the motivation. And like I said, this is sort of a stepping stone to where the platform is going. My name is Brock Allen. A little bit about me.
01:21
I teach for a training company called Developmentor. I work with Think texture. I work on a lot of open source projects there. And I'm a MVP and a contributor to ASP.net and the community. So what we'll do is talk about this thing called Owen and Katana, which, like I mentioned,
01:42
is a new hosting model for your web application code. And we're going to look at sort of why Microsoft is moving this way. And we'll talk about the details of what Owen is versus what Katana is. And then I'm just going to write a bunch of code to show you the mechanics of it so that you get a sense of how you are going to be perhaps coding against it,
02:03
perhaps writing your own code that plugs into it, and sort of setting up what components, what code you're going to want to run in your web applications going forward. So the first motivation for this new web hosting model is actually, and sort of ironically, ASP.net itself.
02:25
You guys know what ASP.net originally meant, right? It was basically 12 or 14 years ago when they were working on a new framework. They came up with this concept of ASP.net web forms. Of course, we call it web forms now because there's now MVC, which you need to contrast it against something.
02:43
But anyway, back when .net was first shipped, we had this new web programming model called ASP.net. And underneath ASP.net, we had this programming model for doing HTTP. And it's basically resided in this DLL called system.web. So I'm sure a lot of you guys have used system.web.dll
03:03
to write web application code. When ASP.net was first being developed, they were porting over almost the desktop style of programming. So we had a very, web forms itself was a very object oriented programming model. In terms of building a web application,
03:21
the target audience at the time was VB6 developers, desktop developers, who then wanted to start getting their code out onto the web. And that's totally fine. But the underlying HTTP framework that resides in system.web, and I'm talking about things like the HTTP context and the whole programming model of HTTP modules and handlers.
03:41
All of this infrastructure was being built up to support this web forms style of programming model. So the problem with this is that it is a pretty old framework. It's been around for some 12 or more years, at least released for 12 years. And you can imagine it was in development for a couple years prior to original release.
04:02
And it's basically a really big framework. It's got a lot of code. There are things that, given the HTTP programming model, the HTTP module programming model, there's a lot of code. It runs on every single request into your application, regardless of whether or not you care to use it. Things like session state and just the whole engine.
04:24
Even if you go and try to disable some of these things, still some code may run that relates to features that you don't use or care about. So we have this basically really old framework. And given where Microsoft is going and wants to go with some of their new frameworks,
04:41
they want to be very agile, very quick about putting out new frameworks, new features. And a framework that's 12 years old with that much code in it is very hard to be agile and put out new features. As they were working on some of the newer frameworks, like SignalR and Web API, more specifically, I think, SignalR, as they were really pushing
05:02
the limits of what ASP.net originally could do. And so they would find bugs that have been in ASP.net for 12 years now. And so you can imagine on a framework of that size, any time you fix a bug, well, you kind of open up a few new ones just because of the monolithic sort of nature of the framework.
05:22
Also, I mean, who wants to use code that you wrote 12 years ago? I certainly don't. So ASP.net is basically sort of this legacy framework. And Microsoft, I think, wants to move away from it. Now, that doesn't mean that we want to move away for something like IIS.
05:41
IIS is also a web server, but it is system.web sitting on top of IIS that gives us the ability to write .net code that is running in that web server. Microsoft is very much still behind IIS. They think it's the fastest web server on the planet, of course, until you load a framework that is old and perhaps slow in some scenarios
06:02
and kind of bloated. So again, Microsoft has this legacy thing called system.web that they need to move away from. Another motivation for this new hosting approach with Owen and Katana is sort of this mentality that we've gotten into, and I myself am guilty of this,
06:22
is that when you create a new empty project in MVC, do you ever think about how much stuff you get? Now, again, I never really thought about this, but do you really need system.drawing and system.enterprise services? And I think data sets are in here somewhere, too.
06:40
I mean, people still use data sets. So this is sort of the attitude or the approach is that they throw everything at you just in case you might need some little feature from some obscure library. I don't know. I mean, again, maybe this isn't a problem. Maybe it is. But I kind of like the idea of only pulling in what you need
07:01
and then hunting out or seeking the libraries that you want to use and explicitly or deliberately pulling them into your project. I just don't think we need all this. Also, kind of giving, oh my gosh, look how big that is. So this is just like half of my config file for a new empty ASP.net project. So there's just a lot going on here for what's considered to be an empty project.
07:23
So it makes you worry about, again, the kind of the age and bloat of the system. Another motivation for Owen and Katana is this framework called Node.js. You guys heard of this? Node.js is basically this way where you can run JavaScript on a server
07:41
and host a web application or a web server. And their approach is sort of like what I was saying on the previous slide is that they start small. They want to basically have the least amount of code to get your web server up and running. And then as you want to add features, you go seek out those libraries and you pull them into your application. So it's really compelling to be able to write
08:01
three lines of code and have a full web server up and running. So there's something to be said for this lightweight sort of composable model. I guess going back as well, so the style with Node.js is that when you want to pull in code, you get to choose and pick the things that you want to run.
08:20
And of course, by its nature, nothing else is going to be running in here. So again, contrasting that with the system.web, heavy, kind of bloated framework. So this is not bad that Microsoft likes this model, because there are a lot of good things about it. But that's kind of where this Owen and Katana model
08:41
are going. And that's where Microsoft is going with their future of building these sort of cloud-enabled, whatever that means, web server frameworks. So this is where Owen and Katana come in. So there is a distinction between the two, although they are used interchangeably sometimes.
09:02
But the idea here is that there's this concept of Owen. Owen is a specification. And what this specification is, is it says how you can build a web server that can host .NET code. That's basically it. So there's a specification that they have to say, actually,
09:22
two things. One is how a server can expose HTTP to an application bit of code. And then, of course, how that code plugs in to this hosting environment. The code that would plug into this hosting environment, we call it middleware. It's a term borrowed from some of the other frameworks.
09:43
And so the idea, then, is that if you are writing an application or application components, middleware, and you target this abstraction, then that means the only thing you depend on is this abstraction. And therefore, you could have potentially any implementation of a web server.
10:01
Now, of course, Microsoft's going to provide an implementation for us. That's great. And in fact, there's an implementation that even runs in IIS, of course. That makes a lot of sense. But given that this abstraction or this interface that Owen defines, it gives us a level of indirection. So you can run a web server that's not running in IIS.
10:22
And there's something compelling about that. Now, I'm not saying you're going to want to throw away IIS. I think for 90% of people, maybe even 95% of people, IIS is still going to be the web server you want to host in. All of your operations people already know how to manage it. And you're comfortable and friendly with it. And it provides you a lot of features. But in some environments, you can't install IIS.
10:43
It just depends on what you're doing. So being able to run a web server outside of IIS is kind of a good idea, or an interesting idea at least. Owen started in the community. So this actually started as a community movement a couple years ago, or a few years ago now,
11:03
basically trying to figure out a way to get MVC to run basically outside of IIS and perhaps away from the system.web runtime. So without the communities pushing for this, and involvement, and innovation in this,
11:21
I really don't think Microsoft would be doing these steps that they are doing today. And again, I think they're good steps. They're definitely going in the right direction. Let me show you briefly the Owen specification. That's bright. Owen.org. Hopefully our connection's up. Good.
11:40
So you can go up here. You can read the specification. It's actually quite an interesting light specification. But there are two things to it. I said that one is that the Owen specification gives an interface or a specification for how a web server is going to be hosting HTTP and exposing it
12:02
to application code. The way they do that is they basically define a dictionary. So they have this thing called an environment. The environment is the current HTTP request into the server. And it is modeled as a dictionary of string object, which actually is kind of like this guy right here.
12:23
So they model the HTTP environment as this dictionary string object. So what that means is that in ASP.net, if you ever wanted to look at the request or the response, there were objects for that, request.querystring and response.statuscode, things like that. Well, here, it's a dictionary.
12:42
So if you want to reach in or if you want to write code that runs in an Owen environment, then this is how you talk to the HTTP layer. Now, the strings are keys into the dictionary for looking up something about the HTTP request or the response. So if you were to look up into the dictionary
13:00
for something called Owen.request method, then the dictionary would return you a string that told you if this is a get or a post or a put or a delete. If you were interested in the URL, say, then there's a Owen.request path, which gives you back a string. If you wanted the request headers, you would look at the headers dictionary item.
13:20
It would give you back another dictionary, because the headers are key value pairs. If you want the body, you'd look into the request body, and you would access the body as a stream. Fairly low level. I got to say coding against this directly isn't really fun. But this is what it takes to be a specification to give you
13:41
this sort of abstraction of what web server you're running on. We're not taking a dependency here on any one specific framework. That's kind of the idea of this. In terms of the response, same sort of thing. In the same dictionary are things like the response headers, the response body, the status code, so on and so forth. So this is called the environment
14:01
that an Owen server must provide to code that is going to be running in this. Now the second piece is the specification indicates is how code plugs in to this Owen server. And that's what this is here up at the top. This is called the app funk. And this is where the what the funk comes from in the title.
14:21
So the idea here is that you want to run code in this environment. You're going to write middleware. Or maybe somebody else will write middleware, but you will be using it. This middleware is going to plug into this Owen environment, this Owen server. And the way it plugs in is it basically has to have an interface or a method that is going to be invoked by the Owen server.
14:41
And so the way they do that is they define a funk, basically a delegate, which hands you the environment as a parameter. So that dictionary where you can get access to the request and the response, that's this dictionary. They hand this in to you as a parameter. And then the return value is actually a task, which means this architecture is
15:01
asynchronous by design. And that is, again, a really, really good thing. So if you want to write code that plugs into this Owen environment, you have to have basically an implementation of that signature, that function. Any questions about this? No?
15:20
All right. So that's basically what Owen is about. It is the specification for defining what a web server will expose, APIs, to access the HTTP environment. And then how code can plug into this environment. And we call that code middleware. So this is where Katana then comes in. Katana is Microsoft's implementation
15:43
of the Owen specification. So they provide a few things here. One is, actually, Katana is actually quite big. And they are adding more and more things to this every day and every week. But first and foremost, Katana is going to provide you with a set of Owen servers.
16:01
So like I said, Microsoft's going to build a host, a server, that you can then run in. So they actually have a few Owen servers. They have one that I mentioned. Actually, they have two that run in IIS. So I'll talk a little bit about those later. But they have another one that allows you to do self-hosting.
16:21
Again, so the idea is you don't want to run in IIS. So you could write a Windows service or a console application, or your WPF app can now start hosting HTTP calls. So that's the first and foremost thing that Katana provides us with. The second thing that Katana provides us with is a set of convenience classes.
16:42
I said that that dictionary was how you are going to interact with HTTP. And pretty low level to do. So I wouldn't want to code that every single day. So the other thing that Katana is going to give us is this thing called an Owen context. It kind of is reminiscent of the HTTP context. Because the old HTTP context gave you
17:01
a request and a response and a nice programming model on top of the HTTP request. So that's basically what the Owen context provides us with, is an Owen request and an Owen response. And then the last thing that is part of this thing called Katana is that we have middleware that
17:21
is being written by Microsoft. So again, middleware is the code that will run in one of these Owen servers. And the idea is that Microsoft going forward, the way they are going to provide their features, whether it be a library, most commonly a library, but whatever kind of functionality
17:41
that Microsoft traditionally provides us with, say security, logging, that kind of thing, is going to be produced as middleware going forward. So that makes perfect sense, because if you think about it, Microsoft today, they have this fragmented set of frameworks that they're calling ASP.net, but they're all
18:02
different frameworks. So we have web forms, we have MVC, we have Web API, we have SignalR, whatever. And so they don't want to have to reinvent the wheel for each one of these frameworks. They don't want to have to implement security over and over. They don't want to have to implement logging over and over and whatever else. So instead of them doing security within each one
18:22
of these frameworks, they're going to hoist it out to the hosting layer and provide it as middleware. So middleware is basically how Microsoft's going to be delivering functionality to us going forward in the future.
18:42
So Owen defines an architecture that is good to know about because of the terminology that we use. So I'm going to show this to you, and then I'm going to go start writing some code to show how we build applications using Owen and Katana. So the first thing that Owen defines in terms of their architecture is this concept of a host.
19:00
The host is basically the hosting process. So whatever process that you are going to be running in, running this web server, that's the host. So this could be your console application. If you're going to be doing self-hosting, you're going to create your own console project. Or if you're going to be doing this in a WPF app or a Windows service, or IIS.
19:22
So IIS could also be our host. Then what we have is an Owen server. So the Owen server is the thing that actually is implementing the Owen specification that I talked about. It is going to basically do what it takes to have the HTTP connection open. It's going to be listening on the socket for whatever
19:41
incoming requests. And then it provides the environment dictionary for every request coming in that I talked about. And then what the host is going to do, well, actually, I guess what the host has to do is pick which Owen server you want. That's going to be part of the process of writing the host. Again, the host is typically written by you, whereas the server is some code that you're going
20:03
to use, someone else's library. So then you and the host, you are going to pick your Owen server, then you're going to pick which middleware you want to run. So again, the middleware is going to plug in to the Owen server. And there's a way to basically register what middleware that you want to run.
20:21
So the nice thing about this model, again, is that this is fairly lightweight compared to system.web. With system.web, it was all or nothing. And if you got all of it, you got all of it. With this model, you get to pick and choose what middleware you actually want to run. And the really nice benefit about this is that you're going to be able to have less running code.
20:42
Your server's going to perform better. So less code is sometimes better. So that's the job of the host. Host is really, like I said, kind of like your application. So you're going to pick which middleware you want to load in. These middleware, by the way, are going to get chained together.
21:01
So they're going to form, basically, a linked list of which middleware that you want to run. And so they are chained together. And therefore, order is important. When a request comes in, it's going to come into the middleware. And the middleware does whatever it does, whatever feature that is, whether it's like security or cores or it's logging infrastructure, whatever.
21:22
And then it then calls to the next middleware. So that's basically the chaining mechanism. Middleware, because they are chained together, you are going to be writing the code that calls to the next middleware. Or a middleware author would do this. So if you're writing middleware,
21:40
you're going to say, OK, now it's time for me to go call the next guy in the chain. That gives you the control to then say, well, I'm not going to call to the next guy in the chain. So middleware can short circuit the call. So in other words, you can get into your application. And if your middleware decides, I don't want the call to proceed, or maybe your middleware is actually
22:01
where the call should stop because you are actually producing the results, then you do that. And then you simply return. You don't call to the next guy in the chain. So the last concept that is in this Owen architecture is what they call the application. So you may or may not be writing middleware yourselves.
22:22
More likely, you're going to be using other people's code, components, middleware, that's already provided, Microsoft's or others. But you probably are going to be more likely to write application-level code. So like I said, you may not write middleware code, but you probably will write Web API code. So you might be writing code running in Web API, or SignalR,
22:44
or in the next version of MVC, which will be hosted in this model. You might be writing your MVC code. And so that code that you're writing lives within that framework, that application-level framework. And therefore, you may not even know about the Owen infrastructure that is running beneath you here.
23:03
So that's another piece of the puzzle here is that your code just may be application code. You certainly will be at the host level, though, picking and choosing the middleware and application frameworks you want to run. So this all gets wired up and invoked by your user agent.
23:21
OK, so let's go write some of this code. So what I'm going to do is flip over and run Visual Studio. And I'm going to first start by writing a,
23:40
so back to my picture here, a host. And the host that I'm going to build is a console project. So I'll go over here. I'll go to Windows desktop. I'll do a console project, and I will hit OK. So I'm authoring the host. I need to pick which Owen server that I want to load. Well, the one from Microsoft is the self-hosting Owen
24:00
server. There are others, though. There's one called NoWyn. That is an Owen server that is capable of being run on, obviously, a Windows machine, but also on Mono. And in fact, Microsoft, I think, is working with that project to make their next version capable of all running on Mono.
24:23
And I worry that my NuGet feed is down. Here we go. OK, good. So what I went in and I searched for Owen. Actually, self-host is what I want here. So I'm going to pick my Owen server, and that is Owen self-host. So I'll hit Install.
24:44
Load this up. Accept. So again, this doesn't have to be a console project. It could be like a Windows service or embedded in some other application you already have. Did I pick the right one? I don't think I did, actually.
25:07
There we go. Yeah, yeah, yeah, I totally picked the wrong one, sorry. Let's go get rid of that one. OK, let me try this one more time.
25:25
There we go, that's the right one. OK, so what I'm going to do is go into my application here. And webapp.start.
25:44
So what we're going to do is there's this class called webapp that basically wraps up the self-hosting Owen server. You basically tell it what you want to listen on, something like that.
26:01
And then what you need to do is configure it. So I've chosen my Owen server, and I am going to then build a configuration class. So that's what this generic argument is, basically indicates what class to do that in. So I'll go build this guy. And so this has the method to do configuration.
26:23
It's called configuration, go figure. And so this is how Katana allows you to register what middleware you want to load in. Now notice the configuration here. I have no interface I'm implementing. It's based on convention, the name of the method
26:41
and the argument you get passed to do this configuration. And so you're just picking which startup configuration that you want. OK, yep, question? Yes, yes?
27:00
So like I said, we're talking about here specifically the implementation that was released with Visual Studio 2013. This is Katana 2.0, basically. There are changes coming in the future. The general style is going to be incredibly similar, the whole concept of middleware and the server and the host and all these moving parts.
27:20
So you're absolutely right, in the future, they are making some breaking changes in the API. But the general programming model is going to be the same. OK, so what did I want to do here? Well, I've got to write some code in here to run some middleware. So what I'm going to do is I'm going
27:40
to show you the simplest version here, is they have something called run. And run is basically where you register a piece of middleware that is the termination in this pipeline that we're going to be building. And so what they hand you is the Owen context that I mentioned. Here, I'm just doing this as a delegate. And this is the environment, if you will, from the Owen
28:01
server. Now this parameter is actually the Owen context wrapped around the environment. So it provides us the convenience functions for working with the request and the response. But it's really just a fancy wrapper on the dictionary that the underlying Owen server provides. And so as you see here, this context has things like request. You can do request dot the URI, the absolute URI.
28:25
We can maybe print that out into the console. Something like this. You then have, of course, other things on the request, like the query string, the standard programming model for the incoming request. And then we have the response where
28:41
you could set the status code. You can set headers. You can change the body. And then they have a couple of convenience functions for writing out to the body. Now again, I said that this is asynchronous by design. So I'm getting a little bit of an error here
29:02
saying I'm not returning a task. So what I can do is use the great async and await features in C Sharp. And now I have an asynchronous implementation. Actually, there's even a right line. Oh, it's right there, right line async, yes. All right. Good. So right now I have just really, really simple hello
29:22
world, basically middleware configured. Now back over here then, I'll simply write out that we are up and running. We're ready. And then I will wait, because we are in a console project. We'll just do read line. OK, so 432, 4321 is my URL.
29:45
So good. Looks like I'm up and running. And so if I do, if I bring up my browser here, and I go to local host, 4321, and hit Enter,
30:00
yeah, look at that. So we basically hit that endpoint that's hosted here in this console project. And in fact, it looks like my browser hit it twice, because it went once to the root, which is what I indicated here, and then once Chrome asked for the favorite icon. So whatever URL you go to, that's
30:20
basically going to hit our R1 server. And then we've implemented this, just always return this HTML. OK? OK, so that's real easy to get started. Like I said though, typically you're going to configure several different bits of middleware to compose your application, whatever you want to do. So there is another way to register some middleware.
30:42
This is really just one to just, like I said, print out, generate the response, and terminate the pipeline. There's another one called use. And what use does is it allows you to be the kind of middleware that intercepts the request. So you can do processing before the request, and then you let it go along.
31:00
And then when it comes back, you can do processing afterwards. So this actually passes you two parameters. They pass you the context, and they pass you the delegate to the next middleware in the chain. So I'll put in another inline function here. Again, this is going to be asynchronous,
31:20
so I'll do my async. And then I can do something like, this is my pre-processing. I can do some post-processing, like this. And then I can call the next in the chain. So maybe you're writing some security. I do a lot of security work, so this
31:41
is the thing that's on my mind most of the time, is you want to intercept every request because you're looking for some sort of token that's being passed in, or you want to intercept the request to look for something and operate off of it. So this guy is just going to sit in the pipeline. Of course, order matters here. So I want this one to go first, and then this one is going to go second. And then on the way out, of course,
32:01
we'll do its post-processing. So if I run this, good. Go back to my browser. I hit refresh. The result here is the same. But if you look over my little console window now, you see the pre-processing and then the post-processing. OK? Good. Questions about that?
32:21
Yeah, go ahead. Yes? So the question's about what references do I really have now? Well, you have, basically, this stuff I could probably ditch because I don't need it.
32:41
XML, link, but you do have your own bits. So those are the ones that you're depending on for this particular, you know, you've chosen your server, like I said, the Katana server, and that's, of course, the hosting bits that you need. This stuff, if you're not using it, of course, this is a console app, right? Not an ASP.net app.
33:01
OK. Let me show you a couple of other things here, and then a couple other APIs that you might use with the middleware, or to configure middleware. So I showed you registering a couple different middleware as basically delegates, right? Just callback functions. You can be a little bit more formal about your middleware
33:21
by creating it as a class, like this. And so, if you put the right keywords in here, it works. And so you create a class, and what you have to do is if you want to package up your middleware as actually a class, you have to have, well, pretty much this invocable function that I talked about.
33:43
And so the pattern there is you do public task, invoke. They pass you the I dictionary of string object as a parameter, OK? And I guess we could do an await here, I'm sorry, async.
34:00
OK. Now notice they hand you the raw dictionary. OK, this is not the Owen context convenience helper. So a very common thing to do is the very first line of code is you actually then will new up the Owen context, and you'll just pass in the environment as the constructor argument. And then this will then give you the request and the response and all those convenience
34:20
functions. Again, all they're doing is just setting data in this dictionary. Good. So I guess I could do a const dot response dot write async. So this is from my middleware like that.
34:43
It's a little weird to maybe call this and then call to the next guy. Actually, that's the thing I'm missing here is where does the next come in to play? Up here, they passed you the next as a second argument. Here, they only pass you the environment. Well, the way that you receive
35:01
the next guy in the chain is passed as a constructor argument. So you have to have a constructor that takes the delegate to this next thing. So you need to accept a delegate, a func of I dictionary of string of object
35:21
that returns a task. And that is the next reference. Yeah, when I was first learning this, I was like, you know, what the funk is this? You hold onto that as a member variable. And then wherever in your actual implementation, you then can do your good old await next.
35:42
And this one, actually, you pass the environment directly. So that's actually the interesting thing here is you can manipulate the environment and change it for what the next guy sees. So maybe there's something about the request that you want to make look different. And the next one, we'll just see whatever you have changed.
36:01
If I want to register this guy then, I simply go up here. And then there's an app.use where you can do a generic argument like that. OK? So if I build this one more time, if I run it, if I run my browser and I hit refresh, then you see that they both get run. OK?
36:20
All right. So that's kind of the style. There's one more feature, actually, which is kind of interesting to show. Let me show this real quick here is they have the concept of, actually, let's move these around. I want to move this one down here.
36:41
They have the concept of app.map. And this is a really interesting feature where what you can do is we're building, basically, a very linear chain of middleware, right? When the request comes in, they're all going to get called in order. Map allows you to branch the middleware that you want to run
37:00
and you do it based on the incoming URL. OK? So if I put slash hello here, then what you have to do or what you are allowed to do here is have an alternate configuration. So actually, you know what? Let me put my middleware in the middle here. And the bug that I always do, which I almost did here now,
37:23
but I caught myself, is that don't forget to use this app builder instead of the top level app builder. So that's what they're handing you is if we hover over this, this is actually the same type of app builder that we get passed up here. So it allows you to basically branch in the middleware
37:40
and then configure almost like a parallel pipeline or a branched pipeline. So this one will always run because it's right there at the beginning. But if the incoming request starts with slash hello, then this one will run and it's done. The pipeline ends in whatever middleware you have provided here.
38:02
If the request does not have slash hello, then it basically branches to the rest of your configuration down here, which this is going to say hello Owen, and this one should say hello my middleware. So this is all based on the incoming URL. There's another version of this where you can write more elaborate code. You can actually write a callback to say yes,
38:21
take the branch or no, don't take the branch. This actually kind of reminds me of routing in MVC or in Web API. So if I hit refresh now, notice I'm just getting the hello Owen. But if I put a slash hello at the beginning and hit Enter,
38:41
then I'm branching and hitting the other path. I'm going to do one more thing just to show you that this really is the approach going forward for hosting application frameworks. And let's pull in Web API now. So I'm going to pull in Web API.
39:02
I'm going to go to NuGet. I'm going to go look for Web API Owen. And so what I want is all I need to do is pull in the ASP.net Web API that's targeting the Owen as our host. And that will basically allow us to run Web API on top
39:21
of the Owen server that we have configured in this application. So then what I'll do here is I actually will do this. I will do a app.map. And what I'm going to do is you know how very often in Web
39:41
API you segregate your APIs by the slash API prefix. Instead of doing that within your Web API code, you can actually do it here at the Owen middleware layer. So what I'm going to do is I'm going to set that up here. And then, by the way, all of your routes in Web API
40:01
are going to be relative then to whatever map you've done here. So the normal configuration for Web API is you create the HTTP configuration. You do whatever config you want or set of whatever media type formatters and everything else you'd want to do.
40:20
And then I need to register this. Actually, I'll make this API app. And I'm going to register now Web API in the Owen hosting environment. So on this app builder, what I have is a helper called now useWeb API. So what they do is when you pull in an application
40:41
framework, they typically set up an extension method off of the app builder to allow them to be hooked in as middleware. So this is the API that will hook in Web API's application as middleware. So the entire application programming model is itself simply middleware. And we pass the config like this.
41:03
So if I go do a controller real quick here, like this, I do a public IHTT get.
41:21
I'll do a route because I'm doing the attribute-based routing test. Again, notice I don't have to do API slash test. I just do test. But the URL will be API slash test because of that. And so then I do a return. I'll do JSON. I'll new up something with message goals.
41:41
Hello, Web API in, you know, Owen. OK. Good. If I run this. So four, three, two, one again.
42:01
So then I'll get my hello, Owen. I'll do slash hello, slash something. I'll get my middleware. And now if I go to slash API slash was it test? OK. There we go. I have my Web API code. All right. So you could do the same with SignalR.
42:21
You can also do the same with other frameworks. Lots of open source frameworks. I'm sure you guys have heard of Nancy. Right? There are a couple talks here this week on Nancy. You know, it can be hosted in this sort of environment as well. And again, because now reusable functionality is being built as middleware, you can stick the middleware at the beginning of your pipeline.
42:40
And then no matter what framework you're using, they all get the benefit of it, whether it's a Microsoft framework or some other open source framework that you're using. OK. Good. So let me switch gears and run this. I'm going to take basically the same code and now run this in IIS. OK. That means I'm going to need to pick a different Owen server.
43:04
It's one that will run out of IIS. OK. So let's do a new project here. File new, project. I will now do a web server like this.
43:21
And this is actually running out of IIS Express. I'll just do an empty web application. And by the way, the thing I'm showing you here, this is how I create all of my new Web API projects. I don't use the template here, because it adds so much stuff. What I do is I start empty, and then I add my Owen server, and then I just pull in Web API, just like I showed you a few minutes ago.
43:43
So I'll hit empty. I will then go and look for the Katana server that runs in IIS. Now I said earlier, there are two Katana servers that run in IIS today. One of them is the production ready one
44:01
that was shipped, like I said, back with 2013. And that is the system web version here. There is this one still uses ASP.net or system.web, which is kind of funny, because this was sort of the motivation to move away from this. But the idea here is that you may still
44:21
be using system.web. You might be using MVC or web forms, and now you want to use some of the new Katana middleware. Well, you're already using system.web, so it's not a problem to reference that and have that in your application. So they actually have a nice model where they kind of layer in the two pipelines, one from Katana or one from Owen and one from the normal system.web pipeline.
44:43
So anyway, that's the production one that we currently have. There is another one that I'm going to talk about in a minute called Helios, and that is in beta. And I think they're, I'm not sure when they're going to ship it, but I imagine it'll be the next big release when they release all this next ASP.net stuff.
45:00
I suspect that's when they're going to make that one production ready. So that is system.web. I've pulled this in as my Owen server. Now in my other project, what I did in main was I then went and explicitly configured the URL, and this is my configuration class.
45:21
Once I'm doing this in ASP.net or in system.web, when I run this, I should get an error right away saying, hey, you've told me that you want to run Owen inside of ASP.net or inside of IIS, but you have not done any of this configuration stuff that's needed.
45:40
So what's happening is just by virtue of referencing the assembly, it is loading itself up into ASP.net, and it needs to be configured, and it's failing because we haven't done that yet. So what I need then is this class. The same startup class that I wrote in the other one.
46:03
So startup public void configuration, like this. And just by virtue of having this, the exception should go away. It's gone now. I don't have any pages in here, but the exception is gone. So that is being loaded by configuration,
46:22
or convention rather, loading up my configuration. There are ways you can explicitly indicate which startup class you want to use. There is an assembly-wide directive that you can put in your code that can pick. The other thing is there's a configuration file entry that you can put. And so that's actually quite useful in your configuration file.
46:40
You may have a version of your configuration here that is sort of a testing environment configuration versus a production, maybe versus Azure or some other hosting provider if you're using that. So you can easily switch this based on a configuration flag.
47:00
There's something else I was going to say about this. Now I forgot. Okay, well, anyway, I'll keep moving along. So what I'll do is I'll go back and grab pretty much the same startup that I had from here. So I'll grab all the same stuff. I don't have Web API yet, but I'll pull that in a minute. So I'll just pop all that in there. And then I need my middleware, like that.
47:27
Yep, good, there. Okay, I think I'll probably have some namespaces I need to pull in. Yeah, oh, and I don't have that stuff yet. So let's just comment that out for now.
47:44
Good, all right. So now we're running an IIS. I should be able to run this. And same thing, there's my hello Owen and there was my hello, I think it was hello. And my middleware, did my middleware get called?
48:01
Yeah, let's just run this in my debugger here to make sure that guy's getting called as well. Something like that. Good, okay, so yeah, now we're in my middleware. Okay, good, so we're actually now running here inside of ASP.NET and it's the same basic
48:20
kind of configuration pipeline, okay? This kind of is, if you want to think of it this way, this is the replacement for your global ASAX, right? In terms of like sort of application-wide configuration. It is very code-focused, right? They're very much orienting this on a code-based approach rather than a configuration file-based approach. So again, at the very beginning,
48:41
I said one of my motivations was this massive configuration file. If you do want some sort of configuration, then you can write that code yourself and load in and you can tailor your middleware based on a config, but that would be up to you to decide how to do. Okay, so let's switch this over.
49:02
I guess I can add back Web API or I can switch this over to Helios. I guess let me do that real quick before I have too many other libraries to pull in here. So let me just show you Helios real quick. So Helios, I need to go look in the pre-release of NuGet, and if I look for Owen host,
49:24
hopefully that is good enough, here it is. So Microsoft.Owen.host.IIS, okay? So this is the one, if you can tell up here, oh, it's not even in beta, it is in alpha. So it is like very, very early, but the point of this is this is going to be your Owen server
49:41
that eliminates that dependency on system.web, okay? So we can hit install. Again, one of the benchmarks that they showed was that a normal HTTP request into system.web, every HTTP request in that HTTP context class takes up like 30K of data,
50:04
and so using the Helios approach, they got that down to like 1.5, okay? So if you're thinking about the kind of scalability that things like SignalR require, right, that memory overhead is gonna be a huge deal, okay? And so you're getting the ability to put more requests through one server, okay?
50:25
So you don't have to scale out as fast. So here I have this running. If I run this again, okay, good. You know what, did I remove, let me remove the other one, I don't think I did. I'm actually surprised that they both work together.
50:40
So let's get rid of system.web and get rid of that guy. Okay, good, now I have the Helios guy. We run them, okay, still running, right? It still looks the same, you can't really tell the difference, but I think what I should be able to do is now go over here and get rid of XML and web services and extensions and dynamic data and system.web and enterprise services
51:02
and drawing and data and all of those, okay? So we'll get rid of all those, get rid of that guy. And so now, you're back down to kind of a core set of libraries, no references to those guys and we're still running, okay? All right, and I can throw web API back in, but then you're picking and choosing the libraries
51:21
then that you wanna pull back in. Good, I think I'm almost done. My slides have some more samples here. I just wanted to have some additional sort of reference material if you wanted to go through this.
51:40
I've already talked about all these things, but there are other middlewares that Microsoft's providing. So one of them is something called the static file middleware and this is actually quite interesting. So you're thinking to yourself, wow, static files. We have to like deliberately write code to load in, you know, have our web server serve up static files. That's normally a behavior of IIS and so normally you wouldn't need that,
52:01
but if you think about these scenarios where more and more modern applications are being delivered as the spa style applications like with Angular and things like that, what does your web server really need to host? Well, some HTML, some CSS, some images maybe, some JavaScript, right? Those are all static files.
52:20
And then web API, right? That's pretty much all your web server needs to serve up. So again, for those people who don't host in IIS, that's really good because you could serve up a whole spa style application without this install of IIS, okay? All right. So anyway, there's just some samples of how you can load this in. You basically say, for this virtual path,
52:41
what's the actual real path on the file system it should map to? There's even what's called the embedded resource file system where you actually take your files like your HTML and your JavaScript and you embed them as embedded resources within your assembly so there's not actually loose files on the file system but they're being served up from your binary,
53:01
which is kind of cool. CORS is basically, we have two implementations of CORS essentially. We have one in web API itself but again, going forward, since web API is merging into MVC in the next version, CORS support will be primarily done
53:20
at the Owen or Katana level, okay? So this is the second implementation that's provided more coarse grained because it's at the hosting level and not down at each individual API. Okay, I mentioned a bunch of application frameworks as well so I already showed you web API but SignalR is designed this way and here are a bunch of other open source projects
53:41
or projects that you can load in that have all been designed to run as Owen middleware. Okay, so I showed you these already. Here's SignalR and that's it. So it's quite interesting what they're doing with this new hosting approach. It's definitely the right thing.
54:01
I mean, you know, for what we want our web servers to do, you know, the shall we say heritage code of system.web, you know, is, well, that's what it is, heritage code at this point. Okay, thank you very much.
54:23
I will put the slides and the demos up on, well, my website. So it's gone now but anyway, there's a link up on the speaker profile. Should have a link to my website. So yeah, it's just brockallen.com. So I'll put those up by the end of today. Okay, thanks.