I thought I would give you a little feedback of the OWIN functionality for Wisej.
It isn’t very often that I ever get a holy crap moment but I did with this! I am very intrigued with the possibilities of what this could open up.
I do have a question on how would you deploy this to clients and how would updates be performed? We use applications with click once and the users like the automatic updates.
Great job and thanks!
The OWIN approach is an interesting concept for different deployment scenarios. Here is our licensing model if you want to deploy Wisej projects as a self-hosted app:
If you have to deploy a number of “micro servers”, please contact us to discuss the different options. We have the ISV unlimited deployment for up to 5 concurrent users that is inexpensive and it’s designed for small low-cost deployments for which the self hosting feature is a good fit.
Besides that, we’d be happy to hear about your experience with Wisej OWIN and other deployment scenarios. Please share how you use it to help us improve and extend Wisej.
Thanks for your comprehensive answer.
I’ve read a lot about NGINX vs Apache. NGINX was designed to solve the C10K/C10M issue and uses asynchronous, non-blocking, event-driven connection handling algorithm. It scales far better than Apache and is the choice for load balancers and/or frontend proxy for other web servers.
If the web server is Microsoft.Owin.SelfHost and we just need a frontend proxy, I’d say NGINX is the way to go as it’s much better at this job than Apache.
Owin/Katana basically replaces the classic and integrated pipeline used by IIS to communicate with web applications. An example of those handlers are AspNet WebForms, AspNet MVC, AspNet WebApi, etc. The System.Web handlers with OWIN are now middlewares.
If you look in /src you’ll see a bunch of projects, most of them are middleware (handler) to perform various tasks: serve static files, authentication, diagnostics, etc. One of those projects is System.Web handler that lets an OWIN stack of middlewares work with IIS.
Another project in there is Microsoft.Owin.SelfHost, which is a lean web server that implements the OWIN interface. So you can use the OWIN stack from a) IIS; b) self hosted using Microsoft.Owin.SelfHost; or c) you can write your own listener or process that is not even a web server and use the OWIN stack.
In Wisej.HostService we used the Microsoft.Owin.SelfHost web server and added the Wisej middleware. You can see in the source code the call to app.UseWisej();
However, as of today, there is no way to self host an AspNet WebForms application with OWIN, or actually anything other than IIS or Cassini.
Our implementation (WisejHost) starts a new application host using System.Web.Hosting.ApplicationHost.CreateApplicationHost to create a new AspNet Application Domain (which is what IIS or Cassini do), then from the new App Domain we start the Microsoft.Owin.SelfHost host and feed the OWIN pipeline.
But, since we kept the entire Wisej core system intact (the HttpHandler and HttpApplication, AspNetWebSocketContext) and our Wisej middleware implemented the System.Web.HttpWorkerRequest abstract class to feed the existing Wisej IHttpAsyncHandler, we can also feed the entire AspNet WebForms (or anything else related to AspNet) directly. In fact with Wisej.HostService you can self host any AspNet application without Wisej. There is no other implementation that can do that. In other words, our OWIN middleware does the opposite of Microsoft.Owin.Host.SystemWeb, it makes OWIN work with the IIS pipeline without IIS.
What do you lose compared to IIS? Well, IIS is a large system with a lot of stuff built in. When you self host you are on your own, so to speak. If you need authentication you have to choose a middleware that performs the authentication that you want. If you need compression, the same (although Wisej already compresses all responses, http or websocket). IIS allows you create App Domains, with Wisej.HostService each instance is a domain, but you can run multiple instances on the same machine (different port).
An interesting use for Wisej.HostService it to work together with NGINX or Apache (NGINX is better IMO, very small and easy to use). I have tested it with multiple Wisej.HostService instances and it works perfectly. Once you know how to configure NGINX…
The Wisej.Application (Standalone) feature is a bit different. It uses exactly the same code but it runs the server and the viewer in the same process (different app domains). You can use it as a traditional desktop (or client/server) application and it can serve external users at the same time. I’m thinking about an “appliance” app, a kiosk.
In both cases, our projects are configured to merge all the OWIN/Katana assemblies (and Chrome Cef implementation) into a single executable to simplify deployment.
This self hosting/standalone feature is a very nice feature and moves Wisej way into the future.
After reading about OWIN (the standard) and Katana (the implementation) I checked the Katana project at https://github.com/aspnet/AspNetKatana and found out it’s alive and with fresh commits (2 months old).
It looks like Katana is the only implementation of OWIN around. I understand Katana is a middleware, not a Web Server.
So there is something I don’t get: where is the Web Server? What piece of software is playing the Web Server role in the self hosting solution?
Since the self hosting solution isn’t using IIS, we must compare it with IIS. The advantages are obvious, but what do we loose? Is it less robust? Is it as secure as IIS?
Very happy to hear! So, here are some more info:
The entire system is solid and works with everything because, as you can see from the small source code involved, it’s comprised of 3 parts:
You can easily personalize the standalone version with your splash screen, add controls that can interact with the embedded app, or even have multiple views (multiple apps) in the same standalone window. In the future we may add the option to go full screen.
There is no installation required, it’s a simple xcopy deployment. You can update the app by replacing the assemblies in /bin or the related resources (images, scripts) in the project root. I don’t know which is the best way to do it remotely though.
The standalone version (IE or Chrome) can also serve external users with a browser if you change the domain from localhost to * by adding -domain:* to the startup command line. In fact you could create a server app with a live monitor/configuration UI and serve outside users.
The host service can run as a process or as a service. To install it as a service us -i in the command line, it will add itself to the services and run automatically when the machine is powered up.
We recently tested it with NGINX as a proxy and it works amazingly well as a load balancer too and it preserves the WebSocket functionality.