Results 1 to 5 of 5

Thread: Duplicator Element

  1. #1
    Join Date
    Jan 2011
    Posts
    6

    Default Duplicator Element

    How do I duplicate I message using an xml schema element.

    For example I have an output from an aggregator that gets passed to an outbound service.

    The outbound service does some processing and eventually outputs to a channel . That's fine. Now I want to poll that channel in three places. I meant by poll is duplicate the final message. Maybe one for logging, another one for a custom service, another for another custom service.

    I was expecting there's an element like <duplicator receive-from-channel="...."/>

    Then I have three end receivers that will receive from duplicator
    <receiver1 receive-from="duplicator" />
    <receiver2 receive-from="duplicator" />
    <receiver3 receive-from="duplicator" />

    We have a splitter, aggreggator. Shouldn't we have a duplicator?

    I wanna do it via the xml way

  2. #2
    Join Date
    Jan 2008
    Location
    Mohnton, PA USA (that's near Philadelphia)
    Posts
    2,148

    Default

    Spring Integration messages are immutable by definition, which means that every endpoint (splitter, aggregator etc.) receives a new instance of the Message.
    Read more here: http://static.springsource.org/sprin...essage-builder

    So essentially you don't need to do anything with regard to duplication. Is that what you were looking for?

  3. #3
    Join Date
    Mar 2006
    Posts
    312

    Default

    It almost sounds as if you're simply unfamiliar with PublishSubscribeChannel?

  4. #4
    Join Date
    Jan 2011
    Posts
    6

    Default

    Thanks for the replies.

    I believe the PublishSubscribeChannel seems to be the closer solution I was looking for I guess I was thinking differently. The only issue here is I need to implement a MessageHandler

    With the ordinary channel, I just create a POJO with no dependencies or interfaces needed.

    Why can't we have a channel that duplicates messages but without the need for a publish-subscribe channel? Or maybe not a channel...another element that duplicates messages declaratively?

    I understand that messages are immutable. But I was looking for something in between a default channel and pub-sub channel. I just want a simple duplicator

  5. #5
    Join Date
    Jan 2008
    Location
    Mohnton, PA USA (that's near Philadelphia)
    Posts
    2,148

    Default

    I am not sure what do you mean. The whole point of the channel abstraction is to manage HOW two+ endpoints talk to each other which means if A wants to talk to B and only B, then you POJOs representing A and B are connected with DirectChannel (as below)
    Code:
    <int:service-activator input-channel="inChannel" output-channel="someChannel">
         <bean class="foo.bar.Bar"/>
    </int:service-activator>
    
    <int:channel id="someChannel"/>
    
    <int:service-activator input-channel="someChannel" output-channel="someOtherChannel">
         <bean class="foo.bar.Baz"/>
    </int:service-activator>
    However if more then one endpoint is interested in what A has to say, then you simply switch from DirectChannel to PubSubChannel
    Code:
    <int:service-activator input-channel="inChannel" output-channel="someChannel">
         <bean class="foo.bar.Bar"/>
    </int:service-activator>
    
    <int:publish-subscribe-channel id="someChannel"/>
    
    <int:service-activator input-channel="someChannel" output-channel="someOtherChannel">
         <bean class="foo.bar.Baz"/>
    </int:service-activator>
    
    <int:service-activator input-channel="someChannel" output-channel="someOtherChannel">
         <bean class="foo.bar.Bazzzz"/>
    </int:service-activator>
    I am not sure what would duplicator do different?

    Also, i would suggest to read up on Enterprise Integration Patterns http://www.eaipatterns.com/. This is where all these patterns come from

Posting Permissions

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