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

Architecture of Applications, Services and Data Delivery R3

From FIWARE Forge Wiki

Jump to: navigation, search

Contents

FIWARE WIKI editorial remark:
This page corresponds to Release 3 of FIWARE. The latest version associated to the latest Release is linked from FIWARE Architecture

Introduction

The Generic Enablers (GEs) of the Applications/Services Ecosystem and Delivery Framework (herein referred as the Apps Chapter for short) together support the creation of a ecosystem of applications and services that is sustainable and fosters innovation as well as cross-fertilization. In particular the Apps GEs support managing services in a business framework across the whole service lifecycle from creation and composition of services to monetization and revenue sharing. With the term “service” we refer to both frontend applications and backend application services (typically exposed through an API).

  • A Store, which enables selling services 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 providers, (2) contracting of applications/services, (3) gathering application/services usage accounting info, and (4) charging for the acquisition and usage of application/services.
  • A Marketplace, which allows consumers to find and compare service offerings published on different stores and provides further functionality to foster the market for future internet applications and services 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 set of Service Composition enablers, which enable the composition of existing services into value added composite services, which can be monetized in the Business Framework.
  • Two BEMES (Business Elements Model Editor and Simulator) GEs used to create and simulate business models for value-added composite services and applications, where many other providers are involved. The BEMES component is an integration of both a Business Elements Model Editor GE and a Business Elements Model Calculator (Simulator) GE as shown in the figure underneath.
  • A set of Mediator enablers, which can be used to achieve interoperability between future internet services and also to allow interfacing to existing enterprise systems.

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 FI-WARE platform.

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.

GEs in the Apps Chapter are named according to their main functionality which is different from the role names introduced in the FI-WARE 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.

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. FI-WARE Generic Enablers are marked by blue boxes.

Apps and Services Ecosystem Architecture Blueprint

The service or application deployment into its own platform, the cloud (FI-WARE 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 provider also needs to deliver status information to the Revenue Sharing component.

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 FI-WARE 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. First the GEs on the Service Provider side are the different Composition Enablers, which can be used to generate different kinds of composite applications and services following various paradigms of composition. Besides the provider can also use other development tools in order to create new services.

The service provider has to upload the service descriptions (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 put into a store (e.g., a store realized by the Store GE) and 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, the registry/repository, the BEMES, and the Revenue Sharing RSS engines. Additionally, the Store GE interoperates with external components in charge of retrieving accounting information from services contracted under a “pay-per-use” model. It also performs the charging and expenditure control, and forwards the charging details to the RSS GE to calculate the revenue sharing. A given service provider shall be able to choose a business model from the Business Elements Model Editor GE and link it to the offering they publish in the Store GE, so as to allow the Store to extract the pricing model that it will apply during charging and to notify the RSS GE that a new offering has been published.

The Mediation side, represented by the Mediator GE, finally is used to access existing legacy components via FI-WARE open interfaces and further provide services for application specific translation of data formats and protocols.

Use cases

The FI-WARE platform consists of a number of Generic Enablers, which can be used to build a concrete FI-WARE instance. Different FI-WARE 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 GE 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. Materialization of the architecture linked to the Apps chapter has followed an Agile methodology so that each of these usage scenarios have been mapped into Themes. The functionality to be supported by each of the FI-WARE GEs involved in a Theme is described in more detail in the corresponding Epics. You may refer to the description of the FI-WARE Agile Methodology to learn more about how Agile concepts are being used in the materialization of the FI-WARE vision.

The first Theme 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 a service s/he wants to commercialize, is to define the Business Model for the new offering. In this task the service provider could create a new business model or instantiate a predefined one from a template using the Business Elements & Models Execution and Simulation (BEMES) toolkit. Then the service provider could use the simulation tool provided by BEMES in order to check its adequacy. The Business Model will be stored in the repository by the BEMES tool. The Business Model associated to an application/service will contain both the description of the pricing as well as the revenue share model (in this latter case, in a way that can be processed by the Revenue Share Engine).

Once the Business Model has been chosen, the next task implies creating the Linked USDL description for the service offering, by using the USDL editor and storing it in the Repository. Then, the service provider creates the offering skeleton in the Store, including the name and version that will be used to identify the offering in the Store, as well as the link of the USDL that describes both the service and its Business Model. When the Store receives the request to create an offering, it downloads the USDL description from the Repository. In the next step, the service provider registers the resources and binds them to the offering.

Once the service offering has been created, the next step for the service provider is to publish it in order to make the service offering available to potential customers. The service provider should choose the target marketplace, where the offering will be searchable. Finally, the Store publishes the service offering in the chosen Marketplace, and notifies the Revenue Sharing System that a new offering has been published, which downloads the revenue sharing model (which is part of the chosen business model) from the Repository.

Aggregator creates masup
Service provider creates offering

The Consumer uses the Business Framework in order to discover, examine, buy and execute services in a FI-WARE platform.

The second Theme 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 who 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, the expenditure balance is updated by the RSS GE and 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 send 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 doesn’t 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.

The second Theme describes the end-to-end process associated to the Consumer Buying Service and it shows the interactions of generic enablers 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 associated to that offering. 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, charges the client, and 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 application/service.

(b) In case the pricing model only includes “pay-per-use” “price parts” the process finishes, since no use of the service has been done yet but the Store has performed 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 send 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. Note that the generation of CDRs doesn’t 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 buying service theme

Unified Service Description Language

USDL is the Unified Service Description Language, which is used to share information about services and apps between the different GE.

Architecture description of GEs

This list of enablers is not conclusive, and may be extended in future phases of the FI-WARE project. For project management reasons and limited resources, some of the mentioned roles in the FI-WARE Vision, such as the SLA monitoring, and multi-channel/multi-device support will be addressed in future extensions of FI-WARE.

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 can be used to realize large distributed service description repositories and registries. The Complex Event Processing and Publish Subscribe enablers can be used for gathering monitoring data for SLA monitoring and Revenue Sharing.

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 Security Monitoring GE can be used to ensure compliance to the security requirements of Business Framework. The Privacy GE can be used to realize privacy according to privacy where consumer related private information is captured and stored.

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