WE have a requirement to publish an event which will be subscribed by multiple subscribers. Each subscriber in turn will return the response for the message.
We are trying to use on-premise windows service bus for this.
This link https://code.msdn.microsoft.com/Brokered-Messaging-Request-0ce8fcaf covers the request and response pattern for queues. But I am looking for request/response pattern from multiple subscribers using Topics.
I could not find any reference on this.
Could you please suggest an approach to implement this.
Related
I am building a system using microservices architecture, using RabbitMQ as the messaging service.
I have a use cases of communication between 2 services and face the difficulties of using RabbitMQ to implement it.
Cart-Service needs to get data from Product-Service. In this case Cart-Service can send a message, Product-Service subscribes to that message. But I find no way for Product-Service to send back the data to Cart-Service.
May you let me know whether my approach of using RabbitMQ in this case is correct?
Any other approach I should apply in this use case?
Thank you in advance.
Use an event-driven naming convention for your rabbitMQ message routes. The format can be <service>.<entity>.<action>, e.g. "cart.item.added".
Cart service subscribes to product.*.* messages, Product service - to the cart.*.* ones.
The workflow might be the following:
cart: publishes "cart.item.added" message.
product: receives "cart.item.added" message, publishes "product.product.read" one
cart: receives "product.product.read" message with the product info.
If you're using Node.js for the microservices, you could read more on how to prototype RabbitMQ message exchange here:
https://medium.com/#krawa76/bootstrap-node-js-microservice-stack-4a348db38e51
I was just reading about Enterprise Service Bus and trying to figure out how to implement it. However, the more I read about it, my conclusion was that it is just a glorified message queue.
I read about it here: What is an ESB and what is it good for?
We use RabbitMQ in our architecture quite a lot and what I was having hard time understanding was that there any many similarities between both concepts:
Both are basically post and forget
You can post a message of any format in both queues
My question is that what is it that an ESB does and RabbitMQ is not able to do?
I have not used RabbitMQ so I wont be able to comment on it. I have used ESB and currently using it.
ESB: It provides you multiple ways of subscribing to your message.Its mostly useful in Publisher-Subscriber model in which topics and subscription is used. You can publish your message payload in topics(similar to queues). Unlike a queue,topic provides us with capability to have more than one subscription for a single topic. This subscription can be divided based on your business need and you can define some kind of filter expression on those topic (also called channel)and with the specified filter a proper subscriber will pull the message from bus. Also one single message can be subscribed by multiple subscriber at a time. If no filtering is used on topics then it means all subscriber for that topic will pull the message from the channel.
This is asynchronous mechanism as you mentioned, post and forget. There is a retry mechanism in ESB where you can try subscribing the message for some number of times I think its 10 times(max) after which its sent in dead queue.
So if your requirement is to connect multiple enterprise system with loosely couple architecture then ESB is a good option.
I hope this was helpful to know about ESB
I'm building a basic event based message system for a couple of services.
For my user service, I'm going to use a user topic exchange which will have routing keys like user.event.created, user.event.updated and user.event.deleted.
My logs service will consume user.event.* keys so I can log all events, whereas my email service will only listen for user.event.created as I'll only send out email on creation.
Now say I created a posts service, I want the logs service to consume events from here as well. Is it ok for me to bind both exchanges to the single logs.process queue?
Is there a better way of achieving this?
As long as each of the consume threads has it's own connection, it's fine. So, one thread consumes from topic exchange, the other from direct one etc.
As for the better part, I don't know - would require some more details.
My team are looking for ways to separate the various components of our system to decoupled services. What we'd like to achieve is an event-driven pattern where services subscribe to receive information sent when events occur in other systems.
Since we're already using WCF for our request-reply messaging, we'd like to continue using it for this particular pattern. Ideally, the messages would be managed via MSMQ to enable us to use reliable messaging to give us fault tolerance in the event of a service failure.
We're not looking for anything complicated like transactional support across service boundaries. Really, we just need a simple subscription-based message dispatch system. Are there any simple frameworks or services which can help us work to this pattern?
Probably the easiest is NServiceBus (http://www.nservicebus.com/PubSub.aspx) but this does not use WCF.
However from a integration perspective sending and receiving messages is far simpler than the messaging semantics on web services, so you don't need WCF to abstract that away.
Edit: In order to enable this using NetMsmqBinding you will have to implement the subscription infrastructure yourself. It would also be fairly easy to do.
Your publisher would need to have a database to store the subscriptions. When your subscribers start up, the first thing they do is send a subscription message to the publisher, who logs the subscription in it's subscription db.
The subscription messages should contain:
The message types I am interested in
My queue address
Then when your publisher wants to publish a message it retrieves the subscriptions and evaluates each one to see if the message matches the subscription and to retrieve the address to send to. Then it just sends the messages.
This is a standard pattern for implementing pub sub.
I need to build a system that uses a Publish/Subscribe bus (e.g. Mule, ZeroMQ, RabbitMQ), but the literature all implies that subscriber applications are reliably available to receive messages from topics to which they subscribe as soon as the Pub/Sub bus is able to deliver the message.
I have a system where some of the applications will be reliably connected to the Publish/Subscribe bus, but other applications will not be active or connected to the bus all the time.
The obvious solution is to have some sort of "presence" protocol between the unreliable application and the Publish/Subscribe bus so that "present" applications get their messages delivered immediately, and "not present" applications have their messages queued up in a persistent buffer of some kind, and as soon as they complete the "presence handshake", the queued messages are delivered to the newly present application.
Are there any Publish/Subscribe buses which have this kind of feature built in, or are there any open-source add-ons which do this? Can you point me to any URLs which describe this?
You can achieve this behaviour quite easily with any AMQP-compliant broker (such as RabbitMQ).
Choose the correct exchange type for your usage model. You'll want to use a direct exchange if you're always sending to absolutely named destinations, something like chat.messages.
If you want to do pattern-based routing, you'll want to use topic exchange. Then you can route based on patterns such a chat.messages.*.
Routing is described in more detail in the RabbitMQ Tutorials.
To create the kind of persistent subscription that you mention, have each subscriber create a queue that is private to that subscriber. The queue is then bound to the relevant routing keys on your chosen exchange.
Since each subscriber has its own queue, messages will be consumed by the subscriber when active and stored when subscriber is inactive or disconnected.
You haven't mentioned your language of choice, but in Java you can accomplish this with JMS using durable subscribers. Any implementation of JMS (there are many, including the aforementioned RabbitMQ) will support this feature.