Как обеспечить передачу сообщений с помощью опроса / опроса с веб-сервера - PullRequest
Новая
       73

Как обеспечить передачу сообщений с помощью опроса / опроса с веб-сервера

0 голосов
/ 27 октября 2010

Это основано на Как отправлять сообщения между компаниями . Если я решу, что компания S (upplier) должна опрашивать заказы компании (B) каким-то простым способом на основе HTTP, что является наилучшей реализацией.

  • Я предполагаю, что в компании B запущен веб-сервер, а внутренняя база данных этого веб-сервера надежна. Мы должны сделать как можно меньше возможных предположений о процессах хранения в S и о том, могут ли они сохранять состояние (например, список уже переданных GUID)
  • Интернет-соединение между B и S ненадежно.
  • Мы должны достичь возможной согласованности , означающей, что в один момент времени все ордера между B и S. должны быть переданы.

Какова наилучшая практика для внедрения такой системы?

Ответы [ 5 ]

3 голосов
/ 27 октября 2010

Одним из подходов к решению этой проблемы является использование какого-либо продукта для организации очередей, как сотрудника IBM, которого я сразу считаю MQ. Однако, поскольку я сам не являюсь MQ-человеком, как и вы, я, вероятно, был бы доволен подходом, основанным на обслуживании, который вы используете.

Есть два возможных подхода, которые приходят на ум. Одним из них является использование WS Reliable Messaging , которое выталкивает проблему надежности в инфраструктуру веб-служб. Другой способ - запустить собственный надежный протокол поверх простых, но ненадежных услуг.

У меня нет серьезного практического опыта по внедрению системы с WS Reliable Messaging, я верю, что это можно сделать, чтобы работать, но это требует некоторой степени контроля над участниками - так как это сравнительно недавний стандарт, который мы не может гарантировать, что у любого данного ИТ-магазина будет реализация, и взаимодействие между поставщиками может быть проблемой. Чем больше у меня контроля над SW-стеками на каждом конце, тем больше у меня шансов использовать WS Reliable Messaging. [Я должен также упомянуть WS Atomic Transaction, которая также может быть использована для создания надежных сервисов; применяются те же проблемы взаимодействия.]

Так как насчет того, чтобы покататься? Ключевым моментом здесь является сделать все услуги идемпотентными. Поскольку у нас нет транзакционных гарантий, которые охватывают две системы, мы должны предположить, что любой вызов службы может произойти сбой с неизвестным результатом.

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

B должен предлагать такие услуги: 

 Give me the next order(s)

 I have stored {orders ...}

Так, как мы определяем «следующее». Простейший случай хорошо работает, если объемы, с которыми мы имеем дело, могут позволить нам иметь одну «нить» передачи. Затем B тикает по отправленным заказам по одному, и у заказов есть монотонно увеличивающийся идентификатор. Затем мы можем упростить до: 

 I have stored order <65,004> please give me the next

обратите внимание, что это идемпотентный запрос: его можно безопасно повторить много раз. Также обратите внимание, что S должен предвидеть возможность получения одного и того же заказа дважды и проверять наличие дубликатов.

1 голос
/ 10 ноября 2010

Я думаю, вы пытаетесь сказать, что Компания B является пассивным участником. S (поставщику) просто необходима возможность получить все заказы, которые B публикует (возможная согласованность). Но B не нуждается или не заботится о том, какие ордера S уже есть (нет необходимости в коммите).

Если компания B имеет полуточные часы, вы можете использовать дату в качестве монотонно увеличивающегося GUID, в зависимости от разрешения событий - вы не захотите опрашивать, если вам все равно нужно разрешение в миллисекундах. Вы используете только часы B, поэтому вам не нужно беспокоиться о синхронизации. Если B публикует все заказы, S может просто забрать заказы с того места, где он был остановлен в последний раз.

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

Это может быть некрасиво, но звучит так, как будто вы не ожидаете большой сложности от компании B. Используйте SSL и аутентификацию, и она заблокирована и зашифрована.

Если вам не нужна производительность, в простом нет ничего плохого. Что вы действительно получаете от сложного протокола?

1 голос
/ 09 ноября 2010

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

S ---> D ( Call a service which would list record keys)
D----> S ( provide xml of keys)
S----> D ( Request each of the records)
D----> S ( Submit record)

В случае, если после синхронизации делается новая запись, Destination может вызвать службу, развернутую в источнике, которая будет обрабатыватьновая запись.

Поскольку связь обрабатывается, купите механизм веб-службы, вам не нужно беспокоиться о параметрах сообщения.SSL можно добавить для безопасности.

Cheers!

1 голос
/ 03 ноября 2010

Хорошо, во-первых, вы не можете гарантировать что-либо по ненадежной ссылке. Проблема Двух Генералов доказывает это как для детерминированных, так и для недетерминированных протоколов. Все, что вы можете сделать, это смягчить ненадежность до приемлемой степени.

Самый простой способ, в вашем случае, когда сервер получает запрос на опрос, он отправляет x количество ответов, все с одинаковым GUID. Например. 

S: B, anything new?
S: B, anything new?
S: B, anything new?
B: Yes, S, I need a jacket (order #123).
S: B, anything new?
B: Yes, S, I need a jacket (order #123).
S: B, anything new?
B: Yes, S, I need a jacket (order #123).
S: B, anything new?
B: Yes, S, I need a jacket (order #123).
B: Yes, S, I need some shoes (order #124).
S: B, anything new?
B: Yes, S, I need a jacket (order #123).
B: Yes, S, I need some shoes (order #124).
S: B, anything new?
B: Yes, S, I need some shoes (order #124).
S: B, anything new?
B: Yes, S, I need some shoes (order #124).
...

S может получать спам с заказами, но, поскольку # отправляется с каждым запросом, это не имеет большого значения. Если мы пропустили это раньше, мы получаем это сейчас. Если мы не получили это раньше, уууу! У нас это есть сейчас. Система работает! Вы заметите, что B отправляет сообщения 5 раз в моем примере. В реалистичном сценарии вы, вероятно, отправите сообщение сотни или тысячи раз, пока не достигнете желаемой надежности.

Теперь вышеприведенное решение требует интенсивной обработки и пропускной способности, но оно работает. Более умный способ - сделать то, что делает TCP: иметь трехстороннее рукопожатие. 

S: Hello B. Are you there? -> SYN
B: Hello S, yep I'm here. What's up? -> SYN+ACK
S: Oh good, you're there. -> ACK
S: B, anything new?
B: Yes, S, I need a jacket (order #123).

Но .. HTTP уже делает это. Так что если что-то не получится, вы узнаете. Тайм-аут соединения, соединение разорвано и т. Д.

Теперь вы можете переписать эти сценарии на уровне приложения (введите WS-ReliableMessaging), но на самом деле TCP уже надежен. Некоторые критики этих SOAP (ish) фреймворков и поддельных протоколов (они обычно работают поверх HTTP) обвиняют их в том, что они по сути заново изобретают колесо - и проблемы колеса - на более высоком уровне абстракции.

Суть в том, что любая система может выйти из строя, включая надежные системы обмена сообщениями.

Что касается возможной последовательности, я думаю, вы можете быть смущены. Окончательная согласованность применима только к распределенным системам хранения, где после Write() вы, возможно, не сможете определенным образом извлечь его с Read() в течение некоторого времени. Это совсем не похоже на твою проблему. Я имею в виду, я понимаю, что вы говорите, но в системе eventually consistent между узлами предполагается надежное (достаточное) соединение. Вы не делаете этого предположения (хотя я думаю, что вы должны .. TCP чертовски надежен).

1 голос
/ 03 ноября 2010

То, что вы, вероятно, ищете, это двухфазный коммит.Это хорошо описано в Интернете, например, здесь:

http://en.wikipedia.org/wiki/Two-phase_commit_protocol

Суть этого:

Процесс фиксации происходит следующим образом: 

* Phase 1
      o Each participating resource manager coordinates local 
        operations and forces all log records out:
      o If successful, respond "OK"
      o If unsuccessful, either allow a time-out or respond "OOPS" 
* Phase 2
      o If all participants respond "OK":
            * Coordinator instructs participating resource managers to "COMMIT"
            * Participants complete operation writing the log record
              for the commit 
      o Otherwise:
            * Coordinator instructs participating resource managers to "ROLLBACK"
            * Participants complete their respective local undos

Должно работать для любых данных.

...