Ретранслятор служебной шины Azure - получение данных из локальной среды

Возможен ли следующий сценарий в Azure?

Мне нужно получить данные из помещения клиента в Windows azure, обработать и сохранить в базе данных или табличном хранилище. Помещения клиента находятся за брандмауэром / натур ... и т. Д. Как лучше всего создать одно единственное решение (которое будет работать для всех клиентов) и позволит мне получить данные о конкретном клиенте.

Обычно рабочая роль получает данные от клиента 1, обрабатывает их и сохраняет; чем от клиента 2 и так далее.

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


person David Dury    schedule 24.01.2013    source источник


Ответы (2)


Дэвид, реле служебной шины - идеальное решение для этого. Вы можете написать службу WCF, которая будет работать в каждом помещении клиента и подключаться к вашей единой службе в облаке. Использование ретранслятора служебной шины дает здесь множество преимуществ: 1) Для службы на стороне клиента вам НЕ нужно открывать какие-либо входящие порты в их NAT / брандмауэре, поскольку клиент служебной шины будет устанавливать исходящее соединение. 2) Вы можете запустить один или несколько экземпляров своей службы в облаке и прослушивать один или несколько адресов / конечных точек на служебной шине. Таким образом, вы можете как масштабировать сервис, так и изолировать каждого клиента в зависимости от ваших потребностей. 3) Мы поддерживаем балансировку нагрузки, при которой несколько отправителей (из местоположения клиентов) могут подключаться к одному адресу конечной точки, и здесь снова для облачной службы прослушивателя вы можете подключить несколько экземпляров к той же конечной точке 4) Обширная поддержка привязки WCF. доступны, поэтому вы можете выбрать подходящий канал для ваших нужд

Ниже приведены дополнительные ресурсы для начала работы. Обзор: http://www.windowsazure.com/en-us/develop/net/how-to-guides/service-bus-relay/ Пример: http://code.msdn.microsoft.com/windowsazure/Relayed-Messaging-Load-bd76a9f8

person Abhishek Lal    schedule 25.01.2013
comment
Однако у меня есть один вопрос. В примере, который вы упомянули, как я могу это сделать, чтобы я не использовал в клиенте имя эмитента: OWNER и его секретный ключ? Я имею в виду, что из соображений безопасности можно ли создать настраиваемое имя эмитента с именем: MYCUSTOMER и его собственный ключ, и это настраиваемое имя эмитента не будет иметь полного контроля, как владелец ..? Ты знаешь, что я имею в виду? - person David Dury; 26.01.2013
comment
Я знаю, что этому вопросу 2 года, но в настоящее время я разрабатываю очень похожее решение. Что касается создания дополнительных удостоверений для аутентификации служебной шины, обратите внимание на SBAzTool от команды Azure, который представляет собой интерфейс командной строки и DLL, который позволяет создавать удостоверения и разрешения служебной шины (т.е. прослушивание, отправку, получение) и ключи. программно. Azure SBaZ Tool Просто поместите это здесь на случай, если кто-то еще столкнется с этим вопрос, как и я! - person Ian Andrew Irwin; 23.01.2015
comment
использование реле служебной шины - это нормально, но для этого вам либо нужно иметь оболочку wcf вокруг вашей веб-службы в локальной среде, либо вам нужно внести некоторые изменения в конфигурацию. Можно ли вызвать локальные веб-службы из веб-API Azure, ничего не меняя в локальных веб-службах. - person Ramprasad; 03.08.2017

Я несколько сбит с толку - если вам нужно ПОЛУЧИТЬ данные от клиентов, не могут ли они просто позвонить в вашу службу? обычно межсетевые экраны разрешают исходящие запросы?

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

person Yossi Dahan    schedule 25.01.2013