By Ted Pattison
Scaling a SharePoint farm is often achieved by efficiently sharing resources across sites running in different web applications and by offloading processing cycles from front-end web servers to dedicated application servers. SharePoint 2007 provides a resource-sharing architecture based on Shared Service Providers (SSPs). However, SSPs are not ideal because they have no support in the core platform. Instead, they are part of the SharePoint Server 2007 product and they do not support extensibility.
SharePoint Foundation introduces a new infrastructure for service applications that replaces the older SSP architecture from SharePoint Server 2007. In SharePoint 2010, service applications are used to facilitate sharing resources across sites running in different web applications and different farms. The new service application architecture also provides the means for scaling a SharePoint farm by offloading processing cycles from the front-end web servers over to dedicated application servers.
A key benefit to this new architecture is that you can treat a service application as a pluggable component. After a service application has been installed and created, it can be configured for several different deployment scenarios. In simple farms, an instance of the service application can run on each front-end web server. In more complex farms, a service application can be configured to run on a separate application server or in a farm of application servers.
A service application targeting SharePoint 2010 must be written to a specific set of requirements. For example, a service application must be written to query the configuration database about its current deployment configuration, and it must adjust its behavior accordingly.
When a service application runs across the network on a dedicated application server, it relies on a proxy component on the front-end web server. The proxy component is deployed along with the service application and it provides value by abstracting away the code required to discover where the service application lives on the network. The service application proxy component provides additional value by encapsulating the WCF code uses to execute Web service calls on the target service application.
The proxy-based design of service applications yields quite a bit of flexibility in terms of deployment and configuration. You can configure a proxy in one farm to communicate with a service application in another farm. The proxy simply consults the configuration database and discovers the correct address for the application server running the service application. The implication here is that the new service application architecture makes it much easier to share resources across farms.
There are four built-in service applications that ship with SharePoint Foundation. When a new farm is created, SharePoint Foundation automatically creates and configures two important service applications named Application Discovery and Load Balancer Service Application and Security Token Service Application. There are two other service applications built into SharePoint Foundation named Business Data Connectivity Service (BCS) and Usage and Health data collection that can be created either by hand or by running the Farm Configuration wizard available in the SharePoint 2010 Central Administration site.
Unlike Shared Service Providers (SSPs) in SharePoint 2007, service applications were designed with developer extensibility in mind. Any SharePoint developer with the proper knowledge and incentives can create a service application that can plug into any SharePoint 2010 farm.
Even if you never find a good reason to create your own service application, it's important that you understand how they work and how they fit into the high-level architecture of SharePoint Foundation. For example, SharePoint Server 2010 delivers a good deal of its functionality through service applications. Furthermore, there are many other groups within the Office team at Microsoft that have built their own service applications that can be installed and configured in a SharePoint 2010 farm.
Ted Pattison is an author, instructor and co-founder of Critical Path Training (www.CriticalPathTraining.com), a company dedicated to education on SharePoint technologies. For the last five years Ted has worked with Microsoft’s Developer Platform Evangelism group researching and authoring SharePoint training material for early adopters. Ted started working with SharePoint 2010 in August of 2008 and since that time has led a series of 5-day training classes in which he has already taught hundreds of professional developers how to get started building custom business solutions using the SharePoint 2010 platform.