I am developing a greenfield project which has two requirements.
- To be ran in the cloud (Azure).
- To be ran on a self hosted Windows Server installation.
This project is broken into 3 main parts.
- A collection of clients.
- A RESTful server.
- Persistent Storage.
For this question the clients are irrelevant, the RESTful server is built with ASP.NET WebApi (satisfying the requirements above) and the persistent storage is Azure Tables in case of the cloud or RavenDb when self hosted. And so to the question.
What is the best mechanism for scheduling jobs in this architecture that satisfies both requirements listed above.
I have a concept of jobs which are ran by querying the RESTful server and asking it to do a scheduled time check on any active jobs so the service really only needs to make a very simple rest query to start the process.
All the jobs and the logic to run them (They are templates) is on the server so no logic is required by the service.
Ultimately the best response would be some sort of ticker service that asks the service to preform the check. If I could build this directly into the ASP.NET WebApi server I would be even happier. It is a new tech to use so please excuse any glaring oversights I may have missed that would resolve this question.
One approach would be to write a very simple ‘scheduler service’ (similar in principle to quartz scheduler mentioned in the OP comments) written in [insert favourite .Net language here].
This service can be as simple or as complex as you wish; at the lower end it could simply operate a timer that at set intervals would invoke the REST API to trigger your process
The service itself could be written as a class library which can then be hosted within a Windows Service when deployed on a Windows Server installation; or, hosted within an Azure Worker Role when deployed to the cloud. When deployed in an Azure Worker Role the scheduler could easily run within an XS instance (1GHz CPU, 768MB RAM, 20GB Storage) at minimal cost – $14.40 per month at current prices.
This approach allows the same code-base to be used in both solutions (simply reference the class library project) and can be independently unit-tested.
Taking this approach one step further, you could automagically load the class library assembly at runtime, making future deployment and upgrades extremely easy.