Messaging through a service bus in .NET using MassTransit part 4: dependency injection with StructureMap


In the previous post we saw how to publish messages with MassTransit. Our demo register customer command listener publishes a customer registered event that any interested party can sign up to. An advantage with the setup is that the publisher has no knowledge of the consumers, they are completely decoupled. The opposite and more frequent case is often a manager application that knows exactly which parties should be notified and sends them a message directly.

In this post we’ll diverge a little from messaging techniques and look at dependency injection instead. We’re inte particular interested in how to inject a dependency into a registered command or event consumer.

Read more of this post

Messaging through a service bus in .NET using MassTransit part 3: publishing messages to multiple consumers


In the previous post we got our hands dirty and started coding a small demo application around MassTransit. We managed to send a message from a publisher to a consumer using the MassTransit/RabbitMq client library. We saw a very basic configuration of the bus control and how to register a consumer for a message type. The message type can by convention be an event or a command. Both are best encapsulated in an interface with get-set properties and separate naming conventions. Therefore commands and events are not some special C# language features in this case. Instead, they are basic terminology in the world of messaging. Our first example centred around sending a single command using a single queue.

In this post we’ll extend our demo to publishing a message that can be consumed by multiple receivers. The goal is to publish a customer registered event from the register customer command consumer. The event will be consumed by 2 receivers that the event publisher will not have any knowledge of.

Read more of this post

Messaging through a service bus in .NET using MassTransit part 2: starting with some code


In the previous post we presented the topic of this series: using the MassTransit service bus implementation in .NET. We also discussed service buses in general, what they are, what they do and how they can help the developer concentrate on the “important” stuff in a project based around messaging instead of spending time on low-level messaging operations. This is not to say that a service bus is a must for a distributed system to work properly. The system may as well work with RabbitMq only without an extra level of abstraction on top of it. Therefore you must be careful with your design choices. This is especially true of full-blown ESBs – enterprise service buses – that cost a lot of money and introduce a high level of complexity in a distributed architecture.

In this post we’ll start writing code and send an object over the wire using MassTransit.

Read more of this post

Messaging through a service bus in .NET using MassTransit part 1: foundations


In the previous post we completed our updated series of using RabbitMq in .NET. We looked at a couple of miscellaneous topics such as getting a confirmation from RabbitMq whether a messages was actually queued or how a consumer can “not-acknowledge” a message. We also went through some other concepts like data serialisation where a link was provided to the relevant posts in the original series.

This post will start a new series but the topic will be very similar. We’ll stay in the world of messaging. In fact we’ll be building upon the previous series and take a step upwards in the abstraction ladder. We’ll be looking at the basics of using a service bus in .NET using the open-source MassTransit project.

Read more of this post

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


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

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


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


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


A great site

Elliot Balynn's Blog

A directory of wonderful thoughts

HarsH ReaLiTy

A Good Blog is Hard to Find

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


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: