Sharepoint 2013 : Service Application Fundamentals (part 2) - The Connection Structure - Tying It Up with an Example

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 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.

FIGURE 4

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.