Azure Service Bus

Akalanka Gajasinghe — Sat, 16 Mar 2024 13:18:05 +0000

Azure Service Bus is a cloud-based messaging service that facilitates communication between applications and services without requiring everything to be in the cloud. At its core is the Azure Service Bus Namespace, which serves as a container for organizing messaging components. Within a single namespace, you can have multiple queues and topics, helping to manage and streamline communication.

Service Bus is ideal for enterprise-level messaging where critical business information, such as invoices, financial transactions, or credit card swipes, needs to be reliably transmitted. Its key features ensure that messages are,

delivered in sequence
maintain integrity during sessions
support transactional operations,

making it crucial for operations where accuracy and order are paramount.

Azure Service Bus offers comprehensive integration with various Azure services, enhancing its functionality and application scope. Key services that integrate well with Service Bus include Event Grid, Logic Apps, Functions, Dynamics 365, and Stream Analytics. The integration with Event Grid, in particular, enables connectivity with numerous other services, expanding its utility. Moreover, Service Bus provides a straightforward API, facilitating easy interaction with these diverse Azure services

Queue

Messages are sent to and received from queues, simplifying the communication process.
Queues allow for the temporary storage of messages until the receiving application is available to process them.
Messages in the queue are organized and timestamped upon arrival, ensuring an orderly sequence.
Once a message is accepted, it is stored in redundant storage to prevent loss.
The delivery mechanism is based on pull mode, requiring the receiving application to request messages actively.

Topics and Subscriptions

Topics and Subscriptions are used for asynchronous message sending and receiving, similar to queues but with distinct capabilities.
While queues support point-to-point communication, topics are ideal for publish/subscribe (pub/sub) scenarios.
A single topic can have multiple, independent subscriptions, enhancing message distribution flexibility.
Subscribers can receive all messages sent to a topic or use rules and filters to receive specific messages, allowing targeted communication.
Topics enable distributing a single message to multiple receivers, which is not typically possible with queues.
Azure Service Bus incorporates various advanced features, demonstrating its robustness as a messaging technology.
It integrates seamlessly with other Azure services, extending its utility and application within the Azure ecosystem.

Azure Service Bus and Azure Storage Queues

Azure Storage Queues are very similar to Azure Service Bus, Comparison is down below.

Feature	Azure Service Bus	Azure Storage Queues
Intended Use	Complex enterprise-level messaging	Simple, high-volume messaging
Messaging Features	Advanced (e.g., dead-lettering, duplicate detection, sessions, transactions)	Basic
Communication Patterns	Supports various patterns (e.g., pub/sub, sessions)	Basic queuing
Integration	Extensive with Azure services	Limited
Protocols and Standards	AMQP, SBMP, HTTP/HTTPS	HTTP/HTTPS
Security	Advanced security and compliance	Basic security
Scalability	Highly scalable with more complex features	Highly scalable with simpler features
Message Size and TTL	Up to 256 KB/message, configurable TTL	Up to 64 KB (256 KB for premium), max 7 days TTL
Cost	Up to 256 KB/message, configurable TTL	More cost-effective for basic needs
Ideal for	Enterprise applications requiring reliable, ordered, and complex messaging	Web-scale applications requiring massive volume processing with less complexity

Azure Service Bus supports various messaging patterns that allow the distribution of messages to multiple consumers. Some of these patterns include:

Publish/Subscribe (Pub/Sub):
- This is the primary pattern used to distribute a message to multiple consumers. A publisher sends messages to a topic, and each message is then forwarded to all subscriptions associated with that topic. Each subscription acts like an independent queue, receiving copies of the messages sent to the topic. This way, multiple consumers (subscribers) can independently retrieve and process the messages.
Competing Consumers:
- In this pattern, multiple consumers connect to the same queue or subscription. Each consumer competes for message processing. Once a consumer retrieves a message for processing, it is locked and becomes invisible to other consumers. This pattern is useful for load balancing and increasing throughput, as different consumers process different messages in parallel.
Forwarding:
- Azure Service Bus allows you to automatically forward messages from a queue or subscription to another queue or topic. This feature can be used to create complex routing schemes or workflows where messages processed by one consumer are automatically sent to another queue or topic for further processing by additional consumers.
Sessions:
- When dealing with ordered message processing, sessions allow related messages to be processed sequentially. In a scenario with multiple consumers, each session (identified by a session ID) ensures that all messages within a session are processed by the same consumer, maintaining message order within each session.
Dead-lettering:
- While not a direct method of distributing messages to multiple consumers, dead-letter queues can be used as part of a broader pattern where messages that cannot be processed (e.g., due to format errors or processing failures) are moved to a dead-letter queue. These messages can then be consumed and handled (e.g., investigated or reprocessed) by a separate set of consumers.

Simplify Component Communication in .NET with MediatR

Akalanka Gajasinghe — Mon, 03 Jul 2023 18:54:46 +0000

MediatR, the acclaimed NuGet package, is a game-changer for .NET development, revolutionizing the way we handle communication and achieve loose coupling between components. Let's explore the key features of MediatR in this LinkedIn post:

🔹 Mediator Pattern Made Easy:

MediatR provides a robust implementation of the mediator pattern for .NET, enabling seamless communication and decoupling between components. Say goodbye to rigid dependencies and welcome scalable and maintainable applications.

🔹 Request/Response Messages:

With MediatR, you can dispatch request/response messages effortlessly. These messages are directed to a single handler responsible for processing them. This approach streamlines your codebase and promotes a clear separation of concerns, enhancing the overall maintainability and testability of your application.

🔹 Notification Messages:

MediatR takes it a step further by enabling the dispatching of notification messages. These messages are distributed to multiple handlers, allowing you to implement publish/subscribe or observer patterns within your application. This flexibility empowers you to build highly extensible and event-driven systems.

By leveraging MediatR in your .NET projects, you unlock the following benefits:

✅ Simplified communication and reduced coupling between components.

✅ Clean separation of concerns, resulting in highly maintainable code.

✅ Improved testability with easy mocking and unit testing of individual handlers.

✅ Enhanced extensibility through the publish/subscribe mechanism for notification messages.

Join the growing community of developers embracing MediatR and revolutionize your application architecture today!

//Inject MediatR to your DI container
services.AddMediatR(cfg => {
    cfg.RegisterServicesFromAssembly(typeof(Program).Assembly);
});

// Request/response messages
public class CreateTodoItemCommand : IRequest<int> { }
public class CreateTodoItemCommandHandler : IRequestHandler<CreateTodoItemCommand, int>
{
    public Task<int> Handle(CreateTodoItemCommandrequest, CancellationToken cancellationToken)
    {
        // Your application logic
       return Task.FromResult(0);
    }
}

// Notification messages
public class TodoItemCompletedEvent: INotification { } 

public class TodoItemCompletedEventHandler : INotificationHandler<TodoItemCompletedEvent>
{
    public Task Handle(TodoItemCompletedEvent notification, CancellationToken cancellationToken)
    {
        // Your application logic
        return Task.CompletedTask;
    }
}

public class TodoItemCompletedSendMailEventHandler : INotificationHandler<TodoItemCompletedEvent>
{
    public Task Handle(TodoItemCompletedEvent notification, CancellationToken cancellationToken)
    {
        // Your application logic
        return Task.CompletedTask;
    }
}

// Let's Call
// private ISender _mediator;
_mediator.Send(new CreateTodoItemCommand())

// private IPublisher _publisher;
_publisher.Publish(new TodoItemCompletedEvent());

DEV Community: Akalanka Gajasinghe

Azure Service Bus

Simplify Component Communication in .NET with MediatR