SharePoint Web Service Applications

In a previous post, I described the five core classes (SPService, SPServiceInstance, SPServiceApplication, SPServiceProxy, and SPServiceApplicationProxy) that comprise the core of the SharePoint 2010 Service Application Framework. I also outlined some of the server farm topologies that can be described within this framework.

In this post, I’ll introduce the specialized support for web service applications in SharePoint 2010.

Web Service Applications

It should be clear from my previous posts that SAF does not specify a communications protocol. SAF allows service deployments or topologies to be modeled so that SharePoint can provide a consistent management and deployment experience. Service developers may choose any suitable communications protocol independent of the decision to use SAF.

SAF does, however, include specialized support for services that choose to use the Windows Communication Framework (WCF). Developers may leverage this specialized support for web services built on SAF in order to avoid some of the more tedious and complex tasks associated with deploying and invoking a web service on multiple machines in a server farm.

NOTE:  Web service applications are web services that run on application servers. This is not the same as web services that run on web front end (WFE) servers, e.g., in the _vti_bin directory of a SharePoint site. Web service applications are not part of a SharePoint site. They are farm-scoped services that can be consumed by many SharePoint sites—even sites in different web applications and in remote server farms.

Deployment

SAF supports automatic deployment of web service applications within a server farm. SharePoint administrators can point and click (or use a PowerShell script) to deploy these service applications to any application server.

SharePoint deploys web service applications to the “SharePoint Web Services” site hosted by IIS7, and takes care of details like configuring the site for http, https (complete with a ready-to-use SSL certificate), and net.tcp.

Runtime

SAF includes runtime support for web service applications, including a service context object that wraps up all of the context needed to invoke a service application.

This service context object (SPServiceContext) provides the information necessary for service consumers to find a service application proxy of a given type.

For example, a web part may use SPServiceContext to request a proxy for our sample Calculator service application by type. SPServiceContext will return the requested Calculator service application proxy appropriate for the web application hosting the web part, as configured by the server farm administrator.

The round-robin load balancer (SPRoundRobinServiceLoadBalancer) is a software load balancer built into SharePoint, which means that SharePoint customers do not have to purchase or configure an external load balancing solution for service applications. It depends on the SharePoint topology service to discover service application endpoint addresses.

The default load balancer algorithm is a simple round-robin, but it is extensible so a more sophisticated algorithm can be employed by a service application proxy.

Other runtime features include propagation of locale settings, which allows the server to respond with results localized as appropriate for the client, and diagnostic information that can be used to correlate traces across machines in a server farm.

Discovery

The SharePoint “topology” service provides service application discovery features for a server farm. It is a service application that is installed and automatically started on every machine in a SharePoint server farm by default.

The topology service enables server farm administrators to browse and connect to published service applications, typically from remote server farms. SharePoint server farm administrators choose which service applications to publish.

In addition, the topology service provides endpoint address information for service consumers, e.g., for the built-in round-robin load balancer. For example, if a service application is hosted on two application servers (i.e., it has two online service instances), the two physical service application endpoint addresses will be available from the topology service.

Claims-based Authentication

SharePoint web service applications support claims-based authentication using the Windows Identity Framework (WIF). Among other features, this means that the SharePoint user identity may be delegated to the service application, even across server farms, for authorization decisions.

For example, without user identity delegation, a search query web service application would have to return “un-trimmed” search results to consumers. That is, results that should not be visible to the end user. In this case, the consumer (e.g., web front end) would have to be trusted to trim the search results. With the delegation support in claims-based authentication, the search results can be trimmed by the service application. This can improve performance as well as security.

Implementing a Web Service Application

To implement a SharePoint web service application, subclass the SPIisWebService* classes. For example, our Calculator service application classes would become:

class CalculatorService : SPIisWebService
class CalculatorServiceInstance : SPIisWebServiceInstance
class CalculatorServiceApplication : SPIisWebServiceApplication

class CalculatorServiceProxy : SPIisWebServiceProxy
class CalculatorServiceApplicationProxy : SPIisWebServiceApplicationProxy

Note that these are just specialized implementations of the five core SAF classes. The specialized SPIisWebService* classes are conceptually identical to the core SPService* classes from which they derive. If you’re not familiar with these classes, refer to my earlier post.

Next time, I’ll go a little deeper into the Calculator service implementation.