Announcement Announcement Module
No announcement yet.
Loose coupling of producer / consumer Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Loose coupling of producer / consumer

    I was wondering if there is a standard way to implement a loose coupling between two channels.

    All xml configuration currently seems to require that you declare message input and/or output. Or it creates a direct channel.

    I'm trying to design something a less coupled together. Channel A receives or produces a message, transforms it, etc..,
    then passes it off to ?something-spring-integration? where channel b is able to pick it up and do its thing. All without actually declaring the a->b flow in xml.

    [channel a]* >>?>> [channel b]

    In my case this would be useful where channel-a's could be spun up at runtime due to some user input. There could be multiple channel-a's as well.

    I can imagine doing this with some service activators and java code between a and b. But was wondering what the best-practices approach is.
    Last edited by absurd; May 20th, 2013, 10:10 AM.

  • #2

    At aglance looks like you are looking for that what Spring XD will provide:

    However if you provide a bit more info, maybe we can say something else.
    Maybe is it enough for you to use File Exchange, Shared DB, or some MQ?..



    • #3
      Hi there,

      Thanks you for your repy.

      So it does sounds like I need some kind of data-store between prodcuing-channel-A and consuming-channel-B, that was my initial thought after reading the Refernce, but I thought I'd ask anyways.

      I dont have much in terms of specifics yet, as Im currently in the process of drawing box diagrams, and selecting technologies.

      But at high level channel-A will be polling for an image from a feed configured by a user. There could be multiple feed sources, so multiple channel-A's.

      Channel -B in my case will be the internal system transform channel, it will be responsible for resizing the image(s), storing a copy as well as meta data in a persistent store. etc...

      I was also hoping that this decoupling of A & B would give a me a well defined horizontal scaling point. Where channel A on one node, or even multiple nodes will push image messages into a distributed queue (Redis queue perhaps?), while channel B on a completely different node (or multiple nodes) would end up consuming from the queue.

      Any thoughts? Whats a good solution here for holding messaging between A & B?

              CHANNEL    CHANNEL
                 A          A
                 |          |
                 |          |
                 v          v
       ?disitributed queue/big data/redis/XD?
                 |          |
                 |          |
                 v          v
                   CHANNEL B
      I read up on XD in your links, but wasnt sure what advantage it gives over a straight data solution, such Terracotta for example. I did like the concept of sinks and taps though, I think they illustrate what Im looking for here. Basicaly I need a sink for channel A, which can have a tap for channel B
      Last edited by absurd; May 21st, 2013, 12:29 PM.


      • #4
        Whats a good solution here for holding messaging between A & B?
        I'm using RabbitMQ as a middleware and AMQP-adapters to access it from my aaplications.


        • #5
          Great, spasibo/thanks for your advice, RabbitMQ seems like precisely the solution I was looking for here.

          Kills two birds with one stone for me, allows A/B decoupling, and an out-of-the box scalability cross cut. Given that I can abstract rabbit behind AMPQ, I'm not even locked in to that solution if I ever want to change vendors, although given rabbit's clustering, mirrored queues, etc can't imagine I'd ever need to.

          [channelA] -----> (AMPQ / RabbitMQ) -----> [channelB]