Workflow Management Facility Avatar
  1. OMG Specification

Workflow Management Facility — Open Issues

  • Acronym: WfMF
  • Issues Count: 9
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Contradictory WFR

  • Key: WFMF14-1
  • Legacy Issue Number: 4220
  • Status: open  
  • Source: Anonymous
  • Summary:

    I think there is a coherence issue between the WFR 5 and 6 on Transition meta-class:
    [5] Transitions outgoing pseudostates may not have a trigger
    and
    [6] An inital transition at the topmost level either has no trigger or it has trigger with the stereotype "create".

    Initial transition is a specific case of transition outgoing a pseudostate. The WFR [6] puts then the WFR [5] in the wrong.

    I propose then to have a single WFR and the following rewriting:

    [5] The transition outgoing the initial pseudostate of statemachine root state either has no trigger or it has trigger with the stereotype "create". In all other case, transitions outgoing pseudostates may not have a trigger.

    Yours,

    Sébastien Gérard.

  • Reported: WfMF 1.3 — Mon, 12 Mar 2001 05:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

WfRequeste and WfActivity inheritance - The Phanton Menace

  • Key: WFMF11-4
  • Legacy Issue Number: 2975
  • Status: open  
  • Source: Anonymous
  • Summary:

    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

  • Reported: WfMF 1.1 — Mon, 1 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Problem with resolution of issue 2041

  • Key: WFMF11-6
  • Legacy Issue Number: 3264
  • Status: open  
  • Source: Hewlett-Packard ( Dan Matheson)
  • Summary:

    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?

  • Reported: WfMF 1.1 — Mon, 31 Jan 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

The UML diagram from the 1.2 version needs changes

  • Key: WFMF11-5
  • Legacy Issue Number: 3240
  • Status: open  
  • Source: Hewlett-Packard ( Dan Matheson)
  • Summary:

    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).

  • Reported: WfMF 1.1 — Wed, 19 Jan 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Make the association between WfRequester and WfProcess optional

  • Key: WFMF11-1
  • Legacy Issue Number: 2065
  • Status: open  
  • Source: Anonymous
  • Summary:

    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).

  • Reported: WfMF 1.1 — Thu, 8 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Transition from open state to closed.

  • Key: WFMF11-8
  • Legacy Issue Number: 3266
  • Status: open  
  • Source: Hitachi ( Toshiaki Sakaguchi)
  • Summary:

    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.

  • Reported: WfMF 1.1 — Tue, 1 Feb 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

${issue.summary}

  • Key: WFMF11-3
  • Legacy Issue Number: 2110
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: WfMF 1.1 — Mon, 19 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

With respect to WfExecutionObject and WfEventAudit

  • Key: WFMF11-2
  • Legacy Issue Number: 2100
  • Status: open  
  • Source: Anonymous
  • Summary:

    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 ?

  • Reported: WfMF 1.1 — Mon, 19 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Issue with the UML diagram from the 1.2 version

  • Key: WFMF11-7
  • Legacy Issue Number: 3265
  • Status: open  
  • Source: Hewlett-Packard ( Dan Matheson)
  • Summary:

    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).

  • Reported: WfMF 1.1 — Mon, 31 Jan 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT