Mauro Servienti and Sean Farmar show how to use NServiceBus to power a web application with real-time request-response and publish-subscribe messaging. Learn to: * Broadcast ‘push’ notifications to many clients * Send response notifications to specific clients * Handle front end scale-out requirements with little effort * Design and use a backplane to cover more complex scenarios * Connect NServiceBus with .NET SignalR

1. http://particular.net
Powering front end apps with NServiceBus
Sean Farmar – Mauro Servienti
Solution Architects @ Particular Software

2. Agenda
• Targeted responses overview
• Scale out issues
• Technical solutions
• Architectural implications

3. Targeted responses overview
• Also identified as Request/Reply
• Technical requirements may drive in the Request/Reply direction:
• As seen with Elton Stoneman: SignalR clients
• IoT devices that cannot participate in a pub/sub based architecture
• Integrations with third party services or legacy systems

4. Queue
Request / Reply scenario
SignalR
client
HTTP based
Front-end
Back-end
system
Message MessageSocket
Reply MessageReply Message

5. Queue
Request / Reply “Scale out” issue
SignalR
client
Front-end
Instance-1
Back-end
system
Message MessageSocket
Reply MessageReply Message
Front-end
Instance-2
Front-end
Instance-n
Socket
Instances Cluster

6. Request / Reply “Callbacks” scenario
Queue
SignalR
client
Front-end
Instance-1
Back-end
system
Message MessageSocket
Return Message
Front-end
Instance-2
Front-end
Instance-n
Instances Cluster
ReturnMessage

7. “Callbacks” Scale Out issue
Queue
SignalR
client
Front-end
Instance-1
Back-end
system
Message MessageSocket
Return Message
Front-end
Instance-2
Front-end
Instance-n
Instances Cluster
ReturnMessage

8. Backplane: transport agnostic
Queue
SignalR
client
Front-end
Instance-1
Back-end
system
Message MessageSocket
Reply / Event
Front-end
Instance-2
Front-end
Instance-n
Instances Cluster
backplane
Reply Message Copy
Note: A backplane is a Single Point of Failure

9. Unique Queue Per Endpoint Instance
SignalR
client
Front-end
Instance-1
Back-end
system
Message MessageSocket
Reply / EventFront-end
Instance-2
Front-end
Instance-n
Instances Cluster
Exchange
Reply / Event Copy
Instance-2 binding
Note: Transport dependent

10. Demo

11. Single Responsibility Principle
• Backplanes and Unique Qs force endpoints to have one responsibility:
• Talk to the SignalR client (in our sample)
• Be the bridge connecting 2 different infrastructures using different transports
• Such endpoints can’t have any business responsibility:
• All the instances would receive a copy of the message
• All the instances would try to execute the same business logic

12. NSBCon – Dallas, TX
December 1 – 4 – http://particular.net/nsbcon2015

13. Q&A
Thank you!