Workflow engine

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.

SCA Model of EasyVIPER workflow engine, with some processes also represented as SCA components.

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.

Workflow architecture, composed of nodes and behaviours.

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

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.
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.