Messaging through a service bus in .NET using MassTransit part 8: observing events in the bus

October 6, 2016 Leave a comment

Introduction

In the previous post we learned how to intercept messages in MassTransit. We can intercept messages using various observer interfaces when sending, publishing, receiving and consuming messages. We cannot modify the message content so they are read-only operations. The implemented interfaces need to be registered with the bus so that we can do any extra work on the messages such as logging or debugging.

In this post we’ll see how to register events that happen in the bus.

Read more of this post

Advertisements

Filed under .NET, Messaging Tagged with , , ,

Messaging through a service bus in .NET using MassTransit part 7: intercepting messages

October 4, 2016 5 Comments

Introduction

In the previous post we investigated how types are handled by MassTransit and how they are represented in RabbitMq exchanges and queues. With MassTransit we can send and receive concrete objects and it will take care of creating the necessary queues and exchanges for us. The objects are serialised and deserialised without us having to worry about JSON or XML strings.

In this post we’ll see how to intercept messages both in the publisher and receiver.

Read more of this post

Filed under .NET, Messaging Tagged with , , ,

Messaging through a service bus in .NET using MassTransit part 6: message types and inheritance support

September 29, 2016 1 Comment

Introduction

In the previous post we went through how exceptions are handled in MassTransit. By default the only mechanism is that if a registered consumer throws an exception while processing a message then that message ends up in an error queue. The error queue is named after the queue name where the consumer is listening with “_error” attached to it. By default MassTransit won’t try to relay the message again. However, it’s simple to add various retry policies with the UseRetry extension method. We can configure a wide range of retry policies: incremental, exponential, exception-based ones and other types. In addition MassTransit publishes a Fault message if all retries have been exhausted without success. The fault address or response address can specify a different queue where the fault message will be delivered. A different consumer can then monitor the fault queue and do something meaningful with the fault message.

In this post we’ll look at how message type inheritance is supported in MassTransit.

Read more of this post

Filed under .NET, Messaging Tagged with , , ,

Messaging through a service bus in .NET using MassTransit part 5: failures

September 28, 2016 Leave a comment

Introduction

In the previous post we explored how to inject a dependency into the registered consumer class in MassTransit. Consumer classes will often have at least some sort of dependency such as a repository interface or another abstraction to propagate the changes made. Good software engineering dictates that a class should indicate what dependencies it needs through e.g. its constructor. This is the contrary of control-freak objects that construct all their dependencies hidden in their implementations.

In this post we’ll take a look at various failure handling options in MassTransit.

Read more of this post

Filed under .NET, Messaging Tagged with , , ,

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

September 22, 2016 Leave a comment

Introduction

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

Filed under .NET, Messaging Tagged with , , ,

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

September 20, 2016 3 Comments

Introduction

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

Filed under .NET, Messaging Tagged with , , ,

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

September 14, 2016 1 Comment

Introduction

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

Filed under .NET, Messaging Tagged with , , ,

← Older posts

ultimatemindsettoday

A great WordPress.com site

Elliot Balynn's Blog

A directory of wonderful thoughts

Robin Sedlaczek's Blog

One more Nerd

HarsH ReaLiTy

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 BEST PRACTICES WITH MICROSOFT STACK & ANGULAR

Cyber Matters

Bite-size insight on Cyber Security for the not too technical.

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: