Announcement Announcement Module
Collapse
No announcement yet.
Chain Element Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Chain Element

    Hello,
    I would like to get more information on the Chain Element and its advantages. Currently I have the following code snippet and I was wondering would using the Chain Element bring anything?? Another question is am I allowed to have aggregator also inside the Chain element???Would apprecaite help

    Code:
    <ws:outbound-gateway id="gateway"
    				         request-channel="requestChannel" 
    				         reply-channel="responseChannel"
    				         uri="http://localhost:8080/Spring_WS_GID/"/>
    				         
    <service-activator input-channel="responseChannel" output-channel="checkChangeChannel" ref="changeChecker" method="checkForChanges" />
    <beans:bean id="changeChecker" class="integrationGID.ChangeChecker"/>
    
    
    <service-activator input-channel="checkChangeChannel" output-channel="splitterChannel" ref="convertToDomBean" method="convertToDom" />
    <beans:bean id="convertToDomBean" class="integrationGID.ConvertToDom"/>
    
    <!--  split into one message per division element -->
    <si-xml:xpath-splitter input-channel="splitterChannel" output-channel="filterChannel" id="divisionsSplitter">
        <si-xml:xpath-expression expression="//div:Divisions" ns-prefix="div" ns-uri="http://gid.com/div/schemas"/>
    </si-xml:xpath-splitter>
    	
    <!--  discard any messages representing divisions that have not changed -->
    <filter input-channel="filterChannel" output-channel="aggregatorChannel" ref="hasChangedSelector" id="changedDivisionsFilter" />
    <si-xml:xpath-selector evaluation-result-type="boolean" id="hasChangedSelector">
    	<si-xml:xpath-expression expression= "boolean(boolean(./@Change-Occured='true'))" ns-prefix="div" ns-uri="http://gid.com/div/schemas" />
    </si-xml:xpath-selector>
    
    
    <aggregator input-channel="aggregatorChannel" ref="aggregateBean" method="aggregateChangedDivisions" output-channel="deliveryChannel" reaper-interval="200" send-partial-result-on-timeout="true" timeout="100" tracked-correlation-id-capacity="100" id="changedDivisionsAggregator"/>
    
    <beans:bean id="aggregateBean" class="integrationGID.ChangedDivisionsAggregator"/>
    
    <publish-subscribe-channel id="deliveryChannel"/>
    
    
    <mail:outbound-channel-adapter id="MailOut" host="localhost"  username="root" password="root"/>
    <mail:header-enricher  input-channel="deliveryChannel"  subject="Base System" output-channel="MailOut"
                         to="black@localhost"
                        from="white@localhost" cc="blue@localhost"
                       overwrite="false"/>
    
     <jms:outbound-gateway request-channel="deliveryChannel" connection-factory="connectionFactory" extract-request-payload="true" request-destination="Base"/>
    <beans:bean id="connectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
    <beans:property name="brokerURL" value="tcp://localhost:61616"/>		
    </beans:bean>
    <beans:bean id="Base" class="org.apache.activemq.command.ActiveMQQueue">
    <beans:constructor-arg value="ChangedData" />
    </beans:bean>

  • #2
    It may well improve the readability of the configuration and also allows you to scope channels as being private within a message flow. The chain element represents a straight line message flow so for example transform, split then route can be represented as below.

    Code:
    <transformer input-channel="channelA" output-channel="channelB" ref="transfomerBean" />
    <splitter input-channel="channelB" output-channel="channelC" ref="splitterBean" />
    <router input-channel="channelC" ref="routerBean" />
    However for a flow where each message passes through a number of components in a defined sequence there is a lot of noise there. With a chain it is easier to read and the channels connecting each component in the message flow are implied in the configuration and also therefore effectively private to the chain.

    Code:
    <chain input-channel="channelA">
    	<transformer ref="transfomerBean" />
    	<splitter ref="splitterBean" />
    	<router ref="routerBean" />
    </chain>

    Comment


    • #3
      Thanks Jonas for the response. Can we add aggregator too into the chain Element?

      Comment


      • #4
        No having an aggregator in the chain is not currently supported in the namespace.

        I think however it should be so I will update this thread once I have had time to check out the code to see if there is a problem with adding this in.

        Comment


        • #5
          You can use any MessageHandler in the chain, but if it's not the last element it should be a subtype of AbstractReplyProducingMessageHandler. The fact that <aggregator/> is not supported is something that was overlooked afaik. Please create an issue for that.

          Comment


          • #6
            There lies the problem since AbstractMessageAggregator does not extend AbstractReplyProducingMessageHandler. Instead it extends AbstractMessageBarrierHandler. Therefore something like split,aggregate, route is not currently possible. Although split,aggregate would be if you use the bean namespace.

            Comment


            • #7
              Yes, I don't think there is a problem with allowing barriers in the middle of the chain. In fact, allowing any handler in general would be OK. Question then is if it is going to be unexpected if handlers later in the chain are not invoked.

              Comment


              • #8
                To me the point of the chain is that is to pass a message through a sequential number of processing steps. I think the handlers constituting those steps should be able to behave as normal. The chain currently supports a filter midway through since that does implement AbstractReplyProducingMessageHandler. So we already support the scenario where the message is dropped mid chain.

                I think this restriction mid chain is due to the fact that AbstractReplyProducingMessageHandler defines the setOutputChannel method. However AbstractMessageBarrierHandler also defines such a method so one possibility would be to test for either type mid chain. However I wonder if we need to look for a more generic solution. Should AbstractMessageBarrierHandler extend AbstractReplyProducingMessageHandler since they do produce replies in some situations and replies can be set as optional in classes extending AbstractReplyProducingMessageHandler? Or maybe it does not make sense to view the aggregated message as a reply?

                I have created INT-574

                Comment

                Working...
                X