+1 to Prasad's change.
Just you got a simple typo of doubling the "with" word. :-)
Regards,
Alex
Prasad Yendluri wrote:
Alex (et. al),
I would like to make another minor but important amendment.
In the second paragraph we need to qualify the IMAs, as those with "initiate=no".
Here is the new (complete) proposal with this small change:
--------------------------------------
The bullets above describe the correlation set "Initiation Constraint".
If multiple correlation sets are used in an outbound message
activity (e.g, <invoke>), both initiation
constraint and consistency constraints MUST be observed for
all
correlation sets used. If multiple correlation sets are used in an
inbound message
activity (IMA) (e.g. <receive>),
then the 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 IMA
with with
initiate="no",
a message MUST match all such 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 consistency constraint checking is not applicable for IMA.
--------------------------------------
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 Prasad,
A general +1 to your revised text. It does read better. :-)
I would like suggest some minor rewording for ease of read and
consistent writing style. (e.g. dropping "correlation" word before
"initation constraint" or "consistency constraint" and a more
consistent "IMA" usage)
--------------------------------------
The bullets above describe the correlation set "Initiation Constraint".
If multiple correlation sets are used in an outbound message
activity (e.g, <invoke>), both initiation
constraint and consistency constraints MUST be observed for
all
correlation sets used. If multiple correlation sets are used in an
inbound message
activity (IMA) (e.g. <receive>), then the 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 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 consistency constraint checking is not applicable for IMA.
--------------------------------------
I had a brief email converation with Prasad. He said this new change
looks good to him.
Thanks! :-)
Regards,
Alex Yiu
Prasad Yendluri wrote:
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
|