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

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

Advertisements

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

Introduction

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 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

Messaging with RabbitMQ and .NET review part 4: one way messaging with a basic consumer

Introduction

In the previous post we looked at the RabbitMq .NET client. The client is a library that can be downloaded from NuGet and which allows us to work with RabbitMq messages in our .NET projects in an object-oriented way. In particular we saw how to create an exchange, a queue and a binding in code. We also successfully sent a message to the queue we created in a simple .NET console application. We also discussed the notion of durability whereby we can make all resources in RabbitMq fault tolerant so that they survive a server restart.

In this post we’ll see how to consume one-way direct messages in code.

Read more of this post

Messaging with RabbitMQ and .NET review part 3: the .NET client and some initial code

Introduction

In the previous post we installed the RabbitMq service on Windows. I think you’ll agree that it wasn’t a very complicated process. We then logged into the management GUI using the default “guest” administrator user. We finally looked at how to create users and virtual hosts. We said that a virtual host was a container or namespace to delimit groups of resources within RabbitMq, such as “sales” or “accounting”. We also created a new user called “accountant”.

In this post we’ll start working with RabbitMq in Visual Studio. We’ll in particular start exploring the RabbitMq .NET client library.

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: