Нажатие сервера по сравнению с клиентским получением по запросу для топологии сервера агента
Я должен создать системное включение из 2 компонентов:
Единственный сервер, которые обрабатывают и хранят данные. Это также периодически отсылает обновления агентов
Несколько агентов, которые установлены в удаленных конечных точках. Они собирают данные в (часто, но не всегда) продолжительные операции, и эти данные должны добраться до сервера
Я использую.NET C#, и идеально я хочу использовать стандарты совместимый коммуникационный метод (т.е. тот, который мог теоретически работать с Java также, поскольку мы можем также использовать агенты Java в будущем). Там какие-либо альтернативы к веб-сервисам? Каковы мои опции?
Путем я вижу его, я имею 3 опции с помощью веб-сервисов и сделал следующие наблюдения:
- Клиентское получение по запросу
- Никакой открытый порт не потребовал в агенте, поскольку он действует как клиент
- Должен был бы опросить сервер относительно обновлений
- Нажатие сервера
- Открытый порт в агенте, поскольку это действует как сервер
- Сервер должен опросить агенты относительно результатов
- Гибрид
- Открытый порт в агенте, поскольку это действует и как клиент и как сервер
- Никакой опрос; сервер выставляет обновления при необходимости, клиент отправляет результаты, когда они доступны
'Гибрид' (то, где агенты являются и клиентом и сервером, кажется очевидным выбором - но это приложение будет обычно устанавливаться в средах предприятия и правительства, и я обеспокоен, что у них может быть проблема с открытием порта в агенте. Я живу слишком много на этом?
Есть ли какие-либо другие за и против, которые я пропустил?
4 ответа
Наши друзья из http://www.infrastructures.org клянутся механизмами, основанными на вытягивании: http://www.infrastructures.org/papers/bootstrap/bootstrap.html
Основная причина, по которой они предпочитают client-pull, а не server-push, заключается в том, что клиенты могут не работать, а клиенты должны (в общем случае) применять все операции, подталкиваемые серверами. Если этот критерий не важен в вашем случае, возможно, их вывод не будет вашим выводом, но я думаю, что стоит прочитать раздел "Push vs Pull" их статьи, чтобы определить для себя.
Если вы используете какой-то сервер обмена сообщениями (JMS для Java, не уверен для C#), то ваш сервер обмена сообщениями - единственный сервер, которому нужно открыть порт, и вы можете иметь двустороннюю связь от вашего агента к серверу обмена сообщениями и от сервера к серверу обмена сообщениями. Это позволит вам реализовать гибридную модель без необходимости открывать порт на сервере агента.
ИМХО, я считаю, что ваш лучший вариант - это вариант извлечения .., который может удовлетворить ваши основные системные требования, как показано ниже:
Первая часть: данные должны попасть на сервер, это очевидно может быть выполнено с помощью вызова веб-метода, который отправляет эти данные в качестве параметра
2-я часть: (Сервер периодически отправляет обновления агентам): вы все равно можете делать это, когда клиент (обычный) извлекает какую-то сеть сервисный метод, который «запрашивает» обновления с момента последнего извлечения (своего рода метка времени для получения пропущенных обновлений)
Гибридный метод кажется мне немного странным, учитывая, что я считаю агента частью система, которая, вероятно, может довольно часто отключаться, что будет делать сервер в случае сбоя? Обычно это трудный вопрос / решение, особенно если вы не уверены, что это намеренное «отключение» или сбой системы / сети и т. д.
Я бы сказал, что в наши дни вы можете серьезно рассматривать только тянущие технологии. Проблема с push заключается в том, что клиенты часто скрыты за устройствами обхода сетевых адресов (NAT), такими как беспроводные маршрутизаторы, широкополосные модемы или межсетевые экраны компании, и чаще всего недоступны для сервера.
Установление исходящих соединений («телефон-дом»), особенно на хорошо известных портах, таких как HTTP / HTTPS, можно в принципе считать «возможным» даже в самых ограниченных сетях.