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 - 74 - Ambiguity in join condition definition


Agreed. I like to think of there being two conditions that need to 
satisfied before an activity can be started: structural, and join. The 
latter only applies if the activity's incoming link set is not empty. 
The former must be satisfied before the latter is (if necessary) then 
considered.

 From an implementation point of view, this can be regarded as a couple 
of internal states that precede the actual "started" state for an 
activity. If there are no incoming links for the activity, we can skip 
the second preceding state and go directly to the "started" state 
(substitute whatever terminology you are comfortable with for the state 
names. BPEL shouldn't get into the business of dictating implementation 
terminology! :-)

-Ron

Frank Leymann wrote:

>The issue is that there is a clear distinction between what is called a
>"join condition" and a "start condition". The latter is not addressed in
>BPEL at all.
>
>The purpose of a join condition is to "join", i.e. synch-up threads of work
>that are going on in parallel. The purpose of a start condition is to
>specify under which conditions (causal, temporal,...) an activity that is
>known to be ready to be performed will actually be performed.
>
>If there is nothing to join or sync-up, a join condition doesn't make sense
>at all. Thus, we should not introduce an artificial join condition for
>activities without incoming edges (even if this condition would so trivial
>to handle than a constant TRUE condition).
>
>Regards,
>Frank
>
>-------------------
>Prof. Dr. Frank Leymann, Distinguished Engineer
>IBM Software Group
>Member, IBM Academy of Technology
>
>Phone 1:  +49-7031-16 39 98
>Phone 2:  +49-7056-96 50 67
>Mobile:  +49-172-731 5858
>--------------------
>
>
>
>
>
>Please respond to <ygoland@bea.com>
>
>To:    Frank Leymann/Germany/IBM@IBMDE, <wsbpel@lists.oasis-open.org>
>cc:
>Subject:    RE: [wsbpel] Issue - 74 - Ambiguity in join condition
>       definition
>
>
>There are two cases where an activity does not have any incoming links:
>
>Case 1 - No Join Condition is Explicitly Defined - This is a hole. The spec
>requires that the join condition be equal to the OR join of the incoming
>links but there are no incoming links so what does it mean to have an OR
>join of nothing? Tri-state logic being more than I want to deal with I
>suspect a quick sentence of the form "in the case where an explicit join
>condition is not defined and the activity does not have any incoming links
>the value of the join condition is set to true."
>
>Case 2 - A Join Condition is Explicitly Defined - In this case the only
>function that can be called is getLinkStatus and that can only be called on
>links that have the activity as their target. By definition of this
>scenario
>there is no such link therefore any call to getLinkStatus will produce a
>static analysis error (we need to add this to the static analysis error
>list). Therefore the only contents of the Join Condition can be various
>types of fancy Boolean nonsense all based on playing around with True and
>False. While silly, it isn't harmful.
>
>Therefore I would propose that we pretend that join conditions exist on all
>activities, independent of having any links pointing at them. In the case
>where there are no links and no explicitly defined join condition we just
>a-priori define the join condition to be true. All other cases seem to take
>care of themselves.
>
>             Just a thought,
>
>                         Yaron
>
>  
>
>>-----Original Message-----
>>From: Frank Leymann [mailto:LEY1@de.ibm.com]
>>Sent: Tuesday, October 21, 2003 12:50 AM
>>To: wsbpel@lists.oasis-open.org
>>Subject: RE: [wsbpel] Issue - 74 - Ambiguity in join condition
>>definition
>>
>>
>>
>>The current spec says:
>>
>>"If the explicit joinCondition is missing, the implicit
>>condition requires
>>the status of at least one incoming link to be positive..."
>>
>>I.e. if you don't specify any explicit join condition the implicit
>>condition is the ORing of the truth values of the incoming links.
>>
>>Furthermore, the current spec says that
>>
>>"The expression for a join condition for an activity MUST be
>>constructed
>>using only Boolean operators and the bpws:getLinkStatus function (see
>>Expressions) applied to incoming links at the activity"
>>
>>I.e. it is NOT possible to spec join conditions that refer to other
>>functions than getLinkStatus.
>>
>>To avoid "mathematical subtleties" that can blow your mind (statements
>>about the empty set...), we need an explicit clarification
>>for situations
>>where there are no incoming links at all.
>>
>>Regards,
>>Frank
>>
>>--------------------
>>
>>
>>
>>
>>
>>Please respond to <ygoland@bea.com>
>>
>>To:    <wsbpel@lists.oasis-open.org>
>>cc:
>>Subject:    RE: [wsbpel] Issue - 74 - Ambiguity in join condition
>>       definition
>>
>>
>>What is harmed if we allow join conditions on activities that
>>don't have
>>links? Isn't it already possible to write a join condition
>>that doesn't
>>refer to any form of link state in calculating its Boolean output?
>>    Just Curious,
>>        Yaron
>> -----Original Message-----
>> From: ws-bpel issues list editor
>>    
>>
>[mailto:peter.furniss@choreology.com]
> Sent: Thursday, October 09, 2003 2:59 PM
> To: wsbpel@lists.oasis-open.org
> Subject: [wsbpel] Issue - 74 - Ambiguity in join condition definition
>
>
>
> This issue has been added to the wsbpel issue list. The issues list is
> posted as a Technical Committee document to the OASIS WSBPEL TC pages on a
> regular basis. The current edition, as a TC document, is the most recent
> document with the title in the "Issues" folder of the WSBPEL TC document
> list - the next posting will include this issue. The list editor's working
> copy, which will normally include an issue when it is announced, is
> available at this constant URL.
> Issue - 74 - Ambiguity in join condition definition
>
>
> Status: open
> Date added: 9 Oct 2003
> Submitter: Dieter Roller
> Date submitted: 09 October 2003
> Description: The specs could possibly be interpreted in such a way that
> activities without an incoming link could also have a join condition. This
> is not the intended meaning.
> Submitter's proposal: Modify the first sentence in the second paragraph in
> section 12.5.1 as follows :
>       Every activity that is the target of a link has an implicit or
>       explicit joinCondition attribute associated with it; an activity
>       that is not target of a link has no joinCondition attribute
>       associated with it.
> Furthermore it may be helpful to have a similar sentence earlier in the
> document.
> Changes: 9 Oct 2003 - new issue
>
>
>
> To comment on this issue, please follow-up to this announcement on the
> wsbpel@lists.oasis-open.org list (replying to this message should
> automatically send your message to that list), or ensure the subject line
> as you send it starts "Issue - 74 - [anything]" or is a reply to such a
> message.
>
>
> To add a new issue, see the issues procedures document (but the address
> for new issue submission is the sender of this announcement).
>
>
> 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
> .
>
>
>
>
>
>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.
>
>
>
>
>
>
>
>
>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]