SharePoint 2010: Where to Publish a WCF Service - TechNet Articles - United States (English) - TechNet Wiki

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