Using WCF Services

Windows Communication Foundation (WCF) is a programming model from Microsoft that allows developers to build service-oriented applications. WCF provides security, reliability, transactional semantics, and interoperability. Programming with WCF is beyond the scope of this guidance. For more information, see the Getting Started Tutorial on MSDN.

You can access WCF services that are consumed in SharePoint applications with standard .NET Framework programming techniques. The main challenges of consuming WCF services in a SharePoint application are determining how to store and maintain the configuration information. Consumers of a WCF service must be properly configured to access the services. There are two ways to configure the clients of a WCF service. You can either use a configuration file or you can configure the client programmatically. Configuration data includes a valid service endpoint, a binding, and a behavior.

Because SharePoint is based on the ASP.NET platform, configuration data can be included in the Web.config file of a SharePoint Web application. SharePoint has a built-in deployment mechanism for making Web.config modifications. However, if the deployment process includes moving the application to more than one environment, providing the correct WCF endpoint information to the SharePoint object model is difficult. For example, during user acceptance testing (UAT), the endpoint of the Partner Portal application's pricing system points to a location on Server A. When the application is moved into the production environment, the endpoint of the pricing system points to a location on Server B. If the Web.config modifications are encoded as literals in the application code, developers must recompile the code with new endpoint information for each environment.

The following illustration shows the steps for deploying modifications to multiple environments by recompiling the code in case the Web.config modifications are encoded as literals in the application code.

Deployment to multiple environments with recompilation

You can avoid this situation by reading configuration values from an XML file deployed to the 12 hive. For example, the Partner Portal application reads the configuration values from an XML file in a known location and uses SharePoint's SPWebConfigModification API to update the Web.config in all Web front-end servers. For detailed information, see the Partner Portal application's Contoso.LOB.Services.Client project.

When there are multiple Web front-end servers, the XML file with the correct WCF configuration values must be deployed to the Web front-end server where the feature receiver will execute. If the feature receiver is executed on a Web front-end server that does not have the correct WCF configuration XML file, that environment will be updated with the wrong WCF endpoints. The best practice is to update the XML file in all Web front-end servers in that environment.

The following illustration shows the steps for deploying modifications to multiple environments without recompiling the code.

Deploying to multiple environments without recompilation

To ensure that all the Web front-end servers have the same WCF configuration XML file, you can update the XML file in the Web solution package before deployment. This requires a tool for opening and repackaging CAB files.

If you do not want to use the SharePoint object model methods to update the Web.config file, you can configure the binding and behavior of a WCF client with the WCF API. WCF allows you to programmatically set the binding and behavior for clients that connect to a WCF service. The advantage to this approach is that less configuration data must be maintained in the SharePoint application. The drawback is that it requires a greater development effort to integrate the client with the WCF services. For more information, see Managing Web.config Modifications.

Home page on MSDN | Community site