Команда возврата WCF для запуска приложения

Question

В системе киосков, которую я настраиваю, все киоски связываются с центральным сервером для регистрации и получения команд обновления. Я не использую связь Dual Http, потому что не могу гарантировать, какие порты будут разрешены на клиентском сайте, поэтому связь всегда инициируется из киоска (клиента). В настоящее время у меня есть контракт на обновление, который возвращает перечисление с именем KioskAction, которое представляет все команды, которые может выполнять киоск (UpdateClient, SendLogFile, UpdateSetting и т. Д.). Это работает достаточно хорошо, но мне интересно, есть ли более элегантный способ справиться с этим.

Текущий метод обновления в киоске выглядит примерно так ...

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;
    ...
}

Моя проблема в том, что для того, чтобы добавить больше функциональности киоска, я должен перестроить и заново развернуть и приложение киоска, и службу WCF. То, что я рассматриваю, это возвращение какого-то скрипта (возможно, IronPython), который на самом деле содержит код, необходимый для выполнения действия. Тогда я мог бы добавить новые функциональные возможности, просто добавив новый скрипт в систему без каких-либо изменений в приложении Kiosk или в службе Kiosk.

Очевидно, что существуют некоторые проблемы безопасности, поскольку клиент Kiosk по сути выполняет любой код, который возвращает служба Kiosk, поэтому, если служба Kiosk скомпрометирована, все киоски также могут быть. Есть ли какие-то другие вещи, на которые мне нужно обратить внимание, или я должен принять это во внимание, прежде чем двигаться в этом направлении?

Answer 1

Вы могли бы также рассмотреть рабочие процессы Windows Workflow Foundation, а не код. Если вы используете декларативные рабочие процессы (иногда называемые рабочими процессами «только для xoml»), вы сможете поместить их в каталог и активировать их в общем. Это разработано, чтобы позволить это.

Answer 2

Я вижу пару рисков.

1. Вы создаете что-то конкретное для своих целей, когда уже есть удаленные инструменты администратора / обновления? Это тщеславный проект - где вы бы предпочли создать его самостоятельно, чем использовать то, что уже существует?
   Может быть, сделайте некоторое исследование addl, прежде чем создавать свой собственный механизм удаленного взаимодействия и исполнения IronPython.
   • С одной стороны, ознакомьтесь с PowerShell и, в частности, с возможностью размещения PowerShell (через RunSpace). Вы можете отправить код powershell до клиента и запустить его в PowerShell RunSpace , принадлежащем вашему клиенту WCF. Кроме того, вещь RemoteRunSpace давно может быть интересной. Не уверен, что в Powershell v2 это встроено. Если да, то это может быть полезно для вас.
   • ConfigService в StockTrader выполняет обновление настроек приложения, но не «запускает произвольный код». Доступен исходный код и arch doc для ConfigService.
2. Если вы решите пойти по пути «запустить любой код», обязательно добавьте в систему большую красную кнопку сброса на тот случай, если один из ваших сценариев не выполнит в точности то, что предполагалось, и приведет к 1000 удаленным киоскам. связи с внешним миром.