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