{children:excerpt=true}

{numberedheadings}

h1. Overview of the EBM usecase

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.

{center}
!ReflexiveSchema.png|border=1,width=400!
An adaptive SOA framework.
{center}

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|easybpel:EasyBPEL Overview] and more precisely [EasyVIPER|easyviper:EasyViper Overview].

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

{center}
!Salty_full_architecture.png|border=1,width=1200!
The whole EBM usecase architecture.
{center}

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|http://en.wikipedia.org/wiki/Chemical,_biological,_radiological,_and_nuclear]. A set of sensors are placed at this level, onto which the first feedback control loop (FCL) can subscribe to.

The represented probes sent by sensors are, on one hand, the 4 main timestamps during a service invocation within the bus:
* T ~i~ \_1 is set when the request of the client is entering the bus,
* T ~i~ \_2 is set when the request of the client reaches the invoked service,
* T ~i~ \_3 is set when the response of the service is entering the bus,
* T ~i~ \_4 is set when the response of the service goes outside the bus.

On the other hand, some functional probes are retrieved in order to control precisely the crisis workflow:
* C ~i~ is the heart rate of the i ^th^ fireman service.
* AT ~i~ is the blood pressure of the i ^th^ fireman service.
* S is the status of the crisis.


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). A lookup table is built at this level between SLA violations and corresponding reconfiguration actions. These reconfiguration actions are exposed by a particular service of the BPEL engine and are described by the following figure.

{center}
!esb_salty_model.png|border=1,width=1200!
EBM usecase with the Salty framework view.
{center}

Command actions are _(start)stopWorkflow_, _replaceService_, {color:#0000ff}{_}removeBranch{_}{color}, {color:#0000ff}{_}executeFScript{_}{color} (blue ones are work in progress).

In the case of a more complex adaptation action (that would consists in a combination of these unitary actions), a BPEL workflow appears well suited to orchestrate the reconfiguration. These reconfiguration BPELs are executed by a dedicated BPEL engine located on the FCL node of Petals ESB.

This look-up table can be filled at deployment or, in a more interesting way, it can be fed along the workflow execution, thanks to the second FCL. Indeed, in case of a unknown SLA violation, for which no reconfiguration action is foreseen, an indirection is made on the second FCL. In this higher level adaptation process, an expert can design (or select or configure) a particular BPEL in order to add a tuple in the first FCL table.

Finally, if a violation is detected (a partner down for instance), a reconfiguration action or BPEL is selected, stored and executed in order to adapt the running workflow (replace a missing partner for instance).

h1. Current scenario specification

h2. Adaptation for a non responding service

In this scenario, an agreement is defined, that indicates a Web Service (fireman) MUST answers in less than X seconds. Thanks to an enhancement of the WSDM implementation,
timestamps are sent at T ~2~ and T ~4~ (at the moment, timestamps are sent only at T ~4~). Thanks to the intermediate T ~2~ report, a too high latency can be detected during the invocation.
Then the violation implies a replacement of the invoke activity endpoint (see the following figure).

{center}
!schema_juju_1.1.png|border=1,width=400!
Non responding service case.
{center}

h3. Deployment phase

The CBRN workflow is stored in the BPEL engine of the managed system. Web services representing every partner are available.
The WSDM node subscribes on the crisis workflow (on timestamps).
A request is sent to start the CBRN workflow.


h3. Runtime phase

During the execution of the process, a partner, i.e. a Web Service does not answer (fireman for instance).
The WSDM node detects the loss of one partner and launches the corresponding reconfiguration action, that consists of a BPEL \(i) verifying the status of the corresponding invocation activity, (ii) stopping the workflow, (iii) replacing the endpoint of the partner and (iv) restarting the workflow.
The end of the workflow is executed and the nominal output is expected.

h2. Adaptation for a service failure response

In this scenario the service answers with a business fault. Thanks to a prior subscription on activity present in the "invoke catch", a notification is sent to the WSDM node.
This issue is managed by a reconfiguration workflow that consists in \(i) verifying the status of the corresponding invocation activity, (ii) stopping the workflow, (iii) adding an invoke activity and a partner (fireman2) and (iv) restarting the workflow. The following figure summarizes this scenario.

h3. Deployment phase

The CBRN workflow is stored in the BPEL engine of the managed system. Web services representing every partner are available.
The WSDM node subscribes on the crisis workflow (on the wait activity).
A request is sent to start the CBRN workflow.

h3. Runtime phase

During the execution of the process, a partner, i.e. a Web Service answers with a business fault (fireman for instance).
The WSDM node detects the failure of the service and launches the corresponding reconfiguration action consisting in adding a invocation to a new partner.
The end of the workflow is executed and the nominal output is expected.

h1. Technical point of view implying EBM products

From a technical point of view, main works are
* Notification, observation and command facilities provided as a workflow engine administration interface, implemented thanks to a EasyVIPER extended service (see the specific [how-to|easyviper:How to implement and add an extended service to EasyVIPER?]).
* WSDM profile implementation, SLAs, WS-Agreement constructions (TODO link to technical help).
{numberedheadings}