EasierCos takes as input a BPMN (Choreography) process. It compiles it in order to generate an EasyVIPER process instance, that consists in an executable graph composed of behaviours dedicated to the choreography. Once started, a process instance subscribes to partners involved in the choreography relationships.
Indeed, in the context of a SOA middleware, as an ESB for instance, we can consider every partner - every service provider - is prone to be a notification producer. Notifications containing QoS and technical information can be sent if activated.
Then, the process instance waits for the different notifications it expects, and checks the several timestamps validity. In case of time out or not acceptable timestamps, it's the EasierCos turn to send alerts to higher level middleware tools, such as governance platform.
h1. How does it work?
The main job is done by EasyVIPER. Once compiled by EasierCos, EasyVIPER executes the choreography as an execution graph (exclusive and inclusive gateways have been intepreted as corresponding EasyVIPER behaviours at compilation time), into which nodes correspond to choreography tasks.
{center}
!EasyBPMNModel.png|border=1!
EasierCos layer architecture: compilation and process definition registry.
{center}
Indeed, EasyVIPER provides main behaviours related to SOA process execution, such as Receiver, Sender, Loop, If,...
Furthermore, we can benefit from the fact it's an extensible library, for which new behaviours can be implemented. A new behaviour dedicated to the choreography is then implemented. This behaviour, called MEMB (for Message Exchange Monitoring Behaviour), is a WS-Notification consumer that previously subscribed on specific topics related to partners and that is able to check notifications validity.
If you want know how to use {report-info:page:space > space:name} library, please consult the list of [How-tos|How-tos].
If you have any questions, please use the \[{report-info:page:space > space:name} contact form\|Contact\].
...