topic Re: defining pvm event terminology in Alfresco Archive

defining pvm event terminology

tombaeyens — Tue, 20 Jul 2010 08:58:56 GMT

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

Re: defining pvm event terminology

dsyer — Mon, 26 Jul 2010 04:07:11 GMT

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?

Re: defining pvm event terminology

bernd_ruecker — Mon, 26 Jul 2010 09:56:39 GMT

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.

Re: defining pvm event terminology

tombaeyens — Tue, 27 Jul 2010 10:27:48 GMT

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.

Re: defining pvm event terminology

falko_menge — Tue, 27 Jul 2010 14:34:51 GMT

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.

Re: defining pvm event terminology

tombaeyens — Tue, 27 Jul 2010 15:12:38 GMT

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.