Announcement Announcement Module
No announcement yet.
Reuse of a chain of endpoints without writing it again Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Reuse of a chain of endpoints without writing it again


    Is there a way to "factorize" a <chain> so it can be reused at different other places with different input and output channels?

    For example, at different places in my configuration files, I need to do the following:

    <chain id="commonChain">
    	<header-enricher> ... </header-enricher>
    	<service-activator> ... </service-activator>
    	<gateway> ... </gateway>
    but for different input and output channels.

    It would be nice if it was possible to only write something like :

    <chain ref="commonChain" input-channel="channelX" output-channel="channelY" />
    anytime I need to do the same chain of endpoints.

    Is there currently such a feature I wouldn't be aware of? If not, would it make sense to implement something like that?

    Thank you!

    -- Pierre

  • #2
    Interesting, but what about this:
    Channel is just a connector between to endpoints, regardless what they are.
    So i can essentially assemble different flows, but once they all need to go through the same chain, send them to the same channel, essentially accomplishing everything you need.
    Also, you can bridge channels to connect two unrelated flows to the same chain:
    <service-activator .. output-channel="A"/>
    <service-activator .. output-channel="B"/>
    <bridge input-channel="A" output-channel="C"/>
    <bridge input-channel="B" output-channel="C"/>
    <chain input-channel="C".../>


    • #3
      I agree for the input, but what about the output of the chain? In your solution, I would need a dispatcher to redirect the output to the correct channel: this is too complicated.


      • #4
        Well, let me try to rephrase what you said:
        The output of the chain process needs to be routed to a specific flow, so...
        <service-activator .. output-channel="A"/>
        <service-activator .. output-channel="B"/>
        <bridge input-channel="A" output-channel="C"/>
        <bridge input-channel="B" output-channel="C"/>
        <chain input-channel="C" output-channel="D"/>
        <router input-channel="D" expression="" />
        Obviously you can use SpEL expression if routing logic is simple or create a router bean and refer to it via 'ref' attribute.

        What you are suggesting is certainly been discussed several times internally, but i guess we have not seen yet a solid use case with a convincing argument that that would be a better solution. . . but as I said its not totally out of the question. In fact i would suggest open a new JIRA as 'feature request" and we'll see how it goes.


        • #5
          Also, if the original messages have a "replyChannel" header, then you can leave out the output-channel altogether. Is that an option?


          • #6

            Thank you for your replies and suggestions.

            The router is not an option: the chain is supposed to be generic and could be defined in an XML configuration file stored in a common jar shared by different flows. The router wouldn't be able to know the different flows that call him.

            Setting the replyChannel header could work but with some drawbacks:
            • We can't be sure that the chain won't need to override the replyChannel header for some similar reason too.
            • The XML would be less readable: if the <chain> is defined in a different XML configuration file, an external reader wouldn't understand easily how the flow goes; he would have to follow the channels from one file to another.
            • The chain couldn't be called from another chain (as the input- and output-channels are not explicitely defined within a chain).

            I'll open a JIRA for the syntax I suggested as it looks to me the more elegant and more readable way to reuse a chain.

            If you have other ideas about the subject, I'll be very interested to discuss it.

            Last edited by plecesne; Aug 6th, 2010, 03:55 AM.


            • #7
              JIRA - Feature request :