OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue - 263 - proposal for vote


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]