Coda messaggi e servizi Web? [chiuso]

In quali condizioni si preferirebbero le app che parlano tramite una coda di messaggi anziché tramite servizi Web (intendo solo XML o JSON o YAML o qualsiasi altra cosa su HTTP qui, non un tipo particolare)?

Devo parlare tra due app su una rete locale. Una sarà un'app Web e dovrà richiedere comandi su un'altra app (in esecuzione su hardware diverso). Le richieste sono cose come la creazione di utenti, lo spostamento di file e la creazione di directory. In quali condizioni preferirei i servizi Web XML (o TCP o altro) piuttosto che utilizzare una coda di messaggi?

L'app Web è Ruby on Rails, ma penso che la domanda sia più ampia di così.

Quando usi un servizio web hai un client e un server:

1. Se il server non funziona, il client deve assumersi la responsabilità di gestire l'errore.
2. Quando il server funziona di nuovo, il client è responsabile del rinvio.
3. Se il server risponde alla chiamata e il client fallisce, l'operazione viene persa.
4. Non hai contese, vale a dire: se milioni di client chiamano un servizio web su un server in un secondo, molto probabilmente il tuo server si spegnerà.
5. Puoi aspettarti una risposta immediata dal server, ma puoi anche gestire le chiamate asincrone.

Quando si utilizza una coda di messaggi come RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo, ci si aspettano risultati diversi e più tolleranti agli errori:

1. Se il server non riesce, la coda persiste il messaggio (facoltativamente, anche se l'arresto della macchina).
2. Quando il server funziona di nuovo, riceve il messaggio in sospeso.
3. Se il server fornisce una risposta alla chiamata e il client ha esito negativo, se il client non ha riconosciuto la risposta, il messaggio persiste.
4. Hai delle controversie, puoi decidere quante richieste vengono gestite dal server (chiamalo invece worker).
5. Non ti aspetti una risposta sincrona immediata, ma puoi implementare / simulare chiamate sincrone.

Code dei messaggi ha molte più funzioni, ma questa è una regola empirica per decidere se si desidera gestire autonomamente le condizioni di errore o lasciarle nella coda dei messaggi.

Ci sono state molte ricerche recenti nel considerare come le chiamate HTTP REST potrebbero sostituire il concetto di coda dei messaggi.

Se si introduce il concetto di processo e attività come risorsa, la necessità di un livello di messaggistica centrale inizia a evaporare.

Ex:

POST /task/name
    - Returns a 202 accepted status immediately
    - Returns a resource url for the created task: /task/name/X
    - Returns a resource url for the started process: /process/Y

GET /process/Y
    - Returns status of ongoing process

Un'attività può avere più passaggi per l'inizializzazione e un processo può restituire lo stato quando sottoposto a polling o POST a un URL di richiamata al termine.

Questo è molto semplice e diventa abbastanza potente quando ti rendi conto che ora puoi iscriverti a un feed rss / atom di tutti i processi e le attività in esecuzione senza alcun livello intermedio. Qualsiasi sistema di accodamento richiederà comunque una sorta di front-end Web e questo concetto è integrato senza un altro livello di codice personalizzato.

Le tue risorse esistono fino a quando non le elimini, il che significa che puoi visualizzare le informazioni storiche molto tempo dopo il completamento del processo e dell'attività.

Hai individuato il servizio di rilevamento, anche per un'attività che prevede più passaggi, senza protocolli extra complicati.

GET /task/name
    - returns form with required fields

POST (URL provided form's "action" attribute)

La scoperta del servizio è un modulo HTML, un formato universale e leggibile dall'uomo.

L'intero flusso può essere utilizzato a livello di codice o da un essere umano, utilizzando strumenti universalmente accettati. È un client guidato e quindi RESTful. Ogni strumento creato per il Web può guidare i tuoi processi aziendali. Hai ancora canali di messaggi alternativi POSTANDO in modo asincrono su un array separato di log server.

Dopo averlo considerato per un po ', ti siedi e inizi a capire che REST potrebbe semplicemente eliminare la necessità di una coda di messaggistica e di un ESB.

http://www.infoq.com/presentations/BPM-with-REST

Le code dei messaggi sono ideali per le richieste che potrebbero richiedere molto tempo per l'elaborazione. Le richieste sono in coda e possono essere elaborate offline senza bloccare il client. Se il client deve essere informato del completamento, è possibile fornire un modo per controllare periodicamente lo stato della richiesta.

Le code dei messaggi consentono anche di ridimensionare meglio nel tempo. Migliora la tua capacità di gestire esplosioni di attività pesanti, poiché l'elaborazione effettiva può essere distribuita nel tempo.

Si noti che le code dei messaggi e i servizi Web sono concetti ortogonali, ovvero non si escludono a vicenda. Ad esempio, è possibile disporre di un servizio Web basato su XML che funge da interfaccia per una coda di messaggi. Penso che la distinzione che stai cercando sia Coda messaggi rispetto a Richiesta / Risposta, quest'ultima è quando la richiesta viene elaborata in modo sincrono.

Le code dei messaggi sono asincrone e possono riprovare più volte se la consegna fallisce. Utilizzare una coda di messaggi se il richiedente non deve attendere una risposta.

La frase "servizi web" mi fa pensare alle chiamate sincrone a un componente distribuito su HTTP. Utilizzare i servizi Web se il richiedente necessita di una risposta.

Penso in generale che vorresti un servizio Web per un'attività di blocco (queste attività devono essere completate prima di eseguire più codice) e una coda di messaggi per un'attività non bloccante (potrebbe richiedere un po 'di tempo, ma non non c'è bisogno di aspettare).