The last session on the last day on the conference was presented by Andrew Connell, no intro needed there I think. Connell showed us partly how the new service application architecture was set up in 2010. As I have mentioned before the Shared Service Provider is gone and replaced with a new architecture which is much much more solid and extensible. Extensible seems to be one of the keywords for this release.
A big disadvantage in 2007´s SSP model was that we basically had to go with all or nothing (you either had the SSP or you didn´t). The SSP was also not extensible and web apps were tied to specific SSPs that in return were tied to a specific farm.
This story changes in 2010 as seen in the screenshot above.
Application Service model features:
- Integrated round-robin load balancer
- Claims based authentication
- backup/restore functionality
- UI in Central Admin
- Controllable though PowerShell
So when should you be in the business of writing a custom service application and how hard is that actually to do?
If you need to share data across sites & site collections or you need to execute long running operations that require a robust scale out strategy then you need to go into the business of writing your own. I can already think of a couple of scenarios were this will be the case.
So, as you can see in the architectural overview that is shown above you have a couple of areas were you need to go in and supply your own implementation of these different parts. Connell showed us how to do that and promised to out his code out on the blog ASAP so this will probably be a base for all other implementations of custom service applications.
A service application consists of many components. As you can see in the screenshot above the service app consumers live on the WFE server and then communicate through a proxy to the app server where a WCF service answers the call.
So it now seems that SharePoint developers have to know how to write WCF services, PowerShell cmdlets, and communicate through LINQ and REST (among other things). This is a development that I rather like, cause I have used this stuff for a while already and just been sad that SharePoint didn´t support them OOTB.
Lastly, I have to mention one new thing, that I hadn´t seen before. If you look in the screenshot above each WCF service now lives in a folder called WebServices in the 14 hive. Each service then lives in its own folder with its own web.config file!
Why is this important? Well, remember writing custom code to those horrific APIs for customizing the web.config. Well now we just provision a file, right?