D4.1: Service & Tools specification

(1)

eXperimental Infrastructures for the Future Internet

D4.1: Service & Tools specification

Revision: v.1.0

Work package WP4

Task Task 4.1

Due date 30/09/2013

Submission date October 2013

Deliverable lead ATOS

Authors Joaquin Iranzo, Susana Gonzalez Zarzosa, Juan Alvarez, Ana Juan (ATOS) Jose Gonzalez, Jorge Valhondo (UPM) Ciro Formisano, Leonardo Vallini (ENG) Paul Grace (IT-IN) Daniel Gidoin, Pascal Bisson (THALES)

Reviewers Silvio Cretti (Createnet), Davide Dalle Carbonare (ENG)

Abstract This document contains the functional and technical specifications of all components produced in the framework of WP4 “Services and Tools”. This documentation also contains mockup design information required for training and knowledge transfer.

Keywords XIFI Services & Tools, Portal, Marketplace, Resource Catalogue, Yellow Page, Recommendation, SLA Management, Security Dashboard, Interoperability, FI-WARE, Generic Enabler.

(2)

Document Revision History

Version Date Description of change List of contributor(s) V0.1 05/09/2013 First TOC deliverable and

content

Joaquin Iranzo (ATOS) V0.2 25/09/2013 Circulation of first draft Joaquin Iranzo (ATOS) V0.3 01/10/2013 Circulation of second draft Joaquin Iranzo (ATOS)

V0.4 04/10/2013 Inputs to various sections Joaquin Iranzo, Susana Gonzalez Zarzosa, Juan Alvarez, Ana Juan (ATOS) Jose Gonzalez, Jorge Valhondo (UPM) Ciro Formisano (ENG) Paul Grace (IT-IN) Daniel Gidoin, Pascal Bisson (THALES) V0.5 04/10/2013 Overall revision Federico Facca (Create-NET)

V0.6 08/10/2013 Implementation of changes and added new information

Joaquin Iranzo (ATOS) V0.7 14/10/2013 Reviewer of the document Silvio Cretti (Create-NET)

Inputs to various sections Daniel Gidoin and Pascal Bisson (THALES)

V0.8 14/10/2013 General comments and changes to the document, grammatical improvements

Paul Grace (IT-INN)

V0.9 17/10/2013 Contributions to XIFI portal

Jose Gonzalez, Jorge Valhondo (UPM) V0.10 17/10/2013 Contributions to security

dashboard

Susana Gonzales Zarzosa (ATOS) V0.11 18/10/2013 Implementation of changes Malena Donato (ATOS)

V0.12 21/10/2013 Overall revision to the deliverable

Davide Dalle Carbonare (Engineering) V0.13 21/10/2013 Implementation of changes Malena Donato (ATOS) Joaquin Iranzo

(ATOS)

V0.14 22/10/2013 Inputs to various sections Joaquin Iranzo, Susana Gonzalez Zarzosa, Juan Alvarez, Ana Juan (ATOS) Jose Gonzalez, Jorge Valhondo (UPM) Leonardo Vallini (ENG) Paul Grace (IT-IN) Pascal Bisson (THALES)

V1.0 23/10/2013 Final version Joaquin Iranzo (ATOS)

Disclaimer

This report contains material which is the copyright of certain XIFI Consortium Parties and may only be reproduced or copied with permission in accordance with the XIFI consortium agreement.

All XIFI Consortium Parties have agreed to publication of this report, the content of which is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License1.

Neither the XIFI Consortium Parties nor the European Union warrant that the information contained in the report is capable of use, or that use of the information is free from risk, and accept no liability for loss or damage suffered by any person using the information.

(3)

Copyright notice

Project co-funded by the European Commission in the 7th Framework Programme (2007-2013) Nature of the Deliverable: R (Report)

Dissemination Level

PU Public 

PP Restricted to other programme participants (including the Commission Services) RE Restricted to bodies determined by the XIFI project

(4)

EXECUTIVE SUMMARY

This document contains the first functional and technical specifications of all the components produced for the framework of WP4, Services & Tools. These tools and services tackle the XIFI’s federation‘s main objective, which is to attract stakeholders, providing added value services and tools for users and participants. This document will be the base of the next software delivery, namely D4.2 Base Line Tools v1 (month 9, September 2013) and the D4.3 XIFI Marketplace implementation (month 12, March 2014) deliverables.

The WP has followed a pattern while identifying the scenarios and the requirements covered, analysing and describing the functionalities and including detailed technical specifications. The described modules are not independent as they are compliant with the federated architecture, which is described in D1.1 [1].

The document includes an architecture overview in order to understand and set the environment. Once contextualized, the following sections detail the components specification, that are the different modules, always following the same description, to facilitate further integration and unify all the designs.

The specification covers key components such as the XIFI Portal (Marketplace) as the Single Entry Point (Portal) where the XIFI users, the use case developers and infrastructure owners can access the XIFI federated services. In this portal all the federated services are available, namely Resource Catalogue (Yellow page), SLA Management, Interoperability Tools and Security Dashboard. Apart from these, two other components from FI-WARE are also included: the Cloud Portal and Monitoring dashboard.

It is important to note that the progress in this WP and evolution of these mentioned components will be done in parallel with the rest of modules and work packages (WP2, WP3 and WP5), since the design of the components is not static and will evolve over time. This means that the results of this document are crucial as it is the base for a subsequent development of the components resulting from the activities in T4.1, T4.2, T4.3, T4.4 and T4.5 after this release. However, it is not a final and static specification, and it should be actualized along the development, in order to achieve the ultimate goal of quality.

(5)

3.1.1 Scenarios ...24 3.1.2 Identified Requirements ...27 3.1.3 Functionalities ...28 3.1.4 Baseline Technologies ...30 3.1.5 Detailed Design ...30 3.2 XIFI Portal ...30 3.2.1 Scenarios ...31 3.2.2 Identified Requirements ...35 3.2.3 Functionalities ...36 3.2.4 Baseline Technologies ...37 3.2.5 Detailed Design ...37

3.2.6 Graphical User Interface (GUIs) ...40

3.2.7 Interfaces exposed (REST) ...42

3.3 Resources Catalogue and Recommendation tool ...45

3.3.1 Scenarios ...45

3.3.2 Identified Requirements ...54

3.3.3 Functionalities and Use Cases diagrams ...55

3.3.4 Baseline Technologies ...66

3.3.5 Detailed Design ...67

(6)

3.4.3 Functionalities and Use Cases diagrams ...90

3.4.4 Baseline Technologies ...100

3.5 Interoperability tools ...113

3.5.1 Scenarios / User stories ...113

3.5.2 Analysis of Interoperability in FI-WARE...116

3.5.4 Functionalities and Use Cases ...118

3.5.5 Baseline technologies. ...123

3.5.6 Overall Design ...123

3.6 Security and Privacy Dashboard ...134

3.6.3 Functionalities and Use Cases ...139

3.6.4 Baseline technologies. ...140

4 CONCLUSIONS ...148

REFERENCES ...149

APPENDIX A: WIRECLOUD MASHUP PLATFORM ...152

APPENDIX B: RESOURCE CATALOGUE, API OPERATIONS ...159

APPENDIX C: SLA MANAGEMENT, API OPERATIONS ...169

APPENDIX D: INTEROPERABILITY TOOL, API OPERATIONS ...174

(7)

LIST OF FIGURES

Figure 1: Visual Map of XIFI main building blocks. ...17

Figure 2: XIFI general FMC compositional structure diagram ...19

Figure 3: XIFI deployment architecture ...20

Figure 4: Portal high-level architecture ...21

Figure 5: UC-1 Identity Federation ...25

Figure 6: Sequence Diagram, Identity Federation ...25

Figure 7: UC-1 Identity Delegation ...27

Figure 8: Sequence Diagram, Identity Delegation ...27

Figure 9. Federated authentication ...28

Figure 10: Identity Delegation ...29

Figure 11: XIFI Portal within the XIFI Federation Platform context ...31

Figure 12 UC-1 Use Marketplace within the XIFI Portal ...33

Figure 13: Sequence Diagram, use Marketplace within the XIFI Portal ...33

Figure 14: Use Case, assessment service provided by XIFI Infrastructures ...35

Figure 15: Sequence Diagram, assessment service provided by XIFI Infrastructures ...35

Figure 16: XIFI Portal components ...38

Figure 17: Detail of the Application Mashup component ...39

Figure 18: GUIs - Public area ...40

Figure 19: GUIs - Public area, instances detail. ...41

Figure 20: GUIs - Public area, resource catalogue. ...41

Figure 21: GUIs - Login ...42

Figure 22: GUIs - Home page ...42

Figure 23: Application Mashup API Resources Summary ...43

Figure 24: Store API Resources Summary ...44

Figure 25: Use Case, the user finds the services/resources ...47

Figure 26: Sequence Diagram, the user finds the services/resources ...48

Figure 27: Use Case, the infrastructure owner advertises his resources ...50

Figure 28: Sequence Diagram, the infrastructure owner advertises his resources ...50

Figure 29: Use Case, the developer can provide the feedback of the XIFI resources ...53

Figure 30: Sequence Diagram, the developer can provide the feedback of the XIFI resources ...53

Figure 31: UC1 - Search of resources ...56

Figure 32: UC2 - Recover the resources information ...58

Figure 33: UC3 - Offering resources ...60

Figure 34: UC4 - Recommendation of resources ...62

(8)

Figure 36: Resource Catalogue FMC compositional structure diagram ...68

Figure 37: Sequence diagram: Search of resources ...70

Figure 38: Sequence diagram: Recover the detailed information of the resources. ...71

Figure 39: Sequence diagram: Offering resources. ...72

Figure 40: Sequence diagram: Recommendation ...73

Figure 41: Data model diagram of the Resource Catalogue...74

Figure 42: GUIs - Resource Catalogue main. ...76

Figure 43: GUIs - Specific Enablers ...76

Figure 44: GUIs - Other Services. ...77

Figure 45: GUIs - Infrastructure Map ...77

Figure 46: GUIs - Infrastructure map details. ...78

Figure 47: GUIs - Resource Information. ...79

Figure 48: GUIs - Boundaries metrics ...79

Figure 49: GUI - Details of the instance. ...80

Figure 50: GUI - Details of the instance (QoS) ...80

Figure 51: GUI - Main resource information . ...81

Figure 52: GUI - Other information ...81

Figure 53: GUI - Comments...82

Figure 54: GUI - Infrastructure Owner, management. ...83

Figure 55: GUI - Information new service. ...83

Figure 56: API REST of Resource Catalogue. ...84

Figure 57: Use Case, SLA Negotiation- Scenario 1 ...86

Figure 58: Use Case, SLA template - Scenario 2 ...88

Figure 59: Use Case, SLA Monitoring - Scenario 3 ...89

Figure 60: UC1 - SLA_Template_Management ...91

Figure 61: UC2 - SLA_Discovery ...93

Figure 62: UC3 - SLA_Negotiation ...95

Figure 63: UC4 - SLA_Enforcement ...97

Figure 64: SLA_Renegotiation ...98

Figure 65: SLA_Accounting ...99

Figure 66: Cloud4SOA architecture ...101

Figure 67: SLA Manager FMC compositional structure diagram...102

Figure 68: Sequence diagram: SLA Negotiation first cycle. ...104

Figure 69: Sequence diagram: SLA Negotiation ...105

Figure 70: Sequence diagram: SLA Enforcement ...106

(9)

Figure 73: GUI - Developer, management. ...109

Figure 74: GUI - SLA template ...109

Figure 75: GUI - new SLA template. ...110

Figure 76: GUI - Generic Enabler detail information. ...110

Figure 77: GUI - User metrics...111

Figure 78: API REST, SLA Management ...112

Figure 79: UML Use Case Diagram for the Future Internet Application Developer. ...119

Figure 80: UML Use Case Diagram for the Generic Enabler Developer. ...121

Figure 81: UML Use Case Diagram for an infrastructure owner of the XIFI federation. ...122

Figure 82: Analysing interoperability of an Enabler ...124

Figure 83: Analysing interoperability of an Enabler ...125

Figure 84: The FMC compositional structure. ...126

Figure 85: Pattern Execution Sequence ...128

Figure 86: Interface Comparison Sequence ...129

Figure 87: GUIs - Interoperability Tools Home screen. ...130

Figure 88: GUIs - Pattern-based Interoperability Testing ...130

Figure 89: GUIs - Output report ...131

Figure 90: GUIs - Check behaviour interoperability ...131

Figure 91: GUIs - Interface Compatibility Testing ...132

Figure 92: GUIs - Check behaviour interoperability ...132

Figure 93: API REST ...133

Figure 94: Use Case Diagram for Federation Security Officer ...135

Figure 95: Interaction Diagram for Federation Security Officer...135

Figure 96: Use Case Diagram for Correlation and Visualization of Security Events. ...137

Figure 97: Interaction Diagram for Local System Administrator ...138

Figure 98: Diagram with the relationships among components in the Security Dashboard. ...140

Figure 99: Sequence Diagram for Accountability Reporting ...142

Figure 100: Sequence Diagram for Correlation and Visualization of Security Events. ...143

Figure 101: Data model diagram for the Security Dashboard ...144

Figure 102: GUI - Security Dashboard: main page. ...145

Figure 103: GUIs - Analysis of events ...146

Figure 104: GUIs - visualization of incidents ...146

Figure 105: GUIs - configuration of policy...147

(10)

LIST OF TABLES

Table 1 – Identity Federation - Scenario 1 ...25

Table 2 – Identity Federation - Scenario 2 ...27

Table 3- Identity Federation - Requirements ...28

Table 4- Identity Federation - Functionalities ...30

Table 5- XIFI Portal - Scenario 1 ...33

Table 6- XIFI Portal – Requirements ...36

Table 7- XIFI Portal - Functionalities ...37

Table 8- Resource Catalogue - Scenario 1 ...48

Table 11- Resource Catalogue - Requirements ...54

Table 12- Resource Catalogue - Uses Case 1...56

Table 13- Resource Catalogue - Use case 2 ...58

Table 14- Resource Catalogue - Use Case 3 ...60

Table 17- Resource Catalogue - Features...65

Table 18- SLA Management - Scenario1 ...87

Table 19- SLA Management - Scenario 2 ...88

Table 20- SLA Management - Scenario 3 ...89

Table 21- SLA Management - Requirements...90

Table 22- SLA Management - Use Case1 ...92

Table 23- SLA Management - Use Case 2 ...93

Table 24-SLA Management - Use Case 3 ...96

Table 27- SLA Management - Uses Case 6 ...99

Table 28- SLA Management - Features ...100

Table 29- Interoperability tool - User Story 1 ...114

Table 32- Interoperability tool - Requirements ...118

Table 33- Interoperability tool - Use Case 1 ...119

Table 34- Interoperability tool - Use Case 2 ...121

(11)

Table 36- Interoperability tool – Features ...123

Table 37- Interoperability tool - List of components ...127

Table 38- Security Dashboard - Scenario 1...135

Table 39- Security Dashboard - Scenario 2...138

Table 40- Security Dashboard - Requirements ...139

(12)

ABBREVIATIONS

API Applications Programming Interface DoW Description of Work

FI Future Internet

FI-PPP Future Internet Public-Private Partnership Programme FMC Fundamental Modeling Concepts

GE Generic Enabler

GUI Graphical User Interface GWT Google Web Toolkit HMI Human Machine Interface HTML HyperText Markup Language IaaS Infrastructure as a Service IdM Identity Management

OSSIM Open Source Security Information Management PaaS Platform as a Service

PAP Policy Administration Point PDP Policy Decision Point PEP Policy Enforcement Point PRP Policy Repository Point QoS Quality of Service

REST Representational State Transfer SaaS Software as a Service

SE Specific Enabler

SAML Security Assertion Markup Language

SIEM Security Information and Event Management SDC Service Data Centers

SLA Service Level Agreement SSO Single Sign On

UC Use Case

USDL Unified Service Description Language UML Unified Modeling Language

XACML eXtensible Access Control Markup Language WADL Web Application Description Language

(13)

WSDL Web Services Description Language VDC Virtual Data centers

(14)

1 INTRODUCTION

The XIFI federated environment aims to be the community cloud for European FI-PPP developers enabled by advanced FI infrastructure in Europe. The FI-PPP [3] is an ambitious programme by the European Commission part of the 7th Framework Programme aiming at exploring the potential of a common platform for Future Internet technologies to establish new business ecosystems. XIFI, through this community cloud, will provide a market place to access: i) the web-based services offered by FI-PPP (i.e. the Generic Enablers developed by FI-WARE [4] and the Specific Enablers provided by Use Case Trials), ii) advanced Future Internet infrastructures that provide capacities, and iii) data to empower the applications developed by early adopters of FI-PPP technologies.

This document contains the first functional and technical specifications of all the components produced in the framework of WP4, Services & Tools. This work package aims to deliver tools to support the developers in selecting enablers according to different functional and non-functional parameters. In addition, tools delivered by this work package aim to simplify management and monitoring of the SLAs subscribed by users and will provide solutions to monitor security and privacy related parameters. These tools and services tackle XIFI's federation main objective, which is to attract stakeholders, providing added value services and tools for users and participants.

This document describes XIFI’s Services and Tools, which are responsible for providing the visual tools that the stakeholders need in the federated environment. There is only one access point which centralizes the components, so, it is important to design and define the graphical user interface that is the base of the interaction with the users. All of the components have a GUI to provide the functionalities, and they cover a wide variety of scopes:

The XIFI Portal (Marketplace): it is the Single Entry Point (Portal) where the XIFI users (UC/developers but also infrastructure owners) gain access to the XIFI federated resources/services. Such a common endpoint will be represented by the XIFI Portal, a platform designed to host, link and promote the rest of functional components, meanwhile it provides the homogeneous graphical user interfaces (GUIs) to obtain a fluent interaction. This portal integrates all of the federated services in a common environment: Resource Catalogue, SLA Management, Interoperability Tools and Security Dashboard

The Resource Catalogue (Yellow pages) and Recommendation Tool: it provides information about available enablers and infrastructures within the federation, making it easier for the experimenters to discover and compare them. The component is mainly used by a developer who wants to find and access the XIFI federated resources/services and the infrastructure owners who want to advertise the services provided by his/her infrastructure through this component. The user can browse/search the catalogue of the services/resources offered and find what he/she needs. SLA Management: it will allow the federating infrastructure to be able to provide mechanisms to

offer SLAs to experimenters, in order to allow the sustainability of the XIFI services. So, it is used by the XIFI Consortium together with infrastructure owners to define SLAs for their services and by the end users (developers) for monitoring of those SLAs.

Interoperability tools: it facilitates the usage of enablers offered by XIFI nodes and it augments the business value of joining the XIFI federation for infrastructure owners; providing guidance to experimenters/application developers to select enablers and assess interoperability claims this wish to make about the software produced to support their trials.

The Security Dashboard: it provides tools to manage on-line, and according to the desired level, the security and privacy of the resources adopted by experimenters. It allows monitoring of the federation resources against security risks; it is provided to the users through a Security Dashboard integrated into the Marketplace component and it gets security monitoring data from the security probes installed on each node.

(15)

are not included in the XIFI DoW that we consider essential to integrate in the XIFI portal from the beginning of the implementation, these are the Cloud Portal and the Monitoring Dashboard. It is not the objective to describe them in this document, since they come from FIWARE environment however their features are briefly included as follows.

The basic objective of the Cloud Portal is to facilitate the user of the cloud to perform operations over the underlying infrastructure. This includes perform actions such as: create user, manage projects, lunch instances on a base of images, create images in the image repository, retrieve flavors from the resource, etc. Moreover the portal facilitates management of a Virtual Data centers (VDCs), Services and Service Data Centers (SDCs), PaaS management and will offer monitoring statistics of the physical and virtual machines. It is implemented in a form of a Web GUI following the example of the portals that today's common cloud infrastructure managers like Amazon EC2, Eucalyptus, Cloud Sigma, Rackspace, etc. In concrete it bases its design principles on the OpenStack Horizon Dashboard.

The Dashboard Monitoring allows a quick and effective way to review key performance indicators at a glance. It is easy to read and shows a graphical presentation of the current status and historical trends. The users can focus on what matters and react faster to important events. It recovers the information of the Monitoring GE through the Context Broker GE which mediates between consumer’s producers (monitoring module) and the consumer applications (the dashboard). The dashboard is based on Wirecloud platform that allows creating and integrating heterogeneous data, application logic, and UI components (widgets/gadgets) sourced from the Web to create new coherent and value-adding composite applications like the Monitoring Dashboard.

The document provides all technical specifications that will be basis for implementation and integration of all of the federated services for the next software delivery, namely D4.2 Base Line Tools v1 (month 9, December 2013) and the D4.3 the XIFI Marketplace implementation (month 12, March 2014) deliverables. Going into detail, this document, on one hand, contains details of the requirements and functionalities that we want to cover, based upon the different inputs that include Use Cases, the infrastructure requirements and the architecture, and including, existing dependencies with the federation and the monitoring modules. On the other hand, it represents the first detailed version of the technical specification to be implemented. It is important to note that the work set out in this document as well as the work in WP4 should and will progress in parallel with the rest of modules, since the design of the components is not static and will evolve over time. These constant and necessary updates, in order to achieve the ultimate goal of quality, will be reflected in the collaborative tool adopted in XIFI: the wiki (http://wiki.fi-xifi.eu).

The methodology used to design the modules is based on the Unified Modelling Language (UML) standard, which gives us the early detection of problems, alignment of components, implementation and, above all, it allows us to make incremental design. Therefore, the structure of this document is aligned with this methodology and it is described in the section 3. All the modules are described through:

The definition of the scenarios that describe the potential use and applicability of the component. The identification of the requirements.

The description of the functionalities through the use case diagrams and the summary of the features (in order to identify them and do the follow-up during component’s development process).

The base technologies that each component is based on or makes use of.

A detailed design describes using UML diagrams the different component’s parts and the Fundamental Modelling Concepts (FMC) which provides a universal notation for the visualization and communication of structures and concepts in a coherent and efficient way. The

(16)

main diagrams to be used are sequence diagrams, component diagrams, data model, and activity diagrams.

Graphical User Interface shows the component’s mockup. The intention is not to be a user

manual, but to provide an overview of what the component aims to deliver and therefore it is not focused on the look and feel.

In addition, the exposed interfaces (REST) describe the external services interfaces provided by the module.

In the following section, the authors of this document introduce a map of XIFI system and services that allows the readers to orientate across the different building blocks of XIFI. The same map will be available in all XIFI technical related deliverables so as to provide a common feeling to the reader. The authors plan as well to adopt the same principle to guide external stakeholders across the different public documents that will be exposed in the XIFI wiki [31]. It is worth mentioning, in relation to the project wiki, that while this is a static document, the wiki is a live entity and represents the "working" documentation where all the latest evolutions of requirements, derived scenarios and architecture are available.

1.1 A visual map of XIFI main building blocks (you are here!)

XIFI offers a marketplace to European large-scale trial developers to access FI-PPP technologies and Future Internet infrastructures. The marketplace provides access to Generic Enablers developed in FI-WARE (the horizontal platform), and potentially (to be checked when they will be provided) to the Specific Enablers developed by Use Case projects (the vertical platforms), through a highly available and reliable "federation" of infrastructures. To complement and support the above-mentioned technologies (GEs and SEs), XIFI leverages on FI infrastructures with different characteristics (e.g. in terms of location, user community, quality of service, special hardware).

XIFI aims at illustrating the potential of such a marketplace through different showcases that will act as demonstrators of XIFI offer. For example, one of our showcases will illustrate how developers can take advantage of XIFI multi-site infrastructure to build distributed applications with high-availability set-up and QoS control across the different used sites.

The XIFI offer comprises two main parts: the platform, i.e. the "virtual" market place that allows end-users to browse through, configure and access enablers and infrastructures in preparation for their experimentations and the operational services, i.e. the set of activities around the platform to provide a comprehensive "package" to XIFI end-users. The operational services and the platform go beyond pure technical considerations: they offer a summary vision of technical and business aspects that constitute the XIFI offering.

The XIFI platform is conceived with the context of the community cloud deployment model, and offers all three traditional services models of cloud platforms: Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) [24]. The XIFI platform is composed of different elements, such as:

User Interfaces comprising tools for browsing, discovering, recommending, configuring, allocating and deploying resources; such interfaces provides as well means to interact with operational services provided by infrastructure owners, such as developer support and SLA management;

(17)

available through the federation, the shared security and identity management across the federation, the software automation for the installation of new nodes and new services on top of nodes;

Dynamic Network Management to support connectivity configuration across federation nodes at the level of single services, fulfilling changing user demand;

Resource Monitoring that supports the active and passive collection of data from physical and virtual sources, providing the capacity to gain access to meaningful information on infrastructure and service availability;

The XIFI operational services are a set of fundamental services to support the management of the XIFI platform as well as address the needs of different actors, i.e. infrastructures owners and application developers. Most of these services are governed by protocols and procedures to ensure the operational continuity of the XIFI platform. Such operational activities cover management of the nodes - in particular Level 1 and Level 2 support to developers-, support to infrastructure owners in deployment and maintenance of the platform (with special focus on new infrastructures joining XIFI during its second year) and training for developers and infrastructures owners (it will be built exploiting the showcases and referring to the documentation available from the technical activities over the project).

XIFI building blocks are shown in

Figure 1

. In this deliverable the authors will provide an overview of XIFI user interfaces and their specifications.

(18)

In this deliverable we will focus on providing added value services and tools for the federation environment within “User Interfaces” and “Federated Cloud and Services Management” main blocks

.

1.2 Scope

This deliverable focuses on the definition of the different services and tools which provide added value to the federated environment, and it describes both the functionalities and technical specifications of the different covered modules. It is considered that the scope is mainly:

To detail the functionalities that covers the stakeholders’ necessities. In order to do it, the focus is on its definition and also on the visual point of view through the mock-ups. Mock-ups have the objective to introduce the visual integration and usability, so, the aim is not provide a user manual (since we are in the design phase), however this approach will be necessary in order to provide inputs for other WPs

To identify existing tools that our components will be based upon (mainly FI-WARE components), and integrate all in a coherent and harmonious way. As it can be observed, there is a large diversity of third-party components and tools, and therefore integration becomes challenging.

To design the technical specification that will be necessary to develop the modules in the first cycle for the deliverables: “D4.2 Baseline Tools v1” and “D4.3 XIFI Marketplace implementation”. This specification emphasizes the component architecture and the integration between modules, through the UML definition. It also defines a first API, detailing the required interfaces that the modules must expose to cope with all the identified features. Further, it defines the transversal integration of all of the modules (visual and security); this is necessary for the deliverable “D4.3 XIFI Marketplace implementation” where all the described modules have to be integrated within the same environment.

(19)

2 ARCHITECTURE PRINCIPLES

2.1 Architecture Overview

This section presents an overview of the architecture, focusing on the details associated to the modules which are included in WP4, Service and Tools. In the document D1.1, it is described thoroughly the XIFI architecture. It is not the intention of this document to enter further detail about it; however it is necessary to introduce this general vision, in order to frame the specific work on services and tools.

Figure 2: XIFI general FMC compositional structure diagram

The above figure shows the FMC compositional structure diagram highlighting the relations among the components. Two parts can be clearly distinguished:

(20)

The lower box represents a generic node of the XIFI federation.

The upper box contains the "federation services", i.e. the services offered to support the management and provisioning of resources in a unified fashion.

For the meaning of the acronyms related to the WARE GEs, please see the corresponding FI-WARE documentation. It has to be mentioned here that this architecture diagram has been presented and then validated inside the XIFI/FI-WARE architectural working group (see Document D1.1 [1], section 3.4).

In addition, to guarantee a robust and sustainable architecture, all the components should be deployed: Either having all the XIFI federation services and repositories (like monitoring, security, portal, catalogues etc.) distributed on all the nodes. This can complicate a lot the management of the federation, in particular, presenting synchronization problems among the different nodes;

Or having all the XIFI services on just one node does not assure high availability.

For this reason, as depicted in the following figure, two nodes are considered as masters and the other three as slaves: the master nodes are the ones where, in addition to the features deployed on the slave nodes, the centralized parts of the federation services (i.e. the components needed to manage the federation) are deployed whilst the slaves ones are the nodes where only the software needed for deploying and managing user services is installed.

Note: not all of the relations between the nodes are depicted

.

Figure 3: XIFI deployment architecture

Such services and tools, which are covered by this document, are located only in the master nodes. To support high availability of the XIFI platform, a number of services are provided by each node of the federation. This avoids any disruption in case the master nodes experience some outage. This is the

(21)

distributed on all nodes in order to allow the end users to access the XIFI services hosted on a particular node even though the central authentication and authorization system is down. Similar considerations can be applied to the monitoring system.

This document focuses on the federation services, and more concretely on the services and tools which are covered by WP4. The figure below represents the high-level overview and integration of all the federated services and tools, showing how the different modules are connected to each other.

Figure 4: Portal high-level architecture

2.2 Components functionality overview

Before going into detail about the description of the different components, this section presents an overview of each component‘s functionality.

Identity Federation and Single Sign On

The available services exposed in the Marketplace may be deployed in remote nodes and requested directly without passing anytime through Marketplace. Otherwise there are services inside the Portal itself (the Marketplace is some of these). In order to allow easy access to all this kinds of services and in order to enable one service to use another service under a User authorization, the Portal (as central part of the system that interact both with IdM and internal/external services) has to "understand" both Federation and Delegation. The User just authenticated in the IdM could access to (or could delegate a third actor to access to) service in order to accomplish an extended Single Sign On feature.

XIFI Portal (Marketplace)

By agreement within the project, XIFI end users (Use Case Projects and single FI developers) will have a single entry point exclusively to gain access to the services and tools that the federation is intended to support. Such a common endpoint will be represented by the XIFI Portal, a platform designed to host, link and promote the rest of functional components; meanwhile it provides the indispensable graphical user interfaces (GUIs) to obtain a fluent interaction. The portal will not be limited to be a container of applications; it will integrate the framework in a Marketplace where to expose the available services to the end users. Furthermore, the portal shall include an Identity Manager in charge of resolving credentials in a unique manner through the entire federation.

Resource Catalogue (Yellow page) and Recommendation Tool

The services provided by this component could be called Yellow Pages, however, this name may bring controversy as it is a registered trademark. To avoid it, Resource Catalogue is adopted instead.

(22)

Following the philosophy of the XIFI federation, the module brings together all of the resources, which are heterogeneous, into a single repository; providing information about available enablers and infrastructures within the federation, making it easier for the experimenters to discover and compare them. The component is mainly used by a developer that wants to find and access the XIFI federated resources/services and by an infrastructure owner that wants to advertise the services provided by its infrastructure. The user can browse/search the catalogue of the services/resources offered and find what he/she needs.

On the other hand, the recommendation tool complements the resource catalogue since it allows to provide feedback about the resources. This allows to share the user experience, facilitating the search, the discovery and the comparison between them. Furthermore, the providers will be able to use this information to know the feeling and comments about their resources and it will allow them to apply the necessary actions to improve their services.

SLA Management

Ensuring Service Levels is an important characteristic in order to provide reliable and stable services. Providing the users with a defined Quality of Service – no matter, if these agreements are legally binding contracts or not, it is an important feature for XIFI’s Federation users. SLA Management will be able to provide a mechanism to offer SLAs to experimenters, based on WS-Agreement specification [9]. It will be used by the XIFI Consortium together with infrastructure owners in order to define Service characteristics and QoS for their services and by the end users (developers) for monitoring of those SLAs.

Interoperability tools

The Interoperability Tool allows multiple XIFI stakeholders to perform tests and checks that will allow them to validate their interoperability claims, where interoperability is the ability of one or more systems to understand and exchange information with one another. Available as a web-based tool accessible from the XIFI portal, users are able to test that their own developed or hosted software interoperates within common configurations of FI-WARE enablers. The developers of new Future Internet applications can execute their software to test how interoperates with these patterns; the tool will report any interoperability problems occurring due to differences in protocol and data. Developers of new enablers will be able to compare their development against the open enabler specifications published within the XIFI federation. Importantly, the interoperability tool is a guide for users; it does not guarantee or prove interoperability and it does not act as a certification authority for compliance with any specification. However, the interoperability tool can be leveraged in support of either of these goals.

Security Dashboard

The Security Dashboard will provide a tool to manage on-line the monitoring of security and accountability events which take place in the XIFI Platform. These events will be collected from different devices existing on the network through the installation of agents. The Security Dashboard will be available as a web interface integrated in the XIFI portal to allow the Federation Security Officer and the local System Administration to configure and define the events to be collected and the security directives to be monitored as well as to visualize the events collected and the alarms generated in order to analyse and identify risks and vulnerabilities. This knowledge will allow to take mitigation actions in the XIFI Federation Platform and Infrastructure.

(23)

3 COMPONENT SPECIFICATION

We are utilising agile approaches for the design and development of the services and tools, and hence there is no clear-cut requirements phase. Instead in the first phase we specify a set of use cases that capture the initial requirements; these are based upon the information obtained from the original Description of Work for the XIFI project and also the survey-based requirements capture (which includes input from the Use Case Trial projects and the infrastructure owners) that was used to inform the XIFI architecture design. Subsequently, the use cases will be iteratively refined as new requirements emerge. Such agile methodology is well suited to ‘software engineering tool’ development where a concrete set of requirements cannot be captured until the end-users have experience of the capabilities of the tool itself. Hence, all the changes and evolutions will be reflected on a live document, using tools as Redmine and Wiki. These tools also allow the XIFI project to follow-up the roadmap of the different components.

The document is composed mainly by modules which have been described in a same manner. The common structure has been chosen to maintain this agile approach and to deliver the document as the D4.1. It is complicated to find a common structure and content for all the modules, since they are unalike and heterogeneous. So, the modules do not always explain in detail the same sections and the content may have little variations, however, basically the approach and the ultimate goal will be the same.

The structure of the modules follows the next sections:

Scenarios: As we have commented, we want to identify the requirements and we specify a set of scenarios, described by Use Cases following the UML notation. We can consider that it is a brief description, or story, that describes the use of the system. They identify the stakeholders, roles and their constraints, describing the relevant aspect of the environment. Another approach, to achieve the same objective, is to use the User Stories like in the Interoperability tools section.

Identified Requirements: Based upon the scenarios and analysis of the survey-based requirements and the XIFI architecture design, we can identify the requirements that can be functional or technical. It is only a simple list to identify them.

Functionalities and Use Cases: After identifying the stakeholders and requirements, we want to provide richer use case descriptions of the modules, in order to enter more in detail of the functionalities. These UML use case diagram specifications are then used for the design of the modules and most importantly the user interface design. We also introduce a summary of features that allow to identify and follow-up the evolution of them, introducing the intended delivery iteration (first or second which are in harmony with the two years of the project).

The Baseline Technologies describes the technologies that we have used or based on the design. The Overall design section goes into detail about the technical design. The modules can decide

what are the best diagrams to describe them, since all the diagrams are useful in a heterogeneous context. The mainly diagrams are the FCM, the sequence, the activity and the data model.

The Graphical User Interface (GUIs) is one of the most important sections, since all the described modules interact with the user directly. As we are in the design phase, we are not in a position to create a real GUI. Hence, we have considered creating a mockup, focusing more in the behaviour and the functionalities than in the look and feel.

Interfaces exposed section describes the external services interfaces provided by the module. This approach allows decoupling the layers, i.e. we can consider different types of graphical interfaces (html, mobile, desktop applications….) or other components can interact directly with the module (business-to-business).

(24)

3.1 Identity Federation and Single Sign On

XIFI users will have access to a plethora of services, potentially across different Administrative Domains (each single node, is by definition in XIFI federated approach a different Administrative Domain). Users should be able to access the different services in a transparent way regardless their access point, so as to simplify their authentication process across the different domains. This functionality is generally covered by so called Identity Management (IdM) Systems.

In the specific case of XIFI, an Administrative Domain represents one of the different organizations that are part of XIFI federation and hence in charge of one of the nodes (or regions to use a more common cloud terminology) part of the XIFI federation. IdM is one of the different functionalities related to security in IT systems.

An Identity Federation requires the ability for a user belonging to an Administrative Domain (e.g. XIFI Node A) to use his credentials to access a service or to manage resources on a different Administrative Domain (e.g. XIFI Node B). In a Federation, Administrative Domains shares a number of policies, practices and protocols to manage the identity and trust into users, services and devices across them. Single Sign On (SSO) is a subset of Federated IdM where a user has a single set of credentials to access services on more Administrative Domains. We speak about Delegation when a user uses his credentials to allow another actor (e.g., human or service) to use a service (or to manage a resource) on his behalf. Both scenarios are relevant in the context of XIFI.

In the context of this deliverable, IdM is just a functionality that XIFI Portal will use to ensure the access to different resources by users. In the next sections we provide a description of scenarios that should be supported by an IdM from the perspective of XIFI Portal. The actual deployment (or integration) of the IdM solution occurs in Task 2.2, responsible for the federation APIs.

3.1.1 Scenarios

This section collects scenarios of usage of the IdM that are relevant from the perspective of XIFI portal.

3.1.1.1 Scenario 1 – Identity Federation and Access to Federated Services

Section Description Use Case

id Identity Federation – Scenario 1 Title &

Description

Identity Federation and Access to Federated Services: A User member of the Federation can access services offered by all Federation members

Author(s) ENG, ATOS

Actors User (it can be any XIFI user: e.g. Developer, Administrator, …), Identity Provider, Service Provider

Objective Users registered on a XIFI Node, compatibly with their role, should be able to access services on other XIFI Nodes in a transparent way

Pre-Conditions

The user is registered in at least on XIFI node (including the node hosting XIFI portal) and the user has the policies which will be applied.

The service has been deployed and it is ready to be used.

Process 1. The user wants to use the service and he creates an access request to it.

(25)

Dialog request. The service calls the Federation Authority in order to validate the user’s credentials.

3. The Federation Authority validates the credentials among the different Administrative Domains of the Federation, and it asks the user to confirm identification (if it is necessary).

4. The user introduces the credentials in order to be validated and identified in the Federated environment.

5. The Federation Authority confirms to this service, if this user can access or not to it.

6.

The service allows the access to this user. Variations NA

Post-Conditions The user is authenticated on the service he requested. Diagrams Use Case Diagram

Figure 5: UC-1 Identity Federation

Interaction Diagram

Figure 6: Sequence Diagram, Identity Federation

Issues &

Notes NA

(26)

3.1.1.2 Scenario 2 – Identity Delegation

id Identity Delegation – Scenario 2 Title &

Description

Identity Delegation: A User requests access to a service A that needs to access, on behalf of the user, Service B

Author(s) ENG, ATOS

Actors User (it can be any XIFI user: e.g. Developer, Administrator, …), Service Provider. Objective Users registered on a XIFI Node, compatibly with their role, should be able to delegate

access to other services on their behalf in a transparent way

Pre-Conditions

The user is registered in XIFI and the user policies have been created. The services have been deployed and they are ready to be used Process

Dialog

1. The user wants to use the service A (delegated service) and he creates a request to access it.

2. The service A, which belongs to a Delegated Service Provider, has to validate the user request. The service A calls the Federation Authority in order to validate the user’ credentials.

3. The Federation Authority validates the credentials among the different Administrative Domains of the Federation, and it asks the user to confirm identification (if it is necessary).

4. The user introduces the credentials in order to be validated and identified in the Federated environment.

5. The Federation Authority confirms to this service A, if this user can access or not to it.

6. The service A creates an access request to the service B on behalf of the user. 7. The service B, which belongs to another Service Provider, has to validate the

service A request on behalf of the user. The service B calls the Federation Authority in order to validate the credentials of the user and the delegated Service Provider. 8. The Federation Authority validates the credentials of the user and the delegated

Service Provider, among the different Administrative Domains of the Federation. If it is necessary, it asks the delegated Service Provider to confirm the identification (the user has been confirmed in the step 4).

9. The delegated Service Provider confirms the credentials to be identified in the Federation environment.

10. The Federation Authority confirms to the service B if this service A on behalf of this user can access or not to it.

11. The service B allows the access to this service A on behalf of this user.

12.

The service A allows the access to this user (and indirectly to the service B). Variations NA

Post-Conditions Service A access service B on behalf of the user Diagrams Use Case Diagram

(27)

Figure 7: UC-1 Identity Delegation

Figure 8: Sequence Diagram, Identity Delegation

Issues &

Notes NA

Table 2 – Identity Federation - Scenario 2

3.1.2 Identified Requirements

The following table list requirements to be fulfilled by the IdM solution adopted in XIFI. Req. num Description

R1

Shall support identity federation across different organizations (XIFI Services, Tools, Entities and Components may belong to different Administrative Domains)

(28)

R3 Shall support integration of different existing IdM solutions in place in XIFI nodes

R4 Shall adopt standard and extensible protocols and technologies.

R5 Shall support protocols compatible with different clients (browsers and other web based services)

R6 Shall implement FI-WARE IdM GE Open Specifications Table 3- Identity Federation - Requirements

3.1.3 Functionalities

Feature Description Federated

Identity Management

Figure 9. Federated authentication

In XIFI, the IdM will provide Federated Identity Management as depicted in Figure 9:

1. User Agent (UA) requests access to a service (Service_1).

2. Service_1 redirects (Red_1) UA to the Service_1 Gateway for authentication. 3. Service_1 Gateway redirects UA to the User Agent Gateway (Red_2). To

perform this operation, Service_1 Gateway has to know information about the User (his Administrative Domain). If Service_1 can manage this information then the UA can be redirected directly to User Agent Gateway without passing through Service_1 Gateway (this last case represents the behaviour of SSO, in the case of Federated authentication this occurs when Service_1 has no or very limited IdM logic).

4. The User passes his credentials through User Agent Gateway to the IdM (the IdM instance that can validate his credentials). Gateways represents only

(29)

IdM.

5. Authorization token are passed back to Service_1 (steps 5 and 6). The Authorization token may include different information about users (e.g. attributes) in the different administrative domains. A global knowledge on users can be achieved only by information exchange between the IdMs of the different administrative domains.

6. The user uses the service (step 7)

Identity Delegation

Figure 10: Identity Delegation

IdM in XIFI will provide Identity Delegation functionalities as depicted in Figure 10:

1. User Agent (UA) requests access to a service (Service_1).

2. Service_1 redirects (Red_1) UA to the Service_1 Gateway for authentication. Service_1 passes to Service_1 Gateway also its credentials.

3. Service_1 Gateway redirects UA to the User Agent Gateway (red_2) accordingly to the User’s Administrative Domain. ).

4. The User passes his credentials through User Agent Gateway to the IdM (the IdM instance that can validate his credentials). Gateways represents only logical entities, they do not process credentials that are passed only to the IdM.

5. The User Authorization token is passed back to the Service_1 Gateway. 6. The Service_1 Gateway pass back both authorization tokens are passed back

to Service_1. Authorization token may include different information about users (e.g. attributes) in the different administrative domains. A global knowledge on users can be achieved only by information exchange between the IdMs of the different administrative domains.

(30)

7. Service_1 requests access to Service_2. The request includes User Authorization and Service_1 Authorization token.

8. Service_2 contact IdM through Service_2 Gateway and verify the validity of them.

Table 4- Identity Federation - Functionalities

3.1.4 Baseline Technologies

Following the “eat your own dog food” principle we introduce below the IdM GE that will provide IdM solution for XIFI.

IdM GE

The FI-WARE specification Identity Manager GE [35] is the reference technology to manage identities in the FI-PPP. By browsing the FI-WARE Catalogue [19], the available implementation of such Generic Enabler can be found in the chapter Security. IdM GE, as regards Federation and Delegation, should support SAML [3] and OAuth [6]. The latest released version of the IdM GE does not implement SAML support yet.

3.1.5 Detailed Design

IdM, as early mentioned, is not a core development of work package 4. It is rather a service adopted as it is by Cloud Portal and existing interfaces. Extensions and requirements non supported by current IdM GE implementation will be taken into consideration within the Federation Layer API activities (Task 2.2).

3.2 XIFI Portal

The XIFI Portal represents the component enclosed in the XIFI Federation Platform (the picture below displays how it is related to the rest of the context) from which XIFI end users (Use Case Projects and single FI developers) will gain access to the services and tools that the federation is intended to provide. Therefore, each of these services shall be accessible through a graphical representation (a Graphical User Interface - GUI) supported by this portal.

The FI-WARE project does represent a key contributor in the framework of XIFI. The provisioning models that infrastructure nodes will be required to provide are closely related to the technology specified by FI-WARE. However, this project as itself includes a set of portals and frameworks that might be quite interesting to be linked within the XIFI-specific portal. There are self-service interfaces provisioning Generics Enablers (GEs), such as the FI-WARE Cloud Portal [12], which may imply a meaningful inclusion. This is the way by which the end user will be able to have access to the complete framework from a common endpoint, the XIFI Portal.

(31)

Figure 11: XIFI Portal within the XIFI Federation Platform context

Within the portal there is a key component which is in charge of managing the service offerings to the end users; the XIFI Marketplace. This component is mainly responsible for wrapping the functionalities provided by the Resources Catalogue, Recommendation Tool, and some other features related to the SLA management and the monitoring of the infrastructures performance/status.

3.2.1 Scenarios

This section collects some initial XIFI Portal-oriented scenarios which may represent valuable source of requirements as starting point in the design of this platform. As the portal will be required to enclose a diverse set of components, such as the Resources Catalogue or the SLA Management, following scenarios aim at providing a general overview of the workflow among them.

3.2.1.1 Scenario 1 - Use the Marketplace within the XIFI Portal

id UC-7.1

Title & Description

Use the Marketplace within the XIFI Portal: A FI Developer gains access to XIFI Federation Services accessible via the Portal contained in the platform

Author(s) UPM

Actors FI Developer

Objective The Portal shall be the Single Entry Point which enables FI Developers to leverage XIFI resources and services provided by the infrastructures

(32)

Conditions GEs Process

Dialog

1. Authentication: developer gains access to the portal using his credentials for identification, which might be associated to privacy/business terms. It may model his profile as a customer

2. Browse Resource Catalogue: infrastructures need a catalogue to market their available resources, both providing and hosting models. FI Developer uses this catalogue for browsing the existing capabilities

o Resources Discovery: available and new resources, in terms of GE instances and infrastructure capabilities, first need to be discovered

o Instance/Node Recommendation: among all possible instances/nodes, system may recommend one according to functional and technical parameters

o Process monitoring metrics: monitoring metrics provided by XIFI Federation Monitoring shall be processed and used to elaborate a recommendation according to a criteria

3. Select Provisioning Model: developer accesses to XIFI resources according to the decision between two different provisioning models: SaaS and PaaS

o Provide SaaS: in case it is selected, all the functionalities related to Software-as-a-Service (SaaS) are setup. (*Further details are described within D3.1 [2] in the preliminary scenario UC project wants to setup and use an experimentation

environment)

o Provide PaaS: in case it is selected, all the functionalities related with Platform-as-a-Service (PaaS) are setup. (*Further details are described within D3.1 [2] in the preliminary scenario UC project wants to setup and use an experimentation

environment)

o Define SLAs & Accounting: business terms need to be defined between the developer and the selected infrastructure according to the selected service

o

Assure Interoperability: overall interoperability needs to be guaranteed

Variations NA

Post-Conditions The FI Developer is in condition to use the service(s) provided by XIFI Diagrams Use Case Diagram

(33)

Figure 12 UC-1 Use Marketplace within the XIFI Portal

Figure 13: Sequence Diagram, use Marketplace within the XIFI Portal

Issues &

Notes NA

(34)

3.2.1.2 Scenario 2 - Assessment service provided by XIFI Infrastructures Section Description Use Case id UC-7.2 Title & Description

Assessment service provided by XIFI Infrastructures: analysis and feedback of infrastructure services according to the actual performance.

Author(s) UPM

Actors FI Developer

Objective Assessment of services and rating infrastructures' provision.

Pre-Conditions FI Developer has previously selected and used a XIFI service. Process

Dialog

1. Analysis of metrics: data gathered from Federation Monitoring is processed to be analyzed directly by the developer through a graphical interface.

o Network/Datacenter Performance: it handles monitoring metrics related to the network and datacenter performance.

o GEs Performance: it handles monitoring metrics related to the GEs performance

2. Check SLAs: leveraging monitoring data, the developer can check and compare the SLAs he agreed on the provisioning.

3. Update Resource Catalogue: developer may enhance the catalogue by updating some information in terms of valuation.

o Provide Reviews: valuation in terms of comments/suggestions. o Rating: valuation in terms of rates.

Variations

NA

Post-Conditions

Resource catalogue shall include the feedback provided. These valuations may influence in the recommendation process of instances/nodes.

(35)

Figure 14: Use Case, assessment service provided by XIFI Infrastructures

Figure 15: Sequence Diagram, assessment service provided by XIFI Infrastructures

Issues &

Notes

NA

3.2.2 Identified Requirements

(36)

Req num Description

R1 Shall represent the single entry point for end users to gain access to the XIFI Services and Tools.

R2 Shall fulfil the integration of heterogeneous data, application logic and UI components.

R3 Shall be a platform capable of connecting web applications from multiple domains.

R4 Shall be also capable of connecting widgets to back-end services.

R5 Shall be oriented to end users without programming know-how, at first glance. R6 Shall provide mechanisms to extend features through development of new

applications.

R7 Shall use web technologies and principles: e.g.. RESTful services, HTML and CSS.

R8 Shall be as much compliant as possible with existing FI-WARE technology. R9 Shall not be limited by Web Browsers capabilities.

Table 6- XIFI Portal – Requirements

3.2.3 Functionalities

Feature Description

Provide Graphical User Interfaces (GUIs)

Since the portal is the common entry point for the end users (Use Case Projects and single FI developers) to the XIFI and FI-WARE frameworks, it needs to approach and empower visual representations in different manners:

XIFI services and tools which may be developed by following the model of an Application Mashup platform (see the following sections for further details). Widgets are the key elements of the composition model and shall provide a visual representation of the service data and functionality to which they are bound.

However, FI-WARE-related platforms/portals do not require new GUIs. The portal shall keep an area in its representation dashboard dedicated exclusively to them, extending and integrating the existing interfaces.

Previous principles may be extensible to those XIFI services which provide their own graphical representation.

Support for Wiring mechanism

Widgets are isolated applications and the XIFI Portal is in charge of providing a mechanism to compose a fully functional web application from different widgets through events and data sharing. Widgets expose (data/event) inputs and (data/event) outputs, so that an output from one widget can be linked to other widgets' inputs. This is the way, intercommunication and coordinated behaviour may be reached.

(37)

mechanism services or data sources via a set of operators. Such operators do not offer a GUI, but through their abstract representation they can be wired to widgets allowing data flow, i.e. they represent the means to dynamically associate the widgets with the concrete services or sources of information to be used in the context of a particular mashup.

Enable the creation of a composite web application through graphical means

Empower end users with few or no programming skills to create and share their own web composite applications in a fully visual fashion.

Support the XIFI Marketplace

XIFI infrastructures require a virtual space where to make accessible, offer and deal with those federated services that are willing to be provided to end users. This task shall be fulfilled by a marketplace within the portal.

Table 7- XIFI Portal - Functionalities

3.2.4 Baseline Technologies

Attending the requirement of leveraging available FI-WARE technology as far as possible, below we introduce some relevant tools which may be considered as a starting point during the implementation and integration stage.

Application Mashup

The FI-WARE specification Application Mashup GE [13] may be used as the reference technology to be considered with regards to the end-user centred Web Application Mashup component (to be introduced in the section 3.2.5). By browsing the FI-WARE Catalogue [19], the available implementation of such Generic Enabler can be found in the chapter Applications/Services Ecosystem

and Delivery Framework; such tool is Wirecloud [14].

Marketplace

The FI-WARE specification Store GE [15] may be used to develop the Marketplace of infrastructure resources that XIFI requires to include within the portal. By browsing the FI-WARE Catalogue we can find that there is available an implementation integrated with the previously commented Wirecloud

GE design. Such tool is included in the chapter Applications/Services Ecosystem and Delivery Framework and it is called WStore [16].

3.2.5 Detailed Design

Going through a modular analysis of the XIFI Portal, the figure below represents a FMC diagram of the main components within the portal and how they are related to other key modules of the platform.

D4.1: Service & Tools specification

eXperimental Infrastructures for the Future Internet