Service Applications in SharePoint 2010: Continued:

Readers as promised with all of you, I am writing up in continuation with my previous article of the Services Applications in SharePoint 2010.

Microsoft SharePoint Server 2010 includes a set of service applications that you can use to share services across Web applications. In some cases, you can also share service applications across farms. You can manage service applications by using Central Administration or by using Windows PowerShell 2.0.

Below are the details on the Service Applications and the detailed study link for them.

Service application references:

Access Services:
Access Services in Microsoft SharePoint Server 2010 is a service that allows users to publish an Microsoft Access 2010 Web database to a SharePoint site. When an Access Web database is published to SharePoint Server 2010, a site is created to host the Web database, plus it moves all of the database objects and data to a SharePoint list on that site.
Access Services administration:
http://technet.microsoft.com/en-us/library/ee692394.aspx

Business Data Connectivity:
Microsoft Business Connectivity Services are administered primarily by using the Business Data Connectivity service. Administrators of Business Data Connectivity service applications can perform operations on the source of data for those applications to maintain security and ensure appropriate access to data.
Business Data Connectivity service administration (SharePoint Server 2010):
http://technet.microsoft.com/en-us/library/ee661742.aspx

Document Conversion:
Microsoft SharePoint Server 2010 supports installing document converters on the server that let users transform documents from one format to another.

Conversions can be run either from the user interface or programmatically, such as from a custom workflow. The relationship between a source document and its transformed counterpart is maintained.
Manage document conversions (SharePoint Server 2010):
http://technet.microsoft.com/en-us/library/cc770227.aspx

Excel Services:
Excel Services in Microsoft SharePoint Server 2010 provides several methods to extend the capabilities of Excel Calculation Services, customize applications and workbooks, and also allow developers to incorporate Excel Services into their solutions.Excel Services in Microsoft SharePoint Server 2010 provides the ability to connect to external data sources and refresh this data.Excel Services administration (SharePoint Server 2010)
http://technet.microsoft.com/en-us/library/ee681487.aspx

Managed Metadata Service:Managed metadata is a hierarchical collection of centrally managed terms that you can define and then use as attributes for items in Microsoft SharePoint Server 2010.
Managed metadata administration (SharePoint Server 2010)
http://technet.microsoft.com/en-us/library/ee530393.aspx

PerformancePoint
To use PerformancePoint Services in Microsoft SharePoint Server 2010, you must configure a PerformancePoint Services service application. Once you have created the service application, you must provide data access to the users. This can be done by using the unattended service account, or by configuring Kerberos delegation.
PerformancePoint Services administration (SharePoint Server 2010)
http://technet.microsoft.com/en-us/library/ee681490.aspx

Search ServiceEnterprise search administration (SharePoint Server 2010)
http://technet.microsoft.com/en-us/library/ee792877.aspx

Secure Store:
In Microsoft SharePoint Server 2010, the Secure Store Service replaces the single sign-on (SSO) feature of Microsoft Office SharePoint Server 2007. The Secure Store Service is a claims-aware authorization service that includes a secure database for storing credentials.The Secure Store Service is an authorization service that runs on an application server. The Secure Store Service provides a database that is used to store credentials. These credentials usually consist of a user identity and password, but can also contain other fields that you define. For example, SharePoint Server 2010 can use the secure store database to store and retrieve credentials for access to external data sources. The Secure Store Service provides support for storing multiple sets of credentials for multiple back-end systems.Configure the Secure Store Service (SharePoint Server 2010)
http://technet.microsoft.com/en-us/library/ee806866.aspx

State Service:
State Service is a shared service that is used by some Microsoft SharePoint Server 2010 components to store temporary data across related HTTP requests in a SQL Server database. In SharePoint Server 2010, the State Service is required by InfoPath Forms Services (including out of the box and custom workflow forms), the SharePoint Server 2010 Chart Web Part, and certain Microsoft Visio 2010 scenarios that do not use Microsoft Silverlight 3.Manage the State Service (SharePoint Server 2010)
http://technet.microsoft.com/en-us/library/ee704548.aspx

Visio Graphics Service:
The Visio Graphics Service is a Microsoft SharePoint Server 2010 service application that allows users to share and view Visio web drawings using Visio Services. The service application also enables data-connected Microsoft Visio 2010 web drawings to be refreshed and updated from different data sources.Visio Graphics Service administration (SharePoint Server 2010):
http://technet.microsoft.com/en-us/library/ee524059.aspx

User Profile Service:
User Profile Service is a shared service in Microsoft SharePoint Server 2010 that enables the creation and management of user profiles that can be accessed from multiple sites and farms. Administration of User Profile Service applications is much simpler in SharePoint Server 2010 and can be delegated to a service application administrator by the farm administrator.User Profile Service administration (SharePoint Server 2010):http://technet.microsoft.com/en-us/library/ee721050.aspx

SharePoint 2010 Service Applications

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!

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.

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

If you have any queries/questions regarding the above mentioned information then please let me know. I would be more than happy to help you as well as resolves your issues. Thank you.

In Next Artcile I will try to publish the list of SharePoint 2010 Service Applications and thier use.