Services architecture planning (SharePoint Foundation 2010)
Updated: January 27, 2011
This article describes the services architecture for sharing service applications and provides example architectures for Microsoft SharePoint Foundation 2010.
In this article:
The following poster-size models are also available to use with this article. You can modify the diagrams within the models to represent your own organization plans.
Services in Microsoft SharePoint 2010 Products
Cross-farm services in SharePoint 2010 Products
About service applications
SharePoint Foundation 2010 includes a set of services that can be shared across Web applications. These services are called service applications. Some service applications can be shared across farms. Sharing service applications across Web applications and farms greatly reduces the resources required to provide these services across multiple sites.
The following service applications are provided with SharePoint Foundation 2010:
Business Data Connectivity service — Gives access to line-of-business data systems.
Usage and Health Data Collection service — Collects farm wide usage and health data, and provides the ability to view various usage and health reports.
Microsoft SharePoint Foundation Subscription Settings Service — Provides multi-tenant functionality for service applications. Tracks subscription IDs and settings for services that are deployed in partitioned mode. Deployed through Windows PowerShell only.
Some service applications are provided by other Microsoft products, including Microsoft Office Web Apps. Office Web Apps are online companions to Microsoft Word, Excel, PowerPoint, and OneNote, enabling people to access and do light editing or sharing of Office documents from virtually anywhere. Business customers licensed for Microsoft Office 2010 through a Volume Licensing program can run Office Web Apps on-premises on a server running SharePoint Foundation 2010.
The services infrastructure is extensible, and third party companies can create additional service applications that can be used with SharePoint Foundation 2010.
Service applications are different from the services that are started and stopped on specific servers and listed on the Services on Server page in the SharePoint Central Administration Web site. Some of the services listed on this page are associated with service applications, but service applications represent specific instances of services that can be configured and shared in specific ways.
Services infrastructure and design principles
SharePoint 2010 Products improves the services infrastructure that was introduced in the previous version. In SharePoint 2010 Products, the infrastructure for hosting services moves into SharePoint Foundation 2010 and the configuration of service offerings is much more flexible. Individual services can be configured independently, and third-party companies can add services to the platform.
You deploy service applications within a farm by using one of the following methods:
Selecting services when you run the SharePoint Products Configuration Wizard.
Adding services one by one on the Manage Service Applications page in the Central Administration site.
Using Windows PowerShell.
More granular configuration of services
The service application infrastructure gives you more control over which services are deployed and how service applications are shared:
You can deploy only the service applications that are needed to a farm.
Web applications can be configured to use only the service applications that are needed, instead of all the services that have been deployed.
You can deploy multiple instances of the same service in a farm and assign unique names to the resulting service applications.
You can share service applications across multiple Web applications within the same farm.
You can choose the service applications for a Web application when you create the Web application. You can also modify the service applications that are associated with a Web application later.
Service application groups
By default, all service applications are included in a default group, unless you change this setting for a service application when it is created. You can add and remove service applications from the default group at any time.
The following diagram shows a typical deployment with all service applications contained in the default service group.
When you create a Web application, you can select the default group or you can create a custom group of service applications. You create a custom group of service applications by selecting only the service applications that you want the Web application to use.
Custom groups that are created in Central Administration are not reusable across multiple Web applications. Each time that you select custom when you create a Web application, you are selecting service applications only for the Web application that you are creating.
Service applications are deployed within a single Internet Information Services (IIS) Web site. This is the default behavior and cannot be changed. However, you can customize the configuration of service application groups and the association of Web applications to service application groups.
The following diagram shows the logical architecture for a more complex deployment.
Notice the following characteristics of the farm in the diagram:
All service applications are contained within the same IIS Web site.
There are two groups of service applications: the default group and a custom group. Not all service applications have to be included in the default group. In the diagram, an additional instance of the Business Data Connectivity service is added to the farm but not included in the default group. It is used only by one Web application.
Web applications connect either to the default group or to a custom group of service applications. In the diagram, there is one custom group.
Service applications can be deployed to different application pools to achieve process isolation. However, if you want to optimize the performance of your farm, we recommend that you deploy service applications to one application pool.
To achieve physical isolation for a service application, choose or create a different application pool for the service application.
Connections for service applications
When you create a service application, a connection for the service application is created at the same time. A connection is a virtual entity that connects Web applications to service applications. In Windows PowerShell, these connections are called proxies. "Proxy" appears at the end of the type description for connections on the Manage Service Applications page in Central Administration.
Service application administration
Service applications are managed directly in Central Administration rather than through a separate administration site. If needed, service applications can be monitored and managed remotely. Service applications can also be managed and scripted by using Windows PowerShell.
Deploy service applications across farms
Some service applications can be shared across server farms. Other service applications can be shared only within a single server farm. In SharePoint Foundation 2010, the only in-box service application that can be shared across farms is Business Data Connectivity service.
The following guidance applies to sharing service applications across farms:
Any farm can consume a cross-farm service application as long as it is licensed to use the service application. For example, any SharePoint Foundation 2010 farm can consume the Business Data Connectivity service application from another farm. This includes consuming this service application from a SharePoint Server 2010 farm. However, a SharePoint Foundation 2010 farm cannot consume a cross-farm service that it is not licensed to use, such as the User Profile service application, from a SharePoint Server 2010 farm.
Each Web application can be configured to use service applications from different farms. For example, you can share the Business Data Connectivity service application across Web applications in several server farms. Web applications can consume this service application from one or more different farms while consuming service applications from the local farm.
Service applications that support sharing across farms can be run in a central farm and consumed from other farms. In large environments, computing-intensive service applications can be run in a central farm to minimize administrative overhead and to scale out easily and efficiently as requirements grow.
For more information about how to design architectures for cross-farm services, including example architectures, see the Cross-farm services in SharePoint 2010 Products model that is referenced at the beginning of this article.
Deploy cross-farm services
Sharing service applications across farms requires the following steps:
Configure trusted farms.
Ensure that farms have exchanged certificates to trust one another. Export the certificate to a file and back up the file before you connect to cross-farm services.
Publish the service application.
To share a service application across farms, you must first publish the service.
Connect to a cross-farm service application.
To consume a service that is published by a remote farm, create a connection to the service. This process prompts you to enter the URL of a published service, which is displayed during the publishing process. A connection on the local farm is created to connect to the service application on the remote farm.
For the Business Data Connectivity service application administration features to work from the consuming farm, the domain of the publishing farm must trust the domain of the consuming farm.
For more information about how to configure services for use across farms, see Share service applications across farms (SharePoint Foundation 2010).
January 27, 2011
Updated with information about how to implement cross-farm service applications.
May 12, 2010