TIBCO EMS

EMS (Enterprise Message Service) è un prodotto che implementa le specifiche JMS ed è utilizzato come bus al posto o associato a Rendezvous.

EMS (Enterprise Message Service) è un prodotto di messaggistica sviluppato dalla società TIBCO. EMS implementa le specifiche JMS (Java Message Service), che è uno standard di messaggistica per la comunicazione asincrona tra applicazioni distribuite.

EMS può essere utilizzato come bus per la comunicazione tra applicazioni distribuite, sostituendo o associandosi a prodotti come Rendezvous di TIBCO. In questo modo, EMS consente alle applicazioni di inviare e ricevere messaggi in modo affidabile, garantendo che i messaggi siano consegnati nell’ordine corretto e che non vengano persi.

EMS supporta molteplici protocolli di comunicazione, tra cui TCP/IP, HTTP e HTTPS. Inoltre, EMS offre funzionalità avanzate come il clustering, la persistenza dei messaggi su disco e la scalabilità orizzontale per garantire l’affidabilità e le prestazioni elevate. EMS è disponibile per molte piattaforme, tra cui Windows, Linux, Solaris e AIX.

Java Message Service (o JMS) è l’insieme di API, e con Application Programming Interface e con queste si indicano un insieme di procedure atte all’espletamento di un dato compito; sono cioe’le  librerie software di un linguaggio di programmazione appartenenti a JavaEE, che consentono ad applicazioni Java presenti in una rete, di scambiarsi messaggi tra loro, e quindi:

– Il framework JMS fornisce una base per lo sviluppo MOM (message oriented middleware).

Message Oriented Middleware (MOM) è una categoria di software che fornisce una piattaforma per la comunicazione e lo scambio di messaggi tra applicazioni distribuite in un ambiente di sistema. Si basa sul concetto di messaggistica asincrona, in cui le applicazioni possono inviare e ricevere messaggi in modo indipendente l’una dall’altra.

Le caratteristiche principali del Message Oriented Middleware includono:

1. Messaggistica asincrona: le applicazioni possono inviare e ricevere messaggi in modo asincrono, senza dover essere attivamente in esecuzione nello stesso momento. I messaggi possono essere memorizzati e consegnati in modo affidabile anche se i destinatari non sono disponibili al momento dell’invio.
2. Modello publish-subscribe: le applicazioni possono pubblicare messaggi su un argomento (topic) specifico, e gli altri componenti interessati a quell’argomento possono sottoscriversi per ricevere i messaggi. Questo modello consente la comunicazione di tipo broadcast in cui un messaggio può essere ricevuto da più destinatari.
3. Gestione della coda dei messaggi: i messaggi inviati tra le applicazioni vengono gestiti tramite code di messaggi. I messaggi vengono accodati in modo che possano essere consegnati in modo sequenziale e garantito ai destinatari.
4. Affidabilità e integrità dei messaggi: i sistemi di MOM forniscono meccanismi per garantire la consegna affidabile dei messaggi, consentendo la persistenza dei messaggi e la rilevazione e gestione degli errori di trasmissione.
5. Interoperabilità: i middleware message-oriented sono progettati per supportare standard di comunicazione come JMS (Java Message Service) che consente l’interoperabilità tra applicazioni scritte in diversi linguaggi di programmazione.

L’obiettivo principale del Message Oriented Middleware è consentire la comunicazione affidabile, scalabile e flessibile tra le applicazioni distribuite, facilitando l’integrazione e lo scambio di dati tra i diversi componenti di un sistema. Viene ampiamente utilizzato in scenari complessi come sistemi di elaborazione distribuita, integrazione di applicazioni aziendali, sistemi di messaggistica in tempo reale e molto altro ancora.

– I sistemi di messaging, permettono un elevato disaccoppiamento delle applicazioni di un sistema distribuito  (loosely coupled applications).

La flessibilità di JMS ed il livello di disaccoppiamento che introduce lo rendono un sistema vincente non solo nelle applicazioni B2B, ma anche in realtà d’integrazione (EAI) e per le Mobile Applications.

Il disaccoppiamento dei client è reso possibile grazie alla mediazione del messaging server: i client non devono sapere nulla l’uno dell’altro

Tibco Enterprise Message Service implementa JMS

• Il messaging è un sistema di comunicazione tra componenti software
• I sistemi di messaging permettono un elevato disaccoppiamento delle applicazioni di un sistema distribuito (loosely coupled  applications)

JMS si basa sulla creazione e sull’invio di messaggi

L’API JMS consente ai programmatori di creare e inviare messaggi, che possono contenere dati, informazioni di stato o istruzioni di controllo, ad altre applicazioni in modo asincrono, ovvero senza dover aspettare una risposta immediata. Inoltre, JMS offre funzionalità di messaggistica affidabile, che assicura che i messaggi vengano consegnati in modo coerente e sicuro ai destinatari, anche in caso di interruzioni di rete o di altri problemi.

• Il creatore dei messaggi è detto producer
• Il ricevente dei messaggi è detto receiver
• Tibco EMS server è l’intermediario per lo scambio dei messaggi e ne assicura la consegna al receiver giusto e i  client non devono sapere nulla l’uno dell’altro
• Tibco EMS server supporta funzionalità di fault tolerance

Questo prodotto fa si che messaggi di diversa natura posano essere letti tra di loro anche da ambienti di natura diversa grazie al fatto che EMS li traduce.

Un messaggio proveniente da una qualsiasi macchina a EMS.

1-EMS lo invia a 1 delle 4 macchine di INTEGRATION ( sono 4 )  e quindi queste elaborano il messaggio , reinviandolo a EMS

2-EMS invia il messaggio elaborato ad un altro ambiente o altra macchina.

E’ caratterizzato da Topic e code:

Un Topic è equivalente al modello di pubblicazione / sottoscrizione di TIBCO Rendezvous.

Significa che i Topics in TIBCO Rendezvous fungono da canali di comunicazione utilizzati per la distribuzione di messaggi, e che questo modello è utilizzato per consentire ai vari componenti di un’applicazione di comunicare tra loro in modo asincrono attraverso l’invio e la ricezione di messaggi su Topics specifici. In altre parole, il modello di pubblicazione / sottoscrizione di TIBCO Rendezvous è basato sui Topics, che fungono da canali di comunicazione per la distribuzione dei messaggi.

In effetti hai uno o più editori che pubblicano su un argomento (soggetto) e ogni abbonato che ascolta su quell’argomento riceverà una copia del messaggio.

Una Coda funziona in modo diverso.

Viene spesso descritto come un modello punto-punto, il che non è del tutto vero.

Quando si utilizzano le code, si avranno uno o più mittenti che inviano a una coda e uno o più ricevitori che ascoltano quella coda. Quando un mittente invia un messaggio a una coda, * solo uno * dei destinatari riceverà una copia di quel messaggio. Questo è eccezionale per il bilanciamento del carico. In un certo senso questo comportamento può essere paragonato a TIBCO Rendezvous Distributes Queues (RVDQ).

TIBCO Rendezvous Distributes Queues (TDQ) è una funzionalità di TIBCO Rendezvous, una piattaforma di messaggistica in tempo reale utilizzata per la comunicazione tra applicazioni distribuite. Le caratteristiche principali di TDQ includono:

1. Distribuzione dei messaggi: TDQ distribuisce i messaggi tra i nodi della rete in modo efficiente, garantendo che i messaggi siano consegnati in modo affidabile e in tempi brevi.
2. Gestione della coda: TDQ offre una gestione avanzata della coda dei messaggi, consentendo ai client di accedere a una coda condivisa di messaggi e di elaborarli in modo concorrente. Ciò consente una maggiore scalabilità e una migliore gestione del carico di lavoro.
3. Flessibilità: TDQ offre una grande flessibilità nella configurazione delle code, consentendo di specificare le politiche di accesso, le priorità dei messaggi, i filtri e altre opzioni avanzate.
4. Monitoraggio e diagnostica: TDQ offre anche funzionalità avanzate di monitoraggio e diagnostica, tra cui la visualizzazione delle statistiche di utilizzo della coda, il controllo della disponibilità e della capacità della coda, la tracciabilità dei messaggi e il supporto per il debug.
5. Sicurezza: TDQ offre una serie di meccanismi di sicurezza avanzati, tra cui l’autenticazione e l’autorizzazione, la crittografia e il supporto per i protocolli di sicurezza standard del settore.

In sintesi, TIBCO Rendezvous Distributes Queues offre una soluzione potente e flessibile per la gestione della coda dei messaggi distribuiti, consentendo una maggiore scalabilità, una migliore gestione del carico di lavoro e un elevato livello di affidabilità e sicurezza.

Questo comportamento di “bilanciamento del carico” non può essere realizzato con argomenti.

Alla domanda se si desidera utilizzare code o argomenti:

-Se la propria architettura richiede che un messaggio venga recapitato a più abbonati, selezionare gli argomenti o TOPIC

–Se esiste un solo abbonato o hai bisogno di funzioni di bilanciamento del carico, usa le CODE.

Nota anche che non puoi davvero parlare di “push” o “pull” qui. Un client (abbonato/destinatario) deve connettersi esplicitamente al server E4JMS e, una volta connesso, e sono disponibili nuovi dati su una coda argomento o , il server invierà questi dati a quel client.

L’uso delle code non fa in modo che l’applicazione utilizzi il polling per recuperare i suoi dati, invece il server invierà automaticamente nuovi messaggi al destinatario

JMS supporta due protocolli di comunicazione:

• Point to point (QUEUES – CODE)
• Publish / Subscribe (TOPICS – ARGOMENTI)

Le specifiche JMS:

• Forniscono l’implementazione di questi due domini in maniera separata;
• Definiscono le compatibilità per ogni dominio, dando la possibilità ai produttori di implementarle senza costringere l’applicazione a  legarsi ad esso.

• Il Point-To-Point (PTP) lavora sfruttando i concetti di coda (Queue), producer  (o sender) e consumer (o receiver )
• Ogni messaggio ha un solo producer ed un solo receiver ‘effettivo’
• I messaggi sono conservati in una QUEUE fino a quando non giungono a destinazione
• Il producer crea il messaggio e lo invia sulla QUEUE.
• Il receiver recupera il messaggio dalla QUEUE e invia un messaggio di Acknowledgement di ricezione avvenuta.

• Ogni messaggio ha un solo consumer. Ciò non vuol dire che ci deve essere un solo receiver ma che solo un receiver otterrà il messaggio.
• Non c’è una dipendenza tra il sender ed il receiver. Il sender può inviare il messaggio anche quando non ci sono receivers attivi, appena un receiver si attiverà verranno letti i messaggi che sono stati inviati sino a quel momento.

 

Il Publish/Subscribe lavora, invece, sfruttando il concetto di topic, publisher e subscriber.

• Il producer del messaggio è noto come “publisher”
• Il receiver del messaggio è noto come “subscriber”
• I messaggi sono conservati in “topic”
• Più publishers possono inviare messaggi su un “topic” e più subscribers possono ricevere lo stesso messaggio (broadcast)

Publisher : s’intende uno o più clients che “registrano” il messaggio in una topic che è resa disponibile a tutti i subscribers

Subscriber : Si mette in ascolto sulla topic e reperisce i messaggi che   sono inviati dal momento che lui si è messo in ascolto, perdendo i   precedenti

• Se ci sono più subscribers in ascolto sulla topic i messaggi verranno ricevuti da tutti
• C’è una dipendenza temporale tra il publisher ed il subscriber

se nessun subscriber è attivo mentre un publisher invia un messaggio quest’ultimo verrà perso

Riassumendo:

• Publisher / Subscriber: uno o più Consumer si “iscrivono” ad un argomento (Topic) e ricevono gli aggiornamenti quando uno o più Producer li pubblicano.
• Point to Point: un Consumer legge dalla propria coda (Queue) i messaggi inviati da uno o più Producer.

Il primo caso(Publisher / Subscriber) è il caso broadcast, il producer non conosce i consumer.

Nel secondo invece, (Point to Point)il producer deve conoscere il consumer (ed il suo indirizzo).

La struttura dei messaggi JMS è standard ed è composta dalle seguenti tre parti:

• Message Header (required): intestazione del messaggio (informazioni per il routing e la consegna del msg)
• Property Fields (optional): properties che ogni vendor può aggiungere.

Esempio: Tibco EMS prevede la property “JMS_TIBCO_COMPRESS” (permette la compressione dei messaggi)

• Message Body (optional): corpo del messaggio

Il message header è costituito esattamente da 10 campi che  devono essere obbligatoriamente presenti; tali campi sono usati sia dai client che dai provider al fine di identificare ed inoltrare il messaggio.

Tra questi sono presenti

• JMSMessageID: identificatore univoco del pacchetto;
• JMSDestination: definisce il nome della Queue o Topic a cui il pacchetto è destinato;
• JMSPriority: definisce la priorità (1=più bassa/9=più alta);
• JMSTimestamp: definisce il timestamp del tempo d’inoltro;
• JMSType: tipo del messaggio (text, bytes, map, etc) .

.