One of the most interesting and powerful new things in SharePoint 2010 is the shift away from shared service providers (SSP’s) and the move to service applications. This area is of great interest to me as I see this as having huge potential for SharePoint to have it’s own internal cloud!

Later this week, Thursday, October 22 @ 12p specifically, I’m presenting a session at the SharePoint Conference on creating custom service applications (session SPC406). This is a HUGE topic… definitely not for the light hearted developer. Unfortunately when I present that session I won’t have time to cover all the ins and outs of what the service architecture is and how it works… but I’ll do a very quick rundown.. spending most of my time on how to create custom ones. In this post I want to provide a bit more back story and point you to some other really good resources regarding custom service applications.

If you’re planning to attend SharePoint Connections in a few weeks in Vegas I’ll have a breakout session there on creating custom service applications as well.

Why the shift away from Shared Service Providers (SSP’s)?

SSPs were pretty handy in Office SharePoint Server 2007. They allowed us to create a configuration of profiles, audiences, Excel Services, BDC and search that we could share between two Web applications. But what if we wanted one Web application to simply use the same search configuration in one SSP but have a totally different profile / BDC configuration? The only option was to create a new SSP and dupe the search config… but these two SSPs were totally independent.

Another trick was the scalability of SSPs. We couldn’t just say “here are four new servers that just do SSPs” very easily. Nor was it easy to share an SSP across SharePoint farms.

Enter the new Service Application Architecture in SharePoint 2010

Simply put: Microsoft took a sledge hammer to the SSP architecture and broke it into pieces. Think of service applications as little programs, but don’t think in terms of an individual EXE or DLL. Instead, think of it more like a complete application that may be comprised of multiple assemblies, databases, timer jobs, Win32 services, external systems, etc.

You take this service application, and deploy it to a SharePoint App Server. Now… a service offering is almost worthless unless you can consume it, right? The consumption piece, in SharePoint, happens on the SharePoint Web Front End (WFE') level. So you need to connect your service applications to the WFE’s. This is done using a proxy (don’t think WCF/ASMX proxy… think of it in the more generic term for now).

This proxy knows how to talk to your service application, exposed on the app server by a custom WCF service. Now, you can have a consumer, such as a Web Part, that talks to the proxy to communicate with the service. One of the coolest parts of this is that the consumer doesn’t have a clue where the service is running.

One major advantage to this new architecture is the flexibility in scaling service applications up and out. Let’s say your service application is in high demand at specific times of the year, such as tax season. All you’d do is deploy your service application to additional app servers and fire up a new instance on that box. When the proxy on the WFE polls the farm asking “where is the WCF service of the service app I’m need to talk to", the service architecture’s internal round-robin load balancer will pick the next server where that contains an instance of the service application and hand the URI of it’s specific WCF service back to the proxy which it will then use to communicate with the service application where the real fun happens.

Another cool thing is that you can publish your service application to other farms. To do this you simply install the service application’s proxy in the other farm and point it to a specific URI provided by Central Administration when you publish the service application. This enables enterprises to have dedicated service farms that can be specially configured based on the services that are provided (search, taxonomies, analytics, data aggregation, etc). They could then share these service offerings with other SharePoint farms in the enterprise or with customer farms!

If you’re at the SharePoint Conference this week, make sure you see (or watch the recordings) the following sessions that cover the new service architecture… they aren’t exactly developer topics, but they will help you understand what this architecture is all about:

• Introduction to Service Applications & Topology – Tuesday @ 9a
• Scaling SharePoint 2010 Topologies for your Organization – Tuesday @ 1030a