RCommon
HomeGitHub
  • Introduction
  • Common Scenarios
  • Getting Started
    • Running Examples
    • Roadmap
    • Releases
      • 1.0.1.75
      • 1.0.2.0
      • 2.0.0
      • 2.1.0
  • Topics
    • Fundamentals
      • Configuration
      • Logging
      • GUID Generation
      • Time and Date
      • Emailing
        • SMTP Email
        • SendGrid Email API
      • Data Transfer Objects
        • Pagination
      • Security
        • Current User
        • Claims
      • Events
        • Transactional Events
        • Synchronous Events
        • Asynchronous Events
        • Producers
        • Subscribers
      • Validation
        • Fluent Validation
      • Caching
        • Dynamically Compiled Expressions
        • Persistence Caching
        • Caching Services
        • Redis & Valkey
        • Memory Cache
      • Serialization
        • JSON.NET
        • System.Text.Json
    • Patterns
      • Specification
      • Mediator
        • MediatR
          • Validator Behavior
          • Unit of Work Behavior
          • Logging Behavior
      • CQRS
        • Commands
        • Queries
      • Persistence
        • Repository
          • Entity Framework Core
          • Dapper
          • Linq2Db
        • Transactions
          • Unit of Work
      • Event Bus
        • In Memory
        • MediatR
        • Wolverine
      • Message Bus
        • MassTransit
        • Wolverine
    • Architecture
      • Overview
      • Microservices
      • Clean Architecture
      • Event Driven Architecture
  • Examples
    • Clean Architecture
    • CQRS
    • Mediator: MediatR
    • Event Handling: In Memory
    • Event Handling: MediatR
    • Event Handling: MassTransit
    • Event Handling: Wolverine
    • Validation: Fluent Validation
Powered by GitBook
On this page
  • Overview
  • Other Considerations
  • Implementations
  • Examples
  1. Topics
  2. Patterns

Message Bus

Message Bus implementations in RCommon.

PreviousWolverineNextMassTransit

Last updated 7 months ago

Overview

Fundamentally, there is no difference between how RCommon handles events through a message bus, and how they are handled through an . A message that you intend to send through a message bus still comes through the event router, and is then broadcasted through the pipeline of that have been registered in dependency injection. The only thing that changes is the implementation of the which uses a client for a message broker such as RabbitMQ, or Amazon SQS - which is ultimately implemented by one of the below .

Other Considerations

RCommon attempts to simplify many aspects of event/message handling. There are, however, aspects which are inherently complex albeit necessary to prevent event more complex entanglements of downstream sub-systems which consume your events/messages.

Two-Phase Commits

Perhaps the most difficult element of many applications that utilize events to communicate with other systems is the need to transmit messages only after local transactions have been committed successfully. As the database storing the data and the message broker are two separate components, making a single transaction that persists an event and publishes it to the broker can be difficult. One of these operations may fail, causing the system to become inconsistent. The most common solution to this problem is the implementation of a . This is available on both and .

Serialization

Distributing messages through a message bus requires serialization. As such, ensuring that you messages can be serialized is important. The current implementations of message bus have the ability to serialize your messages using various formatters but you'll want to take care to ensure that your objects are serializable so that they don't disrupt the system transmitting/consuming them.

Implementations

Examples

event bus
event producers
event producer
implementations
transactional outbox
MassTransit
Wolverine
MassTransit
Wolverine
Event Handling: MassTransit
Event Handling: Wolverine