Results 1 to 7 of 7

Thread: Reuse of a chain of endpoints without writing it again

Hybrid View

  1. #1
    Join Date
    Jun 2010
    Location
    Paris
    Posts
    106

    Question Reuse of a chain of endpoints without writing it again

    Hi,

    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:

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

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

    Code:
    <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. #2
    Join Date
    Jan 2008
    Location
    Mohnton, PA USA (that's near Philadelphia)
    Posts
    2,148

    Default

    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:
    Code:
    <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. #3
    Join Date
    Jun 2010
    Location
    Paris
    Posts
    106

    Default

    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. #4
    Join Date
    Jan 2008
    Location
    Mohnton, PA USA (that's near Philadelphia)
    Posts
    2,148

    Default

    Well, let me try to rephrase what you said:
    The output of the chain process needs to be routed to a specific flow, so...
    Code:
    <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. #5
    Join Date
    Oct 2005
    Location
    Boston, MA
    Posts
    2,840

    Default

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

  6. #6
    Join Date
    Jun 2010
    Location
    Paris
    Posts
    106

    Default

    Hello,

    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.

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

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •