In this article I want to describe Service applications in SharePoint 2010. Sharepoint 2010 service application is to replace SharePoint 2007 SSP (Shared Service Providers). Provide much more flexibility in terms of deployment, management, topology and capabilities.
Service Applications are actually nothing more than a logical concept. There is actually no such thing as a “Service Application”. The term is chucked around all over the shop and is destined to become as ubiquitous and misleading as “Web Front End”. You can’t just blame marketing. In the lead up to RTM, many SharePoint “experts” have been playing buzzword bingo with the term and giving false information about them, and even more worryingly, how to build them.
Of course SharePoint wouldn’t be SharePoint if it didn’t have totally confusing administrative interfaces and inconsistency in terminology. Central Administration is perhaps the worst culprit here.
The bottom line is forget about “Service Applications” other than as a term to describe the model of deployment for shared services in SharePoint 2010. Again, it’s a logical concept or container, nothing more.
There are a number of components within a “Service Application”. They are:
1. Service Instance
This is the meat of the thing, it’s the implementation of the functionality provided. Application binaries. It could include Windows Services, configuration, registry settings etc. SharePoint assets could include timer jobs, services, management pages etc. These bits are deployed to every server in the farm when the install is performed. When PSConfig(UI).exe is run you will see the status: “Successfully installed Service Instance: name of service”. Different service applications of course will have a different variety of bits.
2. Service Machine Instance
This is the machine or machines in the farm that run the “service”. It is often referred to as a “SharePoint Service”. You configure this using Services on Server. More than one machine can run the Service Machine Instance and by default, software round robin load balancing is provided. You do not need to implement Network Load Balancing of any incarnation. Certain services will also provide their own software load balancing scheme (e.g. Excel Calculation Services). Not all service applications have an associated service machine instance. Some service machine instances can only be started on one server in the farm unless there are multiple service applications. Some Service Machine Instances have additional configuration.
Some “legacy” service machine instances exist, such as the Document Conversions Services, for which there is not an associated Service Application. In addition services such as the Claims to Windows Token Service and the Sandbox Code Service are just SharePoint wrappers for a Windows Service.
3. Service Application Endpoint
When you start a service machine instance for which there is an associated Service Application, an IIS Virtual Application will be created within the SharePoint Web Services IIS Web site. This will include the Service Application Endpoint (a WCF or ASMX). Each service application must expose a service application endpoint. The service application endpoint is only created on the machine(s) hosting the service machine instance.
4. Service Application
This is the logical container of the service, what is exposed through Manage Service Applications. It includes the management aspects of the service and configuration. When created the associated databases (if any) and configuration will also be created. The service application endpoint is not created until an associated service machine instance is started. There can be more than one instance of a particular service application.
Pages for managing the Service Application are hosted in Central Administration and are called using a GUID in the query string. Service Applications are global to the farm.
5. Service Connection (aka Service Application Proxy)
This is a virtual link between consumers (e.g. Web Applications) and the service. This is an interface for consuming applications and services that understands the load balancing scheme for a service and how to speak to the service machine instance(s). This is not a WCF proxy. The Service Connection also enables inter-farm services. Some Service Connections include settings which are specific to a given connection. The UI calls them Service Connections, but they are more commonly known as Service Application proxies – the term used by PowerShell.
6. Consumers
Consumers are any component that uses the service. Examples include Web Applications, a page, another service application, etc. All the consumer needs is a reference to the service connection.
Not all service applications are equal. This is SharePoint after all
1. Core
Service applications which are provisioned by PSConfig(UI).exe: Topology and STS, for which there is no or little configuration.
2. General Purpose
Service applications for which no associated service machine instance is exposed for configuration, such as the State Service.
3. Simple
Service applications that have relatively little configuration or moving parts, for example the Access Database Service or the Subscription Settings Service.
4. Medium
Service applications that have a relatively small amount of moving parts, such as the Managed Metadata Service.
5. Complex
Service applications that have a relatively complex amount of configuration and moving parts, such as SharePoint Server Search Service or User Profile Service (which have multiple Service Machine Instances).
Not all service applications are created, configured or managed in the same way. There is a ways to go in striving for this consistency and in some cases it is not prudent anyway.
As a general recommendation, the order of creation should be:
- Create the Service Application and Proxy
- Configure the Service Machine Instance
In some cases this order is enforced, in others it doesn’t matter.
