Message-Oriented middleware (MOM)

“Enterprise messaging software has been in existence since the late 1980s. Not only is messaging a style of communication between application, it is also a style of integration”

Si legge su “Active MQ in Action”, dove in 2 righe racchiude tutto il senso dei sistemi bastati su messaggi.

Moltissima documentazione si trova in rete sui Message-Oriented middleware detti MOM, tra wikipedia , google, slideshare,ecc…quindi evito discorsi tecnici troppo lunghi e noiosi e vi delizio solo delle mie impressioni:))!!!!.

Perché MOM e non RPC?

I  sistemi bastati su RPC sincroni hanno dei grandi limiti di fronte alla continua necessità di distribuzione  dati e  iterazione fra moduli eterogenei . I MOM nascono per superare questi limiti, ponendo fra i moduli un “broker”e gestendo la comunicazione a messaggi in modo asincrono, disaccoppiando di fatto le responsabilità tra i moduli .

Facciamo un esempio pratico:
Diciamo che  un modulo A  invia dei dati ad un modulo B che riceve  i dati e li inserisce in un DB.
Vediamo nelle 2 modalità:
Sync RPC:
ModuloA -> Connect(“ModuloB.ip”);
ModuloA ->ExecRemoteProcedureOnMobuleB(Buffer[]); <<—– Il moduloA a questo punto è bloccato
ModuloB->SendAck() ;
ModuloA <<<<— Il modulo A a questo punto è disponibile per un’altra operazione.

Async MOM
ModuloA -> Connect(“MOM.ip”);
ModuloB -> Connect(“MOM.ip”);
ModuloA -> Publish(Buffer[]); <<—- Invia il messaggio ed è subito disponibile
ModuloB->OnReceivedData->InsertBuffIntoDB(Buffer[]);
ModuloB->SendAck() ;

Come si  può vedere dall’esempio le differenze sostanziali sono 2:

1. Nel caso RCP il moduloA si connette direttamente al ModuloB, mentre nel caso MOM entrambi si connettono ad un broker.
2. Nel caso RCP il ModuloA rimane bloccato finché il ModuloB non termina l’operazione, mentre nel caso MOM il ModuloA invia un messaggio sul MOM e torna subito disponibile, il ModuloB riceve il dato e lo elabora in modo autonomo.

Si capisce quindi l’oggettivo guadagno del caso MOM, i moduli lavorano in modo indipendente tutte le operazioni vengono gestite dal broker attraverso delle “code” (concetto che in seguito approfondiremo) .
La cosa che mi ha subito colpito, nell’uso dei broker, è la semplicità con la quale creare un loadbalancer tra i Moduli.
Complichiamo l’esempio , per capire meglio:
Diciamo che il ModuloA invia i dati molto  velocemente ed il  ModuloB non riesce a “smaltire” tutte le richieste. Quindi bisogna aggiungere un altro ModuloB1 in modo da bilanciare le chiamante.
Vediamo nei 2 casi:

1. Sync RCP , il ModuloA deve fare round robin tra i due moduli, in modo bilanciare l’invio dei dati sui due ModuliB.
2. Async MOM , il Modulo A non deve fare niente, basta aggiungere il ModuloB1 e connetterlo al broker ed automaticamente i dati vengono bilanciati.

L’indipendenza dei moduli, nel II° caso, fa sì che che chi invia i dati ( spesso detto Producer) non conosce l’esatta collocazione di chi li riceve e li elabora ( spesso detto Consumer). Questa caratteristica, secondo me, è la chiave per realizzare un sistema scalabile molto molto facilmente senza troppe complicazioni “sistemistiche”.

Nel pochissimo tempo libero che ho  vorrei scrivere un semplice  sistema di LOG asincrono con linguaggi diversi, non tanto perché il mondo ne ha bisogno ma solo a scopo “didattico”.

Il tutto lo troverete su github.com/Gsantomaggio/AsyncLog dove per il momento è vuoto …ma confido in breve tempo di mettere su qualcosa.

Mentre ascolto Led Zeppelin Remasters Vol I , penso a come sviluppare il mio fantastico sistema di log asincrono, penso che utilizzerò  RabbitMQ oppure ActiveMQ come middleware e   MongoDB oppure CouchDB come database.

..to be continued….