Sistemi di messaging: Differenza tra Broker e Brokerless nelle architetture informatiche
In informatica, la maggior parte dei sistemi di messaging utilizza un’architettura a stella o a hub con al centro un messaging server, il broker, utilizzato dai vari componenti o applicazioni per comunicare tra di loro. Questo modello porta alcuni vantaggi. Le applicazioni per comunicare tra di loro, devono conoscere solo l’indirizzo del broker, il quale poi instrada i messaggi alla giusta applicazione in base a determinati criteri (che si basano generalmente sul nome della coda, meccanismi di routing o proprietà del messaggio), invece di utilizzare indirizzi fisici delle applicazioni. Il tempo di vita del mittente e del destinatario non devono necessariamente sovrapporsi.
L’applicazione mittente può inviare il messaggio e chiudersi, perché il messaggio sarà disponibile in qualsiasi momento successivo per il destinatario. Il modello è robusto contro i guasti dell’applicazione, in quanto, quando se ne verifica uno, i messaggi precedentemente inviati e non ancora ricevuti non vengo persi. Gli svantaggi sono principalmente due: richiede un’eccessiva quantità di comunicazione di rete e il broker può rappresentare un collo di bottiglia per l’intero sistema, dato che tutti i messaggi devo passare attraverso di lui. Questo modello può essere utilizzato sia con approcci di tipo SOA sia con più efficienti approcci a pipeline.
Nelle architetture brokerless la comunicazione tra le applicazioni è diretta. In questo modo si elimina il collo di bottiglia introdotto dal broker, ideale per applicazioni che necessitano di bassa latenza e un alto throughput. S’introduce però la necessità di conoscere gli indirizzi fisici delle applicazioni per instaurare la comunicazione, condizione accettabile per casi semplici ma inaccettabile nel caso in cui si debbano supportare centinaia di applicazioni.
Si può quindi introdurre il concetto di broker come servizio di directory dove il broker distribuisce informazioni sugli indirizzi delle applicazioni. In quest’approccio l’applicazione si registra al broker, rendendo noto il suo indirizzo fisico, e per inviare messaggi a un’altra applicazione richiede l’indirizzo di quest’ultima al broker, il quale mantiene aggiornate le informazioni sulle applicazioni attive e i loro indirizzi. In questo modo si possono ottenere buone performance e una più semplice gestione del sistema.
Un altro modello architetturale è quello a broker distribuito, che permette di sfruttare alcuni vantaggi sia del modello a broker sia di quello brokerless. Permette al tempo di vita delle applicazioni di non doversi necessariamente sovrapporre, perché i messaggi sono memorizzati nel broker fino a che il destinatario non diventa disponibile, garantendo inoltre che i messaggi non vengano persi a seguito di un crash di un’applicazione. Per ottenere ciò è necessario introdurre un broker tra ogni coppia di applicazioni che vogliono comunicare, il quale si occupa anche di ottenere gli indirizzi delle applicazioni attraverso il servizio di directory. Si mantiene in questo modo la manutenibilità senza avere il collo di bottiglia di un singolo broker, i vari broker posso anche risedere in macchine dedicate, differenti da quelle in cui risiedono le applicazioni.
Per aumentare l’affidabilità si può utilizzare un servizio di directory distribuito. Nei precedenti modelli se il servizio di directory non è disponibile, in seguito a un guasto, non è possibile istanziare nuove comunicazioni, poiché non è possibile ottenere gli indirizzi delle applicazioni. In questo modello il servizio di directory è distribuito eliminando il single point of failure nella gestione della configurazione.
