Open aemruli opened 10 years ago
@aemruli the bus uses a topic, so it would need to be a combination of SNS and SQS.
@spencergibb Yes you are right. In this case an application would publish notification to a topic. Every application would create an subscription that receives the notification in a SQS queue. I will investigate how to make the subscription process fully automated when an app comes online (which should be easy)
@aemruli It is not difficult, I've had some experience with it.
:+1:
@aemruli @spencergibb What's the status of spring cloud bus support for sqs? I'd much rather let AWS handle the messaging service rather than me maintaining a RabbitMQ server.
Now that spring-cloud-bus
builds on spring-cloud-stream
, this would require a Binder
implementation for SQS/SNS. Of course that would mean it would be generally useful for a wide range of spring-cloud-stream
use-cases. Within the next day or two, some significant simplifications will be merged for the Binder
interface and the current Binder
implementations (Kafka, RabbitMQ, and Redis). The nice thing is this notion of a producer interacting with SNS and a consumer interacting with SQS maps to the new model quite well. For more context, see the PR here: https://github.com/spring-cloud/spring-cloud-stream/pull/276
I wonder if Spring Integration AWS SQS/SNS adapters fit the Binder
requirements: https://github.com/spring-projects/spring-integration-aws and we should release finally M1 for spring-cloud-stream
:smile:
Definitely the SI adapters should be used by the Binder
. This doc seems to provide quite a bit of info for the SNS-->SQS connection.
Any updates on this request?
Spring Bus might get a backend that leverages SQS for internal communication