Service Application Connection
The service application connection
(or service application proxy; remember tomato/tamahto) is what most
users are thinking about when they create the service application from
Central Administration. This connection is the path between the service
application, along with its web service(s), and the service application
group that accepts requests from the web application. In other words,
the web application is associated with a service application group that
in effect is saying, “Here are all the service applications you can
use.” When the web application wants profile information, for example,
it knows what User Profile web services to call. If you look in IIS,
you will see a website named SharePoint Web Services. If you drill
through this list, you can find these service application connections
and their web services. They will be named and listed as a 32-character
GUID, not a logical name.
Like the service application group, the service application connection is known by a few other names, including proxy and application proxy,
especially when dealing with the SharePoint 2013 Management Shell and
the SharePoint object model. Recall from the preceding section that
service application groups are sometimes referred to as proxy groups.
Avoid using these older terms, as “proxy” is one of those ambiguous,
overused IT words that often cause confusion.
Service Application
The destination of this complicated connection matrix is the service application, which provides the service you need. The service application groups and service application connections
serve to organize and access the service applications. When you create
a service application, the accompanying service application connection
is created with it. Some service applications require storage; the
databases they use are covered next.
Service Application Database(s)
As mentioned earlier, not all service
applications have a storage requirement, For example, Excel Services
does not store data; it only facilitates the display of data stored
somewhere else, so it doesn’t need a database. Conversely, Search has
intensive storage needs, so it has multiple databases. The Managed
Metadata service needs only one database to do its job.
Of special note for SharePoint 2013 is the new
Access Services. Access Services as they existed in SharePoint 2010
still exists as a separate service application named Access Services
2010. The new Access Services (without the year suffix) is used by
creating individual Access sites, also called apps,
in SharePoint 2013. Each Access app stores its information in a SQL
database, so if you create 20 Access apps you will have 20 databases.
Note that you must have a SQL Server 2012 server to host these Access
app databases. These databases don’t need to be on the same SQL Server
as the rest of the SharePoint databases.
When a service application needs a database, you
are prompted to provide a name if you are manually creating the service
application; for some service applications, such as Search, the
databases will be automatically created and named. Each database is
unique to an individual service application. For example, if you create
an Enterprise BDC service application and an HR-Only BDC service
application, you will have two unique databases. You can use a single
database and service to host data that needs to be kept logically
separate, but it requires additional planning and the use of PowerShell
cmdlets. You’ll learn more about that later. Given a choice, don’t
create a database name with an ugly GUID on the end.
Table 1 shows the service applications that require a database or databases.
TABLE 1 Service Applications Requiring Database(s)
SERVICE APPLICATION |
HAS DATABASE(S) |
CROSS-FARM CAPABLE |
Application Management Service [new in 2013] |
Yes |
|
MachineTranslation Services [new in 2013] |
Yes |
Yes |
Access Services [new in 2013] |
Yes |
|
Access Services 2010 |
|
|
Business Data Connectivity Service |
Yes |
Yes |
Excel Services Application |
|
|
Managed Metadata Service |
Yes |
Yes |
PerformancePoint Service Application |
Yes |
|
Search Service |
Yes |
Yes |
Secure Store Service |
Yes |
Yes |
State Service |
Yes |
|
Subscription Service |
Yes |
|
Usage and Health Data Collection Service |
Yes |
|
User Profile Service |
Yes |
Yes |
Visio Graphics Service |
|
|
Word Automation Services |
Yes |
|
Work Management Service |
|
|
Service Application Service(s)
Sometimes called services, service application services
are located in Central Administration on the Application Management
page. Under Service Applications, click the Manage services on the
server link. The link is also on the System Settings page.
The services are the true workhorses in the
stack. When you make a request to Excel Services, for example, the
request goes through the groups, connections, and applications we have
already discussed to finally get to the service application service.
The service application deals with the hand off of the request, but all
the actual processing and work is done by the Excel Calculation
Services running on one or more servers in your farm.
These services are one of the key ways you scale
service applications. If, due to heavy usage, you find that you need
more performance from Excel Services, then you could start the Excel
Calculation Services on another server in your farm. That way, when you
make requests of the Excel service application, it will distribute the
request between both of the servers running the services. You can
continue to add servers running the service until you achieve your
performance target.
Each service application handles this load
balancing of the services in its own way. Excel Services has a setting
to control the load balancing. Managed Metadata just does the load
balancing on its own.
Tying It Up with an Example
This section looks at an example using
two scenarios that incorporate the default service application group
and a custom application group, respectively. Figure 4 provides a schematic diagram of these scenarios, which apply the concepts described in the preceding sections.
Looking first at the left side of the diagram, this company has a SharePoint web application, http://intranet
(1a), that is associated with the default (2a) service application
group. The default service application group contains three service
applications: Enterprise BDC (4a), Enterprise Managed Metadata (4b),
and Enterprise Excel Services (4c). These are connected to the default
service application group by the three service application connections
(3a, 3b, 3c). (Note that these connections are not something that
administrators can actually touch through Central Admin; they are
created when the service application is created and they enable the web
applications to talk to the associated service applications.) The
Enterprise BDC stores its content in its database (5a) and uses the
Business Data Connectivity service (6a) running on the server. You can
also see that the Enterprise Managed Metadata service application has a
database (5b) and a service (6b). Finally, Enterprise Excel Services
does not have a database but is using the Excel service (6c). This
process is relatively straightforward.
Now consider the slightly more complicated
scenario on the right side of the figure. The company has a second web
application at http://marketing
(1x). That web application is using the [custom] (2x) service
application group. Now for the twist; there are still three service
application connections, but the connection (3b) to the Enterprise
Managed Metadata (4b) and the connection (3c) to the Enterprise Excel
Services (4c) are reused, demonstrating that a service application can
be connected to multiple service application groups. Enterprise Managed
Metadata continues to use the same database (5b) and service (6b) as
before, because it is the same service application. The same is true
for Enterprise Excel Services and its service (6c).
Note one final twist: Marketing has a unique
service application, Marketing Managed Metadata (4x) that is connected
(3x) to the [custom] group. This service application has a unique
database (5x) for its storage, but it uses the same Managed Metadata
service (6b) that the Enterprise Managed Metadata service application
did.
If you grasp these relationships, then you
understand the essential behavior of service applications — maybe not
everything, but you are certainly off to a solid start.