Actually #4 I listed below is not applicable here. So taking out the with
initiate="no"
part.
Here is the slightly amended proposal:
--------------------------------------
The bullets above describe the correlation set "Initiation Constraint".
If multiple correlation sets are used in an outbound message
activity (e.g, <invoke>), both correlation initiation
constraint and consistency constraints MUST be observed for
all
correlation sets used. If multiple correlation sets are used in an
inbound message
activity (e.g. <receive>),
then the correlation initiation constraint MUST be
observed for all
correlation sets used. If any one of the correlation sets does not
follow the constraints above, the standard fault
bpel:correlationViolation MUST be thrown.
When multiple correlation sets are used in an inbound message activity
(IMA), a message MUST match all correlation sets for
that message to be delivered to the activity in the given process
instance. When correlation
set in a message does not match an
already initiated correlation set in the process instance or if it is
not initiated, the message
MUST not be delivered to an IMA. Therefore,
the correlation consistency constraint checking is not applicable for
inbound message activities.
--------------------------------------
The above text replaces the following sentences in section 9.2 :
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 sentences (below) that follow the above text currently will be
retained:
"If an inbound Web service request
message arrives and both (1) no running process instance can be
identified by a
message correlation set mechanism and (2) all inbound message
activities
referencing the Web service operation have the createInstance attribute
set to
"no" are true then this scenario is out of scope of this
specification because there is no process instance that would be able
to handle
it."
Regards,
Prasad
Prasad Yendluri wrote:
Alex et. al,
I propose some amendments to account for the following problems with
the current proposal:
1. First of all we agreed in the TC call today not to use CamelCase for
"correlationSet" etc. So, we need to fix that.
2. Everywhere else in the spec we call it "initiate" or "initiation" of
correlation set. Not "initialization". So, I suggest we change
"initialization" to "initiation".
3. The meaning and context for "outbound" and "inbound" as stated in
the first paragraph is not clear.
"If multiple correlationSet's are used in a message
activity then the above consistency (outbound only) and
initialization
(inbound and outbound) constraints MUST be observed for all
correlationSet's used .."
I suggest rephrasing.
4. The current proposal took out "with
initiate="no","
for inbound case, that was in the original text.
5. The current proposal states "When a message
does not match an
already initiated correlationSet, it
MUST not be delivered to an IMA." It leaves out the case for
"uninitiated" correlation set.
6. The current proposal does not state what text in the current spec it
is replacing.
Here is my amended proposal:
--------------------------------------
The bullets above describe the correlation set "Initiation Constraint".
If multiple correlation sets are used in an outbound message
activity (e.g, <invoke>), both correlation initiation
constraint and consistency constraints MUST be observed for
all
correlation sets used. If multiple correlation sets are used in an
inbound message
activity (e.g. <receive>) with
initiate="no",
then the correlation initiation constraint MUST be
observed for all
correlation sets used. If any one of the correlation sets does not
follow the constraints above, the standard fault
bpel:correlationViolation MUST be thrown.
When multiple correlation sets are used in an inbound message activity
(IMA), a message MUST match all correlation sets for
that message to be delivered to the activity in the given process
instance. When correlation
set in a message does not match an
already initiated correlation set in the process instance or if it is
not initiated, the message
MUST not be delivered to an IMA. Therefore,
the correlation consistency constraint checking is not applicable for
inbound message activities.
--------------------------------------
The above text replaces the following sentences in section 9.2 :
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 sentences (below) that follow the above text currently will be
retained:
"If an inbound Web service request
message arrives and both (1) no running process instance can be
identified by a
message correlation set mechanism and (2) all inbound message
activities
referencing the Web service operation have the createInstance attribute
set to
"no" are true then this scenario is out of scope of this
specification because there is no process instance that would be able
to handle
it."
Regards,
Prasad
Alex Yiu wrote:
Hi all,
A minor rewording request from Danny (in GREEN): (accepted as a
friendly amendment)
-------------------------
The bullets above describe the initialization constraint applied to
correlationSet. If multiple correlationSet's are used in a message
activity then the above consistency (outbound only) and initialization
(inbound and outbound) constraints MUST be observed for all
correlationSet's used. If any one of the correlationSet's does not
follow the constraints above, 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. When a message does not match an
already initiated correlationSet, it
MUST not be delivered to an IMA. Therefore,
the related consistency constraint checking is not applicable in this
case.
-------------------------
Thanks!
Regards,
Alex Yiu
|