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!
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_2.1.png|width=500!
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.
{center}
!schema_1.1.png|width=500!
Service failure 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 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}
...