In SharePoint 2010, Shared Service Providers (SSP's) are replaced by Service Applications. Services are no longer combined into a SSP. They run independently as a service application. The service application architecture is now also built into Microsoft SharePoint Foundation 2010, in contrast to the Shared Services Provider (SSP) architecture that was only part of Office SharePoint Server 2007.
A key benefit here is that all services are installed by default and there is no SSP setup.
The services architecture is extensible, allowing third-party companies to build and add services to the platform.
Services are managed directly in Central Administration (rather than a separate administration site).
Services can be monitored and managed remotely.
Services can be managed and scripted by Windows PowerShell.
Shared services communications take place over HTTP(S). Shared services do not directly access databases across farms.
Most new services are built on the Windows Communications Framework. They have optimization built into their protocol, using binary streams instead of XML for data transfer. Test results show improvements in network throughput with this change.
Advantages of Service Applications over SSP
The key limitation of the SSP architecture was that it was configured by using a set of services, and all web applications associated with the SSP bore the overhead of all the services even if they weren't being used. To change the service configuration for a particular Web application, a new SSP would have to be created.
The service application architecture on the other hand, allows a set of services to be associated with a given Web application and a different set of services to be associated with another Web application. Also, the same service application can be configured differently in different Web applications; therefore, Web sites can be configured to use only the services that are needed, rather than the entire bank of services.
One major advantage to this new architecture is the flexibility in scaling service applications up and out. Another advantage is that service application to other farms. To do this you simply install the service application's proxy in the other farm and point it to a specific URI provided by Central Administration when you publish the service application. This enables enterprises to have dedicated service farms that can be specially configured based on the services that are provided. They could then share these service offerings with other SharePoint farms in the enterprise or with customer farms.