The workflow engine is the main component of EasyVIPER. It receives message exchanges, uses the Process Instance registry in order to know if it can correspond to one of the deployed workflows. It forwards these exchanges to Process Instances and also sends message exchanges going outside them.
{center}
!EasyVIPERWorkflowEngine.png|border=1,width=900!
SCA Model of EasyVIPER workflow engine, with some processes also represented as SCA components.
{center}
h2. Workflow SCA architecture
Workflows built by EasyVIPER consist in a set of SCA components executed in a structured way. Their architecture is a graph of nodes, onto which are bound behaviors (see the following figure). The real business tasks are performed by these behaviours. Nodes components are only considered as containers. This is explained by the will to be strongly adaptive and to easily change a workflow with minor impact on components bindings. Indeed, the replacement of a behavior on a node only implies one link.
{center}
!workflowSCA.png|border=1,width=900!
Workflow architecture, composed of nodes and behaviours.
{center}
h2. Core Model
EasyVIPER defines 13 main default behaviours:
|| name || action \\ ||
| Receiver | Waits for some external message(s). |
| Assign | Makes assignments between variables. |
| Sender | Sends a message (invoke a Service or replies to a client). \\ |
| Throw | Sends a fault message. \\ |
| ReThrow | Propagates faults in the graph. \\ |
| Scope | Creates a context for its enclosed graph nodes (variables, partnerlinks, ...). |
| Conditional | Conditional action according to a predicate. |
| Loop \\ | Performs several times a subset of the graph. \\ |
| Sequence | Divides the process into sub-processes that work in sequence. |
| Flow | Divides the process into sub-processes that work in parallel. \\ |
| Wait | Stops the execution and waits (according to a duration or a date). |
| Exit | Emergency exit that stops and finishes the process. |
| Empty | Does nothing |
As EasyVIPER is extensible, it is possible to add user-defined behaviours (debug or log behaviours for instance). However, these main behaviors are sufficient to express workflows defined by standards as WS-BPEL or BPMN 2.0.
h2. Graph model
EasyVIPER builds execution graphs composed of nodes supporting the behaviours detailed above. The mapping between BPEL activities and EasyVIPER behaviors is the following:
* the name of the EasyVIPER behavior is set with the name of the BPEL activity,
* the node supporting a behavior called A is called node_supporting_A.
* The following list details the mapping between BPEL and the EasyVIPER model:
** Receive, Pick -> Receiver
** Invoke, Throw -> Sender
** ForEach, While -> Loop
** Flow -> Fork
Other behaviors have got the same name in the EasyVIPER model.
{center}
!EasyVIPERWorkflowEngine.png|border=1,width=900!
SCA Model of EasyVIPER workflow engine, with some processes also represented as SCA components.
{center}
h2. Workflow SCA architecture
Workflows built by EasyVIPER consist in a set of SCA components executed in a structured way. Their architecture is a graph of nodes, onto which are bound behaviors (see the following figure). The real business tasks are performed by these behaviours. Nodes components are only considered as containers. This is explained by the will to be strongly adaptive and to easily change a workflow with minor impact on components bindings. Indeed, the replacement of a behavior on a node only implies one link.
{center}
!workflowSCA.png|border=1,width=900!
Workflow architecture, composed of nodes and behaviours.
{center}
h2. Core Model
EasyVIPER defines 13 main default behaviours:
|| name || action \\ ||
| Receiver | Waits for some external message(s). |
| Assign | Makes assignments between variables. |
| Sender | Sends a message (invoke a Service or replies to a client). \\ |
| Throw | Sends a fault message. \\ |
| ReThrow | Propagates faults in the graph. \\ |
| Scope | Creates a context for its enclosed graph nodes (variables, partnerlinks, ...). |
| Conditional | Conditional action according to a predicate. |
| Loop \\ | Performs several times a subset of the graph. \\ |
| Sequence | Divides the process into sub-processes that work in sequence. |
| Flow | Divides the process into sub-processes that work in parallel. \\ |
| Wait | Stops the execution and waits (according to a duration or a date). |
| Exit | Emergency exit that stops and finishes the process. |
| Empty | Does nothing |
As EasyVIPER is extensible, it is possible to add user-defined behaviours (debug or log behaviours for instance). However, these main behaviors are sufficient to express workflows defined by standards as WS-BPEL or BPMN 2.0.
h2. Graph model
EasyVIPER builds execution graphs composed of nodes supporting the behaviours detailed above. The mapping between BPEL activities and EasyVIPER behaviors is the following:
* the name of the EasyVIPER behavior is set with the name of the BPEL activity,
* the node supporting a behavior called A is called node_supporting_A.
* The following list details the mapping between BPEL and the EasyVIPER model:
** Receive, Pick -> Receiver
** Invoke, Throw -> Sender
** ForEach, While -> Loop
** Flow -> Fork
Other behaviors have got the same name in the EasyVIPER model.