SPC’09: Introduction to Service Applications and Topology in SharePoint 2010
Disclaimer: This post is based on notes taken while watching a conference session. For that reason, it may contain incorrect information or data that I might have misunderstood. Also, the product it refers to was not available yet at the time of the writing, thus, not allowing me to validate the present information.
This was the first session I attended on the second day of the SharePoint Conference 2009 and it was lectured by Umesh Unnikrishnan from Microsoft.
- Service is a middle tier feature that performs the useful function of providing data or processing resources to SharePoint features. For instance, Search is a Service.
- Service Applications is a configured logical instance of a Service, which provides data or computer resources and exposes administrative interfaces.
- Service Instance is a running physical instance of a Service (in the sense of a process).
Web Applications are associated with Service Applications by means of a Service Application Proxy, which connects the two allowing the Web Application to use the Service Application. The associations between a Web Application and a Service Application can be changed at any time by administrators, and can be managed in groups (Service Application Proxy Groups).
Evolution of Shared Services Provider
In SharePoint 2010, the Shared Services Provider is replaced by separate Service Applications:
- User Profiles Service Application
- Search Service Application
- Excel Service Application
- Business Connectivity Application
- And all the new Service Applications in SharePoint 2010
This means that:
- Services are now independent, and don’t exist under the umbrella of the Shared Services Provider
- There is no more Shared Services Provider administration site, all the administration is integrated in the Central Administration site
- You can develop Service Applications and integrate them in SharePoint 2010
- When SharePoint 2007 is upgraded to SharePoint 2010, the services provided by the SSP are directly mapped to their respective Service Applications
SharePoint 2010 ships with around 20 out-of-the-box Services, and other products like Office Web Apps, Project Server and SQL Power Pivot also include Services. All these services are built using the same framework that is provided to extend this model, which is incorporated into SharePoint Foundation:
- Built-in support for scaling via multi-server support and load balancer
- Includes mechanism to host and deploy WCF-based Service Applications
- Includes Administration UI and PowerShell integration
- Includes Timer Job support
- Can be multi-tenant aware
Regarding Service Administration in SharePoint 2010:
- All the administration is performed in Central Administration or through PowerShell scripting. Each service plugs its management UI into the Service Management Page.
- The new association model is much more flexible than before, and allows each Web Application to use only the Services it really needs.
- The Service Application model incorporates software-based fault tolerant round-robin load balancing. There is, however, support for hardware-based load balancing and extensibility points for 3rd party components.
- Service Applications support cross-farm federation adding even more flexibility to its configuration. This allows a farm to provide services to other farms.
Farm Administrators can configure Delegated Administrators, which are users with Central Administration access that manage one or more Service Applications. Central Administration UI is security trimmed allowing Delegated Administrator to interact only with their managed Service Applications.
There are four pages dedicated to Service Application administration:
- Manage Service Applications page
- Create/Delete Services Applications
- Manage Service Application metadata
- Connect to remote Service Applications
- Publish and Secure Service Applications
- Service-specific management UI page
- Service Application specific settings
- Dashboard showing Service Application status (search crawl status, profile import status, etc)
- Manage Service Associations page
- Add/remove associations between Web Applications and Service Applications
- Manage Services on Server page
- Start/stop Service Instances on specific servers
The security model was improved:
- Inside the farm, services use claims-based authorization
- Between farms, services communicate via WCF-based web services
- There is support for SSL/Transport Security
The Service Applications can be isolated:
- Each Service Application uses a separate database and, optionally, a separate application pool
- Different Service Applications for a single Service can run under different accounts and use different databases
Security is managed per Service Application. There are two types of security:
- Admin Security
- Specifies who has admin rights over a Service Application
- Used for security trimming
- By default, all Farm Administrators are included
- Access Security
- Specifies claims that have access to the service
- By default, the farm claim has access
- Some services might require more granular access rights
Service Application Deployment
The configuration of the Service Applications can be performed:
- Automatically, via Farm Configuration Wizard, which creates all Service Applications with their default settings.
- Manually, using the Central Administration UI (New Button in the Manage Service Applications page). This allows you to:
- Specify custom application pool, database location, service account
- Create Service Applications and their Service Application Proxies
Service Application Associations
By default, all Service Applications in a farm are associated with all Web Applications (through Service Application Proxies). This default association scheme can be changed so that associations are managed separately for each Web Application and Service Application.
Service Application Publishing
Publishing a Service Application makes it available outside the farm, where it can be discovered and consumed by remote farms. However, you still have to perform associations to give Web Applications access to the Services Application and cross-farm trust is required via certificate exchange.
- Simplest one
- All Web Applications are associated with all Service Applications
- Single farm
- Each Web Application is associated with only the needed Service Applications
- Some Service Applications are shared between different Web Applications
- There can be multiple Service Applications for a single Service, associated with different Web Applications, to ensure isolation
Shared Resource Farm
- Multiple farms
- One farm contains all the Service Applications and publishes them to be consumed by Web Applications in other farms
- The other farms contain only the Web Applications which consume the published Service Applications of the first farm