This blog is to provide a quick ramp up on SharePoint 2010’s new Shared Service Architecture. Some new concepts are introduced and this is part 1 of a 2 part series on this topic. Part 1 is for describing the components and concepts that are behind this new model. Part 2 will discuss using Shared Services with multiple farms. Special thanks to Sheyi for the knowledge transfer as well as technical review.
Shared Service Basics
Shared Services are the replacement to SSP’s and provide greater flexibility in administering SharePoint. Shared Services have been built into WSS framework unlike its predecessor, SSP’s, which were built into the MOSS framework. In MOSS, the SSP was a one stop shop which contained several shared services like search, profile, excel services for example. This in itself caused a multitude of problems since it’s potentially a single point of failure for multiple services. Also, SSP’s weren’t as flexible when providing specific permissions to manage specific services within an SSP. SharePoint 2010 flattens an SSP so now each service is an independent entity. This will make more sense after reviewing the entire blog.
In SharePoint 2010, A Shared service is a component that does useful work. All Shared Service components are considered part of the Shared Services framework. For Example, Search is considered a shared service and profile is considered a shared service. The number of different shared services available in a farm is dependent on which SKU is used.
For Example: Search Service Application and Profile Service Application comes with SharePoint 2010 Standard and Enterprise SKU. Performance Point Service Application and PowerPoint only comes with SharePoint 2010 Enterprise SKU.
Service Applications
In order to use a Shared Service, a Service Application must be provisioned. A Service Application is a farm level instance, “logical instance”, of a Shared Service. A Service Application consists of the following:
· Administrative interface (Admin Page to manage the associated service application)
· Application Pool
· Database\Databases
· Physical Instance (Actual running process\Web Service running on a physical machine)
Note: Not all Service Applications are the same. Each one is unique and may or may not contain the above components listed.
For Example: SharePoint OOB comes with Excel Shared Service. Until you deploy and create a service application, you cannot consume that shared service.
Service Applications can be provisioned automatically using the Farm Configuration Wizard or manually by using Central Administrator\Manage Service Application page. Power Shell can also be used to create Service Applications.
The following example describes manually provisioning a Service Application using Central Administrator:
1. Create via Service Application Page
2. Creates Excel Proxy and Excel Service Application
3. Note: This will “NOT” start the associated SharePoint service which means the WCF web service will not be created.
4. Start the Excel services from services on server page which will create a physical instance, “web service”
Step 3 deserves some further explanation. After starting a service on a specified server, a virtual directory and corresponding web service is provisioned. Within IIS, all web services reside within the Shared Web Services website.
For Example:
This is not very intuitive as each virtual directory contains a long GUID. Right click and explore each virtual directory will display the associated web service.
For Example, exploring virtual directory 81dfd03d65544035aa193db1a1fcdc98:
SharePoint 2010 has moved away from asp.net web services (ASMX) to WCF web services (SVC).
Note: All web services reside under the following directory by default:
C:\Program Files\Microsoft Office Servers\14.0\WebServices\
Redundancy Built-in
Multiple application servers can run a physical instance of the same Service Application. This is accomplished by running step 3 above on more than one application server. This provides redundancy in that requests from WFE’s pass through a built in load balancer to locate available application server running a physical instance.
For Example: Two application servers are running the same Excel Service application. If one application server goes down, the built-in load balancer will detect it and future request to Excel Service Application will be directed to application server that is still up and running with the associated physical instance.
Service Application Proxy
Service Applications have a corresponding Service Application Proxy. A Service Application Proxy is an object that a service consumer (web part) uses to connect to a Service Application. A consumer could be considered a web part, OM, or internal code. A web application has no idea how to communicate with a Service Application without a Service Application Proxy.
For example, provisioning a User Profile Service Application looks like the following within Central Administrator\Manage Service Applications page:
Many parts working together
To see how this works together I like the example of running a query from a Search page on a WFE.
Search query is performed and WFE’s search web part talks to service application proxy which uses WCF to connect to Server running physical instance of Service Application on application server. The application server talks to a database. Results are returned from Application Server to WFE and displayed for user whom submitted the query.
Consuming Service Applications in a Single Farm
A SharePoint administrator now has more control over which Service Applications are deployed. For example, if the only requirement is search, only a Search Service Application is deployed. If a SharePoint Administrator wants all 18 Service Applications, that Administrator can provision\deploy all of them. By default, Service Application is consumed at the Web Application level. A single web application can consume multiple search shared services. A single shared service can be consumed by multiple web applications. This is controlled through the use of Service application Proxy Groups. Proxy Groups create mappings between service applications proxies and the web applications that consume them. When a new farm is provisioned, a default proxy group called default is created. Service application proxies are added to this proxy group by default. Proxy Groups are created using PowerShell via the new-spserviceapplicationproxygroup cmdlet. Changing or Adding service applications to proxy groups is possible through using add-spserviceapplicationproxygroupmember cmdlet within PowerShell.
When provisioning a web application, a service connection field provides the ability to specify which proxy group that web application is mapped to.
By default, a web application will only consume service applications that are associated with that particular proxy group. In the screenshot above, proxy group DanCan contains the Excel Service Application2 proxy.
This is extremely flexible so for example:
Proxy Group: DanCan
Service Application Mapping: Search Service Application 1
Web Application: http://ContosoWebTeam
Proxy Group: DQBlizzard
Service Application Mapping: Search Service Application 2
Web Application: http://ContosoHRTeam
All users performing searches from Web Application ContosoWebTeam will only pull search results from Search Service Application 1. All users performing searches from Web Application ContosoHRTeam will only pull search results from Search Service Application 2.
A Web Application isn’t forced to consume all service applications within assigned proxy group. If web application is connected to a proxy group containing 10 Shared Service Application proxies, it’s possible to consume a variable # of Shared Service Applications. It’s up to the Administrator and this is configurable via Central Administrator\Application Management\Configure Service Application Associations. The following screenshot displays a web application ContosoHRTeam associated with DanCan proxy group. DanCan proxy group contains two Application proxies:
A SharePoint administrator no longer wants ContosoHRTeam web application to consume Excel Service Application2.
You can accomplish this in two ways:
1. Modify Proxy Group Membership
To modify proxy group membership, simply select the proxy group name and uncheck the unwanted Service Application. For Example, SharePoint Administrator wants to drop Excel Service Application2 from DanCan Proxy group:
In the above example, Excel Service Application 2 is unchecked so any web applications consuming this proxy group will no longer be associated with Excel Service Application 2. This may not be desirable if multiple web applications are consuming from DanCan proxy group.
2. Modify Service Application associations on Web Application
From the configure service application association page, select the Web Application and choose custom:
Uncheck Excel Service Application 2. This is useful when you only need to change service application associations on web application level. With this method, DanCan proxy group membership is maintained. Also, this provides the SharePoint administrator the option of consuming multiple service applications that span proxy groups.
Rules
Some additional rules to be aware of:
1. A web application can only map to one proxy group by default
2. A service application can map to one or more proxy groups. Another way of saying multiple proxy groups can contain the same service application proxy
3. A proxy group can contain multiple service applications of the same type. So it’s possible to have two Excel Service Applications reside in the same proxy group.
Note: This deserves some explanation. By having multiple service applications of the same type reside in the same proxy group doesn’t mean a web application will consume from both. Only one will be marked as default and used. Changing which service application is marked as default is possible through Manage Web Application\Service Connections. Within Configure Service Application Associations, set group of connections to custom and set preferred service application as default.
4. Multiple Web Applications can map to the same proxy group
5. A Web Application can consume Service Applications from multiple proxy groups when custom is specified.
Part 2 will focus on service provisioning setup\consumption across multiple farms.
Thx,
Russmax, MSFT