I have had a read on what's new in .NET4.6 and one of the things is ASP.NET 5 which I am quite excited about.
One of the new things is New modular HTTP request pipeline, however there is no more info on how exactly is it going to change.
The only reference in the article is
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, your app will
experience better throughput. The new pipeline also supports OWIN.
What are major differences between ASP.NET4.5 and ASP.NET5 Http pipelines? How modularity will be controlled?
The biggest difference in my opinion is the modularity of the new request pipeline. In the past, the application lifecycle followed a relatively strict path that you could hook into via classes implementing IHttpModule. This would allow you to affect the request, but only at certain points along the way by subscribing to the different events that occur (e.g. BeginRequest, AuthenticateRequest, etc.).
The full descriptions of these can be found on MSDN: IIS 5 & 6 or IIS 7, and a walkthrough of creating such a module can be found here.
In the new ASP.NET 5 world, the request pipeline is decoupled from System.Web and IIS. Instead of a pre-defined path, it uses the concept of middleware. If you are familiar with OWIN, the idea is nearly identical, but the basic idea is that these Middleware Components are registered and then the request passes through them in the order that they are registered.
Each middleware component is provided a RequestDelegate (the next middleware component in the pipeline) and the current HttpContext per-request. On each request, the component is invoked, and then has the opportunity to pass the request along to the next in the chain if applicable. For example, an authentication component might opt not to pass the request along to the next component if authentication fails. Using this system, you can really handle a request any way you choose, and can be as light-weight or as feature-rich as you need it to be.
This example is a little bit dated now (e.g. IBuilder has been renamed to IApplicationBuilder), but it is still a great overview of how building and registering these components looks.
Related
There's one point in ASP.NET Core that I believe I didn't fully understand yet and that is the idea of request features. As explained in the docs:
Feature interfaces define specific HTTP features that a given request may support. Servers define collections of features, and the initial set of features supported by that server, but middleware can be used to enhance these features.
My initial understanding about this was that request features are all things a server should expose to be used on the application pipeline. That is, behaviors that a server should perform like sending a file.
On the other hand, there's, for example, the authentication request feature. Now, I'm not sure authentication falls into this category. It doesn't seem like some server behavior that the application should call, but rather, a concern of the application itself.
This makes me wonder what really makes something be a request feature. So, what makes something be a request feature in ASP.NET Core? Is my initial understanding wrong? What is behind the decision of making something a request feature?
My initial understanding about this was that request features are all things a server should expose to be used on the application pipeline. That is, behaviors that a server should perform like sending a file.
That's one use of http features. It's also a way to augment or light up behaviors on the HttpContext, like buffering, send file, authentication, websockets.
Middleware can also add features specific to that middleware, you can see examples of this:
The exception handler middleware flows the exception that occurred via a request feature - https://github.com/aspnet/Diagnostics/blob/dev/src/Microsoft.AspNetCore.Diagnostics.Abstractions/IExceptionHandlerFeature.cs.
The routing middleware adds route data to the current http context via a request feature - https://github.com/aspnet/Routing/blob/dev/src/Microsoft.AspNetCore.Routing.Abstractions/IRoutingFeature.cs
Generally it's a way to flow per request behavior and state from the server, through middleware, to the application.
I'm reading the OWIN 1.0 spec at http://owin.org/spec/owin-1.0.0.html and just can't wrap my head around how it works. I've downloaded Katana source, but that's huge and didn't help any. I'm familiar with the somewhat standard way of having a project/assembly with interfaces only, which allows to integrate two projects without direct regencies. But I can't understand how the web server will call into the web app with only Func<> and Action<> definitions.
OWIN boils down to two things:
1) an "environment" dictionary
2) a method that processes requests and sends responses.
For #1, this is just a property bag that gives you access to the request headers, request stream, response headers, response stream and server data. Think of this as your HttpContext for ASP.NET or HttpListenerContext for System.Net.HttpListener. In fact, in more recent builds of Katana (https://katanaproject.codeplex.com/, which is an open source implementation from the ASP.NET team, there have been improvements (more to come) to simplify this down to an easier to use object model, including an OwinRequest, OwinResponse, and IOwinContext.
For #2, this is often called the "AppFunc" and the signature is:
using AppFunc = Func<IDictionary<string, object>, Task>;
This signature is used for "Middleware" that is in a pipeline of request handlers or it can be the end application which is generating HTML, is a WebAPI, etc.
In Katana, there is a class you can inherit from that simplifies this signature to consume the IOwinContext I mentioned previously. Take at look at OwinMiddlware
You can also read this article which gives an overview of the Katana/OWIN effort: http://www.asp.net/aspnet/overview/owin-and-katana/an-overview-of-project-katana
OWIN just defines how the web server and web application will talk to each other. Your application must implement one side of this contact, the other side which connects to the web server must be provided by installing a NuGet package specific to the web server. There is one for IIS, one for self hosting (stand alone application) etc.
I'm having problems because of a poorly written third-party library which our system heavily depends on. This library is not thread-safe (because of some bugs and static variables) and I need to use it in a ASP.NET webservice, which handles each user request in a separate thread.
I've tried many solutions for this problem. The best solution for now is, in my opinion, let subprocesses handle the requests. One subprocess will listen and handle the requests for one user, so I can synchronize access to the library code in a per user fashion, which is much better than all that I can do when sharing static variables between requests.
How can I route requests received by IPC communication to the appropriate WebMethods without reinventing the wheel? If possible, I would like to use the classes from .Net that handle this in a normal ASP.NET webservice, but I'm having a hard time trying to find their names.
TL;DR: I have a class MyWebService (that inherits from System.Web.Services.WebService) with some methods marked with WebMethodAttribute and I want to pass a made-up HttpRequest (or HttpContext) to it and tell it "handle it like you're receiving this from a real HTTP server, despite the fact the current process is a console application".
First, you may want to consider using WCF instead of ASMX, which is a legacy technology, kept only for backwards compatibility.
Second, you have another option: ensure that only a single thread ever uses the third-party libarary at a time. Placing lock blocks around all access to the third-party library may solve the problem.
I've just read this interesting article regarding simultaneously calling multiple methods on a WCF service from Silverlight:
http://weblogs.asp.net/olakarlsson/archive/2010/05/20/simultaneously-calling-multiple-methods-on-a-wcf-service-from-silverlight.aspx
The article states: "It turns out that the issue is founded in a mix of Silverlight, Asp.Net and WCF, basically if you’re doing multiple calls to a single WCF web-service and you have Asp.Net session state enabled, the calls will be executed sequentially by the service, hence any long running calls will block subsequent ones."
I am assuming that the blocking is only an issue if you are making multiple calls to the same service, and that two simultaneous calls to two different methods on two different services should not result in one blocking the other?
The suggested solution to the problem in SL3 involves using the following syntax in the Application_Startup method:
WebRequest.RegisterPrefix("http://", WebRequestCreator.ClientHttp);
The session state will then have to be maintained on WCF calls by seting up a cookie container, and sharing it across all of your proxies (see http://forums.silverlight.net/forums/p/174322/393032.aspx)
Is this still the recommended solution in Silverlight 4? Has anyone used an alternative approach?
In .NET 4, you can do this in Application_BeginRequest
if (Context.Request.Path.EndsWith("xxx.svc"))
Context.SetSessionStateBehavior(SessionStateBehavior.Disabled);
If you are making a call into an ASP.Net application, and you are using session cookies, then all the calls into the application are serialized (apart from ones where the page explicitly opts out of session state).
Normally this isn't a big issue, because a client browser typically hits an ASP.Net page plus a bunch of resources (images, js, css etc...), and these latter aren't mapped to ASP.Net so IIS serves them up natively. But if you try and hit two ASP.Net pages at the same time (eg in a frameset) you will see them load up one after another.
Now I don't know that this happens with WCF, but based on what you say, if you see that behaviour for one service I would expect to see that for all of them, because the session is per-user, not per-service.
In ASP.Net you can 'opt out' of session state on a page by page basis. If that's possible for a hosted WCF service, and viable for your scenario (to make the services stateless) that would aleviate the issue. Or move one or more services to a different ASP.Net application (different session)
Bear in mind that you can see other issues here to do with the instancing and reentrancy models of the service. Your problem as described above is a per-user concurrency issue, but there are others. For example, if you set the service up as a singleton (InstanceContextMode.Single) and non-reentrant (ConcurrencyMode.Single) then only one request will ever be processed at a time across all users.
Update: Doing some doco reading:
WCF services aren't enrolled into ASP.Net sessions unless you ask for it (using )
WCF services can on a per service basis opt in, using the [AspNetCompatibilityRequirements] attribute on the service implementation
There doesn't seem to be any way of opting in but not opting into Session state.
There's a good blog post about this on Wenlong Dong's site
So from what I can see you should be able to use AspNetCompatibilityRequirementsMode.NotAllowed to opt out individual services completely from ASP.Net services. Alternatively, leave it off by default and only opt-in the ones that need access to the ASP.Net session (bearing in mind that unless you really need to share the same session with ASP.Net, just using WCF's session services is probably a better bet).
I've been a longtime ASP.NET developer in the web forms model, and am using a new project as an opportunity to get my feet wet with ASP.NET MVC.
The application will need an API so that a group of other apps can communicate with it. I've always built API's out just using a standard web service prior to this.
As a sidenote, I'm a little hesitant to plunge headfirst into the REST style of creating API's, for this particular instance at least. This application will likely need a concept of API versioning, and I think that the REST approach, where the API is essentially scattered across all the controllers of the site, is a little cumbersome in that regard. (But I'm not completely opposed to it if there is a good answer to the potential versioning potential requirement.)
So, what say ye, Stack Overflow denizens?
I'd agree with Kilhoffer. Try using a "Facade" wrapper class that inherits from an "IFacade". In your Facade class put your code to consume your web service. In this way your controllers will simply make calls to the Facade. The plus side of this being that you can swap a "DummyFacade" that implements the same IFacade interface in that doesn't actually talk to the web service and just returns static content. Lets you actually do some unit testing without hitting the service. Basically the same idea as the Repository pattern.
I would still recommend a service layer that can serve client side consumers or server side consumers. Possibly even returning data in a variety of formats, depending on the consuming caller.