This blog post drills down on the various hosting capabilities of WCF and WF in .NET 4 and for Window Server AppFabric as introduced in in the Introduction to AppFabric blog entry.
When referring to hosting, I am discussing the features of the “application environment”, which enables execution and management of the applications.
The .NET 4 for WCF Web services one focus was on making the application easier to configure and manage. For Workflow (WF) Web services, we integrated the “application environment” with WAS (Windows Process Activation Service) so that you could deploy, execute and manage WF services.
Windows Server AppFabric extends the WAS “application environment” to provide two additional hosting capabilities, namely “Always Running” and “Scheduled Start”.
I will describe these hosting features in detail in this post, so let’s start with the improvements in .NET 4.
.NET 4 Hosting Enhancements
1) Config Based Activation (CBA):
Today when hosting web applications containing services, you need to deploy an additional “.svc” file, describing metadata and information about the services. When organizations/applications have large number of services, there is an inherit explosion of files causing a management overhead. To address this problem, we introduced the config based activation feature which allows registration of the services in the web.config files, eliminating the need for a .svc file.
How-To:
a. Add the service registration to the web.config file of your web application.
In the example below, we register two services, the CreditCheckService and the PaymentService. In addition the Payment/PaymentService.svc specifies a customfactory that can be used for activation.
<system.serviceModel>
<serviceHostingEnvironment>
<serviceActivations>
<add relativeAddress= “CreditCheckService.svc” service=“Microsoft.ServiceModel.Samples.CreditCheckService”/>
<add relativeAddress= “Payment/PaymentService.svc” service=“Microsoft.ServiceModel.Samples.PaymentCheckService” Factory=”CustomFactory”/>
</serviceActivations>
</serviceHostingEnvironment>
</system.serviceModel>
Note: You have the option of using either Service Config Editor or Visual Studio Intellisense to configure the application.
More details about this feature can be found here;
%u00b7 http://msdn.microsoft.com/en-us/library/ee358764(VS.100).aspx
2) Support Multiple Site Bindings:
Many hosters and organizations host their web application over multiple ports and hostnames. This makes their service accessible over multiple addresses. For example the following addresses resolve to the same service.
store.com
OR
www.store.com:80
www.store.com:90
The URLs above require specifying multiple site bindings in IIS. Lack of this support for this feature in the WCF runtime was an adoption blocker in the 3.0 release of the .NET framework. In .NET 3.5, we made some incremental improvements through baseAddressPrefixFilters. In .NET 4, we have addressed more of this feature, which has significantly eased the shared hosting deployment issues.
How-To:
a. Configure Site: Configure IIS site binding with the required host headers.
b. Enable Application: Configure the application web.config file to enable multiple site bindings. See example below.
<system.serviceModel>
<serviceHostingEnvironment multipleSiteBindingsEnabled=”true”>
<system.serviceModel>
Note: Only multiple of http/https site bindings are supported. i.e. TCP and other protocols are not currently supported
More details about this feature can be found here;
%u00b7 http://msdn.microsoft.com/en-us/library/ee358763(VS.100).aspx
3) Enable Extension-less URLs
There are scenarios when you might want to deploy your web service without extensions in the URL say for example, a WCF REST RSS service deployed with these URL
http:://www.store.com/products/
http://www.store.com/Movies
We leveraged System.Web.Routing feature and added a new System.ServiceModel.Activation.ServiceRoute API to enable the registration of WCF services. This enabled us to extend an API customers were already familiar with it to WCF Services.
How-To:
The example below enables activation of a WCF REST service over the URI http://www.store.com/movies
a. Enable runAllManagedModulesForAllRequests
Add the following configuration to the application web.config file. Note: the Visual Studio web application template includes this by default.
<modules runAllManagedModulesForAllRequests=“true“>
b. Register the Route Handler/Module
<add name=“UrlRoutingModule“
type=“System.Web.Routing.UrlRoutingModule,
System.Web.Routing, Version=4.0.0.0,
Culture=neutral,
PublicKeyToken=31BF3856AD364E35“ />
</modules>
<handlers>
<add name=“UrlRoutingHandler“
preCondition=“integratedMode“
verb=“*“ path=“UrlRouting.axd“
type=“System.Web.HttpForbiddenHandler,
System.Web, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a“ />
</handlers>
c. Register the service either in global.asax or AppInitiate() method deployed to App_Code directory.
protected void Application_Start(object sender, EventArgs e)
{ RouteTable.Routes.Add(new ServiceRoute(“movies”, new WebServiceHostFactory(), typeof(Movies)));
}
More details about this feature can be found here –
%u00b7 http://msdn.microsoft.com/en-us/library/ee358764(VS.100).aspx
4) Workflow in WAS
As part of providing the “application environment” for WF, we enabled
1) Activation of declarative .xamlx Workflows when deploy to WAS
2) Continued execution by identifing instance performing work and reporting it to the hosting environment. This ensures that the host process is not un-necessarily recycled.
How-To:
Use the WCF workflow Service Application template to develop WF application to be hosted in WAS/Windows Server AppFabric. These templates will generate .XAMLX resources which are directly hostable in WAS.
Note: if you have custom activities which need to be deployed along with the application, then they need to reference it in the system.web.compilation <assemblies> element.
Windows Server AppFabric Hosting
Now let’s look at the feature for Hosting that Windows Server AppFabric provides in addition to the .NET Framework.
5) Windows Server AppFabric Service Management Service
There are mainly two scenarios why we implemented the service Management Service in Dublin. They are:
A Batch processing
a. The scenario is that you want to batch process orders at off peak times or weekend. Typically this scenario is that a web application takes the order and puts it in the queue, and the orders are processed from at the end of the day when servers are typically otherwise idling.
B Support Windows Server AppFabric Workflow Management Service
b. The Workflow Management Service (WMS) is responsible for resuming “runnable” durable instances. See Introduction to AppFabric blog entry for details. This service uses the Service Management Service as a mechanism to start the WorkflowServiceHost. This is an implementation detail of the Windows Server AppFabric Workflow Management Service.
To support the above requirement there needed to be a protocol agnostic way to start a service and so we introduced the Windows Server AppFabric Service Management Service, which enables starting any service (registered with the application environment) within the application.
How-To
The first question to ask is “How do I address this service?” To demonstrate this with an example.
http://www.store.com/Services/dvd.svc/titleInfo
Above is a URI of a dvd.svc .Remember the fact that Service Management service is an independent service, which resides in every virtual application, and is capable of being activated over the named.pipe transport protocol.
It implements an IServiceManagement interface, which contains the ActivateService method, with one parameter the virtualPath.
Returning to our example, let’s say the above dvd.svc is deployed in the virtual application called “Services”.
To construct URI of the Service Management service
1) Replace the protocol the service URI with net.pipe
2) Replace the hostname with the appropriate host header specified in the site binding
3) Remove the relativeServicePath and append it rest of the path with /ServiceManagement.svc
So for this example, the Service Management Service can be specified with
net.pipe://localhost/Services/ServiceManagement.svc
Typically to start a service, you could envision a application which takes a service URI, calculates the SMS URI, and pings the application.
6) Autostart WCF/WF Services
One issue when hosting services in IIS is the “first message latency” message delay or the the requirement to “Warm-up” the application, in advance of the first message.
Autostart is a feature introduced in Windows 7 and Windows Server 2008 R2 which allows you to achieve this. It provides “Warm-up” and the “Always Running” semantics. Additionally, It removes the need to write a WAS host aware transports, otherwise known as Listener Adapters.
You should use this feature for primarily two reasons
a. Reduce the latency incurred by the first message.
b. Hosting WCF transports/protocols for which there are no Listener Adapters. The trade-off is site density
This feature is supported only on the Win7 and Win2008 R2 platform.
How-To:
Windows Server AppFabric provides configuration support in IIS Manager to Autostart the application.
1. Navigate to the Application
2. Click on Configure in Actions pane
3. Configure the Application to either by choosing
a. Enabled which will autostart all the services
or
b. Custom option, which will autostart only the specific services.
To Autostart an individual service, you will need to navigate the configuration panel for that specific service.
To summarize, we made hosting investments , in both the framework and Windows Server AppFabric, primarily focusing on the following aspects
1) Easier WCF service configuration and management
2) Enable activation and execution of Worflow in WAS
3) Enhance the existing “application environment” capabilities in WAS by providing additional semantics like “Always Running” and “Scheduled Start” for web services.