Шаблон обмена сообщениями запрос / ответ - служебная шина Azure

Все ,

Я сомневаюсь в шаблоне ответа на запрос ... Предположим, что это мой сценарий

1. У меня есть служба, работающая в Windows Azure. Пользователи могут вызывать эту службу для выполнения команды.

2. У меня есть клиентские приложения, работающие в моей интрасети. Это клиентское приложение выполнит команду. Компьютер, на котором запущено клиентское приложение, подключен к Интернету, но не имеет статического IP-адреса, т.е. к машине нельзя получить доступ напрямую через Интернет.

3. Я планирую использовать служебную шину Azure, через которую моя служба в Windows Azure может взаимодействовать с клиентским приложением для выполнения ....

В этом сценарии могу ли я использовать обмен сообщениями типа "запрос / ответ", то есть может ли служба опубликовать сообщение и ожидать ответа от клиента.

OR

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

Любая помощь приветствуется


azure azureservicebus azure-servicebus-queues wcf messaging
person Sabarish Sathasivan    schedule 30.04.2014    source источник
comment
В каком направлении идет общение? Компьютер интрасети вызывает службу в Windows Azure или служба Windows Azure вызывает команду на компьютере в интрасети (или на обоих)?   -  person mellamokb    schedule 30.04.2014
comment
Связь может быть в обоих направлениях.   -  person Sabarish Sathasivan    schedule 01.05.2014

Ответы (2)


arrow_upward
0
arrow_downward

Поскольку вы используете WCF (на основе тега), вам следует рассмотреть возможность использования Service Bus Relay, вызывающий асинхронно службы WCF.

person TheDude    schedule 30.04.2014
comment
Поскольку ip клиентской машины динамический, это не вызовет пробкема - person Sabarish Sathasivan; 01.05.2014
comment
@ sam1977: на главной странице Service Bus Relay говорится, что динамический IP - это как раз один из обрабатываемых сценариев. Технически Service Bus Relay работает, устанавливая исходящее соединение для имитации входящего, поэтому IP-адрес клиента не имеет значения. - person mellamokb; 01.05.2014
comment
@ sam1977 IP-адрес клиентского компьютера на самом деле не имеет значения - приемник ретрансляции зарегистрируется, и все вызовы этой конечной точки Azure будут ретранслироваться на клиентский компьютер. - person TheDude; 02.05.2014

arrow_upward
0
arrow_downward

Я предполагаю, что вы хотите использовать здесь Relaybinding, используя WCF.
В этом случае ваша веб-служба (которая находится за NAT, устройствами брандмауэра и т. Д.) Открывает только исходящие соединения. Служба прослушивает зарегистрированную конечную точку в облаке (которая доступна для него из-за учетных данных и протокола). Все входящие служебные вызовы отправляются через этот порт / сокет. Затем ответ будет снова отправлен обратно через исходящий порт.
Если IP-адрес вашей службы изменится, она снова зарегистрируется (путем прослушивания той же зарегистрированной конечной точки), и вы сможете связаться с этой службой прозрачно.

Другой способ получения запроса / ответа асинхронным способом - использовать очереди. Это не требует открытого соединения между вашим клиентом и вашей службой и может происходить полностью асинхронно. Этого можно достичь, отправив сообщение в очередь запросов для вашей конкретной службы (с идентификатором корреляции). И когда эта служба обработает это сообщение, она может отправить ответ в очередь ответов вашего приложения, используя сеансы. Хороший пример этого шаблона можно найти в блоге Алана Смита: http://www.cloudcasts.net/devguide/Default.aspx?id=13051.

person Sam Vanhoutte    schedule 02.05.2014