One of the new features of SharePoint that you should be super excited about is the new model for providing functionality that crosses the site collection boundary. As you might be aware, the site collection is typically the place where integration between content sites stops, but it's also a place where the need to have more begins.
Take cross-site navigation as a prime example. Many larger SharePoint installations follow a model where separate departments get separate site collections by virtue of having different owners and usage profiles. However, this doesn't always play nice with the need to provide one common navigation infrastructure to easily get from point A to point B, even when the points are in totally different locations. Of course, you can imitate by storing the same navigation hierarchy twice, but this design decision introduces unwanted administrative overhead. The answer? Service Applications to the rescue.
Technically you could already achieve site collection spanning logic in SharePoint 2007 by leveraging SPPersistedObject instances that you bind against a web application. This idea has now been formalized, giving you a better programming model, and easier integration with enterprise features such as backup / restore or claims security. On top of that, you now have one common UI platform for administrators to interact with the services that you provide.
To build a Service Application, you need four components. First, you create a Service. The Service can be thought of as the "idea" that you're implementing. The Service class is used by SharePoint as an access point to learn about the second component: Service Applications. Think of a Service Application as the component that implements the idea defined by the Service. Each Service can have multiple instances of the Service Application, each Service Application being a distinct entity with its own backend infrastructure, such as a database.
After setting up this basic structure, you then take the next step and add a Service Proxy and a Service Application Proxy. The interesting stuff here is the Service Application Proxy.
This proxy class lets you bind a Web Application to the logic provided by a single instance of the Service Application. As such, it's the intermediate component letting you talk to the service on behalf of a consumer. The Service Application Proxy abstracts the manner in which this communication takes place.
Under the covers, the proxy talks to the Service Application using WCF channels. This lets you offload the incoming calls to backend application servers where the Service Application runs. Of course in single-server environments everything can execute on one machine. The second proxy, the Service Proxy, is an entry point for SharePoint that lets you integrate with the management pages and configuration wizard. Using the system of proxies, you get the benefit of a scalable architecture with which you can service thousands of site collections, or a few site collections that have a high level of demand. Of course, don’t forget to add a service consumer, a Web Part for example, so that your application isn't left gathering virtual dust up in the Application attic.
The investment in this new core model can be noticed in a variety of places in the SharePoint object model. Earlier, when you needed to access shared components, you would use the ServerContext class. You now get a ServiceContext class that in essence does the same. It's the contextual entry point that you can use to retrieve the current proxy depending on the Web Application your code is running in. Great examples that you might work with are the search application or the Business Connectivity Services (BCS) object model. Practically everything that is provided as a service lets you talk to that service based on this context.
If you're experiencing demand for cross-site collection features, be sure to check out this new advanced architecture. To give it a go, don’t forget that you can find a complete sample application in the members section of the Critical Path website. I have also written a few words on the topic on my blog with smaller samples guiding you through the process of creating these nifty SharePoint components.
