This is the first part of a series on Service Applications. The following has already been posted:
Find the code for this sample on my CodePlex demo portal under the Navigation Service Basic release.
About Service Applications
One of the new features of SharePoint that I am super excited about is the new model for providing functionality that crosses the site collection boundary. Although technically you could already do this in SharePoint 2007 by creating a hierarchy of SPPersistedObject instances that you bind against either the farm or a web application, you now get a better programming model, easier integration with enterprise features such as backup / restore and claims security as well as one common UI platform for administrators to, eh, administrate your application. Awesome!
While there are many things that you can do with a Service Application, such as offloading load balanced calls to backend application servers through WCF you don't actually need to do this. There is a huge amount of flexibility in the framework meaning that quite quickly a Service Application becomes an interesting component to add to your solution. The key question to ask is obvious. When would you create a Service Application?
When to create a Service Application
As with all big questions there are many answers. Also the opposite is interesting, when not to do so. If you examine the built-in services there is one obvious, perhaps overlooked, common notion. They share data across site collection (across web applications typically). So one big motivator that I recognize for building service applications is exactly this need. Many of the medium / large sized document management solutions have this need to share data. I will not say that it is as easy as need shared data à thus application, RSS for one is also a great roll-up candidate. But especially this need is what I have time and time again implemented in one way, shape or form. A Service Application is a great way to express application level functionality that encompasses multiple site collections.
Components of a Service Application
Before discussing the types of Service Applications you can create, let's first focus a bit on the components that you have available. The global picture is not so big. The hierarchy of interesting objects is part of the configuration database and expressed as a series of SPPersistedObject objects. The hierarchy root being the SPFarm.
The SPService class represents a farm-wide service. It contains a collection of SPServiceInstance objects each of which can be seen as a component for that farm-wide service bound to a particular server in your farm. You for instance have the farm-wide database service which contains a SPServiceInstance for each actual server in your farm. What is new is that the SPService now has a collection of SPServiceApplication objects. Like the SPServiceInstance representing the service for a particular SPServer, the SPServiceApplication represents the service for a series of Web Applications. Each SPServiceApplication can contain specific resources to facilitate that goal. You might provision a database for each SPServiceApplication, meaning each instance of a Service Application has its own database. You might also, eh, not do this. It's all up to you. Many built-in services take this approach though. When you create and configure a new instance of a service application the administrator gets presented with a nice interface to create new databases with.
A large part of the scalability capabilities of the Service Application framework is the ability to offload data to backend application servers. SharePoint provides for this through integration with WCF as the communication platform. Typically your SPServiceApplication class will be the WCF host and you will create the SPServiceApplicationProxy derived class to communicate with this host. You can now use the SPServiceApplication on a backend server, and use the SPServiceApplicationProxy to talk with it from a frontend webserver. You can also add in some load balancing to further increase scalability.
Since SharePoint needs to know about what proxies you support you create a SPServiceProxy class that knows about your Service Application proxies. Note the distinction between the SPServiceProxy and SPServiceApplicationProxy. Like the SPService you'll most likely create only one SPServiceProxy per farm. Service Applications and proxies are created as needed. As such the SPService acts as a conduit for discovering SPServiceApplications and the SPServiceProxy acts as a conduit to discover SPServiceApplicationProxy objects.
Types of Service Applications
Given the different needs when expressing application level functionality there is quite some flexibility in how you can build a service application. There are of course benefits and downsides to each approach.
- Just a Service Application
This first type is the simplest case and the most inflexible. You only create a SPService and SPServiceApplication, no proxies at all. There is a big consideration however. Without having a proxy layer to your service application you'll not be able to associate web applications with your service (at least not easily, perhaps not at all). So, since you'll cannot bind a web application to the service application, you're left with having a single SPServiceApplication that services the entire farm (similar to the parent SPService). I am not sure if you should take this approach
- Direct proxy
The second mode of operation you do create a proxy layer, and hence you're configurable through Central Administration. However, you don't use WCF as a communication conduit between your service application and the proxy, but the proxy calls methods directly on the service application. Meaning, no offloading to application servers,
- WCF proxy
Perhaps the only 'real' service application, not sure on that yet. This time the proxy does use WCF framework to offload calls to backend servers. Also the hardest since you'll need to create more components and you'll need to understand WCF to a certain degree.
So, that concludes my first post on the new service Applications framework. In the next blog post I will introduce the simplest Service Application to facilitate a common SharePoint goal; cross-site collection navigation.
Hope it helps!