Hi all,
Here are three points mentioned as amendments in the conf call:
- For variable resolution, it will be resolved to associated scope
only.
- For message exchange resolution, it will be resolved to the
associated scope first then ancestor scopes. It is similar to
partnerLink and CS resolution.
- When onEvent faults (i.e. onEvent message activity faults, such
as xml validation), the fault will be first thrown to the assoicated
scope.
Regards,
Alex Yiu
Alex Yiu wrote:
Hi all,
Here is the note for discussion for Issue 241.
Thanks!
Regards,
Alex Yiu
Note on Issue 241 (Potential Directional Vote Draft)
Last modified: Feb 21, 2005
Terminology:
- associated scope: the scope directly attached to
<onEvent> or <onAlarm> under <eventHandlers>. The
semantics of scope is already decided by Issue 204 resolution, while
Issue 242 may change the syntax of associated scope.
- ancestor scopes: the containing <scope> or
<process> or scope-equivalent constructs of <eventHandlers>
(depending on resolution of Issue 242)
Resources
|
Resolving To
|
Declaration Locally in the Associated Scope
|
variables [Note #1]
|
[Currently: resolving to associated
scope only]
Suggestion: kept the same [Rationale
#1]
|
[Currently: implicit declaration] [Note #2]
Suggestion: kept the
same [Rationale #1]
|
partnerLink
|
[Currently: seem like resolving to
ancestor scopes only]
Suggestion: resolving
to the associated scope first and then ancestor scopes
|
[Currently: after passing Issue 204,
partnerLink can be declared locally]
Suggestion: kept the same (maybe with explicit text
clarification)
|
correlation set
|
[Currently: seem like resolving to
resolving to the associated scope first and then ancestor scopes]
Suggestion: resolving
to the associated scope first and then ancestor scopes (using <correlation> syntax) (maybe with explicit text
clarification) |
[Currently: CS can be declared
locally]
(using <correlationSet> syntax)
Suggestion: kept the same |
messageExchange
|
There were two options
discussed during F2F: [Note #3]
- same as variable
- same as correlationSet/partnerLink
|
[Currently: MsgExchange can be
declared locally, including the default message exchange]
Suggestion: kept the same |
Note #1:
Variables include all these cases:
- messageType variable: using messageType="..." syntax
- element-based variable of single-part doc-lit message: using
element="..." syntax
- simple, complex type, element based variables: using
<fromPart> syntax
Note #2:
Definition of Implicit Variable Declaration:
- Current spec text:
- "The variable attribute identifies a variable local to the
eventHandler that will contain the message received from the partner."
- "Optionally the messageType attribute may be omitted and
instead the element attribute substituted if the message to be received
has a single part and that part is defined with an element type that
matches the element type referenced by the element attribute."
- "When using the <fromPart> elements, each <fromPart> element constitutes a declaration of a variable of that
name within an implicit
scope associated with the event handler. The
variable type is derived from the type of the corresponding message
part."
Rationale
#1: [decision point
here]
- Implicit variable declaration and resolving to the associated
scope only (current spec behavior) will ensure that multiple instances
of <onEvent> has its own local copy of variables of recieved
messages.
- If we allow resolution to the parent scope of variable used in
<onEvent>, then multiple instances of <onEvent> will be
more than likely to "share" the same variable of received messages and
the received message will overwrite each other during multiple
instantiation of <onEvent>.
==> That is almost equivalent asking
users to get a stone to throw at their own feet
==> Why allowing usage pattern which is harmful ranther than
useful to users??
- Implicit variable declaration also save users from writing
redundant codes, especially in the case of <fromPart>. If we want
to achieve implicit variable declaration, it would be better to have
variables resolved to the associated scope only. Otherwise, the
semantics would be surprising/mysterious to users, if a variable of
same name is declared in an outer scope.
- About comparision with using a <receive> within a
parallel
forEach, I would not say they are equivalent. Variables in an
<onEvent> is like parameters of a method call, where multiple
calls can happen concurrently and each call should have its own copy of
parameter. On the other hand, variables used in <receive> in a
parallel forEach is similar to calling another service call that
modifies data in a parallel env. In most of programming languages, the
first pattern is enforced by the programming language design itself. On
the other hand, if a same variable is shared among multiple parallel
service call, a good language envirnoment would warn users about that
to its best extent. That is especially true to a high-level language
like BPEL.
Note #3:
There were two options discussed during F2F: [decision point
here]
(A) same as variable:
Assuming
variable is resolved to associated scope only. That means the
messageExchange is resolved to associated scope only.
(B) same as
correlationSet/partnerLink: That means the messageExchange can be
resolved to a parent scope
F2F attendents seem like preferring this one (B) so far.
[AYIU: IMHO, I am wondering
what is a legal usage patter for (B)? Can we construct a general
legal case? I don't need a meaningful one but just a legal one.
- Using a while or forEach loop to reply the <onEvent>? It
does not seem to work.
- Using another <onEvent> to reply? It does not seem to
work either.
- Unless all the <onEvent> call is serialized, I cannot
find
a legal usage case so far. If the incoming call is known to be
serialized, a <receive> within <while> loop should be used
instead.]
Minor
adjustment of Issue 123 Resolution:
When I was proposing the amendment to Chris' proposal on Issue 123 to
drop "partnerLink" from the list:
http://lists.oasis-open.org/archives/wsbpel/200512/msg00050.html
because I was aware that partnerLink resolution is different from
variable.
Unfortunately, I was not aware that the resolution of variables and
correlation set in the current spec text is different at that time. If
I was
aware that at that time, I would suggest just listing variable in the
resolution rule in Issue 123 proposal.
One way or the other based on the decision point on [Note #3]. I
suggest to clarify Issue 123 resolution.
From: "This resolution follows the same scoping rules as variable and
correlationSet resolution."
To: "This resolution follows the same scoping rules as variable
resolution."
OR:
From: "This resolution follows the same scoping rules as variable and
correlationSet resolution."
To: "This resolution follows the same scoping rules as correlationSet
resolution."
END
---------------------------------------------------------------------
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
|