RE: [wsbpel] Issue - 74 - Ambiguity in join condition definition

["Frank Leymann" <LEY1@de.ibm.com>]

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.