Create new message chain out of existing channels

Stempler :

I wish to create a message chain out of existing channels, without specifically write all the elements again.

Currently I have several long chains that overlaps one another with certain elements. Every time I add a new element, I have to add it in several chains. I wish to create a chain of channels, that can be called as a sequence.

To simplify, my applicationContext at the moment has 3 channels. channel 1 and channel 2, and channel 3 that consist of the two:

<int:chain input-channel="channel-1">
    <int:service-activator ref="serviceA" method="doService" />
    <int:service-activator ref="serviceB" method="doService" />
    <int:service-activator ref="serviceC" method="doService" />
</int:chain>

<int:chain input-channel="channel-2">
    <int:service-activator ref="serviceD" method="doService" />
    <int:service-activator ref="serviceE" method="doService" />
    <int:service-activator ref="serviceF" method="doService" />
</int:chain>

<int:chain input-channel="channel-3">
    <int:service-activator ref="serviceA" method="doService" />
    <int:service-activator ref="serviceB" method="doService" />
    <int:service-activator ref="serviceC" method="doService" />
    <int:service-activator ref="serviceD" method="doService" />
    <int:service-activator ref="serviceE" method="doService" />
    <int:service-activator ref="serviceF" method="doService" />
</int:chain>

What I looking for is a simple solution that will enable me to do something like

<int:chain input-channel="channel-3">
    <??? channel-1 />
    <??? channel-2 />
</int:chain>

Is there some simple way to do that?

Oleg Zhurakousky :

I think you've miss-interpreted the concepts of chain and channel.

1. The channel is at the core of pipes-and-filters as it is a pipe, so weather you use chain or not you still use channel. What chain allows you to do is to simplify the definition of the flow by letting you define a list of filter elements. Those elements are still connected with anonymous channels.

2. The explicit channels (e.g., <int:channel...>) are there specifically to be referenced, allowing several flows to intwine with one another by sending and or receiving messages to/from such channels.

So, hopefully you can see that creating chains from channels kind of goes against both pipes-and-filters architecture and the design of the framework which we tried to keep very consistent. In other words what I am reading from your post is that you have some flows that may be producers and/or consumers of other flows (wholly or partially) and if that's the case just use explicit channels.

Here is the simplified version of your flow:

<int:chain input-channel="channel-1" output-channel="channel-1out">
    <int:service-activator ref="serviceA" method="doService" />
    <int:service-activator ref="serviceB" method="doService" />
    <int:service-activator ref="serviceC" method="doService" />
</int:chain>

<int:chain input-channel="channel-2">
    <int:service-activator ref="serviceD" method="doService" />
    <int:service-activator ref="serviceE" method="doService" />
    <int:service-activator ref="serviceF" method="doService" />
</int:chain>

<int:bridge input-channel="channel-1out" output-channel="channel-2"