[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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:fujishima@bc.jp.nec.com]
> Sent: Tuesday, December 06, 2005 9:19 PM
> To: chris.keller@active-endpoints.com
> 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:fujishima@bc.jp.nec.com]
>>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:dannyv@tibco.com]
>>>>*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
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]