Search code examples
spring-integrationenterprise-integration

Spring Integration and the Message Bridge Pattern

Learning Spring Integration. I am trying to understand the IntegrationFlow DSL and the use of its to(IntegrationFlow) method.

It seems that this allows us to daisy-chain the end of Flow 1 with the beginning of Flow 2.

Is this the DSL's implementation of the Message Bridge pattern, where channels are connected to each other? If not, how is this different than a Message Bridge? Is it similar to the direct: and seda: endpoints in Apache Camel parlance, that is, a way of snapping routes together?

Solution

  • Yes, we can treat it that way, but technically it is just composition of more high-level messaging abstractions together. There is no EIP Message Bridge pattern implementation as a single top-level component.

    Let's see it objective:

    How can multiple messaging systems be connected so that messages available on one are also available on the others?

    Use a Messaging Bridge, a connection between messaging systems, to replicate messages between systems.

    So, let's say we need to transfer data from Apache Kafka topic into some IBM MQ queue. For Kafka we use an KafkaMessageDrivenChannelAdapter and for IBM MQ - JmsSendingMessageHandler. We connect them via DirectChannel the rest is done with internal (de)serializers to remap Kafka records into JMS messages. Does this approach implement the mentioned pattern? I think yes. And with different channel adapters we can implement many use-cases transferring data from one source to another.

    And that Message Bridge confirms our assumption:

    The Messaging Bridge is a set of Channel Adapters.

    Now about to(IntegrationFlow) operator. This is just a convenient API to decompose your configuration between different logical, reusable pieces. At runtime we don't have any IntegrationFlows interacting: only endpoints are exchanging messages via channels between them.

    Yes, you can treat Camel's direct: and seda: as a MessageChannel abstraction in terms of Spring Integration. Yes, we can say that this separation via channel is a bridge we have talked before. But in terms of Spring Integration sometimes there is no reason to separate the logic and people just do this:

    IntegrationFlow.from(Kafka.messageDrivenChannelAdapter())
               .handle(Jms.outboundAdapter()) 
               .get();

    Is this a bridge we saw before? I guess yes. Even if we don't have an explicit channel definition it is still there for us auto-created by the framework.