In my last post, I described the SharePoint Foundation 2010 Service Application Framework (SAF) object model.

To make these concepts more concrete, let’s design a simple calculator service using SAF.

Specification

Our calculator service will provide a single “Add” method that takes two integers as input and returns the sum.

The service will support deployment on many SharePoint application servers, in order to provide additional scalability and reliability.

Usage Scenario

Our primary usage scenario will be a web part that provides a user interface to our calculator service within a SharePoint site. This web part will accept user input for two integer values, invoke the “Add” method of our calculator service with these two values, and then display the returned result.

Service Object Model

Our calculator service will have three (3) server components: a service, a service instance, and a service application. These components will be implemented in the following classes (using C# syntax):

class CalculatorService : SPService

class CalculatorServiceInstance : SPServiceInstance

class CalculatorServiceApplication : SPServiceApplication

The CalculatorService class will be used to register the existence of our calculator service in a SharePoint server farm. We will register exactly one persisted instance of this class in the server farm configuration database (config db) when our calculator service is installed.

The CalculatorServiceInstance class will be used to register an installation of our calculator service on a particular server in a server farm. We will register exactly one instance of this class in the config db for every application server where our calculator service is installed.

The CalculatorServiceApplication class will be used to register a logical calculator service endpoint in a server farm. We will not create an instance of this class during installation of our calculator service. Instead, a server farm administrator will create instances of this class on demand as appropriate for his or her SharePoint deployment. Each instance of this class will provide a logical connection point for clients to execute our calculator service “Add” method.

The CalculatorServiceApplication logical endpoint will be hosted on each application server that has a CalculatorServiceInstance with a Status property value of “Online” (started). Server farm administrators may use either the SharePoint Central Administration site or PowerShell to start and stop CalculatorServiceInstances in order to provide the desired level of scalability and redundancy.

Client Object Model

Our calculator service will also have two (2) client components: a service proxy, and a service application proxy. These components will be implemented in the following classes:

class CalculatorServiceProxy : SPServiceProxy

class CalculatorServiceApplicationProxy : SPServiceApplicationProxy

The CalculatorServiceProxy class will be used to register the existence of our calculator service client in a server farm. We will register exactly one persisted instance of this class in the server farm configuration database when our calculator service client feature is installed.

The CalculatorServiceApplicationProxy class will be used to register a connection to a calculator service application in a server farm. We will not create an instance of this class during installation of our calculator service client. Rather, a server farm administrator will create one or more instances of this class as appropriate for his or her SharePoint deployment. Each instance of this class will provide the connection information necessary for the calculator web part in our usage scenario to execute our service application “Add” method.

Summary

We’ve designed a scalable calculator service application and conceptually modeled it using the SharePoint Service Application Framework. Next time, we’ll look at some of the server farm topologies that are possible using this design.