Messaging with RabbitMQ and .NET review part 11: various other topics

Introduction

In the previous post we looked at the scatter/gather message exchange pattern. It is similar to RPC in that the sender will be expecting a response from the receiver. The main difference is that in this scenario the sender can collect a range of responses from various receivers. The sender will set up a temporary response queue where the receivers can send their responses. This MEP is suitable for scenarios that require 2 way communication with more than a single consumer. An example would be a system where we’re sending out a notice to some selected construction companies asking for a price offer. The companies then can respond using the message broker and the temporary response queue.

In this post, which will also finish the series, we’ll look at various smaller topics around the RabbitMq client.

Read more of this post

Advertisements

Messaging with RabbitMQ and .NET review part 10: scatter/gather

Introduction

In the previous post we looked at message filtering using message headers in RabbitMq. The Headers exchange pattern is very similar to Topics we saw in this post. The sender sends a message of type Headers to RabbitMq. The message is routed based on the header values. All queues with a matching key will receive the message. We can specify more than one header and a rule that says if all headers or just one of them must match. The headers come in key-value pairs such as “category:vehicle”, “type:car”. Headers allow us to fine-tune our routing rules to a great extent.

In this post we’ll look at one more message exchange pattern called scatter/gather. It is similar to two-way messaging but the publisher will get the responses from multiple consumers.

Read more of this post

Messaging with RabbitMQ and .NET review part 9: headers

Introduction

In the previous post we looked at two ways to filter messages from an exchange to one or more queues bound to it. Routing keys provide a simple mechanism where the routing key of the message, such as “asia” is forwarded to all queues that also have a routing key “asia”. In other words the filtering is based on a direct string comparison. The Topic message exchange pattern is a more sophisticated variant where the ‘*’ and ‘#’ placeholders let you fine-tune the binding rule between an exchange and a queue. We can also bind multiple queues to the same exchange with varying routing keys.

In this post we’ll look at one more message filtering technique called headers which is in fact very similar to the topic MEP. The headers MEP offers a very fine-grained way to set up the binding rules between the exchange and the queue(s).

Read more of this post

Messaging with RabbitMQ and .NET review part 8: routing and topics

Introduction

In the previous post we looked at two-way messaging in RabbitMq. This messaging type corresponds to the Remote Procedure Call (RPC) messaging pattern. RPC is slightly different from the previous MEPs in that there’s a response queue involved. The sender sends an initial message to a destination queue via the default exchange. The message properties include a temporary queue where the consumer can reply. The receiver processes the message and responds using the response queue extracted from the message properties. The sender then processes the response. We managed to set up a rudimentary chat application in our demo project at the end of the post.

In this post we’ll concentrate on two message filtering techniques: routing keys and topics. The two are quite similar so a single post is enough to handle them both.

Read more of this post

Messaging with RabbitMQ and .NET review part 7: two way messaging

Introduction

In the previous post we looked at the fanout exchange type. This exchange type corresponds to the publish-subscribe message exchange pattern. This MEP is very similar to one-way messaging. The major difference is that there can be multiple queues bound to an exchange. The incoming messages are forwarded to every queue where each queue is monitored by a listener. This exchange type is suitable for cases where you know that there will be multiple listeners.

So far we’ve looked at patterns where the publisher sent a message to a queue and didn’t care about any response back from the consumer. In this post we’ll see how to set up two-way messaging where a publisher receives a response from the consumer.

Read more of this post

Messaging with RabbitMQ and .NET review part 6: the fanout exchange type

Introduction

In the previous post we looked at an alternative way to consume messages from a queue in RabbitMq. In particular we discussed the usage of the EventingBasicConsumer which is an event and delegate based alternative to the DefaultBasicConsumer class. The outcome is the same in both cases, i.e. the consumer monitors the assigned queue and pulls messages from it.

In this post we’ll discuss how to work with the fanout exchange type.

Read more of this post

Messaging with RabbitMQ and .NET review part 5: one way messaging with an event based consumer

Introduction

In the previous post we saw how to process messages from a queue using a receiver we derived from a default basic consumer. We implemented the HandleBasicDeliver function for that purpose. We also discussed two message exchange patterns (MEPs), one-way and and worker queues. The two are practically identical in code but the worker queues MEP implies that we have 2 or more consumers competing for the messages from the queue. That way we can spread out the message load across multiple consumer instances.

In this short post we’ll look at an alternative way to consume messages from a queue in code.

Read more of this post

ultimatemindsettoday

A great WordPress.com site

Elliot Balynn's Blog

A directory of wonderful thoughts

Softwarearchitektur in der Praxis

Wissenswertes zu Webentwicklung, Domain-Driven Design und Microservices

Technology Talks

on Microsoft technologies, Web, Android and others

Software Engineering

Web development

Disparate Opinions

Various tidbits

chsakell's Blog

WEB APPLICATION DEVELOPMENT TUTORIALS WITH OPEN-SOURCE PROJECTS

Guru N Guns's

OneSolution To dOTnET.

Johnny Zraiby

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

%d bloggers like this: