Hi Alex,
Yes, the proposed rewording distingushing between the inbout and
outbound aspects works.
I believe this is an issue. Diane also clarified that (significant)
changes to Ch 1-9 warrant raising issues.
Regards,
Prasad
Alex Yiu wrote:
Hi Prasad,
Yes, we need a clarification there. (And, there was a similar
discussion happened in Redmond F2F in last Sept.) The confusion comes
from we are mixing / muddling two scenarios here: inbound and outbound.
-----------------------
If multiple correlationSet’s are used in a
message activity with initiate="no", then the consistency constraint
MUST be observed for all correlationSet’s used. For example, the correlationSet's used in an inbound
message activity (e.g. <receive>) must all match a message for
that message to be delivered to the activity in the given process
instance. If one of the initiated
correlationSet’s does not match the message, the standard fault
bpel:correlationViolation MUST be thrown.
-----------------------
=> The green part is talking about general correlation set
consistency semantics.
=> The blue part is talking about the particular case of handling
inbound message. This refined semantics for inbound messages makes the
general CS consistency semantics not applicable anymore.
Since the green part semantics repeats semantics logic mentioned in the
bullets of: "When the initiate attribute is set to "no" or is not
explicitly set" and etc, I would suggest the rewording as follows:
-----------------------
If multiple correlationSet’s are used in a
message activity (inbound or outbound), then the above
consistency and initialization constraints
MUST be observed for all correlationSet’s used. If
any one of the correlationSet’s does not follow the above
constraints , the
standard fault bpel:correlationViolation MUST be thrown.
When the correlationSet's are
used in an inbound message activity (IMA) (e.g.
<receive>), a message MUST match all correlationSet's for that message to be
delivered to the activity in the given process instance. Since the message is not delivered to IMA when it
mismatches an initiated correlationSet (with initiate="no" or "join"),
the related consistent constraint checking is no longer applicable.
-----------------------
With this reworded text, different concerns are not separated. And, the
green text got generalized now and more applicable, while the concern
of the blue texts got clarification and its application target got
pinpointed.
Prasad, does it look good to you?
In short, I agree with Prasad that we need to tackle this issue by
rewording.
If this clarification deems to be a normative change, then we should
open this issue.
Thanks!
Regards,
Alex Yiu
Prasad Yendluri wrote:
Description:
The specification in section 9.2 states:
"If multiple correlationSet’s are used in a
message activity with initiate="no",
then the consistency constraint MUST be observed for all
correlationSet’s used. For example, the correlationSet's used in an
inbound
message activity (e.g. <receive>)
must all match a message for that message to be delivered to the
activity in the given process instance. If one of the initiated
correlationSet’s
does not match the message, the standard fault bpel:correlationViolation
MUST
be thrown."
Given "correlationSet's
used in an inbound
message activity (e.g. <receive>)
must *all* match a message for that message to be delivered to the
activity in the given process instance", how
is it possible to match up a message with a process instance and throw
the "bpel:correlationViolation"
exception if "*one* of the correlationSet’s
does not match the message" as stated in the last sentence above
(excerpt from the from spec).
Minimally this needs some clarification. Off the bat looks to be a
contradiction to me.
Regards,
Prasad
|