Dr Marian Neagul (Institute e-Austria Timisoara, Romania) presented the CloudLightning Service Description Language at the Fifth National Conference on Cloud Computing and Commerce in Dublin City University on 12th April 2016.

1. SELF-ORGANISING, SELF-MANAGING
HETEROGENEOUS CLOUD
The CloudLightning Service Description Language

2. CloudLightning Gateway
Service – API & Definition
Language
Marian Neagul / marian@ieat.ro
Institute e-Austria / www.ieat.ro
Timișoara / Romania

3. Overview
• A different perspective to the CloudLightning Architecture
• The CloudLightning Gateway Service
Main Functionalities
API Model
• The CloudLightning Service Description Language

4. The CloudLightning Architecture
Gateway Service Perspective
GatewayService
Gateway Service UI
OrchestratorEngine
Blueprint Decomposition Engine
Apache Brooklyn
ServiceCatalogues

5. The CloudLightning Architecture
Gateway Service Perspective
GatewayService
Operator
CSP
Acquire/Deploy Blueprint
Register Offers
Catalogues
Brooklyn
Service
Decomposition
Console/UI
QueryyDeploy
SelfOrganizingCloud
Deploy Services
Trigger Self Organization

6. CloudLightning Gateway Service
Overall functionality
• Represents the interface between the Operator and the
Self Organizing Cloud
The Gateway Service also serves the CSP, allowing him to
register new blueprints (definitions of applications) and
services
• Abstracts the inner workings of the self organizing system
(effectively hiding most of the internal details like vRacks,
Cells, etc)
• It’s functionality is wrapped around a custom tailored
Service Definition Language ☞
What is an
application ?

7. CloudLightning Gateway Service
Gateway UI (Web Console)
• The Web Console is aimed to provide
user interface for Blueprint definition
service service registration
and, most importantly, for triggering the deployment of the
blueprint 
• The Console builds upon the capabilities of the Brooklyn
component
This allows us to reuse already existing Apache Brooklyn
features
• It aims to hide the intricacies of the self organization
systems

8. CloudLightning Gateway Service
Catalogues
• We have several kinds:
Service Catalogues: holding service definitions provided by the
CSP or, eventually, by the Operator
Blueprint Catalogues: holding blueprint definitions
(compositions of registered services or blueprints)
• The catalogues are consumed by:
The decomposition engine, aiming to optimize the service
choice according to various criteria
The console, for presentation and management purposes
The Apache Brooklyn component for triggering the effective
service orchestration and deployment

9. CloudLightning Gateway Service
Service Decomposition Engine
• The Service Decomposition Engine is the component of
the Gateway Service responsible with the interaction with
the self organizing system
• It’s main function:
Transforming abstract specifications to concrete
implementations according to user requirements; This is
achieved by tight integration with the self organizing system;
The Decomposition Engine is the facilitator for achieving some
of CloudLightning main aspirations: as for example energy
efficiency or performance

10. CloudLightning Gateway Service
Apache Brooklyn
• We build upon the Apache incubated Brooklyn Project
We extend it to support our concept of “meta” services
We extend it in order to properly interact with the Service
Decomposition Engine
• Brooklyn's Blueprint language serves as the “backbone”
of the CloudLightning Service Definition Language
We add custom constructs for referencing “meta” services and
specifying service requirements ☞

11. CloudLightning Gateway Service
Service Definition Language
• As previously mentioned represents the main construct
for specifying application and service requirements
• Is build on top of the Apache Brooklyn Blueprint
Extended to support meta services
Extended to support the specification of requirements at
various levels: service or application level

12. Structure of the Blueprint / SDL
The API view

13. Example Blueprint / SDL
location: cloudlightning-1:ro.ieat
name: My Cool Raytracing Solution
requirements:
- ....
services:
- type: io.cloudlightning.entity.meta.RayTracingComputeService
id: RayTracingComputeService
brooklyn.config:
cloudlightning.soso.min_performance: 100gflops
cloudlightning.soso.placement-policy: same-broadcast-domain
cloudlightning.config:
hints:
prefer: ['GPU', "FPGA", "CPU"] # List of preferences
requirements: ...
- type: io.cloudlightning.entity.meta.raytracing.controller
id: raytracingController
brooklyn.config:
messos_cluster.head_node:
$brooklyn:component("RayTracingComputeService")

14. Implementation Schedule
• Specification of the requirements for the Service
Definition Language is expected to be formulated by end
of M15 (End of April 2016)
• The complete implementation of the Gateway Service is
expected by end of M24 (February 2017)
We plan to push relevant patches upstream (Brooklyn)

15. Questions ?

16. THANK YOU
Marian Neagul