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.OpenSpecification.Data.ContextBroker - FIWARE Forge Wiki

FIWARE.OpenSpecification.Data.ContextBroker

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Data.ContextBroker
Chapter Data/Context Management,
Catalogue-Link to Implementation Orion Context Broker
Owner Telefonica I+D, Fermin Galan (TID)


Contents

Preface

Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.

Copyright

Legal Notice

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

Overview

Introduction to the Publish/Subscribe Context Broker GE

The Publish/Subscribe 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 Publish/Subscribe Context Broker GE supports two ways of communications: push and pull towards both the Context Producer and the Context Consumer. It does mean that a Context Producer with a minimal or very simple logic may continuously push the context information into the Publish/Subscribe Context Broker, when the information is available or due to the internal logic of the Context Producer. The Publish/Subscribe 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 Publish/Subscribe Context Broker (on-request mode), while the Publish/Subscribe Context Broker can push the information to Contest Consumer interested in it (subscription mode).

A fundamental principle supported by the Publish/Subscribe 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 Publish/Subscribe 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 Publish/Subscribe 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 or Data/Event Producers to the Context or Data/Event 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 Publish/Subscribe Context Broker GE through a well-defined interface specifying the data it needed in a defined way: on request or on subscription basis. The Publish/Subscribe 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.

Example Scenarios

The number of potential context sources permanently connected through 3G links, e.g. mobile user terminals, embedded sensors, microphones and cameras, is expected to increase significantly in the coming years. By processing and inferring this raw information, a variety of useful information will be available in future communication and content management systems. It is likely for smart spaces to grow from smart homes/offices to urban smart spaces in which plenty of artifacts and people are interconnected over distance. This will enable all sorts of innovative interactive pervasive applications as perceived by Weiser [1].

A few examples of how usage of the Publish/Subscribe Context Broker GE may improve the user experience and enrich a service are given below.

Next figure shows a context-aware advertising service (described in [2]) sending an invitation and a coupon to a customer in proximity to a boutique. Also the goods are chosen for that customer based on her/his preferences and previous acquisition. Therefore advertisement messages traffic is significantly reduced, targeting only potential clients, and the clients' user experience is not suffering from a "broadcast" of advertisement messages with zero or very low value. This scenario is possible because the customer or a service provider on her/his behalf, subscribes to some content (e.g. advertisement message and coupon) under certain conditions (the customer is close to the boutique and matching the preferences).

Example of context-aware advertising service

Another example might be context-aware content exchange shown in the figure below, where a customer sees only the content published by social friends (friends in a social network the customer is member of) only when this content is related to her location as well as when that content was originally "placed" in that location. Using interfaces provided by the Publish/Subscribe Context Broker, the application used by the customer can subscribe to be informed based on recommendations related to her/his current location, her/his preferences and coming from friends of the Social Networks the customer is member of. Recommendation would be handled as content information provided by recommender systems or individuals.

Example of context-aware content exchange

Basic Concepts

All the communications between the various components of the Publish/Subscribe Context Broker high-level architecture occur via the NGSI RESTful interface interfaces/protocols, which is described in a following sections. 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 Publish/Subscribe Context Broker GE Model

Publish/Subscribe Context Broker

As already mentioned the Publish/Subscribe 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 comunication is between CS and CB is in push mode, from the CP to the CB.

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 specialized kind of Context Producer actor, which provides context information on demand, in synchronous mode; that means that the Publish/Subscribe 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.

Entity

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 Publish/Subscribe 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 the Publish/Subscribe Context Broker GE with its natural counterparts, that is the Context Producers and the Context Consumers.

  • Context Producers publish data/context elements by invoking the updateContext operation on a Publish/Subscribe Context Broker.
  • Context Consumers can retrieve data/context elements by invoking the queryContext operation on a Publish/Subscribe Context Broker
  • Context data is kept persistent by Publish/Subscribe 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 Publish/Subscribe Context Broker. Some Context Producers (named Context Providers) may also export a queryContext operation Publish/Subscribe 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 Publish/Subscribe Context Broker
  • Publish/Subscribe Context Broker forwards the query to the appropriated Context Provider and returns the result to the originating Context Consumer

Interactions related to forwarded updates to Context Consumers

Publish/Subscribe Context Broker is able to forward context update to Context Consumers able to process that operation. This is the typical case for actuation functionality based on update side-effects as Context Consumer (e.g. turn on/off a lamp).

  • Context Producer can send a updateContext operation to Publish/Subscribe Context Broker
  • Publish/Subscribe Context Broker forwards the updateContext to the appropiated Context Consumer and returns the result (either success or error) to the originating 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 ContextBroker 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 Publish/Subscribe Context Brokers can be used not only for registering Context Producers on which queryContext operations can be invoked (Context Providers or Context Consumer able to process updateContext) 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 Publish/Subscribe 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 information received by the Publish/Subscribe Context Broker (from a Context Source or as a result of a request to a Context Provider) is stored in a context database. If another Context Consumer requests the same context information to the Publish/Subscribe Context Broker, it can be retrieved from the database.

Publish/Subscribe Context Broker persistence is only for the current context snapshoot of the system. In other words, Context Broker doesn't implement context history persistence. However, it can be achive using a Context Consumer in charge of such persistence in any desired persistence backend.

Scalability

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

Geolocalization

Entities could be associated to a given location (typically, GPS coordinates). Thus, Publish/Subscribe Context Broker must allow to consider entities location and resolver queries and subscriptions based on them, e.g. a Context Consumer getting the context information for all the entities within a given area defined by a polygon or circle.

Federation

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

Pagination

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, Publish/Subscribe Context Broker has to implement pagination mechanisms in its API in order to cope with this scenarios, so the information is splited and retrieved in several blocks.

Multitenancy

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

Security

Although it is not required for Publish/Subscribe Context Broker to implement security "natively", it must be able to integrate with FIWARE GEs in change of that task to secure the APIs exposed by Publish/Subscribe Context Broker.

References

[1]

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

[2]

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

[3]

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

Detailed Specifications

Documentation here:

Re-utilised Technologies/Specifications

Most of this GE's API operations regarding Events/Context retrieval and notification are inspired on the OMA (Open Mobile Alliance) NGSI Context Management specifications.

However, the FIWARE team has identified potential updates to the standard to guarantee its correct exploitation in this context, solve some ambiguities and extend its capabilities according to the FIWARE vision. Therefore, we will speak onwards about the FIWARE NGSI specification. FIWARE NGSI specifications differ from the OMA NGSI specifications mainly in the binding, as far as OMA doesn’t have any binding by definition. However FIWARE NGSI improves some of the OMA NGSI aspects, which could be improved in the OMA as well, and finally, thus not all the mandatory/optional definitions may be respected in the FIWARE binding. Therefore the FIWARE NGSI is mainly the technological binding for the OMA specifications with very little omits and differences.


Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FI-WARE level, please refer to FIWARE Global Terms and Definitions

  • Data refers to information that is produced, generated, collected or observed that may be relevant for processing, carrying out further analysis and knowledge extraction. Data in FIWARE has associated a data type and avalue. FIWARE will support a set of built-in basic data types similar to those existing in most programming languages. Values linked to basic data types supported in FIWARE are referred as basic data values. As an example, basic data values like ‘2’, ‘7’ or ‘365’ belong to the integer basic data type.
  • A data element refers to data whose value is defined as consisting of a sequence of one or more <name, type, value> triplets referred as data element attributes, where the type and value of each attribute is either mapped to a basic data type and a basic data value or mapped to the data type and value of another data element.
  • Context in FIWARE is represented through context elements. A context element extends the concept of data element by associating an EntityId and EntityType to it, uniquely identifying the entity (which in turn may map to a group of entities) in the FIWARE system to which the context element information refers. In addition, there may be some attributes as well as meta-data associated to attributes that we may define as mandatory for context elements as compared to data elements. Context elements are typically created containing the value of attributes characterizing a given entity at a given moment. As an example, a context element may contain values of some of the attributes “last measured temperature”, “square meters” and “wall color” associated to a room in a building. Note that there might be many different context elements referring to the same entity in a system, each containing the value of a different set of attributes. This allows that different applications handle different context elements for the same entity, each containing only those attributes of that entity relevant to the corresponding application. It will also allow representing updates on set of attributes linked to a given entity: each of these updates can actually take the form of a context element and contain only the value of those attributes that have changed.
  • An event is an occurrence within a particular system or domain; it is something that has happened, or is contemplated as having happened in that domain. Events typically lead to creation of some data or context element describing or representing the events, thus allowing them to processed. As an example, a sensor device may be measuring the temperature and pressure of a given boiler, sending a context element every five minutes associated to that entity (the boiler) that includes the value of these to attributes (temperature and pressure). The creation and sending of the context element is an event, i.e., what has occurred. Since the data/context elements that are generated linked to an event are the way events get visible in a computing system, it is common to refer to these data/context elements simply as "events".
  • A data event refers to an event leading to creation of a data element.
  • A context event refers to an event leading to creation of a context element.
  • An event object is used to mean a programming entity that represents an event in a computing system [EPIA] like event-aware GEs. Event objects allow to perform operations on event, also known as event processing. Event objects are defined as a data element (or a context element) representing an event to which a number of standard event object properties (similar to a header) are associated internally. These standard event object properties support certain event processing functions.
Personal tools
Create a book