One of the biggest changes in SharePoint 2010 is the introduction of Service Applications. Like the functions bound up in the SharePoint 2007concept of Shared Services, Service Applications provide cross-farm functionality and give organizations flexibility in their deployments of critical services. But, unlike SharePoint 2007, you can deploy Service Applications in a range of configurations, and they are a whole lot more numerous than their predecessors.
SharePoint 2007’s Shared Services represented a modification in the way SharePoint farms were managed. Certain key functionality, like search, was separated from the base server and deployed in a manner that allowed it to be shared across more than one farm. In SharePoint 2010, Microsoft created the idea of Service Applications and Service Proxies. A Service Application is a more basic approach to creating a shared service.
There are separate Service Applications for each of the historical components of the Shared Services Provider, also called SSP. These include profiles, search, Excel services and logging. In addition, there are a lot of new applications for the new services provided by SharePoint 2010.Here’s a partial list:
- Search Service
- User Profile Service
- Business Connectivity Services
- Performance Point Services
- Metadata Management Services
- Secure Store Service
- State Service
- Usage and Health Data Collection Service
- Web Analytics Service
- PowerPoint Service
- Visio Graphics Service (for Workflow)
Although there are many more services in SharePoint 2010 than in2007, Microsoft has significantly changed the management of these services. With the dissolution of the SSP concept, so too was the administration site dissolved. All services are now managed directly through Central Administration.
A Database for Everyone
Flexibility was one of Microsoft’s primary design goals for the new Service Application architecture. As such, the historical monolithic database that housed what was an SSP had to change. With the slew of Service Applications also comes a database for every one of them.
As you deploy each Service Application, a database is created to support it. This allows SharePoint administrators to separate and segment Service Applications from one farm to another. Unfortunately, it also introduces a much more complicated management and business continuity solution.
Business continuity planning for SharePoint was already complex. By adding more moving parts, it becomes even more complicated. But the multiple databases also reduce the possibility that a single database corruption or failure will wipe out more than just a single Service Application.
Publishing and Consuming
When the SSP concept was eliminated, so was the singular point of entry for consuming those Shared Services. In its place, Microsoft created the concept of a Service Proxy, which is an abstraction of the Service Application. A Service Proxy enables communication between a SharePoint farm in need of a particular service and the Service Application that’s providing that service.
In this way, SharePoint administrators can publish a proxy for a specific service Application, like search, to a farm. When that farm needs the search service, it simply makes are quest through the proxy. Now, the trick is that the Service Application itself can be hosted virtually anywhere, and because the proxy is the consuming farm’s entry point, it does not specifically need to know that the search service is hosted on an entirely different farm.
In terms of management, this approach is both liberating and challenging. It’s liberating in the sense that SharePoint administrators can now create whole farms dedicated to hosting service applications. This eliminates bottlenecks, allows farms to be optimized for more background processing and somewhat simplifies business continuity scenarios because the proxies can be pointed anywhere and reconfigured as needed. But the complexity manifests itself in more management overhead associated with various communications between farms and with the associated “permissioning” and authorization that needs to occur for sharing across domain boundaries.
New Levels of Customization
As any SharePoint administrator knows, custom solutions can be difficult. In SharePoint 2007, Shared Services Providers were a generally blissful respite from the variety of custom solutions often deployed in enterprises. Unlike Web parts or features and solution files—though accessed through an SSP—not a whole lot of custom development occurred specifically within the context of the SSP. This is not the case with SharePoint2010 Service Applications.
In a bid to allow developers to really expand SharePoint’s capabilities, Microsoft created patterns to develop custom Service Applications. Although many enterprises will welcome the ability to extend existing services or create entirely new services, SharePoint administrators will need to get a hold of these applications quickly because they will inevitably add more complexity to their SharePoint environments. Further, because they cross all boundaries, including farm boundaries, a misbehaved Service Application could have serious consequences in the enterprise.
Much like the trouble caused by errant Web parts or features, custom Service Applications have the potential to be far more time consuming because they’re now effectively global in scope and could span more than one farm. As a result, SharePoint administrators should make sure developers create the appropriate management mechanisms and logging. This will allow proper troubleshooting in the event of bugs or other issues.
Avoiding Server Sprawl
SharePoint administrators should be wary of an increase in server sprawl. Like some of their SharePoint 2007predecessors, SharePoint 2010 Service Applications can generally be load balanced.
That’s a huge advantage for services that might span multiple farms and will likely be true for others like Business Connectivity Services (formally the Business Data Catalog),Visio Graphics Service or Metadata Management Services because these could prove popular and process orintensive. In a load-balanced configuration, administrators have the ability to ensure appropriate performance levels and redundancy.
But this ability may cause organizations to increase the size of their SharePoint farms. It is certainly true of enterprises already using SharePoint 2007, which discovered that their employees depend on the portal and cannot afford downtime. It’s also true of organizations that realize that the additional new services will increase load beyond a simple small farm or even a medium farm in larger companies. Because of this, there will be a push to add more servers to improve farm performance or to create a pure services farm where a single medium farm may have sufficed.
In the end, SharePoint 2010 represents a significant step forward in the evolution of this popular portal product. But, as companies incorporate advances in the platform, there will be additional changes in how administrators manage these farms. Some of the changes will place extra burdens on staff, while others will improve management capabilities. Either way, be prepared for them by getting to know Service Applications better.
About the Author
Shawn Shell is the founder of Web-based applications, employee and partner portals as well as enterprise content management solutions. He has spent more than 20 years in IT, with the last 10 focused on content technologies. Shell is a co-author of Microsoft Content Management Server 2002: A Complete Guide (Addison-Wesley), and he is the lead analyst/author on the CMSWatch SharePoint Report.