Entity Framework Architecture for long running windows service

Question

I have a question how to best architecture my solution using Entity Framework in a windows service.

I want to provide an online (web-)service which allows users to execute possibly long running tasks, watch the progress of the tasks, cancel them, etc.

So far I am using a windows service to actually execute the tasks which exposes WCF endpoints to queue new work and manage existing tasks.

I am using Entity Framework to store a history of all jobs. However I am not completely sure how I should model the interaction between the background process of executing the jobs (with current progress inforation) and the wcf services exposing this status.

Should I completely seperate both parts, letting the background process periodically write the current state to the database and the WCF services poll the information from there?

Or does it make sense that the WCF service directly gets the information from the background process accessing a static member or something similar? Should they share a DataContext?

I would like to have the information current and it seems a bit strange having both the background processing and the WCF service running in the same process, but then communicating via the database, but on the other hand it seems to be a nicer architecture...

Thanks a lot!

Answer 1

I would recommend separating both the parts. And save the state in database, where in future you can also extend your architecture to multiple machines easily. Your database and web client access can stay at one server and long running tasks can stay at multiple servers.

Crashing one will not affect other. You will be able to log information correctly. Review the information and also prepare reports on time of execution and prediction etc can be generated if states are saved correctly in database.

Answer 2

A good solution include a message queue (MSMQ, table, whatever) between the Web interface and the workers.

The Web interface queues messages and poll their status as needed. The worker (possibly more than one) pick the message processes it and update the status.

If worker crash, message should return to the queue.