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
Architecture of Applications, Services and Data Delivery - FIWARE Forge Wiki

Architecture of Applications, Services and Data Delivery

From FIWARE Forge Wiki

Jump to: navigation, search



The Generic Enablers (GEs) of the Applications/Services and Data Delivery Chapter (herein referred as the Apps Chapter for short) together support the creation of an ecosystem of applications, services and data that is sustainable and fosters innovation as well as cross-fertilization. In particular Generic Enablers that are part of this reference architecture can be grouped in three mayor architectural blocks:

  • Business API Ecosystem: Business Frameworks (BFs) represent one of the cornerstones of service ecosystems. The key objective of a BE is to build and support an ecosystem of data, applications and services that is sustainable and fosters innovation as well as cross-fertilization. In particular, the Business API Ecosystem consists of a number of interrelated components that support managing services across the whole offering lifecycle: from publication of offerings to monetization and revenue sharing. The Business API Ecosystem relies heavily on standard APIs defined by the Tele management Forum (TMForum) as a common uniform description format for products and offerings. This ecosystem includes features, which enable selling digital assets (i.e. applications, services and data) for consumers as well as developers of future Internet applications, and is responsible for managing offerings and sales. The Business API Ecosystem supports (1) registration and publication of new offerings by application/service and data providers, (2) contracting of applications/services and data, (3) gathering application/services (including data services) usage accounting info, and (4) charging for the acquisition and usage of application/services, on the basis of the predefined price model. Additionally, it includes revenue sharing features, which allow the calculation and distribution of revenues according to the agreed business models. The Business API Ecosystem requires a revenue sharing (RS) model to calculate the incomes and revenue shares to be distributed among parties (service providers).

  • FI Application Mashup Framework: The FI Application Mashup Framework aims at offering support for application mashup, with a focus on the creation of visualization dashboards and operation cockpits from the underlying services and data. The framework leverages the notion of app and data mashup to allow domain experts and other knowledge workers without programming skills to easily develop application mashups as highly configurable cockpits and dashboards based on data- and event-based wiring of widgets and operator chaining, being these widgets and operators linked to backend services and data.

  • Data Visualization Framework: The Data Visualization Framework aims at creating agile, beautiful visualizations and meaningful reports useful to present the large variety of datasets data stakeholders will bring in the play as well as providing customisable data analytics.

This set of self-contained GEs represents only an initial starting point for a future business framework. It is expected that supplemental enablers (e.g. for contracting, quotation, etc.) will be developed outside of the FIWARE platform.

GEs in the Apps Chapter are named according to their main functionality, which is different from the role names introduced in the FIWARE Vision. While the role names (Aggregator, Broker, Gateway, etc.) are used to describe the stakeholders of the service ecosystem in an abstract way, the enablers’ names refer to software components.

This page is for Release 5 of FIWARE. If you need to see the previous architecture for components of Release 4, please visit Architecture of Applications, Services and Data Delivery R4

Architecture Overview

The following diagram gives an example of how the GEs of the App Chapter can be combined to form a concrete architecture for a Service Business Framework. FIWARE Generic Enablers are marked by blue boxes.

Apps, Services and Data Visualization Architecture Blueprint

The service or application deployment into its own platform, the cloud (FIWARE or not) or the Internet of Things infrastructure is the concern of the infrastructure provider. The service provider needs to provide interfaces to accept commercial transactions such as a customer/consumer buying a service on the Business API Ecosystem and has to do all necessary preparations in order to let the customer actually use the service as described in the contract.

The architecture given here is only a blueprint showing an example of how the GEs in this chapter can be used in an encompassing target platform. In a real use case, the architecture might look different according to the individual needs of the use case. However, it is important to recognize that the interplay among the GEs and other application platform components is ensured by the FIWARE Open Specifications linked to the interfaces supported by the GEs, through which the communication and interaction take place.

The architecture blueprint is divided into three major areas:

  1. first the GEs on the Service Provider side are the different application mashup and data visualization enablers, which can be used to generate different kinds of dashboards and cockpits as well as composite applications. Besides, the provider can also use other development tools in order to create new services;
  2. the service provider can put his/her applications, services and data into a store (realized by the Business API Ecosystem GE), which provides discovery and monetization features as well as revenue settlement and sharing.
  3. additionally, the Business API Ecosystem GE interoperates with external components in charge of retrieving accounting information from services contracted under a, let's say, “pay-per-use” model. Also GEs in Service Provider interact with external components, in particular with the Data Portal in order to retrieve data and display meaningful analyses.

Use cases

The FIWARE platform consists of a number of Generic Enablers, which can be used to build a concrete FIWARE instance. Different FIWARE instances might differ from each other because of the concrete selection of GEs and their customization. Also additional domain-specific enablers as well as proprietary enablers may be added. The following generic scenario diagrams show how the GEs of the Apps Chapter are typically used in a sample use case. We provide scenario diagrams from the perspective of a Service Provider providing services and from the perspective of a Consumer buying and executing services.

The first use case describes the end-to-end process associated to the Service provider creating an offering and it shows the interaction of a number of generic enablers from the Apps chapter.

The first step for the service provider, once s/he has chosen the services s/he wants to commercialize, is to register the different digital assets that are going to be included in her offering by creating a set of product specifications using the Catalog Management API of the Business API Ecosystem. The next step consist on creating the offering, including its basic info, legal conditions, the pricing model, etc. Additionally, the service provides has to choose the product to be sold and the catalog where the offerings is going to be published. To finish with the creation of the offering, the service provider selects the Revenue Sharing Model that specifies how to divide the revenue generated by the offering among the different stakeholders. To do that, the different Revenue Sharing models previously created by the service provider are retrieved from the Revenue Sharing Management API of the Business API Ecosystem . If none of the existing revenue sharing models is adequate, the service provider can create a new Revenue Sharing Model. Note that the Revenue Sharing models are not intended to apply to a single offering but to be used and reutilized along offerings with similar characteristics. Once the offering has been created, the service provider launches it, as well as the offered product, in order to make the offering available to potential customers.

Service provider creates offering

The second use case describes the end-to-end process associated to the Consumer Buying a Service and it shows the interactions of GEs from the Apps chapter.

The first step in this process is the discovery and comparison of offerings through the Catalog Management API of the Business API Ecosystem. Once the customer has decided to acquire a concrete offering, s/he contract it using the Ordering Management API of the Business API Ecosystem. Once this request has been received:

(a) In case the offering has at least one “price plan” whose price model is different from “pay-per-use” (e.g. a single payment or the initial payment of a subscription), the Business API Ecosystem calculates the corresponding charge, charges the customer, and creates the required Charging Detailed Records (CDRs). The Charging Management module then forwards these CDRs to the Revenue Sharing Management API to calculate the revenue sharing. These CDRs would be also made available to the external billing system, which will bill the customer for the acquisition of access rights to the service.

(b) In case the pricing model only includes “pay-per-use” “price plans” the process doesn’t calculate an initial charge but the Business API Ecosystem performs the necessary steps to allow generation of CDRs later on, based on actual usage of the service.

When the purchased service includes one or more “price parts” of type “pay-per-use”, it is expected that an accounting component (i.e. any external component in charge of monitoring the use of the services or any monitoring system operated by the service provider) generates documents with information about service made usage by the customer. Those documents will be sent to the Usage Management API component of the Business API Ecosystem. Periodically, it uses the usage information and the pricing model of the service offering to calculate the charging associated to usage of service, and generates a CDR that is sent to the Revenue Sharing Management API.

Note that the generation of CDRs does not need to take place at the same time usage information is gathered: generation of CDRs and charging may well be a process that takes places regularly, based on usage information gathered during a given period of time. The generated CDRs can be later used to generate invoices to customers. Similarly, the RSS makes the Revenue sharing calculation based on the received CDRs and uses the Revenue Share model to distribute the revenues among the different parties involved.

Consumer acquire service

The last meaningful use case describes the process in which the user creates reports by his-own through ad-hoc reporting functionalities provided by the Data Visualization GE (see following image, but pay attention to the fact that the Data Portal is not a GE in the Apps Chapter). The user interacts with the Data Visualization GE, which in turn retrieve data and metadata of the available datasets by the Data Portal; in case the user subscribed a pay-per-use model, the Data Portal notifies the Business API Ecosystem about the dataset's usage.

User performs ad-hoc reporting

Architecture description of GEs

This list of enablers is not conclusive, and may be extended in future phases of the FIWARE project.

Interfaces to other Chapters

It is intended that any Generic Enabler implementation can be offered within the Business Framework. We also encourage implementing the Business Framework using Generic Enabler implementations of other chapters. The following subsections give some indications of GE implementations that might be relevant.


GE implementation for Big Data, Open Data and Context Broker can be used for gathering information that will be visualized (Application Mashup and Data Visualization) and analyzed (Data Visualization), as well as monetized as "premium datasets" (Business Framework GEs).


Within a Business Framework implementation there is the need for a common user identification mechanism across the different components. This could be achieved by the IdM GE of the security chapter. The PEP Proxy could be used as a basis for implementing accounting API usage when access control is also needed.


Cloud enabler implementations can be used to host parts of the Business Framework in the cloud in order to provide scalability and cost efficient operation. The Cloud Object Storage could be used to store artefacts required by the Business Framework components.

Internet of Things

A Business Framework implementation that manages the business lifecycle of application/services that rely on sensors and actuators in the Internet of Things can use the IoT enablers implementations.

If a service that is commercialized via the Business Framework actually relies on sensors and actuators, the service description has to reflect this in order to capture business relevant properties. Therefore the service description need to be extended by parts describing the specific IoT requirements (needed resources, specific SLA, ...). This description is derived from the exposed capabilities of the IoT enablers.

Personal tools
Create a book