The Service Application Framework (SAF) in SharePoint Foundation 2010 was designed with specific goals in mind:
It should provide the benefits of the MOSS 2007 Shared Service Provider (SSP), such as a unified service management experience, without some of its restrictions, such as having to either consume all MOSS 2007 services from a web application, or none of them.
And, it should be flexible enough to provide these benefits to virtually any middle-tier service, whether pre-existing or built from the ground up on SAF.
To that end, SAF is designed around an abstract model of service providers and consumers. This abstract model provides the hooks that SharePoint uses to provide a unified management experience for a large variety of services.
Services that implement this model may be integrated with SharePoint features such as the Farm Configuration Wizard, the “Services on Server” and “Service Applications” management UX, and SharePoint backup/restore, to name a few.
For more information information on service application integration points, see the Service Application Framework Overview topic in MSDN.
Developers interested in integrating custom middle-tier services with SharePoint should become familiar with this abstract model, as it is core to understanding the remainder of the Service Application Framework.
IT Pros may also be interested in the model as it pertains to the service application management experience.
NOTE: It’s important to clarify that SAF is designed for “middle-tier” services, as opposed to “front-end” services. By “middle-tier” service, I mean a service that is consumed by servers in a SharePoint server farm.
A middle-tier service is not part of a SharePoint web application or site, and is not directly accessed by end users. It is typically accessed from a Web Front End server (WFE) on behalf of an end-user request.
For example, the “Search Box” web part executing on a WFE invokes a middle-tier “Search Query” service application to retrieve raw search results, which are then rendered to HTML by the web part.
SharePoint does support front-end web services, but that is not an SAF feature—it’s a SharePoint web application feature.
Review: Topology Object Model
Before diving into the SAF object model, a quick review of the SharePoint topology object model is in order:
SharePoint groups servers into a logical unit called a server farm.
A configuration database (config db) is created for each server farm.
A SharePoint configuration database contains a hierarchy of configuration objects, which all subclass the abstract SPPersistedObject class.
All servers in a given SharePoint server farm connect to the same config db to discover the server farm topology.
The following configuration objects represent the SharePoint server farm topology:
The SPFarm class represents a SharePoint server farm. It is the root of the configuration database hierarchy.
Every SharePoint config db contains an SPFarm object that represents the “local” server farm which is created when the config db is created.
The SPServer class represents a single server in a SharePoint server farm.
When SharePoint is installed on a server, it is “joined” to a server farm, which means that a new SPServer object is created and stored in the server farm config db.
Service Application Object Model
The SAF service application object model extends the topology object model with additional configuration object types. Each type represents a concept in the service application model. These types are logically split into two groups: client (consumer) types and service (provider) types.
Developers may choose to implement all of these types, only client types (for example, to connect to a non-SharePoint service), or only service types (for example, to create a service that performs a background task).
The SAF service types are SPService, SPServiceInstance, and SPServiceApplication.
The SPService class represents a service that has been registered in a SharePoint server farm.
A custom SPService may be installed by a SharePoint solution or a custom MSI, and registered when a server farm administrator activates a SharePoint farm-scoped feature or executes a PowerShell script.
SPServiceInstance (Service Instance)
The SPServiceInstance class represents a service (SPService) that has been installed (but not necessarily started) on a specific application server (SPServer) in a SharePoint server farm. An SPServiceInstance has a Status property that indicates whether or not the service instance has been started.
An SPServiceInstance is typically registered in the offline (stopped) state on each machine in the server farm when the SPService is installed. A server farm administrator may then choose on which machines to start the SPServiceInstance using the SharePoint Central Administration site (the “Services on Server” page) or PowerShell (the Start-SPServiceInstance cmdlet).
NOTE: Some services may not execute on application servers. These are called “in-process” or “in-proc” services, because they execute in the same process as the service consumer. “In-proc” services typically do not register SPServiceInstance objects with SharePoint, so administrators do not have the option to start and stop these services on individual servers.
SPServiceApplication (Service Application)
The SPServiceApplication class represents a logical service endpoint (to which a service consumer connects).
The word “logical” describes the fact that this endpoint may actually consist of many physical endpoints; that is, the service application may be hosted on many application servers for additional reliability and scalability. These physical endpoints are represented by online (started) SPServiceInstance objects.
Those familiar with the concept of a SharePoint Web Application (SPWebApplication) may find it helpful to think of a Service Application (SPServiceApplication) as the equivalent of an SPWebApplication for application servers. In the same way that a single SPWebApplication may be hosted on many web front end (WFE) servers, a single SPServiceApplication may be hosted on many application (App) servers.
NOTE: SPServiceApplication endpoints are hosted by all online (started) SPServiceInstance objects for a given SPService. SAF does not currently model service applications that run on a subset of the online app servers hosting a service.
The SAF client types are SPServiceProxy and SPServiceApplicationProxy.
SPServiceProxy (Service Proxy)
The SPServiceProxy class represents a service consumer (client) that has been registered in a SharePoint server farm.
A custom SPServiceProxy may be installed by a SharePoint solution or a custom MSI, and registered when a server farm administrator activates a SharePoint farm-scoped feature or executes a PowerShell script.
SPServiceApplicationProxy (Service Application Proxy)
The SPServiceApplicationProxy class represents a logical connection to a service application.
An SPServiceApplicationProxy object may be used by many consumers, such as web parts, to invoke a service application.
This class may be used to encapsulate (hide) the details of communicating with a service application, such as low-level communication protocols, from consumers. However, in the most abstract sense it represents only the information necessary to connect to the service application, e.g., the service application address.
SAF provides a flexible abstract service model that can be extended to integrate custom middle-tier services with the SharePoint management experience.
This abstract model is represented by five (5) configuration object types: SPService, SPServiceInstance, SPServiceApplication, SPServiceProxy, and SPServiceApplicationProxy.
Understanding this abstract model is key to the task of integrating services with SharePoint and is a prerequisite to understanding the remainder of the SAF components built on these core concepts. It should also be helpful to SharePoint administrators who want a deeper understanding of how services are managed “under the covers” in SharePoint.