Wenlong Dong's Blog : WCF WebHost

WCF Request Throttling and Server Scalability

wdong — Mon, 21 Apr 2008 10:09:00 GMT

Two Threads per Request

In .NET 3.0 and 3.5, there is a special behavior that you would observe for IIS-hosted WCF services. Whenever a request comes in, the system would use two threads to process the request:

· One thread is the CLR ThreadPool thread which is the worker thread that comes from ASP.NET.

· Another thread is an I/O thread that is managed by the WCF IOThreadScheduler (actually created by ThreadPool.UnsafeQueueNativeOverlapped).

When you have a high latency request, you would see the following callstack in the debugger before the request is completed (with .NET 3.5):

0ee6ee8c 5094dad5 mscorlib_ni!System.Threading.WaitHandle.WaitOne()+0xa

0ee6ee8c 50951e3b System_ServiceModel_ni!System.ServiceModel.Activation.HostedHttpRequestAsyncResult.ExecuteSynchronous(System.Web.HttpApplication, Boolean)+0x8d

0ee6eeb4 65fe626d System_ServiceModel_ni!System.ServiceModel.Activation.HttpModule.ProcessRequest(System.Object, System.EventArgs)+0x143

0214e4f4 65fe3fd1 System_Web_ni!System.Web.HttpApplication+SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()+0x5d

0ee6ef08 65fe804f System_Web_ni!System.Web.HttpApplication.ExecuteStep(IExecutionStep, Boolean ByRef)+0x41

0ee6efb8 65fe4df2 System_Web_ni!System.Web.HttpApplication+PipelineStepManager.ResumeSteps(System.Exception)+0x63b

060f05dc 66003a92 System_Web_ni!System.Web.HttpApplication.BeginProcessRequestNotification(System.Web.HttpContext, System.AsyncCallback)+0x56

0ee6f040 65fd8022 System_Web_ni!System.Web.HttpRuntime.ProcessRequestNotificationPrivate(System.Web.Hosting.IIS7WorkerRequest, System.Web.HttpContext)+0x352

0ee6f0c4 65fd7e07 System_Web_ni!System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr, IntPtr, IntPtr, Int32)+0x1f2

0ee6f0f4 01782374 System_Web_ni!System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr, IntPtr, IntPtr, Int32)+0x1b

0ee6f138 6a2abf3c webengine!MgdGetCurrentNotification+0x236

0ee6f19c 74a22ea0 webengine!MgdGetPreloadedSize+0x4d

0ee6f1b0 74a23696 iiscore+0x2ea0

0ee6f560 6a2ac222 webengine!MgdCanDisposeManagedContext+0xb5

0ee6f570 015f1311 webengine!MgdIndicateCompletion+0x22

System_Web_ni!System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr, IntPtr, IntPtr, Int32)+0x289

This is the worker thread that comes from ASP.NET. Another thread is still processing the request in WCF:

01fbf0ac 0e9001c7 App_Web_rsfhd6l1!HelloWorld.SimpleService.Hello(System.String)+0x14

01fbf0ac 50b8d90b System_ServiceModel_ni!DynamicClass.SyncInvokeHello(System.Object, System.Object[], System.Object[])+0x3f

01fbf0ac 50b6d245 System_ServiceModel_ni!System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(System.Object, System.Object[], System.Object[] ByRef)+0x1fb

01fbf108 509137ad System_ServiceModel_ni!System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(System.ServiceModel.Dispatcher.MessageRpc ByRef)+0xd5

01fbf148 509136a6 System_ServiceModel_ni!System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(System.ServiceModel.Dispatcher.MessageRpc ByRef)+0xad

01fbf174 50913613 System_ServiceModel_ni!System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(System.ServiceModel.Dispatcher.MessageRpc ByRef)+0x76

062b75a8 50913459 System_ServiceModel_ni!System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage3(System.ServiceModel.Dispatcher.MessageRpc ByRef)+0x33

062b75a8 50912257 System_ServiceModel_ni!System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage2(System.ServiceModel.Dispatcher.MessageRpc ByRef)+0x59

062b75a8 50911f8f System_ServiceModel_ni!System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage1(System.ServiceModel.Dispatcher.MessageRpc ByRef)+0x127

01fbf1f0 509115ff System_ServiceModel_ni!System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean)+0xdf

01fbf394 5090f8c9 System_ServiceModel_ni!System.ServiceModel.Dispatcher.ChannelHandler.DispatchAndReleasePump(System.ServiceModel.Channels.RequestContext, Boolean, System.ServiceModel.OperationContext)+0x1ff

01fbf3dc 5090f35e System_ServiceModel_ni!System.ServiceModel.Dispatcher.ChannelHandler.HandleRequest(System.ServiceModel.Channels.RequestContext, System.ServiceModel.OperationContext)+0x169

01fbf42c 5090f2f1 System_ServiceModel_ni!System.ServiceModel.Dispatcher.ChannelHandler.AsyncMessagePump(System.IAsyncResult)+0x5e

01fbf42c 50232d68 System_ServiceModel_ni!System.ServiceModel.Dispatcher.ChannelHandler.OnAsyncReceiveComplete(System.IAsyncResult)+0x41

01fbf42c 50904501 SMDiagnostics_ni!System.ServiceModel.Diagnostics.Utility+AsyncThunk.UnhandledExceptionFrame(System.IAsyncResult)+0x28

01fbf468 50992b36 System_ServiceModel_ni!System.ServiceModel.AsyncResult.Complete(Boolean)+0xb1

01fbf4d8 50992215 System_ServiceModel_ni!System.ServiceModel.Channels.InputQueue`1+AsyncQueueReader[[System.__Canon, mscorlib]].Set(Item<System.__Canon>)+0x46

01fbf4d8 50991ffb System_ServiceModel_ni!System.ServiceModel.Channels.InputQueue`1[[System.__Canon, mscorlib]].EnqueueAndDispatch(Item<System.__Canon>, Boolean)+0x1f5

00000000 5091d7e5 System_ServiceModel_ni!System.ServiceModel.Channels.InputQueue`1[[System.__Canon, mscorlib]].EnqueueAndDispatch(System.__Canon, System.ServiceModel.Channels.ItemDequeuedCallback, Boolean)+0x6b

00000001 50977b7e System_ServiceModel_ni!System.ServiceModel.Channels.SingletonChannelAcceptor`3[[System.__Canon, mscorlib],[System.__Canon, mscorlib],[System.__Canon, mscorlib]].Enqueue(System.__Canon, System.ServiceModel.Channels.ItemDequeuedCallback, Boolean)+0x75

01fbf570 5094f396 System_ServiceModel_ni!System.ServiceModel.Channels.HttpChannelListener.HttpContextReceived(System.ServiceModel.Channels.HttpRequestContext, System.ServiceModel.Channels.ItemDequeuedCallback)+0x1ce

01fbf5b8 5094e4cf System_ServiceModel_ni!System.ServiceModel.Activation.HostedHttpTransportManager.HttpContextReceived(System.ServiceModel.Activation.HostedHttpRequestAsyncResult)+0xc6

0216803c 5094defd System_ServiceModel_ni!System.ServiceModel.Activation.HostedHttpRequestAsyncResult.HandleRequest()+0xdb

01fbf60c 5094dea5 System_ServiceModel_ni!System.ServiceModel.Activation.HostedHttpRequestAsyncResult.BeginRequest()+0x19

01fbf638 50903be6 System_ServiceModel_ni!System.ServiceModel.Activation.HostedHttpRequestAsyncResult.OnBeginRequest(System.Object)+0x29

01fbf674 50903b26 System_ServiceModel_ni!System.ServiceModel.Channels.IOThreadScheduler+CriticalHelper+WorkItem.Invoke2()+0x36

01fbf688 50903ab5 System_ServiceModel_ni!System.ServiceModel.Channels.IOThreadScheduler+CriticalHelper+WorkItem.Invoke()+0x4a

01fbf6bc 5090390f System_ServiceModel_ni!System.ServiceModel.Channels.IOThreadScheduler+CriticalHelper.ProcessCallbacks()+0x185

01fbf6e8 5090388b System_ServiceModel_ni!System.ServiceModel.Channels.IOThreadScheduler+CriticalHelper.CompletionCallback(System.Object)+0x6f

01fbf720 50232e1f System_ServiceModel_ni!System.ServiceModel.Channels.IOThreadScheduler+CriticalHelper+ScheduledOverlapped.IOCallback(UInt32, UInt32, System.Threading.NativeOverlapped*)+0xf

01fbf720 79405534 SMDiagnostics_ni!System.ServiceModel.Diagnostics.Utility+IOCompletionThunk.UnhandledExceptionFrame(UInt32, UInt32, System.Threading.NativeOverlapped*)+0x2f

01fbf744 79e7c74b mscorlib_ni!System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32, UInt32, System.Threading.NativeOverlapped*)+0x60

01fbf758 79e7c6cc mscorwks!LogHelp_TerminateOnAssert+0x3433

01fbf7d8 79f00eca mscorwks!LogHelp_TerminateOnAssert+0x33b4

01fbf7f8 79f00e75 mscorwks!GetCLRFunction+0x1de16

Why is this? Is this a scalability issue for WCF? I will explain this below.

Asynchronous Request Processing

One of the most significant pieces for WCF is that it is highly asynchronous from bottom to top for the whole channel stack and the programming model. The advantage is apparent: applications have high flexibility by issuing operations asynchronously, doing some other stuff in parallel, and coming back to handle the completed operations once they are completed. This is also scalable when the asynchronous operations are I/O bound so that you do not need to hold extra threads to wait for operation completions.

ASP.NET also supports asynchronous request processing mechanisms through IHttpModule and IHttpAsyncHandler. With these interfaces, ASP.NET can push many concurrent requests up to the layers which have such asynchronous implementations. In this way, the whole stack need a small number of threads to process a large number of concurrent requests given appropriate queuing for the requests.

However, this also exposes a memory problem when this is on IIS 6.0. When there is unlimited number of incoming requests, all of the requests would be pushed up by ASP.NET to upper layers and it would cause significant memory consumption. Thus it would cause the server to be unavailable to do its work correctly.

So in the release of .Net 3.0 and 3.5, WCF implemented synchronous versions of HTTP module and handler instead of asynchronous ones. See the following for more details.

ASP.NET Threading on IIS 6.0

When ASP.NET is hosted in IIS 6.0, requests are handed over to ASP.NET on IIS I/O threads. ASP.NET uses CLR ThreadPool worker threads to handle requests. The CLR ThreadPool automatically adjusts the number of threads based on the server workload. In order to prevent from using too many threads or using too much memory, ASP.NET has a limit on the number of threads concurrently executing requests. This is controlled by the httpRuntime/minFreeThreads and httpRuntime/minLocalRequestFreeThreads settings. If the limit is exceeded, the request is queued in the application-level queue, and executed later when the concurrency falls back down below the limit. Thomas Marquardt has written an excellent blog on this:

http://blogs.msdn.com/tmarq/archive/2007/07/21/asp-net-thread-usage-on-iis-7-0-and-6-0.aspx (TM0707)

In .NET 2.0, the magic config “processModel/autoConfig” in machine.config automatically configures the ASP.NET threading settings for most applications. For those which require special settings need to be configured differently. The following KB article was provided as the general guidance:

http://support.microsoft.com/kb/821268 (KB821268)

However, there is no throttling for concurrent requests in ASP.NET on IIS 6.0.

WCF Request Throttling and Tuning

Because of lacking the throttling for concurrent requests in ASP.NET, WCF would get unlimited concurrent requests pushed up from ASP.NET if WCF had implemented asynchronous HTTP module/handler on IIS 6.0. It would cause severe memory usage problem. Because of this concern, WCF implemented the synchronous HTTP module/handler in 3.0 and 3.5 instead.

Here I only describe how the HTTP module works for WCF. The logic for the HTTP handler is similar. When a request comes in from ASP.NET, WCF grabs the request if it is a WCF request (by checking the registered BuildProvider of the extension to see whether it is WCF service BuildProvider). After that, it immediately switches to a new I/O thread and hold the ASP.NET worker thread until the request is completed. You may ask, why doesn’t WCF reuse the ASP.NET worker thread to handle the request until it is completed? Here are the reasons:

· As long as the ASP.NET worker thread is not returned back to ASP.NET, the request is not able to be completed. The client would be blocked.

· When the WCF operation is one-way, the request has to be completed before the service operation is invoked. So the ASP.NET worker thread has to return earlier.

· WCF supports people to complete a two-way operation earlier in a service operation when you call RequestContext.Close.

All of these require that WCF should not hold the ASP.NET worker thread once the request is claimed to be “completed”. At the same time, WCF has to hold the ASP.NET worker thread in a waited state before the request is completed due to the requirement of synchronous request processing logic. WCF relies on this ASP.NET thread throttling logic to limit concurrent requests.

Intuitively this seems to have scalability issue. Fortunately for most WCF services, especially high-throughput ones, this has quite low impact as long as the server is busy processing requests. This is demonstrated as the CPU usage of the server.

On multi-proc/multi-core servers, the default limit of concurrent requests may not be enough for the server to achieve best throughput. This would require larger limits for ASP.NET worker threads to be used to handle requests.

Throttling Tuning

In order to achieve high throughput on high-end servers, you would need to make the following throttling tuning:

· Increase ASP.NET thread throttling to allow more concurrent worker threads to handle requests

· Increase WCF service throttling to allow more concurrent requests

The latter reflects the change of the known WCF throttling settings such as MaxConcurrentCalls, MaxConcurrentInstances, and MaxConcurrentSessions. The former would require fine tuning of ASP.NET thread throttling as documented in the KB article KB821268 mentioned above. Basically ASP.NET does not execute more than the following number of concurrent requests:

(maxWorkerThreads*number of CPUs)-minFreeThreads

This is 12 by default on a single CPU machine. In order to get more threads to process requests, you need to increase maxWorkerThreads. Once you can get CPU fully loaded with the settings, setting “minWorkerThreads” to 2 or 3 would allow WCF to have best throughput. Here is sample setting in machine.config:

The above settings work for most WCF applications. However, when the service has very slow operations which are I/O bound (for example, they further connects to backend database or network or file system to perform high-latency operations), you would need to use many outstanding ASP.NET worker threads to achieve parallel requests. This is bad when the number of requests is huge, for example, several thousands or more. Each thread would hold a fair amount of system resource, i.e., memory. It would cause the service to be very slow to respond. This really requires a real asynchronous design to solve the problem. Because of this, ASP.NET introduced a new throttling logic for concurrent requests in IIS 7.0 to support this scenario for WCF.

ASP.NET Throttling on IIS 7.0 in Integrated Mode

As Thomas mentioned in his blog entry (TM0707) mentioned above, the following registry value is introduced to throttle concurrent requests:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0]

“MaxConcurrentRequestsPerCpu”=dword:0000000c

The default value is 12 per CPU which means is similar as the default setting for ASP.NET worker threads. This was introduced in ASP.NET 2.0 SP1 (shipped with .NET 3.5) and thus it is available in Windows 2008. It only applies to the IIS 7.0 Integrated mode, which is exactly where WCF is registered on Windows 2008.

Scalable Solutions for High Latency Services

Though the above throttling support was added to Windows 2008, WCF still uses synchronous module/handler instead of asynchronous ones in the released versions due to timing constraint. However, the internal WCF design does allow asynchronous request processing and it is just one step away from the real asynchronous logic. Here I provide a simple wrapper for that.

Custom HttpModule Using Reflection

The internal WCF types support asynchronous HTTP module. Since they are internal, we have to rely on reflection to create a real one.

First of all, you would need to register the async events for your HttpModule as following:

context.AddOnPostAuthenticateRequestAsync(

MyHttpModule.beginEventHandler,

MyHttpModule.endEventHandler);

This is registered to the PostAuthenticateRequest for the same reasons as the default WCF HttpModule.

Secondly, you would need to use reflection to create the instance of the internal WCF type System.ServiceModel.Activation.HostedHttpRequestAsyncResult:

Type hostedHttpRequestAsyncResultType = typeof(ServiceHostingEnvironment).Assembly.GetType("System.ServiceModel.Activation.HostedHttpRequestAsyncResult");

ConstructorInfo hostedHttpRequestAsyncResult = hostedHttpRequestAsyncResultType.GetConstructor(BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.Public,

null, new Type[] { typeof(HttpApplication), typeof(bool), typeof(AsyncCallback), typeof(object) }, null);

return (IAsyncResult)hostedHttpRequestAsyncResult.Invoke(new object[] { application, false, cb, extraData });

Once you have the custom HttpModule, you can replace it with the default one that is registered in the WAS configuration %windir%\system32\inetsrv\config\applicationhost.config:

<system.webServer>

<system.webServer>

To do that, you can also define local settings in web.config:

<system.webServer>

</modules>

</system.webServer>

The sample code is attached.

Improvement in .NET 3.5 SP1

In .NET 3.5 SP1, we will provide the real asynchronous HTTP module/handler for WCF to better solve this problem.

How to redirect a Url in IIS6/IIS7 and in ASP.NET?

wdong — Tue, 18 Sep 2007 09:29:00 GMT

Sometimes you want to redirect users request to a different one when you want to retire old ones but still provide backward-compatibility. David Wang has a good summary on different redirects for IIS in his blog entry. Here I just want to add a few points which have helped people to resolve tricky problems.

First of all, as David pointed out, there are two (or three in David’s terms) types of redirects:

· Client-side redirection: the server sends a “302 Redirect” response to the client together with the new location header.

· Server-side redirection: the server rewrites the request with another URL transparently and the client is not aware of anything.

Client-side redirection

It is also called HTTP redirection. You can achieve it in the following ways.

Redirect in IIS6

You can use the HttpRedirect Metabase setting to perform redirection in IIS6. This property can be set to a virtual application, a file, or a virtual directory (a.k.a. web folder). It requires the physical existence of these “source” items. To achieve that, you can use IIS Manager. Here are the steps on how to set it for a file:

· Right click on the file and click on Properties

· Click on “File” tab of the dialog

· Select “A redirection to a URL” radio box

· Type in your new Url, and/or make any other changes, and click OK.

After this, you would have setup the file so that all requests to this file is redirected to the new Url. You can check the Metabase setting with the following command:

cscript.exe %SystemDrive%\Inetpub\AdminScripts\adsutil.vbs get /w3svc/1/Root/foo/p1.aspx/HttpRedirect

If the file does not have any Metabase property pre-defined in the Metabase, you cannot use adsutil.vbs to set this property. But you can set it with the script to a virtual application.

Redirect in IIS7

In IIS7, the concept is similar as that of IIS6. You can use the new command “appcmd.exe” to enable redirection as following:

%windir%\system32\inetsrv\appcmd set config "Default Web Site/foo" -section:system.webServer/httpRedirect -enabled:true -destination:"http://localhost/bar/p1.aspx"

This tells IIS to redirect all request sending to the virtual application “/foo” to “/bar/p1.aspx”. The actual result is that appcmd.exe adds the following section to the web.config file for the application “/foo”:

<system.webServer>

</system.webServer>

Redirect with ASP.NET

You can also use ASP.NET to implement client-side redirection. If you don’t want ASP.NET pipeline to intercept any such request, you would need to implement the logic in the global.asax file. This is important for WCF applications since WCF intercepts requests from the pipeline for WCF requests. Here is some sample code for a global.asax file:

<%@ Application Language="C#" Debug="true" %>

// This is the application file that handles ASP.NET application-level

// events. It works for ASP.NET HTTP pipeline. Note that this mechanism

// does not work for non-HTTP case.

void Application_BeginRequest(object sender, EventArgs e)

{

if (string.Compare(this.Request.Url.AbsolutePath, "/foo/p1.aspx", StringComparison.OrdinalIgnoreCase) == 0)

{

this.Response.Redirect("/foo/p2.aspx", true);

}

</script>

This approach is more flexible than those provided by IIS:

· It does not require the existence of the physical file.

· It is imperative and thus you can add any custom programming logic to determine whether you want to redirect the request. For example, you can check the query string to see whether it contains the information that requires a redirection.

Server-side redirection

It is sometimes also called Url rewriting or Url aliasing. One of the advantages for server-side redirection is performance because there is no round-trip involved if the redirection is on the same machine.

Redirect with ASP.NET

You can use ASP.NET to implement the server-side redirection with Server.Transfer(path) method.

How to use .asmx extension to handle WCF requests?

wdong — Tue, 18 Sep 2007 04:45:00 GMT

For backward compatibility, WCF supports easy server-side migration from ASMX to WCF. This is good news for existing ASMX customers. Generally, the clients of ASMX may have server Urls hard-coded with the extension “.asmx”. For example, here is a sample Url:

http://www.myserver.com/foo/MyService.asmx

After installing WCF on the box, you can let WCF to handle the same client requests. Here are the steps about how to achieve this:

Replace BuildProvider for ASMX

You need to use the WCF service build provider for .asmx extension by seting the following in the web.config file of your virtual application:

<system.web>

</buildProviders>

</compilation>

</system.web>

When WCF is running in the Mixed Transport mode (instead of AspNetCompatibility mode), WCF would intercept the request based on the BuildProvider information for the extension.

Replace HttpHandler for ASMX

If you are running WCF in AspNetCompatibility mode, you would also need to change the HttpHandler s for .asmx to the WCF HttpHandler. On IIS6, you just need to have something as following in your config:

<system.web>

<add path="*.asmx" verb="*" type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

validate="false" />

</httpHandlers>

</system.web>

On IIS7, things are different. IIS7 introduces two different HTTP pipelines: Integrated and Classic. The latter works similar as IIS6 in the way that all of the managed requests go through the ASP.NET ISAPI filter. When this happens, the HttpModules and HttpHandlers defined in web.config files would be invoked for the corresponding requests.

When the virtual application is running in the Integrated mode, however, the modules and handlers defined in web.config files under the <system.web> section are totally ignored. All of the requests are handled straightforward by IIS7. So you need to make sure that you have integrated handlers defined for the corresponding extensions. We can set the following in the web.config of the virtual application to achieve this:

<system.webServer>

</handlers>

</system.webServer>

The section <system.webServer> is actually rooted in %windir%\system32\inetsrv\config\applicationhost.config instead of in the root web.config in %windir%\Microsoft.Net\Framework{64}\v2.0.50727\config. The <remove> element takes the “name” as the key instead of the “path” as we did to the <system.web> section. You must specify “validateIntegratedModeConfiguration” to false to make IIS happy.

Correct SOAP Actions

Once you configured above settings, you can create a .asmx file which looks exactly as a .svc file. For example, you can have the following content:

<% @ServiceHost language = "c#" Factory="HelloWorld.SimpleServiceHostFactory" %>

Now you can browse your service with an .asmx extension. At this point, all requests will go through happily into WCF channel stack.

One last thing that you need to be aware is that you need to make sure your WCF service is backward compatible to ASMX so that ASMX clients can communicate with it. Basically you need to use the interoperable binding such as BasicHttpBinding. And you need to make sure the request/response SOAP actions are expected for ASMX clients. Here is an example:

[ServiceContract(Name = "RequestReplyService", Namespace = "http://myoldasmxworld.org/")]

public interface IRequestReplySyncServiceAsmx

{

[OperationContract(IsOneWay = false, Action = "http://myoldasmxworld.org/HelloRequestReply")]

string HelloRequestReply(string text);

}

It is compatible to the following ASMX web service:

[WebService(Name = "MyAsmxService", Namespace = "http://myoldasmxworld.org/")]

public class AsmxRequestReplyService

{

[WebMethod]

public string HelloRequestReply(string text)

{

// Implementation

}

How to change HostName in WSDL for an IIS-hosted service?

wdong — Thu, 02 Aug 2007 03:47:00 GMT

If you have a web-hosted service “simple.svc” under the virtual application “/simple”, you would probably get the following service address in the WSDL:

<wsdl:service name="SimpleService">

<wsdl:port name="BasicHttpBinding_ISimpleContract" binding="tns:BasicHttpBinding_ISimpleContract">

<soap:address location="http://mycomputer.private.mydomain.com/simple/Simple.svc" />

</wsdl:port>

</wsdl:service>

The host name “mycomputer.private.mydomain.com” is automatically picked up by WCF. In the real production environment, you would want to use a public host name or even an IP address in the address. Here are a few steps that can help you to make the change:

1) Change IIS Site Binding

WCF populates service base addresses based on IIS site bindings. The format of a site binding looks like “<ip>:<port>:<hostname>”. For HTTP, the default site binding for the default web site is “:80:”. This means that the service can receive messages from any IP addresses for the host and it uses “weak” wildcard for address registration. You need to change it to be an “exact” host name for the site so that it shows up in your service base address. You can use the IIS utility tool adsutil.vbs (or appcmd.exe on IIS7) to achieve that.

You can query your current site bindings for the default web site as following:

cscript //nologo %systemdrive%\inetpub\adminscripts\adsutil.vbs get W3SVC/1/ServerBindings

Here is the command to change it:

cscript //nologo %systemdrive%\inetpub\adminscripts\adsutil.vbs set W3SVC/1/ServerBindings “:80:www.fancydomain.com”

You can also change it from IIS Manager UI. For HTTPS, the following command would work:

cscript //nologo %systemdrive%\inetpub\adminscripts\adsutil.vbs set W3SVC/1/SecureBindings “:443:www.fancydomain.com”

2) Recycle the AppDomain

Once you changed IIS settings, WCF does not automatically pick up the changes from IIS Metabase. You have to recycle the current AppDomain for the virtual application. There are a few different ways to do that:

· Change web.config file for the virtual application

· Kill w3wp.exe process

· Run “iisreset.exe”

3) Query the WSDL

Now when you query the WSDL of your service, you will see the new addresses:

<wsdl:service name="SimpleService">

<wsdl:port name="BasicHttpBinding_ISimpleContract" binding="tns:BasicHttpBinding_ISimpleContract">

<soap:address location="http://www.fancydomain.com /simple/Simple.svc" />

</wsdl:port>

</wsdl:service>

Impersonation with Double Identities

wdong — Fri, 01 Dec 2006 04:58:00 GMT

There are two different levels of security that you can use for WCF services: Message level and Transport level. For Transport level, in HTTP case, you can use different IIS Authentication mechanisms to perform client authentication. If you do not carefully set the settings of the WCF binding, you may end up with both security levels enabled. This has a direct impact of impersonation. The reason is because WCF does not know which identity you want to apply to impersonation.

Generally, it is not recommended to have double securities enabled. However, there is actually a reason why people could get into this dilemma:

It is normal for people to disable anonymous access in IIS. In WCF, we want to make sure that a service explicitly specifies its transport level security settings. In this case, it means that you have to configure the service to not use anonymous authentication at transport layer. So when you also want to enable message-level security to perform message signing or encryption, you would get into this double-identity situation.

Here is a simple custom binding configuration that demonstrates how it is the case of double identities:

</binding>

</customBinding>

It enables both message-level security and it also enables the NTLM authentication at the transport layer.

In this case, if you have an operation which requires impersonation, you would get the following error on the server side (you can see it from a debugger):

System.InvalidOperationException: Cannot start impersonation because the SecurityContext for the UltimateReceiver role from the request message with the 'http://www.microsoft.com/test/IHelloContract/Hello' action is not mapped to a Windows identity.

This is because WCF actually set the ServiceSecurityContext to WindowsIdentity.Anonymous when multiple identifies are found.

There are three different ways to resolve this issue.

1. Enable Anonymous Access from IIS

This is the simplest way, though there is a security concern for this approach. Here is the binding configuration that does not have the transport-layer authentication enabled:

</binding>

</customBinding>

You have to enable the anonymous access in IIS to make this work, otherwise you would get ServiceActivationException on the server side due to mismatched settings between WCF binding and IIS.

This is not the ideal solution if you have other services in the same application that you want to have anonymous access disabled for security purpose.

2. Use Imperative Impersonation

When I said impersonation would fail above, I meant declarative (or automatic) impersonation. Here is the sample service operation that does this:

[OperationBehavior(Impersonation = ImpersonationOption.Required)]

public string Hello(string greeting)

To use imperative impersonation, you need to remove the “Impersonation” setting from the above declaration and perform impersonation from code. This requires having a Windows identity being retrieved from the context. Fortunately WCF provides a way for you to find the identities that are available in the stack:

OperationContext.Current.ServiceSecurityContext.AuthorizationContext.Properties["Identities"]

You can cast this into List<IIdentity> and examine each identity of them. You cannot tell which identity is from which layer though. However, in WCF V1, the identity from the transport layer is always the first one. But this is guaranteed in future versions.

Once you have the Windows identity, you can perform the impersonation by yourself:

using (identity.Impersonate())

{

// Do something

}

3. Remove Unnecessary Identities Using Custom Authorization Policy

If you are still not satisfied by the above approaches, here is another choice for you. You need to use the ServiceAuthorizationBehavior.ExternalAuthorizationPolicies extension point to add an extra authorization policy to remove identities which are not needed. Here is a good sample about how to implement a custom authorization policy: http://msdn2.microsoft.com/en-gb/library/aa702720.aspx.

In our case, we can implement the Evaluate() method of the custom MyAuthorizationPolicy as following so that the last identity is picked:

public bool Evaluate(EvaluationContext evaluationContext, ref object state)

{

IList<IIdentity> identities = evaluationContext.Properties["Identities"] as IList<IIdentity>;

if (identities != null && identities.Count > 1)

{

// Pick the last one (which is likely to be the identity embeded in the message.

evaluationContext.Properties["Identities"] =

new List<IIdentity>(new IIdentity[] { identities[identities.Count - 1] });

}

return true;

}

Now you can configure the Authorization behavior in your ServiceHost. You need to implement ServiceHostFactory so that this custom behavior can be added to the ServiceHost. Here is an implementation of the CreateServiceHost method:

public override ServiceHostBase CreateServiceHost(string constructorString, Uri[] baseAddresses)

{

ServiceHost serviceHost = new ServiceHost(typeof(HelloService), baseAddresses);

serviceHost.Authorization.ExternalAuthorizationPolicies = new ReadOnlyCollection<IAuthorizationPolicy>(

new IAuthorizationPolicy[] {

new MyAuthorizationPolicy()

});

return serviceHost;

}

The sample code for this blog entry is attached.

Virtual Application vs Virtual Directory

wdong — Thu, 23 Nov 2006 00:48:00 GMT

People are always confused by these two IIS concepts, especially for the new IIS7/WAS. These are not new concepts. They are available since IIS6 on Windows 2003 Server. However the terms were misused in IIS6 and they are corrected in IIS7 in Windows Vista and higher versions of Windows.

Virtual Application

What is it?

The term “virtual application” is a fundamental concept for IIS and ASP.NET. Here is the definition in my own words: a virtual application is a construction unit of a web site that participates protocol listening and process management. It can be uniquely identified by its absolute virtual path from that web site. For example, you can create a virtual application with virtual path “/foo” in the “Default Web Site”. For simplicity, we also call virtual application as "Default Web Site/foo" or simply “/foo”. Every web site has at least one virtual application, a.k.a, the root virtual application “/”.

A web site can be uniquely identified by its site ID. All of the web sites are under the same root “/W3SVC”. So each web site can be represented in the format of “/W3SVC/<SiteID>”. For example, the “Default Web Site” can be represented as “/W3SVC/1”. With this, we can uniquely identify a virtual application with its full path, for example,

/W3SVC/1/Root/foo

If you have the IIS6 scripting tool “adsutil.vbs” installed, you would be able to check the settings of the virtual application with the following command:

cscript %systemdrive%\inetpub\adminscripts\adsutil.vbs enum /W3SVC/1/Root/foo

Protocol Listening

When you create a virtual application, you would expect your new virtual application to receive requests that are dedicated to it. There are two aspects of “protocol listening”:

For a particular protocol (for example HTTP), a web site is nothing but a list of virtual applications. This means that the protocol activation service (which is IIS or W3SVC in the HTTP case) registers a list of Urls in the protocol listener service (which is HTTP.sys driver for HTTP). Each of this Url is associated with a virtual application.
You can specify which protocol is enabled for a virtual application. In IIS6, you can specify HTTP or HTTPS. In IIS7, however, you can specify any protocol(s) through the “enabledProtocols” property of the virtual application. For example, you can specify protocols “net.tcp”, “net.pipe”, “net.msmq”, or “msmq.formatname” that are implemented by WCF.

Application Pool

The other aspect of a virtual application is that it also participates in process management. IIS/WAS has the concept of application pools. An application pool is a definition or template of a worker process (w3wp.exe) that is used by IIS/WAS to create new worker process instances. Two most important properties of an application pool are:

It has an identity which is the running account of the worker process in this pool. You can configure the identity to a specific account so that you can achieve security isolation from other pools.
It has a list of settings to control the health of worker processes running in this pool. For example, you can set process recycling and idle timeout, enable debugging, configure Web Gardens, or enable Rapid-Fail Protection (RFP), etc. For IIS6, more information can be found at http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/c9b5db6f-874e-4ec9-93ed-1733367c117b.mspx?mfr=true.

Each virtual application must be assigned to an application pool in IIS. All of the requests (except for static content) will be handled in worker processes in that application pool.

Please note that Application Pool is managed by WAS instead of IIS in the IIS7 family. This separation makes non-HTTP activation possible. With this refactoring, “IIS” is simply the web server that only handles HTTP/HTTPS requests.

ASP.NET Application

For ASP.NET, a virtual application has its real meaning as an “application”. When an ASP.NET request is first received in a virtual application, a new AppDomain is created in the worker process that handles subsequent ASP.NET requests. This includes all WCF requests. So in the ASP.NET world, a virtual application is mapped to an AppDomain. This provides important code isolation for managed applications that sits in the same worker process. It is even more important for web hosting when the applications are running in the partial trust environment.

Virtual Directory

Isn’t “virtual directory” the same as “virtual application”? In IIS6, from the IIS Manager (UI), if you right click on “Default Web Site” -> New, you will see “Virtual Directory …” from the list. What is going on there? Well, as I said, the terms are misused in IIS6. When it says “Virtual Directory”, it actually means “Virtual Application”.

Am I kidding? No. A real “virtual directory” is just a container of files. It is a construction unit of a virtual application, just like a virtual application to a web site. A virtual application must have at least one virtual directory. Here is a sample configuration section that defines the virtual application “/foo” and its virtual directories in the WAS' configuration file %windir%\system32\inetsrv\config\applicationhost.config:

<sites>

</application>

...

</site>

</sites>

Note that the virtual directory “/bar” points to a different physical path, actually it points to a network share (UNC) path!

How can we create a real virtual directory in IIS6 then? It is a little bit trickier from the UI. In the IIS Manager UI, you can right click on the virtual application and then click on New -> “Virtual Directory …”. After specifying the alias and path, you will get the virtual directory using all default settings.

However, there is another trick to convert a virtual application into a virtual directory. Here are the steps:

Create a virtual application “/foo” and a sub virtual application “/foo/bar”.
Right click on the virtual application “/foo/bar” and select properties. You will see the properties dialog popped up.
Under the “Virtual Directory” tab, look for the “Remove” button. See the image below:

Click the “Remove” button and click on “OK” button.

Now you have created a virtual directory “/bar” under the virtual application “/foo”. The icon for the virtual application is different than that of the virtual application. Here is what you will see:

Nesting

Virtual applications and virtual directories can be nested, meaning, a virtual application or directory can be created under another virtual application or directory in any combinations.

This nesting has the following implications:

The virtual path of the parent application/directory is the prefix of the child application/directory.
For ASP.NET, the web.config of the parent virtual application/directory affects the child application/directory.
For ASP.NET, the assemblies referenced by the parent virtual application are inherited by the children.

Other than those, virtual applications still have their own isolation that I mentioned in the above sections.

IIS7/WAS Installation

wdong — Wed, 22 Nov 2006 21:34:00 GMT

IIS7 has a modular design which allows you to selectively install components that are needed. This design is based on the new manifest-driven Componentization technology that was first introduced in Windows Vista. As the IIS site claimed, there are more than 40 standalone feature components of IIS7 which can be independently installed. This is good or bad. The good part is that IT professionals can easily customize the installation as needed. The bad part is that it’s hard for developers to understand which components are needed. Here I would like to write something regarding the latter.

If you are familiar with CMI (Component Management Interface) or CBS (Component Based Setup), you would know that there are many different ways to install components on Vista. You can use the GUI interface (called Software Explorer) which is available from “Control Panel” -> Programs -> “Turn Windows features on or off”. Or you can use command-line tools such as pkgmgr.exe or ocsetup.exe (which is a wrapper of pkgmgr.exe). I will talk about the simplest approach, GUI interface, below.

Minimal Installation: Installing WAS

The minimal installation of the whole IIS7 package is to install the Windows Process Activation Service (WAS). WAS is a standalone feature and it is the only feature from the IIS7 family that is available for all Windows Vista client SKUs (Basic, Home, Business, and Ultimate, etc).

From the “Turn Windows features on or off” UI of the control panel, you will see the WAS component listed in the list as in the following image:

This feature has three sub-components:

.NET Environment
Configuration APIs
Process Model

If you select the root node of WAS, only the “Process Model” sub-node is checked to be installed by default with the root. Please note that with this installation, you still cannot do anything interesting today. It only means that you can get WAS to work.

If you further check the “Internet Information Services” feature from the feature list, you will find out that the “Configuration APIs’ node is automatically checked.

In order to make WCF or any ASP.NET application to work, you need to further check the sub-node “.NET Environment”. This means that all of WAS components are needed in order to make WCF/ASP.NET to work well. Fortunately these are automatically checked once you install any of those components.

IIS7: Default Installation

By simply checking the “Internet Information Services” feature from the UI, you will see that quite some sub-nodes are automatically marked as following:

This is the default installation of IIS7. In this way, you can use IIS7 to service static content (such as HTML pages etc). However, you can’t run ASP.NET or CGI applications.

IIS7: Installlation with ASP.NET support

From the above image, it’s obvious that you need to install “ASP.NET” to make ASP.NET work on IIS7. After checking “ASP.NET”, you will find the following UI:

This is the minimal environment for both WCF and ASP.NET applications to work in IIS7.

Installation with IIS6 Compatibility Components

Many people still have problems with the above installation when they run Visual Studio 2005 or some automation scripts/tools (for example, adsutil.vbs) to configure virtual applications. The main reason is because those tools depend on the legacy IIS6 Metabase API support as well as the legacy IIS6 scripting tools. Here is the UI that shows what are missing from above:

You need to check “IIS 6 Scripting Tools” (which automatically checks other three subnodes of “IIS 6 Management Compatibility”). After that, you will see the following UI:

With this installation, you are good to play with IIS7, ASP.NET, and WCF features and samples available on the web.

Maximum Installation

You may want to play with other components that are not installed by default. To install them, you can simply go through the whole tree of the IIS and check every leaf node. In this way, you will get the full IIS7 feature set installed.

What is IIS7?

wdong — Wed, 22 Nov 2006 20:26:00 GMT

What is IIS7? What is the difference between IIS6 and IIS7? Here are the simple answers:

§ IIS7 is a new revision (version 7.0) of the Internet Information Services that is shipped on Windows Vista and the next Windows Server version.

§ The most attractive features of IIS7 are: modular design (thanks to the new Windows componentization technology first introduced in Windows Vista), extensible architecture (with public web server APIs), and unified distributed configuration system.

§ Another big change to IIS7 is that it first introduced a new NT service “Windows Process Activation Service” (WAS). WAS manages application pool configuration and worker processes. This enables process activation through both HTTP and non-HTTP transports.

More details about IIS7 can be found in the IIS7 public web site: http://www.iis.net/.

When people asked me how to host WCF services on IIS7? I would always say: it is the same as on IIS6. Well, this is generally correct. People still kept on hitting unique problems on IIS7. I will expand this in more details in my future blog entries.

.NET Framework 3.0 and SDK are shipped

wdong — Wed, 08 Nov 2006 05:01:00 GMT

Finally, we made it! .NET Framework 3.0 (was called "WinFX") is shipped today. Here is the download link: http://www.microsoft.com/downloads/details.aspx?FamilyId=10CC340B-F857-4A14-83F5-25634C3BF043&displaylang=en.

Here is the SDK download link: http://www.microsoft.com/downloads/details.aspx?FamilyId=C2B1E300-F358-4523-B479-F53D234CDCCF&displaylang=en.

How to use WSDualHttpBinding on Windows XP for Hosted Services

wdong — Thu, 19 Oct 2006 22:01:00 GMT

On Windows XP, Internet Information Service (IIS) does not use HTTP.sys which is the HTTP driver that can be used to share HTTP traffic on the same port by multiple applications. This means that when IIS is running, the default port 80 is taken by IIS and no other applications can use it.

So if you use WSDualHttpBinding for your service, the client won’t be able to open the listener against the default port 80 on the same machine and it would fail with AddressAlreadyInUseException.

To workaround this, you need to change the ClientBaseAddress of WSDualHttpBinding on the client side so that it uses a different port than the one that IIS is using. From client config, you can do the following:

<system.serviceModel>

<endpoint name="WSDualOnXP"

address="http://localhost/WSDualOnXP/HelloWorld.svc"

binding="wsDualHttpBinding"

bindingConfiguration="WSDualOnXP"

contract="HelloWorldClient.IHelloContract" />

</client>

</wsDualHttpBinding>

</bindings>

</system.serviceModel>

From code, you can also set the ClientBaseAddress:

WSDualHttpBinding binding = new WSDualHttpBinding();

binding.ClientBaseAddress = "http://localhost:808/WSDualOnXP/";

On the server side, you don’t have to specify the ClientBaseAddress since the addressing correlation is automatically done by WCF infrastructure.

Cannot Find Server (404) or Get Plain Text for WCF .svc Files From IIS?

wdong — Sun, 10 Sep 2006 05:32:00 GMT

Question

After upgrading WCF (or NetFx-3.0) from an older beta version to RC1, I get “Page Not Found” (404) error or get the plain text content of the .svc file for .svc files. Is .svc extension removed from IIS?

Why?

If you installed WCF or NetFx-3.0 RC1 or later versions, you may get this problem. On Windows XP SP2, you may get the plain text of the .svc file. On Windows 2003 Server, you may get error like “Cannot find the page” (404) error. It looks like .svc extension is not supported in IIS.

Is .svc mapping removed from IIS? No. Definitely not! The reason why you saw this is because your IIS Metabase got messed up by an earlier WCF installer due to a nasty bug. You need to clean up the IIS Metabase manually so that it works again. How? Please keep on reading.

Before RC1, there was a bug in WCF installer. It accidentally populates .svc mapping to every path/node in IIS Metabase. This messed up the Metabase and has potential security concern. Fortunately, we found this issue in RC1 and fixed it. By fixing it, we only install .svc mapping to the template of the root /W3SVC of IIS Metabase. However, those machines with earlier WCF beta versions installed still have the messy ScriptMaps. They stop the inheritance of the .svc ScriptMaps from the template at the root /W3SVC. This is especially true for the “Default Web Site” and its virtual applications.

If you create a new web site with WCF RC1 installed, you won’t have this problem for that web site.

Solutions

Here are different ways that can help you to resolve the problem:

· Download tool: CleanIISScriptMaps.exe

Please find the tool “CleanIISScriptMaps.exe” in the attached zip file. The source for the tool is also included. You also find this tool and corresponding information on http://wcf.netfx3.com/files/folders/product_team/entry5648.aspx. The usage for this tool is simple, just run it without any argument from any command window. After running it, everything should just work fine. You don’t need to rerun any other setup.

If you find that .svc is still not supported for some virtual directories but you want them to be supported as well, you can run the tool with more options to explicitly remove the ScriptMaps properties from those paths. Here is the full usage of the tool:

Usage: CleanIISScriptMaps <options>

Options:

By default, the tool removes redundant ScriptMaps properties.

/f Remove ScriptMaps from all nodes in IIS Metabase except for

the root "/W3SVC".

/p Prompt for confirmation when removing ScriptMaps at a node

that is different than that of the root "/W3SVC".

/v Print out verbose information.

/? Print this help.

· Reinstall IIS or re-create web sites

You can uninstall IIS and reinstall it so that the IIS Metabase is cleaned up. Then you will need to run the WCF install tool manually as following:

"%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe" /r /y

If you are running Windows 2003 Server, you may be able to delete the “Default Web Site” and re-create it. The problem will be fixed as well.

· Install .svc manually as a temporary workaround

You can run the following command to install .svc mapping manually. However, this does not clean up the mess of the IIS Metabase. You will see the same problem again when you install newer WCF. So this is the least recommended approach comparing to the above two options:

"%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe" /s:W3SVC

Though this does not clean up the Metabase for you, it does not mess up new web sites.

WCF Impersonation for Hosted Services

wdong — Thu, 18 May 2006 07:19:00 GMT

In my blog entry “ASP.NET Compatibility Mode”, I showed how to perform impersonation with ASP.NET. WCF provides more flexible service operation level impersonation. Here is a common question that I heard:

Question:

How can I use WCF impersonation for hosted services with BasicHttpBinding?

Answer:

You can use different security modes (specified in BasicHttpSecurityMode) to achieve this:

Message
Transport
TransportCredentialOnly
TransportWithMessageCredential

Here I will just show how to use “TransportCredentialOnly” mode which needs special treatment for hosted case.

Step 1: Implement the operation

In order to enable impersonation, you need to specify the impersonation option on your service operation. Here is a simple service contract:

[ServiceContract]

interface IHelloService

{

[OperationContract]

string Hello(string text);

}

To enable impersonation for the operation “Hello”, you need to specify the Impersonation property for the OperationBehavior attribute in the operation implementation as following:

[OperationBehavior(Impersonation=ImpersonationOption.Required)]

public string Hello(string text)

{

return string.Format("Hi {0}, you said: {1}", WindowsIdentity.GetCurrent().Name, text);

}

Step 2: Create the binding

To specify the security mode to “TransportCredentialOnly”, there are different types of authentication types that we can use. The most common secure type is “Windows” which means that the underlying transport will use Kerberos (or NTLM if Kerberos is not supported) negotiation. Here is a sample configuration section:

</security>

</binding>

</basicHttpBinding>

Step 3: Configure the virtual application in IIS

Now that we have WCF service implementation and binding settings, we need to configure IIS to host the service correctly. Here are the steps:

Create a virtual application called “sample” in IIS to host your service.
Ensure to turn on “Integrated Windows authentication” for this virtual application. This will allow IIS to use Kerberos to perform authentication. Specifying a different scheme will cause WCF service activation error.

At this point, you have the hosted WCF service ready to handle requests.

Step 4: Create a client

Now we can create a simple client to connect to the above service. Here is the binding that matches the one on the service-side:

BasicHttpBinding binding = new BasicHttpBinding(BasicHttpSecurityMode.TransportCredentialOnly);

binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows;

With this binding, we can easily create a proxy to connect to the service:

ChannelFactory<IHelloService> factory = new ChannelFactory<IHelloService>(

binding, new EndpointAddress("http://localhost/sample/service.svc"));

IHelloService proxy = factory.CreateChannel();

Console.WriteLine(proxy.Hello("Hi"));

((IChannel)proxy).Close();

factory.Close();

The sample code is attached.

ASP.NET Async Pages vs Async WCF Service Operation

wdong — Sun, 07 May 2006 07:37:00 GMT

In Dmitry’s blog, he mentioned about how to write ASP.NET async pages with ASP.NET 2.0. Basically, the server page can handle the request asynchronously without blocking the request thread and the server thread can be returned to the thread pool to handle other requests.

WCF is quite flexible in supporting asynchronous programming. Actually the client and the service can use any pattern (sync or asnc) in their own way to perform the same operation. For example, you can use the following service contract with an async operation in it:

[ServiceContract(Namespace = "http://tempuri.org", Name = " HelloService")]

interface IHelloService

{

[OperationContract(IsOneWay = false, AsyncPattern = true)]

IAsyncResult BeginHello(string text, AsyncCallback callback, object state);

string EndHello(IAsyncResult result);

}

This allows you to implement the service operation in the same way as ASP.NET async pages.

On the client side, you can access the service either from an async call or a sync call. For example, you can have a sync client to access the above async service operation with the following client contract:

[ServiceContract(Namespace = "http://tempuri.org", Name = "HelloService")]

interface IHelloService

{

[OperationContract(IsOneWay = false)]

string Hello(string text);

}

The sample code is attached for download.

WinFX February CTP is released!

wdong — Wed, 22 Feb 2006 21:57:00 GMT

GREAT NEWS! The WinFX February CTP has just been released today and can be downloaded from here. Here is the readme document. This CTP has consumed a lot of customer feedback and thus brings quite a lot of breaking changes over the January one. The detailed WCF breaking changes can be found here. The changes include namespaces, APIs, configuration, setup, etc. Ed Pinto has a quick blog entry on this.

The biggest change to WebHost is that the .svc file format is changed. This was actually reflected in my earlier blog entries.

Before:

<%@Service language="C#" Debug="true" class="Microsoft.ServiceModel.Samples.CalculatorService" %>

After:

<%@ServiceHost language="C#" Debug="true" Service="Microsoft.ServiceModel.Samples.CalculatorService" %>

You can also use the factory model to create your own ServiceHost with the following advanced syntax:

<%@ServiceHost language="C#" Debug="true" Factory="Microsoft.ServiceModel.Samples.CalculatorServiceHostFactory" Service="Microsoft.ServiceModel.Samples.CalculatorService" %>

The Visual Studio CTP for this WinFX can be found at this link.

The WinFX SDK is also released as part of the larger Windows SDK which includes pre-release documentation, samples, and tools for both Win32® and WinFX® in Windows Vista.

Hosting an “Indigo” (WCF) Service

wdong — Mon, 14 Nov 2005 09:01:00 GMT

Table of Contents:

Introduction

Hosting Environments

· ASMX Services

· WCF Services

· Different Hosting Environments

WAS Hosting Environment

· A Simple Hosted Service

· Service Configuration

· Service Addressing

· Service Activation

· Service Recycling

Let me start with something simple for this topic. I first make a few assumptions here:

You have used Microsoft Internet Information Services (IIS).
You are familiar with .NET Programming with Common Language Runtime (CLR) and ASP.NET.
You have heard of Microsoft Windows Communications Foundation (WCF), code-named “Indigo”.

That is all what you need to know before reading the following!

Below I will write about how to host a WCF service in a special “hosting” environment.

Introduction

There are tons of articles and blogs out there talking about Service Oriented Architecture (SOA), Web Services, and WCF. Never mind if you have not read them. So I will make things as simple as possible. Basically, WCF, as the next generation of service-oriented programming platform, provides a set of .NET APIs in its Version 1 (V1) for developers to use. It will be released as part of a larger package WinFX. You can download the most recent PDC release from here.

Every service-oriented programming model is also a client-server model. WCF has no difference. Both the client and service counterparts of WCF are based on the so-called “ABC” model: Address, Binding, and Contract. People also call this as “WHW” model: Address stands for “Where”, Binding stands for “How”, and Contract stands for “What”. Among the three, Binding is the most complicated part in this model. It tells WCF how to transfer data between the client and the service:

What transport do we use: HTTP, TCP, MSMQ, Named Pipe, etc?
What encodings do we use for the data to be encoded?
What security mechanisms do we use for the underlying channels?
Etc.

For each WCF service, there is a host that manages service instances and lifetime. The base type of the host is System.ServiceModel.ServiceHost. It provides events and extensibility points for you to programming with. Actually I am lying here. ServiceHost is not the most basic service host type, but System.ServiceModel.ServiceHostBase is. However, you will never touch this base type if you do not want to re-create the whole channel stack to replace WCF underlying implementations.

How far have I diverted from my topic? Aren’t we talking about WCF service hosting? No, not yet! The concept of “host” has relative meanings in different programming plug-in layers. The “host” that I will talk about here has a broader meaning: it is application-level “host”. That is, a host is an application that loads one or more WCF ServiceHosts, which we will call services in the following, and manages their lifetime. In some cases, it provides an environment that works as the entry point for all messages that are routed to the services. Am I clear here? If not, please read on.

Hosting Environments

There are different types of hosting environments for WCF services. To understand how these hosting environments work, we need to go back to see how the predecessor of WCF, a.k.a., ASMX works.

ASMX Services

When ASP.NET V1 was shipped, a Web service framework known as ASMX was introduced. It is tightly integrated with the ASP.NET HTTP pipeline. This pipeline provides the hosting environment to ASMX services and it is almost always hosted inside ASP.NET applications which are managed by IIS. In this way, ASMX services can leverage the advantages of ASP.NET applications such as process management, application recycling, configuration and deployment, and extensibility points provided by ASP.NET HTTP pipeline.

It is not required to have IIS to run ASMX services. For example, you can use the ASP.NET Cassini sample web server to host an ASP.NET application and thus ASMX services. You also build a web server into your own application to host the ASP.NET pipeline using the managed HTTP.sys utility System.Net.HttpListener(see Run ASMX without IIS).

However, ASMX services cannot run without the ASP.NET HTTP pipeline. Even though you can integrate the pipeline into your application as above, you still need to think of the ASMX services as being in a different world, that is, they have their own configuration and deployment which are quite web-flavored. In this sense, WCF services go one big step beyond to make service-oriented programming real.

WCF Services

The fact that ASMX services are tightly coupled with ASP.NET HTTP pipeline is due to the flat and passive HTTP request handling mechanism. HTTP requests received from IIS are passed on to ASP.NET pipeline and then are consumed by service methods.

WCF services, however, are based on a strictly layered model to break this paradigm. Roughly speaking, there are three different layers for WCF services:

ServiceModel layer
Channel layer
Transport layer

This layered model is similar as the Open System Interconnection (OSI) model. The lowest Transport layer is responsible for listening and receiving requests and converting the received data into “Messages”. A Message is a cross layer data packet that travels all of the layers to the top. The Channel layer provides a Message processing framework for different service requirements. In the real implementation, it actually consists of one or more sub-channel layers such as Basic layer, Security layer, ReliableMessaging layer, Transaction layer, etc. The top ServiceModel layer is the application layer that manages service instances and invokes service operations. It provides Object Models (OM) for people to program with.

In this layered model of WCF services, the top SericeModel layer is also responsible for building the lower level layers in different hosting environments. It also makes the Transport layer to be freely chosen among different communication protocols. This is why it does not rely on the ASP.NET HTTP pipeline as ASMX services does.

Different Hosting Environments

As mentioned above, WCF services are hosted by a ServiceHost. Ideally, any application or environment can create ServiceHost to host WCF services. In reality, we classify the different environments into three categories:

Windows Activation Service (WAS) hosting environment
EXE applications
NT Services

The WAS hosting environment is a broad concept that extends the ASP.NET HTTP pipeline hosting concept for ASMX services. WAS is an NT service in Windows Vista. It is separated out from the legacy IIS as a standalone Windows component that provides protocol-agnostic activation mechanism for different protocols besides HTTP. The IIS, Cassini, and any custom Web Server flavored hosting environments also fall into this category since they share the same WCF service deployment and activation mechanism. I will talk about this more in later sections.

You can easily host a WCF service in an EXE application so that you can control the lifetime of the ServiceHost. Furthermore, the WCF service shares the same configuration file with the application. This hosting environment is mostly useful when you also build your client code into the application. A good example is that a sophisticated business application with 3-tier architecture can have WCF services to pass messages between different layers.

NT Services are special EXE applications which are long running and the lifetime is controlled by Service Control Manager (SCM). Because of the long running behavior, you need to be careful of all of different requirements for writing an NT Service: security, reliability, and performance. You can use Microsoft Visual Studio to create managed NT Services with “Windows Service” project type.

WAS Hosting Environment

As mentioned above, a WCF service works similarly as an ASMX Service. For HTTP protocol, it relies on ASP.NET HTTP pipeline to transfer data. For non-HTTP protocols such as Net.Tcp, Net.Pipe, and Net.Msmq etc, it relies on the extensibility points, i.e., ProcessProtocolHandler (PPH) and AppDomainProtocolHandler (ADPH), of ASP.NET to transfer data. We will use the term “protocol handler” interchangeably to refer to either the ASP.NET HTTP pipeline or the ADPH. In the context of this writing, WCF services hosted in this environment are called WAS hosted services or simply called hosted services, and in contrast, services hosted in NT Services or EXE applications are called self-hosted services.

Let’s first take a look at a simple hosted service and see how it works.

A Simple Hosted Service

A hosted service requires a physical service file with extension “.svc” to be associated with it. Here is the content of a simple service file HelloWorld.svc:

<%@Service Language="C#" Class="HelloWorld.HelloService" %>

using System;

using System.ServiceModel;

namespace HelloWorld

{

[ServiceContract]

public interface IHelloContract

{

[OperationContract]

string Hello(string greeting);

}

[ServiceBehavior]

class HelloService : IHelloContract

{

public string Hello(string greeting)

{

return "You said: " + greeting;

}

This file has a Service directive which is enclosed in the “<% %>” block and it also contains inline C# code. The Service directive tells the hosting environment which Service this file points to.

Just as ASMX services, the code can be compiled into a DLL that is deployed to the Global Assembly Cache (GAC), or to the application’s “\bin” directory, or it can be put in a C# file under the application’s “\App_Code” directory.

With this service file, we have defined a service contract IHelloContract and the service implementation. However, the service still does not have an endpoint defined yet. You can either define an endpoint declaratively through the configuration file “web.config” or imperatively through code. The latter will be covered separately in a different blog later.

Service Configuration

The service configuration inside the web.config file is very similar as that of self-hosted services. Here is an example of web.config file for the above service:

<?xml version="1.0" encoding="utf-8"?>

<system.serviceModel>

<endpoint binding="basicHttpBinding"

contract="HelloWorld.IHelloContract" />

</service>

</services>

</system.serviceModel>

</configuration>

I need to point out a few points for this config file:

1) Service Type Attribute: The service type “HelloWorld.HelloService” specified here plays as a lookup key for the corresponding HelloWorld.svc. It tells the hosting environment which service will take the configuration specified here.

2) Endpoint Address: I did not specify the “address” of the endpoint here. The endpoint address is the same as the base address in this case. I will expand this in the next section.

3) Nested web.config: The service configuration can be specified in nested web.config files. For ASP.NET applications, a web.config file can locate in any sub-directories or virtual web directories as well as the root of the virtual application. All of the settings in the nested web.config files are merged for the virtual ancestors of the directory where the .svc file locates.

Service Addressing

The .svc file does not contain much useful information except for providing the service type which is also specified in the web.config file. Then why do we need .svc files after all? The main reason is that we need them to provide intuitive addressing model.

Suppose that we drop the above HelloWorld.svc file into a virtual application “/test”, we automatically have the following base address for the service:

http://localhost/test/HelloWorld.svc

You can enable different protocols for a single ASP.NET application. Each protocol needs to have a protocol binding for the whole web site. For IIS6 and below, the only protocol that is supported is HTTP (which implies HTTPS).

The WAS hosting environment looks up all enabled protocols for the ASP.NET application and generates the base addresses for the hosted service. Each base address has the following format:

<scheme>://<hostname>[:<port>]/<apppath>/<servicefilename>.svc

You can access the base addresses through the ServiceHostBase.BaseAddresses property. In WCF V1, only one base address is supported for each protocol. So if there are two or more bindings for HTTP is specified, you will get an ArgumentException on the service side with error message “Collection already contains an address with scheme http”.

Note: It is NOT recommended to specify an absolute address (with protocol scheme included) to the endpoint in web.config, otherwise, you will get AddressAccessDeniedException on the service side if the address does not match the service base address up to the application path (<apppath>) or EndpiontNotFoundException if you happen to match the application path but not the service path.

Service Activation

The WAS hosting environment is represented by the public type System.ServiceModel.ServiceHostingEnvironment. It is responsible for service activation, that is,

· It finds the service compilation information from System.Web.Compilation.BuildManager

· It creates the ServiceHost instance to host the service with compilation information.

· It then calls ServiceHost.Open to build the layers.

· It then caches the service and manages its lifetime inside the AppDomain.

This whole process is exposed through the following public method:

public static void EnsureServiceAvailable(string virtualPath)

This API is protocol agnostic. It is an extensible point for a custom protocol handler to activate the service.

The service activation process has the following characteristics:

1) Activation on demand: A WCF service is activated in the AppDomain only if EnsureServiceAvailable is called by one protocol handler for that service. Once it is activated, it will be active in the AppDomain until the AppDomain is unloaded.

2) Activation once for all: A WCF service can be activated from any protocol handler. Once it is activated, it is activated for all endpoints and thus all protocols. So when a second protocol handler calls EnsureServiceAvailable, it is a no-op as the service has been activated.

Service Recycling

Hosted WCF services enjoy all of the features for ASP.NET applications. One of the major feature is application recycling including AppDomain recycling and process (or AppPool) recycling. There are different factors that can cause application recycling to happen. See “Recycling Application Pool Settings” for more information about process recycling. When the worker process is recycled, all of the AppDomains in that process are also recycled. The configuration setting HostingEnvironmentSection.IdleTimeout can control AppDomain recycling. Also an AppDomain can be recycled if critical files for the application are changed. These files include web.config, assemblies in the “\bin” directory, code files in the “\App_Code” directory, etc.

Whenever a .svc file is modified in application, the AppDomain is also recycled. This is to simplify the service recycling mechanism. When the AppDomain is recycled, the ServiceHostingEnvironment tries to close all of the cached WCF services in a timely manner. Services not closed timely are aborted at the end. The timeout is controlled by the HostingEnvironmentSection.ShutdownTimeout property.

The drawback of service recycling is that all of the sessionful data is lost. This means that Security and ReliableMessaging break when recycling happens. The workaround is to leverage the ASP.NET state service features by enabling AspNetCompatibility mode. I will expand on this in a later blog.