Spring Integration (parte 3)

Negli articoli Spring Integration (parte 1)  e Spring Integration (parte 2) abbiamo visto come realizzare in modo semplice un sistema EAI con Spring Integration ed abbiamo introdotto alcune delle sue componenti principali. Proseguiamo analizzando altri componenti di tipo message endpoint.

Enricher

Gli Enricher aggiungono informazioni o contenuto ad un messaggio e possono essere considerati come delle varianti dei Transformer. Sostanzialmente prelevano il messaggio dal canale di input, aggiungono informazioni all’header o al payload del messaggio e lo inviano nel canale di output. Di base gli enricher sono quindi due: Header Enricher e Payload Enricher.

Header Enricher

Di seguito è mostrato un esempio di header enricher in cui il tag <int:header> consente di inserire nell’header proprietà custom che possono assumere sia un valore costante (header foo nell’esempio) che riferimenti a bean (header bar bell’esempio):

Si noti inoltre che esistono tag specifici per il set di header standard come errorChannel, correlationId, priority, replyChannel, routing-slip, etc.

E’ possibile anche determinare dinamicamente il valore che l’header deve assumere specificando un bean ed un metodo da eseguire per il calcolo del valore. In alternativa è anche possibile utilizzare una espressione SpEL:

Payload Enricher

Un payload enricher aggiunge contenuto al payload del messaggio. Supponendo che il payload sia un bean caratterizzato dalle proprietà property1 e property2, il seguente XML ne ridefinisce il valore:

Gli enricher degli esempi precedenti possono essere combinati producendo la sequenza di operazioni mostrate nell’immagine seguente, in cui i due enricher sono applicati consecutivamente:

L’invio del messaggio nel canale di input può essere eseguito, ai fini del test, attraverso il seguente codice:

L’output prodotto dalla classe Inspector sarà invece:

Custom enricher possono essere implementati attraverso l’utilizzo di un altro componente di Spring Integration, il Service Activator descritto nel seguito. Sostanzialmente il tag <enricher> dispone dell’attributo request-channel che indica un canale condiviso col service activator il quale, una volta lavorato il messaggio, lo restituisce all’enricher per poi proseguire sul canale di output. 

Service Activator

Si tratta di un endpoint che consente di connettere uno bean ad un calane ed assumere il ruolo di service. I messaggi nel canale vengono prelevati dal service activator, il quale invoca il bean per processarli. Se è prodotto un output il risultato è inviato al canale di output dichiarato o, se non definito, al canale di reply specificato nell’header del messaggio.

Il bean che funge da service non deve avere particolari caratteristiche. Il motore semplicemente reperisce il bean indicato nella proprietà ref del tag service-activator ed invoca il metodo specificato nell’attributo method. Non vi sono vincoli alla signature del metodo, quindi tutti e tre i metodi indicati nel codice riportato sotto sono ammessi. La differenza è che il motore passerà l’intero messaggio al metodo 1, il solo payload al 2 e nessun dato al 3.

Se nel tag service-activator nessun metodo è indicato il motore invocherà il metodo 2. Alternativamente è possibile definire un bean con un solo metodo pubblico che quindi sarà invocato dal motore com service.

Non è necessario che il metodo restituisca un valore, ma se lo fa è possibile inviare il risultato in un canale di output come payload di un nuovo messaggio. E’ anche possibile istruire il motore rendendo obbligatoria la restituzione di un risultato provocando alternativamente una eccezione.

Gateway

Lo scopo dei gateway è quello di disaccoppiare il codice applicativo dalle API di Spring Integration, nascondendole  e fornendo una interfaccia che è utilizzata dalla business logic in modo trasparente. Esistono due tipologie di gateway:

  1. Synchronous gateway bloccano l’applicazione fino a quando Spring Integration ha completato l’elaborazione della request;
  2. Asynchronous gateway consentono all’applicazione di continuare l’elaborazione per recuperare l’esito della lavorazione della request in un momento successivo.

L’implementazione di un gateway è molto banale, è sufficiente definire una interfaccia che può poi essere iniettata come componente in un qualsiasi bean ed utilizzato in modo totalmente trasparente per l’applicazione. Il motore, per mezzo di un GatewayProxyFactoryBean genera un proxy per l’interfaccia che si occuperò della reali interazione con le API di Spring Integration. L’implementazione del gateway è naturalmente guidata dalla configurazione. Consideriamo ad esempio il seguente XML dove è dichiarato un messageChannel ed uno standard output adapter che visualizza il contenuto del canale sulla consolle.

L’applicazione può inviare messaggi al canale per mezzo del gateway ed in particolare ottenendo un riferimento all’interfaccia it.javaboss.TestGateway così definita:

L’interazione con SI avverrà quindi nello stesso modo con cui l’applicazione interagisce con un qualsiasi altro bean:

Codice Sorgente

Il codice sorgente completo degli esempi visti è scaricabile qui javaboss-si-parte3.

 

How useful was this post?

Click on a star to rate it!

Average rating 0 / 5. Vote count: 0

No votes so far! Be the first to rate this post.

As you found this post useful...

Follow us on social media!