Hi Mark,
[a]
If I read your email correctly, I could sense there is a disconnect /
missing-link between your understanding and the spec text (or at least
my understanding of spec text and all the passed issue).
Please note that: ways to handle variables in message activities are
greatly influenced by the following passed resolution: Issue 12, 112,
214 (see links below), passed by Yaron Goland and Dieter Koenig. The
parts of current spec text that you may have questions / problems are
actually coming from these three passed resolutions.
http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue12
http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue112
http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue214
I figure that examples are the best way to spell out any gap in
understanding and communication.
[b]
About the second issue Mark mentioned: whether or not the messageType
and element attributes should exist on the <onEvent>, it is
related to Issue 12.
In the case of <receive>:
<receive variable="varA" operation="opB" partnerLink="pLinkC"
... />
messageType and element attribute is not needed in <receive>
activity. Because, the type info of "varA" is known via the explicit
declaration of "varA" in an ancestor scope. And, we DO NEED type info
of "varA" to determine whether Issue 12 logic is applied. That is, get
the single doc-lit WSDL message part into the element variable.
In the case of <onEvent>, the type info of variable referenced by
the variable attribute must be stated one way or other:
Implicit declaration:
<onMessage variable="varA" operation="opB" partnerLink="pLinkC"
( messageType="p:poMsgType" |
element="p:poElem" ) >
<scope>
... <!-- "varA" does not need to be declared here -->
</scope>
</onMessage>
Explicit declaration:
<onMessage variable="varA" operation="opB" partnerLink="pLinkC"
>
<scope>
...
<variable name="varA" (
messageType="p:poMsgType" | element="p:poElem" ) />
...
</scope>
</onMessage>
I prefer implicit declaration because of DRY principle and that is
consistent with the result of our last direciton vote and other passed
resolution.
[c]
About the first issue Mark mentioned, I am not 100% sure that I follow
your source of reservation.
Mark Ford wrote:
I think this violates the spirit of the
<fromPart> element. The parts should not be manifested as
explicit variables. The data received by the IMA goes into an anonymous
temporary WSDL variable. It is simply a container for data that can
only be accessed by the <fromPart> element.
Again, in the case of <receive>,
<receive operation="opB" partnerLink="pLinkC" ... />
<fromPart part="poHeader" toVariable="poHeaderVar" />
<fromPart part="poBody" toVariable="poBodyVar" />
</receive>
"poHeaderVar" and "poBodyVar" refer to variables explicitly declared in
an ancestor scope.
In the case of <onEvent>,
Implicit declaration:
<onEvent operation="opB" partnerLink="pLinkC" ... />
<fromPart part="poHeader" toVariable="poHeaderVar" />
<fromPart part="poBody" toVariable="poBodyVar" />
<scope>
...
<!-- "poHeaderVar" and "poBodyVar" do not
need to be declared here -->
</scope>
</onEvent>
Explicit declaration:
<onEvent operation="opB" partnerLink="pLinkC" ... />
<fromPart part="poHeader" toVariable="poHeaderVar" />
<fromPart part="poBody" toVariable="poBodyVar" />
<scope>
...
<variable name="poHeaderVar" type="p:poHeaderType" />
<variable name="poBodyVar" type="p:poBodyType"
/>
</scope>
</onEvent>
The only relevant difference between <receive> and
<onEvent> in the case is that poHeaderVar and poBodyVar got
declared in the associated scope (attached to) <onEvent>.
Again, I prefer implicit declaration because of DRY principle and that
is
consistent with the result of our last direciton vote and other passed
resolution.
I hope this email clarifies the picture.
Thanks!
Regards,
Alex Yiu
Mark Ford wrote:
I think there are two issues here. The first is
an important clarification of <fromPart> and how it is used
within an onEvent.
The <fromPart> is mutually exclusive with
the variable attribute. This applies to the messageType and element
attributes as well (as pointed out in Alex's proposal). The problem I
have is that both the draft specification and Alex's proposal contain
language that has the parts in the <fromPart> being manifested as
implicit variables within the associated scope. I think this violates
the spirit of the <fromPart> element. The parts should not be
manifested as explicit variables. The data received by the IMA goes
into an anonymous temporary WSDL variable. It is simply a container for
data that can only be accessed by the <fromPart> element.
Manifesting the parts of this temporary variable as implicit variable
declarations of the appropriate type seems unnecessary and undesirable.
It is unnecessary since the data from the variable will be copied into
a target variable that is within scope, therefore if you need to access
the data then read from the designated toVariable. It is undesirable
since the manifestation of these parts as implicit variables could
serve to hide other variables with the same names that would otherwise
be in scope and accessible to the associated scope.
The other issue is whether or not the
messageType and element attributes should exist on the <onEvent>
I think that
this is a matter of style more than functionality. Using the
messageType or element attribute for onEvent is not consistent with
the other IMA's (although it is consistent with a <catch>). In
the other IMA's you need to resolve the variable in order to determine
what type of variable pattern is being used. I would argue that the
same logic should apply here. I don't think we need new attributes in
order to provide the hint.
Hi DK, Mark, Danny, Chris and others,
For rest of Issue 241 discussion, I am going to spilt into two email
threads:
(a) Whether to allow optional explicit declaration and its implication
to <forEach>
(b) Whether to remove messageType and element from <onEvent>
(That is *this* email thread)
For (b): Whether to remove messageType and element attr from
<onEvent>
[Mark and Chris, I think I can understand your intention from you guys
more clearly after reading the email for the second time.]
There are a few important notes to mention:
- A reminder: this issue has already been decided in our previous
directional vote on Issue 241. We have voted in directional vote: we
will do implicit variable declaration.
- The "messageType" / "element" attributes in <onEvent>
exist mainly because we support two different patterns to use a single
variable to receive an inbound message:
(i) a messageType variable (ii) an element variable for single doc-lit
message.
If we did not have support for these two patterns, we would not need
"messageType" / "element" attributes at all in <onEvent>.
Because, we can always deduce the messageType. So, "messageType" and
"element" attribute are not for type declaration per see. It is more
like an indicator which variable pattern is being used.
- Say, if we drop messageType and element attr from
<onEvent>, that will essentially ask users to declare those
variables explicitly in the associated scope. I think it is against our
intention determined by our directional vote last week.
- And, more importantly, how do we handle the cases of
<fromPart>, if we drop messageType and element attr? Are we going
to ask users to declare all these part variables in the associated
scope explicitly also? If users are not required, then we got some
strange asymmetry between <fromPart> usage pattern and other
variable usage patterns. If users are required to declare, then we got
a violation of DRY principle (Don't Repeat Yourself) and usability
issue.
Therefore, I tend to say, we should keep "messageType" and "element"
attr in <onEvent>.
Please let me know any further opinion preferences from you guys soon.
Thanks!
Regards,
Alex Yiu
Danny van der Rijn wrote:
I wasn't
sure how well that would go over, so I didn't suggest it. But now that
Chris did, a hearty +1 from me.
Chris Keller wrote:
+1
But can’t we
just eliminate the messageType and element declarations in the onEvent
element entirely rather than deprecate something which hasn’t been
released yet?
- Chris
From:
Danny van der Rijn [mailto:dannyv@tibco.com]
Sent: Tuesday,
March 07, 2006 2:32 PM
To: wsbpeltc
Subject: Re:
[wsbpel] Issue 241 - Proposal for Vote
+1
We could also consider deprecating the declaration that is NOT in the
associated scope. In other words, keep it in the spec, but alert users
that it's mostly there for backwards compatibility.
Danny
Dieter Koenig1 wrote:
This
suggestion is related to 241 and 204.
For more consistency across event handlers and forEach, if we allow
variables to be declared in the EH's associated scope:
"For cross-reference redundancy and clarity, these variables referenced
by
variable attribute or <fromPart> element may be optionally
declared in the
associated scope explicitly. If explicitly declared, variable types
used in
declaration MUST be exact matches of the correponding definitions in
WSDL."
then it would make sense to allow the optional explicit declaration of a
counter variable (in a scope associated with forEach) as well.
Any opinion?
Kind Regards
DK
Alex
Yiu
<alex.yiu@oracle.
com> To
wsbpeltc
07.03.2006 05:44 <wsbpel@lists.oasis-open.org>
cc
Alex Yiu <alex.yiu@oracle.com>,
Danny van der
Rijn
<dannyv@tibco.com>, Mark
Ford
<mark.ford@active-endpoints.com>
Subject
[wsbpel] Issue 241 - Proposal
for
Vote
Hi all,
Here is the formal proposal for voting for Issue 241:
PDF version: (9 page)
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/17023/wsbpel-specification-draft.241_proposal_v2b.pdf
MS-Word version: (9 page of changes on top of whole spec)
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/17024/wsbpel-specification-draft.241_proposal_v2b.doc
90% of changes are same as the draft that I sent out last week with some
extra clarification and cleaning up syntax in the direction of voting
decision of Issue 242.
Please let me know ahead of time, if you guys have any idea of friendly
amendments or fine-tuning of wordings.
Thanks!
Regards,
Alex Yiu
Alex Yiu wrote:
Hi all,
Here is the proposal draft for Issue 241.
PDF version of 9 pages which contain the changes
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/16945/wsbpel-specification-draft.241_proposal_draft.pdf
MS-Word version of changes applied to the whole spec text (based
on a
very recent version from CVS):
http://www.oasis-open.org/apps/org/workgroup/wsbpel/download.php/16944/wsbpel-specification-draft.241_proposal.doc
Note:
[1]
One more normative changes we need to make (but not a part of the
PDF) is to amend/clarify resolution of Issue 123 in a very minor
way
as follow:
From: "This resolution follows the same scoping rules as variable
and
correlationSet resolution."
To: "This resolution follows the same scoping rules as
correlationSet
resolution."
[2]
In this proposal, I did try to clean up some syntactic issue of
<onEvent> not directly related to issue 242. (e.g. making
variable
attribute optional because of <fromPart>).
I do intend to come up a consolidated proposal based on the
(directional) decision of Issue 242. Because there are a number of
places in desc text of <onEvent> (not just syntax) needs to
be
fine-tuned a bit more after syntactic decisions are made. Here are
two syntactic decisions need to be made:
[a] moving <correlationSets> "inline" declaration to the
associate
scope (regardless of decision of [b] below: whether the associated
scope is collapse into <onEvent>). [Currently, I tend to
say we
should move declaration to make the syntax more consistent with
other
scope-related syntax]
[b] core decision for Issue 242: whether to collapse scope syntax
into <onEvent> syntax. Namely, we have 3 choices here:
(i) Yes, we collapse. The syntax is based XSD extend. Example:
---------------------------
<onEvent ... partnerLink="..." variable="..."
isolated="..." name="...">
<partnerLinks> ... </partnerLinks>
<variables> ...
</variables> <correlationSets> ...
</correlationSets>
... main activity
<correlations> ... </corelations>
<fromPart ... />*
</onEvent>
---------------------------
(ii) Yes, we collapse. Its syntax is NOT derived scope. (That
means
we need to main a separate, duplicated, different and yet similar
grammar rule.) Example:
---------------------------
<onEvent ... partnerLink="..." variable="..."
isolated="..." name="...">
<correlations> ... </corelations>
<fromPart ... />*
<partnerLinks> ... </partnerLinks>
<variables> ...
</variables> <correlationSets> ...
</correlationSets>
... main activity
</onEvent>
---------------------------
(iii) No. We do not collapse. Instead, we choose the
"extend-by-containment" approach. Example:
---------------------------
<onEvent ... partnerLink="..." variable="...">
<correlations> ... </corelations>
<fromPart ... />*
<scope ... isolated="..." name="...">
<partnerLinks> ... </partnerLinks>
<variables> ...
</variables> <correlationSets> ...
</correlationSets>
... main activity </scope>
</onEvent>
---------------------------
Further analysis (from my viewpoint):
The main reason that I heard from proponents of collapse
seems
to be elminiating forward-reference pattern (i.e. a
resource is
declared after reference in source code order). IMHO, that
is a
commonly used situation in a lot of programming language.
Furthermore, you can see later that this situation cannot be
elminated even if we decide to collapse those syntax.
The syntax order in (i) just seems very odd and unnatural
and
make the source code visualization much harder. And,
forward-reference still happens for variable and
partnerLink.
For the syntax in (ii), forward-reference still happens for
variable and partnerLink. The interleaving syntax
(highlighted
blue and brown) make it harder for people to learn and
remember
what is exactly <onEvent> is about. Moreover, we will
be forced
to duplicated grammar rule for tScope for no compelling
reasons. Make BPEL source code syntax analyser
implementation
more difficult.
For the syntax in (iii), I personally prefer the most.
Because,
the syntax groups syntax common to <scope> and
specific to
<onEvent> in a clean and easy-to-learn way.
<onEvent> syntax is
the outer syntax, while <scope> is the inner syntax.
It does
not require any XSD grammar rule duplication. And, it makes
use
of another common and useful design pattern -
"extend-by-containment".
Ideally, I want to submit a proposal (potentially with Danny) that
resolve both Issue 241 and 242. That will minimize any risk
inconsistent and "leftover" editing issue in that section.
[3]
For Issue 245, assuming it is opened. I agree with Danny and Mark
there. This proposal draft contains an attempt to clean up Section
12.5.7 which is also a part of "Event Handlers" section.
Thanks!
Regards,
Alex Yiu
|