SharePoint 2010 Service Applications Architecture (SSA)
If you have any experience in administering MOSS farms, you probably already know how isolated Shared Service Providers (SSPs) can be and how extremely difficult is to restore an SSP in case of disaster recovery. The good news is that for SharePoint 2010 SSPs are gone and we now we have more flexible services that can be shared even between farms – SharePoint Service Applications (SSA).
Before we take an indepth look at SSA, we will need to take a look at the terminology Microsoft uses when describing the new Service Applications architecture.
| Core functionality Name | Description |
| Service | A set of binaries installed on the server farm which are capable of some functionality. |
| Service Application | The Service described above but configured for a specific SharePoint farm. |
| Service Application Proxy | The Proxy service is really a pointer to a Service Application within the farm that exists on the Web front-end. |
| Service Instance | The instance of the Service Application running on the application Server. |
| Service Consumer | A feature such as a Web Part which is using the Service Application to communicate with end-user and present the service results to the browser. |
Table representing new core-service definitions
SharePoint 2010 Architecture vs SharePoint 2007 Architecture
In the example architecture below you can see that we have two SSP’s in the farm, each has its own set of Services and applications. In this SharePoint 2007 environment you can’t share services between SSP’s and especially between farms. You have to setup new services for every SSP you create.

Office SharePoint Server 2007 Service Architecture
In the SharePoint 2010 architecture below, you can see we do not have the SSP. It is simply not needed since we are now using Application Service instances for every web application we choose and the services can be shared between different web applications. In our example we are using the same User Profiles service for all web applications, and dedicated services for every application such as Search Service, BCS (BDC) Service, Access and Visio Services, etc. You may even share the Service Applications between SharePoint farms under Service Application Publishing.

SharePoint Server 2010 Service Architecture
Because of these architecture changes, it is now more complex to plan and design the SharePoint environments based on farms and services. In SharePoint 2007 we simply had to create an SSP and applications under it, with all the required services attached to the isolated SSP environment. Whilst SharePoint SSA is a major advance, not all services can be published (which means not all can be shared between SharePoint farms):
| Services that can be published | Services that cannot be published |
| Users and Profiles (People related applications) | Usage and Health Services |
| Metadata Services | Site Services |
| Business Connectivity Services (BCS) | Project Services |
| Search Services | Excel Calculation Services |
| Secure Store Services | Access Web Services |
| Web Analytics Services | Visio Web Services |
| Word Web Services | |
| Performance Point Services |
Service Application Publishing possibilities for SharePoint 2010
In general, services that are based on Web applications (Word, Visio, Access, and Excel) cannot be shared between farms but they still can be shared between the web applications so it is probably not a major issue. Now, the overall concept of the new SharePoint Services architecture is now clear, let’s go deeper and see how it works from administrative viewpoint.
Continues…
Pages: 1 2
Array




No comments yet... Be the first to leave a reply!