Study: EventSourcing

This page study the way of using Swiffer as an EventSourcing and dispatching system.

Motivation

• having a distributed publish-subscribe mechanism for application events
• guarantee that one event is only processed one time (not several), and not

User API

Posting events:

swiffer.dispatchEvent(new UserLoggedInEvent(user))

Listening to events:

public class MyApplicationEventHandlers {

     @Subscribe
     public void onUserLoggedIn(UserLoggedInEvent e) throws Exception {
         //do your business logic here...
         //any exception thrown would lead to reprocessing the event
     }
}

public static void main(){
   final Swiffer swiffer = ... ;
   final Worker worker = swiffer.newEventHandler(new MyApplicationEventHandlers ());
   worker.start();// non-blocking methods that start polling and executing activity tasks
   worker.stop();// non-blocking
}

Implementation

• swiffer.dispatchEvent should just send a signal, containing a wrapper object (EventDispatchedSignal) containing the event
• a decider should treat EventDispatchedSignal like follows: ** retrieve from the workflow state, the list of registered handlers
  ** for each registered Handlers, publish an ActivityScheduleEvent to the corresponding tasklist
• to handle the event, a special worker is listening to the tasklist of the event **it receive an ActivityTask of type

Main operations