Services Hierarchy of Microsoft SharePoint Foundation
Applies to: SharePoint Foundation 2010
The Microsoft SharePoint Foundation object model can be usefully divided into three hierarchies. This topic discusses the Services Hierarchy, which includes classes that represent Web services, Windows services, other types of services, and instances of services.
For a discussion of the entities that are represented by the classes in the hierarchy, see Background: Service Entities in Microsoft SharePoint Foundation.
The Physical Objects Hierarchy; which includes classes that represent physical entities, such as servers and files, and containers of such entities, such as farms and folders; is discussed in Physical Objects Hierarchy of Microsoft SharePoint Foundation.
The third hierarchy, the Content Hierarchy, includes classes that represent publishable items of data, such as list items. There are also classes that represent nested containers of data, such as lists, content databases, Web sites, collections of Web sites, and groupings of site collections called Web applications. This hierarchy is discussed in Content Hierarchy of SharePoint Foundation.
These hierarchies overlap in the sense that some classes cannot be easily categorized and can be regarded as belonging to more than one hierarchy.
The Services Hierarchy
The classes in this hierarchy represent services, instances of services, and configured farm-scoped instantiations (CFSIs) of services.
Figure 1. The Services Hierarchy
Only public classes are depicted in the figures of this topic.
A SharePoint Foundation service is represented by a class that inherits from SPService. Several such classes are already in the object model, and you can derive new classes from SPService and some of its derived classes.
Figure 2. Services inheritance tree (solid borders indicate sealed classes)
Aside from what it inherits from SPPersistedObject, SPService provides members that get information about the jobs the service is performing. Each of the derived types provides additional functionality relevant to its particular type.
If a service implements the Service Application Framework, then the SPService object has an Applications property that holds all the CFSIs of the service that are running on the farm. A CFSI of a service is represented by an object of a class that inherits from the SPServiceApplication class. There are some classes that are derived from SPServiceApplication already in the object model and you can derive new classes from SPServiceApplication and one of its derived classes.
Figure 3. CFSI inheritance tree (solid borders indicate sealed classes)
Aside from what it inherits from SPPersistedUpgradableObject, its members primarily hold settings for provisioning and access rights to the CFSI.
Every SPService object has an Instances property that holds all the instances of the service that are running on various servers in the farm. The instances that host a particular CFSI are held in the ServiceInstances property of the SPServiceApplication object that represents the CFSI. No more than one instance of each CFSI runs on any one server, but a given service can have multiple CFSIs and they can run on the same servers. Moreover, a given CFSI (and, thus, a given service) can run on multiple servers in which case each server has its own actual instance (a running process) of the CFSI. If the service has no CFSIs, then it still has instances on each server on which it runs, but there can be no more than one instance of such a service on a given server.
Each actual instance can be thought of as both an instance of the service and an instance of one of the service’s CFSIs, if there are any. Each instance is represented by an object of a class derived from SPServiceInstance.
Figure 4. Service instance inheritance tree (solid borders indicate sealed classes)
In addition to what it inherits from SPPersistedObject, SPServiceInstance provides members for starting and stopping the service on the server. Each of the derived types provides additional functionality relevant to its particular type.
The SPLoadBalancerServiceInstance class is not used by the farm's load-balancing software or hardware, nor does it represent an instance of the Application Discovery and Load Balancer Service (see Background: Service Entities in Microsoft SharePoint Foundation). It is a base class that developers can use, along with SPWindowsService, to develop load-balanced document conversion services, such as a service that enables end users to view a PDF document as HTML.
The following diagram shows the relationship between the major base classes of the Service Application Framework of SharePoint Foundation. Solid arrows point from a parent class to the kind of child class held in a collection property of the parent. The dotted arrow indicates that the SPServiceInstance class represents a running process on a server that "instantiates" in a sense a farm-wide service represented by the SPService class. For more information about these relationships, see Background: Service Entities in Microsoft SharePoint Foundation.
Figure 5. Class relationships in the Service Application Framework
You can create new Windows services and Web services. For more information about Windows service development, see Services. For information on developing a Web service that implements the Service Application Framework of SharePoint Foundation, see Service Application Framework.