Override a "default" reply-channel

[zzantozz]

When setting up a reply-producing message handler, I had expected that I could set a reply-channel on the handler itself, which would serve as a "default" reply channel for any message sent to that handler. Then I expected that I could override that "default" by setting the "replyChannel" header on a message. However it turns out that the message header is only checked if the handler has no reply channel. This seems counterintuitive. Is there a reason it's like this? Is there another way to achieve what I'm trying to do? Basically, that's being able to set different reply channels for different messages, but also *not* set a reply channel for some messages and have them go to the "default" channel for the handler (nullChannel, in this case).

[zzantozz]

As an alternate point of view, since a goal of EIP and SI is decoupling of producers, consumers, and other components, what's the appropriate way to set things up if you have several inbound adapters and several outbound adapters, and some (not all) of the inbound adapters want replies and some (not all) of the outbound adapters can produce replies?

[Cleric]

Hi!

This seems counterintuitive

No, it's OK. If you set an 'outbound-channel' on the endpoint you expect your Message will continue to trevel independently of it's reply channel in the Headers. But when your logic ends and you know by protocol you should return reply you just rely on 'reply channel' header and remove your last 'outbound-channel'.
You should look at this as encapsulation: imagine your Message was travel before through a lot of systems. Now you are getting it and should make some logic and in the end should return some reply. After some time it have been decided to improve logic of your system. So, it will be enough just to decouple your endpoints via additional 'outbound-channel'. But for calling system you're still a black box.
Now imagine what will happen if you will reply independently of 'outbound-channel': your reply-message will return just after first endpoint.

set different reply channels for different messages, but also *not* set a reply channel for some messages

It's easy:

<channel id="someChannel">
	<dispatcher load-balancer="none"/>
</channel>

<bridge input-channel="someChannel"/>

<bridge input-channel="someChannel" output-channel="defaultChannel"/>

In this case the first <bridge> relies *only* on reply-channel header. If there is no one, AbstractReplyProducingMessageHandler thorws ChannelResolutionException.
Thanks to UnicastingDispatcher on the 'someChannel' and disabled loadBalancingStrategy failure of first handler (in our case first <bridge>) will dispatch the Message to the second <bridge>.

Is it what are you looking for?

Take care,
Artem

[oleg.zhurakousky]

And just to add to what Artem already said;
In SI we have a notion of "adapters" and "gateways" where 'adapters' are for one-way communication (no reply) and 'gateways' are bi-directional (produce reply)

[zzantozz]

And just to add to what Artem already said;
In SI we have a notion of "adapters" and "gateways" where 'adapters' are for one-way communication (no reply) and 'gateways' are bi-directional (produce reply)

Hi Oleg. I get the general difference between adapters and gateways. What I don't quite get yet is that when you bring a message into the system, it may or may not have a reply channel. And somewhere down the line, it's going to go to either an outbound adapter, which doesn't care about the reply channel, or an outbound gateway, which does. What I want--at least I think I want this--is that when a message with a reply channel goes to an outbound gateway, then the reply should go back to the message's reply channel. But in any other case--no reply channel in the message or going to an outbound adapter--just don't worry about replying. I'm not seeing how to do that yet. It's possible, though, that I'm wrong about what I want, and I'd be happy for someone to point out to me why it would be a bad idea and how to rectify the situation.

[Cleric]

Where can I find documentation on that?

http://static.springsource.org/sprin...-directchannel
However my solution is coming from experience

[zzantozz]

Artem, thanks for another detailed answer. I'm not sure I'm following this one completely. I need to reread it a couple of times. But are you saying that with the following config, if I send one message that has a replyChannel header and one message that doesn't to "someChannel", that this setup will cause the one message to go back to its reply channel and the other to go on to "defaultChannel"? That seems like magic. Where can I find documentation on that?

<channel id="someChannel">
	<dispatcher load-balancer="none"/>
</channel>

<bridge input-channel="someChannel"/>

<bridge input-channel="someChannel" output-channel="defaultChannel"/>