Wednesday, July 2, 2014

Hosting Custom WCF Services in IIS vs SharePoint

copyright from: nikpatel.net

Please note that this article refers to Custom WCF Services built to access SharePoint data or extend SharePoint Operations and what items needs to considered while making decision of hosting in IIS or SharePoint environment.
With SharePoint 2010, Microsoft has allowed SharePoint developers an option of hosting Custom WCF Services in SharePoint 2010 environment. Additionally, WCF Services can be hosted in IIS as well. As with many other Microsoft technologies, developers and administrators faces decision making process whether to deploy custom WCF Services in SharePoint or IIS. Unfortunately, I haven’t come across any official guidance in this matter from Microsoft and most of the articles on TechNet or MSDN demonstrate custom WCF service hosted in SharePoint 2010.
In this article, I will try to list high level items needs to consider while making decision on deploying WCF Service in IIS or SharePoint.
Hosting WCF Service in IIS
  • Can be deployed to dedicated IIS web servers, non-SharePoint servers to utilize dedicated RAM
  • WCF Service would run in its own worker process or application pool
  • WCF Service can have separate authentication and authorization mechanism than SharePoint Implementation.
  • WCF Service can be configured with impersonate = false to run WCF Service logic as application pool service account.
  • If you are accessing or processing SharePoint data from WCF services, you must use REST based API or client side object model to integrate with SharePoint implementation unless you are deploying WCF services as dedicated IIS web site on SharePoint Servers.
  • Needs to deploy WCF service on multiple IIS servers with load balancer to provide high availability
  • WCF Service hosted on separate IIS server wouldn’t interfere with SharePoint processes and chew up RAM required by SharePoint operations
Hosting WCF Service in SharePoint
  • Runs in SharePoint Web Application’s worker process
  • Deployed to SharePoint servers in the farm using SharePoint solutions framework
  • WCF Service would have to use same authentication and authorization mechanism as SharePoint Implementation.
  • WCF Service can’t be configured with impersonate = false since impersonation is enabled by default in SharePoint 2010. This allows calling application to run WCF service in user context and return security trimmed data.
  • If you are accessing or processing SharePoint data from WCF services, it provides best performance because it runs under SharePoint worker process and can use Server Side Object Model
  • WCF Service is already deployed to all the WFE servers and provides high availability by using SharePoint inbuilt load balancer
  • WCF Service hosted in SharePoint worker process would share RAM with SharePoint operations and it may degrade SharePoint performance and scalability
  • If your web application is configured with claims based authentication, it is important to remember that IIS website is configured to have anonymous access. Since your WCF endpoints would be hosted in SharePoint web application, it may receive requests from anonymous users. It is always best practice to check if user is authorized user in WCF service implementation.
Based on above items, hosting WCF Services on dedicated IIS servers would make great case for centralized enterprise services library especially when performance, security, scalability, authentication, and authorization model matters most. This would allow hosting all the custom WCF Services in single environment managed by single team whether they are based on SharePoint or not.
Best use case to deploy WCF Service in SharePoint is to extend SharePoint capabilities and run WCF Services in User Context like out of box WCF Services hosted in ISAPI directory (e.g. Client.svc or ListData.svc or ASMX files). Additionally, hosting WCF services would allow you to use Administrative SharePoint APIs which isn’t available in Client Object Model or REST based API. E.g. User Profile Services API are not available through client object model and if your WCF service is maintaining User Profiles, you have to use Server Side Object Model and hosting custom WCF Service in SharePoint would make more sense.
And, here is the Kicker. You can also host WCF Services as dedicated IIS web sites on the SharePoint Servers to use best of both worlds. This would allow performing Administrative SharePoint operations using Server Side Object Model with dedicated worker process, impersonation model, authentication model, and authorization model. Recently I wrote SharePoint Site Provisioning WCF web service which needed to run under farm account (impersonation = false), anonymous authentication disabled, and perform Administrative APIs using Server Side Object Model. This was perfect case where I needed to host WCF services on IIS servers on SharePoint Servers.
Hopefully this article would help making intelligent decisions while hosting custom WCF Service based on SharePoint Framework.

No comments: