RE: [wsbpel] Issue 37 - Proposal for vote

[Alex Yiu <alex.yiu@oracle.com>]

Hi, all,

Here is the latest revised proposal for vote for Issue 37.
Satish, Yaron, Dieter, Yuzo, Nick and I worked together on this proposal.

The "initiate" attribute becomes a tri-value switch. And, the proposal 
provides details of the semantics of different cases.

Thanks!


Regards,
Alex Yiu

Title: Issue 37 Proposal Draft

Proposal for Vote for Issue 37

June 15, 2004

The "initiate" attribute becomes a tri-value switch instead of a boolean switch. The legal values of the "initiate" attribute are: "yes", "rendezvous", "no". The default value of the attribute remains "no".

After a correlation set is initiated, the values of the properties for a correlation set must be identical for all the messages in all the operations that carry the correlation set and occur within the corresponding scope until the completion of the scope. This correlation consistency constraint must be observed in all cases of "initiate" values.

• When the "initiate" attribute is set to "yes", the related activity MUST attempt to initiate the correlation set. 
• If the correlation set is already initiated and the "initiate" attribute is set to "yes" , the standard fault bpws:correlationViolation MUST be thrown by a compliant implementation.
• When the "initiate" attribute is set to "rendezvous",  the related activity MUST attempt to initiate the correlation set, if the correlation set is NOT initiated yet.
• If the correlation set is already initiated and the "initiate" attribute is set to "rendezvous", the correlation consistency constraint MUST be observed. If the constraint is violated, the standard fault bpws:correlationViolation MUST be thrown by a compliant implementation. 
• When the "initiate" attribute is set to "no", the related activity MUST
  
• NOT attempt to initiate the correlation set.
• If an activity with the "initiate" attribute set to "no" attempts to use a correlation set that has not been previously initiated, the standard fault bpws:correlationViolation MUST be thrown by a compliant implementation.
• If the correlation set is already initiated and the "initiate" attribute is set to "no", the correlation consistency constraint MUST to be observed. If the constraint is violated, the standard fault bpws:correlationViolation MUST be thrown by a compliant implementation.

The "yes" and "rendezvous" values of "initiate" attribute can be used with both start and non-start activities.

When a correlation set of "rendezvous" initiation style is used with a non-start inbound messaging activity, it must be accompanied with at least one other correlation set which is already initiated and for which the "initate" attribute is set to "no". Inbound messaging activites are receive, onEvent and onMessage.    The purpose of this restriction, which applies only to non-start inbound messaging activities, is to ensure that the associated message actually gets delivered to the process instance in which the activity occurs.  Start activities do not require this restriction since the first such activity to receive a matching message actually causes the creation of the process instance in which it occurs.  Outbound messaging activities (reply and invoke) do not need this restriction since they have no need for matching of message to the source process instance.

 

For example, consider the following non-start receive activity:

     <receive ... >
        <correlations>
           <correlation set="bar" initiate="rendezvous" />
        </correlations>
     </receive>

 

The use of the correlation set "bar" with a "rendezvous" initiation type is invalid since it is not accompanied by a correlation set with initiation set to "no".

When a correlation set of "rendezvous" initiation style is used with a start activity, the "rendezvous" initiated correlation set MAY be the only correlation set used in the activity.




Affected Sections:

• 6.2. The Structure of a Business Process
• 10.2. Defining and Using Correlation Sets
• 14.4. Correlation
• Appendix D. XSD Schema