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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193720#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...