scheduled task or windows service

问题:

My team is having a debate which is better: a windows service or scheduled tasks. We have a server dedicated to running jobs and currently they are all scheduled tasks. Some jobs take files, rename them and place them in other directories on the network. Other jobs extract data from SQL, modify it, and ship it elsewhere. Other jobs ftp files out. There is a lot of variety, but all in all, they are fairly straightforward.

I am partial to having each of these run as a windows service instead of a scheduled task because it is so much easier to monitor a windows service than a scheduled task. Some are diametrically opposed. In the end, none of us have that much experience to provide actual factual comparisons between the two methods. I am looking for some feedback on what other have experienced.

回答1:

If it runs constantly - windows service.

If it needs to be run at various intervals - scheduled task.

回答2:

Scheduled Task -

1. When activity to be carried out on some fixed/predefined schedule.
2. It take less memory and resources of OS.
3. Not required installation.
4. It can have UI (eg. Send reminder mail to defaulters)

Windows Service -

1. When a continue monitoring is required.
2. It makes OS busy by consuming more.
3. Require install/uninstallation while changing version.
4. No UI at all (eg. Process a mail as soon as it arrives)

Use them wisely

回答3:

Sceduling jobs with the build in functionality is a perfectly valid use. You would have to recreate the full functionality in order to create a good service, and unless you want to react to speciffic events, I see no reason to move a nightly job into a service.

Its different when you want to process a file after it was posted in a folder, thats something I would create a service for, thats using the filesystem watcher to monitor a folder.

I think its reinventing the wheel

回答4:

While there is nothing wrong with using the Task Scheduler, it is itself, a service. But we have the same requirements where I work and we have general purpose program that does several of these jobs. I interpreted your post to say that you would run individual services for each task, I would consider writing a single, database driven (service) program to do all your tasks, and that way, when you add a new one, it is simply a data entry chore, and not a whole new progam to write. If you practice change control, this difference is can be significant. If you have more than a few tasks the effort may be comperable. This approach will also allow you to craft a logging mechanism best suited to your operations.

This is a portion of our requirments document for our task program, to give you an idea of where to start:

1. This program needs to be database driven.

2. It needs to run as a windows service.

3. The program needs to be able to process "jobs" in the following manner:

4. Jobs need to be able to check for the existence of a source file, and take action based on the existence or not of the source file. (i.e proceed with processing, vs report that the file isn't there vs ignore it because it is not critical that the file isn't there.

5. Jobs need to be able to copy a file from a source to a target location or

6. Copy a file from source, to a staging location, perform "processing", and then copy either the original file or a result of the "processing" to the target location or

7. Copy a file from source, to a staging location, perform "processing", and the processing is the end result.

8. The sources and destination that jobs might copy to and from can be disparate: UNC, SFTP, FTP, etc.

9. The "processing", can be, encrypting/decrypting a file, parsing a data file for correct format, feeding the file to the mainframe via terminal emulation, etc., usually implemented by calling a command line passing parameters to an .exe

10. Jobs need to be able to clean up after themselves, as required. i.e. delete intermediate or original files, copy files to an archive location, etc.

11. The program needs to be able to determine the success and failure of each phase of a job and take appropriate action which would be logging, and possibly other notification, abort further processing on failure, etc.

12. Jobs need to be configured to activate at certain set times, or at certain intervals (optionally during certain set hours) i.e. every 15 mins from 9:00 - 5:00.

13. There needs to be a UI to add new jobs.

14. There needs to be a button to push to fire off a job as if a timer event had activated it.

15. The standard Display of the program should show an operator what is going on and whether the program is functioning properly.

All of this is predicated on the premise that it is a given that you write your own software. There are several enterprise task scheduler programs available on the market, as well. Buying off the shelf may be a better solution for you.