Re: [wsbpel] Issue 123 - Proposal to Vote - Where to declare messageExchanges?

Hi Chris,

Chris Keller wrote:
> Hi Yuzo,
> 
> I can't think of a compelling use case for replying to a receive inside of
> an onEvent handler which was received outside the onEvent.  However what you
> suggest has other ramifications.  For example if you change a partnerLink
> inside of an onEvent (via a copy operation) then the modification is not
> visible outside the onEvent.  There is a surprise factor associated with

Ah, I see. My idea prohibits, for example, assigning a new endpoint 
reference to a partner link as a reaction to an event. It seems bad.

> that behavior that I worry about. Is there a clean way to describe the
> partnerLink copy as just messageExchange oriented?
> 
> * "A partner link has a default message exchange whose name is empty"
> * "Each onEvent instance and each PFE branches has its own copy of the
> messageExchanges of partner links referenced within the instance"

If a partner link and a message exchange associated with it have
different lifetime and/or scope, then it seems to be natural to
separately declare them. At this moment, I feel like withdrawing
my idea.

Yuzo Fujishima
NEC Corpoation

> 
> - Chris
> 
> -----Original Message-----
> From: Yuzo Fujishima [mailto:] 
> Sent: Tuesday, December 06, 2005 9:19 PM
> To: 
> Cc: 'ws bpel tc'
> Subject: Re: [wsbpel] Issue 123 - Proposal to Vote - Where to declare
> messageExchanges?
> 
> Chris,
> 
> Thank you for the response.
> 
> Chris Keller wrote:
> 
>>Hi Yuzo,
>>
>>Interesting suggestion and actually Satish had at one point suggested this
>>option.  It isn't the direction the TC agreed on at the last f2f and would
>>need some discussion before writing up. In addition on the last conference
>>call we talked about a "default message exchange" being provided by the
>>process, onEvent and pfe (parallel for each) contexts in order to minimize
>>the frequency which users need to describe a message exchange.  If a
> 
> message
> 
>>exchange is provided by the partnerLink I am not sure that this would
> 
> work.
> 
>>Any thoughts on that?
> 
> 
> How about the following:
> * "Each of onEvent instances or each of PFE branches has its
>   own copy of the partner link referenced", and
> * "A partner link has a default message exchange whose name is empty"
> 
> The above seems OK for PFE. But maybe not for onEvent.
> How often a response must be sent from within an onEvent
> where the corresponding request is received outside of the onEvent?
> Do we have a compelling use case?
> 
> Yuzo Fujishima
> NEC Corporation
> 
> 
>>- Chris
>>
>>
>>-----Original Message-----
>>From: Yuzo Fujishima [mailto:] 
>>Sent: Thursday, December 01, 2005 11:44 PM
>>To: ws bpel tc
>>Subject: Re: [wsbpel] Issue 123 - Proposal to Vote - Where to declare
>>messageExchanges?
>>
>>Hi,
>>
>>I have a comment regarding the location of the messageExchanges
>>declaration.
>>
>>In my opinion, a messageExchange is an extension to a partner link;
>>to distinguish conversations occurring within a partner link.
>>Therefore, I think it is reasonable to declare mesageExchanges
>>within a declaration of a partner link.
>>
>>Let me explain by example.
>>
>>I do NOT like either of the following:
>>
>>[Example 1]
>>scope S1
>>  partnerLink P1
>>  sequence
>>    scope S2
>>      sequence
>>        scope S3
>>          messageExchange M1 // <= *Attention*
>>          receive V1 partnerLink=P1 messageExchange=M1
>>        scope S4
>>          messageExchange M1 // <= *Attention*
>>          reply R1   partnerLink=P1 messageExchange=M1
>>    scope S5
>>      ...
>>
>>
>>[Example 2]
>>scope S1
>>  partnerLink P1
>>  sequence
>>    scope S2
>>      messageExchange M1 // <= *Attention*
>>      sequence
>>        scope S3
>>          receive V1 partnerLink=P1 messageExchange=M1
>>        scope S4
>>          reply R1   partnerLink=P1 messageExchange=M1
>>    scope S5
>>      messageExchange M1 // <= *Attention*
>>      ...
>>
>>Example 1 is invalid. The problem should not happen
>>in the first place.
>>
>>Example 2 is, in my opinion, confusing.
>>
>>I like the following better:
>>    
>>[Example 2]
>>scope S1
>>  partnerLink P1
>>    messageExchange M1 // for use in S3
>>    messageExchange M2 // for use in S5 (Or just reuse M1 above)
>>  sequence
>>    scope S2
>>      sequence
>>        scope S3
>>          receive V1 partnerLink=P1 messageExchange=M1
>>        scope S4
>>          reply R1   partnerLink=P1 messageExchange=M1
>>    scope S5
>>      ...
>>
>>More concretely, I would propose the following schema:
>><scope or process>
>>  ...
>>  <partnerLinks>?
>>    <partnerLink ...>+
>>      <messageExchanges>?
>>        <messageExchange name="ncname"/>+
>>      </messageExchanges>
>>    </partnerLink>
>>  </partnerLinks>
>>
>>This will also simplify the condition when a missingReply will be raised:
>>just when the partner link in use goes out-of-scope. We don't
>>need to talk about the message exchange.
>>
>>Yuzo Fujishima
>>NEC Corporation
>>
>>Danny van der Rijn wrote:
>>
>>
>>> Alexandre -
>>>
>>>It is my intention that DMD would NOT be applicable to scope, as that 
>>>would be too confusing, IMO.  Apologies that I was not clear on that 
>>>point in this mail. (I think I was more clear elsewhere in the mail 
>>>thread, though.)
>>>
>>>Danny
>>>
>>>
>>>Alexandre Alves wrote:
>>>
>>>
>>>>Hi Danny,
>>>>
>>>>
>>>>
>>>>Specify that an IMA that does not specify a messageExchange resolves 
>>>>to a "default messageExchange declaration (DMD)."  (This is a howler 
>>>>of a name, and needs to be changed)  In this way, not specifying a 
>>>>messageExchange in an onEvent resolves replies to the onEvent, as most 
>>>>users would expect.  DMDs can be thought of as present on each onEvent 
>>>>whether they are "used" or not.
>>>>
>>>>
>>>>
>>>>Regarding option [2], it was not very clear to me if the DMD would 
>>>>also be applicable to scope, or do you envision it only on onEvent 
>>>>(and possibly on process)? I guess the same rationality you presented 
>>>>for the process is true for scope - consistency.
>>>>
>>>>
>>>>
>>>>Rgds,
>>>>
>>>>
>>>>
>>>>* From: * Danny van der Rijn [mailto:]
>>>>*Sent:* Wednesday, November 09, 2005 3:36 PM
>>>>*To:* ' ws bpel tc '
>>>>*Subject:* Re: [wsbpel] Issue 123 - Proposal to Vote
>>>>
>>>>
>>>>
>>>>As we discussed on the call today, here are some thoughts on this 
>>>>issue that are swimming around it my head.  (I wish they would respect 
>>>>the swimlanes, and stop crashing into each other).
>>>>
>>>>An example (in extremely abbreviated syntax) of a problem that we 
>>>>haven't worked out yet:
>>>>
>>>><scope>
>>>>   <partnerlink name="pl"/>
>>>>   <eventHandler partnerLink="pl" operation="op">
>>>></scope>
>>>>
>>>>"op" is a request-reply operation.
>>>>To note:  no partnerLink or messageExchange is declared on the 
>>>>eventHandler associated scope.
>>>>
>>>>Timeline:
>>>>Time 1: The eventHandler receives a message.  For reply-resolution 
>>>>purposes, its identifying triple is {pl, op, null}
>>>>Time 2:  No reply to the above triple has occurred, and another 
>>>>messages comes in on partnerLink pl and op.  If it were to be 
>>>>received, its triple would be {pl, op, null}.  Thus a 
>>>>conflictingReceive should be thrown.  At least it would be reasonable 
>>>>to infer that from the current spec (with or without 123?)
>>>>
>>>>I see 2 ways of solving this:
>>>>
>>>>Option* [1]*
>>>>Rationale:  Makes writing the spec easier.
>>>>
>>>>*[A] *Require that onEvent either define at least one of partnerLink, 
>>>>messageExchange locally.
>>>>- or -
>>>>*[B]* Specify that in the case that an onEvent does not specify a 
>>>>local partnerLink or messageExchange, the onEvent can not run 
>>>>concurrently with itself.  Either the messages must be queued, or 
>>>>conflictingReceive will be thrown any time a message is received on a 
>>>>request/reply operation for an onEvent that has an outstanding request.
>>>>
>>>>I do not favor Option [1].
>>>>
>>>>Option *[2]
>>>>*Rationale:  messageExchange should be reserved for the 20% (or less) 
>>>>cases.  The user of only 80% cases should never have to know about 
>>>>messageExchanges.
>>>>
>>>>Specify that an IMA that does not specify a messageExchange resolves 
>>>>to a "default messageExchange declaration (DMD)."  (This is a howler 
>>>>of a name, and needs to be changed)  In this way, not specifying a 
>>>>messageExchange in an onEvent resolves replies to the onEvent, as most 
>>>>users would expect.  DMDs can be thought of as present on each onEvent 
>>>>whether they are "used" or not.
>>>>
>>>>I favor this option.
>>>>
>>>>Question *[A] *
>>>>Should a DMD be present on a parallel forEach (PFE)? 
>>>>
>>>>The argument against having it present is that PFE is not inherently a 
>>>>web-service operation, and it could be confusing to have it there.  
>>>>The argument for having it there is that in the 80% case, IMAs within 
>>>>a PFE will have replies that are in the same PFE.  Specifying a DMD on 
>>>>a PFE allows the 80% case to not use messageExchange.
>>>>
>>>>I favor having a DMD on PFEs.
>>>>
>>>>Question *[B]*
>>>>Should a DMD be present on the process?
>>>>
>>>>The argument against having it present is that there is no need for it 
>>>>to be present - we already define how to match IMAs with replies if 
>>>>there is no messageExchange.  The argument in favor of having it 
>>>>present is that if it is present, we can get rid of that exact 
>>>>language.  There are no activities with no messageExchange, there is 
>>>>just a default value.
>>>>
>>>>I favor having a DMD on processes.
>>>>
>>>>Danny
>>>>  
>>>>
>>>>Alex Yiu wrote:
>>>>
>>>>
>>>>Hi,
>>>>
>>>>Just want to relay some of the differences between CS and
>>
>>messageExchange:
>>
>>
>>>>-- CS can be declared and init-ed outside of an event handler, before 
>>>>the execution of <onEvent>.
>>>>-- On the other hand, when the messageExchange is being used by 
>>>><onEvent>, the "life cycle"/"state" of messageExchange is tied with 
>>>>"life cycle"/"state". That is, for <onEvent>,
>>>>I cannot find a use case where an <onEvent> would refer to a 
>>>>messageExchange outside of a <eventHandler>. If that reference 
>>>>happens, the only results that I can foresee are some 
>>>>non-deterministic bwps:conflictingRequest fault.
>>>>
>>>>
>>>>Thanks!
>>>>
>>>>
>>>>Regards,
>>>>Alex Yiu
>>>>
>>>>
>>>>Alex Yiu wrote:
>>>>
>>>>
>>>>In my previous email, I meant <onEvent>, instead of <onMessage>. Sorry 
>>>>for the mixup.
>>>>
>>>>Regards,
>>>>Alex Yiu
>>>>
>>>>
>>>>Alex Yiu wrote:
>>>>
>>>>
>>>>Hi Chris,
>>>>
>>>>Thank you for working this proposal out.
>>>>
>>>>A number of suggestions:
>>>>
>>>>(1) Captialize one of the "must" words
>>>>(2) Adding some more scope resolution wordings
>>>>
>>>>A reply activity is associated with an inbound message activity (IMA), 
>>>>such as, <receive>, <onMessage> and <onEvent> based on the tuple - 
>>>>partnerLink, operation, and messageExchange.  The name used in the 
>>>>optional messageExchange attribute MUST resolves to a messageExchange 
>>>>declared in a scope (where the process is considered the root scope) 
>>>>which encloses the reply activity and its corresponding IMA. The 
>>>>messageExchange resolution follows follows common lexical scoping 
>>>>rules, similar to variable resolution. A messageExchange resolves to 
>>>>the nearest enclosing scope.
>>>>
>>>>
>>>>Since messageExchange is scope-based, most likely I would request an 
>>>>additional paragraph of messageExchange resolution within a 
>>>><onMessage> in the context of Issue 204 resolution. (I would send out 
>>>>more emails later).
>>>>
>>>>Thanks!
>>>>
>>>>
>>>>Regards,
>>>>Alex Yiu
>>>>
>>>>
>>>>
>>>>Chris Keller wrote:
>>>>
>>>>Issue 123 - Proposed changes to the current draft for scoped 
>>>>messageEchange:
>>>>
>>>>
>>>>
>>>>In section 6.2 add to the informal syntax describing the XML grammar 
>>>>for both the process element and the scope element between 
>>>>partnerLinks and variables the following:
>>>>
>>>>
>>>>
>>>><messageExchanges>?
>>>>
>>>>    <messageExchange name="ncname"/>+
>>>>
>>>></messageExchanges>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>Change the following paragraphs from Section 11.4:
>>>>
>>>>
>>>>
>>>>The optional messageExchange attribute is used to associate a <reply> 
>>>>activity with an inbound message activity, such as, <receive>, 
>>>><onMessage> and <onEvent>, when there are multiple simultaneously 
>>>>incomplete inbound message activities which requires a reply message 
>>>>to complete.
>>>>
>>>>
>>>>
>>>>A reply activity is associated with a inbound message 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 inbound message activity 
>>>>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 inbound 
>>>>message 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 inbound message 
>>>>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 inbound message 
>>>>activity is executed, there cannot be more than one corresponding 
>>>>inbound message activity 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 with the same partnerLink and operation values 
>>>>are said to match. Empty value does not match with other non-empty 
>>>>values.
>>>>
>>>>
>>>>
>>>>To the following:
>>>>
>>>>
>>>>
>>>>A reply activity is associated with an inbound message activity (IMA), 
>>>>such as, <receive>, <onMessage> and <onEvent> based on the tuple - 
>>>>partnerLink, operation, and messageExchange.  The name used in the 
>>>>optional messageExchange attribute must correspond to a 
>>>>messageExchange declared in a scope (where the process is considered 
>>>>the root scope) which encloses the reply activity and its 
>>>>corresponding IMA.
>>>>
>>>>
>>>>
>>>>An open IMA describes the state of a Web service operation from the 
>>>>point that a request/response IMA starts execution until an associated 
>>>>reply begins execution. It is illegal to have multiple simultaneous 
>>>>open IMAs, which have the same partnerLink, operation and 
>>>>messageExchange tuple.  A BPEL process MUST throw a 
>>>>bpws:conflictingRequest fault when the conflicting IMA begins 
>>>>execution.  Note that it is legal to use the same messageExchange in 
>>>>multiple simultaneously open IMAs so long as the combination of 
>>>>partnerLink and operation on the IMAs are all different from each other.
>>>>
>>>>
>>>>
>>>>If a reply activity cannot be associated with an open IMA by matching 
>>>>the tuples (partnerLink, operation, and messageExchange) then a 
>>>>bpws:missingRequest fault MUST be thrown within the BPEL process on 
>>>>the reply activity. Because conflicting requests MUST be rejected at 
>>>>the time the IMA begins execution there cannot be more than one 
>>>>corresponding IMA at the time a reply activity is executed. Further if 
>>>>an open IMA goes out of scope prior to being closed by a reply 
>>>>activity then the scope MUST throw a bpws:missingReply fault.  In 
>>>>other words a scope which declares a partnerLink or messageExchange 
>>>>used by an IMA will not complete normally if that IMA is open when the 
>>>>scope is to complete.
>>>>
>>>>
>>>>
>>>>If the messageExchange attribute is not specified on an IMA or reply 
>>>>then the activity's messageExchange is said to be null. For matching 
>>>>purposes two null messageExchanges are said to match. However a null 
>>>>messageExhange does not match a non-null messageExchange.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>--------------------------------------------------------------------- 
>>>>To unsubscribe from this mail list, you must leave the OASIS TC that 
>>>>generates this mail. You may a link to this group and all your TCs in 
>>>>OASIS at: 
>>>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>>>
>>>--------------------------------------------------------------------- To 
>>>unsubscribe from this mail list, you must leave the OASIS TC that 
>>>generates this mail. You may a link to this group and all your TCs in 
>>>OASIS at: 
>>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe from this mail list, you must leave the OASIS TC that
>>generates this mail.  You may a link to this group and all your TCs in
> 
> OASIS
> 
>>at:
>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>>
>>
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe from this mail list, you must leave the OASIS TC that
>>generates this mail.  You may a link to this group and all your TCs in
> 
> OASIS
> 
>>at:
>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>>
>>
>>
> 
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 
> 
>