Qeo Open Source Project Documentation : Qeo Glossary

Actor

A Qeo Actor is an individual process or application that participates in Qeo interactions. In a distributed application, one may consider it as one component of the distributed application. Actors play one or more Roles.

App (Application)

An App or Application is an entity that either reads or writes to Qeo Topics. An App is installed on a Device, which is in turned owned by a User. 

Behaviour

A Behaviour is a contract that describes the semantics of a given Data Type. This contract describes whether published values are disseminated reliably, whether a subscriber is guaranteed to see all published values, etc. A Qeo Behaviour maps to a set of DDS QoS settings. In Qeo, two Behaviours have been defined: Event and State.

Event

Data Types with Event behaviour abide by the following contract:

• The data type is keyless;
• Data values published before a Reader subscribed to the type are lost to that Reader;
• Once a Reader is subscribed, it will reliably receive all values that are published for the type.

State

Data Types with State behaviour abide by the following contract:

• The data type may have a (set of) key field(s) to identify different instances on the same topic
• Subscribed Readers will eventually know the latest value for each instance of the Data Type. This is true even if this latest value was published before the Reader subscribed.
• Subscribed Readers will not necessarily be notified of each individual update to an instance's value: when updates occur in rapid succession, a Reader may only see the aggregated result.

Coarse-grained Policy Rules

A Coarse-grained Policy Rule grants a user wholesale access to all data on a topic for either reading, writing, or both. See also Policy (File).

(Data) Type

A Data Type is the basic unit of communication in Qeo. It is uniquely identified by its name (uniqueness is guaranteed through namespacing). A Data Type definition provides information on the type's syntax and semantics.

Data type syntax is formally defined in an XML format standardized by OMG. In essence, a data type is a composite type of arbitrary complexity, in which individual fields may carry annotations. These annotations aid in the interpretation of values of the type: they indicate which fields uniquely identify instances of the type, which fields are optional, what the default values are, etc.

In addition to the syntax definition, a Data Type will be associated with a well-known Behaviour (State, Event, ...), and potentially with some security annotations (yet to be defined). These define the semantics of the type. For more information, go to the Qeo System Description.

DDS

The Data Distribution Service (DDS) is a powerful standard for distributed publish/subscribe communications. It is standardized by the Object Management Group (OMG). Qeo is implemented as an abstraction layer on top of DDS.

Device

A Device is an entity that hosts or runs Applications. These Applications read or write to Qeo Topics. Devices can be headless or headed. See also Headless Device. 

Directed State Pattern

This is an interaction pattern that allows actors to drive the global system state further by expressing their wishes with respect to the state of some other actor.

The pattern defines two roles:

• The Effector is an actor that "owns" the state of some physical or logical entities. It publishes this state on the Current State topic.
• The Requester is an actor that wants to influence the state owned by the Effector. It publishes its wishes with respect to the Effector's state on the Desired State topic.

In essence, the Directed State pattern is the combination of two unidirectional Observer patterns:

• The Effector is the Subject for the Current State, but acts as Observer for the Desired State, and
• The Requester is the Observer of Current State, but the Subject of Desired State.

The Effector will observe the Requester's desires, and based on these desires it will decide how to evolve the entities it "owns". This evolution is then reflected in the Current State, which (ideally) evolves towards the Desired State.  For more information, go to Interaction Patterns.

Fine-grained Policy Rules

A Fine-grained Policy Rule restricts a user's access to a given topic. With these rules, you can express that a user may only see data on the topic that was published by certain users, or that the data that a user publishes on the topic can only be seen by certain other users. See also Policy (File).

Headless Device

A headless device is a special case of a Remote Device. It is a computer system or device that has been configured to operate without a monitor (the missing "head"), keyboard, and mouse. A headless system is typically controlled via a network connection, although some headless system devices require a physical connection to be made for administration of the device. Typically, users do not interact with these devices or use proprietary software on a dedicated system. Qeo allows interaction with these devices over any platform. 

However, given the fact that the user has no GUI or other way to interact with the device, the regular device registration procedure cannot work. For example, the user cannot provide an OTC to the device.

Key

A field or set of fields that uniquely identify an instance of a Data Type. Different data values with the same key represent successive values of a given instance, while different values with a different key represent different instances. If a Data Type does not have any key fields, all values are considered to be successive values of the same instance. For more information, go to Data-Centric Publish-Subscribe.

Manifest (File)

The manifest presents essential information about the application to the Android system. The system requires this information before it can run any of the application's code. Without a manifest file, an application will not run. For more information, go to Creating a Qeo Manifest File.

Module

Modules are namespaces that group data types belonging to the same domain. Their primary purpose is to avoid name clashes - when multiple parties are developing Data Types, use of the same names is unavoidable. By using modules, use of the same name is possible and names can thus be used by multiple parties in different contexts, as long as each party uses a different module. For more information, refer to Structure of a QDM.

Observer Pattern

This is the basic publish/subscribe interaction pattern. The pattern defines two roles:

• The Subject is either a source of events or an owner of state. The Subject publishes events or state updates on a Qeo Topic.
• The Observer is interested in a certain type of events or a certain kind of state. It subscribes to a Qeo Topic.

Note that there can be many Subjects and/or many Observers on the same Qeo Topic. Subjects are unaware of the Observers, and (barring explicit modeling in the published data type) Observers are unaware of specific Subjects. The flow of information in the pattern is unidirectional: if flows only from Subject to Observer.  For more information, go to Interaction Patterns. 

Publisher

A synonym for Writer.

Policy (File)

The policy file determines the access a user (and therefore all Applications running on Devices owned by that user) has; in other words, which Qeo Topics that user can access. It can contain coarse-grained and fine-grained rules. 

QDM

A Qeo Data Model (QDM) is a (mostly) formal definition of the canonical way to describe a certain subject matter (e.g. Temperature, Media, Communication Sessions, WiFi Diagnostics, ...) on Qeo. It consists of a formal description (in XML format) of a set of Data Types related to the QDM subject matter. This description extends beyond the syntax of the Data Types, and incorporates the semantics as well.

In addition to the formal (i.e. computer-readable) part of the description, there is also a more informal, human-readable documentation part that describes the meaning of the Data Type fields, and the relation and interactions between the different Data Types described in the QDM.

For example, the QDM for temperature might contain a Type for temperature sensors, but also Types that describe a thermostat (a state and a request type in typical directed state fashion). The human-readable part of the QDM will then describe the typical roles in the system (thermostat-effector and requester), and how publications of request values should lead to changes of the thermostat's state value.

For more information, go to Qeo Data Model (QDM) Developer Guide.

Qeo

Qeo is a cross-platform framework for distributed communication. It is based on the data-centric publish/subscribe paradigm.

Qeo Forwarder

A Qeo forwarder is an entity in a Realm that extends the wireless domain so a Qeo device does not have to be physically on the same wireless LAN in order to be able to interact within a Realm. For more information, go to Introduction to the Qeo Forwarder.

Reader

A Reader is an entity that subscribes to a specific Topic.

The Reader is an abstract concept in Qeo: in practice there will be a concrete Reader class for each kind of defined Behaviour (e.g. StateReader, EventReader, ...). The API of these individual Reader classes will reflect the different semantics and possibilities of the corresponding behaviours. For more information, go to Writers.

Realm

A realm is a set of users, devices and applications that can exchange information via Qeo Topics.

The Open Realm is a special kind of realm. It requires no user/device authentication and the information exchanged on it via Qeo Topics is not encrypted. Its sole use is for the Remote Registration procedure.

Redistribution (Policy Redistribution)

A policy file is distributed over Qeo to each device within a Realm. Each time a policy file is updated (e.g. by editing the user policy, adding a user or adding a device), the updated file is distributed again so devices always have the latest available policy file. This is called policy redistribution.

Remote Device

A remote device is a device to which the Realm Administrator has no direct access. A special case is a headless device. Typical for a remote device is that a user of a remote device cannot or will not manually enter the OTC. For more information, go to Remote Registration procedure.

Role

A Role is a well-defined set of responsibilities that can be taken up by an Actor in a distributed application. For example, in a Directed State pattern, one Actor will play the role of Effector, while the other will play the Role of Requester. Usually though, the concept of Roles is defined on a slightly higher plane of abstraction. For example, in the Video Call application, one could discern the Roles of Session Participant (a party that takes part in the communication session), Media Endpoint (a source or sink of media, like a webcam or a speaker) and Media Manager (entity that chooses which endpoints will be used by which participants in the call).

An Actor can play multiple Roles at the same time (e.g. in the Video Chat example, an calling application will most likely implement all three of the roles, whereas a STB+webcam combo might implement only the Media Endpoint role).

For each Role, one can specify an exact list of Topics to which an Actor must be subscribed, and an exact list of Topics onto which it should publish.

Sample

A Sample is the unit of publication in Qeo. For Event types, each new event value is a sample. For State types, every incoming state value (whether it is a new instance, or a new value for an existing instance) is a sample. Disposal notification are samples as well, although they hold not useful value.

Security Management Server (SMS)

The Security Management Server  is the central management entity in the Qeo security system. It is used to set up, configure and manage Realms. The SMS is located here: http://my.qeo.org/.

Struct

A struct represents a physical or logical entity with a certain behavior and a number of properties. These properties are represented by members (see below). Structs either have a behavior or not. Structs without behavior cannot stand alone, but can be used as members in a larger struct. Structs with behavior can be published on Qeo. 

Subscriber

A synonym for Reader. 

Topic

A Topic is a synonym for a Data Type. It is just more convenient to use the word Topic in sentences like "subscribing to a Topic".

User

A User is an entity within a Qeo Realm that groups one or more Devices. 

Writer

A Writer is an entity that publishes data of a specific Data Type. The Writer is an abstract concept in Qeo; in practice there will be a concrete Writer class for each kind of defined Behaviour (e.g. StateWriter, EventWriter, ...). For more information, go to Writers.