Background: Service Entities in 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.
This topic describes the service entities in Windows SharePoint Services 3.0. These entities are modeled by the higher level classes in the The Services Hierarchy of the Windows SharePoint Services object model. For background information about the physical and content entities in a Windows SharePoint Services deployment, see Background: Physical Objects in Windows SharePoint Services and Background: Content Entities in Windows SharePoint Services.
Applications and Services
The terms "application" and "service" in software have varying meanings; but an application is most frequently taken to be a large program that has a UI and a wide variety of functions. The common denominator of those functions can usually be expressed only with a very broad phrase such as "word processing" or "spreadsheet analysis." Also, applications provide a lot of end-to-end functionality. For example, a word processor can help an author from blank page through writing successive drafts, formatting, inserting graphics, managing reviews, and final publication of a file as, say, an XPS document. A spreadsheet application can support every stage from data insertion to mathematical-function construction and on to final report publication.
By contrast, a service provides a very narrow range of functionality that usually does not include end-to-end functions that are valuable in themselves. But the functionality that the service provides is valuable as a component part of a variety of applications. Services typically run invisibly and have little or no UI. They wait in memory until an application calls them. The Windows Print Spooler is an example of a service that can be called by any application that has to print a file.
A Windows service is any service that is hosted by the operating system and is available to locally running applications. A Web service is a service that is hosted on a network server and can be accessed by applications, such as browsers, running on remote clients.
Services in Windows SharePoint Services
Windows SharePoint Services includes several Windows and Web services.
**Web Services **
Content Publishing This service makes the data and Web pages available to browsers. It runs on the front-end servers and is the most important service in Windows SharePoint Services. (For more information about front-end servers, see Background: Physical Objects in Windows SharePoint Services.)
The names of Windows SharePoint Services services begin with "Windows SharePoint Services", followed by the name of the kind of thing that is "served up" by the service. Thus, there is a "Windows SharePoint Services Database" service and a "Windows SharePoint Services Web Application" service. But remember that the former is not itself a database, it is a service providing database access. Similarly, the latter is not a Web application. It is a service providing content publishing of Web applications.
Central Administration The content of Central Administration is its own Web application so that it can have its own process and its own security policy. (For more information about Web applications, see Background: Content Entities in Windows SharePoint Services.) This Web application is supported by its own Web service also. This service ordinarily runs on a front-end server only in a single server deployment. In other deployments, it runs on one and only one application server. (For more information about application servers, see Background: Physical Objects in Windows SharePoint Services.)
Windows Services These services appear in the list of Services in the Control Panel of the server. Because these services have a presence in the UI of Windows SharePoint Services and use the object model of Windows SharePoint Services, administrators and developers can start, stop, and manage the services without having to use the Control Panel.
Administration In a farm deployment, this special service is used by Windows SharePoint Services to perform privileged operations on behalf of the administrator on all front-end servers and application servers in the farm.
Timer This service enables administrators to set jobs to run at specified times. It runs on all front-end servers and application servers.
Search This service enables searching of the content in a Windows SharePoint Services deployment. On a multiserver farm, it runs on one or more application servers.
Database This is really a kind of wrapper around the already installed SQL Server Windows service. It enables the Windows SharePoint Services objects to access to the content and configuration databases. In a multiserver Windows SharePoint Services deployment, the server that is hosting a database is usually the only one that is running this service.
Windows SharePoint Services also provides three services that do not fit neatly into the categories of Windows service and Web service:
A Diagnostics service that runs on all front-end servers and application servers.
An Incoming e-mail service that typically runs on only one application server.
An Outgoing e-mail service that typically runs on only one application server.
These last three services mainly hold configuration settings.
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.)
Here are some concrete examples of Windows SharePoint Services 3.0 deployments. First, Figure 1 shows the major objects in the Windows SharePoint Services object model hierarchy immediately after Windows SharePoint Services 3.0 is installed on a single server.
Figure 1. Services, service instances, and Web applications on a new single server deployment
Figure 2 shows the services and service instances on a hypothetical 10-server farm. Note the following things about this example:
The translucent rectangles represent services. These services are modeled in the Windows SharePoint Services object model with SP*Service classes.
The smaller, solid rectangles represent instances of services that are modeled in the Windows SharePoint Services object model with SP*ServiceInstance classes.
The Diagnostics Service does have instances running on all servers (except the dedicated database server), but the object model has no SPDiagnosticServiceInstance class (because there is no need for one in Windows SharePoint Services 3.0), so there are no sold rectangles for these instances.
The Administration, Timer, and Diagnostics services run on all servers (as they must), except the dedicated database server.
Only the five front-end servers run the Web Application Service.
This hypothetical farm has a moderate amount of content but intensive search needs, so three application servers run the Search Service. Each of the Search servers crawls and indexes a different subset of the farm's contents.
A fourth, multipurpose application server runs Central Administration and the e-mail services.
When the Windows SharePoint Services databases are on a dedicated server, as in this case, Windows SharePoint Services need not be installed on that server. The Database Service is just a wrapper for the SQL Server service running on the database server. Hence, Windows SharePoint Services code is not running on the dedicated database server. The service and its instance appears in the figure because it is represented in the object model with the SPDatabaseService and SPDatabaseServiceInstance classes.
Figure 2. Services and service instances on a typical 10-server farm