Abbiamo visto alcune implementazioni dei Channel fornite da Spring Integration. Vediamo adesso quellla di default, nonchè la più comune: il Direct Channel.
Direct Channel
Ha una semantica point-to-point ed implementa l’interfaccia Publish Subscribe Channel dunque invia i messaggi direttamente ad un sottoscrittore.
Differisce dalla Publish Subscribe Channel anche in quanto invia ogni messaggio ad un singolo Message Handler sottoscritto.
Una delle sue caratteristiche è che utilizza un solo thread per effettuare l’operazione su entrambe le sponde del canale: ad esempio se un Handler è sottoscritto ad un Direct Channel e viene inviato un messaggio, questo comporterà l’invocazione del metodo dell’Handler handleMessage(Message) direttamente all’interno del thread del sender, prima che il metodo send() restituisca un valore.
Si noti che essendo l’opzione “più semplice” ed essendo che non aggiunge alcun overhead, questo canale è quello utilizzato di default da Spring Integration.
Il Direct Channel delega internamente ad un Message Dispatcher l’invocazione del suo Message Handler sottoscritto e può utilizzare una strategia di load-balancing. Il load-balancer determina l’ordine delle invocazioni nel caso in cui ci siano più handler sottoscritti allo stesso canale (ad esempio utilizzando la strategia round-robin che comporta una semplice rotazione tra i vari handler).
Per ulteriori informazioni sul load-balancing, si consiglia di leggere la parte riguardante il Direct Channel a questo indirizzo:
static.springsource.org/spring-integration/reference/html/messaging-channels-section.html
ExecutorChannel
È molto simile al Direct Channel (semantica point-to-point).
La differenza chiave sta nel fatto che questo canale delega il dispacciamento ad un’istanza di Task Executor. Ciò significa che il metodo send() non dovrebbe essere bloccante ma anche che l’invocazione dell’handler potrebbe non avvenire nel thread del sender.
Si noti che ci sono situazioni in cui il metodo send() potrebbe essere bloccante, ad esempio se il Task Executor utilizza una rejection-policy che comporta l’esecuzione del metodo nel thread del client nel momento in cui è stato raggiunto il numero massimo di thred eseguibili contemporaneamente (la Thread Pool ha raggiunto la sua massima capacità e la coda dei task in attesa è piena).
