[Design of JBoss jBPM] - Re: introducing process instance ?
by tom.baeyens＠jboss.com
"jbarrez" wrote : But I don't agree that the ProcessInstance should be an interface.
| Why not make it an extension of the ExecutionImpl? After all, the ProcessInstance is just another name of a very specific execution (ie the root execution). You could add some specifc stuff to the process instance (eg business key? as it was in jbpm3 or getAllWaitStates())
|
the ProcessInstance interface that I propose is in the api.
i can't make the same distinction in the implementation classes. but the api user will not notice that.
suppose that we have
class ProcessInstanceImpl extends ExecutionImpl {
| ...
| }
in the implementation. And then suppose that jPDL wants to add a property to all executions... then you end up in multiple inheritence.
and besides, i think it is best that all executions (incl process instances) are stored in only 1 single table.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225852#4225852
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225852
17 years
[Design of JBoss jBPM] - Re: introducing process instance ?
by jbarrez
Tom,
I agree that it makes the executionService more user-friendly.
After all, when you signal an execution and he forks in 5 paths, the following 5 waitstates should be returned to make the code more easier to understand.
The only alternative for the ProcessInstance I'm seeing is a Set/Map/... of curent wait states of the 'root execution'. (or return nothing and let the user make a query ... but then we're back at jbpm 3, which was flawed in that perspective)
But I don't agree that the ProcessInstance should be an interface.
Why not make it an extension of the ExecutionImpl? After all, the ProcessInstance is just another name of a very specific execution (ie the root execution). You could add some specifc stuff to the process instance (eg business key? as it was in jbpm3 or getAllWaitStates())
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225824#4225824
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225824
17 years
[Design of JBoss jBPM] - Re: schema for mail template and activity
by tom.baeyens＠jboss.com
"alex.guizar(a)jboss.com" wrote : Examples cannot be produced at this point because the syntax and the design have not been agreed upon.
|
i'm pushing for examples in the example test code exactly because that improves the discussion on the syntax. you work out examples from simple to complex. then we can review.
"alex.guizar(a)jboss.com" wrote : Unlike other activities email has more complex setup and more moving parts. Let us focus on making the design decisions first.
|
ok. but i think that should be trivial :-)
"alex.guizar(a)jboss.com" wrote : There are two concepts in play.
| * mail template describes the contents of an email
| * mail producer takes a template as input and produces a template as output
|
i think that is already too complex. this is splitting up our implementation to introduce some kind of user pluggability in the middle of our implementation.
check out my alternative MailSession:
interface MailSession {
| Mail createMail();
| Mail createMail(String templateName);
| }
|
| interface Mail {
| Mail setTo(String to);
| Mail setCC(String cc);
| Mail setBCC(String bcc);
| Mail setSubject(String subject);
| Mail setBody(String subject);
| Mail addAttachment(String name, InputStream attachment, String mimeType);
|
| void send();
| }
building that implementation should be the basis. this exposes all the functionality that we want to build on top of JavaMail. this implementation can be leveraged by 1) our mail activity and event-listener 2) task notify and reminder 3) users that want to build custom mail activities programatically.
i don't think it needs to be more complex then that.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225802#4225802
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225802
17 years
[Design of JBoss jBPM] - introducing process instance ?
by tom.baeyens＠jboss.com
i'm thinking to introduce ProcessInstance:
interface ProcessInstance extends Execution {
| }
|
advantage is that with this interface we can indicate more precisely what the ExecutionService methods are returning: a real ProcessInstance (one execution of a full process) or an Execution (one path of execution in a process instance)
sidenote: in the PVM implementation class, we cannot make that distinction. cause if concrete process languages like jPDL want to introduce JpdlProcessInstance as a concrete subclass, that would lead to multiple inheritence.
disadvantage is that the ProcessInstance interface doesn't contain any extra methods. that might be strange. but i don't think it will cause confusion. and it will reduce the confusion in understanding the ExecutionService
public interface ExecutionService {
|
| ProcessInstance startProcessInstanceById(String processDefinitionId);
|
| ProcessInstance startProcessInstanceById(String processDefinitionId, String processInstanceKey);
|
| ProcessInstance startProcessInstanceById(String processDefinitionId, Map<String, Object> variables);
|
| ProcessInstance startProcessInstanceById(String processDefinitionId, Map<String, Object> variables, String processInstanceKey);
|
| ProcessInstance startProcessInstanceByKey(String processDefinitionKey);
|
| ProcessInstance startProcessInstanceByKey(String processDefinitionKey, String processInstanceKey);
|
| ProcessInstance startProcessInstanceByKey(String processDefinitionKey, Map<String, Object> variables);
|
| ProcessInstance startProcessInstanceByKey(String processDefinitionKey, Map<String, Object> variables, String processInstanceKey);
|
| Execution findExecutionById(String executionId);
|
| List<Execution> findExecutionsById(String processDefinitionId);
|
| ProcessInstance signalExecutionById(String executionId);
|
| ProcessInstance signalExecutionById(String executionId, String signalName);
|
| ProcessInstance signalExecutionById(String executionId, String signalName, Map<String, Object> parameters);
|
| ProcessInstance signalExecutionById(String executionId, Map<String, Object> parameters);
|
|
| ExecutionQuery createExecutionQuery();
|
| ExecutionQuery createProcessInstanceQuery();
|
| void setVariable(String executionId, String name, Object value);
|
| void setVariables(String executionId, Map<String, Object> variables);
|
| Object getVariable(String executionId, String variableName);
|
| Set<String> getVariableNames(String executionId);
|
| Map<String, Object> getVariables(String executionId, Set<String> variableNames);
|
| void endProcessInstance(String processInstanceId, String state);
|
| void deleteProcessInstance(String processInstanceId);
| }
|
i also think that the return value for signal should be the process instance and not the execution on which the signal occurs. that will force users to use the right way of getting the executionId's that are in a wait state. in the context of timers, each activity is potentially a scope, resulting in a child-execution and hence you cannot assume that it is the same execution that will be waiting in the wait state. that is why users will have to do something like this in case of a wait state:
Execution processInstance = executionService.startProcessInstanceByKey("TimerTransition");
|
| String executionId = processInstance.findActiveExecutionIn("guardedWait").getId();
|
| executionService.signalExecutionById(executionId, "go on");
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225801#4225801
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225801
17 years
[Design of JBoss jBPM] - Re: schema for mail template and activity
by alex.guizar＠jboss.com
Examples cannot be produced at this point because the syntax and the design have not been agreed upon. Unlike other activities email has more complex setup and more moving parts. Let us focus on making the design decisions first.
There are two concepts in play.
* mail template describes the contents of an email
* mail producer takes a template as input and produces a template as output
In Brad's current model, the above concepts are treated as two parts of the same thing. The mail activity configuration is read into the fields of the mail producer, and the produce(Execution) method reads those fields to create an email.
public interface MailProducer {
| Email produce(Execution);
| }
In my alternate proposal, the template is a separate entity object that represents the configuration. The template is passed to the producer to create an email. The producer thus becomes a control object: it appears to be stateless from the outside.
public interface MailProducer {
| Email produce(Execution, MailTemplate);
| }
In my current conception, MailTemplate is a concrete class, as emails have a standard-defined structure. The extension points are narrowed to the producer itself.
As soon as we decide on a design, we can jump to work out examples.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225770#4225770
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4225770
17 years
