signal name clash

[tom.baeyens]

i would like to hear all opinions on the jbpm term signal and potential alternatives.

a signal in jbpm terminology is an external trigger that is given on an execution. the execution passes the signal to the current activity implementation for handling it.

in jPDL, the typical association that the activity implementations make is to take a transition that corresponds to the signal. (a la finite state machines)

but (also a la finite state machines) a signal can fire the corresponding internal event if there is one. in that case, the process does not propagate the execution, but just executes a list of listeners to the internal event.

signal is now the method on the activity to receive external triggers.

and the methods on the services are called signalExecution.

some more background:

jBPM has 3 types of events.
1) an external event coming into an execution (signal)
2) an internal event on which listeners can listen. those listeners cannot influence the control flow (called events)
3) outgoing events to which BI tools can listen to be informed about what happens when. those are called process logs.

I have been thinking of unifying those 3 concepts into 1 event concept, but I have not yet been able to fully apply such unification into a simple consistent set of concepts.

Since signal has been a fundamental concept in jBPM till now, I don't want to replace it lightly and then find out later that it wasn't such a bad idea afterall.

But the name clash with BPMN is there. So I would like to hear all options, alternatives and thoughts about this first.

[kukeltje]

First of all, nice reading on signals, messages, events is https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/a08bca18-6188-2a10-9ba6-c9d7bd59f281

For me there is one statement (at least) where I think their scope is to narrow:

Remember, in BPMN a "message" really means any kind of signal from outside, even a phone call or web interaction. The key is that it comes from outside the process.

but in the intro

In BPMN, a signal received from outside the process is called a message, whether it's a SOAP message or a fax, phone call, or paper mail.

No word of a web interaction here, so I agree with the latter, not the former
I'd say from outside the system that facilitates the businessprocess. So more than just the bpms. The webapp is part of this 'system'

Now more concrete

3 is not used by many people I think, so the could be seen as non-existent (not that we do not need it!!). Otoh, it is not that different from 2 and I do not see a conceptual problem with unifying 2 and 3 (maybe there is a techical one).

2 can btw currently influence control flow if you explicitly unlock the token, but since that is also uncommon usage, I'd not give that high priority either

Leaves the unification of 1 and 2/3. One of the key words in 1 is 'external' is it external to the process? or external to the system? For me personally the system is the process(engine) combined with messsaging systems, webapp, java code, scheduler etc, so a message for me really is a businessmessage comming from a real external entity via e.g. ebMS. An incomming message can put some data somewhere and signal (which is then internal) the process. In that case it is not that different from what it currently is, right? We just add the concept of a message