Table of Contents


If you're creating a WCF service you basically have two options:
  1. Create a WCF service in a SharePoint context.
  2. Create a separate WCF service.
If you're creating a WCF service in a SharePoint context, you're basically doing the following: you create a SharePointproject, add the WCF service and deploy it to the ISAPI folder. See: http://msdn.microsoft.com/en-us/library/ff521581.aspx for more info. Also, check out  http://cksdev.codeplex.com/, it contains a helpful WCF template.

If you're creating a separate WCF service,  you're basically creating a WCF project and publish the service. See http://sharepointdragons.com/2011/10/07/parallel-programming-in-sharepoint-2010-the-back-to-the-future-pattern/

So, when it comes to choosing one of the two scenarios, which one is best practice, and why?

Create a WCF service in a SharePoint context

  • If you need the service to run in the current SharePoint context
  • If you want to use the Complete support of SharePoint APIs
  • If you want your client to access your service with the same experience as of SharePoint OOB services
  • If you extend some custom functionality of your solution which is by default not provided by SharePoint services.
  • If you want to use and provide the same authentication/authorization configured in the farm while accessing your service.
  •  If your service is getting used internally between the SharePoint farms.
  •  If you want to access the custom service internally for your Solution (client / server kind of architecture)

 

Create a separate WCF service

  • Consider to wrap a .NET 3.5 service in a separate WCF 4 service that uses TPL to speed up things (the back to the future pattern
  • If this is just some functionality from your solution which you want to expose to outer world.
  • You can only use the Client APIs / SharePoint webservice / or your custom code reference inside your WCF service.
  • You have to take care of Authentication/autorization
  • If can be accessed by some other client, without even knowing the existence of SharePoint in back-end.

If you do create a separate WCF service, it's best practice to run it in a separate (non-SharePoint) IIS web site. This way, you won't inherit the config settings of the SharePoint web application, which usually makes things a lot easier.

Inspired by forum discussion: http://social.technet.microsoft.com/Forums/en-US/sharepoint2010programming/thread/f3970114-9dab-45a4-a76a-e9458f57a463