Re: [wsbpel] Issue - 123 - Proposal to Vote

[Francisco Curbera <curbera@us.ibm.com>]

That is not how I read Alex' text. I think what he means to say is that in
addition to the pLink/portType/operation/ values one can encode the
messageExchange attribute to disambiguate the match between receives and
replies, as required. Not that you would introduce a new partner link to do
so.

Partner links have certain semantics associated with them after all, since
they represent conversations between two services; the partner link
structure of a process tells you a lot about its compositional structure
and its interactions with other applications. IMO using the construct to
disambiguate between conflicting receives would be an abuse of the original
semantics of partner link concept.

Paco




                                                                                                                                        
                      "Yaron Y. Goland"                                                                                                 
                      <ygoland@bea.com>        To:       Alex Yiu <alex.yiu@ORACLE.COM>                                                 
                                               cc:       Yuzo Fujishima <fujishima@bc.jp.nec.com>, wsbpel@lists.oasis-open.org          
                      09/10/2004 04:02         Subject:  [wsbpel] Issue - 123 - Proposal to Vote                                        
                      PM                                                                                                                
                      Please respond to                                                                                                 
                      ygoland                                                                                                           
                                                                                                                                        




I propose that we close issue 123 with no action.

The logic for this proposal is that anytime there is a conflict between
receives it can be resolved by introducing new partnerLinks. Hence we
can resolve the problem without having to add any features to the spec.

             Thanks,

                         Yaron

Alex Yiu wrote:

>
> -----------------------------------------------------
> A reply activity is associated with a receive activity based on the
> tuple - partnerLink, operation, and messageExchange. The value defined
> in messageExchange is scoped to the combination of partnerLink and
> operation. That is, it is legal to use the same messageExchange value in
> multiple simultaneously incomplete receive activities so long as the
> combination of partnerLink and operation on the receives are all
> different from each other. An incomplete receive describes the state of
> a BPEL process from the point that a request/response receive activity
> starts execution until its associated reply begins execution.
>
> If there should ever be multiple simultaneous incomplete receive
> activities which have the same partnerLink, operation and
> messageExchange tuple then the *bpws:conflictingRequest* fault MUST be
> thrown within the BPEL process on the conflicting receive activities
> subsequent to the execution of *the successful *incomplete receive .
>
> If a reply activity cannot be associated with an incomplete receive
> activity by matching the tuples and this error situation is not caught
> during static analysis,  then *bpws:missingRequest* fault MUST be thrown
> within the BPEL process on the reply activity. Because conflicting
> requests should have been rejected at the time <receive> is executed,
> there cannot be more than one corresponding <receive> at the time
> <reply> is executed.
>
> If the messageExchange attribute is not specified on a receive then its
> value is taken to be empty. For matching purposes two empty
> messageExchange values on receives with the same partnerLink and
> operation values are said to match. Empty value does not match with
> other non-empty values.
>
> (Please note: there are existing text paragraphs in the spec, which
> enforces that no more than one <receive>s are waiting for a message
> associated with the same partner link, port type, operation, and
> correlation sets. This constraint still exists and will not be affected
> by the proposal of Issue 123. This proposal simply add one more
> constraint to receive, when <reply> are needed to be associated with
> <receive>.)
> -----------------------------------------------------
>

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
.