Monthly Archives: February 2015

Owin and Katana – A Very Interesting Perspective

I have talked @ in earlier blogs @ OWIN and Katana in summary

OWIN defines a standard interface between .NET web servers and web applications. The goal of the OWIN interface is to decouple server and application, encourage the development of simple modules for .NET web development, and, by being an open standard, stimulate the open source ecosystem of .NET web development tools.

Katana – OWIN implementations for Microsoft servers and frameworks

Therefore we hear these 2 words (OWIN / KATANA) together and many times 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 AppleGoogleIBM who wanted to create their own implementation of OWIN, they can do that and name their implementation as ‘XYZ’ and advertise phrases like OWIN/XYZ

Why OWIN

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, specially 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 stuffs, 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:

  1. A vehicle needs to have 4 wheels
  2. A vehicle must have a steering.
  3. 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 stuffs 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 dont 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 implementation 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.

When I may need to write my own OWIN Implementation ?

You have developed an 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:

  1. GET Inventory
  2. DELETE Inventory ID=4
  3. PUT Inventory ID=5

Thats 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).

Advertisements

ASP.NET vNext – Whats in store…. Now ASP.NET Core

aspnetandcore

ASP.NET vNext (Core) has these new Features..

  • New flexible and cross-platform runtime
  • New modular HTTP request pipeline
  • Cloud-ready environment configuration
  • Unified programming model that combines MVC, Web API, and Web Pages
  • Ability to see changes without re-building the project
  • Side-by-side versioning of the .NET Framework
  • Ability to self-host or host on IIS
  • New tools in Visual Studio 2015

ALL ASP.NET Source code has been open sourced on Git Hub…
ASP.NET offers 3 runtimes

  • Full .NET CLR : Full .NET CLR is the default runtime for projects in Visual Studio. It provides the entire API set and is your best option for backwards compatibility.
  • Core CLR (cloud-optimized runtime) : The Core CLR is a lean and completely modular runtime for ASP.NET 5 projects. This CLR has been re-designed into components so you have the flexibility to include only those features that you need in your app. You add the components as NuGet packages. When you are finished, your app is dependent only on required features. By re-factoring the runtime into separate components, we can deliver improvements to the components more quickly because each component is updated on its own schedule. The Core CLR is about 11 megabytes instead of around 200 megabytes for the full .NET CLR. The Core CLR can be deployed with your app and different versions of the Core CLR can run side-by-side.
  • Cross-Platform CLR : Cross-platform runtime for Linux and Mac OS X. When released, this runtime will enable you to develop and run .NET apps on Mac and Linux devices.

Host anywhere : ASP.NET 5 enables you to host your app on IIS or self-host your app in your own process. When you target the Core CLR, you can deploy your app with every dependency bundled within the deployment package. Therefore, your app and its dependencies are completely self-contained and no longer dependent on a system installation of .NET.

Different versions of .NET side-by-side : When apps on a server depend on a single, system-wide installation of the .NET Framework, all of the apps have to run the same version of .NET. This situation might have created some anxiety for you when considering whether to upgrade to a new version of the .NET Framework. Perhaps, you wanted some of your apps to use the latest version of .NET but you were unsure whether all of your legacy apps would work appropriately with the new version. ASP.NET 5 fixes this problem. You can define the dependencies within your deployment package so you can specify for each app which version of .NET to use. You get the benefits of the latest version for some apps and the ease of sticking with an old version for other apps. All of these different versions run side-by-side without any problems. To run different versions side-by-side, you must target the Core CLR

Simplify dependency management: ASP.NET 5 introduces a new, lightweight way to manage dependencies in your projects. You no longer add assembly references to your project; instead, you manage dependencies by referencing NuGet packages. You can add NuGet packages through the NuGet Package Manager or you can edit the JSON file (project.json) that lists the NuGet packages and versions used in your project. To add other dependencies, you simply type the name and version number of the NuGet package into your project.json file. The project.json file only includes NuGet packages that you directly added to your project. If you add a NuGet package that is dependent on other packages, those secondary dependencies are loaded but not listed in the project.json file. This approach keeps your project.json file less cluttered and easier to manage. If you remove a NuGet package from project.json, the secondary dependencies are removed too if no other packages need them.

Eliminate duplication in MVC, Web API: MVC, Web API contained overlapping features but the implementations of those features were separate. For example, MVC and Web API both provided routing but the MVC routing classes resided in the System.Web.Mvc.Routing namespace while similar classes for Web API resided in the System.Web.Http.Routing namespace. Or, Web Pages and MVC both used Razor syntax, but some NuGet packages were compatible with only one or the other. In ASP.NET 5, MVC, Web API will be merged into a single framework called MVC 6. This merging removes duplication from the framework and makes it easier for you to develop apps that use these programming frameworks. You no longer need to write slightly different code depending on whether you are within an MVC, Web API, or Web Pages context.

New Modular HTTP pipeline : ASP.NET 5 introduces a new HTTP request pipeline that is lean and fast. This pipeline is modular so you can add only the components that you need. By reducing the overhead in the pipeline, app will experience better throughput. The new pipeline supports OWIN.

Integrate dependency injection : Dependency injection is built into ASP.NET 5. You can use your Inversion of Control (IoC) container to register dependencies. In ASP.NET vNext, dependency injection is a first class citizen. While in the previous versions of the framework, DI was partially supported, in ASP.NET vNext it is available throughout the entire stack. A minimalistic DI container is provided out of the box but we are leaving the door open to BYOC (Bring Your Own Container). The default container has minimal capabilities. BYOC is possible because of an abstraction over the actual DI container implementation. The abstraction is the IServiceProvider interface and it represents the least set of container behavior our components are limited to assuming are present. All the framework components (MVC, Routing, SignalR, Entity Framework, etc.) rely only on the capabilities of IServiceProvider, but your own application code can use any feature that your chosen DI container has. When you BYOC, you can replace the default implementation of IServiceProvider with a wrapper around your own container. Once that happens, all the dependency resolution calls will be routed to your own container. In the case when you want to use your own container strictly for your own custom types, we support fallback to our default container.The out of the box container supports the following lifestyles:

  • Instance: A specific instance is given all the time. You are responsible for its initial creation
  • Transient: A new instance is created every time
  • Singleton: A single instance is created and it acts like a singleton
  • Scoped: A single instance is created inside the current scope. It is equivalent to Singleton in the current scope

Per Request Scope : In ASP.NET vNext, the Per Request Scope is achieved using a middleware and a scoped lifestyle. The middleware, when invoked, will create a new scoped container which will replace the container for the current request. All the subsequent middleware in the pipeline will then utilize the scoped container. After the request flows through the pipeline and the container middleware is signaled to complete, the scope is destroyed and all the objects created inside it are disposed.

Web Forms : Web Forms 4.6 includes the following new features for Web Forms:

  • HTTP 2
  • Async model binding
  • Roslyn CodeDOM compilers

Existing Web Forms apps will continue to run without modification on IIS with .NET 4.6. You can’t use Web Forms apps with the cloud-optimized runtime.

Applications that you built on earlier versions of ASP.NET will continue to work with the new .NET Framework.

Azure Service Bus + Sessions

Service Bus queues and subscriptions provide support for requiring sessions when receiving messages. Sessions are useful in a number of scenarios where a group of messages are to be grouped together, such as all the items in an order, or when a large document has been split into smaller messages. Sessions are especially useful when an application has load balanced receivers as they ensure that all messages in the same session are received by the same instance of the receiving application.

In order to work with sessions the queue or subscription must be created with the RequiresSession property set to true. Messages sent to the queues and topics that contain session aware subscriptions must have a value set for their SessionId properties. When receiving messages from session aware queues and subscriptions a MessageSession must be used instead of a QueueClient or SubscriptionClient.

Sessions are extremely important, because they allow the receiver to determine whether all the messages that belong to a specific logical group have arrived.