Использование SignalR в рабочих ролях Azure

У меня есть размещенное в Azure веб-приложение, которое работает вместе с несколькими экземплярами рабочей роли.В настоящее время веб-приложение передает работу этим рабочим, помещая сообщения в очередь Azure, чтобы рабочие могли их забрать. Рабочие передают сообщения о статусе и прогрессе обратно, помещая сообщения в очередь «обратной связи». На данный момент, чтобы проинформировать клиентов моего браузера о ходе работы, я делаю в браузере периодические вызовы опроса на основе ajax для метода контроллера MVC, который, в свою очередь, читает очередь обратной связи Azure и возвращает эти сообщения в виде json обратно в браузер. .

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

SignalR.WindowsAzureServiceBus Клеменса Вастерса выглядит превосходно, но оставляет его немного высоковатым и сухим в конце, т.е. отсутствует хороший пример решения.

Добавлен комментарий : Насколько я знаю, мне кажется, что прямая связь от worker роли (в отличие от роли web ) браузеру клиент через подход SignalR возможен. Кажется, что работники должны общаться с веб-ролью с помощью очередей. Это, в свою очередь, заставляет использовать метод опроса, то есть очереди должны опрашиваться на предмет сообщений от рабочих ролей - этот опрос должен исходить (управляться) из браузера, в котором он появляется (как можно настроить цикл опроса в веб-роли?)

Таким образом, SignalR, даже с SignalR.Масштабируемый подход Клеменса Вастерса WindowsAzureServiceBus не может обрабатывать прямую связь от рабочей роли к браузеру.

Будем признательны за любые комментарии экспертов.