Architecture Architecture

The initial architecture of CloudSocket comprises 4 main building blocks/environments which map to the 4 different phases of the business process lifecycle. This architecture has been designed according to 4 main principles:

  1. Loose coupling between environments in order to avoid the existence of tight environment dependencies and enable the selection of different implementations for the same environment towards delivering an integrated CloudSocket to brokers.
  2. A model-driven and layered approach which takes into account and caters for the transformation and alignment of the following artifacts:
    • Conceptual business processes
    • Executable workflows
    • Cloud-deployable workflow bundles
    • Deployed workflow bundles
      in production such that the business processes initially defined are finally deployed and executed in the cloud while the respective information value for business users is also retained and highlighted.
  3. Explicating the representation format and structure of these artifacts by adopting standards as much as possible to ease the integration between the environments and their respective components.
  4. Determining the interfaces of each environment and its components on different levels to allow a high-degree of flexibility in the way each environment or one or more of its components can be realized.

The figure below visualizes CloudSocket's initial architecture where each environment not only focuses on a different business process lifecycle phase but also attempts to provide the appropriate support enabling business and IT alignment. It must also be highlighted that apart from the 4 main environments, there is also the BPaaS Marketplace which acts as an external interface of the BPaaS Execution Environment providing basic marketplace functionality to CloudSocket broker customers that includes the visualisation, purchase and deployment of BPaaS offerings. Following through, we shortly analyze the main functionality of each environment by also indicating which component delivers which part of the main functionality.



Figure 1 - The initial CloudSocket architecture

The BPaaS Design Environment provides modelling and mapping functionality to CloudSocket brokers enabling them to design conceptual business processes as well as map them to the specification of executable workflows that realize them. Thus, this functionality, realized by the Hybrid Modeller, incorporates capabilities to edit domain specific business process models and executable workflows as well as store these two types of artifacts into the BPaaS Model Repository to enable their re-use. In addition, it includes information which can be used to directly (manually) or automatically map domain-specific business processes to executable workflows. The automatic mapping is facilitated through the introduction of semantics and ontologies enabling the annotation of the two artifact types according to different information aspects and the corresponding realisation of the respective mapping functionality via the Semantic Alignment Kernel.

The BPaaS Allocation Environment aims at packaging an executable workflow into a cloud-deployable workflow bundle which can then be provided as a new BPaaS offering by the BPaaS Marketplace. This packaging, which is facilitated by the Bundle Designer, is comprised of three main artifacts and has to be performed according to the desired business and technical requirements of the CloudSocket Broker. The first artifact concerns the allocation and mapping of workflow tasks to concrete SaaS offerings according to the requirements posed by also enabling the dynamic selection or substitution of SaaS during BPaaS execution according to prioritized conditions. The second artifact concerns the allocation and mapping of BPaaS software components to IaaS/Virtual Machine (VM) offerings which is decorated again through prioritized conditions for IaaS selection/substitution. As such, through the selection of SaaS and IaaS services, a particular deployment plan is actually constructed for the BPaaS which is enriched with transactional semantics. The last artifact maps to the specification of adaptation rules which will drive the adaptation of the BPaaS when requirements are violated or the service level offered is deteriorated such that an excellent BPaaS customer experience is continuously guaranteed. Each bundle, either complete, incomplete or disposed/archived is stored in the Draft Bundle Repository to enable its further editing by the CloudSocker Broker as well as its re-use towards designing new bundles.

When a particular BPaaS offering is purchased via the BPaaS Marketplace, the BPaaS Execution Environment is responsible to deploy it in the cloud via the Cloud Provider Engine, thus bringing it into operation. This environment also offers mechanisms in which BPaaS instances can be configured, executed and managed via the respective capabilities offered by an internal Workflow Engine. This environment, empowered by the Monitoring Engine, is also responsible for monitoring the BPaaS execution, according to the particular SLO requirements posed, as well as adapt it via the Adaptation Engine when these SLO requirements are violated, according to the adaptation rules defined in the BPaaS bundle. Finally, the BPaaS Execution Environment offers a plethora of User Interfaces (UI) by the Web-Workspace enabling the visualization and management of BPaaS instances, the highlighting of SLO status and the detailed monitoring drill-down into concrete metric evaluations when one or more SLOs are violated as well as the supply of semantically-rich information concerning the execution and monitoring history of BPaaS to other environments.

The BPaaS Evaluation Environment is the best place for BPaaS performance analysis and improvement. It offers visualisation mechanisms via a Hybrid Business Dashboard which not only allows demonstrations of KPI assessments but also their drill-down into lower-level KPI and metric evaluations. It is also able to perform different types of semantic-based analysis, empowered by an underlying Semantic Repository which semantically integrates the various information aspects required, spanning the discovery of best deployments, the detection of event patterns leading to KPI violations as well as the mining of BPaaS to discover bottlenecks and places for BPaaS model improvement. The first two types of analysis are supported through the Conceptual Analytics Engine while the last one is realized via the Process Mining Engine. All these analyses can lead to optimising the BPaaS and the service levels offered, thus enabling the CloudSocket broker not only to guarantee a stable customer experience but also to maximize its profits.


Copyright © 2016 BOC and other members of the CloudSocket Consortium.

The CloudSocket project receives research funding from the European Union's Horizon 2020 Framework Programme

Coordination: BOC, Dr. Robert Woitsch,