Spring Integration (parte 2)

Introduzione

Nell’articolo Spring Integration (parte 1) 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.

Filter

I Filtri sono endpoint che possono essere collocati tra un canale ed il successivo allo scopo di filtrare determinati messaggi. I messaggi rigettati possono essere scartati (e quindi persi) oppure deviati in un calale degli scarti. La selezione dei messaggi può essere fatta in base a quanto contenuto nell’header dello stesso o nel payload del messaggio.

Come nel caso degli Adapter, SI fornisce diverse implementazioni di Filter che possono essere utilizzati semplicemente configurandoli ma ovviamente è possibile anche realizzare dei custom filter semplicemente implementando l’interfaccia MessageSelector che definisce il metodo accept(). Tale metodo riceve in input il messaggio e restituisce un output boolean che indica se accettare il messaggio (TRUE) o rifiutarlo (FALSE). Ad esempio la seguente classe implementa un filtro che seleziona messaggi contenenti oggetti di tipo java.io.File con nome che inizia con la string msg1:

Adattiamo l’esempio mostrato nel post Spring Integration (parte 1) relativo al channel adapter che legge e scrive su filesystem al fine di filtrare i file letti con il filtro definito sopra. Il tag <filter> che introduce il filtro ha come attributi il canale di input (input-channel), quello di output (output-channel), eventualmente quello di scarto (discard-channel) ed infine il riferimento al bean che implementa il filtro:

<filter input-channel="..." output-channel="..."  discard-channel="..." ref="..."/>

L’XML d’esempio è il seguente:

Il sistema definisce tre direct channel: uno di inbound, uno di outbound ed uno per gli scarti del filtro, ai quali sono collegati gli adapter che leggono e scrivono su filesystem. Il diagramma che rappresenta il sistema è il seguente:

Tra i filtri forniti direttamente da Spring Integration i più interessanti sono:

  • Expression Filter: che consentono di definire una espressione in Spring Expression Language (SpEL) che definisce se accettare o rifiutare il messaggio.
  • Xpath Filter: che consentono di definire espressioni per un payload XML al fine di selezionare i messaggi accettati.
  • XML Validating Filter: selezionano i messaggi in base al fatto che soddisfino o meno un determinato schema.

Transformer

I Transformer sono endpoint che trasformano il payload o la sua struttura in un nuovo messaggio modificato. Ad esempio possono convertire un payload XML in uno JSON. Anche in questo caso Spring Integration fornisce un set di component built-in che implementano diversi transformer:

  • Object to XML (Marshaller) e XML to Object (Unmarshaller) transformer.
  • Object to JSON e JSON to Object transformer.
  • Object to String e String to Object transformer.
  • Object to Map e Map to Object transformer.
  • String to String transfomer che utilizzano una espressione SpEL.

Un esempio di transformer dell’ultimo tipo che esegue il reverse di una stringa letta da standard input è il seguente:

Che implementa il diagramma mostrato nella figura seguente:

Anche nel caso dei Transfomer è possibile utilizzare un semplice POJO per definire un custom transformer.

Router

I router sono endpoint che si occupano della distribuzione dei messaggi, prelevandoli da un canale di inbound e indirizzandoli su uno o più canali di outbound. Tra queste tipologie di endpoint distinguiamo i Content Router, ovvero quei router che ispezionano il messaggio per determinare il canale destinato a riceverlo. SI mette a disposizione diversi content router:

  • Payload Type Router: instradano il messaggio in base alla tipologia del payload.
  • Header Value Router: instradano il messaggio in base al valore di un attributo nell’header del messaggio.
  • XPath Router: determinano il canale da seguire in base al contenuto dell’XML. Questo router definisce solamente il canale di inbound mentre quello di outbound è estratto dall’XML.
  • Exception Router: questo router richiede che il payload sia una istanza di java.lang.Throwable. Lavorano in modo simile ai payload type router con la differenza che questi navigano la gerarchia del tipo di payload per determinare il canale il canale più specifico, mentre gli exception router navigano lo stack trace.

Altre tipologie di router non eseguono alcuna ispezione del messaggio e semplicemente smistano il messaggio su tutti i canali disponibili. I Recipient List Router sono un esempio di tali router in cui il messaggio è inviato a tutti i canali (recipient) indicati in configurazione del componente.

Esiste ovviamente la possibilità di realizzare un custom router semplicemente definendo un bean che estende la classe astratta AbstractMessageRouter ed implementando il metodo determineTargetChannels(). Il codice seguente è un esempio di custom router che oltre ad estendere la AbstractMessageRouter, implementa l’interfaccia ApplicationContextAware al fine di ricevere il contesto di spring da cui recuperare i channel disponibili. La selezione del canale è fatta in base al contenuto del payload del messaggio che, per estrema semplicità, indica il nome del canale da seguire.

Di seguito è riportato l’XML di configurazione del sistema in cui è definito uno standard input adapter, due standard output adapter ed uno standard error adapter. I messaggi il cui payload non corrisponde ad uno dei due nomi dei canali messageChannel1 e messageChannel2 sono dirottati sullo standard error.

L’immagine seguente mostra un esempio di interazione con il sistema:Codice Sorgente

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

 

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!