Event Driven Architecture

28,376 views
28,095 views

Published on

Event-driven architecture (EDA) is a software architecture pattern promoting the production, detection, consumption of, and reaction to events.
This architectural pattern may be applied by the design and implementation of applications and systems which transmit events among loosely coupled software components and services.

In this session you’ll learn how to create a loosely coupled architecture for your business that has the domain at the core. You’ll learn the basics of EDA, and also learn how we are transforming our architecture at Unibet.com to become event driven, and what benefits it will bring to our business. The session will cover technologies such as JMS, XML, JSON, Google Protocol Buffers, ActiveMQ and Spring.

Published in: Technology, Business
2 Comments
92 Likes
Statistics
Notes
  • learned a new word: Domain Events. very useful
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • If you want your presentation reviewed- allow it to be downloaded without invading our registry. Due to lousy web performance - online viewing is impossible.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
28,376
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
1,194
Comments
2
Likes
92
Embeds 0
No embeds

No notes for slide



































































  • Event Driven Architecture

    1. 1. Domain Event Driven Architecture Stefan Norberg, Head of Architecture at Unibet.com twitter: @stnor email: stefan.norberg@unibet.com blog: http://stnor.wordpress.com
    2. 2. @stnor • 17 years as an IT professional • Has worked with most aspects of IT • Operations & infrastructure • IT security • Systems development • Software architecture • Enterprise architecture • Head of Architecture at Unibet
    3. 3. Agenda • Basics and EDA intro • The SOA problem • How Domain EDA completes SOA • Implementation notes from Unibet • What to tell your manager
    4. 4. The three styles of interaction Type of interaction Initiator Participants Time-driven Time The specified systems Request-driven Client Client and Server Event-driven Event Open-ended
    5. 5. Time driven Fruit system run inventory check every 60 mins
    6. 6. Request driven Fruit Tarzan system Me want three bananas!
    7. 7. Event driven Fruit system “Tarzan took three bananas” “Fruit system is low on bananas”
    8. 8. 5 Principles of EDA • “Real-time” events as they happen at the producer • Push notifications • One-way “fire-and-forget” • Immediate action at the consumers • Informational (“someone logged in”), not commands (“audit this”)
    9. 9. Typical EDA architecture Event system system system Producers Event Event Bus Transport Event system system system Consumers
    10. 10. Main benefits of EDA • Better service (no batch, less waiting) • No point-to-point integrations (fire & forget) • High performance, highly scalable systems
    11. 11. The birth of a system Inventory Customer Shop
    12. 12. The monolith Shop Payment Customer Newsletter Reporting Inventory
    13. 13. SOA architecture #1 Divide the problem domains into separate systems Shop Payment Newsletter Customer Inventory Reporting DB
    14. 14. SOA architecture #1 A lot of point to point integration... Shop Payment Newsletter Customer Inventory Reporting DB
    15. 15. SOA architecture #2 Shop Payment Newsletter Service Bus Customer Inventory Reporting DB
    16. 16. SOA architecture #2 Still a lot of point to point integration... Shop Payment Newsletter Enterprise Spaghetti Box (ESB) Customer Inventory Reporting DB
    17. 17. Let’s add fraud checks fraud Shop Payment Newsletter fraud Service Bus Customer Inventory Reporting DB
    18. 18. Let’s add a loyalty system fraud Shop Payment Newsletter fraud Service Bus Customer Loyalty Inventory Reporting DB
    19. 19. Integration ripple effect fraud Shop Payment Newsletter fraud Service Bus Customer Loyalty Inventory Reporting DB
    20. 20. Problem summary • SOA is all about dividing domain logic into separate systems and exposing it as services • Some domain logic will, by its very nature, be spread out over many systems • The result is domain pollution and bloat in the SOA systems
    21. 21. “It's really become clear to me in the last couple of years that we need a new building block and that is the Domain Events” -- Eric Evans, QCon 2009
    22. 22. Domain Events and SOA • A Domain Event is something that happened that the domain expert cares about • A SOA system’s primary focus should be on the domain and domain logic
    23. 23. Domain EDA • By exposing Domain Events on a shared event bus we can isolate cross cutting functions to separate systems
    24. 24. Domain EDA + SOA Reporting Loyalty Shop Payment Newsletter Event Bus Inventory Customer
    25. 25. Domain EDA + SOA Reporting Loyalty Shop Payment Newsletter Event Bus BAM Inventory Customer Fraud
    26. 26. “You complete me” Domain EDA SOA
    27. 27. Example how Domain EDA decouples
    28. 28. Coupled integration Trading Reporting system system model model
    29. 29. Coupled integration Trading Reporting system system model v2 model
    30. 30. Domain EDA integration I’m interested in buy, sell and market status events Trading domain events subscribe Reporting system system model model
    31. 31. Domain EDA integration I’m interested in buy, sell and market status events Trading domain events subscribe Reporting system system model v2 model
    32. 32. - “So what? I can do that with SOA...” - “Yes, but can you do THIS?” (drumroll)
    33. 33. Domain EDA integration I’m interested in buy, sell and market status events Trading domain events subscribe Reporting system system model v2 model Trading domain events system NG model
    34. 34. Domain EDA integration I’m interested in buy, sell and market status events Trading subscribe Reporting system system model v2 model Trading domain events system NG model
    35. 35. Example how EDA scales
    36. 36. Traditional SOA scalability issue 200 tx/s Order processing
    37. 37. Traditional SOA scalability issue 200 tx/s Order processing request/response Loyalty system
    38. 38. Traditional SOA scalability issue 200 tx/s Order processing request/response Loyalty system 100 tx/s
    39. 39. SOA: Weakest link dictates the peak throughput of the system 100 tx/s Order processing request/response Loyalty system 100 tx/s
    40. 40. EDA: Weakest link dictates the sustained throughput of the system 200 tx/s Order processing event Loyalty system 100 tx/s
    41. 41. Implementation notes from Unibet hans.hall@unibet.com
    42. 42. MQ considerations • Ordering • Durability • Performance • Once and only once delivery
    43. 43. Our requirements • 1000 messages / second sustained • Guaranteed delivery • Easy to use client
    44. 44. Brokers tested • Lots of brokers tested • ActiveMQ, OpenMQ, HornetQ, Websphere, Fiorano, RabbitMQ, QPID • Second round • ActiveMQ, OpenMQ and RabbitMQ • ActiveMQ - fitted our use case the best
    45. 45. Testing brokers • Killing brokers • Flow control • Slow consumers • Durable / non-durable • Small configuration change can have huge impact on throughput
    46. 46. Payload considerations
    47. 47. The smorgasbord Schema Name Standardized Binary Easy to use X-platform Std API support ASN.1 Yes Yes Yes No Yes No CSV Partial No No No? Yes No DOM, SAX, XML Yes Yes No Yes Yes XQUERY, XPATH JSON Yes No No Yes Yes No Java serialization No Partial Yes Yes No No Hessian No Partial Yes Yes Yes No Protocol Buffers No Yes Yes Yes Yes No BSON No No Yes Yes Yes No
    48. 48. Domain events need schema support Schema Name Standardized Binary Easy to use X-platform Std API support ASN.1 Yes Yes Yes No Yes No CSV Partial No No No? Yes No DOM, SAX, XML Yes Yes No Yes Yes XQUERY, XPATH JSON Yes No No Yes Yes No Java serialization No Partial Yes Yes No No Hessian No Partial Yes Yes Yes No Protocol Buffers No Yes Yes Yes Yes No BSON No No Yes Yes Yes No
    49. 49. + Efficient, x-platform and easy to use Schema Name Standardized Binary Easy to use X-platform Std API support ASN.1 Yes Yes No No Yes No DOM, SAX, XML Yes Yes No Yes Yes XQUERY, XPATH Protocol Buffers No Yes Yes Yes Yes No
    50. 50. Protocol Buffers • Flexible, efficient, automated mechanism for serializing (binary) • Schema support (.proto files) • Language neutral
    51. 51. Example newuserevent.proto: option java_package = "com.example.foo"; message NewUserEvent { required string name = 1; required int32 id = 2; optional string email = 3; enum PhoneType { MOBILE = 0; HOME = 1; WORK = 2; } message PhoneNumber { required string number = 1; optional PhoneType type = 2 [default = HOME]; } repeated PhoneNumber phone = 4; }
    52. 52. Generating Java Source $ protoc --proto_path=IMPORT_PATH --java_out=DST_DIR path/to/file.proto IMPORT_PATH specifies a directory in which to look for .proto files when resolving import directives. If the DST_DIR ends in .zip or .jar, the compiler will write the output to a single ZIP-format archive file with the given name.
    53. 53. Builders vs messages • Messages classes are immutable • Use builders to construct NewUserEvent stefan = NewUserEvent.newBuilder() .setId(1337) .setName("Stefan Norberg") .setEmail(“stefan@norberg.org") .addPhone( NewUserEvent.PhoneNumber.newBuilder() .setNumber("+46 70 99 66 547") .setType(NewUserEvent.PhoneType.WORK)) .build();
    54. 54. Evolving messages • Be careful with required fields • New fields that you add should be optional or repeated • New fields should have sensible defaults • Prefix deprecated non-required fields with OBSOLETE_ (convention)
    55. 55. Sample EDA producer @Autowired DomainEventPublisher publisher; NewUserEvent stefan = NewUserEvent.newBuilder() .setId(1337) .setName("Stefan Norberg") .setEmail(“stefan@norberg.org") .addPhone( NewUserEvent.PhoneNumber.newBuilder() .setNumber("+46 70 99 66 547") .setType(NewUserEvent.PhoneType.WORK)) .build(); publisher.publish(stefan);
    56. 56. Sample EDA consumer public class YourDomainListenerPOJO { public void receive(LoginEvent loginEvent) { // do something } @Durable(clientId=”com.example.foo.bar”) public void receive(NewUserEvent newUserEvent) { // do something } } <import resource=”classpath:spring-domain-events.xml /> <bean id=”domainEventListener” class=”com.foo.YourDomainListenerPOJO”/> <domain-events:subscribe id=”eventSubscriber” subscriber=”domainEventListener”/>
    57. 57. What to tell your manager
    58. 58. What to tell your manager • SOA+EDA will reduce time-to-market for new functionality • SOA+EDA will enable a layer of high-value services that have a visible impact on the bottom line of the business
    59. 59. Game changing value-add
    60. 60. Complex Event Processing (CEP) • Receives domain events • Performs event correlation using a QL • Fires domain events (“findings”)
    61. 61. CEP Examples request/response “action” events Correlation events “findings” (CEP) if there are no Mastercard deposits from France in 5 minutes during business hours, send NoDespositsEvent if there are >30 failed logins using >5 accounts from the same ip within 2 minutes, block the ip for 24 hours if customer loses €2000 in the casino within 30 minutes and customer != highroller send PotentialHighrollerEvent AND grant €200 casino premium
    62. 62. Business Process Management (BPM) • Business control over definition and automation of business processes • SOA services orchestration • Processes can/should be started by domain events
    63. 63. BPM example Customer System Evaluate Get Customer Profit > Highroller Info €5000 Start Manual investigation / PotentialHighrollerEvent decision Profit > Stop decision? Set VIP Status Stop €1000 Manager approved? approval Stop
    64. 64. Business Activity Monitoring (BAM) • Aggregation, analysis, and presentation of real time information • BAM attempts to do for business processing what network management tools do for network operations
    65. 65. The real-time business eco system Monitoring events (BAM) events Great business Business Value Correlation events Processes (CEP) (BPM) request/response events events request/response Domain Event Driven Service Oriented Architecture (D-EDA) Architecture (SOA) IT enhancements Great architecture IT systems
    66. 66. Thank you!

    ×