I
was misreading the following text from Section 12.5.1
3rd paragraph:
An alternative to the variable attribute are <fromPart> elements. The
syntax and semantics of the <fromPart> elements as
used on the onEvent tag are the same as specified in section 11.3 for the invoke activity. This includes
the restriction that if <fromPart> elements are
used on an onEvent tag then the variable attribute MUST NOT be
used on the same tag. 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.
I was
reading this to mean that the part names were manifested as implicit variables!
Based on your exmaples below the intention here is that the toVariable
attribute of the fromPart is manifested as an implicit
variable.
Thanks for
the clarification.
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
|