SharePoint 2010: #SPC09 - SSP is dead, long live Service Applications!
Notes from the SharePoint Conference 2009 session "Introduction to Service Applications and Topology". This is my personal interpretation of what has been said during the presentation. Don't shoot me if I interpreted something wrong:-)
In SharePoint 2010 Shared Service Providers (SSP's) are replaced by Service Applications. Services are no longer combined into a SSP. Services are running independent as a service application.
So in MOSS 2007:
SSP: combines services like Search, Excel Services, User Profiles, ... into a shared service provider.
In SharePoint 2010:
Service Applications: services like Search, Managed Meta Data, .., your service (20 services in SharePoint Server) are running "unboxed" and independent.
So SharePoint 2010 provides a la carte unboxed services. You can configure which services are running on an application server. Per web application you can configure which services are consumed.
When migrating MOSS 2007 to SharePoint 2010 SSPs will upgrade into Service Applications.
SharePoint Foundation 2010 (WSS 4.0) provides the SharePoint Service Application Framework.
New products like Office Web Apps, Project Server, Gemini (PowerPivot) use this application framework, and this platform can also be used by third parties or you to create custom services.
You can plug your management UI for your service into the Service Management page.
A web application does not communicate directly to a service application, but does this through a proxy:
Web Application <-> Service Application Proxy <-> Service Application
So a general workflow can be:
Browser -> Web Front End ->(Request) Application Server ->(Result) Web Front End -> Browser
SharePoint 2010 does contain a fault tolerant round-robin software load balancer with support for hardware load balancing, so it is possible to have multiple application servers.
The Service Application infrastructure provides application isolation: each service application can use separate databases if needed and optionally run in separate app pool. There is support for multiple service apps for a service with different accounts and databases ==> Great for multi-tenancy (hosting for multiple customers on same platform)
Services are flexible, secure and provide cross-farm federation:
- Trust based security between farms, claims based authorization within the farm
- Share to anyone, consume from anywhere
- WCF based web services for communication
- No direct DB Access
Administration:
You can manage which services are running on a server.
In Central Administration UI: list of services, indented under a service you see the proxy.
Through the wizards you get database names with guids at the end. Better to create manually form Central Administration, or create services through PowerShell.
Per web application you can configure which services apps you want to be available. By default all web applications use all service applications available. You can change this into a custom configuration. Use the Manage Service Associations page for this.
Service applications can be published to make them available outside the current farm. It allows you to select the connection type, for example https or net.tcp. Note that there must be a trust relationship with the farm that wants to consume your service. The service is published on a url. Through this url an other farm can find the published services. Url is in the following format: https://myfarm/Topology/topology.svc
The other farm can connect to your farm through a remote service connection.
Although manual adminstration and configuration of SharePoint 2010 can be done through Central Admin, the future of SharePoint administration is PowerShell.
With respect to Services:
Get-SPServiceApplication returns the set of service applications.
Do Get-SPServiceApplication-name yourservice to get the service object. Do Get-SPServiceApplication -name yourservice | fl to see all properties of the service object.
There are almost a hundred Cmdlets to manage your services.
Side note: It now really becomes time that all administrators learn PowerShell. In my company (Macaw) we use PowerShell extensively for our Macaw Solutions Factory. Everything from configuration, build and deploy through DTAP is done with PowerShell.
It is possible to delegate management of a particular service to someone, that person then has only access to that the management UI in Central Administration for that particular service.
Access security: specified claims principals have access to a service application. By default the "farm claim" has access, but this can be removed ad more detailed claims can be configured for more granular access rights, or example read versus read-write.
Service applications can spawn their own timer jobs.
Generally ISV's will build service applications on the SharePoint Service Application Framework, but for large organizations it could be interesting for SI's to create services to specialized functionality and farm-to-farm fedaration .
For repeatable configuration over your DTAP configuration, use PowerShell to create and manage the services.
You can create complex farm configurations where farms can share service applications. For example: two farms can share the user profile service.
