Chapter 2. Service Applications

In this chapter, we will cover:

  • Managing a service
  • Creating the Secure Store
  • Creating custom security for a service
  • Creating a custom service application proxy group
  • Managing service application associations
  • Setting up Excel Services
  • Setting up PerformancePoint Services
  • Setting up Visio Services
  • Setting up Managed Metadata Service
  • Establishing a trust relationship between two farms
  • Publishing a SharePoint Service
  • Consuming another Farm's Service

Introduction

SharePoint 2010 introduces an overhaul of the MOSS 2007 Shared Service Provider (SSP). It is such a significant paradigm change that those who are responsible for implementing SharePoint must understand architecting to a different level.

MOSS 2007 had the SSP. The SSP encapsulated Search, Excel Calculations Services, user profiles, and the business data catalog. This is a "box" of services. This box was limited because you could not break it apart. One of the reasons it was limited was the fact that the services within affected the whole farm. If Accounting wished to use Excel Calculation Services, the whole farm was affected, even those not using it. In addition, writing an integrated custom service was out of the question.

SSPs are gone in SharePoint 2010. Microsoft has taken the SSP concept and built a new service application infrastructure that is flexible, extensible, and scalable:

  • Flexible: Services can be segmented to a particular group of users providing security boundaries. They can also be consumed by a subset of groups. For instance, Accounting and Engineering could share an instance of PerformancePoint Services. Legal is unaffected and cannot consume the work the other two groups are doing.
  • Extensible: Custom services can be written and "bolted" onto the existing architecture. An example of this is PowerPivot. It provides its own service that utilizes the existing architecture.
  • Scalable: Services are the application layer of SharePoint. As resources are consumed, more boxes may be necessary to scale properly. The service architecture provides for this possibility.

Service applications for SharePoint 2010 can be viewed very similarly to the cable TV paradigm. With cable TV, we have a lot of channel choices and they are presented to us in packages. It becomes a decision as to what package you wish to consume. Premium content costs more and includes channels such as HBO. There is basic cable that typically includes local channels showing programs that are created at a city level; high school football team games would be an example of this.

Basic cable is comparable to the service applications in SharePoint Foundation. By paying a very little amount or nothing at times, you are able to get basic functionality such as Business Connectivity Services.

Moving up to SharePoint Standard is akin to having stations such as TBS, AMC, and so on. It is the middle tier of packages. In our scenario, this is services such as Managed Metadata and Search, which can be subscribed to via different server farms.

Applications such as Excel Services and Visio are comparable to the premium content such as HBO, as these applications come bundled only with the enterprise version of SharePoint.

There are three tenets that you must know when architecting and supporting service applications.

  • Services included in the different versions of SharePoint
  • Services dependent on the others
  • Services that can be shared across farms

The following diagram summarizes the versions and some of the characteristics:

Introduction

Other products such as Office web applications, Project Server, and PowerPivot ship their own services applications.

Most service applications use their own application pool, under which their web service runs. One of the positive effects of this structure is if something goes wrong with that service, it will not affect the rest of the farm. Another positive effect is the ability to implement least privileged accounts. The factor to keep in mind when creating application pools is the amount of resources that they consume—in particular, RAM.

When installing SharePoint 2010, certain configurations are set by default using wizards. We assume no wizards in any of these recipes.