To truly understand the
purpose and function of service applications it is helpful to look at
the way services used to be provided in SharePoint. Microsoft Office
SharePoint Server 2007 (MOSS) used a different service model called the
Shared Service Provider (SSP). As the name implies, this provider hosts
multiple services, such as Search, User Profiles, My Sites, the
Business Data Catalog, and so on. The problem with this model was that
each SSP contained the whole set of services, and a web application
could only be associated with one SSP. In practice this meant that in
order for a company’s department or group to have an independent
Business Data Catalog, that group had to have its own SSP, which in
turn meant duplicating all the services. In terms of resources,
maintaining two SSPs in a large environment was very resource expensive.
For example, imagine you have an intranet for your entire organization at http://intranet.
Human Resources determines that it needs to isolate its Business Data
Catalog from everyone else for security and privacy reasons. With the
SSP model, the only way to do this is to create a new web application
for HR, such as http://hr, and a
new SSP to which it can be associated. This means HR can no longer use
the other services provided by the SSP associated with the intranet web
application, such as Search. HR now has its independent BDC, but in
order to use search in the http://hr
web application, you also have to configure Search in the HR SSP. As
described earlier, that’s because each SSP contains an instance of each
service, and a web application can only be associated with one SSP at a
time, as shown in Figure 1.
The introduction of service applications in
SharePoint 2010 eliminated that constraint. Individual services were
able to stand on their own as service applications. Using service
applications, meeting a requirement such as HR’s in the preceding
example is a snap: Create a new BDC service application — named HR-Only
BDC, for example, create the HR web application at http://hr, and associate it with all the service applications used by the intranet and
with the HR-Only BDC. That’s right; HR can continue to have access to
the same BDC as the rest of the intranet and access to its own private
BDC as well, as shown in Figure 2.
Another important change was made along with the
introduction of service applications. SharePoint 2010 Foundation was
included in the service model, whereas previously Windows SharePoint
Services (WSS) had no SSPs for sharing services at all. Foundation had
fewer service applications available, but the mechanisms were the same.
This is the same for SharePoint 2013, with all versions from Foundation
to Enterprise sharing the same service application architecture but
different product levels having different service applications
available. Having all versions of SharePoint using the same structure
is a big benefit for administrators because it eliminates
inconsistencies between products.
Service applications can be thought of
as shared service providers that have been divided into their
individual components. This creates a much more flexible architecture
that can be configured in nearly infinite ways. The cost of flexibility
is usually complexity, and service applications are no exception.
