SharePoint Service Application Topologies

The SharePoint Service Application Framework object model supports many different server farm topologies. Let’s explore some of them.

Single Application Server

In this topology, the service is comprised of a service application hosted in a single online (started) service instance. A web application is connected to the service application via a service application proxy.

This topology requires a minimal hardware but offers no redundancy, so a failed application server will result in service downtime.

NOTE:  A SharePoint server can be simultaneously configured as both a web front end (WFE) and application server. So it is possible to run this entire topology on a single machine.

Multiple Application Servers

In this example topology, the server farm is expanded to include three application servers. However, we choose to run our service application on only two of these servers. The third server is used for other purposes, for example, it may host a different service application.

This topology offers some redundancy. If one application server goes down, the service instance on the other application server will still be able to handle requests, so our service will not have any downtime. (Of course, if the one remaining server does not have enough capacity to handle the user load, the user experience will be degraded.)

Server farm administrators may use the Central Administration site or a PowerShell cmdlet to start or stop our service instances on any app server at any time in order to accommodate capacity requirements or server maintenance.

NOTE:  There is still only one logical Service Application, though it is hosted by up to three difference application servers at any given time.

Multiple Web Applications

In this topology, multiple web applications are sharing the same service application.

This topology is useful, for example, to share service data such as taxonomy or user profiles across web applications.

Note that the web applications in this topology all share the same service application proxy.

Multiple Service Applications

In this topology, two service applications of the same type are hosted on the same server farm. Web applications in the server farm may be connected to either service application, at the server farm administrator’s discretion.

The two service applications are expected to be isolated between the two service applications. For example, if the service application stores data in a database, each service application may use a different database.

An example where this topology may be useful is a server farm hosting two different web applications which should not share service application data, such as a legal department and a sales department which should not share search query service application data.

Note that both service applications are hosted by the same service instances on the same application servers.

Federated Service Application

In this topology, service applications are consumed by web applications in remote server farms.

An example where this topology may be useful is a service that requires expensive resources, such as an enterprise-wide search service. An IT department may choose to create a search service application on a centralized server farm and publish it to other departmental server farms throughout the organization.

This topology allows the departmental server farms throughout the organization to provide an enterprise-wide search experience for their web applications, without the cost of maintaining their own search indexing service hardware, and without saturating the enterprise network with many redundant search crawlers.

NOTE:  A two-way trust must be configured between two server farms to enable this topology.

Summary

Many more topologies are possible, but I’ve reached the limits of my Visio diagramming skills.

For example, server farms may host many service applications, and application servers may host many different types of service instances. Server farms may also simultaneously publish and consume service applications to/from other farms. Service applications can consume other service applications using service application proxies, and these dependencies can even span server farms. Service applications also support “tenancy” or partitioning to allow them to scale to the user loads generated by large-scale hosting deployments.

The main point I hope I’ve made, though, is that the Service Application Framework object model provides a vast amount of flexibility for administrators to customize service application deployments to fit their needs.

Next time, I’ll describe the specialized classes in the SharePoint Service Application Framework which take care of many of the details of deploying web services in these varied topologies.