Oltre alla natura asincrona/sincrona di un particolare problema e tenendo conto del fatto che MOM (in questo caso aver scelto JMS) offre funzionalità aggiuntive gratuite come bilanciamento del carico e altre, cos'altro si può prendere in considerazione quando si sceglie JMS anziché REST o vice -versa?Quando utilizzare JMS e quando utilizzare REST?
Grazie
Utilizzare sempre REST. È l'approccio di integrazione più moderno, avanzato e scalabile disponibile oggi. Il bilanciamento del carico di un servizio basato su REST è ottenuto semplicemente con il bilanciamento del carico HTTP hardware o software e può essere considerato altrettanto semplice quanto il bilanciamento del carico in JMS.
MOM (Message Oriented Middleware) non è scalabile facilmente (ma potrebbe scalare in modo sufficiente per le proprie esigenze). REST funziona su scala web.
MOM non ha economies of scale. Per le richieste di recupero dei dati, ogni volta che viene richiesta una particolare parte di dati, un altro messaggio deve essere inviato al server e risposto dal server. In un sistema basato su REST, le richieste per gli stessi dati possono essere soddisfatte da un HTTP cache. Ciò significa che quando il volume delle richieste aumenta nel tempo, un sistema basato su MOM vedrà l'aumento del carico del server alla stessa velocità delle richieste. Un sistema basato su REST vedrà l'aumento del carico del server ad un ritmo più lento rispetto alle richieste.
MOM ti tenterà con messaggi ignifughi con consegna garantita, solo per morderti con lo chain of custody problem.
MOM è terribile per la richiesta sincrona di risposta poiché fallirà lentamente (ad esempio, aspetta il timeout) quando il server non funziona. Quando una richiesta sta per fallire, vuoi che fallisca velocemente. Una richiesta HTTP a un servizio basato su REST avrà esito negativo immediatamente (sulla connessione TCP) se il server non funziona.
MOM è utile per la messaggistica asincrona domanda-risposta, ma poi ti verrà lasciato con il problema di dove memorizzare lo stato in-tra la richiesta e la risposta (Suggerimento: Le opzioni disponibili sono File or Regular Database, il Message o un NoSQL Database). Spesso lo sforzo extra di implementazione non vale i vantaggi percepiti dell'asincronicità. Anche i servizi basati su REST supportano richieste asincrone se ne hai davvero bisogno. 202 Accepted è tuo amico in questa situazione.
Infine, l'uso della memorizzazione nella cache consente ai sistemi basati su REST di implementare le integrazioni pull-based, che sono molto più facili da supportare. Per esempio, diciamo semplicemente che vogliamo spostare i dati dal sistema A al sistema B. L'approccio MOM sarebbe quello di inviare messaggi da A a B. Un approccio basato sul REST sarebbe quello di creare un servizio di feed di dati in A (come un feed RSS) che B esegue il polling di nuovi dati (allo stesso modo in cui il tuo lettore RSS esegue il polling di nuovi articoli). Quando B fallisce, nell'esempio MOM, il team di supporto dovrà monitorare le code dei messaggi per assicurarsi che non si sovrappongano, mentre qualcun altro ottiene il backup di B. Nell'esempio REST, il team di supporto deve solo preoccuparsi di ottenere il backup di B. Non c'è molta differenza quando A fallisce. Nell'esempio MOM B non sa e non gli importa. Nell'esempio REST B sa che A non funziona, ma non gliene importa perché ovviamente non ci sono nuovi dati da A quando è giù. Inizialmente, il polling dell'integrazione basata su pull richiede cuciture molto inefficienti, tuttavia il caching HTTP lo rende un problema.
In altre parole, invece di investire in un server JMS, investire in un buon bilanciamento del carico HTTP nella cache.
Mi piace molto questa risposta. +1 :) – ses
"Usa sempre REST" è una risposta terribile. Esistono certamente molti casi validi in cui REST è la scelta più appropriata, ma ce ne sono molti altri in cui MOM è la scelta migliore. –
@PaulLegato Ho lavorato nello spazio MOM per oltre un decennio. È il mio pane e burro e fa schifo. Gimmie un esempio in cui MOM è una scelta tecnica migliore rispetto a REST. –
Non è possibile confrontare queste due tecnologie.
REST è un servizio/modello per fornire un modo organizzato per accedere a risorse senza stato.
MOM Sysems/JMS è un modello progettato per condividere i messaggi tra i sistemi. Riguarda i dati, i dati in modo affidabile.
Non si può davvero confrontare JMS con REST bc risolvono diversi problemi.
Ma se la tua domanda è più simile a quella ho bisogno di un'interfaccia REST per le mie code JMS? In tutte le situazioni, ho visto persone utilizzare REST per proteggere i thin client dalla logica necessaria per mettere in coda i messaggi in JMS. Per esempio. se si ha un client Android che vuole parlare con JMS, è molto più difficile farlo in modo naitvelo rispetto a spingere i messaggi su un'interfaccia di "riposo" che può quindi tradurre e inviare a un JMS.
È possibile condividere dati affidabili tra sistemi utilizzando REST. I feed Atom ne sono un perfetto esempio. –
Non sto dicendo che non puoi. Questo è l'intero scopo di REST. – Nix
"MOM Sysems/JMS è un pattern progettato per condividere i messaggi tra i sistemi." Sto dicendo che REST è davvero bravo in questo. IMO puoi facilmente confrontare JMS con REST poiché entrambi cercano di risolvere i problemi di integrazione delle applicazioni. Hai un esempio di * qualsiasi * che è meglio risolto con JMS di un approccio RESTful? –
Queste sono due diverse tecnologie e modelli .... e come risultato la tua domanda non ha senso. – Nix
@Nix non essere un tale pedante. Dal punto di vista dell'integrazione delle applicazioni, è perfettamente valido considerare un approccio basato sul REST o un approccio basato su MOM. Se non altro, sono sorpreso che i servizi SOAP non siano stati presi in considerazione. –
@Nix Posso ottenere la stessa integrazione usando entrambe le tecnologie, per questo motivo la domanda è prefetto valido. in effetti una grande domanda. –