The Old:
In MOSS 2007, additional services for Search, user profiles, the BDC (enabling connectivity to external data sources), and Excel Services were all bundled into a Shared Service Provider (SSP) enabling multiple Web Applications in the same SharePoint farm to consume these resources; all of these services would have the same configuration. Setting up a search instance with different Crawl Rules, or perhaps exposing different user profile properties, would require a Web Application to use a whole new SSP which would need to be separate from any other instances.
Shown below is a typical MOSS 2007 SSP offering:
The New:
In SharePoint 2010, Microsoft re-architected the SSP into Service Applications. These Service Applications provide the same resources that a SSP did previously, as well as some new ones. A Service Application has its own configuration and content storage databases, and runs independent of any other service that would have otherwise been bundled into an SSP. It is also much easier to expose any single Service Application to other SharePoint Farms. This new architecture provides more scalability, redundancy, portability, and a clear role definition between various servers in the SharePoint Farm.
Shown below is a sample Service Application List in SharePoint 2010:
Scalability/Redundancy:
In terms of scalability, you can control exactly which Service Application(s) will be provided each server, allowing a server’s resources to be better utilized. Another benefit is that you can quickly scale a Service Application to span multiple servers, and SharePoint will take care of round-robin style load-balancing automatically. This load balancing also allows for redundancy; if a server goes down, you haven’t lost all operating instances of Service Applications configured to run on multiple servers. Instances of the Service Application hosted on other servers will continue to be available.
The image below shows how you can pick a server, and start/stop services as desired:
Portability:
Portability of a Service Application is achieved allowing an Administrator to establish a connecting “proxy” between any Web Application and the Service Application you wish it to consume. This is called a Service Application Proxy. The Service Application Proxy enables one or more Web Applications, or code running within Web Applications to “know” how to communicate with a Service Application. You may also easily expose a Service Application for consumption across Farms, which allows for greater sharing of Physical resources combining a Service need from multiple Farms on a single server, or enabling less duplication of data / work allowing these other Farms/Web Applications to share the same Service Application and its data set. If you require multiple configurations, each Service Application may be configured in different ways as desired, and connected to whichever Web Application requires that configuration without the hassle of creating an entirely separate SSP. These configurations can be altered for each Service Application as needed, and the change will be in effect for anything with a Service Application Proxy connection to it. The “bundling” ability of these services is still available — however, now Administrators can choose on the fly which Service Application instances to add to an Application Proxy Group. After creating the Default Application Proxy Group, you can assign it to one or more Web Applications, or customize it for each Web Application as desired.
Shown below are available options for customizing the Application Proxy Group:
Clear Role Definition:
In the past, more often than not a SharePoint Farm server would run more services than needed. Now the granularity of services and better control of where these services will run allows Administrators to better designate each Farm member server specific tasks. Timer jobs associated with a specific instance of a Service Application will run on the specified server(s) and not take priority over jobs running for a different Service Application on a different server. It is also now easier to monitor resource bottlenecks and easily scale Service Applications across servers, as you can easily identify which servers are struggling to handle the present load. A better understanding of what function(s) a particular server will perform allows better capacity planning out of the gate, and fewer surprises later on when one server becomes an obvious weak link in the topology.
Shown below is a view of servers in the Farm, and which services they run:
The End:
Splitting the old SSP into Service Applications and allowing à la carte Service Application Proxy Connection Groups now provides administrators with greater flexibility and speed in creating a dynamic set of services for Web Applications to consume. This, in turn, allows for better hardware utilization, and helps ensure the performance and availability of these Services Applications, within the SharePoint Farm and beyond.
