I am building an app that allows users to execute some commands on a computer by sending them through email. The server will monitor (pull) one or more email accounts and start a communication session. Some authentication is also involved. I am using the latest and greatest .net technologies.
I am thinking to expose the server as a service but then I cannot have a GUI to allow the user to configure things like passwords and email accounts. How can I separate these?
And second, the commands will be pluginable and should provide their own GUI. How can I incorporate this? The server process should be able to use the command functionality and the GUI process should allow for customization.
I have used WCF, which is Microsoft's current technology for implementing web services and/or SOA. You would create a desktop client or webpage that makes calls to the WCF service. The WCF service(s) would be your server component, and the desktop client or webpage would be your user frontend.
It's mainly not a question of how to make service itself. And communication protocol is not the main issue -- with WCF you can expose your application methods via spectre of protocols. It's merely a question of application configuration.
Main question here is how do you like to implement GUI. If your application is normal windows service, then it can't have built-in GUI. Just because service should not have it. So you'll need separate GUI application. Options:
GUI is standalone .NET application that somehow communicates with your service. Let's say via WCF. In this case plugins should also be implemented in two parts: plugin for service and plugin for GUI. I think, it would be too complex to support.
Modification of 1st variant. Both service and GUI are packed in one executable. It looks in what mode it's started (service or standalone) and either monitors mail or shows GUI. Since this is one application, the configuration is also the same. So you will have single registry for plugins. I assume, that in GUI mode application will search for started service and configure it. Drawback - GUI could be run only locally.
You make a sort of "transferrable" GUI - service sends GUI to simple client, which shows it. In this case you have one place for all app code (service and GUI), but it's executed in part in service, in part in client software. But you also need such universal client software.
Thinking a little more about variant 3 we see that solution already exists - it is web technologies. It would be simplest to implement your service as part a web site. And GUI would be another part. If you are unfamiliar with HTML and Javascript you can implement GUI using Silverlight.
In fact, you can host ASP.NET right in your service. Here is the good explanation. But I afraid it adds unnecessary complexity
