best practice for service - UI for the settings or not?

[mmy]

Hi,
I'm currently (re)designing software to register info sent out from a PBX (call loggin software).

One part of the program will be installed on a server, with the only purpose to gather the info and write it to a database. The main user interface (web application) will read this data and display it to the client.

However, the first part should be a service (since it has to run all the time, restart automaticaly when the server gets rebooted, ...). I can acomplish this with a service.

However, I have to make some settings in this program (like the IP address and port of the PBX, the location of the database, mailserver info, ....). If possible, I would like to change this info too with a user interface.

Which would be the best practice:
1) - create a service with a user interface and write/ read the settings to/from the windows profile (like my.settings.IP = xxx.xxx.xxx.xxx)

2) - create a service without a user interface and write/read the settings from a .txt or ini file. This ini fill will always be installed on a fixed location (ex. under program files). A separate windows form can be launched to change these settings.

3) - create a service without a user interface and write/read the settting in a simple database and table (ex. MS Access). Again, a separate windows form can be used to change these settings (the table will be placed in a fixed location)

4) - ?

Maybe there are better options to do this? Hope to hear them. Thanks

 

[johncroc]

Strange that there are no replies to this thread.

That being said...a windows service should never have a UI. The definition and purpose of a "service" is that it should require NO user interaction. Write your service to run completely autonomously, store its settings however seems best to you (I usually use the registry, but that is merely a personal preference), and write a completely separate application to view and edit those settings. In this model, you need to consider what happens when a setting is changed while the service is running. There are two basic choices: You can read the settings during the service startup process and simply document that if changes are made to the settings, the service must be restarted; or you can have the service periodically reload the settings and document that there may be a XX minute delay for the settings to take effect.