Terracotta rende JMS uno strato non necessario?

Question

Attualmente stiamo scrivendo un'applicazione per la quale l'IT ha già acquistato l'hardware. Il loro approccio era quello di acquistare hardware di grandi dimensioni su cui implementare. Per aggiungere ulteriore elaborazione, pianificano l'aggiunta di server aggiuntivi con lo stesso software. Per soddisfare questo progetto, stiamo usando Terracotta per fornire la possibilità di eseguire più JVM come se fosse uno grande. Indipendentemente dal fatto che questo sia un modo saggio per andare (che non sono ancora convinto), questa è la situazione con cui ho a che fare.

In ogni caso, abbiamo una parte dell'applicazione che utilizza una coda standard di tipo produttore/consumatore. Con Terracotta, siamo in grado di creare una singola coda che funziona con più JVM. Questo è piuttosto lucido e funziona bene.

Ma ora, stiamo trovando ulteriori opportunità per eseguire processi asincroni. Per rendere più coerente la nostra logica di accodamento, stiamo considerando l'utilizzo di JMS per astrarre la logica comune. Dato che non useremo JMS come coda remota (almeno per il prossimo futuro), mi chiedo se JMS stia semplicemente aggiungendo complessità non necessaria.

Eventuali suggerimenti o pensieri? Dovremmo semplicemente continuare a creare code come strutture concorrenti, o trattarle come oggetti separati, potenzialmente remoti?

Answer 1

Una coda di messaggi è essenzialmente solo una struttura di dati in coda con alcune opzioni di fantasia. Se il tuo progetto è come la maggior parte degli altri progetti, non sei utilizzando una qualsiasi delle funzionalità JMS che rendono JMS diverso da qualsiasi precedente implementazione Queue, specialmente dal momento che Terracotta gestisce la persistenza e la distribuzione.

Quindi JMS sta probabilmente aggiungendo complessità alla vostra applicazione, il che è qualcosa a cui JMS è piuttosto bravo. Come tutti i fattori di complessità non necessari, sbarazzati di esso. Se decidi di utilizzare JMS per uno o più motivi, fallo allora.

Answer 2

Un mio collega utilizza Mule, che consente di definire le code che possono essere code intra o inter-JVM.

Sono d'accordo con krosenwald: non è chiaro quale JMS aggiungerebbe nel tuo caso, a meno che non ci sia un piano generale per allontanarsi da Terracotta (o almeno avere l'opzione per).

Answer 3

Non ho usato Terracotta ma stiamo utilizzando un prodotto di caching distribuito molto simile ad esso. Anche la nostra architettura sembra simile a ciò che hai. Con produttori e consumatori seduti sulla stessa cache e condividendo i dati utilizzando il sottosistema di memorizzazione nella cache.

Mentre sono d'accordo sul fatto che l'aggiunta di JMS ora potrebbe essere una complessità inutile per voi, abbiamo scoperto che, mentre slick, la cache distribuita non è la migliore implementazione di un meccanismo di messaggistica. Mentre la stessa semantica può essere creata, alcuni piccoli dettagli causano problemi (come il bilanciamento del carico per i consumatori, che potrebbe richiedere una sincronizzazione aggiuntiva con una cache distribuita, ma funziona naturalmente con JMS.)

Se pensi che i tuoi casi d'uso futuri richiedono più semantics pub-sub con persistenza, ecc., potresti voler iniziare a pensare a JMS. Inoltre, considera la separazione delle preoccupazioni. Stai usando Terracotta per distribuire i dati (che è ciò che è stato progettato per fare). Lo userai anche per distribuire le istruzioni di controllo (cosa che avviene meglio con la semantica di messa in onda)?