MCT USE ONLY. STUDENT USE PROHIBITED
Planning a Service Application Architecture 2-1
Module 2
Planning a Service Application Architecture
Contents:
Lesson 1: Introduction to the Service Application Architecture in
SharePoint 2010 2-4
Lesson 2: Service Application Architecture and Components 2-18
Lesson 3: Topologies for Service Applications 2-31
Lesson 4: Mapping Service Applications to Your Logical Architecture 2-43
Lab: Planning a Service Application Architecture 2-50
MCT USE ONLY. STUDENT USE PROHIBITED
2-2 Designing a Microsoft® SharePoint® 2010 Infrastructure
Module Overview
This module reviews the role of the service application architecture in Microsoft®
SharePoint® 2010 and examines its effect on your solution design. The way in
which you deploy services has changed fundamentally since Microsoft Office
SharePoint Server 2007. SharePoint 2010 has a granular approach to service
provision, so you can add service applications for any Web application on an
individual basis. Office SharePoint Server 2007 had a centralized approach to
service deployment, and you implemented all services through a single Shared
Services Provider (SSP).
Your SharePoint 2010 service application design can be more flexible than was
possible previously, so it is important to understand how to implement services
and plan your topology for SharePoint 2010.
Objectives
After completing this module, you will be able to:
• Describe the service application architecture in SharePoint 2010 and list the
available service applications.
MCT USE ONLY. STUDENT USE PROHIBITED
Planning a Service Application Architecture 2-3
• Describe the components and options that are available in the service
application architecture in SharePoint 2010.
• Describe some of the topology options for service applications and their
respective benefits.
• Describe how to map and document business requirements to service
applications.
MCT USE ONLY. STUDENT USE PROHIBITED
2-4 Designing a Microsoft® SharePoint® 2010 Infrastructure
Lesson 1
Introduction to the Service Application
Architecture in SharePoint 2010
The new service application architecture in SharePoint 2010 is a paradigm shift
from the SSP model in Office SharePoint Server 2007. It is essential that you
understand the available service applications so that you can develop the best
SharePoint 2010 solution for your organization.
The new, more granular, architecture offers opportunities for solution architects.
However, this flexibility comes with a responsibility to become fully conversant
with the subtleties of the service interrelationships.
Objectives
After completing this lesson, you will be able to:
• Describe the service application architecture in SharePoint 2010.
• Describe the differences between the SSP model in Office SharePoint Server
2007 and the service application architecture in SharePoint 2010.
MCT USE ONLY. STUDENT USE PROHIBITED
Planning a Service Application Architecture 2-5
• List the available service applications.
• Describe the security model for service applications.
• List dependencies between service applications.
• Describe the benefits of service applications.
MCT USE ONLY. STUDENT USE PROHIBITED
2-6 Designing a Microsoft® SharePoint® 2010 Infrastructure
Service Application Architecture in SharePoint 2010
Key Points
Service applications provide specific functionality to users in SharePoint 2010. This
includes access to application functionality with Microsoft Excel® 2010, Microsoft
Visio® 2010, or underlying services such as the Managed Metadata Service or the
Business Connectivity Services. The framework of the service application
architecture in SharePoint 2010 is designed to enable architects to select only the
services that are required to deliver a business solution. This is a major shift from
the SSP in Office SharePoint Server 2007.
A service application has the following components:
• An administrative interface, through which you can manage the associated
service application
• An application pool
• A service database or databases, dependent on the requirements of the service
• A service application proxy group
MCT USE ONLY. STUDENT USE PROHIBITED
Planning a Service Application Architecture 2-7
• One or more physical instances—the service process running on a physical
server
The service application architecture runs across the SKUs from SharePoint
Foundation 2010 through to SharePoint 2010 Enterprise, though not all SKUs
offer all of the SharePoint services. The service application architecture is also
extensible, so third-party vendors can develop service applications that you can
deploy in your solution.
The flexibility of the service application architecture—where you can deploy
multiple instances of the same service—provides a range of design options for
SharePoint 2010 architects. You can implement multiple instances of a service
application for resilience, performance, or security.
The service application architecture has its own set of terminology; it is important
to understand these terms as you work with your team to develop a design. The
following list explains the terminology:
• Service. The binary files that are installed on the server farm to execute a
function.
• Service application. The implementation of the service on a farm, including any
farm-specific configuration.
• Service application proxy. The target for user calls to the service applications.
User calls are not direct, but use Windows® Communication Foundation
(WCF) to communicate with the service via a proxy. The service applications
that are consumed through a Web application are termed a proxy group. The
proxy is a point to this service that handles calls through a Web Front End
(WFE) server.
• Service instance. A single implementation of a service application. You can
implement multiple instances of a service application in a variety of
configurations, either in the same proxy group or in multiple groups. These
instances run on an application server. You can deploy multiple instances to
provide isolated services or to improve performance through load balancing.
• Service consumer. This term describes the features that use, or consume, the
functionality that the service application provides. This may be an Excel Web
Part that renders Excel Services information in a browser.
Question: Why would you use multiple service instances?
MCT USE ONLY. STUDENT USE PROHIBITED
2-8 Designing a Microsoft® SharePoint® 2010 Infrastructure
Comparison of Service Applications in Office SharePoint
Server 2007 and SharePoint 2010
Key Points
The move to the service application architecture is probably the most significant
architectural change in SharePoint 2010. For architects who are moving from
Office SharePoint Server 2007 to SharePoint 2010, it is important to understand
the differences between these approaches to service deployment.
Office SharePoint Server 2007 provided the SSP to deploy a number of
productivity services, such as the Business Data Catalog (BDC) and Excel
Calculation Services. You typically only used one global SSP, which supplied all
services to all Web applications. This had several consequences for the solution
architect:
• The monolithic design meant that all services were available to all Web
applications; you could not have a separate service for one Web application.
For example, if your Accounts department wanted access to Excel Calculation
Services and the Marketing department wanted access to BDC, you had to
provide everyone with access to both in the farm. This was clearly a waste of
resources, and it also limited the security functionality of SSP.
MCT USE ONLY. STUDENT USE PROHIBITED
Planning a Service Application Architecture 2-9
• There was only one SSP for each farm, which meant that there was a single
point of failure. If this SSP failed, all users lost all SSP functionality.
• SSP was inflexible in deployment. You could not implement granular services
to individual business groups, so a design inevitably provisioned services to
users who did not need them.
• SSP was not extensible. Only services that Office SharePoint Server 2007
provided were available.
The new architecture in SharePoint 2010 offers far greater design scope for
architects. You can now deliver the right set of functionality to the right users
without deploying unnecessary services to all users. This enables architects to:
• Deploy granular services, delivering only the services that are requested for
each Web application.
• Design a flexible deployment that provides scalable resilience and security
through the implementation of multiple instances of service applications. This
enables you to deploy multiple instances of a service application, such as Excel
Services, which are isolated from each other, so that independent departments
or groups do not share Excel content.
• Manage performance by deploying multiple instances of a service application
for the same Web application. Each service application demands resources
such as memory and processor. For example, PerformancePoint Services can
be processor-intensive, so you can deploy multiple service instances to
maximize performance.
• Extend service functionality by deploying third-party service applications or by
purchasing additional service application SKUs such as Microsoft Project
Server 2010.
MCT USE ONLY. STUDENT USE PROHIBITED
2-10 Designing a Microsoft® SharePoint® 2010 Infrastructure
Service Applications in SharePoint 2010
Key Points
SharePoint 2010 SKUs provide a range of services that architects can use to deliver
business requirements. The range of service applications grows with each level of
SKU functionality, from SharePoint Foundation 2010 through SharePoint 2010
Standard to SharePoint 2010 Enterprise. It is important that you identify the right
SKU for your organization, because this will save time and money.
In addition to these service application options, there are some service applications
that are delivered by default:
• The Application Discovery and Load Balancer Service Application.This service
provides administrative functionality for the service application architecture,
such as registering servers on the farm and grouping service applications
across Web applications. The load balancing functionality means that you can
provide the best available performance by providing multiple service
application instances to which SharePoint 2010 can route user requests. This
happens automatically. You may also see this called the Topology Service
Application, derived from the Windows PowerShell™ command
SPTopologyServiceApplication.