Understanding the Service Application Architecture WHAT’S IN THIS CHAPTER? What happened to Shared Services Providers? Service application basics Administering service applications Multi-tenancy in SharePoint 2010 Put your thinking cap on. This chapter is going to plunge you headfi rst into the depths of SharePoint service applications. On the surface, they are pretty straightforward — heck, you can just run a wizard to get started — but truly unlocking their power takes a bit more effort. Service applications are the way SharePoint 2010 provides most of its services. Think of some- thing like Search or Excel Services. These are offered as individual services that can be consumed in a variety of ways. Out with the rigid Shared Services Providers and in with the fl exible service applications. Groups, connections, proxies, services, delegated administrators — what is all of that stuff? As with most things technical, terminology is critical; and unfortunately, once you learn the key SharePoint terms, you will fi nd that half of them have a doppelganger in Windows PowerShell. Ugh. However, once you have a grip on the terminology and the plumbing, it’s time for the fun part. After looking at the fundamentals in Central Administration and then strolling through some of the key cmdlets, you’ll be ready to get your hands dirty. Then once you think you have things under control, you learn a new trick. Some of the service applications can be confi gured to be multi-tenant, meaning that a specifi c instance of the service application can be set up in a way that makes each site collection think it is using a dedicated service, when in reality they are sharing. 7 168 CHAPTER 7 UNderstaNdiNg the service aPPlicatioN architectUre Get excited. You may think this chapter will be boring, but it’s a non-stop thrill ride through one of the most important pieces of SharePoint. FAREWELL TO THE SHARED SERVICES PROVIDER If you are familiar with MOSS 2007, then you know all about those lovely things called Shared Service Providers (SSPs). They enabled services to be packaged and provided in MOSS. An SSP consisted of Search, Profiles, Audiences, and My Sites; and if you were cool enough to have the Enterprise CAL, then they also brought Excel Services and the Business Data Catalog (BDC) to the party. You would then associate one or more SharePoint web applications with the SSP to consume these services. The web application had to get all of its services from one SSP, which caused scaling nightmares for many administrators. For example, suppose you currently host your intra- net at http://intranet and it is associated with the Enterprise SSP. Then Human Resources comes to you and says they need to have their own, iso- lated copy of the BDC to protect their data. First you would have to create for them a unique web application, http://hrweb. Then you would have to create an HR-only SSP and associate their web application with the new SSP. Then you could set up the BDC. The only problem is that when you create the new SSP, you also get a new instance of all of those other services, like Search, as shown in Figure 7-1. If HR would like to be able to search, then you have to configure Search for this SSP because they could not associate their web app with the corpo- rate SSP and its Search index. You can see how this could quickly become a black hole of redundant services and duplicate data. In SharePoint 2010 this is no longer the case. Instead, all of those individual services can stand on their own as service applications. Table 7-1 shows the list of the service applications available and some information about them. TABLE 71 Service Applications SHAREPOINT FOUNDATION SERVICE APPLICATIONS Has Database Cross-Farm Capable Business Data Connectivity Yes Yes Usage and Health Data Collection Yes No Web Analytics No Yes Microsoft SharePoint Foundation Subscription Settings Service Yes No Enterprise SSP Search Profiles BDC . . . Http://intranet HR Only SSP Search Profiles BDC . . . Http://hrweb FIGURE 71 Farewell to the Shared Services Provider 169 SHAREPOINT SERVER 2010 STANDARD SERVICE APPLICATIONS Has Database Cross-Farm Capable Managed Metadata Service Yes Yes Search Yes Yes Secure Store Service Yes Yes State Service Yes No User Profile Service Yes No SHAREPOINT SERVER 2010 ENTERPRISE SERVICE APPLICATIONS Has Database Cross-Farm Capable Access Service No No Excel Service No No Visio Graphic Service No No Word Automation Services No No PerformancePoint Service No No Note that service applications are part of all the SharePoint 2010 editions, including Foundation. This is great news for administrators and should help reduce some of the previous inconsistencies in administering SharePoint. The best way to think about service applications is take the old SSP and explode it out so that each piece stands alone. So instead of buying a combo meal, now you can get the burger, fries, and drink separately — and if for some reason you want two drinks and no fries, that’s fine too. Everything is ala carte. To put that in SharePoint terms, we can return to the example described earlier. Currently, your company uses http://intranet for all SharePoint sites. For security reasons, the Human Resources group wants to have its own BDC, so you begin by creating a web application for them, http://hrweb. Then you provision a new BDC service application named HR only BDC. Now you can associate http://hrweb with that service application and all of the other service applications, as shown in Figure 7-2. As you can see, now HR has access to all of the same service applications as before, including the Enterprise BDC, and they have their own BDC. The other Intranet users are unaffected in terms of access; they are merely excluded from the HR only BDC, thus giving HR its desired isolation. What was such a huge nightmare in the previous version of SharePoint is now a piece of cake in SharePoint 2010. Even better, the service application architecture is infinitely configurable. Of course, as you already know, infinitely configurable also means it can be infinitely complex. Fear not; this chap- ter will help you work through those infinite loops. 170 CHAPTER 7 UNderstaNdiNg the service aPPlicatioN architectUre Search Farm Service Applications Excel Services BDC User Profiles HR Only BDC Http://intranet Http://hrweb FIGURE 72 SERVICE APPLICATION FUNDAMENTALS Before you can begin to work with service applications it is important to get a handle on all of the pieces involved and how they interrelate. There are a series of connections and associations to get from your web application to search results and the better you understand the pieces the easier it is to wire it all together. The Connection Structure In order to provide service applications that are flex- ible and scalable, the services are actually offered through a series of connections and associations (see Figure 7-3). SharePoint web applications are associated with ser- vice application groups, which are made up of one or more service application connections. Each service application connection connects the service applica- tion to the service application group. A given service application consumes one or more service application services. Finally, some of those service applications have databases for storage, while others do not. You already know what web applications are, so the following sections will help you make sense of these interrelated elements. Service Application Groups The group is the piece you associate with your web applications. When you created your first web appli- cation back in Chapter 4, it was set to use the default Web Application Service Application Group Service Application Connection Service Application Service Application Database(s) Service Application Service(s) FIGURE 73 Service Application Fundamentals 171 service application group, as shown in Figure 7-4. Notice that when the default is selected, all of the checkboxes are grayed out. You cannot edit the default group from this screen. FIGURE 74 The default group is automatically provisioned for you. If you used the initial Farm Configuration Wizard, then all of the service applications are part of this group. When you manually create a service application, you can choose to include it in the default group or not by using the checkbox shown in Figure 7-5 (more on that later in the chapter). FIGURE 75 This group enables you to associate a web application with a bunch of service applications. If the default group doesn’t meet your needs, you can you can use the [custom] option. This enables you to specify which service applications you want to use for the web application. Keep in mind that although [custom] appears in the group drop-down menu, you cannot reuse this “group.” When you create a web application and specify [custom], you choose the service applications available to 172 CHAPTER 7 UNderstaNdiNg the service aPPlicatioN architectUre that web application. If you then create a second web application and select [custom], you will not see the service applications you chose for the fi rst web application. This is a unique instance of [custom]. It is not reusable. Proxy groups or application proxy groups are other terms you may hear for service application groups. This is how they are referred to in the SharePoint 2010 Management Shell and in the object model (OM). T o create a group you can reuse, you need to use the SharePoint 2010 Management Shell and run the New-SPServiceApplicationProxyGroup cmdlet. You will learn more about this cmdlet in the section “Service Application Administration” later in the chapter. Service Application Connection The service application connection is actually what most people are thinking about when they cre- ate the service application from Central Administration. This connection connects the web service that runs for the service application and accepts requests from the web application to the service application group. In other words, the web application is associated with a service application group that says, “Here are all the service applications you can use.” That way, when the web application wants profi le information, for example, it knows what User Profi le 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 fi nd these service application connections and their web services. If you confi gured your farm with the Farm Confi guration Wizard, then they will be named and listed as a 32 character GUID and not a logical name. Like the service application group, the service application connection is known by a few other names. Proxy and application proxy are sometimes used, especially when dealing with the SharePoint 2010 Management Shell and the OM. Avoid the temptation to use these terms, as the word “proxy” is one of those overused IT words, used in about a bazillion places. Just don’t do it. Service Application The service application is your main purpose in this somewhat complicated connection matrix. Service applications provide the services you need once you have access to them. When you create a new ser- vice application, you automatically get the accompanying service application connection point and the database(s), 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 actually has multiple databases. The Managed Metadata service only needs one database to do its job. Service Application Fundamentals 173 When a service application needs a database, you will be prompted to provide a name when manu- ally creating the service application. 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. A single database and service can be used to host data that needs to be kept logically separate, but additional planning and PowerShell cmdlets are required. More on that later. Service Application Service(s) Last, but certainly not least, are the service application services. You can find these hanging out in Central Administration on the Application Management page. Under Service Applications, click Manage services on server. 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, you go through the connections listed above and finally get to the service application. It facilitates your 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 appli- cation, 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. You will find that each service application can handle 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. And Search… well, you’ll find several pages in Chapter 14 to explain how Search balances the load. Tying It Up with an Example Take a look at Figure 7-6, which provides a schematic diagram of the concepts just described. Looking first at the left side of the diagram, the company has a SharePoint web application, http://intranet (1a), that is associated with the default (2a) service application group. The default service application group has three service applications in it: 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). These connections are not something that administrators can actually touch; they are created when the service application is cre- ated 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 calculation service (6c). 174 CHAPTER 7 UNderstaNdiNg the service aPPlicatioN architectUre Database Database Database 4a 6a 5a 3a Enterprise BCS BCS Service Http://intranet 1a 2a 4b 6b 5b 3b Default Enterprise Managed Metadata Managed Metadata Service 4c 6c 3c Enterprise Excel Services Excel Service Http://marketing 1x 3x-1 Custom Marketing Managed Metadata 2x 5x Key: 1. Web Application 2. Service Application Group 3. Service Application Connection 4. Service Application 5. Service Application Database(s) 6. Service Application Service(s) FIGURE 76 That was pretty straightforward, so now take a look at a slightly more complicated scenario by looking at the right side of the figure. The company has a second web application at http://marketing (1x). They are using the [custom] (2x) service application group. Now for the twist. There are once again three service application connections. 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). And the 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) as the Enterprise Managed Metadata service application did. That’s it, folks. If you grasp these relationships, you know everything you need to know about service applications. Ok, maybe not everything, but you are off to a solid start. Dig in and keep reading. Service Application Fundamentals 175 Connecting across Farms Once you understand the service applications and all of their connections in your farm, the next log- ical step is to add more connections. Some of the service applications are capable of being published and then consumed across different SharePoint farms. Even more impressive is the fact that all of the service applications except the User Profile service application don’t even require the two SharePoint farms to be in trusted Active Directory domains. Before you can publish or consume the service applications between two farms, you have to establish a farm trust. This is done by using the SharePoint 2010 Management Shell to create and register cer- tificates between the two farms. This is covered in greater detail in the section “Service Application Administration” later in the chapter. After the farm trust is configured, you can go to the publishing farm and select the service application you want to publish. Once it is published, you will get a URL for accessing the published service. From the consuming farm, you simply connect to the published service by providing the URL. Then the connected service application can be added to a service application group, and will provide services just as if the service application had been part of the farm. Figure 7-7 shows an example of four farms at work. Farm 1 introduces a new concept, an enterprise services farm. This is something typically seen only in large companies. The idea is that a farm is created and maintained exclusively to provide services to other SharePoint farms throughout the organization. This way, the services farm can be optimized for hosting services and can be maintained in the same manner. For example, a Search index might contain several million items, requiring several days to do a full crawl, and hours to do an incremental crawl. In order to do this efficiently, you need to optimize your hardware for Search. If you have three SharePoint farms and each maintains its own Search service application, it would be very expensive to do a lot of repetitive crawling of content. Instead, a much better solution would be to maintain the index in one farm and just consume the service from the other farms. Farm 2 is a simple farm for publishing content, maybe hosting just informational websites or similar content. In this farm, the demand for service applications is low, and all of the service applications it does require are provided by the enterprise farm. Therefore, this farm actually has no local service applications and is just optimized for displaying SharePoint content. Farm 3 is a collaboration farm and is a busy place. This farm has demands for all types of service applications — some are consumed from farm 1, and others are hosted locally. The locally hosted service applications are those that are not capable of being published across farms, so they must reside in the farm where they are needed. Note that the Managed Metadata service application from farm 4 is being consumed. Other than that, there is nothing special about this scenario other than the flexibility of consuming service applications from multiple farms. Farm 4 is very similar to the collaboration farm in nature. It is hosting its own web applications and is consuming local and remote service applications. Additionally, it has published the Managed Metadata service application for consumption by farm 3. Although all three farms are using the default group in this example, this isn’t a requirement. You very well could have configured the [custom] group in any of the farms to consume the cross-farm service applications. . applications are part of all the SharePoint 2010 editions, including Foundation. This is great news for administrators and should help reduce some of the previous inconsistencies in administering SharePoint. The. how they are referred to in the SharePoint 2010 Management Shell and in the object model (OM). T o create a group you can reuse, you need to use the SharePoint 2010 Management Shell and run the. desired isolation. What was such a huge nightmare in the previous version of SharePoint is now a piece of cake in SharePoint 2010. Even better, the service application architecture is infinitely configurable.