E 'opportuno utilizzare code di messaggi per le chiamate RPC sincrone tramite la tecnologia AJAX

Ho un'applicazione web che utilizza il plugin jQuery completamento automatico, che invia essenzialmente tramite la tecnologia AJAX una richiesta contenente testo che è stato digitato in una casella di testo al nostro server web, una volta il server Web riceve questa richiesta, quindi viene trasferito a rabbitmq.E 'opportuno utilizzare code di messaggi per le chiamate RPC sincrone tramite la tecnologia AJAX

So che otteniamo benefici dall'utilizzo della messaggistica, ma sembra che utilizzarlo per bloccare le chiamate rpc sia un uso improprio e che qualcosa come WCF sia molto più appropriato in questo caso, è questo il caso o è considerato accettabile architettura?

fonte

2014-04-01 nickbw

Ovviamente dipende dalla vostra applicazione, è possibile utilizzare la coda per le chiamate RPC, ma penso che non è la sua naturale utilizza. Per aiutarti ho due domande: 1. Perché usi le chiamate sincrone? 2. Hai qualche problema con la tua attuale applicazione? Ad ogni modo, non so in quale lingua si stia sviluppando l'applicazione, ma penso che si possano usare le chiamate asincrone con RabbitMQ e utilizzare alcune tecnologie come Spring DeferredResult per ottenere i risultati dalla propria coda. Non mi piacciono tanto le chiamate sincrone, perché si blocca il thread (ad esempio durante la ricerca del DB) inutilmente. – Gabriele

1. abbiamo chiamate sincrone per il plugin di completamento automatico, devi avere una risposta per la richiesta 2. nessun problema oltre a quello che penso sia un uso improprio dei messaggi in questa istanza e voglio cambiarlo, e sto cercando per prove a sostegno di questo cambiamento. – nickbw

E 'possibile effettuare le richieste sincrone RPC con RabbitMQ. Here è spiegato molto bene, con il suo inconveniente incluso! Quindi è considerato un'architettura accettabile. Scoraggiato, ma accettabile ogni volta che la risposta sincrona è obbligatoria.

Come possibile contro-effetto è che l'aggiunta RabbitMQ nel mezzo, si aggiungerà una certa latenza alla soluzione.

Tuttavia si ha la possibilità di guadagnare in termini di affidabilità, flessibilità, scalabilità, ...

fonte

2014-04-02 22:05:45 Sigismondo

sì, è la latenza che per me è l'interruttore, non è possibile avere un completamento automatico lento – nickbw

o ... la latenza qui viene misurata in termini di millis. Più veloce è meglio, ma non è l'unico parametro da tenere in considerazione. L'unica cosa che mi fa pensare, è che il completamento automatico dovrebbe essere implementato come asincrono.È interessante notare che ho trovato [questo post così] (http://stackoverflow.com/questions/4439953) - forse può essere utile: non ho mai usato il completamento automatico adesso, lo lascio a voi. – Sigismondo

Quali benefici vorresti ottenere da esso? E in tutta onestà se metti il messaggio in coda come è sincrono? a meno che lo stesso processo che ha inserito il messaggio nella coda sia quello che lo rimuove, ma che è praticamente inutile no?

Ora, se tutto quello che vogliamo fare è inserire il messaggio nella coda ed elaborare in un secondo momento è grande. Anche il fatto di avere WCF alla miscela è un segno di IMHO che forse qualcosa non è abbastanza chiaro. È possibile utilizzare WCF come gateway API e utilizzarlo per scrivere il messaggio in coda, quindi non si tratta in realtà di WCF o di code, ma più di sincronizzazione vs async.

Il modo in cui si sta mettendo le tue idee, non guarda bene a me.

fonte

2014-04-02 18:28:20 Marco

a volte è necessario avere una risposta da un messaggio, per il completamento automatico, se non si ottiene una risposta sarebbe inutile. Preferirei rimuovere le chiamate sincrone dai messaggi e sono alla ricerca di prove per supportare/contraddire questo – nickbw

Nelle chiamate asycn si ottiene una risposta, ma non il modo in cui si pensa. Ad esempio, se si utilizza CQRS con REST, quando si invia un'istruzione come: AddUserCommand, si ottengono solo i codici HTTP come 200, 401, 406 .. nient'altro, anche se il messaggio viene elaborato per la sincronizzazione. È necessario utilizzare un altro livello API per recuperare lo stato del comando. Quello stesso livello (leggi i modelli) è lo stesso che prova i dati dei tuoi drop down. Una cosa è certa, se vuoi l'elaborazione di sincronizzazione, rimuovi le code dalla tua architettura. – Marco

E 'opportuno utilizzare code di messaggi per le chiamate RPC sincrone tramite la tecnologia AJAX

risposta

Problemi correlati