The Services Hierarchy of Windows SharePoint Services
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
The Windows SharePoint Services 3.0 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 Windows SharePoint Services.
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 The Physical Objects Hierarchy of Windows SharePoint Services.
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 The Content Hierarchy of Windows SharePoint Services.
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 and instances of services.
Figure 1. The Services Hierarchy
A Windows SharePoint Services service is represented by a class that inherits from SPService. Eight such classes are already in the object model, and you can derive new classes from SPService and two of its children.
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.
Every SPService object has an Instances property that holds all the instances of the service that are running on various servers in the farm. No more than one instance of each service runs on any one server, but some services have multiple instances, each one running on a different server. Each instance is represented by an object of a class derived from SPServiceInstance.
Figure 3. 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. 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.
You can create new Windows services and Web services. For example, a Windows service that scans documents for viruses would be a nice addition to a Windows SharePoint Services deployment. (For more information about Windows service development, see Services.)