a cosa serve JMS? [chiuso]

Question

Sto cercando esempi (semplici) di problemi per i quali JMS è una buona soluzione, e anche i motivi per cui JMS è una buona soluzione in questi casi. In passato ho semplicemente usato il database come mezzo per passare messaggi da A a B quando il messaggio non può essere necessariamente elaborato da B immediatamente.

Un ipotetico esempio di tale sistema è quello in cui tutti gli utenti appena registrati devono ricevere un'e-mail di benvenuto entro 24 ore dalla registrazione. Per ragioni di argomento, supponiamo che il DB non registri l'ora in cui ciascun utente si è registrato, ma invece un riferimento (chiave esterna) per ogni nuovo utente è memorizzato nella tabella pending_email. Il lavoro del mittente dell'e-mail viene eseguito una volta ogni 24 ore, invia un'e-mail a tutti gli utenti in questa tabella, quindi elimina tutti i record di posta in sospeso.

Questo sembra il tipo di problema per il quale JMS dovrebbe essere usato, ma non mi è chiaro quale beneficio avrebbe JMS sull'approccio che ho descritto. Un vantaggio dell'approccio DB è che i messaggi sono persistenti. Comprendo che le code dei messaggi JMS possono anche essere persistenti, ma in quel caso sembra esserci una piccola differenza tra JMS e il "database come coda dei messaggi". approccio che ho descritto?

Cosa mi sto perdendo? - Don

Answer 1

JMS e messaggistica riguardano in realtà 2 cose totalmente diverse.

• pubblica e iscriviti (inviando un messaggio a tutti i consumatori che sono interessati - un po 'come inviare un'e-mail a una mailing list, il mittente non ha bisogno di sapere chi è abbonato
• bilanciamento del carico affidabile ad alte prestazioni (code dei messaggi)

Ulteriori informazioni su come si confronta una coda a un argomento

Il caso di cui stai parlando è il secondo caso, in cui sì puoi usare una tabella di database per simulare una coda di messaggi.

La differenza principale è che una coda di messaggi JMS è un bilanciamento del carico altamente concorrenziale ad alte prestazioni progettato per un throughput enorme; di solito puoi inviare decine di migliaia di messaggi al secondo a molti consumatori simultanei in molti processi e thread. Il motivo di ciò è che una coda di messaggi è sostanzialmente altamente asincrona - un un buon fornitore JMS trasmetterà in anticipo i messaggi a ciascun consumatore in modo che ci siano migliaia di messaggi disponibili per l'elaborazione nella RAM non appena un consumatore è disponibile. Questo porta a un throughput massiccio e una latenza molto bassa.

es. immagina di scrivere un bilanciamento del carico web usando una tabella di database :)

Quando si utilizza una tabella di database, in genere un thread tende a bloccare l'intera tabella, quindi si tende a ottenere un throughput molto basso quando si tenta di implementare un bilanciamento del carico ad alte prestazioni.

Ma come la maggior parte dei middleware tutto dipende da ciò di cui hai bisogno; se hai un sistema a bassa velocità con solo pochi messaggi al secondo, sentiti libero di usare una tabella di database come coda. Ma se hai bisogno di bassa latenza e alta velocità effettiva, allora le code JMS sono altamente raccomandate.

Answer 2

A mio avviso, JMS e altri sistemi basati su messaggi hanno lo scopo di risolvere i problemi che richiedono:

• Asincrono : un'applicazione deve notificare a un altro che si è verificato un evento senza che sia necessario attendere una risposta.
• Affidabilità . Garantire il recapito del messaggio una sola volta. Con il tuo approccio DB devi "reinventare la ruota", specialmente se hai diversi clienti che leggono i messaggi.
• Accoppiamento libero . Non tutti i sistemi possono comunicare utilizzando un database. Quindi JMS è abbastanza buono da usare in ambienti eterogenei con sistemi disaccoppiati in grado di comunicare oltre i confini del sistema.

Answer 3

L'implementazione JMS è "push", nel senso che non è necessario eseguire il polling della coda per scoprire nuovi messaggi, ma si registra un callback che viene chiamato non appena arriva un nuovo messaggio.

Answer 4

per rispondere al commento originale. ciò che è stato originariamente descritto è l'essenza di (punto-punto) JMS. i vantaggi di JMS sono tuttavia:

1. non è necessario scrivere il codice da soli (e possibilmente rovinare la logica in modo che non sia così persistente come si pensa). inoltre, impl di terze parti potrebbe essere più scalabile del semplice approccio al database.

2. jms gestisce la pubblicazione / iscrizione, il che è un po 'più complicato dell'esempio punto a punto che hai fornito

3. non sei legato a un'implementazione specifica e puoi scambiarlo se le tue esigenze cambiano in futuro, senza smascherare con il tuo codice java.

Answer 5

Un vantaggio di JMS è abilitare l'elaborazione asincrona che può essere eseguita anche dalla soluzione di database. Tuttavia, di seguito sono riportati altri vantaggi della soluzione JMS su database

a) Il consumatore del messaggio può trovarsi in una posizione remota. L'esposizione del database per l'accesso remoto è pericolosa. Puoi ovviare a questo problema fornendo un servizio aggiuntivo per la lettura dei messaggi dal database, che richiede maggiori sforzi.

b) Nel caso del database, l'utente del messaggio deve eseguire il polling del database per i messaggi in cui JMS fornisce il callback quando arriva un messaggio (come menzionato da sk)

c) Bilanciamento del carico: se ci sono molti messaggi in arrivo, è facile avere un pool di processori di messaggi in JMS.

d) In generale l'implementazione tramite JMS sarà più semplice e richiederà meno sforzo del percorso del database

Answer 6

JMS è un'API utilizzata per trasferire messaggi tra due o più client. Le sue specifiche sono definite in JSR 914.

  

Il vantaggio principale di JMS è la natura disaccoppiata delle entità comunicanti: il mittente non deve disporre di informazioni sui destinatari. Altri vantaggi includono la capacità di integrare piattaforme eterogenee, ridurre i colli di bottiglia del sistema, aumentare la scalabilità e rispondere più rapidamente ai cambiamenti.

I JMS sono solo tipi di interfacce / API e le classi concrete devono essere implementate. Questi sono già implementati da varie organizzazioni / fornitori. sono chiamati provider JMS. L'esempio è WebSphere di IBM o FioranoMQ di Fiorano Softwares o ActiveMQ di Apache, HornetQ, OpenMQ ecc. Altre terminologie utilizzate sono gli oggetti Admin (Argomenti, Code, ConnectionFactories), produttore / editore JMS, client JMS e il messaggio stesso.

Quindi, arrivando alla tua domanda - a cosa serve JMS? Vorrei fare un esempio pratico per illustrarne l'importanza.

Day trading

Esiste questa funzione chiamata LVC (Last value cache)

In Trading i prezzi delle azioni sono pubblicati da un editore a intervalli regolari. Ogni condivisione ha un argomento associato a cui è pubblicata. Ora, se sai cos'è un argomento, devi sapere che i messaggi non vengono salvati come le code. I messaggi vengono pubblicati sugli abbonati vivi al momento della pubblicazione del messaggio (ad eccezione degli abbonati Durables che ricevono tutti i messaggi pubblicati dal momento in cui è stato creato, ma di nuovo non vogliamo ottenere prezzi azionari troppo vecchi che scartano la possibilità di usandolo). Quindi, se un cliente desidera conoscere un prezzo delle azioni, crea un abbonato e quindi deve attendere fino alla pubblicazione del prossimo prezzo delle azioni (che di nuovo non è quello che vogliamo). È qui che entra in scena LVC. Ogni messaggio LVC ha una chiave associata. Se un messaggio viene inviato con una chiave LVC (per un determinato stock) e quindi un altro messaggio di aggiornamento con la stessa chiave, il successivo sostituisce quello precedente. Ogni volta che un abbonato si abbona a un argomento (che ha abilitato LVC) l'abbonato riceverà tutti i messaggi con chiavi LVC distinte. Se manteniamo una chiave distinta per società quotata, quando il cliente si abbona ad essa otterrà l'ultimo prezzo delle azioni e, infine, tutti gli aggiornamenti.

Ovviamente questo è uno dei fattori oltre all'affidabilità, alla sicurezza ecc. che rende JMS così potente.

Answer 7

Guido ha la definizione completa. Dalla mia esperienza, tutti questi sono importanti per una buona misura.

Uno degli usi che ho visto è per la distribuzione degli ordini nei magazzini. Immagina una società di forniture per ufficio che ha un discreto numero di magazzini che forniscono grandi uffici con forniture per ufficio. Tali ordini sarebbero arrivati ??in una posizione centrale e poi sarebbero stati raggruppati per la corretta distribuzione del magazzino. I magazzini non hanno o desiderano connessioni ad alta velocità nella maggior parte dei casi, quindi gli ordini vengono trasferiti su di loro tramite modem dial-up ed è qui che arriva l'asincrono. Le linee telefoniche non sono così importanti, quindi metà degli ordini possono entrare e questo è dove l'affidabilità è importante.

Answer 8

Il vantaggio principale è il disaccoppiamento di sistemi non correlati piuttosto che la condivisione di database comuni o la creazione di servizi personalizzati per il trasferimento dei dati.

I banchi ne sono un esempio acuto, con la messaggistica intraday utilizzata per trasferire le modifiche dei dati in tempo reale mentre si verificano. È molto facile per il sistema sorgente lanciare un messaggio "oltre il muro"; il rovescio della medaglia è che c'è molto poco in termini di contratto tra questi sistemi e normalmente si vede l'implementazione del ricovero dal lato del consumatore. È quasi troppo liberamente accoppiato.

Altri vantaggi sono il supporto immediato di JMS per molti server applicazioni, ecc. e tutti gli strumenti che lo riguardano: durata, monitoraggio, reportistica e limitazione.

Answer 9

C'è un bel riassunto con alcuni esempi qui: http: //www.winslam .com / Laramee / jms / index.html

Answer 10

La soluzione "database come coda messaggi" potrebbe essere pesante per l'attività. La soluzione JMS è meno strettamente accoppiata in quanto il mittente del messaggio non ha bisogno di sapere nulla sul destinatario. Questo potrebbe essere realizzato con qualche ulteriore astrazione nel "database come coda di messaggi", quindi non è una grande vittoria ... Inoltre, puoi usare la coda in un modo "pubblica e iscriviti" che può essere utile a seconda di cosa stai cercando di realizzare. È anche un bel modo per disaccoppiare ulteriormente i componenti. Se tutte le tue comunicazioni sono all'interno di un sistema e / o avere un registro immediatamente disponibile per un'applicazione è molto importante, il tuo metodo sembra buono. Se stai comunicando tra sistemi separati, JMS è una buona scelta.

Answer 11

JMS in combinazione con JTA (Java Transaction API) e JPA (Java persistence API) può essere molto utile. Con una semplice annotazione è possibile inserire più azioni del database + invio / ricezione di messaggi nella stessa transazione. Quindi, se uno di questi fallisce, tutto viene ripristinato utilizzando lo stesso meccanismo di transazione.