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

  • async callback routing

    I have an existing spring service which performs some internal setup, returns an acknowledgement and then (asyc) calls out to an external system. This system will then periodically call back with information.

    The current service is wired using persistent JMS to hand back to a webservice gateway. I wish to decouple this to allow other internal services to also call my existing service. I think that spring integration looks a very good candidate to help me.

    My question is - how best to configure my channels so that I can route back to the appropriate client service (either to a web gateway or to my internal service).

    I can see that we could provide some channel information in a header and use a header based router - but this information would need to be persisted to survive recovery, and this would seem to make the spring service aware of the integration pipes?

    Thanks for any assistance.

  • #2
    Whenever using a Gateway (or even using a MessagingTemplate directly) you can have request/reply behavior based on the addition of an anonymous (exclusive, temporary) MessageChannel that is added to the "replyChannel" header on the request Message. That corresponds to the "Return Address" Enterprise Integration Pattern. Generally, what this means, is that you can leave out reply-channel from any upstream gateway, and the anonymous one will be used as the default. For the "internal services" calling this, that sounds like a candidate for our <gateway> element (which generates a Proxy for a given interface to keep your code decoupled from any of the messaging API).

    Please let me know if I can clarify this in any way.
    -Mark

    Comment


    • #3
      thanks for the reply. If you could clarify a couple of points:

      1. Would this "reply channel" also be suitable for multiple callbacks? The initial call results in a response (basically success or failure to set up the request) immediately - but then multiple callbacks may be made.

      2. How does this work in a clustered environment - we have multiple instances of our application, any one may receive the callback from the external system. As the request is persisted any of the nodes can currently process. Presumably this would be a case for a well named reply channel?

      3. If the callback needs to be handled by a different service, other than the one which initially submitted the request - how would this best be handled.

      Thanks for your prompt assistance

      Comment

      Working...
      X