Spring Integration (parte 1)

Il termine Enterprise Application Integration (EAI) si riferisca da un software o ad una architettura software in grado di integrare applicazioni enterprise eterogenee. Sebbene si possa pensare che le applicazioni EAI possano eseguire le operazioni più disparate, in realtà esistono in tale ambito problemi ricorrenti a cui sono applicabili soluzioni comuni. Questo implica che esistono dei design pattern applicabili nell’EAI che sono stati ben raccolti e documentati nel libro Enterprise Integration Patterns (EIP) di Gregor Hohpe and Bobby Woolf.

Spring Integration (SI) è una architettura di messaggistica, realizzata al di sopra di Spring Framework, che fornisce una implementazione java dei pattern EIP, mettendo a disposizione una serie di componenti che possono essere combinati per realizzare un’applicazione EAI. La configurazione dell’applicazione avviene attraverso un XML che ne definisce le componenti e la loro interazione.

Componenti Principali

I concetti principali di Spring Integration sono:

  1. i producer (sender) ed i consumer (receiver) detti endpoint che si scambiano messaggi;
  2. le pipe dette anche channel che rappresentano i canali di comunicazione tra producer e consumer;
  3. i messaggi che trasportano l’informazione scambiata.

Queste componenti possono essere combinate per realizzare interazioni complesse in cui il messaggio originale subisce diverse operazioni prima di giungere al destinatario finale..

Il messaggio si compone di un header e di un payload. L’header contiene informazioni di sistema attribuite da SI (es. messageId, timestamp, etc.), mentre il payload contiene in dato scambiato dalle applicazioni che può assumere diversi formati (es. XML, JSON, etc.).

Canali

Il canale è la componente SI attraverso la quale i messaggi transitano da un end-point al successivo. Possono essere classificati in due categorie principali: Pollable Channel e Subscribable Channel, che sono dichiarati rispettivamente nelle interfacce java PollableChannel e SubscribableChannel.

I Pollable Channel bufferizzano i messaggi in una coda ed il receiver attivamente richiede il messaggio successivo presente in coda. La coda ha una capacità massima dichiarata al momento della costruzione del canale o in caso contrario corrisponde alla costante Integer.MAX_VALUE. Generalmente questa tipologia di canali sono utilizzati per la comunicazione punto-punto in cui c’è un solo producer ed un solo consumer.

ISubscribable Channel consentono di avere più subscriber/consumer registrati come consumatori dei messaggi. Il messaggio è ricevuto da tutti i consumer registrati. Non hanno un buffer per la conservazione di messaggi ma mantengono la lista aggiornata dei subscriber. Un esempio di applicazione che utilizza tale tipologia di canali è la gestione  degli eventi.

Ovviamente esistono diverse implementazioni di tali tipologie di canali che sono descritte nella documentazione ufficiali al link Messaging Channels. In particolare menzioniamo il DirectChannel ed il NullChannel. Il primo implementa una semplice connessione point-to-point, mentre il secondo 8da usare solo per test) è un canale che non delivera mai il messaggio sebbene restituisca sempre TRUE al sender e NULL al receiver.

Un DirectChannel si definisce semplicemente con l’XML:

Altre implementazioni di canale fornite da SI sono: PublishSubscribeChannel, QueueChannel, PriorityChannel, RendezvousChannel, ExecutorChannel e ScopedChannel.

Message Endpoint

I message endpoint sono le componenti che isolano il codice applicativo dall’infrastruttura di comunicazione fornita da Spring Integration. Esistono divers tipologie di message endpoint:

  1. Adapter: per la connessione dei canali a sistemi esterni;
  2. Filter: per filtrare i messaggi nel canale;
  3. Transformer: per la conversione dei messaggi;
  4. Enricher: per aggiungere contenuto informativo ai messaggi;
  5. Service activator: per l’invocazione di servizi;
  6. Gateway: per agganciare sistemi di messaggistica esterni;
  7. Router: per la selezione del canale che il messaggio deve percorrere;
  8. Splitter: per suddividere il messaggio in più messaggi per essere inviati su canali diversi.
  9. Aggregator: aggrega più messaggi in un unico messaggio.

Di seguito vediamo alcuni esempi di message endpoint, rimandando l’analisi degli altri ad un successivo post.

Channel Adapter

E’ utilizzato per connettere il canale a sistemi esterni (bridge) di fatto disaccoppiando il messaggio dal trasporto e protocollo utilizzato. Possono essere di tipo inbound, ovvero “portano” il messaggio dentro il canale, o outbound, ovvero lo portano fuori. Spring Integration fornisce diversi adapter configurabili: Stream, File, JMS, JDBC & JPA, FTP e SFTP, Feed (RSS, Atom, etc), Mail, MongoDB, UDP, Twitter, etc. Ovviamente è possibile implementarne di custom.

Il primo e più semplice channel adapter è l’inbound/outbound channel adapter che esegue un qualsiasi metodo di un bean e lo invia in un canale dopo averlo convertito in un messaggio. Il seguente esempio utilizza due classi Producer e Consumer che vengono utilizzate da due channel adapter connessi mer mezzo di un direct channel:

Il tag <int:poller fixed-rate="1000"/> indica che il canali di input deve essere interrogato ogni secondo.

Spring Integration supporta anche una descrizione visuale del sistema prodotto, conforme alle icone introdotte nel libro Enterprise Integration Patterns

Un altro semplice adapter è lo standard-in/out/error che consente di leggere o scrivere il messaggio nello standard in/out/error. Per questi adapter esiste uno specifico namespace che che introduce tre nuovi tag: stdin-channel-adapterstdout-channel-adapterstderr-channel-adapter con utilizzo intuitivo. Il seguente XML definisce un sistema in cui l’input da tastiera viene letto e scritto su consolle:

Un’altra interessante coppia di adapter è quella che consente di leggere e scrivere messaggi su filesystem. Anche in questo caso SI introduce un ulteriore namespace che “ridefinisce” i tag inbound-channel-adapter e outbound-channel-adapter. Il seguente XML configura un sistema in cui i file nella cartella inbound sono letti e copiati nella cartella outbound.

Esecuzione

Prima di procedere con gli altri componenti di Spring Integration, vediamo la semplice classe che attiva il sistema, che banalmente “tira su” il contesto di Spring.

Codice Sorgente

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

© 2018 Java Boss - Theme by HappyThemes