Print | posted on Tuesday, October 13, 2009 1:28 PM
The new Service Applications model in SharePoint 2010 presents significants improvements to the scalability of the SharePoint platform and offers tremendously exciting opportunities for developers and ISVs. This arcticle delves into the the Service Applications model and architecture, providing developers and IT Pros essential information on the new foundation of shared services in SharePoint 2010.
One of the least well understood aspects of SharePoint 2007 was that of the Shared Services Provider (SSP). Whilst not particularly complex there was very little accurate information at launch in books and blog posts etc. Even within the excellent Planning and Deployment Guides over on TechNet, SSPs were not covered in significant depth. One of the reasons for this was that most deployments were the simplest possible in terms of SSPs - they would include a single SSP. As customers looked to scale their deployments or implement advanced scenarios with more complex security requirements, getting guidance for how to implement SSPs was troublesome. Commonly held "myths" about SSPs are still apparent in many deployments and in much published material. Often when presenting my Mythbusters session I spend considerable time on the fundamentals of the SSP.
The good news is that with SharePoint 2010, Shared Service Providers are dead. The new Service Application model takes over. Service Applications are a huge improvement to the product, addressing many of the scalability compromises inherent in the SSP model. Service Applications can now be built by third parties and are available in both SharePoint Foundation and SharePoint Server. Service Applications significantly impact Farm Topologies and therefore it is more important than ever to understand the core concepts.
In designed Service Applications there were three main goals:
· Richness - the ability to deliver more features and allow third parties to build their own "shared services".
· Scalability - handle larger loads, scale farms, scale to the cloud
· Flexibility - to be more malleable in terms of granularity
In SharePoint 2007 Farm Topologies were pretty consistent. There were the "classic" models such as the "medium server farm" and the "large farm". Of course these could be expanded for various scenarios such as document conversions and content deployment, but in most cases the traditional model was appropriate. In the cases of some services there were fundamental tipping points where scaling further would not make sense.
With SharePoint 2010 the WFE tier has been optimised as has the SQL tier with heavy optimisation. The Application Server tier however is massively changed, with the Services Application model being the core driver of these changes.
For a start, there are many more services available out of the box. These include Access, BCS, Excel Services, Performance Point, Visio, Word, Office Web Apps, Project Server, Search, People, Web Analytics.
The new Service Application model represents a significant paradigm change. SSPs are gone (and good riddance!). SSPs were hard to understand and once they were presented a model which was often inappropriate. All services were grouped together in an SSP, even though the services offered radically different capabilities. Thus SSPs are hard to deploy, and even harder to manage over the lifetime of a SharePoint deployment. SSPs also didn't scale well, with effectively a single database.
In SharePoint 2010 therefore, services are split out into separate management units (Service Applications). Each of these can have its own database. For example, the Profiles & Audiences services are now the People Service Application and the Search service is now the Search Service Application. As mentioned above there are also many new Service Applications.
In many large deployments the concept of Inter-Farm Shared Services (IFSS) was a key planning consideration. Because at least two farms were required, such scenarios were an expensive proposition even for reasonably simple business requirements. With Service Applications, the Service Application itself can be cross-farm.
The new Service App model also removes the "association" barrier whereby a Web Application could only be associated with a single SSP. Web Applications can now consume services on an individual basis and can use any combination of the available Service Applications.
Also gone is the SSP Admin Web Site. Commonly misconstrued as the SSP itself this was just a Web App for managing the SSP. In SharePoint 2010 Service Applications are managed via Central Administration, not separate Web Application or Content Database is necessary.
The Service Application Model also allows you to deploy more than one instance of the same Service Application.
In part two of this article series, I will dive into the architecture of Service Applications, and map that to the resources on machines in the farm, and provide topology examples. Stay tuned!