You may wish to distribute some of your routing, mediation, or service logic across multiple hosts, you may wish to add some reliability to the messages transmitted through your SI channels, and you may wish to scale out your services more than you could with a traditional client-server architecture. Well, one way to achieve some of the goals mentioned above is to use a message broker to back your SI routes. SI provides abstractions for both AMQP brokers and JMS brokers. In this post, I’d like to use the Cafe sample from the Spring Integration Samples project to illustrate how to use the popular ActiveMQ message broker to back your SI routes with JMS.
- message reliability – the message broker stores and forwards messages. messages will be delivered at most one time. if the broker goes down, previously undelivered messages will persist and can be resent if the consumers didn’t get them
- flexibility – with the components decoupled and relying on EIP, you can maintain each one independently of each other, including deployment, enhancements, etc
- throttle or increase message processing – with components running in their own/separate processes or boxes or parts of the world, you can configure each component to consume or throttle messages depending on how much the environment can handle
- scaling – to handle a higher throughput, just add more instances of a component to listen on a JMS destination
- complexity – maintaining multiple components is more complicated that packing things into one process
- debugging – along with increased complexity comes difficulty debugging. async processes are inherently difficult to debug