Guidance for Using WCF in Windows Azure

WCF services can be hosted in either a web role or a worker role. Which type of role you decide to use depends on the type of WCF service you are writing.

Web roles are customized for web application programming as supported by IIS 7 and ASP.NET. When you use a web role Windows Azure completes the basic IIS setup for you. This role is best used for providing a web-based front end for your hosted service. Web roles in Windows Azure provide support for the HTTP and HTTPS protocols and can serve applications that use the HTTP protocol with a WCF service by using the basicHttpBinding element of the WCF service model.

Worker roles are useful for generalized development, and can perform background processing for a web role. When you have a need for a background process that performs long-running or intermittent tasks, you should use a worker role. External endpoints enable worker roles to expose Internet-facing services over ports other than 80 and 443. These endpoints can be bound to any process and allow the process to communicate externally using a variety of TCP-based application protocols with the WCF service by using the netTcpBindings binding.

The netTcpBindings binding can also be used to communicate internally with a WCF service hosted in a worker role. A scenario in which this is useful is a hosted service that consists of an ASP.Net/MVC site that is running in a web role that communicates with a WCF service that is running in a worker role.

A WCF service that is set up for deployment to a Windows Azure web role uses the same setup and configuration as a WCF service hosted in IIS on on-premise servers. The tips described in this section will help you make the transition to Windows Azure smoothly.

Many HTTP applications, notably WCF, assume that the VIP and dip port are set to the same value.  For example, when WCF produces MEX/WSDL documents (to support the Visual Studio Add Service Reference function), it uses the current request to build various absolute URIs. The ports must match to enable Visual Studio to generate the correct references. When you configure the service definition for the hosted service you should configure the input endpoint to specify that both the port attribute and localPort attribute are set to 80 as shown in the following code snippet.

<ServiceDefinition name="MyService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
   <WebRole name="WebRole1">
      …
      <Endpoints>
         <InputEndpoint name="HttpIn" protocol="http" port="80" localPort="80" />
      </Endpoints>
   </WebRole>
   …
</ServiceDefinition>

Note
If you are using the .NET Framework 3.5 make sure that the useRequestHeadersForMetadataAddress behavior is set in the WCF service configuration. This will make sure that the metadata and other URIs exposed in the WSDL file do not contain the host names of any internal machines. By default the .NET Framework 4 sets this behavior.

The Windows Azure Tools for Microsoft Visual Studio provides a template for creating a basic WCF service in a web role. The template configures the WCF service and the necessary Windows Azure service definitions. The example in Code Quick Start: Create and deploy a WCF service in Windows Azure shows you how to create the basic service and generate the client proxy using the Visual Studio tools.

The security concerns for hosting a WCF service on Windows Azure is the same as those you encounter hosting the service in on-premise servers. For information about security for WCF, see Security Overview in the Windows Communication Foundation documentation.

If you create a WCF service that uses SSL certificates you may encounter a failure in which the certificate cannot be verified against a trusted certification authority. When you view the certificate you see the following error:

This error it is typically caused by missing certificates in the certificate chain. This error can be corrected by adding all the certificates in the chain to the web role.

When you package and deploy the hosted service, the certificates are also deployed.

Use the Windows Azure Access Control Service (ACS)

You can use the Windows Azure Access Control Service (ACS) to help secure the WCF Services. See the following topics for more information:

• Securing WCF Services with ACS
  
  
• How To: Authenticate to a REST WCF Service Deployed to Windows Azure Using ACS
  
  
• How To: Authenticate with a Client Certificate to a WCF Service Protected by ACS - This topic shows how to write code for WCF clients that communicate with WCF services that require Shared Services authentication using Windows Azure Access Control Service (ACS).
  
  
• Code Sample: WCF Username Authentication - This sample illustrates how to use a user name and password to authenticate to Windows Azure Access Control Service (ACS) and obtain access to a Windows Communication Foundation (WCF) relying party.
  
  

You can troubleshoot performance issues for WCF services in Windows Azure using the same techniques that you use with WCF services hosted on-premise servers. Depending on type of issues you encounter, you may use traces and tools such as:

• Service Trace Viewer Tool
  
  
• System.Net Network Tracing
  
  
• Fiddler
  
  
• WinDbg Debugging Tool for Windows
  
  
• Debug Diagnostic Tool (DebugDiag).
  
  

For information about known issues related to developing WCF clients and services, see WCF Troubleshooting quick start.

Typically WCF tracing is the best way to troubleshoot or debug any WCF issues. The following topics provide guidance about how to use WCF tracing.

• WCF Tracing in Windows Azure SDK 1.3 or higher – This blog entry shows how to modify the web.config file to enable WCF tracing in Windows Azure.
  
  
• Configuring Tracing – This topic describes how you can enable tracing, configure trace sources to emit traces and set trace levels, set activity tracing and propagation to support end-to-end trace correlation, and set trace listeners to access traces.
  
  
• Using Tracing to Troubleshoot your Application – This topic lists various topics that describe how you can use tracing to troubleshoot your application.
  
  
• Debugging WCF Services – This topic provides information about restrictions on debugging WCF, debugger support for stepping into a WCF Service, and how to debug a WCF Service that runs outside IIS or the ASP.NET Development server.