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) for data reification and Service Component Architecture (SCA) to observe and command modifications.

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.

The following figure is a summary of the adaptive architecture implemented in the context of Salty.

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