Re: [wsbpel] Issue - 123 - Matching <reply> with <receive>

["Yaron Y. Goland" <ygoland@bea.com>]

The proposal says:

     A reply and a receive are said to be compatible with each other if (A)
    the same partner link, port type, and operation are specified for both
    and (B) the correlation sets specified for reply with initiate attribute
    no are all specified for the receive regardless of the value of the
    initiate attribute there.

Why is B required? Even if one isn't using a message exchange it's 
always possible to match up on partnerLink and operation without having 
to match on correlation sets.


Yuzo Fujishima wrote:

> 
> 
> Hi,
> 
> Below is a more detailed version of proposed resolution for Issue 123.
> Because Yaron and Paco don't seem to like messageExchanges element,
> I organized the proposal into four parts.
> 
> Part 1 and 2 are relevant whether we drop messageExchanges element or not.
> Part 3 and 4 are only relevant if we accept messageExchanges element.
> 
> Any comments, including those on wording, are welcome.
> 
> Yuzo Fujishima
> NEC Corporation
> 
> == Proposed Resolution for Issue 123 ==
> 
> [Part 1] Modification to 11.4. Providing Web Service Operations.
> 
> Replace the following part of the 7th paragraph:
> 
>    The correlation between a request and the corresponding reply is based
>    on the constraint that more than one outstanding synchronous request 
> from
>    a specific partner link for a particular portType, operation and
>    correlation set(s) MUST NOT be outstanding simultaneously.
> 
> with:
> 
>    The correlation between a request and the corresponding reply is based
>    either (A) on the message exchange instance specified for the reply and
>    the receive that received the request, or (B) on the constraint that,
>    if a message exchange instance is not specified, more than one
>    outstanding synchronous request from a specific partner link for a
>    particular portType, operation and correlation set(s) MUST NOT be
>    outstanding simultaneously.
> 
> Insert the following after the 7th paragraph:
> 
>    A reply and a receive are said to be compatible with each other if (A)
>    the same partner link, port type, and operation are specified for both
>    and (B) the correlation sets specified for reply with initiate attribute
>    no are all specified for the receive regardless of the value of the
>    initiate attribute there.
> 
>    If the same exchange instance is specified for a reply and a receive,
>    the reply and the receive MUST be compatible with each other. This
>    constraint MUST be checked statically.
> 
>    The matching is performed as follows. If a message exchange instance is
>    specified for a reply, outstanding receives for which the same instance
>    is specified are searched. If a message exchange instance is not
>    specified for the reply, outstanding receives that is compatible with 
> reply
>    and for which the message exchange instance is not specified are 
> searched.
>    If one and only one is found, it is matched to the reply. If none is
>    found, the semantics is undefined. (Addition to Chapter 14: An
>    invalidReply fault must be thrown for an executable process.) If more
>    than one is found, the semantics is undefined. (Addition to Chapter 14:
>    A conflictingRequest fault must be thrown for an executable process.)
> 
> [Part 2] Introduction of the messageExchange attribute.
> 
> <receive messageExchange? ...>
> <onMessage messageExchange? ...>
> <onEvent messageExchange? ...>
> 
> [Part 3] Addition to 11.4. Providing Web Service Operations.
> 
>    A process or a scope can define message exchange instances. When scopes
>    are nested, the inner scope may define a message exchange instance with
>    the same name as in the enclosing scope or process. When this happens,
>    a reference to such instance from an activity matches the innermost
>    instance visible to the activity.
> 
> [Part 4] Introduction of messageExchange/s elements.
> 
> <scope variableAccessSerializable="yes|no" standard-attributes>
>    standard-elements
>    <variables>?
>        ...
>    </variables>
>    <correlationSets>?
>        ...
>    </correlationSets>
> 
>    <mesasgeExchanges>
>      <messageExchange name/>*
>    </mesasgeExchanges>
> 
>    <faultHandlers>?
>        ...
>    </faultHandlers>
>    <compensationHandler>?
>        ...
>    </compensationHandler>
>    <eventHandlers>?
>        ...
>    </eventHandlers>
>    activity
> </scope>
> 
> == End ==
> 
> 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. 
> 
>