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

[Yuzo Fujishima <fujishima@bc.jp.nec.com>]

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 ==