Services architecture planning (SharePoint Server 2010)

Applies to: SharePoint Server 2010, SharePoint Foundation 2010

This article describes the services architecture for sharing service applications and provides example architectures for Microsoft SharePoint Server 2010.

In this article:

• About service applications

• Services infrastructure and design principles

• Deploying service applications across farms

• Planning considerations for services that access external data sources

• Example architectures

• Single farm, single service application group

• Single farm, multiple service application groups

• Enterprise services farms

• Specialized service farms

• Cross-organization farms

When planning your services architecture, consider the following questions:

• What service applications does your organization require?

• Do any teams require dedicated service applications?

• How many farms does your organization require?

• Are there opportunities to share services across farms?

• Do the needs of your organization warrant a centralized services farm?

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

  • Visio (https://go.microsoft.com/fwlink/p/?LinkID=167090)

  • PDF (https://go.microsoft.com/fwlink/p/?LinkID=167092)

  • XPS (https://go.microsoft.com/fwlink/p/?LinkID=167091)

• Cross-farm services in SharePoint 2010 Products

  • Visio(https://go.microsoft.com/fwlink/p/?LinkID=167093)

  • PDF (https://go.microsoft.com/fwlink/p/?LinkID=167095)

  • XPS (https://go.microsoft.com/fwlink/p/?LinkID=167094)

About service applications

SharePoint Server 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 table lists service applications that are included with SharePoint 2010 Products.

Some services are provided by other Microsoft products, including the services listed in the following table.

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.

Sharing services is no longer exclusive to SharePoint Server, and services are no longer contained in Shared Services Providers (SSPs).

Deploying services

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 updated services infrastructure gives you more control over which services are deployed and how service applications are shared:

1. You can deploy only the service applications that are needed to a farm.

2. Web applications can be configured to use only the service applications that are needed, instead of all the services that have been deployed.

3. You can deploy multiple instances of the same service in a farm and assign unique names to the resulting service applications.

4. 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.

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.

The following screen shot shows a list of service applications for an example farm that can be selected if custom is selected when a Web application is created. Only the first few service applications are included in the picture.

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.

Logical architecture

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 typical farm 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, Service application F is 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, as shown in the following diagram.

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. Some connections might include settings that can be modified. For example, connections for the Managed Metadata service application include several settings, including Term Store Administrators and Default Language.

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.

Deploying 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.

The following diagram shows which service applications can be shared across farms and which service applications are limited to a single farm.

Design guidance

The following guidance applies to sharing service applications across farms:

• Service applications that support sharing across farms can be run in a central farm and consumed from other farms.

• Each Web application can be configured to use service applications from different farms. For example, you can share the User Profile service across Web applications in several server farms, while at the same time you can configure some service applications, such as the Business Data Connectivity service, to be used locally.

• 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, see Enterprise services farms, later in this article.

WAN environments

Some cross-farm service applications are not recommended for use in wide area network (WAN) environments. The following table lists current recommendations for deploying service applications in these environments.

For more information about how to deploy service applications in WAN environments, see Global solutions for SharePoint 2010 Products (model).

Deploying cross-farm services

Sharing service applications across farms requires several steps:

1. 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.

2. Publish the service applications.

   To share a service application across farms, you first publish the service.

3. Connect to cross-farm service applications.

   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 publish process. A connection on the local farm is created to connect to the service application on the remote farm.

If the server farms are located in two domains, the User Profile service application requires both domains to trust each other. For the Business Data Connectivity and Secure Store service application administration features to work from the consuming farm, the domain of the publishing farm must trust the domain of the consuming farm. Other cross-farm service applications work without a trust requirement between domains.

For more information about how to configure services for use across farms, see Connect to a service application on a remote farm (SharePoint Server 2010).

Planning considerations for services that access external data sources

Some service applications can access external data sources. Service applications that use a delegated Windows identity to access external data sources put additional requirements on the environment. For these service applications, external data sources must reside within the same domain as the SharePoint Server 2010 farm where the service applications are located or the service application must be configured to use the Secure Store Service.

The following service applications use a delegated Windows identity to access external data sources:

• Excel Services

• PerformancePoint Services

• InfoPath Forms Services

• Visio Services

Service applications that use a delegated Windows identity to access external data sources can be configured to use the Secure Store Service as an alternative. The Secure Store Service stores and maintains user or service credentials. Service applications can use stored credentials to authenticate to a data source directly. 

If the Secure Store Service is not used and external data sources do not reside within the same domain, authentication to the external data sources will fail. If farm servers are split between two domains, the application servers must reside in the same domain as the external data sources.

The following service applications and products are not affected by these requirements:

• Business Data Connectivity service and Microsoft Business Connectivity Services

• Access Services

• Microsoft SQL Server PowerPivot for Microsoft SharePoint

• Microsoft SQL Server Reporting Services (SSRS)

• Microsoft Project Server 2010

Example architectures

The rest of this article provides example architectures for common deployment scenarios.

Single farm, single service application group

In an architecture that includes a single farm and a single service application group, the default service application group is used for all Web applications in the farm. All sites have access to all of the service applications that are deployed in the farm.

Advantages

This architecture provides the following advantages:

• It is the simplest architecture to deploy.

• All service applications are available to all Web applications.

• Farm resources are used most efficiently.

• All service applications are managed centrally.

Disadvantages

There are several tradeoffs to consider with this architecture:

• You cannot isolate service application data.

• Individual departments or teams cannot manage service applications on their own.

Recommendations

The architecture that includes a single farm and a single service application–group is the recommended configuration for most organizations, at least initially. This configuration works well when you want to host many sites for a single company on the same farm.

Use this configuration to meet the following goals:

• You want to optimize the resources required to run service applications within a farm.

• You are sharing content and profile data across sites that otherwise require process isolation for performance or security reasons.

Single farm, multiple service application groups

If teams require dedicated service applications, build an architecture by using one or more custom groups of service applications. Follow these guidelines:

• Deploy specific service applications for dedicated use by one or more teams within an organization.

• Ensure that the dedicated service applications are not also included in the default group.

• Create one or more Web applications that use a custom group of service applications. The SharePoint administrator selects the service applications that are included in the custom group.

In the following diagram, Farm B shows an example architecture with two groups of service applications. In this example, the Finance team requires a dedicated Excel Services application. Access Services is also deployed for this team.

You can create more than one custom service application group. In the following diagram, two custom groups are created in Farm C. Building on the architecture for Farm B, dedicated Managed Metadata and Business Data Connectivity service applications are deployed to the farm for use by the HR department. This results in a second custom service application group, in addition to the first dedicated service application group that was created for the Finance team.

Service applications that are deployed for dedicated use can share the same application pool or be deployed to a separate application pool for additional isolation. The design of Farm B (two diagrams previous) achieves process isolation for service applications that are deployed for the Finance team by putting these service applications in a dedicated application pool. For Farm C, shown in the preceding diagram, one application pool is used for all service applications; in this architecture, service applications are deployed to optimize performance instead.

Connecting to multiple Managed Metadata service applications

A service application group can include multiple Managed Metadata service applications. For example, in the diagram of Farm C, the custom group that is highlighted in green includes two Managed Metadata service applications.

In this scenario, the sites within the Web applications display taxonomy, social tagging, and other features from both Managed Metadata service applications. Unlike other cross-farm services, Web parts by default include data from multiple Managed Metadata service applications.

For information about how to manage multiple Managed Metadata service applications, see Managed metadata service application overview (SharePoint Server 2010).

Advantages

Architectures that include multiple service application groups provide the following advantages:

• They accommodate multiple organizational goals in the same farm.

• Service data can be isolated.

• Individual teams or departments can manage the service applications that have been dedicated for their use.

• Sites can be configured to use a subset of service applications.

Disadvantages

The tradeoffs in architectures that use more than one group of service applications include the following:

• They are more complex to configure and manage.

• Farm resources are consumed to support multiple instances of some service applications, which can affect performance.

Recommendations

Architectures that include multiple service application groups work well for companies that have divisions or teams that require dedicated service applications or isolated service data, or for sites that are set up with a narrower scope, such as partner collaboration.

Additionally, when multiple groups of service applications are configured, teams and sites can consume services that are offered enterprise-wide, such as profile and search services, while at the same time isolating the use of targeted services for security or performance reasons.

Service applications that are typically deployed for dedicated use by a specific team or department include:

• Excel Services   To optimize performance for a targeted team or to isolate sensitive data.

• Managed Metadata    To allow a team or department to manage their own taxonomy, hierarchies, keywords, and so on. SharePoint Server 2010 combines the results of multiple Managed Metadata service applications, so taxonomies, content types, and other elements can be shared across an organization.

• Business Data Connectivity   Individual teams or departments can integrate with their own line-of-business data systems and keep the data isolated from the rest of the organization.

In some cases, a dedicated group of service applications is configured to narrow the list of services that are used by a Web application. For example, a partner collaboration site can be configured to consume a subset of the service applications that are offered by the farm.

Enterprise services farms

An enterprise services farm is a server farm that is dedicated to hosting service applications for an organization. The following diagram shows an enterprise services farm that hosts the most frequently deployed cross-farm service applications. It also shows several common kinds of farms that consume services from an enterprise services farm.

The rest of this section describes the other farms in the diagram. Farm 2, Farm 3, and Farm 4 represent the kinds of farms that are most likely to consume services from an enterprise services farm.

Published content–only farms (all service applications are remote)

You can deploy a server farm without deploying any service applications locally. In Farm 2, no service applications are hosted locally. All service applications are consumed from a separate farm.

This configuration works well for content that is published. It reduces the administrative efforts required to host a published content farm and allows an organization to take advantage of centrally managed service applications.

Use this configuration when you have the following goals:

• You want to optimize the resources within a farm for hosting content, instead of running service applications.

• You are integrating with organization-wide profiles, metadata, search, and other centrally managed resources.

Collaboration farms (mix of local and remote service applications)

Farm 3 represents a farm that is optimized for collaboration. All service applications that cannot be shared across farms are hosted locally. These include the client-related service applications, which are important for collaboration. Cross-farm service applications are consumed from an enterprise services farm (Farm 1).

Farms can consume services from more than one remote farm. In the diagram, Farm 3 also consumes the Managed Metadata service from a specialized department farm (Farm 4) to integrate with this department's autonomously managed taxonomy, social tagging, and other features.

If there are multiple Managed Metadata service applications, one of the service applications must be designated as the primary service application that hosts the corporate taxonomy. All other instances of this service application are then secondary, and they provide additional data to the primary service application data. Unlike other cross-farm services, Web parts by default include data from multiple Managed Metadata service applications.

This is the recommended configuration for companies that host multiple farms to meet business needs. Use this configuration to meet the following goals:

• To optimize administrative and farm resources at the enterprise level for hosting services (Farm 1).

• To optimize resources at the farm level for hosting collaboration sites (Farm 3).

• To integrate with organization-wide profiles, metadata, search, and other centrally managed resources.

• To integrate with metadata produced by a specialized team or department (Farm 4).

Farms for specialized departments (mix of local and remote service applications)

Some teams within an organization might require a separate deployment of specific services for the following reasons:

• To ensure data isolation (such as Business Data Connectivity data).

• To provide the ability to autonomously manage service applications (such as Managed Metadata).

Farm 4 provides an example. The characteristics of this farm include the following:

• It consumes centrally managed service applications that include Managed Metadata.

• It also includes its own Managed Metadata service application, so this team can autonomously manage its own metadata. Because this service application is shared, the metadata from the rest of the organization can be integrated with this metadata.

Use this configuration to meet the following goals:

• Allow a specialized team or department to manage metadata on their own.

• Ensure that specific service data is isolated and managed separately from the rest of the organization.

Specialized service farms

Consider deploying specialized service farms to optimize farm resources for specific service applications. This allows you to scale out the server farm and to scale up the hardware to optimize performance for a specific service application.

The primary service application that might warrant a dedicated services farm is Search. Search has unique performance and capacity requirements. By offloading the Search service application to a dedicated farm, resources can be optimized for the remaining cross-farm service applications.

The following diagram shows two centralized services farms. One farm is optimized for Search. The other farm hosts all other cross-farm service applications.

Cross-organization farms

Service applications can be shared across any farm, not only enterprise services farms. Consider sharing service applications across farms in the following scenarios.

Scenario A: To provide enterprise-wide service applications without a dedicated enterprise services farm, as shown in the following diagram.

Scenario B: To share resources across farms and to avoid deploying redundant service applications, as shown in the following diagram.

See Also

Other Resources

Resource Center: Architecture Design for SharePoint Server 2010
Resource Center: Security and Authentication for SharePoint Server 2010