Spring Integration – Channels

Spring Integration – Channels

Spring Integration is a framework providing implementation of enterprise integration patterns. To get started on Spring Integration framework we need to first understand some basic constructs.

Since Spring Integration framework’s primary job is providing architecture plumbing, following are the building-blocks of any SI solution:

  1. Message: This is the payload which moves between various nodes which are integrated by the framework
  2. End-point: These are the nodes in the system which are being connected
  3. Channel: Think of it as the pipe concept from Linux whose job is to provide connector or bridge between the end-points

In this blog we will focus on the main types of Message Channels available in Spring Integration.

Channel Classification

Following is the classification of the commonly used channels:

  1. Subscribable: Follows the event driven consumer pattern which doesn’t buffer messages
    • Unicasting: Point-to-point channels which means only one consumer
      • DirectChannel: Calls its subscriber immediately from the same thread
      • ExecutorChannel: Calls its subscriber via an Executor so you can maintain a pool of threads for handling the request
    • Broadcasting: Publish-Subscribe channels , that is, there can be multiple consumers
      • PublishSubscriberChannel: Messge is processed by multiple subscribers to this channel
  2. Pollable: Follows the polling consumer pattern which can even buffer messages. They all are point-to-point channels.
    • QueueChannel: Buffers messages in an unbounded linked blocking queue but the capacity can be specified. The messages are either picked up by the subscriber or they expire on timeout
    • RendezvousChannel: It is same as QueueChannel but with capacity zero. Which means unless the message is received the thread blocks so no new message is picked up
    • PriorityChannel: It is also similar to QueueChannel but it uses priority queue unlike the FIFO approach used in QueueChannel. This channel determines the priority from the ‘priority’ header

By default the QueueChannel and PriorityChannel store the messages in memory but they can also be persisted in database although it would be better to use a message broker if there is a requirement for persistence.