3.3 BPaaS Adaptation Engine

3.3.a AXE Adaptation Framework

 

Research Problem

Current Cloud Orchestration Tools have either too simplistic or too verbose methods of adaptation descriptions. Commercial tools have mainly simple approaches of adaptation, such as container scaling, and research-driven tools suffer of too loosely described methods that are hardly usable for the average customer. An example for the latter is the BPMN integration into TOSCA to describe workflow, for which the user has to implement the classes on their own.

Solution Approach

We aim for an integrated component, that holds the CAMEL adaptation plans, which targets our requirements as described in D3.3. We are sure that we achieve a more useable approach than generic BPMN workflows, as our approach is very specific to the cloud. The Axe adaptation approach furthermore targets to be integrated as loosely coupled component that can be added to the Cloud Provider Engine / Cloudiator without changing internals.

Architecture

[Picture of Adaptation Management, Axe [MS] and how they communicate]

The Adaptation Management component was integrated with the Axe component of the Cloudiator framework in a loosely coupled way. The figure above shows the integration into the components. As any other external component it uses the REST interface of Colosseum and changes the entities as described in the adaptation plans.

 

Information

CloudSocket Webinar on BPaaS PRovisioning
Webinar on Orchestration and Adaptation Slide Set
D3.3 BPaaS Allocation and Execution Environement Blue Print
BPaaS Allocation and Execution Prototypes
Demonstration Video
Presentation: PaaS Orchestration and Adaptation
 

Use

http://134.60.64.166:9017/v0/step
 

Extend

GitHub Adaptation Framework
 

Additional Information

Originator: Frank Griesinger (UULM)
Technology Readiness Level: 4
Related CloudSocket Environment: Execution

3.3.b Cross-Layer Adaptation Framework

 

Research Problem

BPaaS adaptation needs to be performed across different levels of abstraction. This is required in order to avoid having different adaptation mechanisms being triggered independently such that the effects of one mechanism can be undone by the other, thus resulting in vicious adaptation cycles. Moreover, different levels need to be covered as one problematic situation could be impossible to be addressed by just one level. For instance, the migration of a software component from one cloud to another might also require adopting the workflow level in order to perform a respective replacement of the service endpoint in the workflow description, usually done in the context of service replacement.

 

Solution

FORTH has developed a cross-layer BPaaS adaptation framework which is able to orchestrate the execution of different adaptation actions at different levels of abstraction. All level-specific actions are encapsulated in the form of a service while the whole adaptation workflow orchestration
is performed by executing a normal service-based workflow specification. There is also a transformation functionality realised which at the current moment can enable the transformation of the consequent part of an adaptation rule into a concrete adaptation workflow. Such a transformation
currently considers only one adaptation action realisation at each level. However, it is foreseen that in the near future, the workflow concretisation will be performed in a more sophisticated manner by considering adaptation requirements like the adaptation time and cost as well as the
current adaptation capabilities offered, which might span alternative implementations of adaptation actions being supplied by one or more level-specific services.  

 

Architecture

 

 

The architecture of the framework can be seen in the following figure. This framework comprises the following components: (a) an Adaptation Engine which is a normal workflow engine that is able to execute adaptation workflows; (b) three service components covering the workflow, service and infrastructure levels by encompassing respective level-specific functionalities; (c) a Transformer component which transforms the consequent part of an adaptation rule into an adaptation workflow in order to publish it; (d) a Rule Engine which is able to infer based on the current situation which workflow needs to be enacted by the Adaptation Engine.

 

 

Information

FiCloud Paper
Slide Set von Cross Layer Monitoring
BPaaS Allocation and Execution Blue Print
BPaaS Allocation and Exeuction Environment Prototypes
 

Additional Information

Originator: Kyriakos Kritikos (FORTH)
Technology Readiness Level: 4
Related CloudSocket Environment: Execution

3.3.c Synergic Cross-Layer Adaptation Framework

 

Research Problem

BPaaS adaptation needs to be performed across different levels of abstraction for two main reasons: (a) to avoid vicious adaptation cycles. This can occur when independent, level-specific mechanisms are triggered leading to the possibility that one mechanism undoes the effects of another one and vice versa; (b) to cover different abstraction levels in order to confront more advanced problematic situations which cannot be addressed via employing adaptation mechanisms in just one level. For instance, the migration of a software component from one cloud to another might also require adopting the workflow level in order to perform a respective replacement of the service endpoint in the workflow description, usually done in the context of service replacement.

Solution  

The cross-layer BPaaS adaptation solution comprises the integration of different adaptation frameworks that have been developed by two academic partners of the CloudSocket project, namely FORTH and University of ULM. By joining forces, current adaptation implementation gaps at different levels are covered in the form of services which include methods mapping to the level-specific adaptation actions supported. In addition, the respective individual features offered by each framework can be capitalised and exploited to make them available for the combined framework. As such, this solution looks ideal for realising or replacing the functionality of the Adaptation Engine in the current CloudSocket implementation. Some extra and added-value features of the combined framework, either already realised or implemented in the near future, include the following: (a) capability to on-the-fly edit the adaptation rules semi-automatically generated in order to optimise them via the facilities of an expert user along with capability to create new adaptation rules manually; (b) capability to retrieve the adaptation history of a certain BPaaS and thus be able to support analysis over it to derive interesting facts, like how well a certain adaptation rule has served its purpose, i.e., it has been successful; (c) capability to initiate the execution of the consequent part of an adaptation rule in case that user intervention needs to take place; (d) capability to on-the-fly inject new adaptation functionalities in the framework; (e) capability to concretise an adaptation rule based on the current adaptation mechanisms available in the framework. 

Architecture

The architecture of the combined / synergic framework is depicted in the following figure.

 

As it can be seen, this framework comprises the following components:

(a) the Transformer is responsible for mapping adaptation rules, which are generated by the BPaaS Evaluation Environment, into two forms: one which is suitable for storage in the Rule Base and another which is suitable for storage in the Adaptation Engine;

(b) the Rule Base is responsible for storing the adaptation rules provided by the Transformer and discovering the one which is the most suitable to confront the current problematic situation. The latter discovery is supported via the use of monitoring facts communicated by the (BPaaS) Monitoring Framework. In case that an adaptation rule should be triggered, then the Adaptation Engine is informed in order to enact the respective adaptation;

(c) the Adaptation UI is a UI enabling the expert to modify the rules automatically generated by the BPaaS Evaluation Environment or to insert new rules to cover new adaptation situations; 

(d) the Adaptation Engine is a normal workflow engine which is able to enact the adaptation workflows needed while it is also responsible for storing the adaptation actions that have been performed in the Adaptation DB;

(e) the workflows executed by the Adaptation Engine map to method calls of level-specific services: the service and workflow level is covered by the cross-layer adaptation framework of FORTH while the infrastructure and platform level is covered by the adaptation framework of UULM. As already indicated, the methods of these services map to particular level-specific adaptation actions that are offered for  execution;

(f) finally, the Adaptation Service enables the retrieval of adaptation history information from the Adaptation DB, mostly for the analysis purposes of the BPaaS Evaluation Environment, while it also enables the programmatic execution of adaptation workflows, in case where manual intervention is needed, thus mapping to the case that the current situation is not covered by the current set of adaptation rules modelled.  
 
 

Information

D3.3 BPaaS Allocation and Execution Environment Blue Print
D3.4 BPaaS Allocation and Execution Environment Prototypes
Adaptation Slide Set
FICloud Paper
Cross Layer Slide Set
Tool - Wiki
Research Challenge Wiki
Solution Wiki
Architecture Wiki
Related Information on Axe Framework
 

Additional Information

Originator: Kyriakos Kritikos (FORTH)
Technology Readiness Level: 5
Related CloudSocket Environment: Execution

 

Additional Information

Originator: Frank Griesinger (UULM)
Technology Readiness Level:
Related CloudSocket Environment: Execution