Опубликовать / Подписаться / Запрос на обмен большими, сложными и конфиденциальными данными? - PullRequest
Новая
       28

Опубликовать / Подписаться / Запрос на обмен большими, сложными и конфиденциальными данными?

2 голосов
/ 30 марта 2012

Я работаю над проектом, где веб-сайт должен обмениваться сложными и конфиденциальными (и, следовательно, зашифрованными) данными с другими системами. Данные включают личную информацию, технические чертежи, публичные документы и т. Д.

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

С другой стороны, я не уверен, что будет подходящим чистый шаблон издателя / подписчика - в основном из-за сложного и громоздкого характера данных, подлежащих обмену.

По этой причине мы обсудили возможность решения "опубликовать / подписаться / запросить". Часть публикации / подписки будет публиковать сообщение для зависимых систем, что что-то готово для получения. Фактический контент затем выбирается действием старой школы «запрос-ответ».

Как это звучит для вас ??

С уважением, Morten

Ответы [ 3 ]

3 голосов
/ 30 марта 2012

Если системы всегда в сети, звучит хорошо .

Возможно, вы захотите взглянуть на PubSubHubbub , потому что: 1. Не решайте проблему, которая уже была решена 2. Она масштабируема и представляет собой хорошее разделение задач.

В нем участвуют 3 стороны:

  1. Издатели (которые публикуют материалы)
  2. Подписчики (которые заинтересованы в определенных публикациях)
  3. Хабы (которые являются посредниками и избавляются от "опроса")

Работает следующим образом:

  1. Абонент регистрирует свой интерес к URL-адресу с помощью концентратора и предоставляет URL-адрес для обратного вызова.
  2. Издатель уведомляет концентратор о публикации контента.
  3. Концентратор получает дельту и передает ее заинтересованным подписчикам.

Сам протокол является расширением для Atom, но, похоже, он соответствует вашим требованиям, например, новым «контентом» Atom может быть элемент, содержащий URL-адреса недавно опубликованных документов (которые затем можно загрузить отдельно).

Новые / измененные документы => новые / измененные элементы в фиде, содержащие URL-адреса для их извлечения => Концентратор => Подписчики => Извлечение документов из издателя

3 голосов
/ 30 марта 2012

Я не очень разбираюсь в этом, но очередь сообщений должна помочь вам выполнить то, что вам нужно. Я использую такую ​​систему при управлении публикацией данных для нескольких клиентов переднего плана из серверной части.

Если клиент выключен, данные не используются, и сервер не получает подтверждения получения данных. Как только клиент возвращается в оперативный режим, он использует данные и продолжает прислушиваться к новым сообщениям, и очередь становится чистой. И, конечно же, издатель получает подтверждение за использование данных. Таким образом, мы можем идентифицировать и уведомлять людей, у которых есть проблемы на приемной стороне, в качестве бонуса. Может ли это сделать это в вашем случае?

1 голос
/ 30 марта 2012

Этот подход работает, если зависимые системы всегда подключены к сети - вы не можете отправлять сообщения на компьютеры, которые отключены на ночь / выходные дни.

Так что, если клиенты являются серверами, которые работают 24/7,это работает.В противном случае попробуйте такой подход:

  1. Разрешить клиентам регистрироваться самостоятельно
  2. Когда приходят новые документы, добавьте запись "клиент Х должен видеть это" в вашей базе данных
  3. Когда клиенты подключаются, отправьте им все записи.
  4. Когда клиенты успешно загрузили документ, удалите запись «клиент Х должен видеть это».Это делает рабочий стол небольшим.

У этого есть несколько преимуществ:

  1. Клиенты не должны запускаться 24/7
  2. Флаг толькоудален после того, как клиент увидел документ (поэтому обновления не могут быть потеряны).
  3. У вас есть одно место, где вы можете увидеть, какой клиент никогда не извлекает свои документы.Простой select client, count(*) group by client having count(*) > 10 сообщает вам о проблемах.
  4. Большинство клиентов будут получать свои данные своевременно, поэтому рабочий стол останется небольшим.Это означает, что при сборе данных «что сейчас» нужно немного затрат.

РЕДАКТИРОВАТЬ Проблема с автономными подписчиками заключается в том, что они не знают, что онипропали.Поэтому отправляющей стороне необходимо отслеживать неудавшиеся push / pull запросы.Это означает, что вы должны реализовать мой предложенный псевдокод, чтобы возобновить прерванные соединения.

...