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