Problems with a Distributed Environment
As stated before, Qeo's goal is to enable the sharing of information between devices. There are, however, a number of factors complicating this:
- Initially, which entities will be interested in the provided information is unknown.
- The composition of the network is highly variable: portable devices may come and go, even static devices may be powered on or off at the whim of the user.
- The network may be unreliable and slow (wireless networks with bad reception, devices going to sleep...).
The Publish/Subscribe Paradigm
The publish/subscribe paradigm, adopted by Qeo, can alleviate a lot of these problems. It introduces the notion of a Topic as a logical channel that groups related information. Information providers (henceforth called Publishers) publish information on a Topic, while information consumers (henceforth called Subscribers) subscribe to a Topic. By subscribing to a Topic, Subscribers will receive all the information that is published on the Topic.
This setup conceptually decouples Publishers and Subscribers in
- Space: Publishers and Subscribers needn't be aware of each other's location or addressing information. They needn't even be aware of each other's existence.
- Time: there is no synchronization between Publishers and Subscribers. Publishers write to the Topic whenever they have some information to share, Subscribers consume information from the Topic at their leisure. Depending on the behavioural configuration of the Topic, Publishers and Subscribers needn't even be active at the same time for communication to succeed.
Data-centricity
The plain publish/subscribe paradigm does not attach any meaning to the actual content of the messages it disseminates: it is up to the subscriber to make sense of them. Qeo goes one step further: it implements the data-centric publish/subscribe pattern.
The key insight in data-centricity is that Publishers are basically exposing their state to the world, while Subscribers are trying to reconstruct this state from the messages they receive. In data-centric communication, the middleware does not distribute messages about the state, but rather it maintains a global view of the state on behalf of the information consumers.
For data-centric publish/subscribe, this translates to the following:
- Topics have an associated data type, and represent only objects of this type
- Publishers write the current state of an object to the Topic
- The middleware ensures that Subscribers get a consistent view of the objects published on the Topic
This approach is directly beneficial for the efficiency of communication, as the middleware can now interpret the meaning of messages that are sent, and (based on the behavioural configuration of the Topic) decide to drop certain messages that are not (or no longer) relevant.
There is an even more important advantage to data-centricity: it promotes the reusability of the information that is shared. Instead of sending out messages that are relevant only to a particular use case, the information providers in a data-centric world publish facts about the world, and any information consumer can interpret those facts and derive from them the information it needs.
Topics and Data Types in Qeo
In Qeo, Topics and Data Types are tightly coupled. For each Topic, a specific Data Type is designed. These data types reside in a namespace (e.g. org.qeo.wifi) and have a name (e.g. Station). The fully qualified name of the data type (e.g. org.qeo.wifi.Station) is used as the Topic identifier, thus ensuring a one-to-one correspondence between Topics and Data Types.
Instances and Keys
Data Types are defined as composite (and possibly nested) structures. A subset of the fields of a data type may be marked as Key fields. Analogous to relational databases, this means that the combination of the values of these fields serves to uniquely identify an object instance on the Topic. Multiple publications on the Topic that have the same key fields are considered sequential updates of the state of a single object. Data types may also be keyless, which means that all values published to the Topic are considered to be subsequent updates of the singular object instance on this Topic.
Qeo Data Model (QDM)
Qeo is not tied to a particular programming language. In order to facilitate the reuse of data types across implementation languages, data types can be defined in a language-independent XML description language. Such an XML data type description is called a Qeo Data Model (QDM).
Code generators translate these descriptions into language-specific data structures.