fmi static triggers

[tom.baeyens]

i was thinking about adding a mechanism for specifying the external triggers that relate to transitions and events.

now i was reading Bruce Silver's blog about metastorm

OK, not entirely architecture-neutral, since BPMN effectively demands that the orchestration engine can respond to events in some fashion. That?s usually the place where traditional workflow engines (and BPA tools) can?t handle BPMN. Some deal with the problem by leaving events out of the tool palette. But the right approach, in my view, is to admit it?s the right direction, and incrementally move to accommodate it, as TIBCO and Savvion are doing.

http://www.brsilver.com/wordpress/2007/08/01/metastorm-proforma-sidebar/

so this is just a 'For My Information' not to forget to add static events to processes. those should be able to feed in external triggers on the process, rather then on a runtime process instance.

[mvaldes]

Tom,

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 ?"

regards,
Miguel Valdes

[tom.baeyens]

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 ?

[mvaldes]

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

regards
Miguel Valdes

[tom.baeyens]

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)

[mvaldes]

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

regards,
Miguel Valdes