tags:

views:

115

answers:

2

In the kiosk system I'm setting up, all Kiosks communicate with a central server to check in and receive update commands. I don't use the Dual Http communication because I can't guarantee what ports are going to be allowed at the client site, so communication is always initiated from the Kiosk (client). I currently have an Update contract which returns an enum called KioskAction which represents all of the commands that a kiosk can do (UpdateClient, SendLogFile, UpdateSetting, etc). This is working well enough, but I'm wondering if there is a more elegant way of handling this.

The current Update method on the Kiosk looks something like...

var kioskAction = KioskService.Update(kioskId);
switch(kioskAction)
{
    case KioskAction.SendLogFile:
        KioskService.SendLogFile(kioskId, GetLogFile());
        break;
    case KioskAction.UpdateSettings:
        Setting[] settings = KioskService.GetKioskSettings(guid kioskId);
        UpdateSettings(settings);
        break;
    ...
}

My problem with this is that in order to add more kiosk functionality, I have to rebuild and redeploy both the kiosk application and the WCF service. What I'm considering is returning a script of some sort (probably IronPython) which actually contains the code necessary to perform the action. Then I could add new functionality just by adding a new script to the system without any changes to the Kiosk application or the Kiosk Service.

There are obviously some security concerns since the Kiosk Client is essentially running any code that the Kiosk Service returns, thus if the Kiosk Service is compromised, all of the Kiosks could be as well. Are there any other things I need to watch out for, or I should take into consideration before moving in this direction?

A: 

A couple risks I see.

  1. Are you building something specific for your purposes when there are already remote admin / update tools out there? Is this a vanity project - where you'd rather build it yourself than re-use what already exists?
    Maybe do some addl research before building your own IronPython remoting-and-execution thing.
    • For one thing, check out PowerShell, and specifically the powershell hosting capability (via RunSpace). You can ship powershell code down to the client and run it in a powershell RunSpace owned by your WCF client. Also, the RemoteRunSpace thing from a while back may be interesting. Not sure if Powershell v2 has this built in. If it does, it it might be useful to you.
    • The ConfigService in StockTrader does app-settings update, but not "run arbitrary code". The source and arch doc for the ConfigService is available.
  2. If you choose to go the "run any code" route, be sure to add a big red reset button to the system in case one of your scripts doesn't do exactly what was intended, and leads to 1000 remote kiosks being incommunicado.
Cheeso
This is probably a case of me just overengineering it. It isn't designed for remote management so much as limited communication between the kiosk and the kiosk server. We already have a remote admin / update tool in place, but this is more for automated reporting.It would allow me to centralize the code that tells the kiosks when they should send in their usage reports, purge old log files, etc. As it stands, I believe I'll leave them the way they are, which is accepting an enum returned from the Service and running an action based on that. KISS.
Timothy Strimple
+2  A: 

You might also consider Windows Workflow Foundation workflows, rather than code. If you use declarative-only workflows (sometimes called "xoml only" workflows) you should be able to drop them in a directory an generically activate them. It is designed to allow this.

Anderson Imes
These look quite interesting, I'll take a closer look. Thanks!
Timothy Strimple