|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Changes (5)
View Page History
...
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. 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). |
| Receiver | Waits for some external message(s). |
...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.