I am looking to build a small ASP.NET application using WebAPI and a html front-end, on .NET 4.0. I need to support authentication, authorization, data access (EF), logging / tracing. It can be an intranet/internet application, so it should support load balancing / clustering.
I am sure if I just go with ASP.NET and IIS I will get all these features. However I like OWINs idea of independent async modules and its goal of being high performance hosting environment. But how much of OWIN/ KATANA is matured and what functionalities are still missing/buggy?
The whole idea of Owin/Katana is to build a light weight server with only the function we need. Your question is better to be "What are things missing in Owin/Katana, which is available in IIS?"
The short answer is, IIS is a full-blown server. Many of the websites we developed only requires a small fraction of all its functions. It is like shipping a bag of grocery using an 18 wheeler.
If you look at Katana, all functions are modular. Say, if I need WebAPI, I can add in that function. When CORS is needed, I will extend appBuilder to the related functions. So in a sense, we have a fully customizable server. Since all functions can be added in, I would say nothing is missing.
Another thing to mention is that an installation of IIS would require you to run a Windows Server. If you are on a Mac or not a server version of Windows, you can host your website on Katana or any other OWIN implementation.
Related
We don't want our client to share or misuse the deployed asp.net MVC package to other IIS server machines. we need the asp.net MVC package to only work on specific server machines.
I think in cases like this, the best approach is to include in the contract with your client these types of limitations. Something like "This software can only be used on the specified machines". But consult with a legal team if you can.
Otherwise, you can look into "Licensing Servers". You can try to build your own, but it's hard to develop and maintain the server infrastructure. As an alternative, you can check licensing as a Service. I know of https://keygen.sh/, but I believe there are others.
I'm brand new to C#/.NET
Why does ASP.NET have so many different choices of projcets? (Web Application, Web API, Web Site, MVC ect). I just want to listen on a tcp port, and a way to send a response. If there are libraries to help me do routine stuff like constructing the HTTP request, parsing the header, ect - then cool. But I don't want a super opinionated framework that tries to do everything under the sun.
Why do I need IIS at all?
Addressing your points in reverse order, first - why do I need IIS?
The answer is, maybe you don't. If you are doing a simple listener that won't be exposed to the public internet, then you don't need it.
If you are doing a web application that needs to scale, be robust and easy to manage then it can help you with:
Logging
Operating in a multi-server environment for scale/high availability
Handling multiple requests in an isolated way
Serving multiple applications from the same host with sandboxing to ensure each application has guaranteed resources (memory, CPU)
Application lifecycle management
IP address restrictions
support for FTP, CGI, WebDAV
URL rewriting
Response header manipulation
Failed request tracing
Protection against some DoS exploits like slow HTTP attacks
Etc.
In short, it is an industrial strength, real world web server that will keep your application up reliably in a hostile world and scale as your application grows. it is certainly overkill for some cases if you don't need this kind of scale/high availability/management capability. In those cases you have the option to self host ASP.Net in a Windows Service or even a console app. This might sound complicated, but it has been made pretty simple by OWIN - Open Web Interface for .Net. This is an abstraction of the interface used by Asp.Net to communicate with its hosting server.
There is a very good tutorial on how to self host web API in a console app here
http://www.asp.net/web-api/overview/hosting-aspnet-web-api/use-owin-to-self-host-web-api
It does exactly what you ask for in your comment:
You create a console app project
You add references to the right assemblies (the tutorial uses NuGet to download the assembly packages)
You code up your web operation logic
You compile
You run the resulting exe
That's it!
On your second point about ASP.Net - it is a framework that has gone through a lot of evolution trying to keep up with very rapid changes in the web development world. This meant it got a bit bloated and lost some of its coherence, but recently the developers have been focussed on making it more lightweight, more modular and simpler. Scott Guthrie summarises it in his blog:
http://weblogs.asp.net/scottgu/introducing-asp-net-5
Why does ASP.NET have so many different choices of projcets? (Web Application, Web API, Web Site, MVC ect). I just want to listen on a tcp port, and a way to send a response. etc...
Because each project has its own purpose.
If you want to just listen on a TCP port then you could go learn Microsoft's Katana OWIN (but I highly doubt if this is what you want).
Katana OWIN
Briefly going through each projects purpose:
"Web Application" actually opens up another window and lets you choose from the following:
Web API is for exposing RESTful services or JSON data.
Web Forms is for making web pages that use Web Form components.
(A bit like Windows Forms, but Web)
MVC is for making Model-View-Controller web applications. This is where you build components with a separation of concerns. Model for data. View for what the user sees. Controller for controlling how your page behaves.
Why do I need IIS at all?
IIS is for serving .NET applications.
Without it, it would be quite hard to serve .NET applications.
I'll start with 2 then move on to your first question. IIS will run whatever the .NET web service you need, be it a monstrous WCF service, an ASP.NET application or the most basic http handler.
To my knowledge, ISS is the most straightforward way to use .NET web services. If you are used to PHP, it's basically LAMP or WAMP for .NET, which means it is sort of necessary. There are alternatives, as Mike Goodwin points out, but I have to admit I am not familiar with those third parties. Since replacing a layer for another doesnt mean much, I would stick to the "normal" procedure.
Since you dont want the framework to do a truckload of operations for you, your best bet might be along those lines:
Create a basic ASP.NET projet
Remove the default ASP.Net page because it seems you dont want it
Add a Generic Handler to your project. This will result in a myFile.ashx, which handles http requests and let you build any response you want
Of course, if you dont want to bother with IIS configurations, you'll need someone to setup an URL on IIS and map it against your handler repository.
EDIT:
"Abstraction layers" would be the very definition of frameworks, for good or ill, so you're stucked with it.
Now, since you have a low level background a not-so-intrusive way to work with the .NET web services would probably be the three steps I suggested earlier. You are still stucked with IIS though, in order handles the communications (i.e. manages sockets/requests). That's the way the framework works.
STILL, THERE IS HOPE. If you have complete control over your server (which is not my case, some other IT team manages the web servers), you certainly could build a windows service that listens to some socket and work the requests accordingly. It is a most unusal solution if you want to serve web pages, but would work rather well if you only want to push some data through http requests. If you go down this path, I suggest you take a look at the System.Net namespaces, you'll find some classes like "Socket" there. Combined with a console application or a windows service, you could work something out.
One of my coworkers is former microcontroller designer, I know exactly what kind of feeling you have towards the .NET framework. You'll go through some frustrations at times, but most of the time there are work arrounds. Feel free to request more details if you need some.
I went through http://www.asp.net/aspnet/overview/owin-and-katana/an-overview-of-project-katana and was wondering what is the difference between HTTP module and owin middleware. Some pointers that i can think of are
1) Owin middleware decouples the application from host/server. So that it is no longer necessary for me to hook my application logic specifically to System.Web
2) Owin middleware are executed in the order they are added ( not sure if the same holds true for HttpModules; may be depends on how i have added them in web.config)
3) HttpModules helps me to attach my code specific to a application events. Owin middleware is independent of these events
Please also let me know of practical example of using a OWIN module and not a HttpModule.
Some more links i ended up reading (i'll keep on adding here as and when i encounter new)
http://www.cloudidentity.com/blog/2013/07/23/securing-a-web-api-with-windows-azure-ad-and-katana/
Update : perhaps this has the anwer i was looking for
http://www.asp.net/aspnet/overview/owin-and-katana/owin-middleware-in-the-iis-integrated-pipeline
When should I use OWIN Katana?
Thanks.
1) and 3) is correct, 2) is true for HttpModules as well, so no difference. The point is that OWIN doesn't have the very complex infrastructure of ASP.NET requests, and it's host independent. In fact, you can host OWIN applications inside another .NET application if you so desire.
As far as I'm concerned, if you're going with a modern infrastructure, built on ASP.NET MVC, WebApi or such, forget HttpModules. They're part of an infrastructure built ages ago, and for very different problemes than those modern web developers face. It's also usually a lot easier to integrate different services under OWIN (and the built-in OAuth authentication and similart hings are quite handy).
Now, if you're still developing web applications using the "old" WebForms model, HttpModules migth still be a better choice - hosting WebForms in OWIN is possible (and probably works well), but the benefits kind of disappear. However, if you want a thin HTTP end-point, OWIN is just awesome; it's very lightweight and simple compared to the old ASP.NET infrastructure. The fact that it isn't tied strongly to IIS is just a cherry on top. Personally, I still use it with IIS, although I can definitely see a use for a light-weight HTTP server inside a different service. Also, don't forget that IIS version is tied to Windows version - using all the latest features often needs a server upgrade on IIS.
I am new to OWIN and Katana. I really don't get why I should use OWIN, while I can use IIS. To simplify, my question is: What do I lose if I skip learning OWIN and use IIS for my websites?
I googled but there is not a simple explanation. There is some information here, but they use some jargon phrases so I cannot understand it.
In asp.net WebApi v2, the OWIN pipeline becomes the default. It is eventually going to be the standard pipeline under any asp.net project.
I cannot put it better than what is written here : http://www.asp.net/aspnet/overview/owin-and-katana/an-overview-of-project-katana
The section "The Open Web Interface for .NET (OWIN)" explains perfectly the goals of OWIN.
Without OWIN, the asp.net bits are coupled to the way IIS communicates with the application. OWIN abstracts web servers and framework components. That means that your application code will now be aware of the OWIN interface, but not of the webserver that is serving the request.
In return, applications can be more easily ported between hosts and potentially entire platforms/operating systems. For example, the ability to host an application in a console or any process allows Mono to host it without efforts... (Raspberry Pi anyone)
The second aspect is that it works as a pipeline.
You can plug any middlewares (and as many as you want) between the webserver and your application.
This allows for more modular solutions. You can develop redistributable middlewares that can impact the request/response coming to/from your application, but keep these modules separated from the application code.
To persuade yourself of the benefits of this modular approach, take a look at the nuget packages available for OWIN : http://www.nuget.org/packages?q=owin
A lot of these packages were previously core asp.net functionality, and have been extracted as middleware.
For example, adding support to login using various OAuth providers becomes an infrastructure concern (a middleware) and does not need to be part of your application code anymore :
http://www.nuget.org/packages/Microsoft.Owin.Security.Google/
http://www.nuget.org/packages/Microsoft.Owin.Security.Facebook/
http://www.nuget.org/packages/Microsoft.Owin.Security.ActiveDirectory/
...
Or if you want to automatically replace all the images from your website by cute cat images, you can do that transparently as well :
https://github.com/serbrech/Owin.Catify
EDIT : It is now available as a nuget package : Owin.Catify!
public interface OWIN
{
void ListenHttpCallAndServeWebPage();
}
namespace Microsoft.OWIN
{
public class Katana : OWIN
{
public void ListenHttpCallAndServeWebPage()
{
// listen to a port for HTTP call and serve web page
}
}
}
Yes, thats right. OWIN is an interface and Katana is an implementation of OWIN interface by Microsoft. Therefore we hear these 2 words (OWIN / KATANA) together and manytimes we get confused between the difference between these 2 terms. So, Katana is Microsoft's implementation of OWIN interface. Say there is another company named BIG-BOSS who wanted to create their own implementation of OWIN, they can do that and name their implementation as 'BATANA' and advertise phrases like OWIN / BATANA.
So, why OWIN !!!
Think about a country where the only vehicle available for movement is a truck. Nothing else. If you want to buy a vehicle, you would buy truck. Well, that used to serve good but people started to realize that, they don't need truck all the time, especially when they want to go to watch a movie or buy milk, driving a heavy truck not only costs high fuel, but also add stress on driving. But yes, if they want to carry lots of heavy stuff, truck serves the purpose very well.
Then, the Government of that country came up with a specification for vehicle makers. The specification is as follows:
A vehicle needs to have 4 wheels
A vehicle must have a steering.
A vehicle must have headlight and signal lights.
So, based on these specifications, anyone can make vehicle according to different needs and they can name their vehicle accordingly. Therefore, Sedan, Pickup Truck, SUV, VAN, ..etc.. all kind of vehicle showed up in the market. If someone does not need to carry heavy stuff all the time, rather needs a vehicle just for going to workplace, he/she can buy a little Sedan. Someone can buy SUV if he needs little more power.
Based on the above example, we can say that our ASP.NET Web application uses System.Web Assembly which is heavily loaded (like a truck) and if we want to make a little Web Application where our purpose is just to serve some files based on a little set of requests, we are bound to use that heavy System.Web assembly (truck). Now, OWIN shows up. OWIN is a set of specification (we can call it interface) that defines a Server. Based on that specification, someone (like a vehicle maker) can make various kind of servers based on specific problem domains / application needs. Microsoft created their own Implementation for OWIN named Katana in the same way which can serve Web API. As WebAPI is a light weight technology, which does not need full blown System.Web things, a light weight Server implementation (like Katana) can boost the performance heavily when you use Web Api hosted on Katana.
Now, if you ask, 'Do I need it' ? Answer is, 'It depends on your need of performance'. If you don't mind driving your truck even for going to watch a movie, then, perhaps you do not need OWIN. But if you feel that, a light weight Sedan car is all you need to drive within a city, small distance, watch movie..etc.. yes, You may check what implementations of OWIN available in the market. Katana is one of the implementations of OWIN, therefore you can check what Katana offers. Not only Katana, if any other company implements OWIN according to specific Domain (for example, a server for Medical Devices which will download latest medicine information) and if you are a doctor, perhaps, you can check that implementation of OWIN. Moreover, you yourself can create your own implementation of OWIN targeting any specific niche.
In terms of web applications, if you are a simple Web developer, developing custom Websites for your clients, perhaps, you do not need to worry about custom implementation of OWINs, because IIS will serve you in a balanced way. If you build a Web API project, you will get Katana based template ready made from Visual Studio -> New Project, so you won't have to worry about anything other than learning Katana specific techniques. At this moment, Katana is not mature enough to completely replace the need for IIS for ASP.NET MVC, but perhaps, in the future it will.
Then When I may need to write my own OWIN Implementation ?
Answer: Well, say for example, you have developed a Windows application which should run as a server in the background and listen to a port number XXXX. Your server will respond to only some set of Requests like this:
GET Inventory
DELETE Inventory ID=4
PUT Inventory ID=5
That's all. And nothing else. So, why would you need a full IIS web server for this little task? You can create your own OWIN implementation in that case. (Perhaps, you will use Katana for that)
Ok, so I understood that, if I want to make a ASP.NET MVC website, I don't have the option to replace IIS, then why should I need to know about Katana at this moment ?
Answer: Even though Katana is not mature enough to replace the need of IIS so that you can host your ASP.NET MVC website directly on Katana, but Katana implemented many cool interfaces of OWIN so that you can take the advantage of using those features side by side. For example, allowing your users to login using Facebook, Google, Twitter etc was not very easy before. Katana gives you many hooks (as a middle-ware) so that you can let Katana take care of external Social Media based Authentication easily without writing plumbing code. There are many other benefits to using Katana that you may find out when you start using this technology.
A simpler version of that answer is that Katana is gong to fully replace System.Web assembly and the old ASP.NET pipeline, which gives you both better flexibility (use it in more scenarios and use only the parts you like) and performance.
So everyone should watch its evolution now and be ready to switch when it is finally completed.
Below is a diagram I drew to fill in the details Microsoft fails to include in this article.
OWIN is such a standard that it let application frameworks run upon it and forget about everything beneath it. On the other hand, OWIN itself utilizes various host adapters to make sure it can talk to the underlying web servers (IIS and many others).
I am now working with the Jexus web server author to investigate how we can write a host adapter to bridge OWIN/Katana and Jexus. We are really happy to learn that OWIN is flexible and highly customizable.
Reference:
http://blog.lextudio.com/2014/06/why-owin-matters-a-lot-for-asp-net-developers/
Why I should use OWIN, while I can use IIS?
OWIN is designed to decouple web servers from the frameworks you work under. It can make the applications lightweight and portable for the mixing frameworks and servers.
And Katana is Microsoft’s implementation of OWIN components.
Since last few years Microsoft is making web tools more agile and responsive as the their plan is progressing. For an example, the development of ASP.Net MVC and ASP.Net Web API. They do not depend on System.Web dll which is a huge burden they feel now I think. Advantage is both developments fixes can be provided on a timely manner and the cycle is faster than ever. Also now developers can deploy these applications on custom OWIN hosts or Katana, which is a reference of OWIN implementation.
What's the point after all?
Microsoft has released a project which is a lightweight OWIN based web host on top of IIS, called `Helios. The goal is to avoid ASP.NET/IIS relationship by providing some independent small components that can be used, installed and manage independently running on a web-host that implements the OWIN specifications.
One of the core reasons is the performance-factor. Helios will be able to achieve 2x-3x more throughput than standard ASP.Net application. In terms of memory consumption, Helios is much better than System.Web dll. In a taken benchmark Helios architecture allowed a sample application to achieve 50000 concurrent requests with approximately 1GB less overhead compare to a standard ASP.Net application.
OWIN is an abstraction between the web application and the hosting platform. If you write your web application using OWIN you are not tied to IIS, you can use another host if you like.
You asked why use OWIN rather than IIS, but these are not alternatives to each other. OWIN sits between IIS and your application so that you can switch out IIS without rewriting your application.
You might also like to check out this page https://github.com/Bikeman868/OwinFramework/wiki/OWIN
I have a number of web apps running on several IIS6/Server 2003 boxes. They run well and are happy. They are all asp.net web apps and use .NET 3.5.
What, if any, would be valid reasons for contemplating moving the web apps to IIS7/Server 2008?
IIS7 is rewritten from the ground up with a concept of being "pluggable". IIS7 is more extensible than it ever has been before. The entire request pipeline has be reworked to allow you to more easily work with requests, as well.
From a performance aspect, these changes are immediately recognizable. You can run sites developed for IIS6 in a "Classic" application pool that will preserve compatibility, but provide a noticeable performance boost. In the non-scientific evaluation that we have done so far, our legacy application has seen about a 20% reduction of load times on our IIS7 test machine.
Of course, the reason we have to run in "classic" mode is an interesting side note. Inside the global.asax, there is some pre-fetching on application start which touches the HttpContext. Specifically, there is pre-caching done, which IIS7 does not allow. So, before we can switch from "classic" mode, there are some changes that we will have to make.
Eventually, Microsoft will discontinue Server 2003 support. Admittedly, that won't be for several years, so it doesn't impact you today.
Improved support for ASP.NET MVC. This is probably the big one for most of us. You can get ASP.NET MVC working on IIS6, but there are some hoops to jump through.
I'd give you more, but I myself am not yet on Server 2008 yet, and have nothing else to give. Presumably Vista (which I do use, both at work and at home) has the "same" IIS7 as 2008 does -- the UIs certainly look very similar -- but I wouldn't consider my experience there to be useful to your question.
Ability to write pipeline components in managed langauges. Previously, if you wanted to write an ISAPI filter to handle a certain type of web request, you'd have to write it in C++. Now, you can use good ol' .NET code. This allows more customization with the ability to write reusable pipeline components for handling various types of request. For example, all .js file request are routed to a ScriptCompressor pipeline component which zips and returns them with lots of cacheability set up.
The improved support for MVC is linked to this as you can set II7 to route requests without extensions to .NET so you can have urls which are "cleaner" such as http://www.yourwebsite.com/customer/1 without having any extension visible which reveals what type of server technology you're using and is very untrendy these days.