[Design of JBoss jBPM] - signal name clash
by tom.baeyens＠jboss.com
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#4193720
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193720
15 years, 11 months
[Design of JBoss jBPM] - task updates
by tom.baeyens＠jboss.com
hi alejandro,
i've done some work to refactor the task component:
1) i've unified the resource loading of wire bindings and other resources in task component as i did previously in pvm and other components (nothing to worry about)
2) i've extracted variables and timers from pvm ExecutionImpl into a new ScopeInstanceImpl class. Now ExecutionImpl and TaskImpl both inherit from ScopeInstanceImpl. That way the strategy to deal with variables and timers is unified/leveraged between executions and tasks.
The clue will be to map the variables and timers in the task entity with a join-table.
In case the task component is not used, that means that the task mappings are not included. That should not change the schema of the PVM tables. Suppose that you would map the variables and timers related to a task without a join-table, then this would result in an extra column in the JBPM_VARIABLE and JBPM_JOB tables. That column would disappear in case the task mappings are not present.
So all of this is to make sure that the PVM schema remains as is when we add/remove optional components like the task component.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193693#4193693
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193693
15 years, 11 months
[Design of JBoss jBPM] - Re: Task Management component?
by aapthorp
Tom,
The original concept started out as you suggest:
- an action handler to send iCalendar / iTip / iMip notifications to a user via e-mail
- message bean yp handle iTip assignment confirmations / declines returned via e-mail.
- http retrieval of tasks in iCalendar format
and then developed further as I experimented with CalDav and CalDav sched:
- retrieval of task entries via CalDav
- accept / decline / complete / update tasks via CalDav
- creation of ad-hoc tasks via CalDav
- view actor free / busy via CalDav
Apart from the currently limited VTODO (task support) in some clients the potential for extending PIM type apps based on standards for Human Task management is evident (have you come across HumanEdj?). The main limitation is task specific variables and rendering, although I have a few ideas on how to address this e.g. Xforms, XUL extensions. Currently a link to access the task instance via the JBPM console is provided, and for simple tasks the user can signal completion from the calendar client.
As much as possible I've limited the integration to layering the iCalendar model over the JBPM task model and exposing this via e-mail, CalDav and HTTP .ics. The questions I outlined are a result of mismatches between the two models. I've also had initial discussions with CalConnect on limitations in the current iCalendar standards for this purpose.
Hope this answers...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4193550#4193550
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4193550
15 years, 11 months