[jbpm-dev] [Design of JBoss jBPM] - introducing process instance ?
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#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...