From FIWARE Forge Wiki
Following is a description of the Reference Architecture linked to the different chapters of FIWARE. A description of FIWARE Generic Enablers (GEs) being supported in each chapter is provided, including the high-level description of the APIs that each FIWARE Generic Enabler (GE) exposes to application developers or it uses to connect to another FIWARE GEs.
- Cloud Hosting
- Data/Context Management
- Internet of Things (IoT) Services Enablement
- Applications, Services and Data Delivery
- Interface to Networks and Devices (I2ND) Architecture
- Advanced Web-based User Interface
The Reference Architecture associated to each FIWARE chapter can be instantiated into a concrete architecture by means of selecting and integrating products implementing the corresponding FIWARE GEs (i.e., products which are compliant with the corresponding FIWARE GE Open Specifications). However, the description of the Reference Architecture associated to a chapter does not depend on how FIWARE GEs in that chapter can be implemented. Any implementation of a FIWARE GE (also referred as FIWARE GEi) will be, by nature, replaceable.
Application developers reading contents of this document will understand how applications are programmed using APIs exposed by FIWARE GEs (i.e., what is the programming model). They will learn what are the names, basic description of arguments, behavior and responses of the main operations in those APIs. On the other hand, FIWARE Instance Providers will learn how FIWARE GEs can be connected to build FIWARE Instances.
Complementing description of the FIWARE Reference Architecture you can visit the Summary of FIWARE Open Specifications to learn the rest of details about FIWARE GE Open Specifications, particularly detailed API Open Specifications. Note that FIWARE GE Open Specifications will be public and royalty-free.
Developer Community and Tools (DCT) wants to offer a comprehensive environment enabling the FI-PPP program developers (and others) to use in the more efficient, easy and effective way the FIWARE outcomes (i.e. GE Implementations and FIWARE Instances) and exploiting collaboration means to benefit the support of the community. For more details visit the following link.
This page is for Release 5 of FIWARE. If you need to see the previous architecture for components of Release 4, please visit FIWARE Architecture R4
FIWARE Architecture Overview
The following a short introduction of each of the FIWARE Technical Chapters and their major components.
FIWARE Architecture Chapters
The Generic Enablers (GE) for the Apps Chapter together build an ecosystem of applications, services and data that is sustainable and fosters innovation as well as cross-fertilization. In particular the Apps Generic Enablers supports managing applications, services and data in a business framework across the whole service life cycle from creation through composition of applications and data to monetization and revenue sharing.
A couple of basic GEs are important to realize the vision of such an applications, services and data business framework, which enables new business models in an agile and flexible way. Among them: a store, a marketplace, a revenue sharing engine, an application composer through mashup and a data visualization and analysis component.
The Business Framework is heavily relying on USDL as common uniform description format for services which does not only focus on technical aspects of service, but also on business aspects as well as functional and non-functional service attributes.
The Application Mashup GE aims at allowing end users without programming skills to quickly compose beautiful web applications and dashboards/cockpits mashing up widgets, operators and data sources from a shared catalogue.
The Data Visualisation GE 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.
The Data/Context Management FIWARE chapter aims at providing outperforming and platform-like GEs that will ease development and provision of innovative Applications that require gathering, publication, processing and exploitation of information and data streams in real-time and at massive scale. Combined with GEs coming from the Apps Chapters, Application Providers will be able to build innovative business models based on exploitation of massive data provided by end users.
FIWARE Data/Context Management GEs allow to gather information from context and other sources (Context Broker), mediate metadata among GEs and applications (Metadata pre-processor) query stored information through an homogeneous layer (Query Broker), , annotate existing information (Semantic Annotation), store and manage semantic information (Semantic Application Support), generate new knowledge from big data stores using a Map & Reduce paradigm (Big Data analysis) and react to different types of scenarios (Complex Event Processing). It also provides GEs for media management, as easy creation of advanced video applications (Stream Oriented GE) and specifically, video analysis in the compressed domain (CDVA).
The GEs in the I2ND chapter provide three sets of functionalities.
The first is an advanced integration middleware to be used by all FIWARE GEs with high performance communication needs
Open networking elements enable cloud network application developers to build value-added services in private, enterprise and public settings.
The third set of functionalities enables the management of robots by means of platform components and interfaces towards other FIWARE GEs, allowing users to develop smarter and faster robotic applications.
The deployment of the architecture of the IoT Service Enablement chapter is typically distributed across a large number of Devices, several Gateways and the Backend.
A device is a hardware entity, component or system that either measures properties of a thing/group of things or influences the properties of a thing/group of things or both measures/influences. Sensors and actuators are devices.
IoT Resources are computational elements (software) that provide the technical means to perform sensing and/or actuation on the device. The resource is usually hosted on the device.
IoT GEs have been spread in two different domains: Gateway and Backend. While IoT Gateway GEs provide inter-networking and protocol conversion functionalities between devices and the IoT Backend GEs, the IoT Backend GEs provide management functionalities for the devices and IoT domain-specific support for the applications.
The Cloud Chapter offers Generic Enablers (GEs) that comprise the foundation for designing a modern cloud hosting infrastructure that can be used to develop, deploy and manage Future Internet applications and services. Provided hosting capabilities are of several kinds and at several levels of resource abstraction -- aiming at the needs of different applications hosted on the cloud.
The IaaS Data Center Resource Management (DCRM) GE is offering provisioning and life cycle management of virtualized resources (compute, storage, network) associated with virtual machines. The Object Storage GE offers provisioning and life cycle management of object-based storage containers and elements. The Job Scheduler GE offers the application to submit and manage computational jobs in a unified and scalable manner. The Edgelet Management GE offers the capability to host lightweight application components, called edgelets. Moreover, the IaaS Service Management (SM) GE provides the means to host complex applications. Lastly, the PaaS Management GE uses the above capabilities to offer provisioning and management of complete PaaS environments, leveraging also the Software Deployment and Configuration (SDC) GE which offers a flexible framework for installation and customization of software products (via Chef recipes) within individual virtual machines.
The Future Internet services will always be exposed to different types of threats that can lead to severe misuse and damage. Creating secured and trusted services without sacrificing much of the desired functionality, usability, performance and cost efficiency is a great challenge, especially in a dynamic environment where new threats and attack methods emerge on a daily basis.
The overall ambition of the Security Architecture of FIWARE is to demonstrate that the Vision of an Internet that is "secure by design" is becoming reality. Based on achievements to date and/or to come in the short-term (both from a technological but also a standardization perspective) we will show that "secure by design" is possible.
Security, Privacy and Trust in FIWARE is mainly focusing on delivering tools and techniques to have the above-mentioned security needs properly met. Furthermore a decision making support and the automation of countermeasures allow alleviating the workload of users and administrators while raising their security awareness.
The high-level Reference Architecture is formed by four main blocks of GEs: Cybersecurity, Identity and Access Management (and Enforcement), Privacy, Trust and Trustworthiness.
The Generic Enablers (GEs) from the Advanced Web-based User Interface (WebUI) chapter cover a set of GEs that provide an advanced user experience using HTML-5 and a Web-based UI approach.
The objective of the Advanced Web-based UI GE is to significantly improve the user experience for the Future Internet by adding new user input and interaction capabilities, such as interactive 3D graphics, immersive interaction with the real and virtual world via Augmented Reality, virtualizing the display and driving them over the network, and many more.
Other Technical Chapters
The primary goal of the Developer Community and Tools (DCT) is to offer a multi-functional development environment - FI-CoDE - enabling the development and management of the Future Internet Applications (FIApp) built to address the needs of the Future Internet and based on the adoption and integration of the Generic Enablers Implementations.
The FIWARE project intends to support the development of innovation-driven value chains around Applications and Services. These value chains are materialized by a number of actors playing various roles supported by FIWARE technologies. The following table describes the different roles envisioned for the FIWARE-enabled value chains.
While there are clear boundaries among the following roles, a company/organization may take one or more of the roles defined. Indeed, we foreseen it will be very common that some companies/organizations play one of these roles as its core role but will try to gain differentiation in the market or try to capture additional revenue streams by playing any of the other complementary roles.
|Application Developer||Future Internet Application Developers are encouraged to develop smart applications targeting either mass markets or individual enterprises and organizations (which in turn may have a limited number of users or, again, the mass market as end users). These Applications should offer flexible means for deployment, provisioning and runtime operation “on the Cloud”.
Future Internet Applications are intended to be meaningful and stand-alone, implementing a number of functions they export “as a Service” to End Users through a number of User Interfaces but also to third Applications in some cases, through well-defined Service APIs (Application Programming Interfaces). They typically rely on functions provided by a number of Enablers, which can be specific to the Application Domain or Generic (meaning they are general purpose).
|Enabler Developer||Enabler Developers are encouraged to develop software components or more complex systems that can be instantiated to provide functions easing the development, provisioning and/or runtime operation of Future Internet Applications.
Enablers are intended to be universal, that is, they refer to multiple Applications that rely on the functions they implement. Those functions are exported “as a Service” to third Applications through well-defined Service APIs and also to Admin and End Users in some cases, through a number of User Interfaces. Enabler Developers may integrate several lower-level Enablers to realize new and more powerful Enablers.. Note that Applications and Enablers resemble each other in their architecture since both implement functions that they export as services. The central differentiator between them is the primary users to be addressed (End Users in the case of Applications, other Applications in the case of Enablers). Note, however, that some products may qualify equally as Applications or Enablers.
|(Application / Enabler) Service Provider & value added service providers||Service Providers are in charge of deploying, provisioning and operating either Applications or Enablers.
Stakeholders playing the Application/Enabler Developer role may also play this role. However, this is not always the case (e.g., a Public Administrator may be playing the Service Provider role with respect to applications developed by third parties that the city offers to its citizens).
Application and Service Providers mainly participate in an ecosystem enabled with FIWARE technology through provisioning, consuming or discovering of services in relation to their business. A service provider is in general active in one business domain where his main business model is residing, but potentially is enable to be active in other business domains, enabled through FIWARE technology. As a sub-role the value-added service provider will be enabled to build innovative services and apps on top of the offerings other providers within and crossing the ecosystem.
|(Application / Enabler) Service Hosting Provider||Service Hosting Providers provide and operate the hosting infrastructure on top of which Applications or Enablers are deployed. They entwine themselves with the Service Providers to reduce the costs for service provision. |
Service Hosting Providers may provide Cloud Services for hosting Applications and Enablers. Note that, in that case, they can indeed be considered a concrete case of Enabler Service Provider (here, the Enabler is the Cloud providing hosting services) so they may be also referred as “Cloud Hosting Provider”. In many cases, an entity playing the Enabler Service Provider role also hosts the Enablers it provides, therefore also playing the Enabler Service Hosting Provider role. However, note that this is not strictly required (one may think about a Enabler Service Provider that provides a number of enablers, all of them being deployed on Amazon hosting services).
|(Application / Enabler) Service Aggregators||Service Aggregators select Services from a broad variety of Service Providers and compose them to build new service offerings that address the specific requirements of niche End Users.
(Application / Enabler) Service Brokers bring together a multitude of Services from diverse Providers and publish them on marketplaces where end users can compare them, matching their requirements with capabilities of published Services - they should exploit economies of scale and protect investments in the long run. Finally, the ability to combine applications from different sources necessitates innovative revenue sharing models across partners and potentially also customers (e.g. crowd-sourcing) which have to be adapted dynamically as market conditions change.
|FIWARE Instance Providers||An instance provider operates and provides one particular FIWARE instance to a given ecosystem or business domain or to a use case project. He assembles a given set of Generic Enablers and defines a scenario and usage domain for the particular FIWARE Instance. Finally he provisions information about how to use the instance, defines his terms and conditions and enables others to work and collaborate on top of the given FIWARE instance.
Note that not all the FIWARE GEs have to be integrated in a given FIWARE Instance. As an example, a FIWARE Instance may only incorporate GEs from the Cloud and Data/Context Management Chapter.
|Roles in relation to FIWARE Lab||There are a number of upcoming roles, which will play a leading role in “FIWARE Lab” (related to nodes, support levels, etc.)|