[jbpm-dev] [Design of JBoss jBPM] - introducing process instance ?

[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