Print | posted on Sunday, May 02, 2010 9:57 PM
SharePoint 2010 includes a fundamental architectural change from the previous version with the introduction of “Service Applications”. This new architecture has extremely broad and deep consequences for SharePoint practitioners. Unfortunately Service Applications thus far have been poorly explained and documented, and already there are many myths surrounding them. This “In a Nutshell” article is an attempt to distil the core elements down to brass tacks. It is intended primarily for architects and administrators planning their farm topologies, but will also be useful for anyone working with SharePoint 2010.
Introduction.
SharePoint 2010 includes a fundamental architectural change from the previous version with the introduction of “Service Applications”. This new architecture has extremely broad and deep consequences for SharePoint practitioners, touching on nearly every aspect of SharePoint implementation from development approaches, topology design, service federation, authentication, governance and operational service management. Service Applications, rather than any particular service or feature in SharePoint 2010, is the single most important area for the field to adequately understand. At the very least service applications represent a fundamental change to the functional decomposition of services within a farm, the single biggest factor in delivering platform hygiene for distributed application platforms.
Unfortunately service applications thus far have been very poorly explained and documented. There are already, just a few weeks after RTM, many myths around service applications. You’ve probably heard them. A couple of my favourites are “Service applications give you scalability and load balancing for free” and “Service applications avoid authentication delegation problems”, which of course are both total hogwash.
This “In a Nutshell” article is an attempt to distil the core elements of service applications down to brass tacks. I will not be covering any particular service application in detail but rather focus on the core infrastructure plumbing. It is intended primarily for architects and administrators planning their farm topologies, but will also be useful for anyone working with SharePoint 2010.
Benefits (and drawbacks) of the Service Applications model.
The service applications model addresses some key limitations with the “old” Shared Service Provider (SSP) model in SharePoint 2007. First and foremost service applications allow for truly flexible deployment and granular delegation of control. You will have seen this referred to as “Services a-la-carte” – a particularly heinous marketing phrase. Service Federation is also now greatly refined because of amongst other things the adoption of Claims Based Identity in SharePoint 2010. Service applications also enable multi-tenant scenarios. We can also have true service isolation and each service application can now be autonomous in terms of it’s external resources such as configuration and data stores.
All very nice things, and all very much needed. But hold on a second, you have to take this stuff with a pinch of salt. It’s early days. Think back to the release of SharePoint Server 2007. Shared Service Providers (SSPs) were the solution to the scaling issues inherent in SharePoint Portal Server 2003 and a bunch of other things. They were wonderful! Now we are being told that they sucked, and service applications are the solution! Seem familiar? Nobody knows how the service application model will play out. Come back here in three years!
Having said that there can be no doubt that the service application model provides a suitable approach to addressing the scalability and delegation issues with SSPs and also are a fundamental enabler for a much wider feature capability (think Managed Metadata, Office Web Apps) in SharePoint 2010. Indeed the service application model pushes Microsoft’s most “service orientated” product vastly further ahead in the realm of distributed application platform hygiene. And that’s not a little deal at all.
The service application model allows SharePoint 2010 to scale further than ever before, way further. It also introduces a flexibility with respect to deployment that is unmatched in the marketplace. Just what big ass enterprises and SharePoint Online needs. Great!
But wait a minute! Enterprise software is about one thing, compromise. With all that goodness comes a fair dollop of complexity. Think of all those messed up SharePoint 2007 farms, “medium” ones, “large” ones, it doesn’t matter, I’ve never once done a health check and not had to identify farm topology issues. Whacky topologies are a very common thing, and they will get more common with SharePoint 2010. Aside from poor SQL Server implementation and insecure platform configuration, dodgy topologies are perhaps the most common reason for failed deployments or poor performance in production.
Therefore it is more important than ever to fully understand the functional decomposition of SharePoint. How can one choose the appropriate deployment topology if you don’t know which bits do what?
What is a Service Application?
Service Applications are actually nothing more than a logical concept. There is actually no such thing as a “Service Application”. The term is chucked around all over the shop and is destined to become as ubiquitous and misleading as “Web Front End”. You can’t just blame marketing. In the lead up to RTM, many SharePoint “experts” have been playing buzzword bingo with the term and giving false information about them, and even more worryingly, how to build them.
Of course SharePoint wouldn’t be SharePoint if it didn’t have totally confusing administrative interfaces and inconsistency in terminology. Central Administration (a.k.a. SharePoint Control Panel :)) is perhaps the worst culprit here.
The bottom line is forget about “Service Applications” other than as a term to describe the model of deployment for shared services in SharePoint 2010. Again, it’s a logical concept or container, nothing more.
OK, so what’s the real story then?
There are a number of components within a “Service Application”. They are:
- Service Instance
This is the meat of the thing, it’s the implementation of the functionality provided. Application binaries. It could include Windows Services, configuration, registry settings etc. SharePoint assets could include timer jobs, services, management pages etc. These bits are deployed to every server in the farm when the install is performed. When PSConfig(UI).exe is run you will see the status: “Successfully installed Service Instance: name of service”. Different service applications of course will have a different variety of bits.
- Service Machine Instance
This is the machine or machines in the farm that run the “service”. It is often referred to as a “SharePoint Service”. You configure this using Services on Server. More than one machine can run the Service Machine Instance and by default, software round robin load balancing is provided. You do not need to implement Network Load Balancing of any incarnation. Certain services will also provide their own software load balancing scheme (e.g. Excel Calculation Services). Not all service applications have an associated service machine instance. Some service machine instances can only be started on one server in the farm unless there are multiple service applications. Some Service Machine Instances have additional configuration.
Some “legacy” service machine instances exist, such as the Document Conversions Services, for which there is not an associated Service Application. In addition services such as the Claims to Windows Token Service and the Sandbox Code Service are just SharePoint wrappers for a Windows Service.
- Service Application Endpoint
When you start a service machine instance for which there is an associated Service Application, an IIS Virtual Application will be created within the SharePoint Web Services IIS Web site. This will include the Service Application Endpoint (a WCF or ASMX). Each service application must expose a service application endpoint. The service application endpoint is only created on the machine(s) hosting the service machine instance.
- Service Application
This is the logical container of the service, what is exposed through Manage Service Applications. It includes the management aspects of the service and configuration. When created the associated databases (if any) and configuration will also be created. The service application endpoint is not created until an associated service machine instance is started. There can be more than one instance of a particular service application.
Pages for managing the Service Application are hosted in Central Administration and are called using a GUID in the query string. Service Applications are global to the farm.
- Service Connection (aka Service Application Proxy)
This is a virtual link between consumers (e.g. Web Applications) and the service. This is an interface for consuming applications and services that understands the load balancing scheme for a service and how to speak to the service machine instance(s). This is not a WCF proxy. The Service Connection also enables inter-farm services. Some Service Connections include settings which are specific to a given connection. The UI calls them Service Connections, but they are more commonly known as Service Application proxies – the term used by PowerShell.
- Consumers
Consumers are any component that uses the service. Examples include Web Applications, a page, another service application, etc. All the consumer needs is a reference to the service connection.
How do we set these things up?
Not all service applications are equal. This is SharePoint after all
- “Core”
Service applications which are provisioned by PSConfig(UI).exe: Topology and STS, for which there is no or little configuration.
- “General Purpose”
Service applications for which no associated service machine instance is exposed for configuration, such as the State Service.
- “Simple”
Service applications that have relatively little configuration or moving parts, for example the Access Database Service or the Subscription Settings Service.
- “Medium”
Service applications that have a relatively small amount of moving parts, such as the Managed Metadata Service.
- “Complex”
Service applications that have a relatively complex amount of configuration and moving parts, such as SharePoint Server Search Service or User Profile Service (which have multiple Service Machine Instances).
Not all service applications are created, configured or managed in the same way. There is a ways to go in striving for this consistency and in some cases it is not prudent anyway.
As a general recommendation, the order of creation should be:
- Create the Service Application and Proxy
- Configure the Service Machine Instance
In some cases this order is enforced, in others it doesn’t matter.
Wrap Up
So there you go, a quick introduction to the actual things that make up a “service application”. As you can see it’s not as trivial and magical as some markitecture posters would have you believe! Whilst the service application model is a significant architectural improvement in SharePoint 2010 there is a lot to understand, especially when planning farm topology. There is more of course to this whole story, especially in regards to Proxy Groups, Multi-Tenancy and Federation. Those topics will be covered in future articles. Hopefully this breakdown is useful in addressing some of the misinformation out there.
As to the age old, “where should I host what services in my farm?” question, that too is the subject of a future article. Stay tuned!
.