This document provides an introduction and overview of NServiceBus, an open source toolkit for building distributed applications using a message-based architecture. It discusses key concepts like messages, components, services, and endpoints. It also demonstrates request/reply and event-based messaging patterns. The document highlights features for handling failures, scaling out to multiple endpoints, and implementing long-running processes through sagas.

1. NServiceBus
introduction to a message based
distributed architecture

2. Mauro Servienti
CTO @ Mastreeno, LTD
mauro.servienti@mastreeno.com
@mauroservienti
//milestone.topics.it
//github.com/mauroservienti
NServiceBus trainer/support
RavenDB trainer
Microsoft MVP – Visual C#

3. Resources
• Slides on SlideShare:
//slideshare.net/mauroservienti
• Samples on GitHub:
//github.com/mauroservienti
– Repository: Conferences
– Branch: 2014/DDDEastAnglia

4. SO…YOU’D LIKE TO SCALE…

5. Scale out and HA
• Basically means: horizontal scale & distribute;
• It can also mean:
– Async;
– Non coupled:
• we need to escape from the monolith;
– Non temporally coupled:
• Where makes sense we should not rely on two portion
of the system to be live at the same time to work as
expected

6. Distribution & RPC #1
Given that we have occasionally connected
moving parts:
Web Frontend
Shipping
WCF Service
Standard RPC call to WCF
If the «Shipping» service fails, because of an hardware failure:
• We can lose information;
• We need to handle failures and retries manually;

7. Distribution & RPC #2
Given that we have network with medium to high latency:
Web Frontend
If the connection with the «Shipping» service fails, is slow or timeouts:
• We can lose information;
• We slow down the whole system;
Shipping
WCF Service
Standard RPC call to WCF

8. Messages
A message can be shipped to a remote service
via a queue
competing consumers
Web Frontend #1 Shipping Endpoint #1
queue
Web Frontend #2 Shipping Endpoint #2
• If one endpoint fails messages will be picked by the other(s);
• On slow connections or slow endpoints the entire system is not slowed;

9. issues and hiccups
• “Distributed”:
– We cannot rely on subsequent calls;
– We cannot rely on ordering to drive the system;
– We cannot rely on transactions;
• “Async”:
– Async errors;
– Auditing;
– Retries;
– Timeouts;

10. Please welcome:
NServiceBus

11. NServiceBus?
• A toolkit:
– reduce the friction of async and distributed
development based on messages on top of
queues;
– Transport independent;
– And much more, much :-)
• A Platform:
– A set of tools to designs, administer and monitor
production solutions;

12. Concepts
• Message
– An atomic piece of information that has a semantic
meaning in the business;
• Component
– Something that can handle a message;
• Service
– A set of components grouped by context;
• Endpoint
– A set of services grouped by:
• SLA(s);
• Infrastructure concerns;
• Etc..;

13. DEMO

14. Recap
• Request/reply pattern;
• “Easy peasy” setup with the "Host";
• “Unubotrusive” mode:
– reduce versioning problems across endpoints;
• Receiver doesn’t know anything of the sender:
– no coupling in the configuration;
• The sender is configured to send messages
– Based on mappings in the configuration;

15. Concepts #2
• Command: A message that semantically
identifies something to be done (imperative):
– "CreateNewUser";
• Event: A message that semantically identifies
something happened and immutable (past):
– "NewUserCreated";
• Subscription: The notion that an endpoint is
interested in an event;

16. DEMO

17. Recap
• Event based pattern;
• Events are “copied” per subscriber;
• Subscriptions defined in the mappings config:
• Subscriptions stored in RavenDB, by default:
– Other options supported out-of-the-box
• Events are, can be, .net interfaces:
– Evolution and versioning is easier: interfaces can
be composed;

18. TRANSPORT

19. Transports?
• The “wire” that connects endpoints;
• Supported transports (OOTB):
• MSMQ;
• RabbitMQ;
• Sql Server;
• Azure ServiceBus & Table Queues;
• Transport independent;
• In v4.x both parties must agree on the serialization format;

20. under the hood
• At the Sender (or publisher):
– Message serialization;
– Push on the transport;
• At the receiver
– Message deserialization;
– Component (Handler) lookup & invoke;
• Wrapped in a “transaction”:
– v4 requires the DTC, v5 won’t :-);
• I hate the DTC :-P

21. Shit happens…
HANDLING FAILURES

22. Async failures
• First Level Retries:
– Message handling is wrapped in a transaction;
– By default is retried in sequence for 5 times;
• Second Level Retries:
– If FLR fails all the attempts, SLR kicks in;
– 5s delay -> FLR, 10s delay -> FLR, 15s delay -> FLR;
• Do not rely on hope: there is the error queue;

23. What are retries for and not for?
• Transient failures:
– E.g. Mail server down or third party services not
available;
• Bugs:
– We deployed a bug, I did :-), and we do not lose
anything
• Not there to handle business exceptions:
– they can, obviously, but their main target are the
DevOps guys;

24. DEMO

25. Recap
• “Easy peasy”;
• Do not wrap your code in a try/catch block;
• Keep your handlers small and idempotent:
– They can be retried;
– The more complex they are the harder will be to
be idempotent;
• The Particular Platform:
– Tool chain to handle failures;

26. Didn’t we start speaking about scalability?
SCALE-OUT

27. DEMO

28. Recap
• Messages are an atomic piece of information:
– They can be handled by one of the endpoints;
• Multiple endpoints means:
– More power to the business;
– Much easier to be highly available;
– Upgrade without shutting down the “system”;
• If we have a storage:
– We need to scale it out too;
– Will it be complex? Can be, but we can;

29. Long running processes
SAGA

30. Long and complex
Check-out
Order Items
Pick up
Ensure Items
In Stock
Bill customer
credit card
3rd party
billing
service
Setup Order
cancellation
Timeout
Start item
collection
Order ready
to be
shipped
Customer
credit card
billed
cancellation
Timeout
Elapsed
Order
Cancelled? yes
No
Cancel &
Complete
The order
Ship &
Complete
The order
User Request

31. DEMO

32. Recap
• A long running process with a state;
• Can be scaled-out;
• Are concurrency safe;
• Stored by default on RavenDB:
– Other options supported out-of-the-box;
• Timeouts are the way to go to handle the
decision process based on a missing “answer”;

33. Mind…
• Keep you handling code as small as possible;
• If an handler does more than one single action
it is a smell:
– Exactly like a too long method;
– Move to a Saga if you need a “shared” state;
• The more an handler is simple the more it will
be easy to make it idempotent;

34. Q&A
THANK YOU, WE ARE ALL SET :-)