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 R4 - FIWARE Forge Wiki

Architecture of Applications, Services and Data Delivery R4

From FIWARE Forge Wiki

Jump to: navigation, search

Contents

Introduction

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 Framework: Business Frameworks (BFs) represent one of the cornerstones of service ecosystems. The key objective of a BF 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, it consists of a number of interrelated components that support managing services in the business framework across the whole offering lifecycle: from publication of offerings to monetization and revenue sharing. The Business Framework relies heavily on USDL as a common uniform description format for services, which not only focuses on technical aspects of the service, but also on business aspects as well as functional and non-functional service attributes. USDL itself is not a Generic Enabler, since it is a data format and vocabulary specification. It will be introduced as an Open Specification, which is used by different enablers. This framework includes:
    • A Store, which enables 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 store 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.
    • A Marketplace, which allows consumers to find and compare offerings published on different stores and provides further functionality to foster the market for future Internet applications, services and data in a specific domain.
    • A Revenue Sharing System (RSS Engine), which allows the calculation and distribution of revenues according to the agreed business models. The RSS GE requires a revenue sharing (RS) model to calculate the incomes and revenue shares to be distributed among parties (service providers). The RSS GE also offers expenditure limits functionality for limiting the amount of money spent by a customer. Moreover, the RSS GE offers reporting functionality for administrators.
    • A Repository, which provides a consistent uniform API to service descriptions (models) and associated media files for applications of the business framework.


  • 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 4 of FIWARE. If you need to see the previous architecture for components of Release 3, please visit Architecture of Applications, Services and Data Delivery R3

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.

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 store and has to do all necessary preparations in order to let the customer actually use the service as described in the contract.

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 store 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 Linked USDL service description is responsible for sharing and referring to necessary information about the involved services, which occur in the domain specific use case.

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 Store GE) . This component creates and publishes the offering model (defined using Linked USDL) into a repository instance, which is realized by the Repository GE. The repository in turn is queried by all other GEs in the Business Framework, in case a service description or other model description is needed. Once the service description is available, the service can be finally published on the market, realized by the Marketplace GE. A marketplace provides offering and demand matching across many stores and can be targeted to a specific application domain.

The Store coordinates with the marketplace and the repository; it also performs the charging and expenditure control, and forwards the charging details to the RSS GE to calculate the revenue sharing;

3. additionally, the Store 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 using the Store. The next step consist on creating the offering skeleton in the Store, including its basic info, legal conditions, etc. Then, the service provider is redirected to the pricing editor where s/he can create the pricing model that will apply to the offering being created. 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 Store retrieves the different Revenue Sharing models previously created by the service provider from the RSS. If none of the existing revenue sharing models is adequate, the service provider can access the RSS and 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. Finally, the service provider binds the resources s/he registered in the first step to the offering, in order to specify the digital assets to be sold.

Once the offering has been created, the service provider publishes it in order to make the offering available to potential customers. During this process, the service provider chooses the Marketplaces where the offering is going to be searchable. To allow performing smart searches from the Marketplace, the Store creates a Linked USDL document describing the offering and uploads it to the repository before registering the offering in the Marketplace.


Service provider creates offering

The Consumer uses the Business Framework in order to examine, discover, compare, buy and execute services in a FIWARE platform.

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 Marketplace. Once the customer has decided to purchase a concrete offering, s/he contract it through the store registered on the marketplace where that offering was published. When the Store receives this request,

(a) In case the offering has at least one “price part” whose price model is different from “pay-per-use” (e.g. a single payment or the initial payment of a subscription), the Store calculates the corresponding charge. Before charging the customer, it has to check if he has exceeded or not the expenditure limit for a given period of time. This balance of the remaining available expenditure is managed by the RSS GE, which gives this information to the Store. In case the limit is exceeded with this new charge the process ends and the purchase is not performed.

In the case the limit is not exceeded, the Store charges the customer, then the RSS updates the expenditure balance, and finally the Store creates the required Charging Detailed Records (CDRs). The Store then forwards these CDRs to the RSS GE 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 parts” the process doesn’t calculate an initial charge but the Store 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 Service Detailed Record (SDR) documents with information about service usage by the customer. Those SDRs will be sent to the charging component of the Store by using a “push”-oriented accounting API provided by the Store. The Store uses the SDR document 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 RSS GE.

Simultaneously to the generation of the CDR, the Store GE checks with the RSS GE that the expenditure limit has not been exceeded. In case the limit is exceeded, the service must be interrupted until the next period of time or treated according the Store policies defined for these cases.

Note that the generation of CDRs does not need to take place at the same time SDRs are gathered: generation of CDRs and charging may well be a process that takes places regularly, based on SDRs 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 Store 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.

Data

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).

Security

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

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