Upload
doanphuc
View
226
Download
0
Embed Size (px)
Citation preview
Deliverable D2.3
FI-STAR Back-End Platform Services Modules Beta: Development & Access Support
Editor: Paolo Zampognaro, Engineering Ingegneria Informatica
Adel Al-Hezmi, Fraunhofer FOKUS
Deliverable nature: R
Dissemination level: (Confidentiality)
Restricted to Programme (PP)
Contractual delivery date:
M22 (January 2015)
Actual delivery date: 16 February 2015
Suggested readers: FI-STAR Infrastructure Managers, FI-STAR Applications Developers, FI-STAR Applications Provider
Version: 1.0
Total number of pages: Main document: 78
Keywords: FI-STAR Catalogue, FI-STAR Specific Enabler, FI-STAR Reference Cloud Environment, FI-STAR Platform Provider
Abstract
This document provides (i) a report about the development activity of the FI-STAR Back-End Platform Services (SEs) for the Beta release and (ii) a report about the interactions, by all the actors, with the FI-STAR Catalogue and its integration with a solution to support the automatic shipment modality by the Application Provider.
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 2 of (78)
Disclaimer
This document contains material, which is the copyright of certain FI-STAR consortium parties, and may not be reproduced or copied without permission.
All FI-STAR consortium parties have agreed to make this document available on request to other framework programme participants.
The commercial use of any information contained in this document may require a license from the proprietor of that information.
Neither the FI-STAR consortium as a whole, nor a certain part of the FI-STAR consortium, warrant that the information contained in this document is capable of use, nor that use of the information is free from risk, accepting no liability for loss or damage suffered by any person using this information.
This project has received funding from the European Union’s Seventh Framework Programme for research, technological development and demonstration under grant agreement no 604691.
Impressum
Full project title: Future Internet Social and Technological Alignment Research
Short project title: FI-STAR
Number and title of work-package: WP2: Back-End Platform Design and Development
Number and title of task: T2.3: FI-STAR Back-End Platform: Modules Development; T2.4 FI-STAR Platform Access Support: for (prototype BE-α) and refinement (prototype BE-β)
Document title: FI-STAR Back-End Platform Services Modules Beta: Development & Access support
Editors: Adel Al-Hezmi Fraunhofer FOKUS, Paolo Zampognaro ENG
Work-package leader: Paolo Zampognaro, ENG
Copyright notice
2015 Participants in project FI-STAR
This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-nd/3.0
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 3 of (78)
Executive summary
This deliverable is a follow-up on the previous deliverable D2.2 which, is worth to mention, covered (i) the previous ALPHA release of the FI-STAR Back-End platform (in PartA section) and (ii) the requirements analysis related to the FI-STAR Platform access and the consequential design of the FI-STAR Catalogue offering the main access point to the Platform itself (in PartB section).
This deliverable reports about the evolution on both these aspects.
In particular in the PartA the document covers the technical realization of the FI-STAR Back-End platform. It describes in detail the BETA (and therefore according to the development plan final release) of the software modules that have been developed in the course of work package WP2 to support the application development of the FI-STAR trial use cases. These services modules are specified as Application Support Services called FI-STAR Specific Enablers (SEs).
This part also tries to better qualify the adoption of the FI-WARE GEs and demonstrate the modularity of the SE, which allows to build upon existing FI-WARE GE implementations, as it has been asked in the Technical Review Report by the European Commission – Ares(2015)369120 – 30/01/2015.
The report covers following Specific Enablers:
Connectivity Service Back-End
Event Service SE
Targeting and Profiling SE
Security and Privacy SE
Mediation Service SE
Health questionnaire Service SE
Device Management Service SE
Real Time Communication Service SE
Time Service SE
Monitoring Service SE
The technical specifications described in this section are supposed to support the application implementation of the FI-STAR trial use cases and the realization of the BETA roll-out.
The Part B of this deliverable, instead, reports, about how the different actors (i.e. FI-STAR Application Developers, FI-STAR SE Owner, FI-STAR Application Provider) interacted with the Catalogue, to accomplish their tasks, during this second development cycle. It is worth to mention that from this interaction report comes out also the increasing interaction of external partners (i.e. Phase 3 SMEs from the main FI-PPP accelerators) giving evidence of the concrete engagement of the FI-STAR Platform by these partners. In this section is described, furthermore, the design of the solution to support the FI-STAR SEs automatic shipment modality offered to the Application Providers. With respect to this last point details are provided about (i) requirements identification (ii) architecture design and data model specification (ii) programmatic and GUI interfaces.
A list of references supporting the findings of the document provides the reader with specific detailed information.
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 4 of (78)
List of authors
Company Author Contribution
ENG Paolo Zampognaro
Alessandro Avolio
Editor
Executive Summary, Introduction,
Part B: Chapters 2, 2.1, 2.3
Fraunhofer FOKUS Adel Al-Hezmi
Ancuta Corici
Konrad Campowsky
Mikhail Smirnov
Editor
Part A: Chapters 1, 1.1, 1.7
Part B: Contribution to 3.1
TUB Tran Quang Thanh
Benjamin Ertl
Yahya Al-Hazmi
Part A: Chapters 1.2, 1.3, 1.4, 1.10
Part B: Contribution to 3.1, 3.2
TSI-TUC Stelios Sotiriadis
Part A: Chapters 1.9
Part B: Contribution to 3.1, 3.2
TEK Patricia Casla Part A: Chapters 1.6
Part B: Contribution to 3.1
ITTI Tomasz Springer Part A: Chapters 1.8
Part B: Contribution to 3.1
C2K Stefano Nunziata Part A: Chapters 1.5
Part B: Contribution to 3.1
AGE Adrian Koepe, Tomasz Poslada,
Andrei Pintea
Part B: Contribution to 3.1
ENU John Brogan Part B: Contribution to 3.1
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 5 of (78)
Table of Contents
Executive summary ......................................................................................................................... 3
List of authors ................................................................................................................................. 4
Table of Contents............................................................................................................................ 5
List of figures .................................................................................................................................. 8
List of tables .................................................................................................................................... 9
Abbreviations ................................................................................................................................ 10
Definitions ..................................................................................................................................... 13
Introduction ................................................................................................................................... 14
Objectives of this document....................................................................................................... 14
Specifications of this document ................................................................................................. 14
Deliverable structure ................................................................................................................. 14
Part A – FI-STAR Back-End Platform: Development Report ......................................................... 15
1 Implementation Activities ......................................................................................................... 16
1.1 Connectivity Service Back-End ......................................................................................... 18
1.1.1 Reported bugs and requirements ............................................................................... 18
1.1.2 New Interfaces ........................................................................................................... 18
1.1.3 Old Specified Interfaces ............................................................................................. 19
1.1.4 FI-Ware GE specification ........................................................................................... 20
1.1.5 FI-Ware GE uptake .................................................................................................... 21
1.2 Event Service ................................................................................................................... 21
1.2.1 Reported bugs and requirements ............................................................................... 21
1.2.2 New Interfaces ........................................................................................................... 22
1.2.3 Old Specified Interfaces ............................................................................................. 22
1.2.4 FI-Ware GE specification ........................................................................................... 23
1.2.5 FI-Ware GE uptake .................................................................................................... 24
1.3 Targeting and Profiling Service ......................................................................................... 24
1.3.1 Reported bugs and requirements ............................................................................... 24
1.3.2 New Interfaces ........................................................................................................... 25
1.3.3 Old Specified Interfaces ............................................................................................. 25
1.3.4 FI-Ware GE specification ........................................................................................... 26
1.3.5 FI-Ware GE uptake .................................................................................................... 27
1.4 Security and Privacy – Integrated Access Control ............................................................ 27
1.4.1 Reported bugs and requirements ............................................................................... 28
1.4.2 New Interfaces ........................................................................................................... 28
1.4.3 Old Specified Interfaces ............................................................................................. 28
1.4.4 FI-Ware GE specification ........................................................................................... 29
1.4.5 FI-Ware GE reference implementation ....................................................................... 29
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 6 of (78)
1.5 Mediation Service ............................................................................................................. 30
1.5.1 Reported bugs and requirements ............................................................................... 30
1.5.2 New Interfaces ........................................................................................................... 30
1.5.3 Old Specified Interfaces ............................................................................................. 30
1.5.4 FI-Ware GE specification ........................................................................................... 32
1.5.5 FI-Ware GE uptake .................................................................................................... 33
1.6 Health Questionnaire Service ........................................................................................... 33
1.6.1 Reported bugs and requirements ............................................................................... 33
1.6.2 New Interfaces ........................................................................................................... 34
1.6.3 Old Specified Interfaces ............................................................................................. 36
1.6.4 FI-Ware GE specification ........................................................................................... 38
1.6.5 FI-Ware GE reference implementation ....................................................................... 38
1.7 Device Management ......................................................................................................... 38
1.7.1 Reported bugs and requirements ............................................................................... 39
1.7.2 New Interfaces ........................................................................................................... 39
1.7.3 Old Specified Interfaces ............................................................................................. 40
1.7.4 FI-Ware GE specification ........................................................................................... 41
1.7.5 FI-Ware GE uptake .................................................................................................... 41
1.8 Real-time Communication Service .................................................................................... 41
1.8.1 Reported bugs and requirements ............................................................................... 42
1.8.2 New Interfaces ........................................................................................................... 42
1.8.3 Old Specified Interfaces ............................................................................................. 42
1.8.4 FI-Ware GE specification ........................................................................................... 43
1.8.5 FI-Ware GE uptake .................................................................................................... 43
1.9 Time Service..................................................................................................................... 43
1.9.1 Reported bugs and requirements ............................................................................... 43
1.9.2 New Interfaces ........................................................................................................... 43
1.9.3 Old Specified Interfaces ............................................................................................. 43
1.9.4 FI-Ware GE specification ........................................................................................... 43
1.9.5 FI-Ware GE reference implementation ....................................................................... 44
1.10 Monitoring Service .......................................................................................................... 44
1.10.1 Reported bugs and requirements ............................................................................. 44
1.10.2 New Interfaces ......................................................................................................... 44
1.10.3 Old Specified Interfaces ........................................................................................... 46
1.10.4 FI-Ware GE specification ......................................................................................... 46
1.10.5 FI-Ware GE reference implementation ..................................................................... 46
Part B – FI-STAR Platform Access Support .................................................................................. 48
2 Solution for an Automatic Shipment and Deployment .............................................................. 49
2.1 Preliminary Concerns ....................................................................................................... 49
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 7 of (78)
2.2 Application Provider: Platform Access .............................................................................. 49
2.3 Design details ................................................................................................................... 53
2.3.1 Details about the Human Machine Interaction Design ................................................ 55
3 The Catalogue: Usage Experience Report .............................................................................. 65
3.1 SE Owners report ............................................................................................................. 65
3.2 Cloud Platform Managers Report ...................................................................................... 72
3.3 Application Providers Report ............................................................................................ 74
3.4 Bugs analysis and improvements ..................................................................................... 75
3.5 Final considerations .......................................................................................................... 77
References ................................................................................................................................... 78
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 8 of (78)
List of figures
Figure 1: FI-STAR Functional SEs Architecture ............................................................................ 17
Figure 2: FI-STAR Connectivity Back-End Service and FI-Ware enabled components ................. 20
Figure 3: FI-STAR Event Service and FI-WARE enabled components .......................................... 23
Figure 4 FI-STAR Targeting and Profiling service and FI-WARE enabled components ................. 26
Figure 5: High level architecture .................................................................................................... 27
Figure 6: FI-STAR Mediation Service and FI-Ware enabled components ..................................... 32
Figure 7: FI-STAR Device Management Service and FI-Ware enabled components .................... 41
Figure 8 – The Catalogue: Subscription Area ................................................................................ 50
Figure 9 – shipment modality evaluation results ............................................................................ 50
Figure 10 – Architecture to enable the automatic shipment ........................................................... 52
Figure 11 – Data Model: Overview ................................................................................................ 53
Figure 12 – Data Model: Deployment Options detail ..................................................................... 53
Figure 13 – Catalogue Agent: download window .......................................................................... 55
Figure 14 - Catalogue Agent Installation Wizard ........................................................................... 55
Figure 15 – Preliminary initialization actions .................................................................................. 56
Figure 16 - Catalogue Authorisation GUI – User Authentication .................................................... 56
Figure 17 - Catalogue Authorisation GUI – Agent Application Authorisation.................................. 56
Figure 18 – Agent Installation STEP 1: external or internal Configuration Manager. ..................... 57
Figure 19 - Agent Installation STEP 2: external or internal Deployment Service. .......................... 57
Figure 20 - Agent Installation STEP 3: Wizard completed ............................................................. 58
Figure 21 – Configuration Manager Main Page ............................................................................. 58
Figure 22 – Configuration Manager: New Customer Form ............................................................ 59
Figure 23 – Configuration manager: User Preferences Section..................................................... 59
Figure 24 – Configuration manager: Geographic Constraints ........................................................ 60
Figure 25 – Configuration Manager: Deployment Preferences ...................................................... 60
Figure 26 – Deployment Manager: Main Page .............................................................................. 61
Figure 27 – Deployment Manager: Default Platform Provider Preferences ................................... 62
Figure 28 – Deployment Manager: Platform Provider Preferences for SE ..................................... 62
Figure 29 – Deployment Manager: New Cloud Node creation form ............................................... 63
Figure 30 – Agent: Main Page....................................................................................................... 64
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 9 of (78)
List of tables
Table 1: Reported bugs and requirements of the Connectivity Service back-end SE .................... 18
Table 2: New interfaces of the Connectivity Service back-end SE ................................................ 19
Table 3: Old Specified Interfaces of the Connectivity Service back-end SE .................................. 20
Table 4: Reported bugs and requirements of the Event Service SE .............................................. 22
Table 5: Old Specified Interfaces of the Event Service SE ............................................................ 23
Table 6: Reported bugs and requirements of the Targeting and Profiling SE ................................ 25
Table 7: New interfaces of the Targeting and Profiling SE ............................................................ 25
Table 8: Old Specified Interfaces of the Targeting and Profiling SE .............................................. 25
Table 9: New requirements of the Security and Privacy IAC ......................................................... 28
Table 10: New interfaces/operations of the Security and Privacy IAC ........................................... 28
Table 11: Old Specified Interfaces/Operations of the Security and Privacy IAC ............................ 29
Table 12: Old Specified Interfaces of the Mediation Service Enabler ............................................ 31
Table 13: Reported bugs and requirements of the Device Management SE ................................. 39
Table 14: Old Specified Interfaces of the Real-Time Communication SE ...................................... 42
Table 15: Reported requirements of the Monitoring SE ................................................................. 44
Table 16: New interfaces of the Monitoring SE ............................................................................. 45
Table 17: Old Specified Interfaces of the Monitoring SE ............................................................... 46
Table 18 – FI-PPP Phase3 SMEs: Accounts Creation Status ....................................................... 74
Table 19 - Catalogue: Subscriptions Administration Area .............................................................. 75
Table 20 – IssueTracker: issues related to the Catalogue ............................................................. 76
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 10 of (78)
Abbreviations
ABAC Attribute Based Access Control
AES Advanced Encryption Standard
API Application Programming Interface
ASN.1 Abstract Syntax Notation One
ATNA Audit Trail and Node Authentication
BPPC Basic Patient Privacy Consents
CEP Complex Event Processing
CIMI Cloud Infrastructure Management Interface
CMP Cloud Management Platform
CPU Central Processing Unit
DC Data Center
DCRM Data Center Resource Manager
DEN Document Encryption
DM Device Management
DNS Domain Naming Server
EPC Evolved Packet Core
ESP Enterprise Service Bus
ETSI European Telecommunications Standards Institute
FBB Functional Building Block
GCP Global Customer Platform
GE Generic Enabler
GUI Graphical User Interface
IaaS Infrastructure as a Service
IdM Identity Management
IHE Integrating the Healthcare Enterprise
LWM2M Lightweight M2M
KPI Key Performance Indicators
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 11 of (78)
M2M Machine to Machine
NaaS Network as a Service
NGSI Next generation Services Interface
NTP Network Time Protocol
OAuth Open Authorization
OF Open Flow
OMA Open Mobile Alliance
ORM Object Relational Mapping
OTT Over The Top
PaaS Platform as a Service
PAP Policy Administration Point
PCRF Policy and Charging Rules Function
PDP Policy Decision Point
PKI Public Key Infrastructure
POP Point Of Presence
QoS Quality Of Service
ReSTFul Representational State Transfer
RTC Real-Time Communication
SaaS Software as as Service
SAML Security Assertion Markup Language
SCIM System for Cross-Domain Identity Management
SDC Software Deployment Configuration
SE Specific Enabler
SIS Secure Internet Service
SLA Service Level Agreement
SLO Service Level Objective
SM Service Management
SPP Service Provider Platform
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 12 of (78)
SSH Secure Shell
SSO Single Sign On
STUN Session Traversal Utilities for NAT
TLS Transport Layer Security
TSL Trust Service Status List
TURN Traversal Using Relays around NAT
UDP User Datagram Protocol
VDC Virtual Data Center
VM Virtual machine
VOIP Voice Over IP
VPN Virtual Private network
XACML eXtensible Access Control Markup Language
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 13 of (78)
Definitions
FI-STAR SE specification
The specification of a FI-STAR Platform software module. Specification requires the definition of an API and of an internal design.
Provided Interface Set of functionalities provided by a software module to an external actor.
Required Interface Set of functionalities requested by a software module to an external software module.
Interaction view Graphical representation of the external modules with which a software module interact with exchange of information.
Application module In the context of this document, application module is a specific part of a system component build leveraging the FI-STAR Platform Module (i.e. the FI-STAR SE)
Graphical User Interface (GUI)
Graphical User Interface (GUI) is a type of external interface that allows users to interact with the application through graphical icons and other visual elements (as opposed to text-based interactions or command line interfaces). It is intended for use by human users.
Application Programming Interface (API)
Application Programming Interface (API) is a type of external interface that supports interactions between the application and external systems (that is, non-human users).
Functional building block (FBB)
Functional building block is a group of one or several functionalities that belong together (in terms of similar design and/or implementation character, role in the solution, etc.). It is a synonym for an application module.
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 14 of (78)
Introduction
Objectives of this document
The main objective of deliverable D2.3 is to provide a report about the second cycle of the development activity of the FI-STAR Back-End Platform components. Such development took care from one side to implement that part of the specification, delivered in D2.1, but not yet covered by the ALPHA development cycle and, on the other, to cover new requirements coming from the issue tracker.
A further objective is to provide a report about the evolution of the Catalogue to support the access to the enablers, by the Application Providers, trying to fulfil their need of a better control of the private cloud access and of an automatic shipment modality. Details are also provided about the Catalogue usage experience of all the actors during this second phase (similarly to what already made in D2.2).
Specifications of this document
Deliverable D2.3 was completed by mid-February 2015 (M23). The actual delivery date is aligned with the planned one by DoW.
The deliverable D2.3 is based on the achievements and outcomes of tasks 2.3 and 2.4 and the implementation activates performed in the period M16-M22. Scope and content of the document are aligned with the definitions and relevant sections of the Description of Work (new DoW contained in the amendment request).
Deliverable structure
The present document consists of two major parts.
Part A – Development Activity Report, describes the development activity of the FI-STAR Back-End Platform SEs by focusing on organisational and management aspects and on the details of the development step. In particular, for each SE is provided an overview section, a table showing the implementation advancement status, for each interface provided in the specifications, and a final report about the FI-WARE technology adoption degree.
Part B – FI-STAR Platform Access Support, describes the offered support to access the FI-STAR Platform. In particular the Section 2 covers the Catalogue system by focusing, in Section 2.1, on the requirements specification (use cases and actors are described in Section 2.1.1 and Section 2.2.2). In Section 2.2, instead, focus is on the design with particular attention to the graphical interface definition (in Section 2.2.1). Finally Section 2.3 takes care to report the experiences and the implemented activities executed by each expected actors, by interacting with the Catalogue itself. Finally Section 3 and Section 4 provide a description of the environments, adopted within the FI-STAR project, as Reference Cloud Environment for the platform deployment.
References present the list of referenced sources.
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 15 of (78)
Part A – FI-STAR Back-End Platform: Development Report
The Part A will give status report of the implementation activities executed in T2.3 during the Beta phase period (i.e. from July 2014 to December 2015). In addition, this section will provide the description of the application that has been recently developed as a joint activity between WP2 and WP3 with the aim of evaluating the interworking of most specific enablers in the front-end and back-end.
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 16 of (78)
1 Implementation Activities
The development activities carried out by WP2 are covering the implementation of a set of Specific Enablers (SE), which may rely on FI-Ware GEs such as Event Service or are loosely de-coupled from FI-Ware GEs such as the Real-time communication service SE. The implementation of the required service modules in the back-end is going to be achieved within a two one-year-spiral-model prototype cycle based on the design specifications delivered by task 2.2.
The implementation activities were carried out in two phases: Alpha and Beta. Those were specified and aligned with the entire project plan and the other working packages, particularly WP3 and WP4. The Alpha phase lasted from mid of Feb/M11 until June/M15 2014. The Beta phase started in Aug/M16 and ended in Dec/M20.
In the Alpha phase, all SEs released the first implementation with a set of supported interfaces (up to 60%) according to the design and specification deliverable D2.1. In the Beta phase, non-implemented interfaces are completed. In addition, SE users have the ability to report bugs and submit new functionalities that are needed through the catalogue, as explained in part B of this deliverable. Based on this information, the SE owner is able to: track reported bugs, solve them, and decide which requirements will be implemented according to the implementation plan and required effort.
In order to validate the interworking capabilities of several SEs on the front-end and back-end, WP2 and WP3 team developed an end-to-end application. The application covers few sensors connected to an Android application through a set of front-end SEs and the collected data is sent to the back-end SEs and rendered web-based application in real-time. The implementation was presented and discussed with all FI-STAR partners in an interactive workshop during the 7th plenary meeting in Rome. The meeting’s purpose was to provide to all FI-STAR developers, a “hands-on” training on the use of various FI-STAR SEs in an end-to-end scenario.
The project analysis showed progress in the implementation. Status was (and continues to be) monitored via the project-level-information documented in the wiki pages. However, the SE owners keep maintaining the latest version of the SE implementation in FI-STAR catalogue. The development activities are going to last until the end of 2014.
The following results were achieved:
The implementation of all SEs is available for all FI-STAR partners/users in FI-STAR catalogue.
The implementation follows the plan defined in the wiki page: http://wiki.FI-STAR.eu/wiki/Beta_implementation_plan.
Development Plans are document by SE. The summary of all SE implementation status and responsible partners is available in the wiki page: http://wiki.FI-STAR.eu/wiki/Development_Plans#FI-STAR_Specific_Enablers_-_Phase_Beta.C2.A0
SE associated wiki page includes a page for each SE and covers four subsections: new requirements, reported bugs, new identified interfaces, and old designed interfaces, which are not implemented in the Alpha phase.
A demo that shows the interworking across different SEs on the front-end and back-end, including two application interfaces in both front-end (patient device) and on the top of the back-end
Each SE supports a set of interfaces and operations that can be validated by other working packages such as WP4, WP5 and WP6.
Figure 1 gives an overview of most of FI-STAR SEs on the front-end and back-end platform. The figure illustrates a potential deployment scenario, which has been validated by means of two applications developed jointly by the WP2 and the WP3 team. The demo focuses on patient monitoring application, where a patient requires observation of his/her health status by means of measured heartbeats. Therefore, the front-end application first renders the collected data to the patient locally on his smart mobile phone and simultaneously sent periodically to the FI-STAR infrastructure. The back-end application retrieves the data from the back-end SE (i.e. the Event Service), where a doctor can track patient heart rate in a real-time through a web-browser. The
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 17 of (78)
reference implementation of both applications and description are available for all FI-STAR partners. With this regard, an interactive workshop for all FI-STAR partners has been conducted during the 7th plenary meeting.
Figure 1: FI-STAR Functional SEs Architecture
The interfaces between FI-STAR SEs are listed as following:
NGSI-9 and 10 are a set of interface specifications defined by OMA (Open Mobile Alliance) and adapted by FI-WARE GEs specification [19].
ETSI M2M is a set of specifications defined by ETSI as a middleware layer between a set of service capabilities and M2M applications, which both can be deployed in the front-end and back-end [20 – 22]
ICE-STUN is a specification defined by IETF in RFC 5245 to allow the client (e.g. a VoIP or WebRTC agent) to resolve its IP address behind the NAT [23 – 24]
OCSP (Online Certificate Status Protocol) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 6960 [25]
The following subsections will give detailed information of the recent implemented interfaces. In case the SE uses a FI-Ware GE, the associated FI-Ware GE version is going to be listed.
FI-STARBack-EndFI-STARFront-End
Connec vityService
SensorDataCollec onService
No fica onService
LocalDataProcessing
Connec vityService
LocalDataStorage
Applica onReal- me
Communica on
Targe ng&profil
i
ng
EventService
DeviceManagement
Privacy&Security
Applica on
ETSIM2MOMALWDMNGSI-9/10ICE-STUN
ETSIM2M
NGSI-9/10
NGSI-9/10
NGSI-9/10 NGSI-9/10
NGSI-9/10
OCSPOCSPICE-STUN
ETSIM2MOMALWDM
Targe ng&profil
i
ng
LegacyEHR
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 18 of (78)
1.1 Connectivity Service Back-End
The connectivity Service Back-End provides a secure connection between the FI-STAR Front-End and back-end service enablers based on CoAP, HTTPs and CoAP-DTLS. Furthermore, it allows applications to trigger the mobile core for resource allocation or retrieve information about the current connectivity status of the mobile device.
1.1.1 Reported bugs and requirements
The following table listed all bugs and submitted new requirements:
ID Summary Status Category Version Reporter Real Name
29 How to configure the SE correctly?
RESOLVED Support Request
ALPHA WP4_APP_DEV_NORWAY
20 Connectivity Service (BE) instance access request for RTC
SE owner
RESOLVED Support Request
ALPHA REAL_TIME_COMMUNICATION_SERVICE_OWNER
30 Can't find openmtc-ngsi package RESOLVED Bug Report
ALPHA WP4_APP_DEV_NORWAY
78 Including communication from the Connectivity Service BE to
the FE
RESOLVED Improvement
Request
ALPHA WP4_APP_DEV_SPAIN
84 Allow integration with the Publish/ Subscribe Context
Broker GE
CONFIRMED Improvement
Request
BETA WP4_APP_DEV_SPAIN
45 web GUI for visualizing the data RESOLVED Improvement
Request
BETA WP4_APP_DEV_ROMANIA
55 pyxb 1.2.3 require; is not mentioned in documentation
RESOLVED Bug Report
ALPHA WP4_APP_DEV_NORWAY
79 HTTP Error 400: BAD REQUEST when trying to connect to Event Service
IN PROGRESS
Support Request
ALPHA WP4_APP_DEV_NORWAY
87 Documentation mentions non-existing files
CONFIRMED Bug Report
BETA WP4_APP_DEV_NORWAY
47 Se services not available on RTC SE owner instance of
BCON (10.9.5.7.)
RESOLVED Support Request
ALPHA WP4_APP_DEV_POLAND
Table 1: Reported bugs and requirements of the Connectivity Service back-end SE
We have solved 7 issues out of 10. Some of the issues required implementation improvement and lead to beta version, some related to documentation were fixed within 2 weeks at most.
1.1.2 New Interfaces
The following interfaces have been determined as new interface based on the recent requirements listed in the previous subsection.
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 19 of (78)
Interface/operation Description Beta candidate
Specified in FI-Ware GE
Implemented by FI-Ware GE
Comments
OTT_Interface create/start session for QoS allocation
POST request to create session, triggers EPC Rx session initiation. The payload should contain the information needed to create the session.
Yes Yes Yes
OTT_Interface delete session/stop session for QoS allocation
DELETE operation to delete a session that has been created.
Yes Yes Yes
OTT_Interface retrieve connectivity information from the EPC
GET operation to retrieve the information about the IP connection with the mobile device
Yes Yes Yes
OTT_Interface subscribe to QoS session info
POST operation to allow the PCRF to notify about any change in the status of the connection. The body of the operation request should include the notification address
Yes Yes No
OTT_interface modify QoS session
UPDATE operation to update the parameter of the session.
Yes Yes No
RTC SE – STUN request Retrieve the mapped (public) IP address (NAT address) and port number that the NAT has allocated for the application's User Datagram Protocol (UDP) connections to remote hosts
Yes No No
Table 2: New interfaces of the Connectivity Service back-end SE
Detailed description of all OTT interfaces can be found in FI-STAR wikipage [15]. The objective of the OTT interface is to allow the applications to trigger QoS parameter over a mobile core following the 3GPP Evolved Packet Core (EPC).
In order to enable the OTT interface to trigger any QoS parameter (i.e. to execute all the operations of the OTT interface), the PCRF (Policy and Charging Resource Function), deployed in the EPC, has to have the Rx interface configured and with the peer associated with the Back End Connectivity SE.
For the RTC interfaces the STUN/TURN/ICE open source project from [23] can be installed.
1.1.3 Old Specified Interfaces
The following interfaces have been specified during the design phased, but implemented in the Beta phase:
Interface/operation Description Specified in FI-
Ware GE
Implemented by FI-Ware GE
Comments
Secure and Reliable Connection and Transport – Receive data
Receive Data operation to receive data over HTTPS and DTLS
No No Based on use case requirement defined in D2.1
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 20 of (78)
Secure and Reliable Connection and Transport – Send data
Send Data operation to send data over HTTPS and DTLS
No No Based on use case requirement defined in D2.1
Mobility Management To send access network discovery and selection policies to the end device
Yes Yes Based on FI-WARE S3C CDI GE
Table 3: Old Specified Interfaces of the Connectivity Service back-end SE
1.1.4 FI-Ware GE specification
The Connectivity Back-End Service supports two secure communication channels based on HTTP and CoAP-DTLS. It allows triggering QoS parameters over 3GPP EPC through the Rx interface and following FI-Ware I2ND S3C-OTT specification. Furthermore, it provides interface to manage the mobility of the end devices following FI-Ware I2ND S3C-CDI specification. The Connectivity Back-End Service SE is composed of the following modules:
HTTP/HTTPs and CoAP/CoAPs Proxy: This module allows external components to transmit HTTP and CoAP messages between applications and user equipment over a secure channel. During the TLS or DTLS handshake, the Connectivity Service SE will require the CA certificate and validation of the UE certificate before application data can be sent by the UE. In this regard, it interconnects with the security and privacy SE to validate UE certificate. It allows infrastructure component (e.g. the Event SE) to register for certain selective data, which can be forwarded in event-based model. As this module is defined according to new requirements defined in FI-STAR, this module does not relay on FI-Ware GEs.
Figure 2: FI-STAR Connectivity Back-End Service and FI-Ware enabled components
NAT Traversal Server: This module allows the FI-STAR devices behind the NAT to be reachable from outside, especially for those applications that act as server e.g. WebRTC client.
FI-STA
RPla
orm
FI-W
AREPla
orm
Resourcemanagement
HTTP/HTTPsandCoAP/CoAP-DTLSproxy
Connec vityServiceBackend
S3C-OTT
EPC-PCRF
QoS
ETSIM2M
OMALWDM OCSP:Validatecer ficate
NGSI-9/10
NATTraversalServerICE-STUN AdminGUI
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 21 of (78)
Resource Management: This module allows the application to push QoS requirements into the mobile core based on 3GPP Rx reference point exposed by the PCRF. For example, an application would like to improve the data transmission quality towards the end user and it will either send a policy to the end user to select another access network or it will use the current access network and enforce the QoS of the communication channel (bearer). The specification of this module follows Fi-Ware S3C EPC-OTT specification.
1.1.5 FI-Ware GE uptake
This SE is designed to be configurable in order to interact with the following components:
- FI-STAR front-end device follows ETSI M2M specification and OMA-Lightweight Device Management. The data is transmitted via HTTP and CoAP, HTTPs or CoAP-DTLS. These delivery capabilities are new features, which are not supported in FI-Ware GEs.
- FI-STAR back-end enabler exposing the FI-WARE NGSI Open RESTful API. Actually, the instances created within the FI-STAR Cloud Environment are proposed to interwork with the Event SE in order to communicate with the front-end users; nevertheless, it is possible to interwork with any component following the current specification.
- This SE forwards all device management messages to the Device Management SE. - This SE interworks with the Security and Privacy SE in order to validate the UE certificate. - This SE exposes the S3C-OTT interfaces through a new reference implementation as FI-
Ware I2ND S3C-OTT implementation has several restrictions and technical limitation. For further details, we recommend to read D2.2.
Although the software above can be used in isolation, it is very useful to consider its usage in conjunction with other FI-STAR enablers (Front-end Connectivity SE, Event SE, Security and Privacy Enabler and Device Management SE) to design more interesting applications. In such scenario the Back-end Connectivity SE mediates messages between the front-end SEs and the back-end SEs. The certificates used in the secure transmission can be generated with the Security and Privacy SE and configured/burned on the Connectivity Front-end SE.
1.2 Event Service
The Event Service SE is used by two parties, Event Sender and Event Receiver.
Event Sender: are system components that issue events in order to inform other system components of user interactions or system changes.
Currently identified Event Sender:
Real Time Human to Human Communication components: VOIP components, WebRTC components
Health Monitoring
Patient GUI
Front-End Notification Service (or Front-End Connector Service / Front-End Gateway)
Event Receiver: are system components that receive events in order to react on user interactions or changes in other parts of the system.
Currently identified Event Receiver:
Profiling/Targeting component interested in content-related events to learn patient interests and patient interaction events in general to provide inactivity monitoring and alarms
Local Data Processing and Decision Support Service interested in measurement events
User monitoring and analysis interested in user GUI interactions
1.2.1 Reported bugs and requirements
The following table lists all bugs and submitted new requirements:
ID Summary Status Category Version Reporter Real Name
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 22 of (78)
19 Access to Event Service at XIFI Berlin from TUC Questionnaire SE
RESOLVED Bug Report
ALPHA HEALTH_QUESTIONNAIRE_SERVICE_OWNER
66 Local instance availability RESOLVED Support Request
BETA WP4_APP_DEV_ENGLAND
13 Event Service instance access request for RTC SE owner.
RESOLVED Support Request
BETA REAL_TIME_COMMUNICATION_SERVICE_OWNER
81 Event sink not notified properly upon updateContext
RESOLVED Support Request
ALPHA WP4_APP_DEV_NORWAY
16 NGSI methods callback causes server error 500.
RESOLVED Support Request
ALPHA REAL_TIME_COMMUNICATION_SERVICE_OWNER
83 VPN problem with Event Service instance at Berlin node
RESOLVED Bug Report
ALPHA WP4_APP_DEV_NORWAY
18 queryContext method returns data for attributtes does not exists at Event Service SE
RESOLVED Bug Report
ALPHA HEALTH_QUESTIONNAIRE_SERVICE_OWNER
50 BEVE instance for RTC SE owner don't respond (10.9.5.3)
RESOLVED Support Request
ALPHA WP4_APP_DEV_POLAND
12 Method to Request Access Token for EventService SE
RESOLVED Support Request
ALPHA HEALTH_QUESTIONNAIRE_SERVICE_OWNER
76 Local instance availability RESOLVED New Feature Request
BETA WP4_APP_DEV_GERMANY
14 Compliance inconsistent with NGSI specification
RESOLVED Bug Report
ALPHA WP4_APP_DEV_ITALY
82 Question: for how long is context data stored in the Event Service?
RESOLVED Support Request
ALPHA WP4_APP_DEV_NORWAY
17 Cross domain problem with JavaScript callbacks
RESOLVED Support Request
ALPHA REAL_TIME_COMMUNICATION_SERVICE_OWNER
Table 4: Reported bugs and requirements of the Event Service SE
All issues have been resolved during the ALPHA and BETA development phases.
1.2.2 New Interfaces
No new interfaces have been determined as new interface, based on the recent requirements listed in the previous subsection.
1.2.3 Old Specified Interfaces
The following interfaces have been specified during the design phased, but implemented in the Beta phased:
Name Description Covered by a FI-WARE GE
API
Implemented by a FI-WARE GE
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 23 of (78)
Specification
int updateContext(event) update context entities
yes no
int queryContext(event) query context entities
yes no
int subscribeContext(String...) subscribe to context
yes no
int updateContextSubscription(String..) update context subscription
yes no
int unsubscribeContext(String...) unsubscribe to context
yes no
int registerContext(event) register context yes no
Table 5: Old Specified Interfaces of the Event Service SE
1.2.4 FI-Ware GE specification
Figure 3: FI-STAR Event Service and FI-WARE enabled components
The Event Service enabler represents an application made of different software layers. As for the architecture above we have:
WEB APP module
This is a web application, which was designed and implemented to help developers to speed up the development process in building an application based on our REST enablers (see the next points). Such application offers the following user interface:
• Authentication Interfaces: Allow to configure OAuth 2.0 access mechanisms and the interaction with the Security and Privacy enabler
Management Interfaces
Authentication Interfaces
ContextBrokerGE
FI-STA
RPla
orm
FI-W
AREPla
orm
Secured
RestAPI
EventService
WebApp
Secured
RestA
PI
FI-WARE NGSI Open RESTful API
Event DB
Event Log
XMLRPC
API
XMLRPC
API
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 24 of (78)
• Management Interfaces: Allow to manage events and to configure and enable the Context Broker GE
SECURE REST API module
This is a REST web service, packaged with the same WEB APP module, conceived to offer the following capabilities:
• Possibility to retrieve and send data following the FI-WARE NGSI Open RESTful API specification
• Possibility to secure the API via OAuth 2.0 with the built-in mechanisms or via the Security and Privacy SE
All these capabilities are offered via REST interface. The full documentation of such REST interface is available in D2.1 and within the User and Programmers guide within the Documentation section.
XMLRPC API module
This is a XMLRPC based web service, packaged with the same WEB APP module in order to extend the FI-WARE NGSI Open RESTful API to allow an additional standardized way of interaction with the Context Broker GE.
All these modules are actually available to FI-PPP partners, Phase 3 accelerators and SMEs selected by accelerators. Access the Get Your SE area to proceed.
1.2.5 FI-Ware GE uptake
This enabler is designed to be configurable in order to interact with any enabler exposing the FI-WARE NGSI Open RESTful API. The instances created within the FI-STAR Cloud Environment, offered to the users, are created adopting the Orion Context Broker GE for publish/subscribe of events.
The presented architecture highlights how this enabler can interact with other enablers in a typical usage scenario. If the software above can be used in isolation it is very useful to consider its usage in conjunction with other FI-STAR enablers (Targeting and Profiling Enabler, Security and Privacy Enabler) to enrich the application with more features. In such scenario, the Event Service will notify the Targeting and Profiling enabler on new data, while the secure REST API configuration is done via the Security and Privacy enabler.
1.3 Targeting and Profiling Service
The Targeting and Profiling Service SE is used to target and profile patients based on events generated by the patients’ context, e.g. measurements or patient-triggered events. It is closely related to the Event Service SE and can be categorized as an Event Receiver. According to the Event Service SE specification, Event Receiver are system components that receive events in order to react on user interactions or changes in other parts of the system. The Profiling and Targeting component is interested in content-related events to learn patient interests and patient interaction events in general to provide inactivity monitoring and alarms and to monitor and analyse user GUI interactions.
1.3.1 Reported bugs and requirements
The following table listed all bugs and submitted new requirements:
ID Summary Status Category Version Reporter Real Name
74 Executable version requested
CONFIRMED New Feature Request
BETA WP4_APP_DEV_GERMANY
41 Enable setting of rules by rest service
CONFIRMED New Feature Request
ALPHA WP4_APP_DEV_ITALY
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 25 of (78)
85 Receive events from Context Broker GE
CONFIRMED Improvement Request
BETA WP4_APP_DEV_SPAIN
Table 6: Reported bugs and requirements of the Targeting and Profiling SE
All issues and new feature request have been implemented during the BETA development phase.
1.3.2 New Interfaces
The following interfaces have been determined as new interface based on the recent requirements listed in the previous subsection.
Provided Interface
Operation Interfaces
Covered by
FIWARE API/
Implemented by FIWARE
GE
cep
addRule yes yes
deleteRule yes yes
updateRule yes yes
Table 7: New interfaces of the Targeting and Profiling SE
1.3.3 Old Specified Interfaces
The following interfaces have been specified during the design phased, but implemented in the Beta phased:
Interface/operation Description Specified in FI-Ware GE
Implemented by FI-Ware GE
Comments
Data analysis Interface(s) for Big Data analysis Yes Yes
Table 8: Old Specified Interfaces of the Targeting and Profiling SE
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 26 of (78)
1.3.4 FI-Ware GE specification
Figure 4 FI-STAR Targeting and Profiling service and FI-WARE enabled components
The Targeting and Profiling enabler represents an application made of different software layers. As for the architecture above we have:
WEB APP module
This is a web application that was designed and implemented to help developers to speed up the development process in building an application based on our REST enablers (see the next points). Such application offers the following user interface:
• Advanced Data Analysis Interfaces: Allowed to configure and enable the Big Data Analysis GE.
• Authentication Interfaces: Allowed to configure OAuth 2.0 access mechanisms and the interaction with the Security and Privacy enabler.
• Management Interfaces: Allowed to manage the CEP Rules, to configure and enable the Data Handling GE as well as the data model.
SECURE REST API module
This is a REST web service, packaged with the same WEB APP module, conceived to offer the following capabilities:
• Possibility to retrieve and send data following the FI-WARE NGSI Open RESTful API specification.
• Possibility to secure the API via OAuth 2.0 with the built-in mechanisms or via the Security and Privacy SE.
All these capabilities are offered via REST interface. The full documentation of such REST interface is available in D2.1 and within the User and Programmers guide within the Documentation section.
Management Interfaces
Authentication Interfaces
Advanced Data Analysis Interfaces
DataHandlingGE
BigDataGE
FI-STA
RPla
orm
FI-W
AREPla
orm
Targe ng&
Profiling
WebApp
Secured
Rest
API
(viaOAuth2.0)
FI-WARE NGSI Open RESTful API
SecuredRest
API
(viaOAuth2.0)
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 27 of (78)
1.3.5 FI-Ware GE uptake
This enabler is designed to be configurable to interact with any enabler exposing the FI-WARE Data Handling GE API. The instances created within the FI-STAR Cloud Environment for this enabler (that are offered to the user) are created adopting the Esper4FastData GE to process complex events.
This enabler also adopts the Big Data GE for big data analysis. The enabler comes with a built-in WebHDFS adapter that can be used with the Big Data GEi or any other enabler exposing the same APIs.
All these modules are available to FI-PPP partners, Phase 3 accelerators and SMEs selected by accelerators.
The presented architecture highlights also how this enabler can interact with other enablers in a typical usage scenario. In fact also if the software above can be used in isolation it is very useful to consider its usage in conjunction with other FI-STAR enablers (Event Service Enabler, Security and Privacy Enabler) to design a more complex and interesting application. In such scenario the Event Service will notify the Targeting and Profiling enabler on new data, while the secure REST API configuration is done via the Security and Privacy enabler.
1.4 Security and Privacy – Integrated Access Control
This Integrated Access Control enabler (IAC) provides RESTful APIs to be accessed by any consumers that require Authentication, Authorization and Audit Logging functionality. These APIs, on the one hand, leverage relevant security standards (e.g. OAuth2, XACML, SCIM, Syslog etc.) and FIWARE security technologies. On the other hand, several enhancements have been taken into account (e.g. the capability to support HL7 FHIR specific attributes, aligned with current interested standard works such as IHE IUA profiles) to adapt with the requirements from healthcare domain. The high level of the architecture and adopted standards are presented as follows:
Authentication (OAuth, OpenID Connect, SAML)
Authorization (OAuth, Fine-grained Access Control via XACML)
Audit Logging (HTTP + Syslog)
Provisioning: User and Role (SCIM), Access Policy (XACML)
Figure 5: High level architecture
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 28 of (78)
1.4.1 Reported bugs and requirements
There were no reported bugs. However, several requirements are identified and taken into account. The following table listed these new requirements:
Req. Nr.
Feature Description Type Beta candidate
1 Securing access to exposed APIs
Exposed APIs should be protected from unauthorized access.
Requirement Yes
2 Specific user attributes support
The IdM enabler needs to support healthcare specific attributes (e.g. care provider, emergency contact etc.). Such attributes are important in various use cases for user identification and authorization.
Requirement Yes
3 More APIs Some APIs are implemented and updated to better support application developers/consumers.
Requirement Yes
Table 9: New requirements of the Security and Privacy IAC
In order to protect all sensitive published APIs, the FI-WARE access control model is adopted and implemented. As a result, an OAuth access token at HTTP request header is required when accessing such APIs. Moreover, some HL7 FHIR user attributes are taken into account to support our use case requirements. Such attributes can be configured and activated when need. Some new and updated APIs are briefly described as follows. For the detail, please check our documents in the FI-STAR catalogue.
1.4.2 New Interfaces
SCIM-related APIs are introduced in version Beta to manage user identity. To identify a user, a SCIM ID is utilized. Often such ID is not easy to remember when comparing with another unique user attribute like username. As a result we introduce an API allow accessing given user profile through username. Another similar API is for getting Group/Role information. On the other hand, to support patient emergency use case, a sensitive user attribute “emergency” has been specified and two APIs were implemented to manage such attribute.
Interface/ operation Description Specified in FI-Ware GE
Implemented by FI-Ware
GE
GET /Users/username Return detail information about the given user by username
No No
GET /Users/<username>/emergency
Return emergency status of given user
No No
PUT /Users/<username>/emergency
Update emergency status of given user
No No
GET /Groups/<name> Return detail information about the given group by username
No No
Table 10: New interfaces/operations of the Security and Privacy IAC
1.4.3 Old Specified Interfaces
Additionally to the new APIs, some interfaces/operations have been updated in the Beta phased either to comply with FI-WARE API open specification (e.g. Authorization PDP GE) or to enhance their capabilities (e.g. audit logging APIs).
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 29 of (78)
Interfaces/Operations Description Specified in FI-Ware GE
Implemented by FI-Ware GE
PUT /scim/Group/<groupid> Update membership information (e.g. add/remove a user from given group/role)
No No
POST /authz/domains/<domain>/pdp/authorize Return access control decision (Allow or Deny)
No No
POST /authz/domains/<domain>/pdp Return access control decision (Allow or Deny)
Yes Yes
GET /authz/domains/<domain>/pap/policySet Return all access policies
Yes Yes
POST /authz/domains/<domain>/pap/policySet Create new XACML access policy
Yes Yes
DELETE /authz/domains/<domain>/pap/policySet/<policyid>
Remove the given policy
Yes Yes
GET /authz/domains/<domain>/pap/policySet/<policyid>
Return detail information about given policy
Yes Yes
GET /log View log messages based on given criteria (e.g. date, keyword)
No No
GET /log/<userid> View log messages of given user
No No
Table 11: Old Specified Interfaces/Operations of the Security and Privacy IAC
1.4.4 FI-Ware GE specification
The FI-STAR Security and Privacy IAC is compliant with the FIWARE GE architecture and took into account two GEs: IdM GE and Access Control GE (the new name is Authorization PDP), to provide centralized authentication and authorization service (adopting FI-WARE access control model). Moreover, it is worth to mention that this enabler adopts FI-WARE API Access Control model to protect its sensitive APIs.
1.4.5 FI-Ware GE reference implementation
The security and privacy SE has taken into account two FI-WARE GE open specifications: IdM GE and Authorization PDP GE. We have also investigated existing related FI-WARE implementations. Due to our specific requirements, the adopted IdM GEi needs to support several security standards such as OAuth2, OpenID Connect, SAML etc. and our specific user attributes as mentioned above. Several FI-WARE implementations can provide such functionalities like GCP IdM or DigitalSelf. However, at that point in time, we cannot make use of them because they only provide as service. In FI-STAR, the provided solutions must be deployable not only on cloud but also in customer
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 30 of (78)
premise (e.g. hospital). There is one open source IdM named KeyRock that can fulfil part of our requirements, still several functionalities are missing such as the capabilities to support new healthcare specific attributes or the support identity federation standard SAML. We also contacted with FIWARE GE owners and such functionalities will not be available in upcoming releases and the only way is to modified the given source code. Our initial idea when designing our enabler is that it should be API-centric (our implementation should communicate with FIWARE GE through available APIs). As a result, we have selected a popular open source solution in our implementation: WSO2 Identity Server (version 4.6.0). Such solution provides functionalities of both FI-WARE IdM and Authorization PDP. However, as the architecture is API-centric, such functionality can be given by other implementations in the future.
Furthermore, with respect to the recommendation to increase a direct adoption of the FI-WARE GEs products we have recognized it and stressed the modularity design principle as much as possible also within the FI-STAR enablers. The Security & Privacy IAC architecture are now updated and will be implemented to be flexible enough in order to interact with any implementations of the IdM GE and Authorization PDP GE.
1.5 Mediation Service
The Mediation Services offers the possibility to create services to mediate messages, combining the available mediation tasks. In FISTAR, it allows to interact with legacy system in the health sector (existing eHR, existing hospital systems, etc.), including tasks and templates of services that fulfil the requirements aroused along the project.
1.5.1 Reported bugs and requirements
No bugs aroused and no new requirement submitted.
1.5.2 New Interfaces
No new interfaces.
1.5.3 Old Specified Interfaces
The following interfaces have been specified during the design phased, but implemented in the Beta phased:
Interface/operation
Description Specified in FI-
Ware GE
Implemented by FI-Ware GE
Comments
iemail
sendEmail. This operation is used to send an
email message
Input: Structure with data to be sent in email:
Subject, content, from, to, cc, user, password
Output: A boolean value to indicate the execution result
No No
iManagement
Operation: updateMediationTask. This is the
basic operation to manage operation tasks. if the
task does not exist is created if the task exists is
updated and if the task is empty is deleted
Input: The expected task to be updated
Output: Identification of the task or error code
Mediator GE
No
iEvents provided
Operation: registerContext. This operation is
used route the petition to the event service to
create the “context” or event for the notification
Input: The expected request body is an instance
No No
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 31 of (78)
of registerContextRequest
Output: The expected response body is an
instance of registerContextResponse Interface
Operation: subscribeContext. This operation is
used to route the creation of a subscription for a
specific event of the notification
Input: The expected request body is an instance
of subscribeContextRequest
Output: The expected response body is an
instance of subscribeContextResponse
Operation: unsubscribeContext. This operation is
used to route the deletion of a subscription for a
specific event of the notification
Input: The expected request body is an instance
of unsubscribeContextRequest
Output: The expected response body is an instance of unsubscribeContextResponse
event required
Operation: registerContext. This operation is
used to create the “context” or event for the
notification
Input: The expected request body is an instance
of registerContextRequest
Output: The expected response body is an
instance of registerContextResponse
Operation: updateContext. This operation is used
to update the value of the event of the notification
Input: The expected request body is an instance
of updateContextRequest
Output: The expected response body is an
instance of updateContextResponse
Operation: subscribeContext. This operation is
used to create a subscription for a specific event
of the notification
Input: The expected request body is an instance
of subscribeContextRequest
Output: The expected response body is an instance of subscribeContextResponse
No No
iOauth
Operation validate token
Input: message request with token access
Output: message response with validation status
No No
Table 12: Old Specified Interfaces of the Mediation Service Enabler
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 32 of (78)
1.5.4 FI-Ware GE specification
Figure 6: FI-STAR Mediation Service and FI-Ware enabled components
Mediation Service enabler implements Mediator GE Open restful specification. These describe iManagement interfaces.
Other Interfaces are dedicated to the specific domain and represent the mediation services that satisfies requirement aroused during the FI-STAR project.
Our Mediation Services enabler really represents a whole application made of different software layers. As for the architecture above we have:
WEB APP module
This is a web application, which was designed and implemented to help developers to speed up the development process in building an application based on our REST enablers (see the next points). Such application offers the following user interface:
• Management Interfaces: Allow to manage mediation services and to configure and instantiate new mediation interfaces
Mediator Open RESTful specification compliant ENABLER
This is a REST web service, packaged with the same module, conceived to offer the following capabilities:
• Possibility to manage mediation services, using the available mediation tasks.
Mediation Services module
This is a REST web service, packaged with the same module, offering examples and templates of mediation services that fulfil requirements of the health domain aroused during FI-STAR project.
The package is conceived to offer templates and examples of preconfigured services with the following capabilities:
• Possibility to send an email message.
• Possibility to retrieve and send data following the FI-WARE NGSI Open RESTful API specification.
• Possibility to secure the APIs via OAuth 2.0
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 33 of (78)
• Possibility to mediate the message to SOAP, REST,
• Possibility to re-map the contents,
• Possibility to translate to and from HL7
All these capabilities are offered via REST interface. The full documentation of such REST interface is available in D2.1 and within the User and Programmers guide within the Documentation section.
All these modules will be available to FI-PPP partners, Phase 3 accelerators and SMEs selected by accelerators. Access the Get Your SE area to proceed.
Really the presented architecture highlights also how this enabler can interact with other enablers in a typical usage scenario. In fact also if the software above can be used in isolation it is very useful to consider its usage in conjunction with other FI-STAR enablers (Event Service Enabler, Target and profiling enabler, Security and privacy enabler) to design a more complex and interesting application. In such scenario our enabler interacts with the rest of the software using events managed by event services. Typically messages are mediated towards legacy systems (hospital system) and messages are secured with the interaction with Security and privacy.
It is designed to be able to receive messages directly from other modules in NGSI and JSON format (i.e. Target and profiling enabler)
1.5.5 FI-Ware GE uptake
Our enabler should have been built on top of Mediator GE, but this was discontinued. The last release did not include the forecasted Management APIs.
1.6 Health Questionnaire Service
Questionnaires are widely used in the healthcare sector. The Health Questionnaire SE allows to:
Create simple assessment (on-demand) and monitoring (periodicity based) questionnaires;
Schedule monitoring questionnaires;
Collect the results from the questionnaires;
(optionally) to store questionnaire models and results into the repository based on configuration options;
Access questionnaires logs (i.e. historical data) in the questionnaires are stored locally;
Keep audit trail (i.e. log of actions as read, accomplish, identifying the user that accesses the information and the accessed user information);
Publish (optional) new questionnaire context event into the Publish/Subscribe Context Broker GE and Event Service SE to be used by other components, based on configuration options.
1.6.1 Reported bugs and requirements
The following table listed all bugs and submitted new requirements:
ID Summary Status Category Version Reporter Real Name
60 The questionnaire schedule should include the reference to the telecare program in order to be able to define
different telecare programs
RESOLVED Bug Report ALPHA WP4_APP_DEV_SPAIN
62 Include new operations to get the list of pending questionnaires (status, health,
drug follow up and side effects questionnaires)
RESOLVED Improvement Request
ALPHA WP4_APP_DEV_SPAIN
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 34 of (78)
10 Include a new operation to generate the schedule of the monitoring questionnaire based on their
periodicity, completion interval and collection time intervals.
RESOLVED New Feature Request
ALPHA HEALTH_QUESTIONNAIRE_SERVICE_OWNER
64 Include new operations to get the list of pending questionnaires for current
date-time
RESOLVED Improvement Request
ALPHA WP4_APP_DEV_SPAIN
40 NGSI content type for Answers event is wrong
RESOLVED Improvement Request
BETA WP4_APP_DEV_ITALY
72 Keep audit trail log RESOLVED New Feature Request
ALPHA WP4_APP_DEV_SPAIN
57 Update field types into de data base model in order to support DB
independence
RESOLVED Improvement Request
BETA WP4_APP_DEV_SPAIN
80 Include integration with the Publish/ Subscribe Context Broker GE
RESOLVED New Feature Request
BETA HEALTH_QUESTIONNAIRE_SERVICE_OWNER
61 Include new operations to access historical data
RESOLVED New Feature Request
ALPHA WP4_APP_DEV_SPAIN
9 Include specific operations to get the questionnaire model and to save the
results of the assessment and monitoring questionnaires
RESOLVED Improvement Request
ALPHA HEALTH_QUESTIONNAIRE_SERVICE_OWNER
63 Include new operation to get the total number of pending monitoring
questionnaires
RESOLVED Improvement Request
ALPHA WP4_APP_DEV_SPAIN
11 Include a new operation to get the scheduled monitoring questionnaire
RESOLVED New Feature Request
ALPHA HEALTH_QUESTIONNAIRE_SERVICE_OWNER
65 Include new operation to allow the professional to access the results of a
specific patient
RESOLVED Improvement Request
ALPHA WP4_APP_DEV_SPAIN
56 Include a new field in the database RESOLVED Improvement Request
BETA WP4_APP_DEV_SPAIN
73 include operation to configure the SE RESOLVED Improvement Request
ALPHA WP4_APP_DEV_SPAIN
Table 13: Reported bugs and requirements of the Health Questionnaire SE
We have resolved all the issues within 2 weeks (i.e. average. time) from notice.
1.6.2 New Interfaces
The following provided interfaces have been determined as new interface based on the recent requirements listed in the previous subsection.
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 35 of (78)
Provided Interface/operation
Description Beta candidate
Specified in FI-
Ware GE
Implemented by FI-Ware
GE
Comments
iQuestionnaireUI/ getQuestionnaireMonitoringScheduleNum
Gets the number of pending scheduled monitoring questionnaires (for current date time)
Yes Not applicable
Not applicable
Due to R7.2 (Issue 63)
iQuestionnaireUI/ getQuestionnaireStatusList
Gets the list of pending scheduled status monitoring questionnaires (for current date time)
Yes Not applicable
Not applicable
Due to R7.2 (Issue 62)
iQuestionnaireUI/ getQuestionnaireStatusList
Gets the list of pending scheduled status monitoring questionnaires (for current date time)
Yes Not applicable
Not applicable
Due to R7.2 (Issue 62)
iQuestionnaireUI/ getQuestionnaireHealthList
Gets the list of pending scheduled health status questionnaires (for current date time)
Yes Not applicable
Due to R7.2 (Issue 62)
iQuestionnaireUI/ getQuestionnaireDrugFollowUpList
Gets the list of pending scheduled drug follow up questionnaires (for current date time)
Yes Not applicable
Not applicable
Due to R7.2 (Issue 62)
iQuestionnaireUI/ getQuestionnaireDrugSideEffectsList
Gets the list of pending scheduled side effects questionnaires (for current date time)
Yes Not applicable
Not applicable
Due to R7.2 (Issue 62)
iQuestionnaireUI/ getListQuestionnaireItemsStatusDrugFollowUp4User
Gets the list of status monitoring and drug follow up questionnaire items related to an user)
Yes Not applicable
Not applicable
Due to R8.1 (Issue 61)
iQuestionnaireUI/ getListQuestionnaireItemsStatusDrugFollowUp4User
Gets the list of status monitoring questionnaire items related to an user)
Yes Not applicable
Not applicable
Due to R8.1 (Issue 61)
iQuestionnaireUI/ getListQuestionnaireItemsDrugFollowUp4User
Gets the list of drug follow up questionnaire items related to an user)
Yes Not applicable
Not applicable
Due to R8.1 (Issue 61)
iQuestionnaireUI/ getQuestionnaireStatusDrugFollowUpFilter
Filters status monitoring questionnaires and drug follow up questionnaires (for current date time)
Yes Not applicable
Not applicable
Due to R8.1 (Issue 61)
iQuestionnaireUI/ getQuestionnaireStatusFilter
Filters status monitoring questionnaires (for current date time)
Yes Not applicable
Not applicable
Due to R8.1 (Issue 61)
iQuestionnaireUI/ Filters drug follow up Yes Not Not Due to
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 36 of (78)
Provided Interface/operation
Description Beta candidate
Specified in FI-
Ware GE
Implemented by FI-Ware
GE
Comments
getQuestionnaireDrugFollowUpFilter
questionnaires (for current date time)
applicable applicable R8.1 (Issue 61)
iQuestionnaireUI/ getQuestionnaireHealthFilter
Filters health monitoring questionnaires (for current date time)
Yes Not applicable
Not applicable
Due to R8.1 (Issue 61)
iQuestionnaireUI/ getQuestionnaireDrugSideEffectsFilter
Filters side effects questionnaires (for current date time)
Yes Not applicable
Not applicable
Due to R8.1 (Issue 61)
iQuestionnaireUI/ getQuestionnaireModelWithResuts
Gets the log (stored information) of the selected questionnaire. Includes audit trail log
Yes Not applicable
Not applicable
Due to R8.1 (Issue 61)
iQuestionnaireUI/ getQuestionnaireModelData
Gets the results of a specific patient. Includes audit trail log
Yes Not applicable
Not applicable
Due to R8.2 (Issue 65)
iQuestionnaireAdmin/ setQuestionnaireConfiguration
Sets SE configuration values Yes Not applicable
Not applicable
Due to R9.1 Issue (73)
iQuestionnaireAdmin/ getQuestionnaireConfiguration
Gets SE configuration value Yes Not applicable
Not applicable
Due to R9.1 Issue (73)
Table 14: New provided interfaces/operations of the Health Questionnaire SE
The following required interfaces have been determined as new interface based on the recent requirements listed in the previous subsection.
Required Interface/operation
Description Beta candidate
Specified in FI-Ware GE
Implemented by FI-Ware GE
Comments
iEvents/ queryContext
To query the “context” or event for the notification (Context Broker GE)
Yes Not applicable
Not applicable
Due to R9.2 (Issue 80)
iEvents/ updateContext
To create/update the value of the event of the notification (Context Broker GE)
Yes Not applicable
Not applicable
Due to R9.2 (Issue 80)
Table 15: New required interfaces/operations of the Health Questionnaire SE
1.6.3 Old Specified Interfaces
The following interfaces have been specified during the design phase or developed during the Alpha phase, but they have been updated or implemented in the Beta phase:
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 37 of (78)
Interface/operation Description Specified in FI-Ware GE
Implemented by FI-Ware GE
Comments
iQuestionnaireUI/ getQuestionnaireModel
Gets the model of a concrete questionnaire in a particular language, including audit trail log.
Not applicable
Not applicable
Included in Alpha and updated in Beta release due to R10.1 (Issue 72)
iQuestionnaireUI/ saveQuestionnaireModel
Saves the collected data from a questionnaire in data storage and/or publish to event service, including audit trail log.
Not applicable
Not applicable
Included in Alpha and updated in Beta release due to R10.1 (Issue 72); R2.16 (issue 40)
iQuestionnaireUI/ setQuestionnaireMonitoringSchedule
Executes the schedule of monitoring questionnaire (taking into account telecare program).
Not applicable
Not applicable
Included in Alpha and updated in Beta release due to R10.1 (Issue 72)
iQuestionnaireUI/ getQuestionnaireMonitoringSchedule
Gets a descriptive list of the monitoring questionnaires scheduled for a specific date interval and use (taking into account telecare program)
Not applicable
Not applicable
Included in Alpha and updated in Beta release due to R10.1 (Issue 72)
iQuestionnaireAdmin/ loadFile
Loads the questionnaire model from a file and stores it (local file at machine instance).
Not applicable
Not applicable
Included in Alpha and updated in Beta release due R2.14 (issue 56); R2.15 (Issue 57).
iQuestionnaireAdmin/ Load
Loads the questionnaire model from a file and stores it (file is included as a parameter).
Not applicable
Not applicable
New in Beta release. Simplifies questionnaire model loading and replaces dismissed administrative operations.
Table 16: Old Specified Interfaces of the Health Questionnaire SE that have been updated or developed in the Beta phase
Several administrative operations such as:
(1) setQuestionnaire ,
(2) updateQuestionnaire,
(3) deleteQuestionnaire,
(4) setQuestionnaireItem,
(5) updateQuestionnaireItem,
(6) deleteQuestionnaireItem,
(7) setQuestionnaireItemAnswerSet,
(8) updateQuestionnaireItemAnswerSet and
(9) deleteQuestionnaireItemAnswerSet) are dismissed due to work prioritisation.
New, not initially planned, operations and updates have been included in the Health Questionnaire during Alpha M2 and Beta to cover new improvements and features requests. The loadFile and
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 38 of (78)
Load operations already allow loading questionnaire models into the database. The dismissed administrative interfaces only tried to provide another way to load the questionnaire model but do not provided new capabilities.
The following interfaces were specified during the design phase and developed during the Alpha phase, but they have been updated or implemented in the Beta phase:
Interface/operation Description Specified in FI-Ware GE
Implemented by FI-Ware
GE
Comments
iAuthoriisation/ createUserToken
Set the valid user & token Not applicable Not applicable Developed in Alpha phase.
iAuthoriisation/ deleteUserToken
Delete user & token Not applicable Not applicable Developed in Alpha phase.
iAuthoriisation/ updateUserToken
Delete user & token Not applicable Not applicable Developed in Alpha phase.
iAuthoriisation/ getUserToken
Gets the User token Not applicable Not applicable Developed in Alpha phase.
uthoriisation/ getUserTokenLIst
Gets the list of valid user token
Not applicable Not applicable Developed in Alpha phase.
iQuestionnaireUI/ etQuestionnaireResult
Gets the results of a specific questionnaire in JSON format
Not applicable Not applicable Developed in Alpha phase.
iQuestionnaireUI/ getQuestionnaireResultXML
Gets the results of a specific questionnaire in XML format
Not applicable Not applicable Developed in Alpha phase.
Table 17: Old Specified Interfaces of the Health Questionnaire SE that have been developed in the Alpha phase and have not been changed
1.6.4 FI-Ware GE specification
The Health Questionnaire SE is a completely new Specific Enabler coming from the analysed requirements. No FI-Ware specification has been adapted and possibly extended while the implementation of the Beta phased.
1.6.5 FI-Ware GE reference implementation
Not applicable. Refer to the above section.
1.7 Device Management
The Device Management service SE supports various management functions on the end devices. It allows the application or administrator to discover, configure and monitor the end devices. In order to meet FI-STAR requirements for support constrained devices, the Device Management SE follows the OMA Lightweight M2M Device Management (LW M2M DM) specification, which is based on CoAP protocol. Furthermore, it exposes ETSI M2M REST APIs (based HTTP) to the applications and admin GUIS.
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 39 of (78)
1.7.1 Reported bugs and requirements
The following table listed all bugs and submitted new requirements:
Req. Nr.
Feature Description Type Requester Beta candidate
39 Change any Zephyr parameter from outside, using API
Is it possible to change any Zephyr parameter using API (i.e. to control Zephyr sensing's parameter from outside / Smartphone)
New Feature Request
FZI_SE_owner
Yes
Table 13: Reported bugs and requirements of the Device Management SE
This requirement was created for the front end Sensor Data Collection Service SE. This requirement was further generalized into Configuration management and Remote actuation for the Device Management SE to allow remote operation of the sensors and actuators. This request was fixed as beta delivery.
1.7.2 New Interfaces
A Web GUI to display the registered user endpoints and their available eHealth devices is implemented. The web GUI allows selecting which devices to connect or disconnect and triggered from the SDCS Beta requirements.
The Device Management SE is extended for processing the Device Capability Management Object introduced by oneM2M as an extension to Lightweight M2M standard.
The Lightweight M2M standard is based on CoAP, an extension for supporting also web interface is be implemented.
The following interfaces have been determined as new interface based on the recent requirements listed in the previous subsection.
Interface/operation Description Beta candidate
Specified in FI-
Ware GE
Implemented by FI-Ware
GE
Comments
Device Property Management – Discovery
The Discovery operation allows the user/admin to discover and retrieve all endpoints and devices.
Yes No No
Device Property Management – endable-device
The enable-device operation allows the user/admin to enable dedicated device.
Yes No No
Device Property Management – disable_device
The disable_device operation allows the user/admin to disable a dedicated device.
Yes No No
Device Property Management – enable_property
The enable- property operation allows the user/admin to enable dedicated property or certain device
Yes No No
Device Property Management – disable_property
The enable- property operation allows the user/admin to disable dedicated property or certain device, e.g. of such property: RemoteConfiguration
Yes No No
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 40 of (78)
Device Connectivity retrieval
Monitor_connectivity operation allows the service provider to monitor the local connectivity of the mobile device.
Yes No No
Sensor Device information retrieval
Manufacturer, Serial Number, Model name, Attached sensing instruments (A sensor device can measure multiple phenomenon).
Yes No No Can include battery level, and firmware version, but the Protocol Adapter does not support them
Sensor supported commands retrieval
Expose the command list the sensor is supporting.
Yes Yes Yes
Sensor Connectivity retrieval
Monitor connectivity of a sensor to the mobile device.
Yes No No
Device Actuation Send a command to a Sensor attached to the end device.
Yes Yes Yes, not tested
Device Configuration
Allow an App to configure remotely a sensor connected to a mobile device.
Yes Yes Yes
Web GUI Web-based GUI to allow the user/admin to perform all perform all operation listed above.
Yes No No
Table 19: New interfaces of the Device Management SE
1.7.3 Old Specified Interfaces
We focused mainly on the Alpha implementation on scalability of the SE as we did not have further interfaces to be implemented.
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 41 of (78)
1.7.4 FI-Ware GE specification
Figure 7: FI-STAR Device Management Service and FI-Ware enabled components
The specification of the Device Management SE service follows the FI-Ware IoT Configuration Management GE and the operations of the IoT Device Management GE, as depicted in Figure 7. To meet the requirements of FI-STAR concerning device constrains due to power and resources, we decided to follow the OMA Light-weight M2M device management specification based on CoAP for device management rather than ETSI M2M followed by FI-Ware IoT Device Management GE specification, which is based on HTTP. In spite of that, this SE exposes its functions to an admin interfaces following ETSI M2M specification. Furthermore, this SE extends FI-Ware specification with new operations listed in Table 20. The LWM2M protocol can be used for software and firmware update, lock & wipe mechanism to prevent further use after a device is stolen.
FI-STAR SE is aligned with ETSI M2M specification towards the application, while the FIWARE GE Back End Device Management relies on SensorML with HTTP as transport. On the other hand, OMA LW M2M specification is designed for constrained devices by saving energy though the use of CoAP as transport protocol instead of HTTP, which is used by the FIWARE GE. As the FI-WARE device management GE supports the ETSI M2M interface towards the device, it can theoretically use this SE to manage end devices, which support only OMA LW M2M.
1.7.5 FI-Ware GE uptake
We have tested both FI-Ware GEs, the back-end Device Management GE and the Configuration Management GE. Due to FI-STAR requirements and the evaluation results for using one or both GEs were not successful, we decided to implement the envisioned functionalities in one SE rather than in two separated components. The results of the evaluation have been explained in D2.2.
1.8 Real-time Communication Service
The Real Time Communication Service (H-H) (BE) SE offers services enabling audio-video conferencing session management capabilities according to the WebRTC protocol. In particular, for the FI-STAR project, this SE enables conducting online audio-video medical consultations and
FI-STA
RPla
orm
FI-W
AREPla
orm
DeviceManagement
DeviceManagementServer
AdminGUI
Configura onManagement
Configura onManagement
OMALightweightDMbasedonCoAP
DeviceManagement
NGSI-9/10NGSI-9
ETSIM2M
ETSIM2M
Connec vityMonitoring
Remoteactua on
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 42 of (78)
remote supervised rehabilitation sessions. The main functionality of this SE is to provide signaling, presence, session management and monitoring infrastructure for WebRTC streaming clients (peers). The media streaming (audio, video) and front-end clients are a matter of a particular WebRTC implementation and are out of the scope of this FI-STAR back-end platform element. The objective of this SE is to provide a Back-End infrastructure for webRTC protocol.
1.8.1 Reported bugs and requirements
There were no additional requirements issued for the Real-Time Communication Service.
The following table listed all submitted bugs:
Req. Nr.
Feature Description Type Requester Beta candidate
1.1 Problems with parallel video sessions
Only one session at the time can be conducted for only two peers. Bug was not issued by Issue Tracking systems - direct email used. Bug is resolved. Appropriate changes introduced on both cloud FI-STAR environments.
Bug WP3 Leader
YES
Table 20: Reported bugs and requirements of the RTC SE
1.8.2 New Interfaces
There was no need to provide new interfaces or methods due to no additional requirements issued for the Real-Time Communication Service.
1.8.3 Old Specified Interfaces
The following interfaces have been specified during the design phased, but implemented in the Beta phased:
Interface/operation
Description Specified in FI-Ware GE
Implemented by FI-Ware GE
PUT /admin/sessions/close-all
Close all active sessions without
interrupting on going video-conferences.
After this call users will not be able to join
previously created sessions.
No No
GET /admin/users List all registered users (active & inactive). No No
PUT /admin/block Restrict / allow access to the
SessionManager by user name. If a user
is blocked from accessing a video
session, all calls to /sessions?
user=[USER] will return an empty list. This
call will not interrupt on-going
videoconferences.
PUT
/admin/users/__[USER]__?active=__[true|
false]__
No No
GET /admin/status Return current status of the
SessionManager.
No No
Table 14: Old Specified Interfaces of the Real-Time Communication SE
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 43 of (78)
1.8.4 FI-Ware GE specification
The FI-STAR Real-Time Communication SE is a completely new Specific Enabler designed and implemented based on specific FI-STAR requirements. The FI-STAR Real-Time Communication SE does not relay on FI-WARE GE specification due to the fact that by the time it was designed no FI-WARE p2p video conferencing GE was not identified. However the concept of the advanced Stream Oriented GE available currently is similar to the capabilities offered Real-Time Communication and could be potentially merged with the Stream Oriented GE.
1.8.5 FI-Ware GE uptake
The Real-Time Communication SE implementation is a new software component. Currently, FI-WARE offers the Stream Oriented GE and its Kurento implementation offering similar capabilities to the Real-Time Communication SE (basing on WebRTC protocol, node.js web sockets and RESTful API). Real-Time Communication SE implementation in future can be potentially substituted by Stream Oriented GE or can be included extending its capabilities.
1.9 Time Service
The Time Service SE enables other modules to use it and to get accurate time for orchestrating events to be occurred, keep transaction integrity high and maintain authentication and logging features. To this purpose, the Time Service SE synchronizes with an official - source time information and makes time and date data available as a service. This time information is distributed over several stages within the FI-STAR Back-End Platform and offered upon request to other platform components. The Time Service SE provides a RESTFul API solution that uses a custom HTTP scheme to allow communication.
1.9.1 Reported bugs and requirements
The following table listed all bugs and submitted new requirements:
ID Summary Status Category Version Reporter Real Name
46 No documentation for img file Resolved Support Request
ALPHA WP4_APP_DEV_NORWAY
44 No documentation for img file Resolved Support Request
ALPHA WP5_APP_PROV_NORWAY
48 Should http://server/time-service/time be redirected to
time.php etc?
Resolved Support Request
ALPHA WP4_APP_DEV_NORWAY
Table 22: Reported bugs and requirements of the Time Service SE
We have resolved all the requests for support (3) and we have provided direct support, guidelines and training material in the FIWARE e-learning platform (a number of 3 out of 3 issues within 1 week from notice).
1.9.2 New Interfaces
No new services have been developed.
1.9.3 Old Specified Interfaces
No old services have to be developed.
1.9.4 FI-Ware GE specification
We have not found any FI-Ware GE specification available to follow.
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 44 of (78)
1.9.5 FI-Ware GE reference implementation
We have not found any FI-Ware GE implementation available to use.
1.10 Monitoring Service
The Monitoring Service SE provides monitoring information about the used resources as well as the deployed services to multiple stakeholders: administrators, end-users and other FI-STAR Back-End Platform components. It supports cross-layer monitoring from low-level infrastructure resources (physical and virtual) up to application level. In this prospective, several system related metrics, such as processor load, RAM consumption, network throughput and latency, as well as services specific parameters like availability, load, throughput, downtime and failure rate, are measured. It allows its user to define own customized (user-defined) metrics. Measurement data is provided on-demand through different interfaces.
1.10.1 Reported bugs and requirements
There were no reported bugs. However several requirements in terms of supporting different kind of user roles are identified.
The following table listed these new requirements:
Req. Nr.
Feature Description Type Requester Beta candidate
1.1 APIs should support tenant & app KPIs
list of KPIs/metrics related to monitoring the running tenants as well as the apps being developed needs to be measured and provided through the monitoring service SE
requirement
Technical Leader
Yes
Table 15: Reported requirements of the Monitoring SE
1.10.2 New Interfaces
The following interfaces have been determined as new interface based on the recent requirements listed in the previous subsection.
Interface/ operation
Description Beta candidate
Specified in FI-Ware GE
Implemented by FI-Ware GE
JSON-RPC API /
create
Create the following metrics through probes (python scripts) that needs to be done by the admin of the monitoring service SE:
No. of created tenants
List of tenants (their names)
No. of SEs per tenant = list of instances per tenant
Allocated no. of vCPU per tenants (aggregated item
of all SEs) (provided as well in graph that can be
shown through the Portal)
Allocated RAM per tenant (aggregated item of all
SEs) (provided as well in graph that can be shown
through the Portal)
Allocated hard disk space per tenant (aggregated
item of all SEs) (provided as well in graph that can
be shown through the Portal)
Used CPU user time per tenant (aggregated item of
all SEs) (provided as well in graph that can be shown
through the Portal)
Used Memory per tenant (aggregated item of all
SEs) (provided as well in graph that can be shown
Yes No No
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 45 of (78)
through the Portal)
Used Bandwidth (aggregated item of all incoming
traffic on interfaces of all SEs) per tenant (provided
as well in graph that can be shown through the
Portal)
Time consumed to develop an App = operating time
of a tenant
Lines of code per App (this can be supported
through a script that I created to include any user-
defined, app-specific metric that is configured to
send a REST call for instance to github asking for
lines of code committed)
Log data probe (a python script that can be executed
either by an SE user or after rebooting the image if
the zabbix agent is already running, it can be
configured to provide the location of any log file
needed to be stored in the monitoring service SE)
No. of logins App (supported through log data probe
to log the data of the context broker and gunicom log
files in the event service SE)
JSON-RPC API / get
get<Metric_Name>
Retrieving information about the above listed metrics.
Yes No No
JSON-RPC API /delete
delete<Metric_Name>
Delete an existing metric of the above listed metrics.
Yes No No
JSON-RPC API /
update
update<Metric_Name>
Update an existing metric (the above listed metrics) with new measures
Yes No No
JSON-RPC API / exist
exist<Metric_Name>
Check whether an metric the above listed metrics exist
Yes No No
RESTfull API / get
get list of graph IDs per host in order then to browse
these from anywhere as long as you are
authenticated and authorised to get data. These
graphs represent measurement data of particular
KPIs that needed to be visualised and shown as
GUIs and probably integrated with the FI-STAR
provided portals. List of graphs of the supported
KPIs:
Allocated no. of vCPU per tenants
Allocated RAM per tenant
Allocated hard disk space per tenant
Used CPU user time per tenant
Used Memory per tenant
Used Bandwidth per tenant
CPU Load per SE
Memory consumption per SE
Network traffic on interfaces per SE
Swap memory per tenant
Yes No No
Table 16: New interfaces of the Monitoring SE
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 46 of (78)
1.10.3 Old Specified Interfaces
The following interfaces have been specified during the design phased, but implemented in the beta phased:
Interface Operation Description Specified in FI-Ware GE
Implemented by FI-Ware GE
JSON-RPC API & RESTful API
getNetworkLatency Provides the network latency between two machines
Yes No
JSON-RPC API & RESTful API
getPacketLoss Provides the packet loss between two machines
Yes No
JSON-RPC API & RESTful API
getServiceAvailability Provides information about the availability status of the deployed SEs and/or services
No No
JSON-RPC API & RESTful API
getServiceLoad Provides information about the service load
No No
JSON-RPC API & RESTful API
getServiceAccessLog Provides access log data of any service
No No
RESTful API getGraphs Provides list of supported graphs that shows the measures in form of graphs
No No
Table 17: Old Specified Interfaces of the Monitoring SE
1.10.4 FI-Ware GE specification
The FI-STAR monitoring SE is compliant with the initial FIWARE Cloud Monitoring GE architecture based on Zabbix product. However, the GE’s API specification was preliminary based on TCloud specification. The specification was not positively evaluated by its users (e.g. FI-STAR and XIFI projects) as it does not fulfil their needs. This has been already reported in FI-STAR D2.1 and D2.2.
The developers of the FIWARE Cloud Monitoring GE who are also involved in the XIFI project decided to change the architecture as well as the specifications completely with the focus on multi-region, federation support as required by the XIFI project. The new FIWARE Monitoring GE is more complex and consists of several other FI-WARE GEs such as the Context Broker GE, BigData GE as well as NGSI Adapters and BigData connecters, etc. At the beginning of FI-STAR project, which is the same time in which XIFI project started, there was neither clear specification nor implementation ready.
FI-STAR is aware of all these changes as TUB which is developing the FI-STAR monitoring SE is also involved in XIFI project and closely working with the XIFI monitoring team.
Furthermore, the requirements driving the new FIWARE Monitoring GE are different that those of FI-STAR that are derived from FI-STAR use-cases (e.g. SEs/services/development oriented KPIs).
In this perspective, FI-STAR has started developing the monitoring SE. In addition to exposing JSPN-RPC it offers a RESTful API to be in line with the FIWARE technologies.
1.10.5 FI-Ware GE reference implementation
According to what discussed in Section 1.10.4, FI-STAR provides its implementation. Considering the work done in parallel to our implementation, the implementation of the new FIWARE Monitoring
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 47 of (78)
GE offers the data in context format stored in the BigData GE. Although they also provide RESTful API specification focuses on federation aspects, there is no implementation available in the FIWARE catalogue yet.
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 48 of (78)
Part B – FI-STAR Platform Access Support
The Part B will give evidence of the activities executed in T2.4 during the Beta phase period (i.e. from July 2014 to December 2015). Coherently with such task description, section 3 will give witness about how the different actors exploited the Catalogue (already described in D2.2) to accomplish their activities during this second phase. Section 2, instead, will describe the design and implementation activities which were needed to enable the automatic shipment and deployment by an Application Provider/Platform Provider in order to better support the software to data paradigm and, at same time, to evolve the Catalogue in the direction of a Marketplace.
It is worth to mention that, considering this document is an evolution of D2.2, it will be avoided to provide explanation on concepts already described there assuming the reader is aware about them.
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 49 of (78)
2 Solution for an Automatic Shipment and Deployment
In this introduction some aspects not completely specified previously will be better explained. In particular a better explanation about the interaction between the Application Developer and the FI-STAR Catalogue and between the Application Developer and Application Provider is reported in the following Preliminary Concerns I section (Sec. 2.1). In Sec. 2.2 is described, instead, the solution designed and implemented, to improve the access of the Application Provider to the (Beta) FI-STAR enablers in order to offer a better support to the software to data paradigm.
2.1 Preliminary Concerns
The delivery model of the FI-STAR BE enablers follows the approach as service for development purposes. Then, as described in D2.2, the Application Developer accessing the GetYour SE Area
of an enabler will have the opportunity to submit a request in order to obtain his own instance available within the FI-STAR Cloud reference environment. Then he can proceed by integrating the related endpoint in his application modules.
In this respect, to speed up the integration process a “Development Web Platform” was made available to developers where they can directly manage their enablers instances, configure and integrate them in their own applications Such facility is accessible by requesting an account to the Berlin Cloud Manager directly.
It is important to mention that the enablers instances offered to the developers are conceived exclusively for development purposes. This
implies that when the Application Developer will interact with an Application Provider, in a business relationship, the application will not be directly executable within the Application Provider environment (or within the environment of one of his final customers).
For the reason just described, the Application Provider will have, in turn, to interact with the Catalogue, as detailed in the next sections, in order to submit a
subscription for the needed enablers. Such subscription will allow downloading the enablers VM files. In fact, coherently with the software to data paradigm, an (Health) Application Provider aims to obtain directly the software to deploy in his own private cloud environment or in that one’s of his final customers.
2.2 Application Provider: Platform Access
As reported in D2.2, the possibility of subscription for one or several enablers was already made available, to an Application Provider for the alpha release (from July 2014). Anyway the offered shipment options were, at that time, exclusively the “manual” and “via FI-STAR Cloud”.
It is worth to mention that, in the manual case, at the end of the subscription the Application Provider can download, from the Catalogue, the FI-STAR enablers VMs files and, then, proceed, again manually, to the deployment. With the second option, instead, the Application Provider delegates to the FI-STAR Cloud Manager the registration of his (or his customer) Cloud Node and the instantiation there of the enablers VMs (see Figure 8).
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 50 of (78)
Figure 8 – The Catalogue: Subscription Area
Both the options were evaluated with respect to the dimensions considered more critical within the project: the automation degree and the (Private Cloud) access control.
Automation Degree Private Cloud Access Control
Manual Shipment
Exploit FI-STAR Cloud Platform
Automatic Shipment
Figure 9 – shipment modality evaluation results
Manual Shipment
AUTOMATION DEGREE: Low. No kind of automation is supported. The Application Provider is forced, once notified, to access the Catalogue to get the updated enabler VM file. Then he is forced, as well, to interact with the IaaS admin interface of the final customer (or of a trusted platform provider) to proceed with the deployment.
ACCESS CONTROL: High. The Application Provider has full control about which customer (private) IaaS or (trusted) platform provider IaaS to access for deployment.
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 51 of (78)
Exploit FI-STA Cloud Platform
AUTOMATION DEGREE: Mid. Application Provider is not forced to manually download enabler VM file anymore. At the end of subscription process and at each update, the FI-STAR Cloud Manager will be notified in order to proceed with the instantiation. Anyway it is always up to him to manually interact with a IaaS GUI admin to proceed with the deployment
ACCESS CONTROL: Low. This option allows that the enabler (i) or are made available within the FI-STAR Cloud (ii) or are instantiated within a federated cloud node (for instance of the final customer). The first case is clearly a limit. In the second case the control about the federation and the instantiation itself is under the control of the FI-STAR Cloud Manager which could be something not desired.
For the reasons just described it was decided to introduce a new approach which allows to reach the best score on both the dimensions.
Automatic Shipment
AUTOMATION DEGREE: High. With this option are made (optionally) automatic both the enabler VM file shipment and also its deployment in the final cloud node.
ACCESS CONTROL: High. This option offers the possibility, for the Application Provider, to select the (trusted) Cloud Platform Provider also in the extreme case the Application Provider itself needs to have this role. In this way the enablers or are made available in the cloud of a trusted (Cloud) Platform Provider or the federation of the final customer cloud node and the enabler instantiation there is operated, automatically, by a trusted (Cloud) Platform Provider.
Beta Requirements
More detailed requirements related to the envisaged solution are reported below:
[R1] possibility, for the Application Provider, to take in charge the deployment action or to select an external (trusted) Platform Provider
[R2] possibility, for the Application Provider, to specify the system holding the Customers preferences
[R3] possibility to choose if to automate only the enabler VM downloading or also the deployment.
[R4] to check the subscription status for an enabler and to trigger an automatic download and (optionally) an automatic (re) deploy
[R5] to take into account specific customer configuration before proceeding with the (re) deployment (e.g. specified time slot for deployment\re deployment)
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 52 of (78)
Figure 10 – Architecture to enable the automatic shipment
Architecture Description
The Agent Service component is installed within the Application Provider domain as part of a web application. It takes care to periodically check the status of the (SEs) subscriptions, submitted on the Catalogue, by the Application Provider. The communication\polling activity is secured by exploiting an access token obtained by interacting with an Oauth2.0 server (IdM KeyRock) during the initialization step. If a subscription status changed (e.g. new SE version is available, the subscription duration period is expired etc…) then this component will notify the Deployment Manager component which will take care to properly serve the updating requests.
The Configuration Manager is the component offering the functionalities to store and retrieve some Customer preferences. Actually this component holds the preferences related to the Geographic Constraints (affecting all the SEs involved by the health applications of this Customer) and the Deployment Configuration associable to each single SE. Both these information will be made available within a Deployment Option object but new Customer constraints can be easily added (see Figure 11 and Figure 12). Within the Geographic Constraints it is possible to specify if the Customer wish to use its own cloud node to host his applications SEs (LOCAL option) or, instead, if he accepts to rely on the (Cloud) Platform Provider infrastructure. In this last case he can specify\impose, anyway, the (Cloud) Platform Provider has to use exclusively the cloud node located in the country of the Customer (NATION option) or can use whatever (cloud) nodes (EUROPE option1). Synthetically the Geographic Constraints capture the Customers preferences related to “where” the deployment has to happen. Within the Deployment Configuration, instead, the Customer can indicate its preferences related to “how” and “when” such deployment should occur. In fact he can choose only to be notified (NOTIFY option) when a deployment action should be performed (no automatic action) or he can enable a full automatic deployment (AUTOMATIC option) or both (AUTOMATIC&NOTIFY option). In the last two cases the Customer can also specify the time slot when the deployment should be (automatically) performed.
It is worth to mention that in principle an Application Provider could already use a separate system to hold his Customer preferences. For this reason this design document constraints only the interfaces exposed\required by this component and the data model, but the web application, offered to the Application Provider, can be configured also to use an external Configuration Manager (as long as it is compliant with such specification).
1 in order to allow the best performance of an health application also in case of mobility of the final consumer
(e.g. Doctors).
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 53 of (78)
The Deployment Manager is the component which, notified by the Agent, takes care, concretely, to execute the deployment\undeployment of the SEs VMs as consequence of new subscriptions status. For instance if for a SE the subscription policy is of type “Always updated” and a new version for such SE is uploaded within the Catalogue, such module will retrieve, from the Configuration Manager the needed Deployment Options in order to proceed. The way such deployment will take place depends by the information contained within the Deployment Options and already described above. The Deployment Manager could use its own Deployment Configuration for the specific enablers, in case they were not specified by the Customer.
In principle an Application Provider could delegate to third trusted (cloud) Platform Provider the deployment task. For this reason this design document constraints only the interfaces exposed\required by this component and the data model, but the web application offered to the Application Provider, can be configured also to use an external Deployment Manager.
Figure 11 – Data Model: Overview
Figure 12 – Data Model: Deployment Options detail
2.3 Design details
Catalogue Service
Provided interface IOAuth operations:
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 54 of (78)
getUser(accessToken:String):User
createToken(email:String, password:String): String
Provided interface ISubscriptions operations:
subscriptionsByToken(token: String ): List<Subscription>
o This operation allows to retrieve the Subscriptions of an Application Provider identified by an Oauth access token. In details it checks the access token against the IdM-KeyRock in order to retrieve protected information of the Application Provider used to retrieve and return his subscriptions.
Agent Service
Provided interface IAgentGUI:
The Agent provides a WebGUI to manages the agent activity and to monitor the application provider’s subscriptions.
Requested interface IDeployerServiceGUI.
Requested interface IConfigurationManagerGUI.
Requested interface IOAuth operations:
getUser(accessToken:String):User
createToken(email:String, password:String): String
Configuration Manager Service
Provided interface IConfigurationManagerGUI:
The configuration manager provides a WebGUI to allow to configure some customer preferences that will be mapped into CustomerConstraint and DeploymentConfiguration objects which compose, in turn, the DeploymentOptions. Such DeploymentOptions will be accessible programmatically (see IConfiguration interface).
Provided interface IConfiguration operations:
getDeploymentOptionsBySE(SEName:String): List <DeploymentOption>
o This operation allows to retrieve the DeploymentOption of the specified SE. Considering the SE could be involved in applications for several customers this method returns a list of such options (one for each customer). If the Customer did not set the DeploymentConfiguration for a SE, the one set by the Platform Provider is returned within the DeploimentOption (@see DeploymentOption for details).
setKeyConstraintToCustomer(customerName:String, publickey:String, privatekey: String): List <DeploymentOption>
o This operation allows to set the public/private key associated to the customer’s VMs. Such information are made available within the DploymentOption (@see getDeploymentOptionsBySE (SEName: String))
Deployment Manager Service
Provided interface IDeployerServiceGUI:
The Deployer Service provides a WebGUI allowing the (Cloud) Platform Provider (i) to configure his preference (DeploymentOption) and (ii) to define the cloud nodes of his own cloud environment.
Provided interface INotification operations:
notifyNewSpecificEnabler(vminfo: VmInfo, typeOfNotification: ETypeOfNotification, confManager: URI) :DeploymentStatus
o This operation allows the Deployer to be notified each time a SE Virtual Machine, linked to Application Provider's Subscriptions, is changed. The typeOfNotification parameter indicates
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 55 of (78)
if the notification is to trigger an update of a VM or is due to an expired subscription. In first case this method will check the cloud's status and updated/deploy the new vm using also the customer preferences coming from Configuration Manager. In the second case it will undeploy all the VM instances.
2.3.1 Details about the Human Machine Interaction Design
In this section some screenshots of the user interfaces to support the final users in accomplishing the activities expected into requirements will be presented. It is not a complete survey for the sake of simplicity but it will cover the more meaningful user interactions.
- Agent Web Application: download and initialization
After the Application Provider had subscripted some SEs (see sec. 2.2.1 D2.2 for details) the catalogue lets him download the Agent Web Application (see Figure 13).
Figure 13 – Catalogue Agent: download window
It will be deployed within the Application Provider trusted domain and, during its first start up, a Wizard will support the installation process (see Figure 14). Just after the Wizard has been started, some initialization actions will be transparently executed (e.g. Data Base set up) (see Figure 15).
Figure 14 - Catalogue Agent Installation Wizard
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 56 of (78)
Figure 15 – Preliminary initialization actions
Before proceeding with the Wizard steps, it is needed the Application Provider authorises the agent to access some of his information hold in the catalogue. It was decided, for this purpose, to rely on the Oauth 2.0 protocol and, then, the FI-WARE IdM GE – KeyRock has been integrated within the Catalogue service to provide authorization capabilities.
Such a way the wizard, during the initialization step, will forward the Application Provider to the Catalogue authorization GUI in order to allow him: (i) to authenticate himself and (ii) to authorise the Agent for the access. The authorization step ends with the obtainment of an access token which will be used, from this moment, as unique information to trust and authenticate all the Agent’s requests to the Catalogue.
Figure 16 - Catalogue Authorisation GUI – User Authentication
Figure 17 - Catalogue Authorisation GUI – Agent Application Authorisation
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 57 of (78)
The wizard continues and shows the page for the specification of the Configuration Manager system end-point. The Configuration Manager is the component allowing to express the Customer preferences and the wizard let the Application Provider to choose if to rely on an external implementation or on a default one, provided along with the Agent application (see requirement [R2]). See Figure 18 for details.
As for requirement [R1] the wizard allows the Application Provider, also to choose if to take in charge by himself the deployment action (the two roles of Application Provider and Cloud Platform Provider collapse in this case) or to select an external deployment service offered by a (trusted) Cloud Platform Provider (see Figure 19).
Figure 18 – Agent Installation STEP 1: external or internal Configuration Manager.
Figure 19 - Agent Installation STEP 2: external or internal Deployment Service.
When the wizard ends the user has the possibility to access the GUI related to the Agent or that one of the Configuration Manager or of the Deployment Manager. (see Figure 20).
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 58 of (78)
Figure 20 - Agent Installation STEP 3: Wizard completed
- Configuration Manager
Configuration Manager's GUI allows the Application Provider to manage the customers who has bought his health applications.
In particular the GUI offers the possibility to add a new customer, by clicking the Add Customer button from the main page (see Figure 21), and to specify the application(s) he has bought (see Figure 22).
Figure 21 – Configuration Manager Main Page
For the Customer, just created, the Application Provider can edit some preferences. Actually the system supports, as described above, the possibility (i) to specify geographic constraints and (ii) to indicate preferences about the deployment modality.
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 59 of (78)
Figure 22 – Configuration Manager: New Customer Form
About the first type of preference (see Figure 23), the Application Provider, selecting the Edit Geographic Constraint button, can “constrain”, for the current customer, where the Deployment Manager will have to instantiate the VMs for all the enablers needed to the applications of that customer. In Figure 24 the three types of geographic constraint are showed:
Figure 23 – Configuration manager: User Preferences Section
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 60 of (78)
Figure 24 – Configuration manager: Geographic Constraints
- Europe: in this case the Customer has neither an own (cloud) node nor a favourite nation. So the final (cloud) node which will be used will depend, exclusively, by the Deployment Manager implementation (based for example on a balance algorithm).
- Nation: in this case the Customer hasn't an own (cloud) node but the constraint forces the Deployment Manager to use the (cloud) node available in the Customer’s nation.
- Local: in this case the Customer desires to use his own (cloud) node. Then the form allows to insert the Customer's node endpoint and credential that the Deployment Manager will have to use to finalise the deployment action.
About the second type of preference, it is possible to define, for each specific enabler of a Customer (i.e. enablers required by the applications of that Customer), also a preference about the deployment modality (see requirement [R3]).
The Application Provider, by clicking on the button Add preference for a SE, can select a specific enabler and set if the Customer desires: (i) no automatic deployment but only to be notified (ii) a full automatic deployment (iii) a full automatic deployment and a notification. In the last two cases it is possible also to indicate the time slot, preferred by the Customer, to proceed with the automatic deployment.
Figure 25 – Configuration Manager: Deployment Preferences
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 61 of (78)
Figure 25 shows the most complex case when, for the Customer (Ferrara Hospital in the example), it has been selected to send a notification via email and to automate the instantiation of new enabler VMs at the 03:00 P.M. of first Tuesday after February 14th. The expression power on the date lets user to define many different types of time preferences.
- Deployment Manager
Deployment Manager's GUI allows to define the (Cloud) Platform Provider preferences about where and when to instantiate the enablers VMs notified by agent.
In fact the main page of such GUI (see Figure 26) is subdivided in two areas: Platform Provider Preferences and Platform Provider Cloud nodes.
Figure 26 – Deployment Manager: Main Page
The Platform Provider Preferences section allows to specify the “default” Deployment Configuration by selecting the button Edit Default Platform Preferences. This configuration will be used to deploy all the enabler VMs in the case neither the Customer (see the previous section) or the Platform Provider (see below) provided specific preferences for those enablers.
The default platform preferences editing form allows to define, also in this case, the action type (notify, automatic, automatic and notify), the schedule time and the contact email address for the notification.
The Platform Provider can also override the global default preferences (valid for all the SEs) with a new one specific for each SE. He can do it simply by selecting the button Add Preferences for a SE. The editing form is the same as for the global case but with a field in addition where to indicate the SE for which the overriding preferences are submitted (see Figure 28).
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 62 of (78)
Figure 27 – Deployment Manager: Default Platform Provider Preferences
Figure 28 – Deployment Manager: Platform Provider Preferences for SE
In conclusion the final DeploymentConfiguration that the deployment service of the (Cloud) Platform Provider will use is based on the following priority order:
1. Customer’s SE Preference
2. (Cloud) Platform Provider’s SE Preference
3. (Cloud) Platform Provider’s Default Preferences
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 63 of (78)
The Platform provider cloud nodes section, instead, shows the cloud nodes that compose the platform provider’s cloud infrastructure. From this section the (Cloud) Platform Provider can add a new node by selecting the button add new node and filling the related creation form.
Such form allows to insert the country, where the new cloud node is located, the related endpoint and the credentials to access it.
Figure 29 – Deployment Manager: New Cloud Node creation form
It is worth to remember that the cloud nodes which form the cloud infrastructure of the Cloud Platform Provider will be used, for the deployment action, only if the Customer specified a Geographic Constraint of type EUROPE or NATIONAL. In the first case the deployment service will adopt an algorithm to balance the number of active VMs, among all the nodes configured in the system, in the second case, instead, the node available in the same nation of the Customer will be used.
If the Geographic Constraint is of type LOCAL, instead, the cloud node of the Customer will be automatically federated and used, by the deployment service, for the deployment action.
- Agent
The agent’s main page (see Figure 30) shows the subscriptions that the Application Provider activated on Catalogue (see section Specific Enabler Subscriptions Status).
In order to automatically check the status of such subscriptions and trigger appropriate actions in case of changes, the Application Provider has to select the button start polling. This action activates a polling process querying the catalogue service periodically. When changes are identified the Agent will notify the configured Deployment Manager about them.
For tracking and monitoring purposes a log area (see section Agent’s Log) shows the logs related to the subscriptions checking activity and to the feedbacks due to the deployment actions.
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 64 of (78)
Figure 30 – Agent: Main Page
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 65 of (78)
3 The Catalogue: Usage Experience Report
3.1 SE Owners report
In this section are reported, for each enabler, a summary of the information available within the Catalogue [16] to reflect the updates\new contents added within the period from July 2014 to January 2015 (i.e. Beta development phase). Such updates could have been finalised to improve the Documentation section to make it clearer or they could affect the release of further training material (e.g. audio\video courses uploaded within the FI-WARE e-learning platform [17]) or they could be finalised to update the Terms And Conditions section to better qualify the software availability, not only to FI-PPP partners, but also to External actors (i.e. when the project will end).
- Connectivity Service BE SE
Overview Documentation SW upload Terms And Conditions
The Connectivity Service SE is available in the catalogue as BETA release, last updated on 20-February-2014.
Contact details and more information are also available in the Catalogue
Documentation is given in the catalogue Overview and Documentation section of the SE for the BETA version. An additional Installation & User Development Guide has been produced and is also available
Software for the BETA version has been uploaded and is available for the download.
The SE can be requested as an instance at the Berlin node.
Copyright © 2014 FOKUS – All Rights Reserved
External: If external party is interested in this SE, they are welcome to get in touch with the SE owner or [email protected]
FI-PPP: The Connectivity Service SE is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement.
- Device Management Service SE
Overview Documentation SW upload Terms And Conditions
The Device Management SE is available in the catalogue as BETA release, last updated on 20-Feb-2014.
Contact details and more information are also available in the Catalogue
Documentation is given in the catalogue Overview and Documentation section of the SE. An additional Installation & Admin. Guide, along with a User and Programmer Guide has been produced and is also available for this version.
Software is available for the download.
The SE can be requested as an instance at the Crete node.
Copyright © 2014 FOKUS – All Rights Reserved
External: If external party is interested in this SE, they are welcome to get in touch with the SE owner or [email protected]
FI-PPP: The Device Management Service SE is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement.
- Event Service SE Owner
Overview Documentation SW upload Terms And Conditions
The Event Service SE is available in the catalogue as BETA release, last updated on 30-January-2015. Contact details and more information are also available in the catalogue.
Documentation in the catalogue Overview and Documentation section has been improved during the Beta development period. Other than the already available User and Programmer Guide, also an audio\video course has been produced and uploaded within the FI-WARE e-learning
For the BETA version this enabler has been made available also for the download from the Get Your SE area. It remains, as well, the possibility to request this enabler as an instance at the Berlin and Crete cloud, always from the Get
Copyright © 2014 AGE – All Rights Reserved
Copyright © 2014 TUB – All Rights Reserved
External: The BETA version will be made available for external usage such a way: Web App and including REST/XMLRPC modules will be made available under the original BSD license. This SE incorporates the FI-WARE Context Broker Orion which is provided as open source under the AGPLv3 license, but can be used with and enabler exposing the FI-WARE NGSI Open RESTful API specification.
FI-PPP: The Event Service Specific Enabler is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement. The details for the access are reported within the Get Your SE area.
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 66 of (78)
platform. It is reachable from the Catalogue as well (link)
Your SE area.
- Targeting & Profiling SE Owner
Overview Documentation SW upload Terms And Conditions
The Targeting & Profiling Service SE is available in the catalogue BETA release, last updated on 30-January-2015. Contact details and more information are also available in the catalogue.
Documentation, in the catalogue Overview and Documentation section, has been improved during the Beta development period. Other than the already available User and Programmer Guide, also an audio\video course has been produced and uploaded within the FI-WARE e-learning platform. It is reachable from the Catalogue as well (link)
For the BETA version this enabler has been made available also for the download from the Get Your SE area. It remains, as well, the possibility to request this enabler as an instance at the Berlin and Crete cloud, always from the Get Your SE area.
Copyright © 2014 AGE – All Rights Reserved
Copyright © 2014 TUB – All Rights Reserved
External: The BETA version will be made available for external usage such a way: Web App and including REST/XMLRPC modules will be made available under the original BSD license. This SE incorporates the FI-WARE Context Broker Orion which is provided as open source under the AGPLv3 license, but can be used with and enabler exposing the FI-WARE NGSI Open RESTful API specification.
FI-PPP: The Targeting & Profiling Service SE is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement.
- Monitoring SE Owner
Overview Documentation SW upload Terms And Conditions
The Monitoring Service SE is available in the catalogue as BETA release, last updated on 10-February-2015. Contact details and more information are also available in the catalogue
Documentation is given in the catalogue Overview and Documentation section for BETA version. An additional Installation & admin. guide, along with a User and Programmer Guide (for this version) have been produced and are also available in the catalogue.
The BETA version of the software has been uploaded into the catalogue and is available for installation (based on installation and administration guide).
Also for this version it is possible to request the enabler as an instance at the Crete and Berlin cloud node.
Copyright © 2014 - TUB. All Rights reserved.
External: The Monitoring Service SE is available for external use under Apache License Version 2.0.
FI-PPP: The Monitoring Service SE is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement
- Security & Privacy SE Owner (TUB)
Overview Documentation SW upload Terms And Conditions
Security & Privacy SE is available in the catalogue as BETA release, last updated on 30-Jan-2015. Contact details and more information are also available in the catalogue.
Documentation is given in the catalogue Overview and Documentation section of the SE.
Both User and Programmer Guide and Installation and Administration Guide are available as well for this version.
Actually the SE can be requested either as a service instance at the Berlin and Crete cloud nodes or as a downloadable Virtualbox image (for local deployment and testing).
A sample PHP web application is also provided for consumer as API illustration.
Copyright © 2015 - TUB. All Rights reserved.
External: By the end of FI-STAR project, this will be released to external parties by the following open source Apache License 2.0 approach.
FI-PPP: The Security & Privacy SE is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement. Access details within the Get Your SE area.
- Security & Privacy SE Owner (ENU)
Overview Documentation SW upload Terms And Conditions
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 67 of (78)
Security & Privacy SE is available in the catalogue as ALPHA M1 release, last updated on 25-June-2014. Contact details and more information are also available in the catalogue. The TSL SE provides HTTP REST APIs exposing ETSI TSL (Trust Service Status List) 102.231.
Documentation is given in the catalogue Overview and Documentation section of the SE. An additional Installation & admin. guide, along with a User and Programmer Guide has been produced and is also available in the catalogue.
Software has been uploaded into the catalogue and is available for download and installation (based on installation and administration guide).
The SE can be requested as an instance at the Crete and Berlin cloud node.
Copyright © 2014 - ENU. All Rights reserved.
External: The TSL SE is not available for external use at the moment.
FI-PPP: The TSL Specific Enabler is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement
- Time Service SE Owner
Overview Documentation SW upload Terms And Conditions
The Time Service SE is specified here as a component that enables other modules to use it and to get accurate time for orchestrating events to be occurred and keep transaction integrity high
Documentation is included in the catalogue Overview and Documentation section of the SE. An additional Installation & admin. guide, along with a User and Programmer Guide has been produced and is also available in the catalogue.
Software has been uploaded into the catalogue and is available for download and installation (based on installation and administration guide).
The SE can be requested as an instance at the Crete and Berlin cloud node.
Copyright © 2014 © TSI-TUC . All rights reserved.
External: The concrete licence is available as Open Source under the original MIT license.
This SE includes the NTP server which is available under the GNU General Public License (GPL).
FI-PPP: The Event Service Specific Enabler is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement.
Good experience using the catalogue for:
a) Providing documentation and general descriptions of the SE
b) Uploading software in the catalogue
c) Interacting with the catalogue administrators regarding issues.
- Real Time Communication SE Owner
Overview Documentation SW upload Terms And Conditions
The Real Time Communication Service SE is available in the catalogue as BETA release, last updated on 13-Feb-2015. Contact details and more information are also available in the catalogue.
Documentation in a form two separate pdf documents (User and Programmer Guide, Installation & Administration Guide) has been updated in the catalogue for this new version.
It has been uploaded also a guide for a Web Application to use as client to test the RTC SE.
This SE has been uploaded, for the BETA version, into the catalogue and is available for download and installation on 13-Feb-2014.
The SE can be requested as an instance at the Crete and Berlin cloud node.
Copyright © 2014 ITTI sp. z o.o. – All Rights Reserved
External: This enabler will be released to external parties (out of the FI-PPP and FI-STAR project) in a form of closed-source application.
The Enabler is available for personal and non-commercial use after notifying the owner. For commercial or educational purposes, different Terms and Conditions apply. Please, contact via mail the owner of the specific enabler ([email protected]) to get more details and the enabler itself.
FI-PPP: The RTC Specific Enabler is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement.
- Health Questionnaire Service SE Owner
Overview Documentation SW upload Terms And Conditions
The Health Questionnaire Service SE is available in the catalogue as BETA release, last updated on 05-
Documentation is included in the catalogue Overview and Documentation section of the SE. An updated User and Programmer Guide (for BETA version) has been provided. Also a zip containing code
No software has been uploaded to the catalogue yet for the BETA version.
Also for BETA version, the SE can
Copyright © 2014 © Tekniker. All Rights Reserved.
External: At the finalisation of the FI-STAR project the SE will be made available as open source. The concrete license is still under evaluation, further information to be provided
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 68 of (78)
February-2015. Contact details and more information are also available in the catalogue.
samples\test (for BETA version) has been provided.
An audio video course on the FI-WARE e-learning platform is not yet available but is under preparation and will be uploaded soon.
be requested as an instance at the Crete and Berlin cloud node.
soon.
FI-PPP: The Health Questionnaire Service SE is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement.
Contact information for any inquires about licensing is provided.
- Mediation Service SE Owner
Overview Documentation SW upload Terms And Conditions
The Mediation Service SE is available in the catalogue as BETA release, by the end of February 2015. Contact details and more information are also available in the catalogue
Documentation is given in the catalogue Overview and Documentation section of the SE. An additional User and Programmer Guide (for BETA version) has been produced and will be made also available in the catalogue by the end of February 2015.
An audio video course on the FI-WARE e-learning platform is not yet available but is under preparation and will be uploaded soon.
The SE is based on WSO2 ESB. This should be installed following the instruction in the link provided in the catalogue.
Users can download from catalogue the user guide and templates to create required mediation tasks.
By the end of February 2015 it will be possible either to download the enabler or to submit a request for an instance at the Berlin\Crete nodes.
Copyright © 2014 CUP 2000 spa
Copyright © 2014 FUNDACION TEKNIKER
External: The Mediation Service Enabler will be made available for external use as free software under the L-GPL licence. The software is provided "as is" for all parties.
This SE make use of the WSO2 ESB which is distributed under the Apache Software License v2.0
FI-PPP: The Mediation Service Specific Enabler is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement.
- Sensor Data Collection Service SE
Overview Documentation SW upload Terms And Conditions
The Sensor Data Collection Service SE is available in the catalogue as BETA release. Previous release are available as well
Contact details and more information are also available in the catalogue.
Documentation is given in the catalogue Overview and Documentation section of the SE. Code samples are provided to interact with the SDCS while a User and Programmer Guide and an Installation and Administration Guide are available as well in the Documentation area. The BETA version of such software and guides are going to be updated.
Software (BETA version) is available for the download as an APK binary for running on Android.
No possibility to have access as service.
Copyright © 2014 FOKUS – All Rights Reserved
External: If external party is interested in this SE, they are welcome to get in touch with the SE owner or [email protected]
FI-PPP: The Sensor Data Collection Service SE is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement.
- Local Data Processing Service SE
Overview Documentation SW upload Terms And Conditions
The Local Data Processing Service SE is available in the catalogue as BETA release, last updated on 10-February-2015.
Contact details and more information are also available in the catalogue.
Documentation is given in the catalogue Overview and Documentation section of the SE. An additional User and Programmer Guide for the BETA version is going to be produced and uploaded in the catalogue
Software (BETA version) is available for the download as a native Android library (.jar)
No possibility to have access as service.
Copyright © 2014 - TUB. All Rights reserved.
External: The Local Data Processing Service SE is available for external use (i.e. out of FI-STAR and FI-PPP) as Open Source under the original BSD license
The SE includes the Esper for Android library, that is available under the GNU General Public License (GPL-2.0)
FI-PPP: The Local Data Processing Service SE is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement.
- Notification Service SE
Overview Documentation SW upload Terms And Conditions
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 69 of (78)
The Notification Service SE is available in the catalogue as BETA release, last updated on 02-Feb-2015.
Contact details and more information are also available in the catalogue.
Documentation (for BETA version) is given in the catalogue Overview and Documentation section of the SE. An additional User and Programmer Guide (pdf file) is going to be uploaded within the Catalogue.
Software (BETA version) is available for the download as a native Android library (.jar).
No possibility to have access as service.
Copyright © 2014 - TUB. All Rights reserved.
External: The Notification Service SE is available for external use (i.e. out of FI-STAR and FI-PPP) as Open Source under the original BSD license and can be found here:
FI-PPP: The Notification Service SE is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement. Details for the access in the Get Your Se area.
- Connectivity Service SE
Overview Documentation SW upload Terms And Conditions
The Connectivity Service SE is available in the catalogue as BETA release, last updated on 10-Feb-2015.
Contact details and more information are also available in the catalogue.
Documentation is given in the catalogue Overview and Documentation section of the SE. An additional User and Programmer Guide and an Installation & Admin. Guide have been produced and are also available in the catalogue
A code sample is provided as Android Studio Project
Software (BETA version) is available for the download (.apk)
No possibility to have access as service.
Copyright © 2014 FOKUS – All Rights Reserved
External: If external party is interested in this SE, they are welcome to get in touch with the SE owner or [email protected].
FI-PPP: The Connectivity Service SE is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement. Details for the access in the Get Your Se area.
- Local Data Storage Service SE
Overview Documentation SW upload Terms And Conditions
The Local Data Storage Service SE is available in the catalogue as BETA release, last updated on 10-Februaary-2014.
Contact details and more information are also available in the catalogue.
Documentation is given in the catalogue Overview and Documentation section of the SE. An additional User and Programmer Guide for the BETA version has been produced and is going to be uploaded in the catalogue
Software (BETA version) is available for the download as a native Android library (.jar)
No possibility to have access as service.
Copyright © 2014 - TUB. All Rights reserved.
External: The Local Data Storage Service SE will be made available for external use under the original BSD license.
FI-PPP: The Local Data Storage Service SE is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement. Details for the access in the Get Your Se area.
- Motion Evaluation SE
Overview Documentation SW upload Terms And Conditions
The Motion Evaluation SE is available in the catalogue as BETA release, last updated on 04-February-2015.
Contact details and more information are also available in the catalogue, within the Overview area.
Documentation is given in the catalogue Overview and Documentation sections.
The User and Programmer Guide is already uploaded.
An audio video course on the FI-WARE e-learning platform is not yet available but is under preparation and will be uploaded soon.
For the BETA version, this enabler is available for downloading from the Get Your SE area. It is possible, as well, to request this enabler as an instance at the Berlin and Crete cloud, always from the Get Your SE area.
Copyright © 2015 CERTH – All Rights Reserved
Copyright © 2015 DCU – All Rights Reserved
External: This enabler will be released to external parties (out of the FI-PPP and FI-STAR project) by following an open source approach. In detail:
Motion Evaluation Specific Enabler will be made available under an open source license (Apache License 2.0).
It is worth to mention, anyway, that such software relies in turn on:
ZedGraph library (with license GNU Library or Lesser General Public License version 2.0 (LGPLv2))
NewtonSoft.Json library (MIT License (MIT))
(Optional)
FI-WARE GEi – Orion Context Broker (with license BSD)
FI-WARE GEi – Identity Management - KeyRock (open source
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 70 of (78)
under the GNU Affero General Public License)
FI-PPP: The Motion Evaluation Specific Enabler is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement. The details for the access are reported within the Get Your SE area.
- Semantic Enricher SE
Overview Documentation SW upload Terms And Conditions
The Semantic Enricher SE is available in the catalogue as BETA release, last updated on 04-February-2015.
Contact details and more information are also available in the catalogue, within the Overview area.
Documentation is given in the catalogue Overview and Documentation sections.
The User and Programmer Guide is already uploaded.
An audio video course, on the FI-WARE e-learning platform, is not yet available but is under preparation and will be uploaded soon.
For the BETA version, this enabler is available for downloading from the Get Your SE area.
Copyright © 2014 Nissatech Innovation Centre
External: This enabler will be released to external parties (out of the FI-PPP and FI-STAR project) by following an open source approach. In detail:
Semantic Enricher Specific Enabler will be made available under GNU General Public License (GPL) (GPLv2).
It is worth to mention, anyway, that such software relies in turn on:
- Joda-Time java library (with Apache 2.0 licence)
- Guava java library (with Apache 2.0 licence)
FI-PPP: The Motion Evaluation Specific Enabler is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement. The details for the access are reported within the Terms and Conditions area.
- EHR SE
Overview Documentation SW upload Terms And Conditions
The EHR SE is available in the catalogue as BETA release, last updated on 04-February-2015.
Contact details and more information are also available in the catalogue, within the Overview area.
Documentation is given in the catalogue Overview and Documentation sections.
The EHR Manual is already uploaded. Also some examples of Curl APIs call is are provided as well.
An audio video course, on the FI-WARE e-learning platform, is not yet available but is under preparation and will be uploaded soon.
For the BETA version, this enabler is available for downloading from the Get Your SE area.
It is possible, as well, to request this enabler as an instance at the Berlin and Crete cloud, always from the Get Your SE area.
Copyright © 2015 University of Cyprus
Copyright © 2015 InfoTEX Software Solutions LTD
External: The EHR SE layer has been developed by UCY and will be released to external parties (out of the FI-PPP and FI-STAR project) under an open source license (Apache License 2.0).
Furthermore such software depends from the following libraries which in turn are available under the following licenses:
- Hibernate ORM open source software: under the LGPL 2.1 or ASL 2.0 license.
- LCDA Tools: under the Ecliple license - v1.0
For commercial or educational purposes, different Terms and Conditions apply. Pease, contact via mail the owner of the specific enabler
FI-PPP: The EHR Specific Enabler is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement. The details for the access are reported within the Get Your SE area..
- Fall Risk Evaluation SE
Overview Documentation SW upload Terms And Conditions
The - Fall Risk Evaluation SE is available in the catalogue as BETA release, last updated on 13-February-2015.
Contact details and more information are
Documentation is given in the catalogue Overview and Documentation sections.
The Fall Risk Evaluation User Guide and Installation Guide
For the BETA version, this enabler is available for downloading from the Get Your SE area.
It is possible, as well, to request it as an service at the
Copyright © 2015 SingularLogic SA
External: The FRE enabler will be released to external parties (out of the FI-PPP and FI-STAR project) following an open source approach. In particular, the FRE SE will be made available under the Apache License 2.0.
The FRE SE relies on the:
- Orion Context Broker Publish / Subscribe GEi (AGPLv3
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 71 of (78)
also available in the catalogue, within the Overview area.
are available as well while code samples are being prepared.
An audio video course, on the FI-WARE e-learning platform, is not yet available but it is under preparation and will be uploaded soon.
Berlin and Crete cloud node, always from the Get Your SE area.
license)
- Wirecloud GEi (AGPL v3 with a classpath-like exception allowing widgets and operators running onto Wirecloud to be licensed under any license without any restriction)
- The FRE SE interacts with the Identity Managment (KeyRock) GEi (GNU Affero General Public License) for identification purposes.
Furthermore the FRE SE includes the following:
- MySQL Server (GNU GPL v2)
- Apache (Apache License v2.0)
- Flask (BSD License)
- SQLAlchemy (MIT License)
FI-PPP: The EHR Specific Enabler is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement. The details for the access are reported within the Get Your SE area..
- PACS SE
Overview Documentation
SW upload Terms And Conditions
The PACs SE is available in the catalogue as BETA release, last updated on 09-February-2015. Contact details and more information are also available in the catalogue, within the Overview area.
Documentation is given in the catalogue Overview and Documentation sections.
The PACs Manual is not yet available but is under preparation and will be uploaded soon. An audio video course, on the FI-WARE e-learning platform, is not yet available but is under preparation and will be uploaded soon
For the BETA version, this enabler will be available for downloading from the Get Your SE area by the end of February 2015.
It will be possible, as well, to request this enabler as an instance at the Berlin and Crete cloud, always from the Get Your SE area.
Copyright © 2015 University of Cyprus
Copyright © 2015 InfoTEX Software Solutions LTD
External: PACs SE will be released to external parties (out of the FI-PPP and FI-STAR project) by following an MPL/GPL/LGPL triple license (similar to Mozilla) approach. In detail:
The PACs SE rest service code is developed by the Hibernate ORM open source software and is under the LGPL 2.1 or ASL 2.0 license. In more detail the:
LGPL 2.1 license is sufficiently flexible to allow the use of Hibernate in both open source and commercial projects.
Moreover, ASL 2.0 license which some Hibernate projects are released under the more permissive ASL 2.0.
It is worth to mention, anyway, that such software relies in turn on:
-DCM4Chee libraries: These libraries are offered under the MPL/GPL/LGPL triple license (similar to Mozilla). This allows use of the files under the terms of any one of the Mozilla Public License version 1.1 (MPL), the GNU General Public License version 2 or later (GPL), or the GNU Lesser General Public License version 2.1 or later (LGPL).
FI-PPP: The PACS Specific Enabler is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement. The details for the access are reported within the Get Your SE area.
- ePSOS SE
Overview Documentation SW upload Terms And Conditions
The EHR SE is available in the catalogue as BETA release, last updated on 04-February-2015.
Contact details and more information are also available in the catalogue, within the Overview area.
Documentation is given in the catalogue Overview and Documentation sections.
The EHR Manual is already uploaded. Also some examples of Curl APIs call is are provided as well.
An audio video course, on the FI-WARE e-learning platform, is not yet
For the BETA version, this enabler is available for downloading from the Get Your SE area.
It is possible, as well, to request this enabler as an instance at the Berlin and Crete cloud, always from the Get Your SE area.
Copyright © 2015 University of Cyprus
Copyright © 2015 InfoTEX Software Solutions LTD
External: The epSOS SE, layer has been developed by UCY and will be released to external parties (out of the FI-PPP and FI-STAR project) under an open source license (Apache License 2.0).
Furthermore such software depends from the following libraries which in turn are available under the following licenses:
Hibernate ORM open source software: under the LGPL 2.1 or ASL 2.0 license.
CDA Tools: under the Ecliple license - v1.0
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 72 of (78)
available but is under preparation and will be uploaded soon.
For commercial or educational purposes, different Terms and Conditions apply. Pease, contact via mail the owner of the specific enabler ([email protected])
FI-PPP: The EHR Specific Enabler is available to the Parties signed into the FI-PPP program under the conditions established in the FI-PPP Coll. Agreement. The details for the access are reported within the Get Your SE area.
Entries on the Catalogue for the EXPOSE SE and the GEO-FENCING SE were prepared but made not yet public at the time of this document delivery. This to allow the owners to continue working on them but not allowing developers (internal or external to the project) to access them. This is in any case in line with the delivery roadmap of such enablers which, as all the enablers from the Open Call initiative, were expected to be available within the FI-STAR Cloud Infrastructure by the end of February.
3.2 Cloud Platform Managers Report
In this section the Cloud Platform administrators report details about their experience in interacting with the Catalogue in order to serve the requests coming, via Catalogue, by the Application Developers in the period from July 2014 to December 2015 (i.e. Beta development phase)
- XiFI Node Manager (Berlin)
For the period from the Specific Enabler release ALPHA to BETA, end of June to end of January, 27 SEs requests have been submitted to the Berlin node manager via the catalogue and 18 have been served by instantiating the SEs in the Berlin node. Naturally it represents only a screenshot because the process of requests submission is continuously under evolution.
Enabler Requestor
Connectivity Service Back-End WP4_APP_DEV_ROMANIA
Connectivity Service Back-End WP4_APP_DEV_ROMANIA
Connectivity Service Back-End WP4_APP_DEV_POLAND
Event Service WP4_APP_DEV_SPAIN
Event Service HeartHealth_SEs_OWNER
Event Service WP4_APP_DEV_ENGLAND
Event Service WP4_APP_DEV_SPAIN
Event Service WP4_APP_DEV_ROMANIA
Event Service WP4_APP_DEV_ROMANIA
Event Service WP4_APP_DEV_SPAIN
Event Service TRILOGIS_SEs_OWNER
Event Service WP4_APP_DEV_POLAND
Event Service MYSPHERA_SEs_OWNER
Event Service WP4_APP_DEV_NORWAY
Targeting & Profiling Service ACREO_SEs_OWNER
Targeting & Profiling Service WP4_APP_DEV_ITALY
Targeting & Profiling Service WP4_APP_DEV_ROMANIA
Health Questionnaire Service WP4_APP_DEV_ITALY
Tab 1- SE Requests Berlin Node Served
The following requests are, instead, still in a pending status:
Enabler Requestor
Connectivity Service Back-End ACREO_SEs_OWNER
Event Service ACREO_SEs_OWNER
Targeting & Profiling Service ANGEL_SINGULARLOGIC_SEs_OWNER
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 73 of (78)
Health Questionnaire Service FI-PPP_FIC3_Yagram
Health Questionnaire Service FI-PPP_FIC3_Yagram
Security and Privacy Service (TUB)
WP4_APP_DEV_ROMANIA
Real Time Communication Service
WP4_APP_DEV_ROMANIA
Time Service SE WP4_APP_DEV_ROMANIA
Time Service SE FI-PPP_FIC3_HearingSoftware
Tab 2- SE Request Berlin Node Pending
The processes for receiving and serving request confirmed also in this period to be clear and understandable, with a good possibility to interact with the SE requester through comments on the request. The catalogue also provides a good mechanism to give feedback and monitor the progress status of a request by assigning corresponding states to the request (Pending, In Progress, Served).
- XiFI Node Manager (Crete)
For the period from the Specific Enabler release ALPHA to BETA, end of June to end of January, 12 SEs requests have been submitted to the Crete node manager via the catalogue and all have been served by instantiating the SEs in the Crete node. The catalogue has been used in order to record the requests and to monitor feedback and request status (pending, in progress, served).
Enabler Requestor
Time Service SE ACREO_SEs_OWNER
Time Service SE UCY_SEs_OWNER
Security and Privacy Service (TUB)
UCY_SEs_OWNER
Health Questionnaire Service ACREO_SEs_OWNER
Health Questionnaire Service WP4_APP_DEV_SPAIN
Health Questionnaire Service WP4_APP_DEV_ITALY
Targeting & Profiling Service WP4_APP_DEV_ROMANIA
Event Service ANGEL_SINGULARLOGIC_SEs_OWNER
Event Service HeartHealth_SEs_OWNER
Event Service UCY_SEs_OWNER
Event Service WP4_APP_DEV_ROMANIA
Event Service WP4_APP_DEV_ITALY
Monitoring Service WP4_APP_DEV_ROMANIA
Motion Evaluation HeartHealth_SEs_OWNER
Tab 3- SE Requests Berlin Node Served
- Conclusion
In conclusion from the information reported above it results quite evident a big increase in the number of requests served by the FI-STAR Cloud nodes via the Catalogue channel. The rational is due, mainly, to the fact that, in the reporting period this deliverable refers to, the WP4 Application Developers focused their development activities.
Other than this, it is worth to mention, that in the same period the Catalogue was opened also to the FI-PPP members and SMEs (and Web entrepreneurs) selected by the accelerator projects. Below a brief re-cup:
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 74 of (78)
16 June 2014
Berlin Node Crete Node
Total Requests: 8 Total Requests: 5
- 6 served
- 2 pending
- 4 served
- 1 pending
31 January 2015
Berlin Node Crete Node
Total Requests: 27 Total Requests: 14
- 18 served
- 9 pending
- 14 served
- None pending
Berlin Increase: +237%
Crete Increase: +180%
Before closing this section is important to remark the support offered by the project (via Catalogue administrator) in enabling the FI-PPP Phase 3 SMEs to access the FI-STAR enablers. At moment of writing this document the following SMEs were provided (or are going to be provided) of an account as for requests coming from their accelerator representative:
Table 18 – FI-PPP Phase3 SMEs: Accounts Creation Status
3.3 Application Providers Report
The period from the Specific Enabler release ALPHA to BETA (end of June to end of January 2015) was also characterized by the access to the Catalogue, of a new actor: the (WP5) Application Provider. This actor started in submitting the subscriptions finalised to the SE VMs shipment, following the modalities described within D2.2. The objective was to make available, within the remote private cloud of this actor (or of his customers), the enablers needed to deploy and run, within the trial sites, the applications coming from WP4.
It is worth to mention here that during the period of interest only two shipment modalities were available: (i) Manual and (ii) Take advantage of the FI-STAR Cloud Platform. Details about such modalities are available in D2.2 while here a brief report about the interaction with the Catalogue is presented.
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 75 of (78)
Table 19 - Catalogue: Subscriptions Administration Area
31 January 2015
Total: 22 subscriptions
Manual shipment Via FI-STAR (Cloud) Platform
- 20 - 2
3.4 Bugs analysis and improvements
The issue tracker tool, integrated within the catalogue, was set up by following the guidelines reported in the D2.2 - Annex B. Such configuration was conceived to support, from one side, the gathering, during the WP4 application development (alpha and beta), of the issues affecting the whole FI-STAR platform SEs, and, from the other, the gathering of issues affecting the Catalogue itself. In this section will be presented just a summary about the issues associated to the SEs, just to give an idea about the trend in the reporting period, while full description and details can be found in the PartA of this document. On the other hand this section provides a complete analysis of the bugs (and their management) affecting directly the Catalogue.
- SE issues evolution
16-June-2014 31-January-2015
Total increase: +241%
- Catalogue issues
The issues strictly associated to the catalogue are briefly summarised in the figure below:
#ID:2,4,6,7,8 were already analysed and discussed in the D2.2
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 76 of (78)
#ID:31 - How to change email address of account? (type: Bug Report)
WP4_APP_DEV_NORWAY reported about the impossibility to change the mail address for an account. The issue was resolved by explaining that a user has only, just after the log in within the Catalogue, to click on the "edit" tab and, then, to change the mail address found in that area. A screenshot was posted as well for better explanation.
Table 20 – IssueTracker: issues related to the Catalogue
#ID:37 - Event Service download link is missing (type: Bug Report)
WP4_APP_DEV_NORWAY reported about the impossibility to download the Event Service enabler at the "Get your SE" page, although the enabler owner says there should be. The issue was resolved by contacting the Event Service Owner who clarified this enabler were available in that moment only as service instance from the XifFI Berlin\Crete node.
#ID:43 - Cannot download img files for enablers (type: Bug Report)
WP5_APP_PROV_NORWAY reported about the impossibility to download the image files for some enablers he subscribed for. The issue was resolved by making some tests and checking that all worked properly. Furthermore the same reporter advised, later on, they identified the cause of the problem in their firewall which prevented the download.
#ID:52 - No files to download VM images of SEs instances (type: Support Request)
WP4_APP_DEV_POLAND reported about the impossibility to download the image files for some enablers from the Get Your SE area. The issue was resolved by explaining to the requester that the download of the enablers VM images is possible only if he log in with the role of Application Provider.
#ID:75 - Status change disabled (type: Bug Report)
WP4_APP_DEV_GERMANY reported an issue similar to #ID:52 which was solved in a similar way.
#ID:77 - Browser support (type: Bug Report)
WP4_APP_DEV_GERMANY reported the issue tracker seems to not properly work wit IE. He report that clicking on the "My Bugs" list it responds a file, which is prompted to the user, rather than being integrated in the client-side web page. The issue is still in progress because the
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 77 of (78)
Catalogue administrator has repeated the same action, by several IE versions, without capturing this behaviour. The issue will be closed if it will be not possible to repeat this anomalous behaviour.
3.5 Final considerations
In this section we want to highlight FI-STAR worked, during the T2.4 activity, on the development of an own catalogue, which optimises and simplifies the interactions expected by all the involved actors starting from analysis of such actors requirements (see D2.2-PartB). Furthermore the project recognised (as for first review indication) the need to introduce a professional tool for requirements tracking also to support the BETA development step of the platform. Therefore such a tool (based on the professional open source product Bugzilla) was properly customised and seamless integrated within the Catalogue environment (see D2.2-AnnexA).
Anyhow that FI-STAR, as the other Phase 2 projects, has been informed recently, via FI-PPP communication channel, about the intention to import all the enablers within the FI-WAR Catalogue. Such a way the FI-STAR Catalogue will continue to be available until such inclusion process will be completed. In this respect we think that the improvement implemented in our Catalogue (e.g. full automated requests management) and especially the full integration of a professional issue tracker could be something the future “new” FI-WARE Catalogue could take advantage of.
Deliverable D2.3 FI-STAR FP7-ICT-604691
© FI-STAR consortium 2015 Page 78 of (78)
References
[1] https://www.FI-STAR.eu/
[2] FI-WARE DCRM Open Specification. (link)
[3] OMA LWM2M Device Management Protocol http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/oma-lightweightm2m-v1-0
[4] CoAP, Constraint Application Protocol, IETF RFC 7252, June 2014, http://tools.ietf.org/html/rfc7252
[5] Constraint RESTfull Environments (CoRE) Link Format, IETF RFC 6690, August 2012, http://tools.ietf.org/html/rfc6690
[6] FIWARE OpenSpecification IoT Back-End Device Management, http://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.IoT.Back-End.DeviceManagement
[7] FI-WARE (Back-End) Device Management implementation, http://catalogue.fi-ware.org/enablers/Back-End-device-management
[8] FI-WARE Configuration Manager-IoT Discovery specification, http://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.IoT.Back-End.ConfMan
[9] FI-WARE Configuration Manager-IoT Discovery implementation, http://catalogue.fi-ware.org/enablers/configuration-manager-iot-discovery
[10] Telefónica I+D (TID), http://www.tid.es/en, last accessed on July 11, 2014.
[11] FI-STAR Deliverable D2.1 Back-end Platform Services Modules Alpha Design.
[12] Nagios: systems and network monitoring; 2nd ed., by Wolfgang Barth, San Francisco: No Startch Press (2008)
[13] Zabbix – open source monitoring system, www.zabbix.com, last accessed on July 11, 2014.
[14] Collctd – The system statistics collection daemon. www.collectd.org, last accessed on July 11, 2014
[15] http://wiki.FI-STAR.eu/wiki/Connectivity_Service_Back-End_Beta
[16] http://catalogue.FI-STAR.eu/
[17] http://edu.fi-ware.org/
[18] NGSI Context Management; Candidate Version 1.0 – 03 Aug 2010: URL:http://www.openmobilealliance.org/
[19] ETSI M2M specification available in http://www.etsi.org/deliver/etsi_ts/, last visit in Feb 26, 2015
[20] ETSI M2M TS 102 689: M2M Service Requirements
[21] ETSI M2M TS 102 690: M2M Functional Architecture
[22] ETSI M2M TS 102 921: mIa, dIa and mId Interfaces
[23] Free open source implementation of TURN and STUN Server https://code.google.com/p/rfc5766-turn-server/, last visit in Feb 26, 2015
[24] RFC 5245: “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols”
[25] RFC 5912: “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP”