Posted on

UBITECH and SINTEF shows the way the ARCADIA development, deployment, monitoring and maintenance framework maps onto OASIS TOSCA at the ERK 2017 in Slovenia

In the frame of the 26th International Electrotechnical and Computer Science Conference (ERK 2017), which takes place these days (September 26-27, 2017) in Congress Center Bernardin, Portorož, Slovenia, and is organized by the IEEE Slovenia Section together with Faculty of Electrical Engineering University of Ljubljana and other Slovenian professional societies, researchers from UBITECH and SINTEF contrast the OASIS TOSCA standard with the sophisticated ARCADIA framework, which provides developers with an integrated tool chain that reconciles IDE, service orchestrator and monitoring platform, and presents how to use TOSCA to describe ARCADIA orchestrations, and how the lessons learnt building the ARCADIA framework could benefit to future versions of TOSCA.

While ARCADIA’s scope encompasses TOSCA, one can use TOSCA to describe orchestrations of ARCADIA services, that is a ”service graph”. In particular, three key modelling level mappings have been identified:

a) ARCADIA Component vs. TOSCA Service Types. Both ARCADIA and TOSCA have a concept of type that one can instantiate to build a service orchestration. These are “component” in the ARCADIA terminology and “service types” in TOSCA. Both refer to deployable units that one can install and run, such as a JAR file or a Python script to name a few. In addition, every ARCADIA component requires a wrapper that unifies the life-cycle management and monitoring.

b) ARCADIA Service Graph vs. TOSCA Service Templates. Services orchestrations, which pre-assemble instances of existing types, also exist in both ARCADIA (service graphs) and TOSCA (service templates). Service providers combine components or services into new orchestrations or to extend existing ones.

c) ARCADIA Grounded service graphs. As is, TOSCA does not have a notion of running orchestrations, which ARCADIA call “grounded service graphs”. They result from the deployment of an existing service graph and they are target of runtime policy management. TOSCA-compliant are free to use any description and format to expose the status of the highly distributed applications they manage.