0

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?

hotmeatballsoup
  • 385
  • 6
  • 58
  • 136

1 Answers1

1

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.

Artem Bilan
  • 113,505
  • 11
  • 91
  • 118
  • Thanks @Artem Bilan, when we use `IntegrationFlow.to(anotherFlow)` is this a blocking/synchronous integration (like `direct:` in Camel) or is it an async/non-blocking (`seda:`-like) integration? – hotmeatballsoup Dec 09 '22 at 15:31
  • It is really depend on how you start that target flow: of course by default Spring Integration uses `DirectChannel` instances between endpoints. If you start that flow with other channel type, then you can treat it as that `seda` from Camel. See more info about channel types in docs: https://docs.spring.io/spring-integration/docs/current/reference/html/core.html#channel-implementations. Also, I'm not sure why this doc was not clear for you: https://docs.spring.io/spring-integration/docs/current/reference/html/dsl.html#integration-flows-composition – Artem Bilan Dec 09 '22 at 16:04
  • OK thanks again @Artem Bilan. So if I wanted SEDA-like (non-blocking/async) behavior between two flows (say, Flow A and B), would I just start Flow B with an `ExecutorChannel` backed by a `TaskExecutor`? And then just call `flowA.to(flowB)`? – hotmeatballsoup Dec 09 '22 at 16:15
  • Correct. That will work. It will also work like this `channel("the input channel name of another flow")` - if you really like something Camel `seda:` similar. This is really not a producer responsibility to care about the channel type. We just need to know its name. It is a consumer task to decide how it would like to receive input messages. – Artem Bilan Dec 09 '22 at 16:50
  • OK that makes sense. Bear with me, this is a big API but I am chugging through it. I do have previous Camel experience that I can transfer into this, but Spring Integration has its own idioms and implementations. Thanks for the help here. – hotmeatballsoup Dec 09 '22 at 16:55