Jobs

Stick some jobs in the service to execute

In order to have all this nice and easy in one solution, you'll have to run the service and demos in the following way :

Implementing your own jobs

The first step to understanding jobs is to look at the sample projects. If you open "BackgroundWorkerService.Logic.TestJobs" folder, you'll find 3 sample very simple jobs that don't do anything.

A job is simply a class implementing BackgroundWorkerService.Logic.Interfaces.IJob interface. There's only one method

Execute(string jobData, string metaData)

jobData is whatever you passed in when creating the job. It could be anything, from an empty string, a number (stored as string) or for more complex cases a serialized class. You'll usually store something like an ID or record in there for processing, anything that is specific to this INSTANCE of the job.

metaData is more about storing information that you wouldn't exactly call part of the identifying info. For example, your job could count the number of times it has executed and after 5 times give up.
metaData is also different to jobData in that if it is set in your job, it will be persisted to the job store after your job has returned from execution.
If you look at "BackroundWorkerService.Jobs.BasicHttpSoapCallbackJob" (a job implementation that allows remote callbacks), you'll find the metaData field wraps some information about the callback around the actual job's metaData.

Some items of note when implementing jobs :