Message Queue vs. Web Services?




web-services message-queue (4)

C'è stata una discreta quantità di ricerche recenti nel considerare come le chiamate HTTP REST possano sostituire il concetto di coda messaggi.

Se si introduce il concetto di un processo e un'attività come una risorsa, la necessità di un livello di messaggistica medio inizia ad 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 viene eseguito il polling o POST su un URL di richiamata una volta completato.

Questo è semplice e diventa piuttosto 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 lo ha integrato senza un altro livello di codice personalizzato.

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

È stato integrato il rilevamento dei servizi, anche per un'attività con più passaggi, senza protocolli complicati.

GET /task/name
    - returns form with required fields

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

La scoperta del servizio è una forma HTML, un formato leggibile universale e umano.

L'intero flusso può essere utilizzato a livello di programmazione o da un essere umano, utilizzando strumenti universalmente accettati. È un client guidato, e quindi RESTful. Ogni strumento creato per il web può guidare i processi aziendali. I canali dei messaggi alternativi sono ancora disponibili mediante il POST in modo asincrono su un array separato di server di registro.

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

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

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

Devo parlare tra due app su una rete locale. Uno sarà un'app Web e dovrà richiedere i 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 XML Web Services (o TCP diretto o qualcosa del genere) per l'utilizzo di una coda di messaggi?

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


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

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


Penso che in generale, si desideri 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 per questo).


Quando si utilizza un servizio Web, si dispone di 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 sta funzionando di nuovo, il cliente è responsabile di inviarlo nuovamente.
  3. Se il server risponde alla chiamata e il client non funziona, l'operazione viene persa.
  4. Non hai contese, cioè: se milioni di clienti chiamano un servizio web su un server in un secondo, molto probabilmente il tuo server andrà giù.
  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 si prevedono risultati diversi e più tolleranti ai guasti:

  1. Se il server non funziona, la coda continua il messaggio (facoltativamente, anche se la macchina si spegne).
  2. Quando il server sta funzionando di nuovo, riceve il messaggio in sospeso.
  3. Se il server dà una risposta alla chiamata e il client non riesce, se il client non ha confermato la risposta il messaggio è persistente.
  4. Hai una contesa, puoi decidere quante richieste sono gestite dal server (chiamalo invece worker).
  5. Non ti aspetti una risposta sincrona immediata, ma puoi implementare / simulare le chiamate sincrone.

Message Queues ha molte più funzionalità, ma questa è una regola empirica per decidere se si desidera gestire da sé le condizioni di errore o lasciarle nella coda dei messaggi.





message-queue