[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 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
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"
- 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
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]