Step by Step SharePoint Service Applications: Intro

In the following blog posts, I’ll be focusing on writing custom service applications for SharePoint 2010. Service Applications are shared services that are managed in Central Administration that can be consumed by the local or remote farms. Service applications can include a WCF backend service, timer jobs, custom database(s), permissions and central administration management.

For trivial web part applications, a Service Application is overkill. But to move your application to a service-based architecture that can be consumed across the enterprise (by SharePoint farms, that is…) then you should consider a Service Application.

Reasons to write a service application:

1. You need a custom database
2. You need Central Administration of your application
3. You want to publish your application services to multiple web applications
4. You want to publish your application services to multiple SharePoint farms

Probable the best use case example of a managed Service Application is the SharePoint User Profile Application. It provides the “User Profile” framework with My Site and My NewsFeed integration across your SharePoint web applications, even across multiple SharePoint farms.

There are multiple sample applications and blogs about this (just use the google!) but I found them a bit tough to follow, and not very repeatable. After shipping 2 enterprise class Service Applications at NewsGator, I decided it’s time to break it down into it’s simplest repeatable pattern. So in the following posts, we’ll talk about:

1. The “Core” of the Service Application: SPIisWebServiceApplication
2. Service Application Plumbing: Service instances, service provisioning, proxies, and more.
3. Service Application Plumbing: WCF, the Hard Way
4. Deploying the Service Application in a WSP.

SharePoint Projects (WSP projects) are ONLY for Deployment

To start off, it’s important to get a good, clean code story. Whenever I write solutions for SharePoint, I follow the golden development rule: “WSPs are ONLY for Deployment”. Keep your code in a class library. Following that rule will make your code much cleaner, simpler to follow, and reusable. For example, at NewsGator we have a WSP deployment project, a data contract project, a service library project (for the Service Application), a Web Part project, and code libraries. I recommend splitting up your code into a similar structure, it makes references a whole lot easier and separates out boundaries. But at a minimum, you’ll need a WSP project for deployment, and a class library.

Credit

The first pass of my service applications came from Andrew Connell’s sample code. You may find some remnants of that in the code I post, however it’s mostly rewritten from scratch. Big thanks to AC for writing the first reliable sample service application.

Let’s Go!

To get started, create a SharePoint project named SuperCoolServiceApplication, and a class library named SuperCool.ServiceLibrary. Then follow along the next few posts and you’ll be up and running with your own service application in no time. First we’ll cover the basics. Then we’ll go back and add a database, jobs, and security.

In the class library, make sure you add references to Microsoft.SharePoint and System.ServiceModel. Then get ready, we’ll dive into writing code in the next post.

Continue on to part 1!