Event driven actors - lessons learned
•
2 j'aime•2,018 vues
Presentation at the J-fall 2010 on Event Driven Actors
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Event driven actors - lessons learned
Similaire à Event driven actors - lessons learned (20)
Dernier
Dernier (20)
Event driven actors - lessons learned
- 1. J-Fall 2010 Event Driven Actors Lessons learned Rick van der Arend Paul van Dam
- 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. INTRODUCTION
- 4. Introducing Sogyo • Consultancy • Training • Development • Since 1995
- 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
- 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. Events • Something occurs • This gets noticed • Notification is distributed • One-way, Immutable, Asynchronous • Fire-and-forget Event
- 10. Actors • Incoming message queue • Asynchronous message loop • All mutable state internally • All shared state is immutable • An „independent‟ object Actor
- 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. 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. 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. 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. Motivation: Concurrency No ever increasing clock speeds anymore… Transistors Clock speed Power Instructions / cycle
- 16. CASES 1 2 3
- 17. Cases • Case 1: Research into EDA maintainability • Case 2: Research project in Scala • Case 3: Client project
- 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. CASE 1: EDA MAINTAINABILITY
- 20. Q1. What was the goal? To get an answer to the question: “Does an Event Driven Architecture improve maintainability?”
- 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. 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. Q4. What are our experiences? Cyclomatic complexities EDA LA Efferent coupling
- 24. Q4. What are our experiences? Cyclomatic complexities EDA LA Efferent coupling No significant differences in static code analysis
- 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. 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. 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. 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. 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. 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. CASE 2: RESEARCH PROJECT
- 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. 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. 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. 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. Q3. What did we do and why? Message Bus Controller Controller Model Actors View Actors REST Interface GWT UI Log Actor Save Actor
- 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. 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. CASE 3: CLIENT PROJECT
- 40. Q1. What was the goal? Visualize what is going on in the machine
- 41. Q1. What was the goal? Create a management dashboard
- 42. Q1. What was the goal? Look “flashy”!
- 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. The product
- 45. The product
- 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. SOAP Q3. What did we do and why? (II) Event BusService Domain Model PLC event adapter PLC command adapter Client(s) Reporting
- 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. 4.1 The simple event bus Server Service Domain Event bus
- 50. 4.2 Modifying event messages P P Message queue PLC adapter Domain Reporting P
- 51. 4.2 Modifying event messages P P Message queue PLC adapter Domain Reporting D P
- 52. 4.2 Modifying event messages P P Message queue PLC adapter Domain Reporting D PD
- 53. 4.2 Modifying event messages P P Message queue PLC adapter Domain Reporting PDD
- 54. 4.2 Modifying event messages D D Message queue PLC adapter Domain Reporting PDD
- 55. 4.3 Stubbing of components • Run simulations and tests for free – Useful for performance and integration tests – Demo purposes
- 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. 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. WRAP UP
- 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. 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. Questions?
- 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