Uso di SignalR in Azure Worker Roles

Question

Possiedo un'applicazione Web ospitata su Azure che funziona insieme a un numero di istanze di un ruolo di lavoro. Attualmente l'app Web trasferisce il lavoro a questi lavoratori inserendo i messaggi in una coda di Azure affinché i lavoratori possano accedervi. I lavoratori passano lo stato e i messaggi di avanzamento riportando i messaggi in una coda di "feedback". Al momento, per informare i clienti del mio browser sul progresso, eseguo chiamate di polling periodiche basate su ajax nel browser a un metodo di controller MVC che a sua volta legge la coda di feedback 'Azure e restituisce questi messaggi come json al browser .

Ovviamente, SignalR sembra un'alternativa molto attraente a questo approccio gergale di polling/queing, ma ho trovato pochissime indicazioni su come procedere nel fare ciò quando si parla di più ruoli di lavoro (in contrapposizione al ruolo web) che devono inviare lo stato a singoli o a tutti i client.

SignalR.WindowsAzureServiceBus by Clemens vasters sembra superbo ma lascia un po 'alto e asciutto alla fine, cioè manca una buona soluzione di esempio.

Aggiunto commento: Dalla mia lettura fino ad ora sembra che nessuno diretta comunicazione lavoratore ruolo (al contrario di web ruolo) al client browser tramite l'approccio SignalR è possibile. Sembra che i lavoratori debbano comunicare con il ruolo web usando le code. Ciò a sua volta impone un approccio di polling, ovvero le code devono essere interrogate per i messaggi dei ruoli dei lavoratori - questo polling deve originarsi (essere guidato da) dal browser che appare (come può essere impostato un ciclo di polling in un ruolo web?)

In sintesi, SignalR, anche con l'approccio di scala di SignalR.WindowsAzureServiceBus out di Clemens Vasters, non può gestire la comunicazione diretta dal ruolo di lavoratore al browser.

Sarebbe gradito qualsiasi commento da parte degli esperti.

Answer 1

Utilizziamo Code di servizio di Azure Service per inviare dati ai nostri ruoli web SignalR che poi inoltrano ai client. I CAT pages hanno ottimi esempi di come configurare loop asincroni e invio.

Answer 2

È possibile utilizzare i ruoli di lavoro come client SignalR, in modo che inviino messaggi al ruolo Web (che è il server SignalR) e il ruolo Web a sua volta inoltrerà i messaggi ai client.

Answer 3

Tenere presente che la mia conoscenza di queste due tecnologie è molto semplice, sto appena iniziando. E potrei aver frainteso la tua domanda, ma mi sembra abbastanza ovvio:

I ruoli Web sono in grado di sottoscrivere un queue server in cui il ruolo lavoratore deposita il messaggio ?. In tal caso non ci sarebbe nessun client "in tiro", il servizio in coda fornirebbe il codice del lato server web con un nuovo messaggio, e attraverso SignalR si farebbero delle modifiche al client senza le richieste del client coinvolte. La comunicazione tra web e worker rimarrebbe la stessa (che secondo me è il modo corretto di farlo).

Answer 4

I prodotti bus di messaggi alternativi come NServiceBus potrebbero valere la pena di essere esaminati. NServiceBus ha la capacità di consegnare messaggi in modo asincrono attraverso i confini del processo senza bisogno di polling.

Answer 5

Se si utilizza uno dei backplane di ridimensionamento SignalR è possibile far lavorare i lavoratori con i client connessi tramite l'applicazione Web.

How to publish messages using the SignalR SqlMessageBus spiega come procedere.

Si collega anche a un example completamente funzionante che dimostra un modo per farlo.