Solving problems with event-driven architecture, pub-sub concepts, cross-boundaries event-driven communication and building event-driven applications with RabbitMQ in .NET Covered technologies: .NET 4.0, RabbitMQ

2. Hunting rabbits and event-
driven programming
Marjan Nikolovski

5. { Agenda
‹ Basics and introduction to EDA
‹ Messaging patterns
‹ Internal and cross boundaries messaging
‹ Products and technologies
‹ Demo

6. { Basics and introduction to EDA
‹ So what is an event ?
‹ Event-driven behavior as part of our life
‹ What is EDA ?
‹ Event-driven behavior as part of out apps
‹ Current apps situation
‹ To event-driven behavior situation
‹ How can we establish event-driven architecture ?
‹ Layering introduced in event-driven apps
‹ Why we want to build event-driven apps?

7. { So what is an event ?
‹ An event is an occurrence within a particular system or domain; it is
something that has happened, or is contemplated as having happened
in that domain.
‹ Characteristics
‹ Unique
‹ Time relevant

8. Event-driven behavior as part of
{ our life
On new On Wait for
Go
salary account next
shopping
received empty salary

9. { What is EDA ?
‹ WIKI says: Event-driven architecture (EDA) is a software architecture
pattern promoting the production, detection, consumption of, and
reaction to events.
Event Event Event
producer processor consumer

10. Event-driven behavior as part of
{ out apps
Observation
Active Predictive
diagnostics processing
Event-
driven
apps
Dynamic
Information
operational
dissemination
behavior

11. Current apps situation
{ Request – response scenario

12. Current apps situation
{ Request – response scenario

13. Current apps situation
{ Pull (time based)scenario

14. To event-driven behavior situation
{ Event scenario
Don’t call us, we will
call you

15. To event-driven behavior situation
{ Event scenario

16. To event-driven behavior situation
{ Event scenario

17. To event-driven behavior situation
{ Event scenario

18. How can we establish event-driven
{ architecture ?
‹ Good analyses
‹ Stick to Open/Closed and Single responsibility principles
‹ Define the domain
‹ Define:
‹ Who are event producers
‹ Who are event consumers
‹ Introduce event dispatcher (the mediator)
‹ Determine event channel
‹ Everyone do what they are supposed to do, everything else they
delegate to other involved parties via the event dispatcher

19. Layering introduced in event-
{ driven apps
‹ Event publisher
‹ Any client that generates events
‹ Event mediation and Event channels
‹ Event distribution
‹ Events transport via memory, raw, xml, rest, protobuff …
‹ Event subscriber
‹ Any client that consumes the events
‹ Choose event processing strategy
‹ Simple processing (forwarding)
‹ Event streaming (creating events from streamed data and send it to subscribers)
‹ Complex event processing (pattern detection on events)

20. Layering introduced in event-
{ driven apps
and channels
Consumers
Mediation
Producers

21. Why we want to build event-driven
{ apps?
‹ Pros
‹ Exploit parallelism
‹ Better system design - each event has its own processor (single responsibility)
‹ Reduce dependencies in the system
‹ Reduce coupling
‹ Easier testing
‹ Real time monitoring
‹ Scalability
‹ Maintainability
‹ Cons
‹ Highly abstract concept

22. { Messaging patterns
‹ Publish-subscribe aka PubSub
‹ Topic based PubSub
‹ Point-to-point
‹ Request-reply
‹ Store and forward
‹ Pipeline

23. { Publish-subscribe aka PubSub
Publisher
Publish an event
Topic
Consumes the event Consumes the event
Subscriber Subscriber

24. { Topic based PubSub
Topic
Consumes the event Consumes the event
Subscriber Subscriber
Consumes the event
Subscriber
Subtopic
Publish an event
Publisher

25. { Point-to-point
Publisher Queue Subscriber

26. { Request-reply
Subscriber
Publisher/Subscriber Topic Subscriber
Subscriber

27. { Store and forward
Subscriber
Publisher/Subscriber Topic Subscriber
Subscriber
Data

28. { Pipeline
Publisher Topic Subscriber Subscriber Subscriber

29. Internal and cross boundaries
{ messaging
‹ Internal messaging via in memory event dispatcher
‹ Decorate the subscribers in the system
‹ Decorate the receivers in the system
‹ Develop custom event dispatcher that will dispatch the producer events to the
consumer
‹ Cross boundaries messaging via
‹ Any full-duplex communication
‹ Web/Url callbacks
‹ Web based push notifications - long pooling AJAX request
‹ Queue
‹ Custom messaging software

30. { Products and technologies
‹ XMPP based products
‹ Ejabberd
‹ AMQP based products
‹ RabbitMQ
‹ OpenAMQP
‹ Apache QPID
‹ STOMP based products
‹ ActiveMQ
‹ JMS
‹ Other
‹ MSMQ
‹ Azure Service Bus
‹ ZeroMQ

31. { AMQP protocol
‹ Advanced message queuing protocol for message-oriented middleware
‹ Queuing
‹ Routing (point to point, PubSub)
‹ Reliable
‹ Secure
‹ Interoperability on protocol level instead of API level
‹ So how does it work behind the scenes:
‹ Exchanges
‹ Queues
‹ Bindings
‹ Messages

32. { RabbitMQ Broker
Publisher
Binding Queue Consumer
Exchange
Publisher
Exchange
Binding Queue Consumer
Publisher

33. { Message exchange
Topic Fanout Direct
Exchange
Bindings System.Logs.* System.Interupts.*
SomeKey
Q1 Q2 Q3 Q4 Q5 Q6
Queues

34. {

35. Questions?
• Complete electronic evaluation forms
on the computers in the hall and
enter to win!
– Telerik Ultimate Collection
– RedGate .NET Reflector VSPro
– ComponentOne Enterprise Studio Suite
– Pluralsight yearly subscriptions
– CodeSmith Tools Generator Pro
Personal
– JetBrains ReSharper
– Semos Education Training Voucher
– and many more…