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?
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:
So, let's say we need to transfer data from Apache Kafka topic into some IBM MQ queue. For Kafka we use an
KafkaMessageDrivenChannelAdapterand for IBM MQ -JmsSendingMessageHandler. We connect them viaDirectChannelthe 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:
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 anyIntegrationFlows interacting: only endpoints are exchanging messages via channels between them.Yes, you can treat Camel's
direct:andseda:as aMessageChannelabstraction 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: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.