Issues for Workflow RTF

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 2065: Make the association between WfRequester and WfProcess optional
Issue 2100: With respect to WfExecutionObject and WfEventAudit
Issue 2110:
Issue 2975: WfRequeste and WfActivity inheritance - The Phanton Menace
Issue 3240: The UML diagram from the 1.2 version needs changes
Issue 3264: Problem with resolution of issue 2041
Issue 3265: Issue with the UML diagram from the 1.2 version
Issue 3266: Transition from open state to closed.

Issue 2065: Make the association between WfRequester and WfProcess optional (wf-rtf)

Summary: Section 2.6.3 and the object model in Figure 2-1 state that there must be a
 WfRequester associated with each WfProcess. Registering a Requester is useful
 in scenarios where some entity is actually waiting for the process to complete.
 There are several scenarios where this is not the case;  for example when a
 process is started in a chained sub-process scenario or when a process is
 primarily started because of its "side-effects" (achieved by its Activities) ,
 not to retrieve its results. In this case the status queries provided by
 WfProcess are sufficient to allow an administrator to observe the WfProcess.
 Making Requester mandatory implies that someone must keep a persistent object
 around for a potentially long time even when there is no real use for it.
 
 I propose to make the association between WfRequester and WfProcess optional
 (i.e., cardinality of "requester" would be 0..1 instead of 1).
 

Resolution:
Change cardinality of requester to 0..1 and add an exception to create_WfProcess of RequesterRequired.

Summary: With respect to WfExecutionObject and WfEventAudit I am wondering if there
 has been any consideration for loops in a workflow.
 
 E.g. Would it be possible for the same WfExecutionObject to be executed
 twice because there was a rework loop in the process definition ?
 
 How would this impact the state diagram for WfExecutionObject ? There does
 not appear to be any way to move "back" from closed to open.
 How would this be handled by the WfEventAudit records ?
 

	Thanks for your consideration in discussing with me an importante topic. I think that you are one of the few persons that are fighting to put this facility in the reality plan. And I would like to still discuss these topics with you in the future.
	I think that the goal of the WMF DTF is to define a standard that could be possible the componentization and interoperability of a workflow management system. We also know that only the definition of the interfaces (syntactic interoperability) is not enough to the componentization. It is also needed to define the semantic of this interfaces at formal level (and sometimes is also needed to specify non-functional requirements as part of the contract but this is a future problem). The last is very dificult to be achieved but is needed to create an open standard.
	But as a scientist I will to disagree with some points about your arguments in order to justify the stripping of the inheritance relationship between a WfActivity and a WfRequester. I think that you like to be a kind of Object-Oriented Jake Stripper :-)

The UML diagram from the 1.2 version shows the aggregation
between WfProcess and WfActivity and the aggregation between
WfActivity and WfAssignment as aggregations with unidirectional
navigability (open diamond).  These two aggregations should be
of typ[e composite aggregation with bidirectional navigability
(filled-in diamond).

I found that the resolution text of issue 2041 had a problem.

In the text the following operation is added to WfExecutionObject interface.

    boolean is_member_of_history(in WfExecutionObject member)
raises(WfBase::BaseException);

I think the argument "WfExecutionObject member" is strange because the
operation is named as "member of history".

Is it WfEventAudit ?

If it is WfEventAudit do we have to raise a RTF issue?

The UML diagram from the 1.2 version shows the aggregation
between WfProcess and WfActivity and the aggregation between
WfActivity and WfAssignment as aggregations with unidirectional
navigability (open diamond).  These two aggregations should be
of typ[e composite aggregation with bidirectional navigability
(filled-in diamond).

  The spec says in section 2.4.5 that the state of WfExecutionObject can be
set to closed.{terminated, aborted} state only from open.running state. It
is inconvenient when the user makes WfProcess or WfActivity but wants to
remove the object for some reasons. (For example, the object is created by
mistake, the object cannot be started, etc.) We have to start the object to
terminate it, and if it cannot be started also, we cannot set its state to
closed state.
  While Figure 2-2 appears to suggest the state change from any open state
to any closed state are possible. The transition to closed.completed state
should only be from open.running state and it should be distinguished
from closed.{terminated,aborted} state.

Resolution:
  Add the transition from open.not_running.not_started to
closed.{terminated, aborted} state.
  Correct Figure 2-2 so that we can clearly understand the transition to
closed.completed state is permitted only from open.running state.