The Physical Objects 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 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.
Important
For a discussion of the entities that are represented by the classes in the hierarchy, see Background: Physical Objects in Windows SharePoint Services.
The Content Hierarchy; which includes classes that represent publishable items of data, such as list items, and 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; is discussed in the The Content Hierarchy of Windows SharePoint Services.
The third hierarchy, the Services Hierarchy, includes classes that represent services and instances of services. This hierarchy is discussed in The Services Hierarchy of Windows SharePoint Services.
Note
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 Physical Objects Hierarchy
The classes in the Physical Objects hierarchy represent entities that are either actual physical objects or objects that, depending on the context, can be regarded either as physical objects or as non-physical. The four major classes in the hierarchy are shown in Figure 1.
Figure 1. The Physical Objects hierarchy
.gif)
The SPFolder and SPFile classes are not discussed in this article; but to avoid misunderstanding, notice that the entity represented by an SPFolder object or an SPFile object might be located in a Windows SharePoint Services content database instead of in the file system of a server. For example, a spreadsheet file in a Windows SharePoint Services document library is stored in a cell of a database, not in a folder on one of the servers.
SPFarm
A Windows SharePoint Services farm is represented by the SPFarm class. A server farm is a cluster of physical servers that includes one or more front-end servers, zero or more application servers, and an SQL Server that may be hosted on a dedicated database server or on one of the application servers (or on a front-end server if there is only one of those). (Strictly speaking, a Windows SharePoint Services 3.0 deployment is always hosted on a farm, although it may be a "farm" with just a single computer that contains the whole deployment.)
These are some of the characteristics of the SPFarm class:
The SPFarm class represents a farm of one or more physical servers, so it is included in the Physical Hierarchy. But it can also be considered the top level of the Content Hierarchy; for example, all the (non-configuration) content of a Windows SharePoint Services farm can be backed up and restored.
Note
In Windows SharePoint Services 3.0 the configuration database of a farm cannot be restored. It can be backed up and this may be useful as a snapshot of the database that can be compared with the current state of the database for troubleshooting purposes.
In Windows SharePoint Services 3.0, the SPFarm class can also be thought of as representing the configuration database that is associated with the farm because Windows SharePoint Services 3.0 has no class that represents the configuration database itself. For example, the DisplayName property of an SPFarm object is also the name of the configuration database.
An SPFarm object has three major types of child classes: SPServer, SPService, and SPSolution.
SPFarm inherits from SPPersistedObject, which means that the object (there is only one) that instantiates the class persists in the configuration database.
SPFarm has static members for creating farms and returning references to the local farm or a remote farm.
SPFarm has many members that can be used for developing administration functionality. Some of the more important members can help in the administration of the following:
Backup and restoration of the farm
Upgrades of the farm
Migration of (moving) the farm
Error reporting
Caching
SPServer
A physical server in a Windows SharePoint Services farm is represented by the SPServer class. In addition to many inherited members, it has an Address property that holds the IP address of the server and a Role property that identifies the server's role in the farm. If there is just one server, its role is SingleServer. If there is more than one, the front-end servers have the role WebFrontEnd and almost all other servers have the role Application. However, the Role property of a server that is physically hosting a Windows SharePoint Services content database typically has the value Invalid. This is because such servers typically run only one Windows SharePoint Services service—the Database Service (which is a Windows service)—and this database service is really just an alias for the SQL Server Windows service which is not part of Windows SharePoint Services. Hence, it is not really running any Windows SharePoint Services code, and it does not really fit into the Application role. For more about applications, roles, and services, see The Services Hierarchy of Windows SharePoint Services and Background: Service Entities in Windows SharePoint Services.
The SPServer class also has a ServiceInstances property that holds references to all the instances of Windows services and Web services that are running on the server. For more information about service instances, see The Services Hierarchy of Windows SharePoint Services and Background: Service Entities in Windows SharePoint Services.
SPServer inherits from SPPersistedObject. Objects that instantiate SPPersistedObject persist in the Windows SharePoint Services configuration database.
See Background: Service Entities in Windows SharePoint Services for graphic showing a typical farm and its servers.
See Also
Reference
Concepts
Server and Site Architecture: Object Model Overview
Working with List Objects and Collections
Overview: Using the Object Model to Customize Administration
Code Sample: Using the Administration Object Model
The Content Hierarchy of Windows SharePoint Services
Background: Content Entities in Windows SharePoint Services
Background: Physical Objects in Windows SharePoint Services
The Services Hierarchy of Windows SharePoint Services
Background: Service Entities in Windows SharePoint Services
Other Resources
The Administrative Object Model of Windows SharePoint Services 3.0
Windows SharePoint Services Administration
Windows SharePoint Services Administration Development Resource Center