Service with monitor/control application...
-
A question of architecture/implementation... I have a Windows service that periodically contacts a central server with status information and the intent is that it can also make a request for work to perform. I have also created a systray app that can be used to manually contact the central server and will also have the ability to make a request for work. Think SETI@Home... What is the best way for these to work together? I've seen plenty of samples on how to get a Windows Forms app to communicate with the SCM to start/stop a Windows service, but what I want is a bit deeper than that. I want to know if the service's last request for work resulted in it starting a job, and if so, what is it working on? I moved all the common code out of both the service and systray app into a central library that they both reference. Should the common library just be maintaining some local status database that either can query? Or can the service do all the work all the time, and the systray simply connect to the service and drive/monitor it? Any suggestions/tips/thoughts greatly appreciated. Any references to online samples also appreciated... Cheers, Carl ...Every time I press the little black button on the black panel, a little black light lights up to let me know I've pressed it...
-
A question of architecture/implementation... I have a Windows service that periodically contacts a central server with status information and the intent is that it can also make a request for work to perform. I have also created a systray app that can be used to manually contact the central server and will also have the ability to make a request for work. Think SETI@Home... What is the best way for these to work together? I've seen plenty of samples on how to get a Windows Forms app to communicate with the SCM to start/stop a Windows service, but what I want is a bit deeper than that. I want to know if the service's last request for work resulted in it starting a job, and if so, what is it working on? I moved all the common code out of both the service and systray app into a central library that they both reference. Should the common library just be maintaining some local status database that either can query? Or can the service do all the work all the time, and the systray simply connect to the service and drive/monitor it? Any suggestions/tips/thoughts greatly appreciated. Any references to online samples also appreciated... Cheers, Carl ...Every time I press the little black button on the black panel, a little black light lights up to let me know I've pressed it...
I would hook a database onto the server end of the process. As you receive jobs, drop the info for that job into the DB. As you start it update a progress table. when you finish it etc... When the client wants to know where its job is, query the DB and return its history. The best thing with doing it this way is that when the service restarts after a system failure (power cut etc) it knows where it was and can start up again where it left off. Not sure about online references i'm afraid Russ
-
I would hook a database onto the server end of the process. As you receive jobs, drop the info for that job into the DB. As you start it update a progress table. when you finish it etc... When the client wants to know where its job is, query the DB and return its history. The best thing with doing it this way is that when the service restarts after a system failure (power cut etc) it knows where it was and can start up again where it left off. Not sure about online references i'm afraid Russ
Russ, Thanks for the response... Yeah, as I was writing my original post, I was starting to consider that rather than having the systray app be capable of driving the service, I should just hav ethe two operate independently, but reference the same core library which does the work. And the important addition is that the core library needs to persist its state in a local database. I'm trying to keep the client pieces very light however, so hopefully I can construct a reasonable XML file that can maintain all local information... Thanks again... Cheers, Carl