• Save

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Event driven actors - lessons learned

on

  • 2,185 views

Presentation at the J-fall 2010 on Event Driven Actors

Presentation at the J-fall 2010 on Event Driven Actors

Statistics

Views

Total Views
2,185
Views on SlideShare
2,183
Embed Views
2

Actions

Likes
1
Downloads
0
Comments
0

1 Embed 2

http://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Event driven actors - lessons learned Event driven actors - lessons learned Presentation Transcript

  • 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 Rick van der Arend Paul van Dam Sogyo Consultant Sogyo Engineer ▫ Developer ▫ Developer ▫ Architect ▫ Team lead ▫ Coach / Trainer Interests: Interests: ▫ DDD ▫ Event Driven ▫ Craftsmanship ▫ Actor Model ▫ Kung Fu ▫ 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 Event • Something occurs • This gets noticed • Notification is distributed • One-way, Immutable, Asynchronous • Fire-and-forget
  • Actors • Incoming message queue • Asynchronous message loop Actor • All mutable state internally • All shared state is immutable • An „independent‟ object
  • Events and Actors • Events are published by an Actor • Other Actors are subscribed to notifications Event T=0 Actor 2 Actor 1 Bus 2 Actor
  • Motivation: Partitioning SOA (2.0) System  Managing complexity is Enterprise level done by partitioning  HICLEC, SRP System System  Examples: Subroutines, Functions, Objects, Services, Actors, Agents Actor Single system level  Actors are independent, Actor Actor but deterministic Event Driven Actors
  • 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 Requires custom locking “Non-trivial multi-threaded programs are incomprehensible to humans …” Edward A. Lee, The Problem with Threads
  • Motivation: Concurrency No ever increasing clock speeds anymore…  Transistors  Clock speed  Power  Instructions / cycle
  • 1 2 3 CASES
  • 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 Efferent coupling EDA LA
  • Q4. What are our experiences? Cyclomatic complexities Efferent coupling EDA No significant differences in static code analysis LA
  • Q3. – Setup of the experiment Explore • Introduction of EDA & LA • Everyone writes down name, experience Introduce • Check machine and setup 1. Secret Communication • Implement 3 scenario‟s • For both architectures Read 2. Auditing Implement Execute • Log durations and results Task 3. Popularity Contest • Report experiences and views • Review architectures and implementations Review Review & Pause
  • 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:16:14 0:22:01 74% Time spent to complete the Implementation phase 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%
  • 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% EDACrequired a little less 0:43:11 explore 59% 0:25:23 time to D 0:14:11 0:01:45 810% Average 0:16:14 0:22:01 74% Time spent to complete the Implementation phase Participant EDA LA EDA / LA A 0:53:11 0:54:30 98% B 0:41:08 0:27:22 150% EDA required C a little more 1:34:19 time to implement 1:21:52 115% D 0:48:26 0:52:54 92% Average 0:59:16 0:54:09 109%
  • 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 • EDA leads to less changes, in less files 9 A 3 3 2 5 0 • EDA promotes addition0over changing 12 B 6 8 3 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
  • 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? Model View Log Actors Actors Actor Message Bus Save Controller Controller Actor REST Interface GWT UI
  • 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
  • Q3. What did we do and why? (II) PLC event PLC command Domain Model adapter adapter Service Event Bus SOAP Reporting Client(s)
  • 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 Event bus Domain
  • 4.2 Modifying event messages Reporting P PLC adapter P P Message queue Domain
  • 4.2 Modifying event messages Reporting PLC adapter P P P Message queue D Domain
  • 4.2 Modifying event messages Reporting PLC adapter D P P P Message queue D Domain
  • 4.2 Modifying event messages Reporting PLC adapter D D P P P Message queue Domain
  • 4.2 Modifying event messages Reporting PLC adapter D D P D D Message queue Domain
  • 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