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.CloudMessaging - FIWARE Forge Wiki


From FIWARE Forge Wiki

Jump to: navigation, search



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


© Copyright 2015, ATOS.

Legal Notice

Please check the following FIWARE Open Specification Legal Notice (implicit patents license) to understand the rights to use this open specification.


Cloud Messaging GE aims to manage real time communication infrastructures. It born from the strong need to be (always) interconnected, whether personal reasons or business needs. Constantly we are interchanging information through different applications, emails, instant messaging, location, etc. not caring about the amount of information or the receptor's location. These applications are supported by a communication network, but, which infrastructure is being used? Who is the owner? What if I have similar communication needs than WhatsApp? Cloud Messaging platform creates and manages your own infrastructures, which later will support different applications with real time and high performance requirements.

What does “Real Time Communication Infrastructure” means? In our current technological stage, the amount of information that it is going to be created during the next five minutes, in the computing world, is almost impossible to be calculated: Facebook generates 2.5B likes by day, FourSquare receives 5M checking (user’s locations) each day. This situation converges to the need of new infrastructures where it has no limits about gathering (web services), storing (cloud distributed storage) data, and faster communication channels (event-driven architectures). From a more functional point of view: “Cloud infrastructures which spread web services over the unlimited network, capable of processing millions of request by second, and communications with just a few milliseconds of delay”.

Having these premises as basis, Cloud Messaging will provide infrastructures able to communicate an unlimited number of entities, interchanging an unlimited amount of information. But it is not only about the infrastructure, it also provides a platform for easily management of your entities and communication channels: create your own communication entities (mobile, truck, box, thermometer, even yourself...), establish and configure your channel's privacy.

When your environment is ready, you will be able to share your channels. Cloud Messaging infrastructure will make “the magic” that communicate all the entities in real time.

Cloud Messaging has been built with very strong requirements about performance and scalability from the beginning of the project, thus, cutting edge technologies about cloud, big data and real time services have been analysed and implemented.

Basic Concepts

Cloud Messaging is a real time communication platform based on a pub/sub mechanism. It manages two important concepts: entities and channels. An Entity can be defined as any object belonging to the Internet of Things. Cloud Messaging allows the user to create a taxonomy of entities that will allow him to facilitate their management.

A Channel is a concept strongly linked to the Entities. Each of these entities can have as many channels as required, acting each as topics managing different kind of information. Channels are the communication link between an owner of an entity and its subscribers. Each channel owns an endpoint to publish information and another one to get subscribed and receive it.

Technologies used to develop Cloud Messaging are extremely fast and scalable. That allows getting response times close to real time. That means that, when an entity publishes information, the subscribers get it instantaneously, e.g. A truck driver that gets notified because the wagon temperature is too low. These conditions are subject to external factors such as network quality or peeks usage.


High level architecture


The Cloud Messaging architecture is composed by three main functional blocks:

  • Resources Management: This block is in charge of users and resources management, it also manages privacy issues. Through a REST API provides the main operations for:
  • Users management. Create, delete, register your users that will interact with the platform.
  • Resources management.
  • Entities: an entity is a basic resource: boxes, trucks, mobiles, an applications, whatever you need to send information.
  • Channels: each entity will posses his own channels. A channel is composed of a tuple of publication (send) and subscription identifiers (receive).
  • Messaging Management: These block make use of the publication and subscription identifiers in order to facilitate the use of the real-time-communication-infrastructure of Cloud Messaging.

Every message send it through the publication identifier will be received by the list of subscribers. As extra functionalities, is also in charge of checking messages correctness and the subscriptions requirements. This last point is crucial important, you could share your subscription channels but limiting the audience: registered users, public, payments.

  • Messaging broker: The service in charge of maintaining channels, queues, subscribed lists, etc. The block is not strictly part of the platform, it will be a AMQP server used by Cloud Messaging.

APIs and interfaces exposed by the architecture

Cloud Messaging open API allows you to implement your resources management in your own way. This is a key point of Cloud Messaging, your applications could have flexibility enough, not only to send/receive data, but also to configure your environment in a very dynamic way. For example, a chat application could manage rooms creating and deleting entities and channels regarding the needs.

If you are a developer, this should be your section. Here you will find a description of the REST API for resources management and pub/sub functionality.

  • API Users Documentation
  • API Entities Documentation
  • API Channels Documentation
  • API Publication/Subscription Documentation


Cloud Messaging provides a Software Development Kit to develop applications over its platform. The utilization of this SDK is very simple and efficient as show in the next subsections.

  • SDK for Java
  • SDK for Javascript
  • SDK for node.js

Main Interactions

Cloud Messaging was designed with the idea of being a very easy-to-use software that could allow developers to focus on their real application implementations forgetting about the communication infrastructure, which is usually something very complex and takes a lot of tie on what really matters, the domain application itself. Therefore, here it is shown how easy to use Cloud Messaging is:

Image:publish.png Image:suscribe.png

In the images above, it can be seen how easy is for the user to communicate his application. Internally, the system is more complex when a publish/subscription request arrives. To provide the subscription mechanism, Cloud Messaging uses the RabbitMQ message broker to manage the all the messages to be delivered to the different subscribers. In the image below, this mechanism is explained:


Anyway, it does not matter how complex Cloud Messaging is inside. What makes it so powerful is the easy way of integrating it within the developer's code and start using it.

Basic Design Principles

The main design principles for Cloud Messaging are:

  • Extremely simple: A powerful tool to be used the easiest way. SDKs and API available.
  • Scalable: Capacity of handling big amounts of messages in real time and give support to all the users that Cloud Messaging may have.
  • Fast: Delivering messages in real time.
  • Developer friendly: Easy to use and integrate. Earn time to develop what you really want.
  • IoT approach: API based on a world of entities and communication channels.

Detailed Specifications

Documentation here:

Re-utilised Technologies/Specifications

The complete architecture has been designed with Open Source Technologies and having as requirements strongly dependency about performance and scalability.

Some core technologies are:

node.js as webserver and language to implement the server services with huge scalability performance.

express.js is the framework in charge of exposing the REST API to expose the services.

Mongo.db. NoSQL databases allows to support big data capabilities and extremely high response for I/O operations.

RabbitMQ as an implementation of the AMPQ protocol.

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