Compartir a través de

SharePoint Service Application Framework Object Model

  • Artículo

  • 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:

  •  

  • SPFarm (Farm)

  • 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.

  •  

  • SPServer (Server)

  • 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).

  •  

  • Service Types

  • The SAF service types are SPService, SPServiceInstance, and SPServiceApplication.

  •  

  • SPService (Service)

  • 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.

  • Client Types

  • 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.

  •  

  • Summary

  • 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.

Comments

  • Anonymous
    August 26, 2012
    Nice post, it's really help me!