SlideShare a Scribd company logo
J-Fall 2010
Event Driven Actors
Lessons learned
Rick van der Arend
Paul van Dam
Agenda
• Introduction
• Event Driven Actors
• Case 1: Research into EDA maintainability
• Case 2: Research project in Scala
• Case 3: Client project
• Wrap-up
INTRODUCTION
Introducing Sogyo
• Consultancy
• Training
• Development
• Since 1995
Introducing the speakers
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
EVENT DRIVEN ACTORS
Event-driven Architecture
• Software architecture pattern promoting the
production, detection, consumption of, and
reaction to events.
Early usages in interrupt requests and the GUI
Events
• Something occurs
• This gets noticed
• Notification is distributed
• One-way, Immutable, Asynchronous
• Fire-and-forget
Event
Actors
• Incoming message queue
• Asynchronous message loop
• All mutable state internally
• All shared state is immutable
• An „independent‟ object
Actor
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
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
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
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
Motivation: Concurrency
No ever increasing clock speeds anymore…
 Transistors
 Clock speed
 Power
 Instructions / cycle
CASES
1 2 3
Cases
• Case 1: Research into EDA maintainability
• Case 2: Research project in Scala
• Case 3: Client project
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?
CASE 1: EDA MAINTAINABILITY
Q1. What was the goal?
To get an answer to the question:
“Does an Event Driven
Architecture improve
maintainability?”
Q2. What was our approach
We had an UVA Software Engineering student
write a dissertation on EDA Maintainability
and gave him freedom to experiment
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
Q4. What are our experiences?
Cyclomatic complexities
EDA
LA
Efferent coupling
Q4. What are our experiences?
Cyclomatic complexities
EDA
LA
Efferent coupling
No significant differences
in static code analysis
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
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
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
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
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
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
CASE 2: RESEARCH PROJECT
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 
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
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
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
Q3. What did we do and why?
Message Bus
Controller Controller
Model
Actors
View
Actors
REST Interface
GWT UI
Log
Actor
Save
Actor
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
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)
CASE 3: CLIENT PROJECT
Q1. What was the goal?
Visualize what is going on in the machine
Q1. What was the goal?
Create a management dashboard
Q1. What was the goal?
Look “flashy”!
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.
The product
The product
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
SOAP
Q3. What did we do and why? (II)
Event BusService
Domain Model
PLC event
adapter
PLC command
adapter
Client(s)
Reporting
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.
4.1 The simple event bus
Server
Service
Domain
Event
bus
4.2 Modifying event messages
P P
Message queue
PLC
adapter
Domain
Reporting
P
4.2 Modifying event messages
P P
Message queue
PLC
adapter
Domain
Reporting
D
P
4.2 Modifying event messages
P P
Message queue
PLC
adapter
Domain
Reporting
D
PD
4.2 Modifying event messages
P P
Message queue
PLC
adapter
Domain
Reporting
PDD
4.2 Modifying event messages
D D
Message queue
PLC
adapter
Domain
Reporting
PDD
4.3 Stubbing of components
• Run simulations and tests for free
– Useful for performance and integration tests
– Demo purposes
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
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.
WRAP UP
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
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)?
Questions?
Contact info
Rick van der Arend
rvdarend@sogyo.nl
Paul van Dam
pvdam@sogyo.nl
Web: www.sogyo.nl
Blog: www.software–innovators.nl

More Related Content

PPTX
Subverting the monolith!
PDF
5 Steps on the Way to Continuous Delivery
PDF
Getting Started with DevOps
PPTX
Bringing CD to the DoD
PDF
Agile Incident Response and Resolution in the Wold of Devops
PPTX
A glance at a scrum team in real software company
PDF
The state of containers for your DevOps journey
PDF
DevOps for absolute beginners
Subverting the monolith!
5 Steps on the Way to Continuous Delivery
Getting Started with DevOps
Bringing CD to the DoD
Agile Incident Response and Resolution in the Wold of Devops
A glance at a scrum team in real software company
The state of containers for your DevOps journey
DevOps for absolute beginners

What's hot (20)

PPTX
Go Faster - Remove Inhibitors to Rapid Innovation
PDF
Agile Software Development Process Practice in Thai Culture
PDF
Continuous Integration, Delivery and Deployment
PPTX
Private Cloud Deployment Automation with XebiaLabs and OpenShift
PDF
Agile Software Development in Practice - A Developer Perspective
PDF
Preparing for Enterprise Continuous Delivery - 5 Critical Steps
PDF
The Last Mile Continued: Incident Management
PPT
DevOps for z Systems @ InterConnect 2016
PPTX
Harman deepak v - agile on steriod - dev ops led transformation
PDF
2 Epic Migrations at Flo:
PPTX
Agile vs. DevOps for Continuous Testing: How to Optimize Your Pipeline
PDF
Voxxed Athens 2018 - Going agile with kanban
PPTX
How to Embed Codeless Test Automation Into DevOps
PDF
Mobile Apps development best practices. TDD, CI, CD
PPTX
User story refinement in Project GATE
PPTX
CI/CD for mobile at HERE
PPTX
Continuous Delivery Overview
PDF
Introduction to CICD
PDF
User Experience Testing—with the Pilots at 18,000 Feet
Go Faster - Remove Inhibitors to Rapid Innovation
Agile Software Development Process Practice in Thai Culture
Continuous Integration, Delivery and Deployment
Private Cloud Deployment Automation with XebiaLabs and OpenShift
Agile Software Development in Practice - A Developer Perspective
Preparing for Enterprise Continuous Delivery - 5 Critical Steps
The Last Mile Continued: Incident Management
DevOps for z Systems @ InterConnect 2016
Harman deepak v - agile on steriod - dev ops led transformation
2 Epic Migrations at Flo:
Agile vs. DevOps for Continuous Testing: How to Optimize Your Pipeline
Voxxed Athens 2018 - Going agile with kanban
How to Embed Codeless Test Automation Into DevOps
Mobile Apps development best practices. TDD, CI, CD
User story refinement in Project GATE
CI/CD for mobile at HERE
Continuous Delivery Overview
Introduction to CICD
User Experience Testing—with the Pilots at 18,000 Feet
Ad

Viewers also liked (20)

PPTX
Claude monet
PPTX
ley 1014
PPS
Arvoredeamigos
PDF
Laura Munn
PPTX
Get Results With Email Marketing
PPT
สรุปเศรษฐศาสตร์กลยุทธิ์ 17 เมษายน 2553
PPT
D:\getting a charge out of sceience
PPTX
The Rebel’s Handbook
PPTX
Lean & Scrum at VietnamWorks
PPTX
Pam Britton - Leveraging Learning
PPS
N E W Y O R K C I T Y
PPT
L03 Ecosystems Biomes
PPT
PDF
Receitas pessah
PDF
The RIGHT Way to Approach Long-Term Care Insurance
PPTX
Prototype
PDF
Small Business Effective Digital Presence
PPTX
I4school collaborative 3
KEY
Langrich社でのEmacs活用、langrich.el
Claude monet
ley 1014
Arvoredeamigos
Laura Munn
Get Results With Email Marketing
สรุปเศรษฐศาสตร์กลยุทธิ์ 17 เมษายน 2553
D:\getting a charge out of sceience
The Rebel’s Handbook
Lean & Scrum at VietnamWorks
Pam Britton - Leveraging Learning
N E W Y O R K C I T Y
L03 Ecosystems Biomes
Receitas pessah
The RIGHT Way to Approach Long-Term Care Insurance
Prototype
Small Business Effective Digital Presence
I4school collaborative 3
Langrich社でのEmacs活用、langrich.el
Ad

Similar to Event driven actors - lessons learned (20)

PPTX
Reliable mobile test automation
PDF
Conquer CI Server! - Re-establishment of Order and Nurture of the Solid Organ...
PDF
Kubernetes at Reddit: An Origin Story - KubeCon NA 2018
PDF
Cloud and Network Transformation using DevOps methodology : Cisco Live 2015
PDF
HCI U-II HCI software Process (1).pdf
PDF
Technology-Driven Development: Using Automation and Development Techniques to...
DOC
Sathish project mgmt_pmp_9+yrs
PPTX
Acceptance Test Driven Development
PPTX
The Agile Mindset
PDF
Why and How to Run Your Own Gitlab Runners as Your Company Grows
PDF
Why use Gitlab
PPTX
Performance Testing in Continous Delivery
PPSX
Directions NA Water-Agile-Fall methodology and NAV implementation
PDF
Global IT Service Management Tool Implementation – A PRINCE2® project managem...
PDF
Apache CloudStack Examination - CloudStack Collaboration Conference in Europe...
DOC
Aniruddha_Mukherjee_Jan_2015
PPTX
Can We Make Maps from Videos? ~From AI Algorithm to Engineering for Continuou...
PDF
Behavior-Driven Development (BDD) Testing with Apache Spark with Aaron Colcor...
PDF
Usable Software Design
PPTX
Build software like a bag of marbles, not a castle of LEGO®
Reliable mobile test automation
Conquer CI Server! - Re-establishment of Order and Nurture of the Solid Organ...
Kubernetes at Reddit: An Origin Story - KubeCon NA 2018
Cloud and Network Transformation using DevOps methodology : Cisco Live 2015
HCI U-II HCI software Process (1).pdf
Technology-Driven Development: Using Automation and Development Techniques to...
Sathish project mgmt_pmp_9+yrs
Acceptance Test Driven Development
The Agile Mindset
Why and How to Run Your Own Gitlab Runners as Your Company Grows
Why use Gitlab
Performance Testing in Continous Delivery
Directions NA Water-Agile-Fall methodology and NAV implementation
Global IT Service Management Tool Implementation – A PRINCE2® project managem...
Apache CloudStack Examination - CloudStack Collaboration Conference in Europe...
Aniruddha_Mukherjee_Jan_2015
Can We Make Maps from Videos? ~From AI Algorithm to Engineering for Continuou...
Behavior-Driven Development (BDD) Testing with Apache Spark with Aaron Colcor...
Usable Software Design
Build software like a bag of marbles, not a castle of LEGO®

Recently uploaded (20)

PPTX
MYSQL Presentation for SQL database connectivity
PDF
NewMind AI Weekly Chronicles - August'25 Week I
PDF
MIND Revenue Release Quarter 2 2025 Press Release
PDF
Unlocking AI with Model Context Protocol (MCP)
PDF
Build a system with the filesystem maintained by OSTree @ COSCUP 2025
PDF
Architecting across the Boundaries of two Complex Domains - Healthcare & Tech...
PPTX
Effective Security Operations Center (SOC) A Modern, Strategic, and Threat-In...
PDF
7 ChatGPT Prompts to Help You Define Your Ideal Customer Profile.pdf
PDF
Profit Center Accounting in SAP S/4HANA, S4F28 Col11
PDF
Review of recent advances in non-invasive hemoglobin estimation
PPTX
Spectroscopy.pptx food analysis technology
PPTX
20250228 LYD VKU AI Blended-Learning.pptx
PDF
Empathic Computing: Creating Shared Understanding
PPTX
VMware vSphere Foundation How to Sell Presentation-Ver1.4-2-14-2024.pptx
PDF
Encapsulation_ Review paper, used for researhc scholars
PDF
Advanced methodologies resolving dimensionality complications for autism neur...
PDF
cuic standard and advanced reporting.pdf
PDF
Mobile App Security Testing_ A Comprehensive Guide.pdf
PPT
Teaching material agriculture food technology
PDF
Encapsulation theory and applications.pdf
MYSQL Presentation for SQL database connectivity
NewMind AI Weekly Chronicles - August'25 Week I
MIND Revenue Release Quarter 2 2025 Press Release
Unlocking AI with Model Context Protocol (MCP)
Build a system with the filesystem maintained by OSTree @ COSCUP 2025
Architecting across the Boundaries of two Complex Domains - Healthcare & Tech...
Effective Security Operations Center (SOC) A Modern, Strategic, and Threat-In...
7 ChatGPT Prompts to Help You Define Your Ideal Customer Profile.pdf
Profit Center Accounting in SAP S/4HANA, S4F28 Col11
Review of recent advances in non-invasive hemoglobin estimation
Spectroscopy.pptx food analysis technology
20250228 LYD VKU AI Blended-Learning.pptx
Empathic Computing: Creating Shared Understanding
VMware vSphere Foundation How to Sell Presentation-Ver1.4-2-14-2024.pptx
Encapsulation_ Review paper, used for researhc scholars
Advanced methodologies resolving dimensionality complications for autism neur...
cuic standard and advanced reporting.pdf
Mobile App Security Testing_ A Comprehensive Guide.pdf
Teaching material agriculture food technology
Encapsulation theory and applications.pdf

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
  • 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
  • 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.
  • 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.
  • 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)?
  • 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