OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue 81 - Proposal For Vote



Hi, Yaron,

After doing the HW on this particular proposal, I guess we may need to add some more wordings to avoid ambiguity.

Consider this example:
<flow>
    <receive ... createInstance="yes" />
    <assign ... />
</flow>

The summary of the issue said : "Explicitly require that initial activities be start activities."

However, the only relevant text in the proposal that I found is:
To:
A receive/pick activity annotated in this way MUST be a "start activity". A "start activity" is a receive/pick activity that is marked with a createInstance="yes" attribute where no other activities but scope, flow, sequence or empty activities occur before it in the execution path rooted at the process element.

Technically, the <assign> is NOT before the <receive> in either activity ancestor chain sense or document ordering sense. The term "execution path" may be a bit not-so-well-defined also. Hence, I would like to make the text clearer (by mixing in some of old text) as follows:

From:
A
receive activity annotated in this way MUST be an initial activity in the process, that is, the only other basic activities may potentially be performed prior to or simultaneously with such a receive activity MUST be similarly annotated receive activities.

To (Version-2):
A "start activity" is a receive/pick activity that is annotated with a createInstance="yes" attribute. NO other "non-start activities" but scope, flow, sequence or empty activities may potentially be performed prior to or simultaneously with a "start activity". The logical order of performing activities is determined by static analysis. 

It would be nice, if we can actually include some examples like the following to illustrate what we mean in the spec:

That is making the following illegal:
<flow>
    <receive ... createInstance="yes" />
    <assign ... />
</flow>


And, making the following legal:
<flow>
    <links>
        <link name="RecvToAssign"/>
    </links>
    <sequence>
          <receive ... createInstance="yes">
                <sources> <source linkName="RecvToAssign" />  <sources>
          </receive>
          ...
    </sequence>
    <sequence>
          <assign>
                <targets> <target linkName="RecvToAssign" /> </targets>
                ...
          </assign>
    </sequence>
</flow>

         


Thanks!



Regards,
Alex Yiu



Yaron Y. Goland wrote:
Summary: Explicitly require that initial activities be start activities.

Section 6.5

Change: To be instantiated, each business process must contain at least
one such "start activity." This must be an initial activity in the sense
that there is no basic activity that logically precedes it in the
behavior of the process.

To: To be instantiated, each business process must contain at least one
such "start activity." That is, a receive/pick activity annotated with a
createInstance="yes" attribute. See section 11.4 for more details on
start activities.

Change: If exactly one start activity is expected to instantiate the
process, the use of correlation sets is unconstrained.

To: If a process contains exactly one start activity then the use of
correlation sets is unconstrained.

Section 11.4

Change: A receive activity annotated in this way MUST be an initial
activity in the process, that is, the only other basic activities may
potentially be performed prior to or simultaneously with such a receive
activity MUST be similarly annotated receive activities.

To: A receive/pick activity annotated in this way MUST be a "start
activity". A "start activity" is a receive/pick activity that is marked with a createInstance="yes" attribute where no other activities but scope, flow, sequence or empty activities occur before it in the execution path rooted at the process element.

Change: It is permissible to have the createInstance attribute set
to"yes" for a set of concurrent initial activities.

To: It is permissible to have multiple start activities. As specified in
section 6.5 the initial start activity must complete execution before
any other start activities are allowed to execute.

Change: All such receive activities MUST use the same correlation sets
(see Correlation).

To: If a process has multiple start activities then all the start
activities MUST use the same correlation sets and the pattern for all
the correlation sets MUST be sent to "rendezvous" (see Correlation).


To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]