Creating Custom SharePoint 2010 Service Applications and Consumers

Microsoft Office SharePoint Server 2007 introduced Shared Services Providers (SSPs) to provide common services to web applications. In Microsoft SharePoint 2010, Microsoft changed this model to use the new service application framework, which no longer groups services together for multiple web applications. This new infrastructure enables more flexibility in managing and using the services. In addition, it is now possible to create custom service applications. This Visual How To demonstrates how to create custom SharePoint 2010 service applications and consumers that take advantage of the service.

Creating custom SharePoint 2010 service applications is a significant task. As this Visual How To demonstrates, there is a considerable amount of work in building up all the plumbing for a service application to support the actual work of the service. The example in the demonstration for this Visual How To is a service application that provides two simple math functions, as follows.

C#

Copy

 [ServiceContract]
public interface IWingtipCalcContract
{
    [OperationContract]
    int Add(int x, int y);

    [OperationContract]
    int Subtract(int x, int y);
}

There are three classifications of components that make up a custom service application:

• The back end—what resides on the SharePoint application servers
• The front end—what resides on the SharePoint front-end web servers
• The consumers that leverage or use the service application

Service Application Back-End Components
The back-end components in a service application consist of three pieces. The SPService is the hub for the service application. It contains references to all running instances of the service, timer jobs, and derived service applications. The SPServiceInstance hosts the running service. There is exactly one instance of a SPServiceInstance on a server, which can be installed on multiple servers. The more servers they are installed (and running) on, the more scalable the service application is. The last component is the SPServiceApplication. This is a configuration of the service that knows which databases it uses and implements the interface of the service application, in the case of the example in this Visual How To, IWingtipCalcContract, as shown in the following example.

C#

Copy

public class CalcServiceApplication : SPIisWebServiceApplication, IWingtipCalcContract
{
    #region IWingtipCalcContract implementation
    public int Add(int x, int y)
    {
        return x + y;
    }

    public int Subtract(int x, int y)
    {
        return x - y;
    }
    #endregion
}

Service Application Front-End Components
There are two front-end components that make up a service application. The first is the SPServiceProxy, which like the SPService on the back end, acts as the hub for each front-end server. This object contains references to all the proxies connected to back-end service applications. The most important piece on the front end is the SPServiceApplicationProxy. This component's job is to talk directly to a SPServiceApplication running in one of the many SPServiceInstances on a back-end server. Using the internal service application software load balancer, it will get the endpoint address of a Windows Communication Foundation (WCF) service that is hosted by the SPServiceInstance. When a call is made by a consumer, it talks directly to the SPServiceApplicationProxy, which sends the reqest to a specified SPServiceApplication for processing.
Service Application Consumers
The final piece of a custom service application are the consumers. These could be custom WCF services, *.aspx pages, Web Parts, or Windows PowerShell cmdlets—anything that uses the service application. This is done by communicating directly with the SPServiceApplicationProxy and using the SPServiceContext, as shown in the following example.

C#

Copy

public int Add(int x, int y)
{
    int result = 0;

    // run the call against the application proxy
    CalcServiceApplicationProxy.Invoke(SPServiceContext.Current,
        proxy => result = proxy.Add(x, y));

    return result;
}      

Microsoft completely revamped the service infrastructure in SharePoint 2010. This new architecture is much more flexible and scalable than the service offering in earlier versions of SharePoint. It enables administrators to configure services on a case-by-case basis. And instead of grouping them together into SSPs, as in Microsoft Office SharePoint Server 2007, administrators can associate them with web applications on a case-by-case basis. This a la carte configuration provides a great amount of flexibility in arranging services for each web application. Microsoft has also opened up this new architecture to developers to create their own service applications. Although creating custom service applications is a significant undertaking, as shown in this Visual How To, it can provide a great amount of functionality and capabilities in certain situations.