Created by lissensj on May 21, 2014

Qeo Behavior Types

From a Qeo point of view, there are only two types of information: State and Event. Every Qeo Topic is associated with one of those information types, and the information type defines the Behavior of the Topic, i.e. the contract to which the middleware adheres with respect to information published on the Topic.

State

About States

State Topics are used to represent the current state of (physical or logical) entities in the domain. Different kinds of entities are modelled as different data types, and hence as different Qeo Topics. 

Within a single Topic, there may be multiple instances of the same kind of entity. These are distinguished by their respective values for the Key fields of that Topic.

Instance Life Cycle

Instances have a life cycle: they spring into existence the first time a publisher publishes a value for this instance (i.e. this specific combination of Key field values), subsequent publications for the instance update the globally visible instance state, and finally instances disappear either because they were explicitly removed by their publisher, or because their publisher itself disappears.

Local cache and updates

For each Subscriber, Qeo maintains a local cache reflecting the contents of the Topic. Subscribers may iterate through, or perform lookups in, this cache. The local cache is a Subscriber's interface to the Topic. Local caches are update asynchronously by Qeo, and Subscribers can choose to receive one of two kinds of update notifications:

▪    A simple "something changed" notification. This is useful for Subscribers that treat their local cache as a kind of lazy shared memory, where they perform lookups on an as-needed basis.

▪    A more elaborate notification that triggers a callback for each changed instance, providing the current instance state. This is more useful for Subscribers that implement a state machine based on the updates of the global state of one or more Topics.

Contract

State Topics abide by the following contract:

▪    Every instance is, at any point in time, exclusively owned by a single publisher. Over time, the actual owner of a particular instance may change, but there will never be two Publishers at the same time that can publish updates for a given instance.

▪    Subscribers will eventually know the latest value for each instance on the Topic. This is true even if this latest value was published before the Subscriber subscribed to the Topic.

▪    Subscribers will not be aware of any instances that had already disappeared before they subscribed to the Topic.

▪    Subscribers will not necessarily be notified of every individual update to an instance's value: when updates occur in rapid succession, a Subscriber may only see the aggregated result of the updates.

▪    There is no global synchronization between Subscriber's local caches: there are no guarantees that all Subscribers will have the exact same view on the Topic at a given point in time. When the Topic has been stable for a sufficiently long time (i.e. the latest publications for all instances have been propagated to all Subscribers), the contents of all local caches will eventually line up.

Event

About Events

Event Topics are used to model discrete events. Whereas State Topics model facts that hold true for a longer period of time (e.g. whether a door is open or closed), Event Topics model facts that occur at a particular point in time (e.g. someone is passing through the door). A single Event Topic models a single kind of event that can occur in the system.

Event Topics do not hold separate instances: they just represent a continuous stream of events. Hence, Event data types have no Key fields. Of course, the fields that are in the Event data type can be used to distinguish events on a more detailed level (e.g. "person X passed through door Y"), but this is an application concern: the middleware itself does not interpret event publications to that level of detail.

No Local Cache

Event Subscribers will not hold a local cache of events. Rather, they will be notified immediately upon arrival of an event of that event's value. It is up to the application writer to store events for later processing or retrieval if there is a need for this kind of functionality.

Contract

Event Topics abide by the following contract:

  • Events published before a Subscriber subscribed to the Topic are lost to that Subscriber.
  • Once the subscription is made, and the subscription has been propagated to all Publishers, a Subscriber will reliably receive all events on this Topic.
  • Every Subscriber will only be notified of every event once.
  • Events have partial ordering: publications coming from the same publisher will arrive in the order of publication, but there is no guarantee with respect to the ordering of events that were published by different Publishers. This means that not every Subscriber will see all events arriving in the same order.
Icon

In any distributed system, there is some communication latency. Because of this latency, it may take a small amount of time for a Subscriber to be discovered by all relevant Publishers. During this time window, publications on the Topic may be lost to the Subscriber.

The reverse is also true: when a new Publisher starts, it takes some time to discover all relevant Subscribers. If the Publisher writes some events to the Topic before all Subscribers have been discovered, these events will go lost on the as-yet-undiscovered Subscribers.

Fortunately, the time windows involved are very small (on the scale of milliseconds).

Take this into account when designing your system: it does not make sense to create a short-lived publisher (e.g. a process that starts up, publishes one event and immediately shuts down). The reliability of event distribution is only guaranteed in steady-state operation.