SharePoint 2010 Service Application Development 101 – Logical Components

In this post we explore the essential components that make up a service application and the relationships between them: servers, services, service proxies, service instances, service applications, service application proxies, and load-balancers. In addition to these core components, we will also explore adding job definitions and databases to the mix.
This is part 2 of a short series on developing service applications in SharePoint 2010:

• Part 1: Getting Started with SAF + Starter Solution (with Logging / Configuration / Service Locator)
• Part 2 (This Post): Custom Service Application – Logical Components
• Part 3: Custom Service Application – Base Solution
• Part 4: Custom Service Application – Full Infrastructure (with Admin UI and PowerShell)
• Part 5 (Final): Custom Service Application – Integrating features and capabilities into your service application (sample MailChimp integration)

The following diagram highlights the logical components that make up a typical SharePoint service application.

DTaylor has already posted a nice generic description of the major components in his post: SharePoint Service Application Framework Object Model.

I have added a few new components to my diagram above that might be of interest to you as well, if you’re building a service application. These are:

• SPJobDefinition(s): Job definitions can appropriately be managed as part of either a service application or a service application proxy. These custom job definitions usually inherit from the SPFirstAvailableServiceJobDefinition abstract class. This abstract class allows developers to rely on the SAF framework to have the job run on the first available SPServer where an SPServiceInstance is provisioned. I personally prefer to manage jobs as part of the custom SPServiceApplication object, but there are some situations where having jobs run on the SPServiceApplicationProxy may make sense.
• SPDatabase(s): Service applications often have data stored in their own databases. Service applications can connect to multiple databases. SharePoint even provides the infrastructure necessary to work with mirrorred/failover SQL server databases. These databases don’t have to be limited to SQL server databases, but the APIs make it easier to work with SQL server of course.
• SPServiceLoadBalancer: The service application proxy typically leverages a built-in SharePoint service load-balancer to determine which service instance to connect to and consume over a WCF channel. This makes working with services easy and provides a built-in mechanism for scaling your service application right inside SharePoint.
• Custom Service Client API: I typically create a C# and even a RESTful client API that can be leverage by SharePoint UI components and jQuery to work with the service application proxy to consume the service application wcf endpoints hosted on one or more app servers.
• Other Components: A service application can manage any number of components, and these components don’t need to be SharePoint artifacts. A service application could just as well have sub-components to 3rd party systems. You can get pretty creative with how you structure your service applications. The user profile service application gets creative and adds windows services to the mix for example.

I re-created the diagram above with some custom components that I’ll build out in my next post to show how the service application is put together. Here’s the teaser.

We’ll create the service application code in the next post.