The Salty architecture is composed of managed and managing systems that interact at runtime in order to adapt according to changing context.
They interact thanks to sensors and effectors to respectively retrieve information and command modifications. The link between retrieved information and modifications is made thanks to feedback control loops that can be implemented by MAPE-K loops (TODO cite).
In the context of SOA, some standards and mechanisms seem suitable to face sensors and effectors issues. The following figure represents the chosen ones used in order to build an adaptive SOA framework.
We can see Event Driven Architecture (EDA) to implement sensors and Service Component Architecture (SCA) to observe and command modifications, and thus implement effectors.
From the EBM point of view, this adaptive architecture consists in a deployment of ESB middleware in which BPEL engines are installed in order to execute functional and reconfiguration workflows. Runtime adaptation features expected for Salty are located at functional workflow level. Then our main work in Salty concerns EasyBPEL and more precisely EasyVIPER.
The following figure is a summary of the adaptive architecture implemented in the context of Salty.
We can see the managed system is a set of Petals ESB nodes, that embed EasyBPEL engine to execute a business workflow. In the context of Salty, this workflow is a crisis management one, able to solve chemical, biological, radiological, and nuclear crisis. A set of sensors are placed at this level, onto which the first feedback control loop (FCL) can subscribe to. This first FCL is actually a particular node of Petals ESB (or several ones) enhanced by a WSDM profile. This particular feature allows it to receive data in order to detect agreements violation (defined in a first time). If a violation is detected (a partner down for instance), a reconfiguration BPEL is selected, stored and executed in order to adapt the running worklfow (replace a missing partner for instance). ...
Results of Salty mainly deal with EasyVIPER adaptation features.
In particular sensors and effectors are expected to be developed according to the Salty framework. They are implemented within an administration interface of [EasyVIPER|easyviper:EasyViper Overview], exposed as Web Service. The administration is composed of three parts:
# The Notification part, based on WS-Notification and subscribe/notify mechanism. This part allows to subscribe on particular events related to a workflow, and to retrieve functional and non functional information (service latency, which branch of the workflow is executed, service invokation failure, ...)
# The Observation part allows to get some informations about deployed workflows, their status, status of their nodes.
# The Command part allows to (un-)store, start, stop a workflow, to update it by replacing the behavior of a node, ...