2- TIBCO EMS

EMS (Enterprise Message Service) è un prodotto che implementa le specifiche JMS ed è utilizzato come bus al posto o associato a Rendezvous. Java Message Service (o JMS) è l’insieme di API (con Application Programming Interface (API) e con queste si indicano un insieme di procedure (in genere raggruppate per strumenti specifici) atte all’espletamento di un dato compito; spesso tale termine designa le librerie software di un linguaggio di programmazione., ) appartenente a JavaEE, che consente ad applicazioni Java presenti in una rete di scambiarsi messaggi tra loro.

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

– 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

  • 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 à 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.

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).

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.

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)
  • Publish / Subscribe (TOPICS)

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 è il caso broadcast, il producer non conosce i consumer. Nel secondo invece, 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) .