Удаленное управление и сбор данных: WCF, SQL Sync, SyncFramework, BITS или что-то еще? - PullRequest
3 голосов
/ 14 января 2010

У нас есть несколько тысяч клиентских машин с Windows XP на различных сайтах клиентов, на которых все работает какое-то интерактивное программное обеспечение, которое оснащено для сбора анонимных данных об использовании. Клиентские машины используют некоторое старое, старое, старое клиент-серверное программное обеспечение, которое загружает данные на интернет-сервер, передает информацию о конфигурации обратно к ним и может попросить клиентов выполнить некоторые задачи, такие как перезагрузка.

По сути, у нас есть следующие функции (в псевдо C # / IDL):

interface IClientToServer
{
  void LogUsage(clientMachineName, anonymousUserID, Pair[] usageData, startTime, endTime);
  void LogError(clientMachineName, errorMessage);
  void LogUptime(clientMachineName, bootTime);
  DateTime SyncClock(clientMachineName, timezone);
}

interface IServerToClient
{
  void UpdateSettings(Pair[] settings);
  Bitmap GetScreenshot();
  void Reboot();
  string Execute(cmdLine);
}

.. но срок действия этого кода истек (хрупкий, не поддерживаемый из-за недостатка навыков).

Мы собираемся приступить к проекту «начинай с чистого листа», чтобы переработать это программное обеспечение с использованием современных инструментов, SDK и сред.

У нас есть некоторые функциональные требования:

  1. Среда на основе .NET благодаря доступным инженерным ресурсам.
  2. Брандмауэр дружественный - мы можем говорить только с клиентских сайтов на наш интернет-сервер через HTTP / 80, и доступ в интернет ненадежен при относительно низкой пропускной способности клиента. VPN непопулярны среди наших клиентов.

Мы довольно поражены огромным количеством технологий, которые мы могли бы использовать здесь: .NET Remoting, веб-службы .NET, WCF, Sync Framework, SQL Pub-Sub, SQL Sync, BITS и т. Д.

Мы могли бы получить представление о том, какие технологии лучше всего подойдут для дизайна.

Есть ли "естественная" посадка?

1 Ответ

1 голос
/ 18 января 2010

Я бы пошел с WCF. Вы можете легко настроить это для использования основного HTTP. При необходимости вы можете изменить привязки на любом конце, чтобы вы могли использовать другой протокол для связи. Это делает его гибким. Также вы можете разместить службу WCF так, как вам удобно (IIS, NT Service или любой другой процесс .NET, который вы можете придумать). Кроме того, WCF легко настраивается, а .NET предоставляет вам все инструменты, необходимые для общения, поэтому вам не нужно выполнять как можно меньше сантехники.

...