ASP.NET/WCF Integration Architecture with IIS



                                                                                                            <<Prev                        Next>>

Aspnet_isapi.dll is responsible for loading the common language runtime (CLR) into the worker process and creating a default application domain, which is where the managed hosting components of ASP.NET will live. These managed hosting components are responsible for creating additional application domains (one per IIS application) on demand and routing requests to them based on the request's URL.


In IIS 6.0 and previous releases, ASP.NET was implemented as an IIS ISAPI extension.
In these earlier releases, IIS processed a request to an ASP.NET content type and then forwarded that request to the ASP.NET ISAPI DLL, which hosted the ASP.NET request pipeline and page framework. Requests to non-ASP.NET content, such as ASP pages or static files, were processed by IIS or other ISAPI extensions and were not visible to ASP.NET.
The major limitation of this model was that services provided by ASP.NET modules and custom ASP.NET application code were not available to non-ASP.NET requests. In addition, ASP.NET modules were unable to affect certain parts of the IIS request processing that occurred before and after the ASP.NET execution path.

Figure 1: IIS 6.0 & ASP.NET Pipelines


In IIS 7.0, the ASP.NET request-processing pipeline overlays the IIS pipeline directly, essentially providing a wrapper over it instead of plugging into it.
IIS processes requests that arrive for any content type, with both native IIS modules and ASP.NET modules providing request processing in all stages. This enables services that are provided by ASP.NET modules, such as Forms authentication or output cache, to be used for requests to ASP pages, PHP pages, static files, and so on.
The ability to plug in directly into the server pipeline allows ASP.NET modules to replace, run before, or run after any IIS functionality. This enables, for example, a custom ASP.NET Basic authentication module that is written to use the Membership service and SQL Server user database to replace the built-in IIS Basic authentication feature that works only with Windows accounts.
In addition, the expanded ASP.NET APIs use direct integration to enable more request-processing tasks. For example, ASP.NET modules can modify request headers before other components process the request, by inserting an Accept-Language header before ASP applications execute, which forces localized content to be sent back to the client based on user preference.

Figure 2: IIS 7 and Above Integrated Mode
Because of the runtime integration, IIS and ASP.NET can use the same configuration to enable and order server modules, and to configure handler mappings. Other unified functionality includes tracing, custom errors, and output caching.


How WCF requests gets handled in .Net 3.5

Up to the point that the request reaches the worker process,it behaves much like any other request that is handled by aspnet_isapi.dll. The difference is in what happens after the ASP.NET pipeline gets hold of the request. For all requests, configured HTTP modules have an opportunity to interact with request processing at specific points in the lifecycle of the request by handling specific application events. At some point during request processing,the pipeline also looks for an HTTP handler type that should be constructed to process the request according to file extension.
Ultimately,the HTTP handler is responsible for processing requests, but this usually happens after the pipeline has had a chance to authenticate the call,verify that the request was not previously cached,reestablish the session if applicable,and process any other code injected by HTTP modules early in the request lifecycle. After the handler executes,HTTP modules then have another opportunity to interact with the response as it flows back through IIS to the client. Since service operations should be handled by the WCF processing model,not ASP.NET,the service model alters this pocessing lifecycle.

The service model provides its own HttpModule and HttpHandler types,located in the System.ServiceModel.Activation namespace. Both of these components interact with requests directed to a .svc endpoint using traditional ASP.NET configuration settings. As far as ASP.NET is concerned,the HttpHandler type is the target for request processing,but that would mean the request would pass through the usual ASP.NET pipeline with all of the configured modules for forms authentication,caching,and session,for example. By default,the service model bypasses this by pipeline,by hijacking requests targeting .svc endpoints and forwarding them to the service model for processing.

The service model HttpModule gets engaged very early in the lifecycle,handling the PostAuthenticateRequest event and,by default,forwarding the request to the service model. In fact,the service model allocates a thread from the WCF thread pool  and releases the ASP.NET thread so that another incoming request can use it. This behavior ensures that all requests to WCF services are processed in a consistent manner,regardless of whether they are self-hosted or hosted in IIS. The service model handler is never invoked unless ASP.NET compatibility mode is enabled.

Pasted from Learning WCF - Michele Leroux Bustamante

Even though the above text as per Michele talks about releases asp.net thread, it is not actually the case as per Wenlong Dong's Blog. Hence in (.NET 3.5 SP1), WCF has implemented the asynchronous HTTP Module/Handler to allow better server scalability for high latency requests.

Asynchronous WCF HTTP Module/Handler
Besides the existing synchronous WCF HTTP Module/Handler types, WCF introduced the asynchronous versions. Together, WCF has the following four types implemented:
· Synchronous Module:
System.ServiceModel.Activation.HttpModule, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
· Asynchronous Module (new):
System.ServiceModel.Activation.ServiceHttpModule, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
· Synchronous Handler:
System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
· Asynchronous Handler (new):
System.ServiceModel.Activation.ServiceHttpHandlerFactory, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
Though the asynchronous version of HTTP Module/Handler is added in this release, the default installation is still the synchronous version

 .Net 4.0
Default Installation in the Integrated Pipeline mode uses the  asynchronous HTTP Module/Handler and hence it doesn’t block any Asp.Net Worker Thread while WCF process the request in IO Thread.


                                                                         <<Prev                        Next>>

2 comments:

Subscribe to: Posts (Atom)