Internal Event Sequencing Model - The FireFly Stream of Consciousness

[peterbroadhurst]

See #4 for info on why this is in Git

FireFly Internal Event Sequencing Model

One of the most important roles FireFly has, is to take actions being performed by the local apps, process them, get them confirmed, and then deliver back as "stream of consciousness" to the application alongside all the other events that are coming into the application from other FireFly Nodes in the network.

You might observe the problems solved in this architecture are similar to those in a message queuing system (like Apache Kafka, or a JMS/AMQP provider like ActiveMQ etc.).

However, we cannot directly replace the internal logic with such a runtime - because FireFly's job is to aggregate data from multiple runtimes that behave similarly to these:

• Private messaging in the Data Exchange
• The blockchain ledger(s) themselves, which are a stream of sequenced events
• The event dispatcher delivering messages to applications that have been sequenced by FireFly

So FireFly provides the convenient REST based management interface to simplify the world for application developers, by aggregating the data from multiple locations, and delivering it to apps in a deterministic sequence.

The sequence is made deterministic:

• Globally to all apps within the scope of the ledger, when a Blockchain ledger is used to pin events (see Multi-party Event Sequencing for Multi-Party Business Processes #10)
• Locally for messages delivered through a single FireFly node into the network
• Locally for all messages delivered to applications connected to a FireFly node, across blockchain