defining pvm event terminology

[tombaeyens]

i'ld like to review the terminology around events.  i see following types of events:

1) ProcessService.event() & ExecutionImpl.event(): An event is sent to an execution.  The execution propagates the event to the current activity behaviour.  From the perspective of the activiti engine, this is an incoming event.  Event here is overloaded.  Signal could be an alternative, but that also has a meaning in BPMN.  Finding a full PVM naming strategy that is completely non-conflicting with bpmn and other languages is not possible.  But if we can avoid such name clashes, it's always better.

2) ScopeElement.eventListeners: Listeners can subscribe to process definition events.  We currently have the concept of events in the process definition.  A process element (like  the process definition itself, an activity or a transition) can fire different types of events to which can be listened.  Those events have an event name (String).  So each event is uniquely identified by process element and the event name.  Each event can have a list of listeners subscribed to it.

3) History events / Process event bus events.  These are outgoing events produced by the engine.  External tools should be able to subscribe to these events.  History is build on this.  But these events can also be used for other purposes.  In this case, listeners are defined in the process engine.  In our experience, there is some overlap in the events with the process definition event listeners like explained in 2, but the events in which these process-engine-listeners are interested typically differ.

The goal of this topic is to define the concrete meaning of the different events in the pvm and come up with precise pvm terminology.

[dsyer]

In 1) we could use "trigger" instead of "event". I think that's the most important distinction to make (between 1 and 3).

I'm not sure I understand what 2) means (so the name is a candidate for change to make it clearer). What is a process definition event? A parser event? When do they get fired, and who listens?

[bernd_ruecker]

Im my feeling "Event" for 3) is correct, and since it is much more exposed to the outside world than 1) I would name it like that there.
The clash with BPMN is a minor problem, but I think we have to live with it.

Where is the difference between 2 and 3? Isn't it the same concept used in a different scope?

For 1). Hmm, Maybe we can name it "IncomingEvent". Doesn't it somehow boil down to an event like it is named in BPMN? Then naming it like that would be good. On the other hand, this concept is more or less internal only, so I think less visible than the Event Bus, so I would prefer the naming "Event" there.

[tombaeyens]

in the pvm experiments that i'm working on now, i called the incoming events back signal (as in jbpm 3).  i think the name clash with bpmn signal is not a blocker.  bpmn also has the term event and i think it's good to use event for (3) in the pvm.   finding full terminology of the pvm without having a naming clash with bpmn seems to be impossible.

[falko_menge]

Personally, I don't see any problems with having name clashes between the PVM and the BPMN implementation on top of it. They could be easily distinguished by giving them a short prefix, e.g., BPMN events and PVM events.

However, I would prefer that similar terms have similar meanings. As it is the industry standard, BPMN semantics should have precedence over historic meanings from the jBPM space. Hence, a trigger that goes to a single process instance and potentially carries some payload (=signal name in jPBM) should be called Message instead of Signal, which would be broad-casted to all process instances.

[tombaeyens]

although, bpmn is the primary focus of activiti, the pvm has broader scope then just bpmn.  i think message is even more overloaded then signal.  signal only has 2 meanings i am aware of: the uml state machine version and the bpmn version.  it's not ideal, but i think signal gives less confusion then message.