SharePoint Architecture – Introduction to SharePoint Services

One of the more commonly heard phrases in SharePoint community is perhaps “Service Applications”. The phrase typically pops up in conversations related to SharePoint deployment and planning, and sometimes in conversations related to application development. Most often, this is associated with words like “Managed Metadata Service” or “Search Service” or “User Profile Service”. In the days of SharePoint 2007, there used to be other words in the mix – such as “Shared Services” instead of “Service Applications”. I am hoping with this post I am able to explain the concepts, the architecture and, hopefully, the internal implementation details for the service application model that has been built into SharePoint 2010 and SharePoint 2013.

In traditional applications of SharePoint’s nature, it is customary to abstract away the business logic and the computationally intensive sections of code into a separate “tier”. This tier is typically built as a set of SOAP based web services or WCF services that other tiers, such as the user interface components (web parts, application pages, web controls), interact with to work with the underlying data structures. A discussion on why this is necessary in cases like SharePoint, or the fundamentals and theory behind building these services is out of scope of this article, although, it will suffice to say that such a design helps a lot with scalability, adaptability and overall reliability of the system. I am expecting that the reader is already aware of the underlying concepts of SOAP and WCF. If not, this would be a good time to brush up on those skills since SharePoint 2010 the upcoming 2013 version, and possibly the future versions, will be built based on such designs.

Before we get to the core of “Service Applications”, we will take a look at the fundamentals of services, in general, within SharePoint. Service Applications are merely specializations of the fundamental service model designed as the base for all types of services that are deployed and used by SharePoint at runtime.

Types of Services

SharePoint, as a part of it’s deployment and configuration, deploys three types of services – Windows services, IIS based web services, and “other” services. An ISV, when developing and deploying their SharePoint solution may choose to extend any of the above types of services and deploy it to the farm as a part of their solution deployment. We will delve into details of implementing our own custom services for SharePoint in a later article. For now, we will focus on the architecture and design of the services within SharePoint using examples of implementations that come out of the box with SharePoint.

As with any other well defined model, the services side of SharePoint also implements layers of abstraction, with final implementations being very specialised forms of services.

The Base Implementations

At the base of all of this is the very abstract and basic concept called a “SharePoint Service”. A service can be deployed to a farm from where an administrator may choose to host it on a specific server, or more than one, if the requirements demand it, within a SharePoint farm. In SharePoint’s code base this is represented and specified as a type called SPService.

A service may have several instances within the farm. An instance can be best defined as an active service provisioned to one or more servers in the farm. A service instance is created when a farm administrator clicks on the “Start” link associated with a service in the “Manage Services on Server” link. Some services, such as “SharePoint Timer Service”, are instantiated during SharePoint installation time and cannot be started directly from this screen. To see those types of services, choose the “All” view in this screen. A screen grab of this particular screen is attached below.

services_on_server

Within SharePoint’s code base this is represented and specified as a type called SPServiceInstance.

Windows Service

Although the term Windows service may confuse the reader with services that form a part of the Windows operating system itself, here the term is used to represent a SharePoint service that interacts with the operating system at some level. This is not a hard rule, mind you. However, majority of the services configured by default within a SharePoint farm and which interact with the base operating system is implemented as a Windows service.

In SharePoint’s code base a Windows service is represented and implemented as a type called SPWindowsService. The service instance for SPWindowsService based services are implemented from a type called SPWindowsServiceInstance.Some examples of Windows services configured by default within SharePoint are the SharePoint Timer Service, the Database Service, or the Claims to Windows Token Service.

IIS Web Service

IIS Web Services are the most commonly found services and, probably, the most widely implemented customisations in SharePoint solutions space. IIS Web Service provide the flexibility of a SharePoint service that can be scaled out like any other service, as well as ISVs being able to use their existing WCF / Web service development skills to create a full fledged service for their SharePoint solutions.

While all types of services can provide client access libraries to consume their functionality, support for IIS based web services is expansive within SharePoint code base. Hence you will find a lot of widely used services, such as Managed Metadata Service or User Profile service, are built as IIS Web Service.

In SharePoint’s code base an IIS Web Service is represented and implemented as a type called SPIISWebService. The service instance for SPIISWebService based services are implemented by sub-classing SPIISWebServiceInstance type. We will discuss these two classes when we delve deeper into SharePoint Service Application architecture.

Other Service Types

While “SharePoint Windows services” and “SharePoint IIS Web Services” are the most prominent ones for implementation and extensions, there are other types of services which do not follow these abstraction layers and are specialised services performing very specific tasks within SharePoint. These types of services are deployed during SharePoint farm configuration and consumed within SharePoint code base for various purposes.

The most important, and well known, of these types of services is the SPWebService. The term does not imply an IIS Web Service or an ASP.NET web service, instead this is a VERY important service hidden away from developers, but available when called upon. Whenever, an administrator creates a SharePoint web application, this is the service that manages provisioning of the web site to IIS on all WFEs. You can see this service in “Manage Services on Server” page on Central Administration, with the title “Microsoft SharePoint Foundation Web Application”. The service is always started on WFEs. Although, you may stop this service on servers, please note that many other services rely on a fully functioning instance of this service to function correctly. The service instances of this service is represented in the code behind as SPWebServiceInstance and is responsible for deploying web applications and existing SharePoint Farm Solutions to a WFE that has joined a farm.

A Usage Example

To understand how the services are deployed and used within SharePoint, we will need to dig a bit deeper into the internals of SharePoint code base – especially the objects within the Microsoft.SharePoint.Administration namespace.

For this example, we will take the case of SPWebService and SPWebServiceInstance – which are probably the most vital, and important to the functioning of a SharePoint farm.

The illustration below is a typical deployment scenario for any service.

image

 

 

Every service that is deployed within SharePoint may have one or more instances of it running in different servers within a farm. In the above example, when SharePoint was first configured in the farm, an instance of SPWebService was registered with SharePoint, stored within it’s configuration database, thereby letting SharePoint know of the existence of that service. When an administrator opens up the “Manage Services on Server”, selects a server in the farm and clicks on “Start” next to “SharePoint Foundation Web Application” row, they are provisioning an instance of SPWebService to that specific server. SharePoint, behind the scenes, is creating an object of type SPWebServiceInstance and associating that with that specific server within it’s configuration database.

Since SPWebService is the key service that manages all web applications, including the central administration web application, within a farm, we are able to use this service to perform various tasks associated with it. The typical way with which all web applications could be queried with code is by using the following piece of code:

Please note the usage of the ContentService static property in the SPWebService class. Interestingly this property doesn’t return an “instance” of the service in the server where the code is running, but a reference to the service in the list of services configured in the local farm!

How about if you wish to get an instance of the central administration web site?

Any guesses on how many web applications would this return? Yes, exactly 1!

We will look at how to define the relationship between a service type and a service instance type when we implement our own service in a later article.

The content service that we discussed above is unique in the way it is configured and used within SharePoint. An instance of this service is typically present in all the web front ends and application servers within a SharePoint farm. A reference to this service within SharePoint code base is always obtained as a reference to the locally started service instance.

This is obviously not a scalable design, and considering the type of service we were discussing about, it doesn’t need to be.

Scaling SharePoint Services

The example given above deals with a specific type of service. As I mentioned previously there are a few other types of services apart from the one talked about above.

“User Profile Synchronisation Service” is another type of service which not only has a SharePoint component to it, but also has a Windows service component. Provisioning an instance of this service to a server actually configures a Windows service called “Forefront Identity Management Service” in that server. Providing a mechanism for controlling the associated Windows service from SharePoint management screens allows SharePoint administrators to scale out their deployment to match their requirements.

In the previous versions of SharePoint (especially SharePoint 2007) such controls were unavailable and the administrators had to contend with provisioning a server specifically for running services and there were not a lot of ways to scale out a deployment in a clean and controlled way.

There is one draw back for the above mentioned services though – client programs and client code cannot make use of such service instances. The developer is forced to enumerate the service instances locally and find the service instance to work with. If a service instance is not available locally, the code cannot do anything but just complain and throw a fit. That fundamentally defeats the purpose of a scalable deployment.

A good example of this is the “Claims to Windows Token Service” (C2WTS). This service is a part of “Microsoft Identity Foundation” and can be used by customised code to translate a claims based identity to it’s corresponding Windows identity. More information about this service can be found here. “Microsoft Identity Foundation” is deployed by default in every server that SharePoint is deployed. In fact, this is a pre-requisite for SharePoint server and without it SharePoint will refuse to install. While this C2WTS Windows service is not started by default upon deployment, SharePoint administrators can start this service using the “Manage Services on Server” screen in Central Administration. The code that provisions an instance of this service on a SharePoint server simply starts this Windows service on that server.

image

Developers may use the client component of this service to perform translations they need between Claims identities and Windows identifies. Check this link for more details on this. The key point is that the client component needs to have the “Claims to Windows Token Service” started on the server where the code is running. The client component cannot connect to a remote server to perform that operation. This means that on every SharePoint server that the piece of code is running, the C2WTS must be started or the code will fail.

In short, this is not a truly scalable service or a solution.

This is not to say SharePoint is not scalable. The scalability comes from the third type of service in the list I provided above: The IIS Web Services.

IIS Web Services are implemented as WCF services and uses SOAP on HTTP protocol for communication. Provisioned service instances of this type are hosted as IIS virtual applications in an IIS virtual site called “SharePoint Web Services”. Each service can be configured to have multiple “endpoints” through which a service can be exposed to client applications. Endpoints in this context is conceptually equal to endpoints in WCF architecture. Each endpoint has an associated binding, and an address where the service is bound to.

A deeper discussion on the implementation details of this is not in the scope of this article.

When a SharePoint administrator provisions a service to a server from the “Manage Services on Server” screen, SharePoint internally provisions an IIS virtual application associated with that service. For every instance of an IIS web service provisioned, SharePoint keeps track of all possible methods to connect to it in the configuration database.

While available services and provisioned service instances can be enumerated using the above mentioned objects, how can client components connect and use these web services? That is where service applications come handy.

In the next part of this series we will dig deeper into service application architecture.