CLOUD INFRASTRUCTURE - Ningapi.ning.com/files/ys89Oj1AWQ8jnPo7W7qPycGyrXzt0... · includes an Introduction (section 1) and some Conclusions ... Section 2 details the vision of TCBL

CLOUD INFRASTRUCTURE

TCBL 646133 DELIVERABLE 6.2

31st March 2016

Co-funded by

Horizon 2020

DELIVERABLE

PROJECT ACRONYM: TCBL

GRANT AGREEMENT N.: 646133

PROJECT TITLE: Textile & Clothing Business Labs

D 6.2: Cloud infrastructure

V5, 31.05.2016

AUTHORS: Brecht Vermeulen (iMinds) Dieter De Paepe (iMinds)

Jesse Marsh (City of Prato)

REVIEWERS: Paolo Guarnieri (City of Prato) Marc Boonstra (Waag Society)

Francesco Molinari (CCA)

CO-FUNDED BY THE EUROPEAN COMMISSION IN H2020 TCBL: TEXTILES & CLOTHING BUSINESS LABS, GRANT AGREEMENT N. 646133

Dissemination Level

PU Public

Co-funded by

Horizon 2020

3

EXECUTIVE SUMMARY This deliverable reports about the Cloud Infrastructure design and implementation activities

carried forward during the first nine months of the TCBL project (until March 2016). It consists

of three main parts:

A discussion of the envisaged role of the Cloud environment in the economy of the

project, as per the DoA provisions – namely to embed all of the ICT enabled services

supporting the TCBL ecosystem, particularly, but not limited to, the Knowledge

Spaces and the Business Services1;

An overview of the actual implementation process of the TCBL Cloud Infrastructure

and its early results;

A description of the software enablers that should be used in TCBL and have

therefore been evaluated by the host organisation iMinds.

These three parts represent the core sections (2, 3 and 4) of this Deliverable, which also

includes an Introduction (section 1) and some Conclusions (section 5). Section 2 details the

vision of TCBL on the usage of Cloud infrastructure for running its services. The services will

be run on the iMinds Cloud which is located in Ghent, Belgium and operated according to the

TCBL principles of data privacy, etc. (also outlined therein). iMinds personnel is administering

this Cloud.

Section 3 further describes the three different Cloud environments supported by iMinds:

The VMware environment, which is fully redundant and targeted towards production

services. Fully administered and supported by iMinds.

The Virtual Wall environment, which is targeted towards testing out software and

services. Fully administered and supported by iMinds.

The FIWARE node environment which is an implementation of a FIWARE node at

iMinds. iMinds follows only the FIWARE guidelines and can only support in a very

limited way users on this. FIWARE also does not support Windows™ operating

systems.

Network wise, the three Clouds are connected to Belnet, the Belgian NREN (research network

provider) which is connected to Geant, the EU research network. Up to 10Gb/s bandwidth is

available.

Section 4 identifies two software enablers that can take benefit from existing implementations:

namely Log event logging and central authentication. For Log event logging the FIWARE

Orion pub-sub software can be used or one of the implementations of the Tin Can API (xAPI).

On due time, the developers should evaluate further what is exactly needed for event logging.

The other evaluated enabler ‘identity provider’ is much more complex and depends on how the

TCBL services and user management will be structured. An Oauth2 provider implementation

seems the most straightforward to implement single-sign-on.

Due to the iterative path of development of the TCBL services, this deliverable chooses not to

specify the related interoperability requirements (APIs, data models, etc.) top down, as was

originally stated in the DoA. To fill in this gap, the following strategy is going to be followed:

add an interoperability section to the relevant technical deliverables as they become ready, in

particular D 1.2 and D 5.2 in month 18.

1 A Glossary of Used Terms is provided in the following page.


646133 - TCBL Textile & Clothing Business Labs

4

GLOSSARY OF USED TERMS

Term Definition and source

API Application Programming Interface allows to access a specific

application in a pre-determined way to allow another service or

application to exchange data and/or operations with it.

Authentication Verification of a user’s identity, i.e. through an Identity

Management function, generally accompanied but the

provision of certain profile information, in order to allow access

to one or more on-line services.

bpSquare2 A TCBL Business Service (see definition below) dedicated to

the exploration of the innovative business models depicted in

the Pilot Scenarios (see below) and to the improvement of

learning literacy of T&C industry players on selected software

solutions available on the market.

Context Broker A specific FIWARE Generic Enabler, the “Orion” Context

Broker is a publish-consumer service that organises the

subscriptions of producers and consumers in channels,

combined with a database to store the information

Event logging Automatic capture of system events, normally specific or pre-

defined types of user activity, and storage in log files that can

be accessed for analysis and use by other systems and

services (e.g. analytics, gamification, etc.).

FIWARE or FI-WARE3 A middleware platform, driven by the European Union, for the

development and global deployment of applications for Future

Internet.

Generic Enabler A general-purpose software component (sometimes in the

form of an API) that performs a task that can typically be used

by several applications, e.g. authentication, visualisation, etc.

Production Services Services that are running in their fully operational mode with

their final user base, as compared to services still in a testing

2 Adapted from TCBL DoA, various pp., modified after discussions during WP6 Brussels meeting (22nd –

23rd February 2016).

3 See https://en.wikipedia.org/wiki/FIWARE



5


phase.

TCBL Associates

Programme4

TCBL aims to gradually populate the ecosystem with T&C

actors covering the entire value chain by means of yearly calls

for expression of interest. Three types of Associates will be

looked for:

Business Labs (Design, Making, and Place)

Business Systems (Laboratories and Factories)

Business Service Providers.

TCBL Business Labs5 Physical and/or virtual spaces in which actors involved in

TCBL can draw on existing and emerging business models to

freely experiment with new ways of designing, making,

producing within specific locations in the countries covered by

the TCBL partnership. TCBL includes three types of labs:

Design Labs, Making Labs and Place Labs.

TCBL Business Services

(also known as Process

Support Services)6

Training and performance support facilities linked to innovative

business process models and other third party services

facilitating Business Labs and Business Systems in accessing,

assimilating and adapting the new knowledge created through

the Knowledge Spaces and in valorising it to enable new ways

of working in T&C to be developed and implemented.

TCBL Business Systems

(also known as Pilots)7

Pilot activities within TCBL based on existing and concrete

supply and value chains including social enterprises, primarily

in, but not limited to the T&C manufacturing sector, to

establish methodologies for “innovation transfer” of business

model elements.

TCBL Cloud Cloud environment, provided by iMinds, in which TCBL and

third party ICT enabled services can be installed and providing

generic software enablers to be used by different services.

TCBL Data Policy Application of the TCBL Principles to specific policies for the

management of data, including security, privacy,

confidentiality, value chain information, etc.

TCBL Gamification Tool8 Application of gamification methodologies - the use of game

4 Adapted from TCBL DoA, part B, pp. 13-14.

5 Adapted from TCBL DoA, various pp.

6 Adapted from TCBL DoA, various pp.

7 Adapted from TCBL DoA, Part B, p. 8 and p. 35.



6


thinking and game mechanics in non-game contexts to engage

users - to the TCBL business experimentation framework to

foster the engagement of the eco-system stakeholders.

TCBL Knowledge Spaces9 An online, interactive business model repository that hosts and

links to embedded and emergent materials and manufacturing

knowledge for T&C, as well as market, technology, economic

and social trend observations and policy watching.

Knowledge Spaces capture knowledge related to the practice

of T&C production, such as individual needs and desires, and

other aspects that define market conditions, analysing the

social interactions with that knowledge in order to

suggest/identify trends and options for the Business Labs and

Systems.

TCBL Pilot Scenario10 Innovative business process model to be explored by a

selected number of TCBL Pilots. TCBL Pilots can work

together to generate a Pilot Scenario, and then test it in a non-

public (confidential) section of the bpSquare platform.

Tin Can Tin Can is an API (similar to the Experience API or xAPI) that

captures [actor] [verb] [object] ‘Statements of Experience’ and

publishes them in a Learning Record Store (LRS).

8 Adapted from TCBL DoA, p. 14.

9 TCBL DoA, p. 14 and part B, p. 8.

10 Definition created during discussions in WP6 Brussels meeting (22nd – 23rd February 2016).

7

TABLE OF CONTENTS

EXECUTIVE SUMMARY ............................................................................................................ 3

GLOSSARY OF USED TERMS ................................................................................................. 4

TABLE OF CONTENTS ............................................................................................................. 7

1. INTRODUCTION TO WP6 AND TASK 6.2 ........................................................................ 9

2. ROLE OF THE CLOUD IN TCBL ..................................................................................... 11

2.1 A SECURE AND TRUSTED ENVIRONMENT FOR THE TCBL ECOSYSTEM ............................. 11

TCBL data policy ............................................................................................................... 11

RESPONSIBILITY .................................................................................................................... 12

2.2 A PLATFORM EMPOWERING THE TCBL COMMUNITY ....................................................... 12

TCBL hosting policy .......................................................................................................... 13

RESPONSIBILITY .................................................................................................................... 14

Main Cloud enablers ......................................................................................................... 14

3. THE TCBL CLOUD ENVIRONMENT ............................................................................... 16

3.1 CHOICE OF THE CLOUD PLATFORM ............................................................................... 16

3.2 INFRASTRUCTURE SETUP AND FUNCTIONALITIES ............................................................ 16

iMinds VMware platform .................................................................................................... 16

iMinds Virtual Wall ............................................................................................................. 17

FIWARE node ................................................................................................................... 19

iMinds Networking and Services ....................................................................................... 23

The TCBL Cloud Strategy ................................................................................................. 23

3.3 INSTALLATION REQUIREMENTS OF TCBL COMPONENTS ................................................ 23

vDiscover ........................................................................................................................... 24

bpSquare ........................................................................................................................... 24

TCBL.io ............................................................................................................................. 25

4. KEY TCBL ENABLERS ................................................................................................... 26

4.1 AUTHENTICATION ......................................................................................................... 26

4.2 EVENT LOGGING .......................................................................................................... 27

The Orion Context Broker ................................................................................................. 27

The Learning Locker ......................................................................................................... 29

5. CONCLUSIONS AND FUTURE STEPS .......................................................................... 31

LIST OF TABLES ..................................................................................................................... 32

LIST OF FIGURES ................................................................................................................... 33

DOCUMENT INFORMATION ................................................................................................... 34

Revision History ................................................................................................................ 34



8

Statement of originality ...................................................................................................... 34

Copyright ........................................................................................................................... 34

Disclaimer .......................................................................................................................... 34

Acknowledgements ........................................................................................................... 35

9

1. INTRODUCTION TO WP6 AND TASK 6.2

The description of WP6 “Scaling up and Sustainability” in the DoA reads as follows:

Work package six adopts a systemic and multidisciplinary approach in structuring

and modelling the TCBL ecosystem as a whole. Its overarching aim is to secure

the sustainability of project results in the long-term and to transform such results

into pivotal pillars in the quest for positive and lasting impact on EU businesses and

society. Taking a longer-term perspective, the activities will be oriented at creating

the conditions for a successful exploitation of both knowledge and technological

assets after the grant period. The activities conducted in this work package focus

on aspects that are complementary to the business planning activities that will be

carried out on homogeneous sub-systems in work package seven.

In this context, one of the main infrastructural elements considered key to the value

proposition of the TCBL ecosystem is an open Cloud environment that supports the integration

of different services. This is the purpose of Task 6.2, described in the DoA as follows:

This activity provides a common Cloud infrastructure for all of the ICT services

supporting the TCBL ecosystem, based on the FI-PPP’s FI-WARE Cloud, which

allows to host and experiment with Generic Enabler services. In an initial phase,

the task will collect the TCBL Cloud infrastructure requirements as to be able to

provide the best possible experimentation infrastructure. Based on the requirement

analysis and the state of the art of FI-WARE components, a (part of) the iMinds

iLab.t server infrastructure will be configured to support TCBL in the best fitting

way, which is expected to be either (i) maintaining and operating a native FI-WARE

node, to be accessed via the official FI-Lab portal, or (ii) realizing and operating a

dedicated common Cloud infrastructure, based on and compatible with FI-WARE

components, ran in isolation from the FI-Lab. Once the infrastructure is set up, this

task will provide the needed monitoring and technical support to keep the provided

infrastructure operational.

This deliverable D6.2 describes the setup of this Cloud infrastructure, including the following

key steps:

1. Choice of the actual platform and services on which to deploy the Cloud environment.

2. Configuration of the Cloud and installation of the first software components.

3. Identification of the key enablers to deploy for the TCBL Cloud environment.

On a less technical level, this activity has also in parallel consisted in the definition of how the

Cloud concept relates to the TCBL approach and the defining elements for Cloud services in

the eyes of its users. This includes the definition of a data policy for TCBL and some of the

main principles for hosting, as described in the following section.

The original view of the development path for Task 6.2 as set forth in the TCBL DoA foresaw

an evaluation based on the requirement analysis and the state of the art of FI-WARE

components. And after evaluation, a (part of) the iMinds iLab.t server infrastructure would be

configured to support TCBL in the best fitting way, which was expected to be either (i)

maintaining and operating a native FI-WARE node, to be accessed via the official FI-Lab

portal, or (ii) realizing and operating a dedicated common cloud infrastructure, based on and

compatible with FI-WARE components, ran in isolation from the FI-Lab.



10

As early as the project kickoff meeting, it became clear that FIWARE as such did not offer the

ideal Cloud solution for TCBL, when compared to other specific platform environments that

iMinds could make available.

Besides that, it soon became clear that the concrete configurations and interoperability

solutions (APIs, data models, etc.) related to each prospective TCBL service could not be

defined upfront (because a simple adoption of Generic Enablers does not solve this) and

turned into technical specifications of universal nature, but were to be seamlessly and

collaboratively identified for each service installation ‘ad hoc’, with and by the TCBL Partners

and Associates interested in forming Closed User Groups for that installation. The result is that

the prospects for interoperability now reside in the flexibility and adaptiveness of the TCBL

Cloud and its software enablers, rather than the ‘a priori’ definition of data models and

specification of APIs11.

Due to the immature stage of development of the TCBL services, this deliverable cannot

specify the interoperability requirements (APIs, data models, etc.) related to them, as was

originally stated in the DoA. To fill in this gap, the following strategy is going to be followed:

Add an interoperability section to each technical deliverable due in the project (which include

D6.1, D5.1 and D1.1)

11 A summary of the installation requirements of the key TCBL components is provided in section 3.3

below.

11

2. ROLE OF THE CLOUD IN TCBL

2.1 A SECURE AND TRUSTED ENVIRONMENT FOR THE TCBL

ECOSYSTEM

The Cloud is generally considered as a technical ICT infrastructure: an efficient way to provide

computing services by installing applications on remote servers and running them through

apps and browsers on multiple devices. In addition, the Cloud allows to store and share

documents and information, both at the workplace and on the move. The FI-WARE paradigm

further introduces the concept of the Cloud as a Europe-wide service infrastructure with a set

of Generic Enablers, allowing for the creation of local or application-specific instances of the

Cloud with several basic software components already installed and active.

In the minds of many businesses and users – of the sort that will be using TCBL services – the

Cloud also raises a series of issues together with its convenience of use. The advantage of

ubiquitous computing is offset by a lack of clarity of exactly where information and software is

being stored and who is managing it. Wikileaks raises additional questions of the jurisdiction

over Cloud services and the possibility for governments to access data which is otherwise

considered private. This growing suspicion is paralleled by the commercial use of personal

information, with the accuracy of digital marketing giving the impression of monitoring every

step we take. An increasing number of services allow to log in using Facebook, Twitter,

Google, or Linkedin, but despite the warnings and features users are left with the sensation of

a lack of control over what information is being passed from one service to the next.

TCBL addresses these issues as the necessary first step before looking at any of the technical

advantages offered. The TCBL Cloud must first and foremost provide a safe, secure, and

trusted environment within which to carry out on-line interaction in the TCBL ecosystem. This

cannot be achieved through the necessary technical and operational measures alone, but

must also occur through visible evidence coupled with effective communication, associating

the TCBL Cloud with the very identity and principles of the TCBL ecosystem as a whole. This

approach guides the management policies outlined in the following sections.

TCBL DATA POLICY

TCBL is a multi-platform environment that, among other objectives, aims to attain a broad

impact through diffused social media platforms such as Facebook and Twitter on the one

hand, and provide services based on analytics of user interaction (gamification, trending, etc.)

on the other. In addition, the TCBL Cloud aspires to host services that will be managing critical

and confidential information of participating businesses. Each of these issues pulls in different

directions as concerns privacy and data policies, leading to the need for a common data policy

for TCBL as a whole.

This issue is linked to discussions elsewhere in the project (for instance to define evaluation

criteria for Labs and Pilots) related to the need for a common set of principles that define the

TCBL community. The principles identified at the project level, i.e. the general principles on

which the identity of the TCBL brand are based, are as follows: Curiosity (exploration and

innovation), Viability (business soundness, added value to the community), Durability

(environmental sustainability and reduction of waste), Multiplicity (value of diversity and

multiple approaches), Openness (trust, sharing, participation, transparency), Respect (privacy

and authorship, dignity of the people and places), and Responsibility (reliability, accountability,



12

and professionality). From there, the key elements of a TCBL data policy have been identified,

as follows.

Principle Data Policy

curiosity Data is a common scientific good, and should have clear licensing to facilitate access from external sources.

viability Data services should be part of viable business models and maintenance policies clearly stated.

durability Data services should rely on energy-efficient storage and transmission infrastructures.

multiplicity Interoperability should facilitate the use of different formats and standards while promoting convergence.

openness Data should be open by default and data services available to the community.

respect Data services should respect the confidentiality and privacy interests of those who provide or generate data.

responsibility Data services should embed accountability to guarantee privacy, security and service quality.

Table 1. The TCBL Data Policy

These principles are applied to the management of the TCBL Cloud as well as all TCBL

services, in particular those dealing with personal data and/or supply chain information.

2.2 A PLATFORM EMPOWERING THE TCBL COMMUNITY

Once an appropriate data policy is established for the TCBL Cloud, we can better explore the

Cloud paradigm from a functional point of view. TCBL does not intend to propose a tightly

integrated “do-it-all” platform that aspires to satisfy all of their needs. It rather favours the

Cloud as an open platform that can progressively integrate a range of both ‘internal’ (to the

project) and ‘external’ platforms and services through “light”, API-based interoperability (rather

than deep integration of functions and unique data models). This has several advantages:

Different user types can pick and choose the services that fit them best, much like a

user selects apps on a smartphone and selects those to appear on the home screen.

The TCBL platform can bring in new services when the need arises; for instance, it is

possible that in the future we will need a logistics planning service.

This approach avoids lock-in to a particular solution or approach to solving a need,

since we can easily have competing services in the ecosystem and focus on those

that work best.

The “glue” holding together the different applications and providing a common environment is

basically the Cloud itself, for those who wish to install their services on it, and common

authentication and profile-passing APIs for those wishing to remain outside. Functional

interoperability can be determined on a case-by-case basis, using Cloud data stores if and

when necessary.



13

Since those having access to the TCBL Cloud consist of a Closed User Group (CUG) (namely

the set of project partners plus the Associate Labs and Pilots), it is also possible to experiment

with a distributed usage of services that were originally conceived for large corporations. In

this case, different participating Labs and Businesses can be considered as different

departments of a company, or the partnerships participating in specific value chain scenarios

can be considered as different companies within a holding group. Whatever the parallel, in this

sense the Cloud is the company, in the sense that it provides a centralised but open point of

reference for managing data flows, access permissions, etc. across a broad range of

participating enterprises.

This allows for small-scale artisans and SMEs to gain access to software environments that

are normally precluded to them, and thus provides a new level of empowerment to both the

participating enterprises and the composite value chains they form within TCBL. Conversely,

and perhaps more interesting from a business development standpoint, this approach has the

potential to significantly extend the market for the participating ICT service providers. There is

currently a gap between mass distribution of generic productivity software (e.g. Microsoft

Office), often ‘personalised’ by local software houses, and the sophisticated platforms that

target large corporations (e.g. ERP and CRM). The related licensing policies reflect that

market structure.

In addition, relatively closed and specific markets, such as the textile and fashion industries,

tend to be dominated by a few software providers who attempt to cover the entire business

cycle as a means of locking in customers, with software suites piecing together different

functionalities and business models that have failed to open up due to a low degree of

competition. Cloud based SaaS approaches have begun to appear, offering broader licensing

options, but this is still an immature market dominated by the logic of vendor lock-in. Needless

to say, these comprehensive platforms also tend to support and promote the fast fashion

business model that most enterprises attracted to TCBL are trying to break away from.

TCBL thus offers an interesting opportunity for software providers to experiment new markets

and solutions. The set of Associate Business Labs and Pilots constitutes a closed user group

(in the sense of an identifiable set of users) that covers entire supply chains in emerging

market spaces, and can thus be used to capture emergent requirements for the services that

will be required to support sustainable manufacturing in the future. TCBL MoUs with providers

and users can include specific Non Disclosure Agreements (NDA) on the side of TCBL

Associates as well as delimited time frames for experimentation. It is then in the interests of

the TCBL community to co-define, together with the ICT service provider, the best licensing

strategy that allows for uptake in new markets while guaranteeing long-term sustainability and

support for the vendor.

TCBL HOSTING POLICY

All services in the Cloud run on the iMinds infrastructure, located in Gent, Belgium in two

datacenters about 5 km from each other (for redundancy). The Cloud is administered fully

(bare metal servers, network, firewalls, datacentre) by iMinds personnel. The TCBL project

website will allow ecosystem participants to view these facilities (without being too specific, for

obvious security reasons) and see the people who work there, including staff photos and

quotes from interviews regarding the kinds of measures they take to ensure security and

reliability. In addition, iMinds policies with respect to EU and Belgian law for privacy and data

security will also be published, within a possible of maximum transparency.



14

iMinds thus takes a leading role, on behalf of TCBL, in compliance with the TCBL principles

and data policy, enacting the measure highlighted in the table below:

Principle iMinds measures for compliance

curiosity The services running on the iMinds Cloud are not publicly announced. Activity log is individually licensed by the end user and, unless otherwise specified, openly accessible.

viability The iMinds Cloud is a production environment for running services, already operational as a sustainable service.

durability iMinds takes care to ensure state-of-the-art measures for energy efficiency and minimum environmental impact of its hosting infrastructure.

multiplicity The core enablers of authentication and activity log, together with the availability of shared data stores, aim to attain frugal yet effective interoperability across an open and unknown range of services. In addition, multiple services can be run, even multiple instantiations of the same service, e.g. for testing.

openness All TCBL Partners as well as TCBL Associate Service Providers can run services on the iMinds Cloud.

respect iMinds runs the services of TCBL with the same guarantees of security as all its other services. Protection of individual data will be further explored during the project, according to the “entitlement” approach.

responsibility iMinds personnel is responsible for the hardware, network and operating system. Part of the Cloud is fully redundant.

Table 2. iMinds Policy Compliance

Throughout the TCBL project, iMinds will also ensure, together with the TCBL technical

partners, the compliance of all platforms and services installed on the TCBL Cloud with the

TCBL data policy. The long-term management of these issues will be one of the elements for

development in Task 6.5 “Business ecosystem governance”.

MAIN CLOUD ENABLERS

In line with the above logic, two key enablers have been identified that contribute to the

branding of the TCBL Cloud as a secure and trusted environment as well as enabling the kind

of open, multi-platform environment described above. They are:

Authentication

The authentication services allow users to Log in with TCBL on platforms and services

that participate in the TCBL Cloud environment, whether or not they are actually

installed on the Cloud itself, in a similar way that today one can log in to many

services through the user’s Facebook or Google account. This has the obvious benefit

of simplifying the use of multiple platforms, but also provides a common brand: ICT

service providers using our Log in with TCBL feature will also be checked for

compliance with the TCBL data policy. In addition, the TCBL authentication feature will

include the ability for users to identify what profile information can be passed on to



15

another application both by default and on a case by case basis. Log in with TCBL is

therefore an important identity feature for the Cloud, providing the user with a

reassuring experience and reinforcing the benefits of belonging to a value-based

community.

Event logging

Services in TCBL will often use or require event logging for purposes of gamification,

data harvesting for analytics, user profiling, etc. TCBL will provide this facility as a

Cloud enabled one, making sure the end user has the maximum control over his or

her data. The concept of Entitlement, as espoused by Usman Haque12, together with a

form of data licensing, as explored in the CIP ICT PSP Citadel… on the Move

project13, will be explored. In addition, we will also be exploring issues related to group

data ownership, as will likely be the case for supply chain data in TCBL value chains.

With the control of event logging in the hands of end users, it will then be up to

applications and services to demonstrate the benefits of opening up users’ own data

and reassure them of the appropriate use that will be made of it.

Issues regarding the technical implementation of these core enablers are discussed in

Chapter 4 of this document.

12 https://hbr.org/2015/02/managing-privacy-in-the-internet-of-things

13http://ilmiolibro.kataweb.it/libro/informatica-e-internet/119315/the-citadel-open-data-commons/

16

3. THE TCBL CLOUD ENVIRONMENT

3.1 CHOICE OF THE CLOUD PLATFORM

At iMinds there are different platforms for hosting and testing services, each with its own

features and specifics. In the following section these services are described in more detail,

together with the criteria for selection of the most appropriate components for the TCBL Cloud.

VMware platform, fully redundant (compute, storage, network), redundant cooling in

the datacentre, UPS and generator fed and possible to run all operating systems

(including Windows Server). Administrator help is needed for initial setup of machines.

IPv4 and IPv6 supported.

The Virtual Wall platform, which is more oriented towards temporary (Linux) test

setups but on which scaling can be tested and which is fully automated. IPv4 and IPv6

supported.

A FIWARE node which is running on the Virtual Platform and which is compatible with

FIWARE; as such it supports only Linux (limited range of distributions) virtual

machines and only IPv4. Authentication is not administered by iMinds but by FIWARE

central services.

3.2 INFRASTRUCTURE SETUP AND FUNCTIONALITIES

IMINDS VMWARE PLATFORM

The VMware setup is the most versatile and most redundant setup of the iMinds platforms. All

computing, networking and storage is redundant and there is a passive offline backup in a 2nd

datacentre 5km away.

In total the VMware setup has 72 CPU cores, 900GB RAM and 80TB storage. RAM usage is

guaranteed to be not oversubscribed (as memory oversubscription significantly limits

performance because of swapping to disk).

The VMware setup makes it possible to run all operating systems (e.g. including Windows

Server). iMinds system administrators need to do the initial installation of new machines.



17

Figure 1. The iMinds VMware Platform

IMINDS VIRTUAL WALL

The Virtual Wall consists out of about 400 physical servers that can be used in an automated

and remote way to test out or benchmark services. There is also a variation of hardware

available (see http://doc.ilabt.iminds.be/ilabt-documentation/virtualwallfacility.html in such a

way that e.g. vertical or horizontal scaling can be investigated). This facility is not fully

redundant and is also not UPS powered. The most important features are that there is access

to physical servers (versus virtual), that a multitude of servers is available and that no system

administrator is needed to configure the servers.

Figure 2. The iMinds Virtual Wall

The hardware available is summed up in the following table:

http://doc.ilabt.iminds.be/ilabt-documentation/virtualwallfacility.html



18

Type Number of nodes Description

PC gen 1 100 2x Dual core AMD opteron 2212 (2GHz) CPU, 8GB RAM, 4x 80GB harddisk, 4-6 gigabit nics per node

PC gen 2 100 2x Quad core Intel E5520 (2.2GHz) CPU, 12GB RAM, 1x 160GB harddisk, 2-4 gigabit nics per node

PC grid 22 2x Dual Core AMD opteron 270 (2GHz) CPU, 4GB RAM, 1x 80GB harddisk , 1 gigabit nic per node

PC gen 3 110 2x Hexacore Intel E5645 (2.4GHz) CPU, 24GB RAM, 1x 250GB harddisk, 1-5 gigabit nics per node

PC gen 4 28 2x 8core Intel E5-2650v2 (2.6GHz) CPU, 48GB RAM, 1x 250GB harddisk, gigabit and 10gigabit connections

GPU 10 1x 6core Intel E5645 (2.4GHz), 12GB RAM, 4x 1TB disk in RAID5, 4x Nvidia Geforce GTX 580 (1536MB).

PC gen 5 25 1x 4 core E3-1220v3 (3.1GHz), 16GB RAM, 1x 250GB harddisk, 2-10 gigabit connections

Table 3. iMinds Virtual Wall Hardware Configuration.

A graphical user interface is present to configure the Virtual Wall (and similar testbeds around

the world, e.g. in Europe, the US, South Korea, Brazil, and Japan), as shown below:

Figure 3. Virtual Wall Configuration Interface.

The map below shows similar and compatible testbeds around the world:



19

Figure 4. Virtual Wall Compatible Testbeds in the World.

FIWARE NODE

As can be seen in the picture below, FIWARE (https://www.fiware.org) is a complex EU-

funded programme consisting of different parts:

FIWARE lab is a distributed infrastructure which can run Linux based virtual

machines. It provides a Cloud platform for developing and testing applications (“a

sandbox for non-commercial use”).

Generic enablers are essentially software components and APIs that can be used in

applications. They provide an open, public, royalty-free set of open specifications and

reusable software components allow fast and easy prototyping and development of

future internet applications. (see http://catalogue.fiware.org/ )

A specific Accelerator programme funds SME and start-up companies to support

innovative application development using FIWARE and thus create economic impact.

FIWARE LAB(federated openstack cloud)

GENERICENABLERS

ACCELERATORPROGRAMME

https://www.fiware.org/

http://catalogue.fiware.org/



20

Figure 5. Elements of the FIWARE Programme.

FIWARE LAB

The most relevant elements for TCBL, and in fact the elements that are mentioned in the DoA,

are the FIWARE Lab (to be used as the Cloud environment) and the generic enablers (to

promote interoperability between TCBL services and platforms). At the TCBL Kickoff meeting

in July 2016, however, it immediately appeared that FIWARE Lab misses some key features

that are needed for TCBL services, the most important being support for Windows Server

images. An additional drawback, this time a critical one for the reliability of TCBL services, is

the lack of access for node owners such as iMinds to some centralised services such as

authentication, also important for instance for debugging issues. The figure below illustrates

these limitations more clearly.

Figure 6. Administration Rights in the FIWARE Lab Platform.

GENERIC ENABLERS

The second element from FIWARE mentioned in the TCBL DoA are the Generic Enablers,

which are a set of software components and APIs that are to some degree independent of the

FIWARE Platform itself but contribute to offering a flexible service for the development of

other, specific applications. Indeed, they are generally reusable Open Source modules that

have been validated for compatibility with FIWARE and each other. This means that TCBL can

make use of the FIWARE Generic Enables independently of whether or not it uses the

FIWARE Lab infrastructure as its Cloud platform.

Central (portal, keystone authentication, image distribution,

platform choice, platform upgrades, etc)

Infrastructure owner

(iMinds iLab.t)



Accelerator projects marketing and funding

Software(generic

enablers)

SoftwareInstallers

(blueprints)



21

The Generic Enablers in FIWARE14 are grouped according to a general classification as

shown in the figure on the following page.

Figure 7. Classes of FIWARE Generic Enablers.

As one can see, the generic enablers are very versatile and cover a broad spectrum of

functionality. On the other hand, a closer inspection of the Generic Enablers available on the

FIWARE website reveals an uneven state of development, with some important elements at

an immature stage of development or with a limited user base. This would make it difficult to

follow the implementation path foreseen in the DoA, i.e. identify the appropriate enablers,

install them in the TCBL instance of the Cloud, and then distribute the related specifications

and APIs to interested partners and parties.

The strategy adopted is therefore a more interactive co-design approach towards defining the

most appropriate set of TCBL Generic Enablers. This involves a process whereby a TCBL or

14 http://www.fiware.org/tour-guide

http://www.fiware.org/tour-guide



22

Associate Service software developers first identify Generic Enablers that could be useful for

the services they intend to provide to TCBL. From there, the iMinds team can then identify the

best approach to have that specific functionality deployed on the Cloud.

This approach is best illustrated with a concrete example. Let us suppose that there is a need

for big data analysis (and we are already aware that there is this need in the context of Task

1.4 for instance). FIWARE has a Generic Enabler called Cosmos15 that appears to carry out

the required functionality. On the other hand, Cosmos only supports batch processing through

the standard Hadoop16 framework. The iMinds environment, through the Tengu platform17

which instead supports a multitude of frameworks including Hadoop but also Spark, Storm,

MongoDB, Cassandra and others.

Figure 8. The iMinds Tenqu Platform.

In addition, Tengu also supports batch and streaming big data analysis. The choice of the path

to follow thus depends on the exact needs of the specific service environment.

15 http://catalogue.fiware.org/enablers/bigdata-analysis-cosmos

16 http://hadoop.apache.org/

17 http://tengu.intec.ugent.be

http://catalogue.fiware.org/enablers/bigdata-analysis-cosmos

http://hadoop.apache.org/

http://tengu.intec.ugent.be/



23

IMINDS NETWORKING AND SERVICES

For all of the above-mentioned platforms, the iMinds networking specifications and services

are the same:

Redundant connection to Belnet, the Belgian NREN which is connected to Geant.

Available bandwidth of 10Gb/s from the iMinds Cloud towards the Internet. From the

Internet to the iMinds Cloud available bandwith is 10Gb/s from research networks and

700Mb/s from the commercial Internet.

IPv4 and IPv6 public IP addresses (Note that IPv6 is not available through FIWARE)

Possibility to sign SSL certificates for free when the domain name ends in

ilabt.iminds.be (thus a paid for option for most TCBL services).

All the above mentioned infrastructure is maintained by iMinds personnel and is located in

Ghent (BE), hosted in buildings of the Ghent University.

THE TCBL CLOUD STRATEGY

On the basis of the above options and considerations, the following strategy for the TCBL

Cloud environment has been defined:

TCBL will, for the foreseeable future, aim to maintain compatibility with the FIWARE

Lab Cloud environment, but not use its services directly due to limitations of platform

support and administration access.

TCBL production services (i.e. operational to the public) run on the iMinds VMware

cluster. The main reason for this is the level of redundancy available in order to

guarantee service reliability.

The iMinds Virtual Wall is used for testing software, due to its flexibility and ease of

configuration.

While TCBL continues to support the concept and available suite of FIWARE Generic

Enablers, it does so with a critical eye. Selection and installation of Generic Enablers

(including the CKAN Open Data portal and the FIWARE Context Broder, specifically

mentioned in the DoA) will take place on a case-by-case basis, on-demand as required by

TCBL and third party service providers, with the option to adopt alternative approaches where

appropriate.

The means that the specification of interoperability requirements related to the ICT

components that make up the Knowledge Spaces and the Business Services, as well as

potential future services, is carried out as needs arise in a co-design approach, rather than in

a top-down fashion. The on-going results of this interaction between the iMinds Cloud

responsibles and the other technical TCBL partners will be reporting in the future deliverables

of the specific activities, notably for WP 1 “Knowledge Spaces, WP 5 “Business Process

Support” and Task 7.4 “Service SME Engagement”.

3.3 INSTALLATION REQUIREMENTS OF TCBL COMPONENTS

Activities in Task 6.2 have included an exploration of the specific options and requirements for

installation of the key service components on the TCBL Cloud environment. The main

components addressed to date have included:

vDiscover (DITF) is the core component of the TCBL Knowledge Spaces



24

bpSquare (Skillaware) is the core platform for the TCBL Business Services

TCBL.io (Waag) is a platform (not foreseen in the DoA) supporting interaction

between the Business Labs

The following summarises the requirements identified for each component and the state of

advancement of installation.

VDISCOVER

vDiscover requires an Apache web server + PHP + MySQL or MariaDB as a basis. This can

be hosted in any virtual machine, and as a consequence on any of the Cloud environments

available to TCBL. The vDiscover production site will be hosted on VMware, while the test

sites for the components currently under development in WP1 are currently being installed on

the iMinds Virtual Wall.

BPSQUARE

bpSquare is a more complex service environment, with the following requirements.

Hardware Recommendations Software Requirements

Front-End Server CPU Speed: 2.0 GHz 64-bit

processor.

# of CPU: 8 core.

RAM: 16 GB.

HDD: 80 GB (depending on the

space required for the contents

stored into the internal Storage).

Windows Server 2012 R2.

IIS 8.5.

.Net Framework 4.6.

Windows Service CPU Speed: 2.0 GHz 64-bit

processor.

# of CPU: 8 core.

RAM: 32 GB.

HDD: 60 GB.


.Net Framework 4.6.

Database Server As indicated in Microsoft website

for the installation of SQL Server

2012.


Microsoft SQL Server 2012

Standard or Enterprise (Full Text

not required) including Data Base

Services, Integration Services,

Analysis Services.

Microsoft SQL Server

Management Studio.

Table 4. bpSquare Cloud Requirements

The main issue encountered for installation of bpSquare on the TCBL Cloud is the licensing

costs for Windows Server and, above all, the SQL server.

Currenly, the Front End Server and Windows Service are being installed on VMware (required

to host Windows), while other more feasible options are being explored for the database



25

server, including a possible porting to a more economical platform (using Microsoft SQL

express server).

TCBL.IO

The TCBL.io platform is an adaptation of the fablabs.io platform, a Ruby on Rails web

application developed by Fablab Barcelona to support the global network of Fab Labs. The

work is being carried out by TCBL partner Waag as an instantiation of the Business Lab

Framework of WP3.

Being a native Open Source platform, TCBL.io can be hosted on Ubuntu Linux 14.04 on all

Cloud platforms. As the on-going work under way at Waag becomes ready, it will be hosted

according to the general TCBL Cloud strategy: production site on VMware and test sites on

the Virtual Wall.

26

4. KEY TCBL ENABLERS

The two core General Enablers described in Chapter 2 were identified at the project Technical

Task Force meeting in Brussels on 22-23 February, 2016. Since then, in coherence with the

strategy for the Generic Enablers described previously, various options have been identified

for implementation.

4.1 AUTHENTICATION

The goal is to have a central repository of user profiles, with the necessary hooks for other

services to use these profiles. OpenID and OAuth are the two main candidates for this.

FIWARE Keyrock18 is Generic Enabler providing these functionalities as an Identity

Management tool, described as follows:

“Identity Management covers a number of aspects involving users' access to

networks, services and applications, including secure and private authentication

from users to devices, networks and services, authorization & trust management,

user profile management, privacy-preserving disposition of personal data, Single

Sign-On (SSO) to service domains and Identity Federation towards applications.

The Identity Manager is the central component that provides a bridge between

IdM systems at connectivity-level and application-level. Furthermore, Identity

Management is used for authorising foreign services to access personal data

stored in a secure environment. Hereby usually the owner of the data must give

consent to access the data; the consent-giving procedure also implies certain

user authentication.”

Keyrock is also used for FIWARE authentication and services. Keyrock can in theory be

installed stand-alone19, but the requirements are so wide (depends on keystone and horizon

which is typically used by openstack) that installation problems are likely to arise.

Other Oauth2 provider implementations are available,20 that can blend in with an existing

identity manager/portal and provide only the needed Oauth2 services. Different options can be

appropriate for specific requirements (e.g. where and how will the accounts and profiles be

stored, which profile attributes are needed), and depending on the language of the IdM/portal

implementation (e.g. internal LDAP, database or others), the specific implementation can be

selected and installed.

18 http://catalogue.fiware.org/enablers/identity-management-keyrock

19 http://fiware-idm.readthedocs.io/en/latest/setup.html#production-guide

20 http://oauth.net/2/

http://catalogue.fiware.org/enablers/identity-management-keyrock

http://fiware-idm.readthedocs.io/en/latest/setup.html#production-guide

http://oauth.net/2/



27

4.2 EVENT LOGGING

The TCBL meeting in Brussels also expressed the need for a central service to log events of

users in the different TCBL services. An important requirement was also that individual users

are able to directly decide what kind of information is to be logged and which services can

access that information, which in turn means that the event log would need to filter access to

stored logs on the basis of user permissions.

THE ORION CONTEXT BROKER

One of the candidates for event logging is the FIWARE “Orion” Context Broker as originally

mentioned in the TCBL DoA. The Orion context broker works as shown in the figure below

which is the scheme of a typical publish-consumer service. On the left, you see context

producers and on the right context consumers. In the middle, the service organises the

subscriptions of producers and consumers in channels, combined with a database to store the

information.

Figure 9. The Orion Context Broker.

Orion implements the OMA (Open Mobile Alliance) NGSI (Next Generation Service Interfaces) 9 and 10

interfaces. The NGSI architecture is shown below to show the context of NGSI 9 and 10:



28

Figure 10. The NGSI Service Architecture.

The functions of NGSI 9 (Context Entity Discovery Interface) and 10 (Context Information

Interface) are as follows:

Interface Functions Operations

NGSI9 Register

Search and

Subscribe for context sources

registerContext

discoverContextAvailability

subscribeContextAvailability

updateContextAvailabilitySubscription

unsubscribeContextAvailability

NGSI10 Query

Update and

Subscribe to context elements

updateContext

queryContext

subscribeContext

updateContextSubscription

unsubscribeContextSubscription

Table . NGSI Context Interfaces.

Orion can be installed in several ways, all compatible with the iMinds Cloud models described

above.

Install the packages with yum on Centos 6.x21. The MongoDB database can be

installed separately if needed.

Orion can also be installed using Docker containers.22 This is more oriented towards

temporary testing.

21 http://fiware-orion.readthedocs.io/en/develop/admin/install/index.html#installing-orion

22 http://fiware-orion.readthedocs.io/en/develop/user/docker/index.html

http://fiware-orion.readthedocs.io/en/develop/admin/install/index.html#installing-orion

http://fiware-orion.readthedocs.io/en/develop/user/docker/index.html



29

Orion appears to be a fairly mature enabler from FIWARE.23 It is not specifically targeted

towards user’s event tracking on multiple services, but it can be used in that way by

augmenting the services to publish data towards Orion.

THE LEARNING LOCKER

Another option for event logging, suggested in the Brussels workshop, is the

LearningLocker24, which proposes to ‘Store, Sort and Share Learning Data with our Open

Source Learning Record Store’. For this, the Experience API (xAPI)25, very similar to the Tin

Can API26 is used. The Learning Locker is specifically targeted to track:

Mobile Learning

Serious Games

Simulations

Informal Learning

Real World Performance

So-called ‘Statements of Experience’ are published in a Learning Record Store (LRS), e.g.

implemented in a MongoDB database. The web service allows clients to read and write

experiential data in the form of “statement” objects.

Simple Tin Can statements take the general form of “[actor] [verb] [object]”. These labels

coincide with the field names on a statement object. So, in conveying the information that

“Sally experienced ‘Solo Hang Gliding’”, we can quickly spot “Sally” as the actor,

“experienced” as the verb, and “Solo Hang Gliding” as the activity. Ignoring the structure of the

specific parts, the statement object itself would take this structure in JSON format:

{

"actor": "Sally",

"verb": "experienced",

"object": "Solo Hang Gliding"

}

Tin Can also provides facilities for more complex statement forms, a built in query API to help

filter statement streams, and a state API that allows for a sort of “scratch space” for consuming

applications. All communication may be done securely via SSL or OAuth.

On first sight, both Orion and xAPI can be useful in the TCBL context (‘log events of users in

the different TCBL services’) while xAPI fits probably better the limited use case.

Implementations of Tin Can are more commercial - several vendors offering products27

23 http://fiware-orion.readthedocs.io/en/develop/index.html

24 http://learninglocker.net

25 https://learninglocker.net/xapi/

26 https://tincanapi.com/

27 https://learninglocker.net/customers/

http://fiware-orion.readthedocs.io/en/develop/index.html

http://learninglocker.net/

https://learninglocker.net/xapi/

https://tincanapi.com/

https://learninglocker.net/customers/



30

including Learning Locker. Tin Can has both an Open Source and an enterprise version,28 so it

needs to be seen if the Open Source version has enough features to do the job.

This will require a concerted effort between WPs 1 and 5, which both intend to make use of

event logging. In the coming months, a more detailed listing of current and future requirements

for this service will allow to evaluate the most appropriate option between the Open Source

Tin Can / xAPI, the Learning Locker implementation, or the Orion publish-subscribe service.

.

28 https://learninglocker.net/get-started/

https://learninglocker.net/get-started/

31

5. CONCLUSIONS AND FUTURE STEPS

Deliverable 6.2 completes the round of M9 reports of ongoing technical work within the TCBL

WP6, with the global aim of delivering the necessary infrastructure for enabling seamless and

fruitful interactions within the T&C actors belonging to our ecosystem.

In this context, the short-term goal for Task 6.2 (realizing and operating a dedicated common

cloud infrastructure) can be said to have been achieved.

However, as a completion of the global aim of WP6, we will need to closely follow the planned

development phases of WPs 1 and 5, with the key milestone at project month 18 (D 1.2 and D

5.2.1). Here, the final configuration of the authentication and event logging services will need

to be fully operational together with the service environments they are to support. From there,

Task 6.2 will continue to accompany the development and instantiation of TCBL services,

adapting to the requirements of enabling services on-demand as defined in the strategy set

forth in this document.

32

LIST OF TABLES

Table 1. The TCBL Data Policy................................................................................................. 12 Table 2. iMinds Policy Compliance ........................................................................................... 14 Table 3. iMinds Virtual Wall Hardware Configuration. .............................................................. 18 Table 4. bpSquare Cloud Requirements ................................................................................... 24

33

LIST OF FIGURES

Figure 1. The iMinds VMware Platform ..................................................................................... 17 Figure 2. The iMinds Virtual Wall .............................................................................................. 17 Figure 3. Virtual Wall Configuration Interface. .......................................................................... 18 Figure 4. Virtual Wall Compatible Testbeds in the World. ........................................................ 19 Figure 5. Elements of the FIWARE Programme. ...................................................................... 20 Figure 6. Administration Rights in the FIWARE Lab Platform. ................................................. 20 Figure 7. Classes of FIWARE Generic Enablers. ..................................................................... 21 Figure 8. The iMinds Tenqu Platform. ....................................................................................... 22 Figure 9. The Orion Context Broker. ......................................................................................... 27 Figure 10. The NGSI Service Architecture. ............................................................................... 28

34

DOCUMENT INFORMATION

REVISION HISTORY

REVISION DATE AUTHOR ORGANISATION DESCRIPTION

v1 04.03.2016 Brecht Vermeulen iMinds Table of Contents (ToC)

v2 19.03.2016 Jesse Marsh City of Prato Chapter 2, minor edits

v3 20.05.2016 Brecht Vermeulen iMinds Full draft

v4

v5

29.05.2016

30.05.2016

Jesse Marsh

Francesco

Molinari

Taco Van Dijk

Brecht Vermeulen

City of Prato

CCA

WAAG

iMinds

Incorporation of Paolo

Guarnieri review

comments, integration of

contents, layout and

graphics, glossary

Final version

STATEMENT OF ORIGINALITY

This deliverable contains original unpublished work except where clearly indicated otherwise.

Acknowledgement of previously published material and of the work of others has been made

through appropriate citation, quotation or both.

COPYRIGHT

This work is licensed by the TCBL Consortium under a Creative Commons

Attribution-ShareAlike 4.0 International License, 2015. For details, see

http://creativecommons.org/licenses/by-sa/4.0/

The TCBL Consortium, consisting of: Municipality of Prato (PRATO) Italy; German Institutes

for Textile and Fiber Research - Center for Management Research (DITF) Germany; Istituto

Superiore Mario Boella (ISMB) Italy; Skillaware (SKILL) Italy; The Open University (OU) UK;

iMinds (iMINDS) Belgium; Tavistock Institute (TAVI) UK; Materials Industrial Research &

Technology Center S.A. (MIRTEC) Greece; Waag Society (WAAG) Netherlands; Huddersfield

& District Textile Training Company Ltd (TCOE) UK; eZavod (eZAVOD) Slovenia; Consorzio

Arca (ARCA) Italy; Unioncamere del Veneto (UCV) Italy; Hellenic Clothing Industry

Association (HCIA) Greece; Sanjotec - Centro Empresarial e Tecnológico (SANJO) Portugal;

Clear Communication Associates Ltd (CCA) UK.

DISCLAIMER

All information included in this document is subject to change without notice. The Members of

the TCBL Consortium make no warranty of any kind with regard to this document, including,

but not limited to, the implied warranties of merchantability and fitness for a particular purpose.

The Members of the TCBL Consortium shall not be held liable for errors contained herein or

direct, indirect, special, incidental or consequential damages in connection with the furnishing,

performance, or use of this material.



35

ACKNOWLEDGEMENTS

The TCBL project has received funding from the European Union's Horizon 2020 Programme

for research, technology development, and innovation under Grant Agreement n. 646133.

Documents

CLOUD INFRASTRUCTURE - Ningapi.ning.com/files/ys89Oj1AWQ8jnPo7W7qPycGyrXzt0... · includes an Introduction (section 1) and some Conclusions ... Section 2 details the vision of TCBL