fi -ware webinars Nov-Dec 2012 Henk HEIJNEN (henk.heijnen@technicolor.com)

1. Creation of Cloud Proxies – a primer fi-ware webinarsNov-Dec 2012Henk HEIJNEN (henk.heijnen@technicolor.com)

2. Agenda • The Cloud Edge / Cloud Proxy GE in a nutshell • Some possible use cases (examples) • Internal architecture • Integration with FIWARE • Availability • Programming (APIs) / Usage / Misc • Installation • Documentation, where is it? • SW, where to get it? • Q&A

3. The Cloud Edge / Cloud Proxy [1] Example: In a home environment Services in the Cloud PCs Cloud proxy Tablets Home Automation Game Consoles TV sets / STBs

4. The Cloud Edge / Cloud Proxy [2] • Major features: • Organize access to end-devices • Bandwidth management • Security / Privacy • Continuity of service

5. Some examples [1] High level application Services in the Cloud Data link (xDSL …) Cloud proxy Remote control Mini local application • Home automation: • Local intelligence in the cloud proxy  keeps the regulation active even if the data link falls down • Cloud based application  lots of features, remote access, link with other apps… AirCo Mgmt

6. Some examples [2] • Content sharing: • Local intelligence in the cloud proxy  makes sure only the allowed content is shared. Gives common APIs. • Cloud based application  lots of features, remote access, link with other apps… Can be used by operators. High level application Services in the Cloud Data link (xDSL …) Cloud proxy Mini local application The local app can also “hide” the low bandwidth of the datalink NAS Remote access Local HD

7. Some examples [3] • One of the containers is implementing a “pre-loaded” machine with an OSGi framework: • Allows deployment of “legacy” OSGi-based applications • Simple way to develop very small applications (without running a dedicated VM) • Less features, less flexibility

8. Internal architecture [1]

9. Internal architecture [2] • Components: • VES: Virtual Environment System • RM: Resources Monitoring • RC: Resources Control • SPM: Service Platform Management • (local portal) • (core) • (database)

10. Architecture [3] • VES – Virtual Environment System • Allows execution of virtual machines (containers in the current implementation) • Controls the resources given to the VMs • Controls the VMs (start / stop / status …) • RM – Resources Monitoring & RC – Resources Control • Allows the remote application / the cloud operator / the NSP to control and monitor the Cloud Proxy resources (files, local accesses, memory …)

11. Architecture [4] • SPM – Service Platform Management • Manages the download of new VMs • Implements the remote API for controlling the Cloud Proxy • Local Portal • Allows local management. • Mainly interaction with the user for granting / refusing resources / files accesses. • Can also be used to select apps from a list by the final user (mainly for “legacy” applications)

12. Architecture [5] • (core) • local implementation (Linux features). • access to the HW, to the LAN etc … • (database) • downloaded from the cloud • contains the list of the possible (ie: certified) apps and their characteristics • maintains the persistent data

13. Integration inside FIWARE [1] • Applications using the Cloud Proxy must be made of 2 components: • The Cloud-based part • see the other GEs for that !!! • can use any of the FIWARE tools and GEs • The Cloud Proxy part • a VM (LxC container) running under Linux • Embedded SW with limited resources (the Cloud Proxy is a small machine …) • The development environment is a regular PC with normal Linux tools (select your own language, dev tools etc …) • Most of Linux APIs are available (text-based Linux) • a VM that communicates with the Cloud-based part using its own protocols and APIs: • no limitation: can use any protocol, any API, any port# … • allows cloud-proxy apps to interface with legacy (ie: non modified) internet applications

14. Integration inside FIWARE [2] • The Cloud Proxy itself is controlled through 1 and only 1 interface • Between the “cloud operator” cloud-based component and the SPM (Service Platform Management) • In charge of the VMs download and control (start, stop, status) • The “cloud operator” block becomes a “network-component” • Also in charge of “gateway-like” features (control / setup of the device) • For some applications, the user must give his/her acknowledgement • because some apps may access to LAN-based resources (files …) • because of privacy / security reasons (access to profiling …) • This is done through the local portal (because we need a UI) • For most usages, VMs/containers developers do not have to take care of this API

15. Availability [1] • 3 versions of the cloud proxy: • Testbed#1 (July 2012): • simplified version without RC & RM • no OSGi framework • no integration with the cloud (the “Cloud Operator” module is simulated with a PC) • available as a PC SW (over a standard Linux distrib) or on a dedicated HW (super gateway) • Admin interface is using XML-RPC calls • Testbed#2 (July 2013): • all features implemented • (depending on the open calls): better integration with the cloud • OSGi available (intermediate version is already available (Nov 2012)) • running on a dedicated HW (and / or on a standard PC) • Admin interface is using a RESTfull API • Testbed#3 (Dec 2013): • more stable version • includes more features (tbd) accordingly to the UC needs

16. Installation [1] • The Cloud Proxy GE is provided as: • A bundle to be installed over a fresh UBUNTU 12.04TLS distribution on a standard PC • Rapid prototyping • Development for non-home-based environments (automotive, industry …) • Easy an cheap distribution • (next version only) SW running on a dedicated HW • Not for TestBed#1 unless really needed • >1GHz CPU + 1 to 2GB RAM + >120GB HD • better for demos • less flexible for integration and tests (cross dev / embedded)

17. Programming / APIs / Misc [2] • The only API between the Cloud Proxy and the cloud is documented in WP4 • Normally not directly used by the UCs • Very simple • download the database • download a VM • start / stop a VM • get status of a VM • get status of the Cloud Proxy (RAM left, CPU load …) • some misc features (mostly provision “for future use”) • It is the responsibility of each application to define / use its own APIs and protocols with the cloud-based application

18. Documentation [1] • Where to start? • Catalog: http://catalogue.fi-ware.eu/enablers/cloud-edge • Installation guide • https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Cloud_Edge_-_Installation_and_administration_guide • Open Specifications • https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.I2ND.CE • User’s guide • https://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/Cloud_Edge_-_User_and_Programmers_Guide

19. Software snapshot [1] • Get the snapshot here: • https://forge.fi-ware.eu/scmrepos/svn/fi-ware-review/trunk/FI-WARE/I2ND/CE/CloudProxy_Install_1_1_1_0-SNAPSHOT.tar.gz • The SW is available under “FRAND” licenses terms to registered PPP FI partners. • You can obtain a username / password if you meet these requirements. It must be asked to the project administrator

20. Thank you !Q&A henk.heijnen@technicolor.com