SharePoint 2010 Service Applications Architecture Tips and Details

The last days I have been working on some new SharePoint 2010 project , and as you know that one of the first steps in the SharePoint project you need to design and architect farm topology and it’s configuration. One very important stage at the project architecture is the Service Applications Architecture , I finished working on it and I had discovered some details that can be considered as limitations and other as cool features and I will share it here with you. And as always in Service Applications Architecture IT DEPENDS !

So Service Applications ‘provides a resource that can be shared across sites within a farm or, in some cases, across multiple farms.’ as TechNet define it , the architecture is summarized above. Here are the some details and tips that can help you in architecting and configuring  the Service Applications :

1. The services that can be shared amongst multiple farms  are User Profile , Search , Managed Metadata , Business Data Connectivity ,Secure Store Services and Web Analytics. The other services  like Excel Service , Access Service , Project Server , Performance Point Service … etc cannot be shared.
2. You can configure your Web Application to consume services from different applications and also you can configure the service to be used locally.
3. Deploying multiple farm services can be done using three steps , first exchange the trust between the farms , second publish your service , and third create connection to remote farm then service.
4. Although you create different instances of the same service using different names if that suites your architecture .
5. Services that access external data need to have special consideration. The services are Excel Services , PreformancePoint Services , InfoPath Services and Visio Services . The considerations are the external data need to be within the same domain if the access is done by delegated Windows identity ,and  as alternative you can use Secure Store Service stores . there is no third option here.
6. The service applications are deployed within single IIS WebSite , you cannot change such thing . But the good thing that you can customize the configuration of  groups for it and the association of web applications with groups.
7. Creating multiple groups within your Service Applications can make it complex and hard to manage , you should plan and architect it carefully in the enterprise farms.
8. Service Groups can be used to logically scale for performance, security and scalability. if it’s planned and architected  in appropriate way .
9. Architecting service farms has some consideration , If it’s required to have Multi-Tenancy , you should think about creating custom groups that serve your need. For example you can create custom group for publishing portals Application pools and web application that use Managed Metadata , Search , User Profile,  Business Data Connectivity and Secure Store service.  Other issue can be data sharing amongst farms (Centralized based) , this way is easiest way to manage and implement ,also the resources can be used more efficiently in the farm.
10. You can isolate service applications by deploying them to separate application pools to achieve process isolation. (Multi-Tenancy)
11. You can isolate the service data by using the partitioned mode using PowerShell in hosted environments. And not all the services support  partitioning.
12. You can develop your own Service in Service Applications , it has built in support for building applications using WCF .
13. Enough today , or you can add it by posting your feedback.

HTH ,

Saed