Difference between revisions of "Real World Applications/Event Driven Applications"

From HaskellWiki
Jump to navigation Jump to search
 
(50 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
== Introduction ==
 
== Introduction ==
   
An event driven application is an application that reacts to external events.
+
An event driven application/architecture is an application/architecture that is driven by internal/external events. Most non-trivial applications/architectures (from Operating Systems to Web Servers and Enterprise applications) are event driven.
   
Examples of events would be:
+
Examples of events are:
   
* A loan application has been accepted/rejected (commercial business).
+
* A Loan Application has been accepted/rejected (commercial business).
* A new rostering schedule is ready for distribution to crew (airline system).
+
* A new Rostering Schedule is ready for distribution to all crew (Airline Management System).
  +
* An Illegal Trade Pattern has been detected (Trading Fraud Detection System).
* A simulated car has hits another simulated car (commercial racing game).
 
  +
* A simulated car has hits another simulated car (Commercial Racing Game).
* A HTML message has been received (web server).
 
  +
* A robot has reached its destination (Real Time Warehouse Management System).
* A key has been pressed (text editor).
 
  +
* A HTML message has been received (Web Server).
  +
* A key has been pressed (Text Editor).
   
 
The examples demonstrate that events can be anything from high level business events ("A loan application accepted/rejected") to low level events ("User pressed key").
 
The examples demonstrate that events can be anything from high level business events ("A loan application accepted/rejected") to low level events ("User pressed key").
   
In the following, I will show one way to architecture a Haskell system so that it can scale from small "toy" applications (dealing with low level IO events) to large scale "Enterprise" applications (dealing with high level business events).
+
In the following, I will show a way to architecture a Haskell system so that it can scale from small "toy" applications (dealing with low level IO events) to large scale, high volume, distributed, fault tolerant "Enterprise" scale applications.
   
 
Please note that the following is not the only way to attack the problem.
 
Please note that the following is not the only way to attack the problem.
So please contribute your (clearly superior of course) alternative way to do it here: [[https://www.haskell.org/haskellwiki/Real_World_Applications] Real World Applications]
+
So please contribute your (clearly superior of course) alternative way to do it here: [https://www.haskell.org/haskellwiki/Real_World_Applications Real World Applications]
   
 
== Events in Haskell ==
 
== Events in Haskell ==
Line 41: Line 43:
 
== A ''Tiny'' Event Driven Haskell Application ==
 
== A ''Tiny'' Event Driven Haskell Application ==
   
Let's begin with a simple event driven Haskell application:
+
Let's warm up with a ''tiny'' toy event driven Haskell application.
  +
In this case, an event driven calculator that can add numbers and exit.
  +
Not very exciting but it is useful for introducing a number of key concepts.
  +
  +
I will in the following use the term "Domain" to stand for the application state. Fell free to use "Shipping" instead of Domain if your application area is shipping or "Game" if your domain is a game application. More info here: [http://en.wikipedia.org/wiki/Domain_model Domain Model].
  +
  +
Here is the Domain for the calculator application:
   
 
<haskell>
 
<haskell>
 
module Main where
 
module Main where
   
  +
data Domain =
import Control.Monad (when)
 
  +
Domain Int
  +
deriving(Eq,Show)
  +
</haskell>
   
  +
The calculator state simply keeps track of the current value.
import Domain -- The (pure) "domain model" is defined here
 
  +
import Event -- The (pure) events
 
  +
The next step is to define the events that the user can generate:
import UI -- The (non-pure) UI (User Interface) is defined here
 
  +
  +
<haskell>
  +
data Event =
  +
EventAdd Int
  +
| EventExit
  +
deriving(Eq,Show)
 
</haskell>
 
</haskell>
   
  +
In this case all the user can do is to add and exit.
I am here using the term "Domain" to abstract away from the actual application domain. Fell free to use "Shipping" instead of Domain if your application area is shipping containers and "Game" if your domain is a game application. More info here: [[http://en.wikipedia.org/wiki/Domain_model]]
 
   
  +
With those two definition, we can now write the "domain update" function.
The Event module defines the events that both the Domain module and the UI module need to agree on.
 
  +
It simply takes the current state of the domain and an event as input
  +
and outputs the updated domain:
   
  +
<haskell>
The UI module contains some sort of User Interface. For now it doesn't really matter how the UI is implemented. All that matters is that it can somehow present the Domain to a user and get user events back. More on this later.
 
  +
dmUpdate :: Domain -> Event -> Domain
  +
  +
dmUpdate (Domain v) (EventAdd a) = Domain (v + a)
  +
  +
dmUpdate dm _ = dm
  +
</haskell>
  +
  +
For this tiny toy example all we can do is to react to the EventAdd event
  +
and calculate the new value.
  +
  +
The next step is to write the UI. For now it doesn't really matter how the UI is implemented. All that matters is that it can somehow present the Domain to a user and get user events back (More on this later):
  +
  +
<haskell>
  +
uiUpdate :: Domain -> IO [Event]
  +
  +
uiUpdate (Domain v) = do
  +
putStrLn $ "Value is now: " ++ show v
  +
if v < 3 then
  +
return [EventAdd 1]
  +
else
  +
return [EventExit]
  +
</haskell>
  +
  +
For this tiny toy example the UI will not even read from stdin.
  +
It instead return EventAdd events until the Domain state value is >= 3.
  +
After which it generates the EventExit event. Yes it is just a tiny toy example :-)
  +
  +
Given ''dmUpdate'' and ''uiUpdate'' we can now write what is traditionally called the "Event Loop". The event loop is the beating heart of an event driven application:
  +
  +
<haskell>
  +
run :: Domain -> [Event] -> IO ()
  +
  +
run dm [] = do
  +
events <- uiUpdate dm
  +
run dm events
  +
  +
run _ (EventExit:_) =
  +
return ()
  +
  +
run dm (e:es) =
  +
run (dmUpdate dm e) es
  +
</haskell>
  +
  +
For this tiny toy example, the event loop simply asks the UI for new events.
  +
And updates the domain when events are available. It exits when EventExit is received from the UI.
  +
  +
And here is the main function to bootstrap the event loop:
   
 
<haskell>
 
<haskell>
 
main :: IO ()
 
main :: IO ()
main = run newDomain
+
main = run (Domain 0) []
 
</haskell>
 
</haskell>
   
  +
''main'' simply creates a new domain (Domain 0) and calls ''run'' with an empty event list to get started.
The main function simply starts the event loop (run):
 
  +
  +
The result of running the application is:
   
 
<haskell>
 
<haskell>
  +
Value is now: 0
run :: Domain -> IO ()
 
  +
Value is now: 1
run dm = do
 
  +
Value is now: 2
event <- uiUpdate dm
 
  +
Value is now: 3
when (event != EventExit) $
 
run $ domainUpdate dm event
 
 
</haskell>
 
</haskell>
   
  +
== Consequences ==
"run" is where everything happens. The UI updates itself and returns an event.
 
  +
If the event is not EventExit then the domain will be updated with the event and the loop continues.
 
  +
The tiny application above is simple. However a number of key choices have been made that will profoundly shape how the application scales from this tiny application to "Enterprise" level:
  +
  +
UI depends on Domain - Domain does ''not'' depend on UI.
  +
This is the complete opposite of how most applications are (wrongly) developed.
  +
  +
UI can be swapped without changing Domain.
  +
Try that with your average application.
  +
  +
''dmUpdate'' is not generating any events.
  +
However in a more realistic application, updating the domain will typically result in additional events being generated.
  +
  +
Domain is ''pure''.
  +
All the goodness of functional programming.
  +
The idea is to keep as much of the code UI independent.
  +
  +
Domain can be tested without the UI.
  +
No need to setup Database to test.
  +
  +
The Domain API is ''Value'' based not ''API'' based.
  +
Events can be queued, recorded, distributed and replayed.
  +
  +
Events can (should) be ''asynchronous''.
  +
  +
And by the way, this is ''not'' MVC/MVP as will be shown later :-)
   
 
== Growing the Application ==
 
== Growing the Application ==
   
  +
So how do we grow this tiny application to "Enterprise" scale? Read on:
  +
  +
* Simple File Storage
 
* Logging
 
* Logging
 
* Testing
 
* Testing
Line 85: Line 179:
 
* Time
 
* Time
 
* UI
 
* UI
  +
* Performance Monitoring (Dashboard)
* Databases
 
* Client/Server
+
* Automatic Server Scaling
  +
* Complex Event Processing
  +
* (Multiple) Databases (Separating Online and Reporting)
  +
* Client/Server (Haste etc.)
  +
* Humble "File in Directory" Events
 
* Reporting
 
* Reporting
  +
* Business Workflow
 
* Remove Control
 
* Remove Control
 
* Event Sourcing
 
* Event Sourcing
 
* Event Bus
 
* Event Bus
  +
* Security (Event Pattern Based)
  +
* Interop with non-Haskell applications
   
 
== Questions and feedback ==
 
== Questions and feedback ==

Latest revision as of 08:53, 4 July 2014

Introduction

An event driven application/architecture is an application/architecture that is driven by internal/external events. Most non-trivial applications/architectures (from Operating Systems to Web Servers and Enterprise applications) are event driven.

Examples of events are:

  • A Loan Application has been accepted/rejected (commercial business).
  • A new Rostering Schedule is ready for distribution to all crew (Airline Management System).
  • An Illegal Trade Pattern has been detected (Trading Fraud Detection System).
  • A simulated car has hits another simulated car (Commercial Racing Game).
  • A robot has reached its destination (Real Time Warehouse Management System).
  • A HTML message has been received (Web Server).
  • A key has been pressed (Text Editor).

The examples demonstrate that events can be anything from high level business events ("A loan application accepted/rejected") to low level events ("User pressed key").

In the following, I will show a way to architecture a Haskell system so that it can scale from small "toy" applications (dealing with low level IO events) to large scale, high volume, distributed, fault tolerant "Enterprise" scale applications.

Please note that the following is not the only way to attack the problem. So please contribute your (clearly superior of course) alternative way to do it here: Real World Applications

Events in Haskell

In the following, I define an "Event" to be a value describing something that has happened in the past. And yes this should really be called an "Event Notification" but life is too short :-)

Here is a straightforward way to define Events in Haskell:

data Event =
    EventUserExit            -- User wants to exit
  | EventUserSave            -- User wants to save
  | EventUserSaveAs String
  | EventUserUndo            -- User wants to undo
  | EventUserRedo            -- User wants to redo
  deriving(Eq,Show)

Events can be high level or low level depending on how "low level" in the system you are operating. Within a UI sub-system the events are typically low level (key pressed, window closed). In a large scale distributed system the events are typically high level business events (EventCustomerCreated <details>).

A Tiny Event Driven Haskell Application

Let's warm up with a tiny toy event driven Haskell application. In this case, an event driven calculator that can add numbers and exit. Not very exciting but it is useful for introducing a number of key concepts.

I will in the following use the term "Domain" to stand for the application state. Fell free to use "Shipping" instead of Domain if your application area is shipping or "Game" if your domain is a game application. More info here: Domain Model.

Here is the Domain for the calculator application:

module Main where

data Domain =
  Domain Int
  deriving(Eq,Show)

The calculator state simply keeps track of the current value.

The next step is to define the events that the user can generate:

data Event =
    EventAdd Int
  | EventExit
  deriving(Eq,Show)

In this case all the user can do is to add and exit.

With those two definition, we can now write the "domain update" function. It simply takes the current state of the domain and an event as input and outputs the updated domain:

dmUpdate :: Domain -> Event -> Domain

dmUpdate (Domain v) (EventAdd a) = Domain (v + a)

dmUpdate dm _ = dm

For this tiny toy example all we can do is to react to the EventAdd event and calculate the new value.

The next step is to write the UI. For now it doesn't really matter how the UI is implemented. All that matters is that it can somehow present the Domain to a user and get user events back (More on this later):

uiUpdate :: Domain -> IO [Event]

uiUpdate (Domain v) = do
  putStrLn $ "Value is now: " ++ show v
  if v < 3 then
    return [EventAdd 1]
  else
    return [EventExit]

For this tiny toy example the UI will not even read from stdin. It instead return EventAdd events until the Domain state value is >= 3. After which it generates the EventExit event. Yes it is just a tiny toy example :-)

Given dmUpdate and uiUpdate we can now write what is traditionally called the "Event Loop". The event loop is the beating heart of an event driven application:

run :: Domain -> [Event] -> IO ()

run dm [] = do
  events <- uiUpdate dm
  run dm events

run _ (EventExit:_) =
  return ()

run dm (e:es) =
  run (dmUpdate dm e) es

For this tiny toy example, the event loop simply asks the UI for new events. And updates the domain when events are available. It exits when EventExit is received from the UI.

And here is the main function to bootstrap the event loop:

main :: IO ()
main = run (Domain 0) []

main simply creates a new domain (Domain 0) and calls run with an empty event list to get started.

The result of running the application is:

Value is now: 0
Value is now: 1
Value is now: 2
Value is now: 3

Consequences

The tiny application above is simple. However a number of key choices have been made that will profoundly shape how the application scales from this tiny application to "Enterprise" level:

UI depends on Domain - Domain does not depend on UI. This is the complete opposite of how most applications are (wrongly) developed.

UI can be swapped without changing Domain. Try that with your average application.

dmUpdate is not generating any events. However in a more realistic application, updating the domain will typically result in additional events being generated.

Domain is pure. All the goodness of functional programming. The idea is to keep as much of the code UI independent.

Domain can be tested without the UI. No need to setup Database to test.

The Domain API is Value based not API based. Events can be queued, recorded, distributed and replayed.

Events can (should) be asynchronous.

And by the way, this is not MVC/MVP as will be shown later :-)

Growing the Application

So how do we grow this tiny application to "Enterprise" scale? Read on:

  • Simple File Storage
  • Logging
  • Testing
  • Crash Recovery
  • Undo/Redo
  • Time
  • UI
  • Performance Monitoring (Dashboard)
  • Automatic Server Scaling
  • Complex Event Processing
  • (Multiple) Databases (Separating Online and Reporting)
  • Client/Server (Haste etc.)
  • Humble "File in Directory" Events
  • Reporting
  • Business Workflow
  • Remove Control
  • Event Sourcing
  • Event Bus
  • Security (Event Pattern Based)
  • Interop with non-Haskell applications

Questions and feedback

If you have any questions or suggestions, feel free to mail me.