Announcement Announcement Module
Collapse
No announcement yet.
BridgeHandler vs Service Activator Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • BridgeHandler vs Service Activator

    I have one component connected to another via a DirectChannel.

    When the producer component method returns a collection of objects the first time it's invoked Spring Integration correctly invokes the Service Activator method for my consumer component.

    On the second iteration (the components are part of an iterative pipeline), the producer returns data and Spring Integration invokes a Bridge Handler instead of the Service Activator.

    What would cause this to happen? Both times the producer is returning a non-null, non-empty collection of the same object type.

    Any insight/help would be greatly appreciated.

    Thanks,
    Mike

  • #2
    Do you by any chance have a <bridge> with the same reference for its "input-channel" as the <service-activator> has?

    If you can, please provide the relevant excerpt from your configuration.

    Thanks,
    Mark

    Comment


    • #3
      Originally posted by Mark Fisher View Post
      Do you by any chance have a <bridge> with the same reference for its "input-channel" as the <service-activator> has?

      If you can, please provide the relevant excerpt from your configuration.

      Thanks,
      Mark
      Mark,
      I've included part of the configuration below. The QuantitativeJustifier responds to the FuturesGenerator via the FuturesGeneratorResponseChannel.

      Thanks,
      Mike




      <!-- FuturesGeneratorRequestChannel -->
      <si:channel id="FuturesGeneratorRequestChannel">
      </si:channel>

      <!-- FuturesGeneratorResponseChannel -->
      <si:channel id="FuturesGeneratorResponseChannel">
      </si:channel>

      <bean id="FuturesGenerator"
      class="com.ait.dg.sp.futuresgenerator.FuturesGener ator"
      scope="singleton"
      />

      <si:gateway id="IFuturesGenerator"
      service-interface="com.ait.dg.sp.communications.gateway.IF uturesGenerator"
      default-request-channel="FuturesGeneratorRequestChannel"
      default-reply-channel="FuturesGeneratorResponseChannel"
      />

      <si:service-activator input-channel="FuturesGeneratorRequestChannel" ref="FuturesGenerator" method="buildFuturesGraphs"/>
      <si:service-activator input-channel="FuturesGeneratorResponseChannel" output-channel="ParallelStateProductionQueueChannel" ref="FuturesGenerator" method="processData"/>

      <si:service-activator input-channel="QuantitativeJustifierQueueChannel" output-channel="FuturesGeneratorResponseChannel" ref="QuantitativeJustifier" method="processData"/>

      Comment


      • #4
        Mark,
        Sorry I forgot to mention there is no bridge defined.
        Mike

        Comment


        • #5
          Mark,

          I removed the default-reply-channel="FuturesGeneratorResponseChannel" on the IFuturesGenerator and the problem appears to have gone away. Interesting.

          Mike

          Comment


          • #6
            The "default-reply-channel" in a gateway is actually the channel where the *gateway* is expecting to receive results before returning. When there is a default-reply-channel, that means it can be shared - so that the gateway needs to correlate responses (based on MessageID -> CorrelationID). The component that is registered as a subscriber for that shared channel is a "bridge" (it's created automatically).

            On the other hand, when you leave the "default-response-channel" out, it will use an anonymous channel, and that anonymous channel will be set as the replyChannel header of the Message. Whenever the Message reaches an endpoint that has no "output-channel", that header will be used for the reply.

            Does that adequately explain the behavior you are seeing?

            Comment


            • #7
              I think I understand what you're saying. When I create a default-reply-channel a bridge is created to connect my default-reply-channel with the gateway's reply channel?

              A related question: Are there any issue invoking one gateway from another? Do the default-reply-channel for each need to be different?

              Comment


              • #8
                What do you mean by invoking one gateway from another?

                The gateway is a proxy that implements an interface, so usually it's invoked directly from code (where the main point is to hide the messaging API from that calling code).

                If you are wanting to create a "pipeline" that is usually accomplished by connecting output-channels to input-channels (e.g. multiple <service-activator/> elements).

                If you have a different requirement, can you explain it briefly?

                Comment


                • #9
                  I guess the best way to describe what I am doing is looking at the Process Manager pattern: www.eaipatterns.com/ProcessManager.html. Although what I'm doing is not exactly the same.

                  There isn't a trigger message but an API call to the "Process Manager". Currently, this is implemented as a gateway. The "Process Manager' in turn sends a message to the first process (say Proc A) via a second gateway. I did this so I wouldn't have to inject the MessageChannelTemplate leaving both the "Process Manager" and "Proc A" message free. The only other difference (between mine and the Process Manager") is that Proc A communicates with Proc B and Proc B with Proc C over channels (There is no constant feedback to the Process Manager). Proc C then feeds back into the "Process Manager" again. The whole process stops when Proc C produces no output.

                  Does that make sense? Thoughts?

                  Comment


                  • #10
                    Okay. I think I understand the big picture, but can you show code/configuration for what you describe here:
                    The "Process Manager' in turn sends a message to the first process (say Proc A) via a second gateway
                    I'm not quite sure what you mean by having a process send to another gateway. If the first one is a gateway, there is no "implementation"... are you invoking another gateway (via interface) from an Object that is referenced in the <service-activator>?

                    Comment


                    • #11
                      It's exactly as you said. Below the FuturesGenerator is the "Process Manager" while the
                      ParallelStateProducer is "Proc A". The gateway for the ParallelStateProducer is injected/invoked from the FuturesGenerator.

                      <si:channel id="FuturesGeneratorRequestChannel"/>

                      <si:gateway id="IFuturesGenerator"
                      service-interface="com.ait.dg.sp.communications.gateway.IF uturesGenerator"
                      default-request-channel="FuturesGeneratorRequestChannel" />

                      <si:service-activator input-channel="FuturesGeneratorRequestChannel" ref="FuturesGenerator" method="buildFuturesGraphs"/>

                      <bean id="FuturesGenerator"
                      class="com.ait.dg.sp.futuresgenerator.FuturesGener ator"
                      scope="singleton"
                      parallelStateProducer-ref="IParallelStateProducer"/>


                      <si:channel id="ParallelStateProducerResponseChannel"/>

                      <si:gateway id="IParallelStateProducer"
                      service-interface="com.ait.dg.sp.futuresgenerator.parallel state.IParallelStateProducer"
                      default-request-channel="ParallelStateProductionQueueChannel"
                      />

                      <si:service-activator input-channel="ParallelStateProductionQueueChannel" output-channel="TaskGroupProductionQueueChannel" ref="ParallelStateProducer" method="processData"/>
                      <bean id="ParallelStateProducer" class="com.ait.dg.sp.futuresgenerator.parallelstat e.ParallelStateProducer" scope="singleton"/>

                      Comment

                      Working...
                      X