Announcement Announcement Module
Collapse
No announcement yet.
another use case for a schedule period Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • another use case for a schedule period

    As far as I understand in Spring integration the schedule period does for:
    - a Channel Adapter polls from an endpoint (MessageSource) and pulls the messages to the channel
    - a Channel Adapter polls from a channel and pulls the messages to an endpoint (MessageTarget)

    The latter is equivalent to the Service Activator (polls from the input channel) and GatewayProxyFactoryBean (polls from the request channel).

    In my case I have implemented my own RMI endpoint. The configuration looks as followed:

    Code:
    	<service-activator input-channel="requestChannel"
    		output-channel="replyChannel" ref="rmiEndpoint"
    		method="doIntegrationService">
    	</service-activator>
    
    	<beans:bean id="rmiEndpoint"
    		class="com.qnamic.plancom.eip.endpoint.RemotePlanOptAgentEndpoint">
    		<beans:property name="agentId" value="railroad.agent.name" />
    	</beans:bean>
    Here messages from the request channel are send to the RMIEndpoint. There is no need for the Service Activator to poll from the request channel. Responses from the endpoint are send to the reply channel.

    Since I do not know whether the remote object is already registered to the RMI registry I would like to push/resend messages under these conditions:

    - schedule period: the time (e.g. after 1000millis) when to call the endpoint again after a failure
    - timeout: the time (e.g. after 5000 millis) when to stop calling the endpoint after a failure

    NOW THE QUESTION:
    How should I implement this? I took a brief look at the M5 sources and wonder whether I can use the PollingDispatcher and Schedule for my endpoint?!

    The idea of re-calling the endpoint allows the two parties (producer/consumer) not to direclty rely on each other and let the messaging system take care of this. Isn't that one of the biggest advantage of a loosely coupled system as mentioned in EIP?

    Thanks,
    Tai

  • #2
    Tai,

    Can you explain what you mean by this?: "There is no need for the Service Activator to poll from the request channel."

    Thanks,
    Mark

    Comment


    • #3
      Hi Mark,

      Counter question: The message is pushed (from the channel) to the Service Activator when it is send to the request channel, isn't it?

      In this case I have another endpoint sending its message to the request channel and passed to the Service Activator.

      Tai

      Comment


      • #4
        A schedule for Web Services

        Since integration always relies on many 3rd party systems it may occur that one or another party is currently offline. In this case it would be good to have a defined schedule to re-send messages.
        Isn't that use case most likely (e.g. RMI, JMS and Web Services Calls) ?

        Comment

        Working...
        X