WCF Services in SharePoint Foundation 2010
Applies to: SharePoint Foundation 2010
The new REST (Representational State Transfer) interface and new client object model in Microsoft SharePoint Foundation 2010 provide access to common functionality of SharePoint Foundation websites, but not to all their functionality. If you are developing a custom application for Microsoft SharePoint Server 2010, there might be a default Windows Communication Foundation (WCF) web service that exposes the specific functionality that you need to use. However, if no web service provides the access you need, you can create a custom web service that uses the server object model to access data. SharePoint Foundation 2010 supports creation of both Microsoft ASP.NET and WCF custom web services, which can be used to develop SOAP-style or RESTful web services.
Custom ASP.NET web services that you created for SharePoint Foundation will continue to function in SharePoint Foundation 2010 without the need for modification, but moving forward, we recommend that you instead create custom WCF web services. Although an ASP.NET web service has simpler configuration requirements, a WCF service provides more flexible, powerful bindings that are important for advanced applications. By hosting your WCF web service in SharePoint Foundation, you can reduce configuration requirements. If you created a custom WCF web service for the previous release, you probably had to do workarounds to make it work and hosted the service within a separate web application. In SharePoint Foundation 2010, no workarounds are needed because WCF services are supported by default.
You develop a custom ASP.NET web service in the same way as in the previous release. As seen in Walkthrough: Creating a Custom ASP.NET Web Service, you deploy the custom ASP.NET web service to SharePoint Foundation, and you add .wsdl and .disco files to make the schema of your web service discoverable by Microsoft Visual Studio. A WCF web service can be more complicated, because its architecture requires you to specify complete configuration of the WCF service endpoints. This configuration information includes endpoint addresses, a service contract, and a binding configuration, which contains specific information about the environment in which the web service operates. However, the SharePoint Foundation developer usually has no information about the environment in which the web service will operate; the farm administrator determines the configuration of web applications and deploys web services. The administrator can choose from multiple authentication schemes supported by SharePoint Foundation or can enable multiple authentication schemes and assign multiple addresses to the Internet Information Services (IIS) web application. In these cases, a WCF service requires a separate endpoint for each authentication scheme and address. Because this kind of configuration information cannot be provided in a static form, a web.config type of configuration cannot be used. The solution is dynamic configuration, or in WCF terms, programmatic configuration.
Important
When a web application is configured to use claims authentication (Windows claims, form-based authentication claims, or SAML claims), the IIS website is always configured to have anonymous access turned on. Your custom SOAP and WCF endpoints may receive requests from anonymous users. If you have code in your WCF service that calls the RunWithElevatedPrivileges method to access information without first checking whether the call is from an authorized user or an anonymous user, you risk returning protected SharePoint data to any anonymous user for some of your functions that use that approach.
Note
Claims authentication is the standard authentication method in SharePoint 2010. For more information about claims, see Claims and Security and Plan Authentication Methods.
WCF Dynamic Configuration
WCF dynamic configuration in SharePoint Foundation comes in the form of a custom service factory. When you develop your WCF service, you must specify the service factory provided by SharePoint Foundation, and after you specify it, you no longer need configuration entries in web.config. At run time, the SharePoint Foundation service factory configures the appropriate endpoints for your service automatically. You can also instruct the SharePoint Foundation service factory to create a metadata exchange endpoint for your custom service automatically by using a specialized attribute on your service class. When the SharePoint Foundation service factory detects this attribute on the service class, it automatically creates a metadata exchange endpoint for your service. The final step in development of a WCF web service is to deploy it in the %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\ISAPI folder or in a web application.
The following table lists the service types and factories provided by SharePoint Foundation.
Service Type |
Service Factory |
Description |
|---|---|---|
SOAP service |
MultipleBaseAddressBasicHttpBindingServiceHostFactory |
Basic HTTP binding must be used, which creates endpoints for a service based on the basic HTTP binding. |
REST Service |
MultipleBaseAddressWebServiceHostFactory |
The service factory creates endpoints with web bindings. |
ADO.NET Data Service |
MultipleBaseAddressDataServiceHostFactory |
A data service host factory can be used. |
You can apply the following attributes to a service class for behavior:
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)] — For compatibility with ASP.NET.
[BasicHttpBindingServiceMetadataExchangeEndpoint] — To enable a metadata exchange (MEX) endpoint.
Use the WcfServiceSettings property of SPWebService to specify the configuration class for customizing the parameters of the endpoint generated by the SharePoint Foundation service factory. If the capabilities of this configuration class are not sufficient for your needs, you can also develop your own custom service factory that creates endpoints for your web service dynamically.
WCF Service Configuration
A WCF service that is hosted in SharePoint Foundation and that uses dynamic configuration relies on the SharePoint Foundation service factory for configuration of its endpoints. At startup, the service factory reads configuration information from IIS and creates appropriate endpoints for every authentication scheme and address that is specified for the available application. However, WCF requires a unique address for every endpoint. If multiple authentication schemes are enabled for a web application, multiple endpoints map to the same address. To resolve this issue, SharePoint Foundation creates a unique address for every authentication scheme. The address is formed by concatenating the base URL of the service with the name of the authentication scheme, such as the following:
https://server/_vti_bin/Service.svc/negotiate
https://server/_vti_bin/Service.svc/ntlm
https://server/_vti_bin/Service.svc/anonymous
When you add a service reference for a custom WCF web service in an application, you do not have to specify the authentication suffix, but can access the web service through its original URL (for example, https://server/_vti_bin/Service.svc). This is possible because of the HTTP Module, a standard element of the SharePoint Foundation infrastructure that preprocesses all requests handled by SharePoint Foundation. The HTTP Module recognizes WCF service configuration convention, and when a request comes to a WCF service that uses dynamic configuration, the module reroutes the request to the appropriate endpoint based on the authentication of the request. This rerouting scheme works transparently for client applications that see only a single WCF service located at the original name that can be accessed through multiple authentication schemes.
See Also
Concepts
Creating a Custom WCF Service in SharePoint Foundation