{multi-excerpt:name:starting-date|hidden=true}2009{multi-excerpt}
{multi-excerpt:name:ending-date|hidden=true}2012{multi-excerpt}
{multi-excerpt:name=excerpt}
SALTY (Self-Adaptive very Large disTributed sYstems) is an ANR-funded research project (Agence Nationale de la Recherche - ANR-09-SEGI-012). It aims at providing an innovative self-managing software framework at run-time for Very-Large Scale Distributed Systems (VLSDS).

In few years, the software industry has adopted the service architectures paradigm to manage complexity, heterogeneity, adaptability and costs. The growing demand leads to the deployment of ever-larger scale systems, which reliability or performance are impaired by hardly predictable events (software faults, hardware failures, mobility, etc). Consequently, a lot of work towards software and hardware self-adaptations has been carried out and deployed into the field redundancy, resources reservation, scheduling, etc), but none of them is designed to address run-time self-adaptation of VLSDSs that consistently federate local platforms into a global distributed system to support collaborating applications.
{multi-excerpt}

The aim of EBM in this project is to face adaptation issues in the context of ESBs and services orchestration. By using the Salty adaptation framework, we expect to manage long and versatile workflows by enhancing features of [EasyBPEL|easybpel:EasyBPEL Overview] and [EasyVIPER|easyviper:EasyViper Overview].

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

Sensors consist then in either SCA intents put upon workflows nodes, either getter operations upon workflows. These intents can send notifications about functional and non-functional information to a controller. Effectors consist in invoking the command part of the administration interface, in order for the controller to adapt a workflow according to the situation.

The administration consists in an extended service of EasyVIPER. The page [salty:Architecture] details more precisely how this work is used in order to build an adaptive framework.