We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.ArchitectureDescription.Data.ContextBroker - FIWARE Forge Wiki


From FIWARE Forge Wiki

Jump to: navigation, search



Legal Notice

Please check the following FIWARE Open Specification Legal Notice (implicit patents license) to understand the rights to use these specifications.


Introduction to the FIWARE Context Broker GE

The FIWARE Context Broker GE will enable publication of context information by entities, referred as Context Producers, so that published context information becomes available to other entities, referred as Context Consumers, which are interested in processing the published context information. Applications or even other GEs in the FIWARE platform may play the role of Context Producers, Context Consumers or both. Events in FIWARE based systems refer to something that has happened, or is contemplated as having happened. Changes in context information are therefore considered as events that can be handled by applications or FIWARE GEs.

The FIWARE Context Broker GE supports two ways of communications: push and pull towards both Context Producers and the Context Consumers. It does mean that a Context Producer with a minimal or very simple logic may continuously push the context information into the Context Broker, when the information is available or due to the internal logic of the Context Producer. The Context Broker on its side can request the context information from Context Producers if they provide the ability to be queried (Context Producers able to act as servers are also referred as Context Providers). In a similar way, Context Consumers can pull the context information from the Context Broker (on-request mode), while the Context Broker can push the information to Contest Consumer interested in it (subscription mode).

A fundamental principle supported by the FIWARE Context Broker GE is that of achieving a total decoupling between Context Producers and Context Consumers. On one hand, this means that Context Producers publish data without knowing which, where and when Context Consumers will consume published data; therefore they do not need to be connected to them. On the other hand, Context Consumers consume context information of their interest, without this meaning they know which Context Producer has published a particular event: they are just interested in the event itself but not in who generated it. As a result, the FIWARE Context Broker GE is an excellent bridge enabling external applications to manage events related to the Internet of the Things (IoT) in a simpler way hiding the complexity of gathering measures from IoT resources (sensors) that might be distributed or involving access through multiple low-level communication protocols.

Target usage

The FIWARE Context Broker is a GE of the FIWARE platform that exposes the (standard) interfaces for retrieval of the context information, events and other data from the Context Producers to the Context Consumers. The consumer doesn’t need to know where the data are located and what is the native protocol for their retrieval. It will just communicate to the Context Broker GE through a well-defined interface specifying the data it needed in a defined way: on request or on subscription basis. The Context Broker GE will provide the data back to the consumer when queried, in case of "on-request", or when available, in case of "on-subscription" communication mode.

Basic Concepts

All the communications between the various components of the Context Broker high-level architecture occur via the FIWARE NGSI RESTful interface, which is described in a high-level within the following sections. The FIWARE NGSI RESTful interface is inspired and based on the OMA NGSI specification [3]. This is a standard interface allowing to handle any type of data, which may include meta-data.

Context Elements

Aligned with the standard OMA NGSI specification, Context Information in FIWARE is represented through generic data structures referred to as Context Elements. A Context Element refers to information that is produced, collected or observed that may be relevant for processing, carrying out further analysis and knowledge extraction. It has associated a value defined as consisting of a sequence of one or more <name, type, value> triplets referred to as context element attributes. FIWARE will support a set of built-in basic data types as well as the possibility to define structured data types: vectors and key-maps (which elements can be other vectors, key-maps or simple data types).

A Context Element typically provides information relevant to a particular entity, being it a physical thing or part of an application. As an example, a context element may contain values of the “last measured temperature”, “square meters” and “wall color” attributes associated to a room in a building. That's why they typically contain an EntityId and an EntityType uniquely identifying the entity. Finally, there may be meta-data (also referred to as semantic data) linked to attributes in a context element. However, the existence of meta-data linked to a context element attribute is optional.

In summary, context information in OMA NGSI is represented through data structures called context elements, which have associated:

  • An EntityId and EntityType, uniquely identifying the entity to which context data refers.
  • A sequence of one or more data element attributes (<name, type, value> triplets)
  • Optional meta-data linked to attributes (also <name, type, value> triplets)

As an example, we may consider the context element linked to updates on:

  • attributes “speed”, “geolocation”, “current established route” of a “car”, or
  • attributes “message geolocation”, “message contents” of a “user”

The EntityId is a string, and can be used to designate “anything”, not necessarily “things” in the “real world” but also application entities.

A cornerstone concept in FIWARE is that context elements are not bound to a specific representation formalism. As an example, they can be represented as:

  • an XML document (SensorML, ContextML, or whatever)
  • a binary buffer being transferred
  • as an entry in RDBMS table (or a number of entries in different tables),
  • as a number of entries in a RDF Repository
  • as entries in a NoSQL database like MongoDB.

A key advantage of this conceptual model for context elements is its compliance with IoT formats (SensorML) while enabling further extensions to them.

Basic Actors in the Context Broker GE Model

Context Broker

As already mentioned the Context Broker (CB) is the main component of the architecture. It works as a handler and aggregator of context data and as an interface between architecture actors. Primarily the CB has to control context flow among all attached actors; in order to do that, the CB has to know every Context Provider (CP) in the architecture; this feature is done through an announcement process detailed in the next sections.

Typically, the CB provides a Context Provider Lookup Service and a Context Persistence Service.

Context Producer

A Context Producer (CP) is an actor able to generate context. The basic Context Producer is the one that spontaneously updates context information, about one or more context attributes according to its internal logic. This communication from the CP to the CB is in push mode.

Context Producers can work also in pull base way, in which case they are referred as Context Providers.

Context Provider

A Context Provider (CPr) is an specialised kind of Context Producer actor, which provides context information on demand, in synchronous mode; that means that the Context Broker or even the Context Consumer can invoke the CP in order to acquire context information. A CP provides context data only further to a specific invocation. Moreover, a CP can produce new context information inferred from the computation of input parameters; hence it is many times responsible for reasoning on high-level context information and for sensor data fusion. Every CP registers its availability and capabilities by sending appropriate announcements to the CB and exposes interfaces to provide context information to the CB and to Context Consumers.

Context Consumer

A Context Consumer (CC) is an entity (e.g. a context based application) that exploits context information. A CC can retrieve context information sending a request to the CB or invoking directly a CP over a specific interface. Another way for the CC to obtain information is by subscribing to context information updates that match certain conditions (e.g., are related to certain set of entities). The CC registers a call-back operation with the subscription for the purpose, so the CB notifies the CC about relevant updates on the context by invoking this call-back function.

Finally, some kind of Context Consumer may expose update context operations to be invoked by CB. This is mainly related with actuation capabilities, i.e. the update at Context Consumer produces a given actuation, e.g. turn on/off a lamp.


Every exchange of context data here is referred to a specific entity, which can be in its order a complex group of more than one entity. An entity is the subject (e.g. user or group of users, things or group of things, etc.), which context data refer to. It is composed of two parts: a type and an identifier. Every Context Provider supports one or more entity types and this information is published to the Context Broker during an announcement process described later.

A type is an object that categorizes a set of entities; for example entity types are:

  • human users - identified by username;
  • mobile devices - identified by imei;
  • mobile users - identified by mobile (GSM phone number);
  • groups of other entities - identified by groupid;

Conceptual Decoupling

Context and data distribution is the process through which information is distributed and shared between multiple data and context producing and consuming entities in a context(data)-aware system. For efficient data/context management, including context/data distribution, it is imperative to consider communication schemes with respect to the decoupling they provide. Various forms of decoupling are supported:

  • Space Decoupling: The interacting parties do not need to know each other. The publishers (providers) publish information through an event/information service and the subscribers (consumers) receive information indirectly through that service. The publishers and subscribers do not usually hold references to each other and neither do they know how many subscribers/publishers are participating in the interaction.
  • Time Decoupling: The interacting parties do not need to be actively participating in the interaction at the same time i.e., the publisher might publish some information while the subscriber is disconnected and the subscriber might get notified about the availability of some information while the original publisher is disconnected.
  • Synchronization Decoupling: Publishers are not blocked while producing information, and subscribers can get asynchronously notified (through call-backs) of the availability of information while performing some concurrent activity i.e. the publishing and consumption of information does not happen in the main flow of control of the interacting parties.

This decoupling is important to cater for because decoupling of production and consumption of information increases scalability by removing all explicit dependencies between the interacting participants. Removing these dependencies strongly reduces coordination requirements between the different entities and makes the resulting communication infrastructure well adapted to distributed environments. This advantage becomes more beneficial when mobile entities exist in a distributed system (owing to their limited resources, intermittent connectivity etc.).

Generic Architecture

The following figure shows a logical architecture of the Publish/Subscribe Context Broker GE with its main components and interactions with other actors.

Logical architecture of the Publish/Subscribe Context Broker GE

Main Interactions

Notions about OMA NGSI Specs

OMA NGSI (Next Generation Service Interface) Operations are grouped into two major interfaces:

  • NGSI-10
    • updateContext
    • queryContext
    • subscribeContext / unsubscribeContext / updateContextSubscription
    • notifyContext
  • NGSI-9
    • registerContext
    • discoverContextAvailability
    • subscribeContextAvailability / unsubscribeContextAvailability / updateContextAvailabilitySubscription
    • notifyContextAvailability

The FIWARE specification is an evolution/modification proposal of the OMA NGSI specification which aims to maximize the role of NGSI for massive data collection from the IoT world, where a myriad of IoT resources are providing context elements occurrence/updates involving low level protocols. In other words FIWARE NGSI is mainly the binding over OMA NGSI, however some small differences, out of scope of this documents, have been implemented in FIWARE NGSI with respect to OMA specification.

Note that the FIWARE NGSI Binding includes a set of operations (named "convenience operations" as opossed to the operations directly derived from NGSI OMA standard, which are referred as "standard operations"). Every convenience operation at the end is "mappable" to some standard operation thus we will use the later ones in the diagrams in next sections.

Basic Interactions and related Entities

The following diagram depicts the basic interactions of a Context Broker with its natural counterparts, that is the Context Producers/Providers and the Context Consumers.

  • Context Producers publish data/context elements by invoking the updateContext operation on a Context Broker.
  • Context Consumers can retrieve data/context elements by invoking the queryContext operation on a Context Broker
  • Context data pushed by a Context Producer is typically kept persistent by Context Brokers and ready to be queried. This is a distinguishing feature of the OMA Context Management model as compared to some Event Brokering or Event Notification standards.

Interactions related to query-able Context Producers (Context Providers)

Context Producers publish data/context elements by invoking the updateContext operation on a Context Broker. Some Context Producers (named Context Providers) may also export a queryContext operation Context Brokers may invoke as a result of forwarded queryContext from a Context Consumer in the case some registration is in place covering the Context Provider entities.

  • Context Consumers can retrieve data/context elements by invoking the queryContext operation on a Context Broker
  • The Context Broker forwards the query to the appropriated Context Provider and returns the result to the requesting Context Consumer

Interactions related to forwarded updates to Context Providers

A Context Broker is able to forward context updates to Context Providers able to process such events.

  • Context Producer can send a updateContext operation to a Context Broker
  • The Context Broker forwards the updateContext to the proper Context Provider

Interactions to force Context Consumers to subscribe to specific notifications

Some Context Consumers can be subscribed to reception of data/context elements which comply with certain conditions, using the subscribeContext operation a Context Broker exports. A duration may be assigned the subscriptions.

  • Subscribed consumers spontaneously receive data/context elements compliant with that subscription through the notifyContext operation they export
  • Note that the Application which subscribes a particular Context Consumer may or may not be the Context Consumer itself

Extended Operations: Registering Entities & Attributes availability

The registerContext operation in Context Brokers can be used not only for registering Context Providers on which queryContext operations can be invoked but also to register existence of entities in the system and availability of attributes.

  • Publish/Subscribe Context Brokers may export operations to discover entities or even attributes that have been registered in the system.

Extended Operations: Applications subscription to Entities/Attributes registration

Some applications can be subscribed to registration of entities or availability of attributes which comply with certain conditions. They do so by means of using the subscribeContextAvailability operation a Context Broker may export. A duration may be assigned to the subscriptions.

  • Subscribed applications spontaneously receive updates on new entities or attributes compliant with that subscription through the notifyContextAvailability operation they export
  • Note that the subscriber and subscribed applications may not be the same

Basic Design Principles

Context Persistence

Context updates received by the Context Broker (from a Context Source or as a result of a query to a Context Provider) is stored in a context database. If another Context Consumer requests the same context information to the Context Broker, it can be retrieved from the database. When the Context Broker has updated context as a result of a request to a Context Provider, it will typically cache that information for a configured time period (which may be zero, therefore forcing the Context Broker to query the Context Provider).

Context Broker persistence is only for the current context snapshot of the system. In other words, a Context Broker doesn't implement context history persistence. However, history context data can be archived using a Context Consumer in charge of such persistence in any data sink.


Context information can be very large (e.g. entities modeling the the sensor in a big city like London, Sao Paulo or Tokyo) thus a Context Broker should be designed with scalability in mind. Thus, the Context Broker processing logic should be as stateless as possible (to enable horizontal scaling) and the database technology used to implement context persistence should be scalable.


Entities could be associated to a given location (typically, GPS coordinates). Thus, a Context Broker must handle entities location and be able to support queries and subscriptions based on geo-location information, e.g. a Context Consumer getting the context information for all the entities within a given area defined by a polygon or circle.


The Context Consumer, Context Producer or Context Provider role may be played by another Context Broker, enabling federation scenarios. Thus, a Context Broker has to been able to process notifications coming from other Context Brokers (upstream federation). In addition, it has to been able to play the Context Provider role (downstream federation).


The result of synchronous request from Context Consumer can be very large, e.g. a list of 1,000,000 entities. Including so much information in a single response is not feasible. Thus, a Context Broker has to implement pagination mechanisms in its API in order to cope with this scenarios, so the information is split and retrieved in several blocks.


A Context Broker must implement Consumer/Producer isolation, so a set of Consumers/Producers cannot access to context belonging to other Consumers/Producers.


Although it is not required for Context Broker to implement security "natively", it must be feasible to integrate a Context Broker with FIWARE GEs (typically playing the PEP and PDP roles according to the XACML model) to secure the access to the FIWARE NGSI API it provides.



Weiser, M., "The computer for the 21st century", Human-computer interaction: toward the year 2000, Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 1995.


Moltchanov B., Knappmeyer M., Licciardi C. A., Baker N., 2008, “Context-Aware Content Shariing and Castiing”, ICIN2008, Bordeaux, France, UK, October 2008.


Open Mobile Alliance (OMA) Next Generation Services Interface (NGSI) Specification [1]

Personal tools
Create a book