Event driven actors - lessons learned

2,703 views

Published on

Presentation at the J-fall 2010 on Event Driven Actors

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,703
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Event driven actors - lessons learned

  1. 1. J-Fall 2010 Event Driven Actors Lessons learned Rick van der Arend Paul van Dam
  2. 2. Agenda • Introduction • Event Driven Actors • Case 1: Research into EDA maintainability • Case 2: Research project in Scala • Case 3: Client project • Wrap-up
  3. 3. INTRODUCTION
  4. 4. Introducing Sogyo • Consultancy • Training • Development • Since 1995
  5. 5. Introducing the speakers
  6. 6. Introducing the speakers Paul van Dam Sogyo Engineer ▫ Developer ▫ Team lead Interests: ▫ DDD ▫ Craftsmanship ▫ Kung Fu Rick van der Arend Sogyo Consultant ▫ Developer ▫ Architect ▫ Coach / Trainer Interests: ▫ Event Driven ▫ Actor Model ▫ Functional ▫ Questions
  7. 7. EVENT DRIVEN ACTORS
  8. 8. Event-driven Architecture • Software architecture pattern promoting the production, detection, consumption of, and reaction to events. Early usages in interrupt requests and the GUI
  9. 9. Events • Something occurs • This gets noticed • Notification is distributed • One-way, Immutable, Asynchronous • Fire-and-forget Event
  10. 10. Actors • Incoming message queue • Asynchronous message loop • All mutable state internally • All shared state is immutable • An „independent‟ object Actor
  11. 11. Events and Actors • Events are published by an Actor • Other Actors are subscribed to notifications Actor Actor Actor Bus T=0 Event 1 2 2
  12. 12. Motivation: Partitioning  Managing complexity is done by partitioning  HICLEC, SRP  Examples: Subroutines, Functions, Objects, Services, Actors, Agents  Actors are independent, but deterministic Actor Actor System System System Actor SOA (2.0) Event Driven Actors Enterprise level Single system level
  13. 13. Motivation: Loose coupling • Events: immutable, one-way, fire-and-forget • Agents: independent and asynchronous • These characteristics magnify each other • Together, they make a very loose coupling
  14. 14. Motivation: Threading sucks • Standard in Java, C# and others • A form of concurrency with shared memory “Non-trivial multi-threaded programs are incomprehensible to humans …” Edward A. Lee, The Problem with Threads Requires custom locking
  15. 15. Motivation: Concurrency No ever increasing clock speeds anymore…  Transistors  Clock speed  Power  Instructions / cycle
  16. 16. CASES 1 2 3
  17. 17. Cases • Case 1: Research into EDA maintainability • Case 2: Research project in Scala • Case 3: Client project
  18. 18. Questions per case 1. What was the goal? 2. How did we approach this? 3. What did we do and why? 4. What are our experiences? 5. What have we learned?
  19. 19. CASE 1: EDA MAINTAINABILITY
  20. 20. Q1. What was the goal? To get an answer to the question: “Does an Event Driven Architecture improve maintainability?”
  21. 21. Q2. What was our approach We had an UVA Software Engineering student write a dissertation on EDA Maintainability and gave him freedom to experiment
  22. 22. Q3. What did we do and why? Theoretical • Define the problem and its participants • Reason about the influences on maintainability • Compare an EDA and LA implementation Practical • Static code analysis on both implementations • Experiment to get practical validation on the comparison with a Layered Architecture
  23. 23. Q4. What are our experiences? Cyclomatic complexities EDA LA Efferent coupling
  24. 24. Q4. What are our experiences? Cyclomatic complexities EDA LA Efferent coupling No significant differences in static code analysis
  25. 25. Q3. – Setup of the experiment Introduce • Introduction of EDA & LA • Everyone writes down name, experience • Check machine and setup Execute • Implement 3 scenario‟s • For both architectures • Log durations and results Review • Report experiences and views • Review architectures and implementations Explore Implement Review & Pause Read Task 1. Secret Communication 2. Auditing 3. Popularity Contest
  26. 26. Q4. What are our experiences? Time spent to complete the Exploration phase Participant EDA LA EDA / LA A 0:09:04 0:24:33 37% B 0:16:19 0:18:38 88% C 0:25:23 0:43:11 59% D 0:14:11 0:01:45 810% Average 0:22:01 74%0:16:14 Participant EDA LA EDA / LA A 0:53:11 0:54:30 98% B 0:41:08 0:27:22 150% C 1:34:19 1:21:52 115% D 0:48:26 0:52:54 92% Average 0:59:16 0:54:09 109% Time spent to complete the Implementation phase
  27. 27. Q4. What are our experiences? Time spent to complete the Exploration phase Participant EDA LA EDA / LA A 0:09:04 0:24:33 37% B 0:16:19 0:18:38 88% C 0:25:23 0:43:11 59% D 0:14:11 0:01:45 810% Average 0:22:01 74%0:16:14 Participant EDA LA EDA / LA A 0:53:11 0:54:30 98% B 0:41:08 0:27:22 150% C 1:34:19 1:21:52 115% D 0:48:26 0:52:54 92% Average 0:59:16 0:54:09 109% Time spent to complete the Implementation phase EDA required a little less time to explore EDA required a little more time to implement
  28. 28. Q4. What are our experiences? • Impact on the existing code EDA LA Participant Files Places New Files Places New A 3 3 2 5 9 0 B 6 8 0 3 12 0 C 3 3 2 6 6 0 D 2 6 1 3 8 0 Average 3.5 5 1.25 4.25 8.75 0
  29. 29. Q4. What are our experiences? • Impact on the existing code EDA LA Participant Files Places New Files Places New A 3 3 2 5 9 0 B 6 8 0 3 12 0 C 3 3 2 6 6 0 D 2 6 1 3 8 0 Average 3.5 5 1.25 4.25 8.75 0 • EDA leads to less changes, in less files • EDA promotes addition over changing
  30. 30. Q5. What have we learned? • Objectively, complexity stays more or less the same, independent of architecture • EDA makes the flow less visible • EDA lessens the need to know the whole app • EDA makes it easier to add new components
  31. 31. CASE 2: RESEARCH PROJECT
  32. 32. Q1. What was the goal? • WK Pool application needed to be rebuilt • We wanted to make a „object as an agent‟ EDA implementation • Start at April 1st • Deadline was fixed: June 14th 
  33. 33. Q2. What was our approach? • Platform choice with the team • Architectural choices with the team • No „Design Phase‟ • Building user stories in a team of 7: – 1 product manager / graphic designer – 2 back-end developers – 2 front-end developers – 2 part-time architects
  34. 34. Q3. What did we do and why? Platform • JVM → team knowledge • Scala → cool & support for actors, on the JVM • AWS → cloud platform (fast setup and teardown), Java support, Threading (unlike the Google App Engine) Architecture • Event Driven → research goal • Actors → research goal • Fine-Grained Actors → logical consistency-boundary • Broadcast message bus → KISS
  35. 35. Q3. What did we do and why? Architecture (continued) • Model (Actor), View (Actor), Controller (Service) → well known pattern, good fit with the Rest interface, CQRS. Need to attach multiple views to one source (Model). Services localizable statically ('object'-s in Scala) • UI polling synchronously on a View Actor via Rest Interface → experience with the pattern, possibility to use GWT UI • Lift on the server → cool, Scala framework, easy integration • GWT on the client → AJAX UI, insufficient JS experience Persistence • CouchDb → fits actor boundary, scalability, easy replication
  36. 36. Q3. What did we do and why? Message Bus Controller Controller Model Actors View Actors REST Interface GWT UI Log Actor Save Actor
  37. 37. Q4. What are our experiences? • Messages stay looping unless explicitly handled • Timing problems because of non-persistent messaging • Effects are hard to track, both design-time and run-time • Debugging is hard (asynchronicity in debugger & logger) • Modifying published messages was hard (design-time) • Event avalanche: some events caused lots of new events • Adding new functionality (especially views) is easy
  38. 38. Q5. What have we learned? • Use persistent messaging (SBA, BBA?) • Actors 'feel' like a simulation of real life entities. But remember SRP.. • Adding new components in an EDA is easy • Use or make sufficient tooling • Add a timestamp and version to event • Unit-test the actors (evts. in => evts. out)
  39. 39. CASE 3: CLIENT PROJECT
  40. 40. Q1. What was the goal? Visualize what is going on in the machine
  41. 41. Q1. What was the goal? Create a management dashboard
  42. 42. Q1. What was the goal? Look “flashy”!
  43. 43. Q2. How did we approach this? • A combined project team (Sogyo/WSP) – WSP: domain knowledge – Sogyo: software engineering knowledge • Write an application that monitors and reports about events in the real world using a client server event driven architecture.
  44. 44. The product
  45. 45. The product
  46. 46. Q3. What did we do and why? • Platform: – .NET, WPF, WCF • Architecture: – Only events for PLC messages – Internal event bus – Service for configuration – Deployment at customer site
  47. 47. SOAP Q3. What did we do and why? (II) Event BusService Domain Model PLC event adapter PLC command adapter Client(s) Reporting
  48. 48. Q4. What are our experiences? • The event bus can be simple. • Don‟t modify event messages. • Components can easily be stubbed. • Measuring and configuring is something else.
  49. 49. 4.1 The simple event bus Server Service Domain Event bus
  50. 50. 4.2 Modifying event messages P P Message queue PLC adapter Domain Reporting P
  51. 51. 4.2 Modifying event messages P P Message queue PLC adapter Domain Reporting D P
  52. 52. 4.2 Modifying event messages P P Message queue PLC adapter Domain Reporting D PD
  53. 53. 4.2 Modifying event messages P P Message queue PLC adapter Domain Reporting PDD
  54. 54. 4.2 Modifying event messages D D Message queue PLC adapter Domain Reporting PDD
  55. 55. 4.3 Stubbing of components • Run simulations and tests for free – Useful for performance and integration tests – Demo purposes
  56. 56. 4.4 Configuring vs. measuring • Different modes of the application – Configuring adding and removing elements to be like the real world. – Measuring by receiving events from the PLC. • The domain is loaded at the start of the application. • No configuration while measuring
  57. 57. Q5. What have we learned? • Every message on the bus must be unique! • Think about different modes of the application. In our case configuring vs measuring. • Not everything has to be event driven. • EDA makes it easier to add new components.
  58. 58. WRAP UP
  59. 59. Summary Conclusions • EDA lessens the need to know the whole app • EDA makes the flow through the app less visible • EDA makes it easier to add new components Rules of thumb • Use or make sufficient tooling • Think hard about the scope of your components • Not everything has to be event driven
  60. 60. Ideas for future research • What is the proper context to use an EDA in? • What would be the best tooling to have? • How do we determine the granularity of our components (actors)?
  61. 61. Questions?
  62. 62. Contact info Rick van der Arend rvdarend@sogyo.nl Paul van Dam pvdam@sogyo.nl Web: www.sogyo.nl Blog: www.software–innovators.nl

×