I'm not sure to well understand this point. External events (i.e a jms or an email notification) could wake up a process instance. A particular NodeBehaviour could be so implemented to react to those external events.
what do you mean by "to add static events to process ?"
Indeed i didn't explain properly. Koen also didn't get it.
A static event is a signal for 1 particular process instance that can come at any time during the whole execution of the process instance.
This is unlike signals that correspond with transitions. Those signals only can be fed into an execution when it is positioned in the source node of the corresponding transition.
On a static event, you could e.g. spawn a new execution and launch it from a node somewhere in the process. Perhaps a subgraph which is not connected to the graph that forms the main part of the process. Or a process variable could be updated in a process event, so that the main path of execution could take a decision based on the value of that variable.
Probably, as we have it now, you can fire events with the process as an eventSource. So I think that way, static events are already supported.
Or do you see other functionalities that we need to support in order to cover the functionality mentioned in the blog ?
I agree that we can leverage Process events to do that. Actions associated to those events would contain the event logic: i.e change the value of a particular variable.
But, who will be responsible of firing those events ? shall we provide a set of listeners (mail, jms...) ?
pvm should only be concerned with the java API. process languages can expose the API with any transport they want (or just make it available on the ESB)
I agree this is more on the side of solutions developed on top of the PVM.
For instance, we will certainly help end users to work with events in Bonita/Orchestra by providing some specific connectors/listeners (customers like that :-). I guess you have also planed something similar in Jbpm