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  #

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. 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.   

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. 

The source code will be available at the Gitlab.

References: #

• D3.3 BPaaS Allocation and Execution Environment Blueprints
• D3.4 BPaaS Allocation and Execution Environment Prototypes
• AXE Adaptation Framework