Wikis - Page Details

First published by Margriet Bruggeman (3MVP, Microsoft Partne)
When: 27 Mar 2012 1:27 AM
Last revision by Ed Price - MSFT (aMicrosof)
When: 16 Apr 2013 2:46 PM
Revisions: 27
Comments: 23

Options

Can You Improve This Article?

Positively! Click Sign In to add the tip, solution, correction or comment that will help other users.

Report inappropriate content using these instructions.

SharePoint 2010 Best Practices: Where to Publish a WCF Service

If you're creating a WCF service you basically have two options:
- Create a WCF service in a SharePoint context.
- 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