Each generation is called upon to follow its own quest.

Etienne Navarre – Ladyhawke (1985)
Image from onebauer.media

Introduction

FIWARE is an open source initiative defining a universal set of standards for context data management which facilitate the development of Smart Solutions for different domains such as Smart Cities, Smart Industry, Smart Agrifood, and Smart Energy [1].

In any smart solution there is a need to gather and manage context information, processing that information and informing external actors, enabling them to actuate and therefore alter or enrich the current context. The FIWARE Context Broker component is the core component. It enables the system to perform updates and access to the current state of context [1].

The Context Broker in turn is surrounded by a suite of additional platform components, which may be supplying context data (from diverse sources such as a CRM system, social networks, mobile apps or IoT sensors for example), supporting processing, analysis and visualization of data or bringing support to data access control, publication or monetization [1].

What is context information?

Initially we will describe at how researchers have attempted to define context in the past. While most people tacitly understand what context is, they find it hard to elucidate. Previous definitions of context are done by enumeration of examples or by choosing synonyms for context [2].

In the work that first introduces the term ‘context-aware,’ Schilit and Theimer refer to context as location, identities of nearby people and objects, and changes to those objects. These types of definitions that define context by example are difficult to apply. When we want to determine whether a type of information not listed in the definition is context or not, it is not clear how we can use the definition to solve the dilemma [2].

Other definitions have simply provided synonyms for context; for example, referring to context as the environment or situation. As with the definitions by example, definitions that simply use synonyms for context are extremely difficult to apply in practice [2].

The definitions by Schilit et al. and Pascoe are closest in spirit to the operational definition we desire. Schilit claims that the important aspects of context are: where you are, who you are with, and what resources are nearby.

Pascoe defines context to be the subset of physical and conceptual states of interest to a particular entity. These definitions are too specific. Context is all about the whole situation relevant to an application and its set of users. We cannot enumerate which aspects of all situations are important, as this will change from situation to situation [2].

Anind K. Dey provides the following definition:

Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves [2].

Anind K. Dey

If a piece of information can be used to characterize the situation of a participant in an interaction, then that information is context [2].

Take the canonical context-aware application, an indoor mobile tour guide, as an example. The obvious entities in this example are the user, the application and the tour sites. We will look at two pieces of information – weather and the presence of other people – and use the definition to determine whether either one is context [2].

The weather does not affect the application because it is being used indoors. Therefore, it is not context. The presence of other people, however, can be used to characterize the user’s situation. If a user is traveling with other people, then the sites they visit may be of particular interest to her. Therefore, the presence of other people is context because it can be used to characterize the user’s situation [2].

Context aware computing

Context-aware computing was first discussed by Schilit and Theimer in 1994 to be software that adapts according to its location of use, the collection of nearby people and objects, as well as changes to those objects over time [2].

Anind K. Dey provides the following definition for context aware computing:

A system is context-aware if it uses context to provide relevant information and/or services to the user, where relevancy depends on the user’s task.

Anind K. Dey

Similar to the problem of defining context-aware, researchers have also tried to specify the important features of a context-aware application. Again, these features have tended to be too specific to particular applications [2].

The categorization combines the ideas from previous taxonomies and attempts to generalize them to satisfy all existing context-aware applications. There are three categories of features that a context-aware application can support [2]:

1. presentation of information and services to a user
2. automatic execution of a service for a user
3. tagging of context to information to support later retrieval

Features of a context aware app

It encapsulates changes and the impact of changes, so applications do not need to be modified. A context related functionality is responsible for acquiring a certain type of context information and it makes that information available to the rest of the system in a generic manner, regardless of how it is actually sensed [2].

An example is interpreting context from all the devices in a conference room to determine that a meeting is occurring. For example, an indoor infrared positioning system may consist of many infrared emitters and detectors in a building. The sensors must be physically distributed and cannot all be directly connected to a single machine [2].

Context aggregators aggregate context. We defined context as information used to characterized the situation of an entity. A context aggregator, is responsible for all the context for a single entity. Aggregators gather the context about an entity (e.g., a person), behaving as a proxy for other applications [2].

What is NGSI?

The FIWARE NGSI (Next Generation Service Interface) API defines:

• a data model for context information, based on a simple information model using the notion of context entities [3]
  
• a context data interface for exchanging information by means of query, subscription, and update operations [3]
  
• a context availability interface for exchanging information on how to obtain context information (whether to separate the two interfaces is currently under discussion) [3]

Context entities, are the center of gravity in the FIWARE NGSI information model. An entity represents a thing, i.e., any physical or logical object (e.g., a sensor, a person, a room, an issue in a ticketing system, etc.). Each entity has an entity id. Furthermore, the type system of FIWARE NGSI enables entities to have an entity type. Entity types are semantic types; they are intended to describe the type of thing represented by the entity. For example, a context entity with id sensor-365 could have the type temperatureSensor. Each entity is uniquely identified by the combination of its id and type [3].

Context attributes are properties of context entities. For example, the current speed of a car could be modeled as attribute current_speed of entity car-104. In the NGSI data model, attributes have an attribute name, an attribute type, an attribute value and metadata.

• The attribute name describes what kind of property the attribute value represents of the entity, for example current_speed [3]
  
• The attribute type represents the NGSI value type of the attribute value. Note that FIWARE NGSI has its own type system for attribute values, so NGSI value types are not the same as JSON types [3]
  
• The attribute value finally contains
  • the actual data
  • optional metadata describing properties of the attribute value like e.g. accuracy, provider, or a timestamp [3]

The API response payloads in this specification are based on application/json and (for attribute value type operation) text/plain MIME types. Clients issuing HTTP requests with accept types different than those will get a 406 Not Acceptable error.

What is a (Orion context) broker?

A message broker is an architectural pattern for message validation, transformation, and routing. It mediates communication among applications, minimizing the mutual awareness that applications should have of each other in order to be able to exchange messages, effectively implementing decoupling.[4]

The primary purpose of a broker is to take incoming messages from applications and perform some action on them. Message brokers can decouple end-points, meet specific non-functional requirements, and facilitate reuse of intermediary functions. For example, a message broker may be used to manage a workload queue or message queue for multiple receivers, providing reliable storage, guaranteed message delivery and perhaps transaction management. The following represent other examples of actions that might be handled by the broker [4]:

• Route messages to one or more destinations
• Transform messages to an alternative representation
• Perform message aggregation, decomposing messages into multiple messages and sending them to their destination, then recomposing the responses into one message to return to the user
• Interact with an external repository to augment a message or store it
• Invoke web services to retrieve data
• Respond to events or errors
• Provide content and topic-based message routing using the publish–subscribe pattern

Message brokers are generally based on one of two fundamental architectures: hub-and-spoke and message bus. In the first, a central server acts as the mechanism that provides integration services, whereas with the latter, the message broker is a communication backbone or distributed service that acts on the bus. Additionally, a more scalable multi-hub approach can be used to integrate multiple brokers [4] .

So, Orion is a C++ implementation of the NGSIv2 REST API binding developed as a part of the FIWARE platform. The Orion context broker allows us to manage the entire lifecycle of context information including updates, queries, registrations and subscriptions. Using the Orion Context Broker, you are able to create context elements and manage them through updates and queries. In addition, you can subscribe to context information so when some condition occurs (e.g. the context elements have changed) you receive a notification [5].

The next episode

We will provide detailed information about the Orion context broker, and how to communicate with it a C# client.

References

[1]. https://www.fiware.org/developers/

[2]. Understanding and Using Context, Anind K. Dey, Future Computing Environments Group, College of Computing & GVU Center, Georgia Institute of Technology, Atlanta, GA, 30332-0280, USA

[3]. https://fiware.github.io/specifications/ngsiv2/stable/

[4]. https://en.wikipedia.org/wiki/Message_broker

[5]. https://fiware-orion.readthedocs.io/en/latest/