[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 37 - Proposal to vote (updated)
Following yesterday's discussion, this is the text of the proposed
resolution to issues 37. The modified text beings with the third paragraph
("A correlation set of "rendezvous" or "yes" initiation style on a
non-start inbound messaging activity ...).
Paco
Proposal for Vote for Issue 37
June 23, 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.
A correlation set of "rendezvous" or "yes" initiation style on a non-start
inbound messaging activity cannot be used to route incoming messages to the
process instance. The reason is that in the case of the "rendezvous"
initiation style it can not be assumed that the correlation set has been
initiated when incoming the message arrives, while in the cased of a "yes"
initiation style the correlation set is always initiated after the message
has been delivered. For this reason, when these two correlation initiation
styles are used on the receive, onEvent and onMessage activities, other
mechanisms for ensuring the delivery of incoming messages to the process
instance MUST be provided, either by adding to the inbound activity an
already initiated correlation set (for which the "initiate" attribute is
set to "no"), or by the runtime engine in the form of and engine managed
message correlation mechanism.
This requirement does not apply to start activities 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 requirement either 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>
Since the correlation set "bar" with a "rendezvous" initiation type on the
receive activity is not accompanied by a second, already initiated
correlation set, the runtime engine must provide in this case a message
delivery mechanism able to deliver incoming messages to the process
instance.
[The text in the resolution should be revised once issue 96 is closed]
Alex Yiu
<alex.yiu@oracle. To: Alex Yiu <alex.yiu@oracle.com>
com> cc: Francisco Curbera/Watson/IBM@IBMUS, Satish Thatte
<satisht@microsoft.com>, wsbpel@lists.oasis-open.org, "Furniss, Peter"
06/21/2004 02:03 <Peter.Furniss@choreology.com>
AM Subject: Re: [wsbpel] Issue 37 - Proposal to vote (updated)
Hi, all,
(resend with a better subject line for Peter as suggested by Satish)
(As requested by Diane ...)
Here is a slightly updated version of Issue 37 proposal.
Incorporated two data points mentioned by Peter in the previous email on
this thread.
Thanks!
Regards,
Alex Yiu
Proposal for Vote for Issue 37
June 19, 2004
(Parts of Peter's email was incorporated into the proposal. Those changes
are highlighted by underline and background color.)
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" or "yes" 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".
Another way to state this constraint: for a non-start inbound activity,
there must be at least one correlation set with initiate="no". There may be
other correlation sets with "yes" or "rendezvous".
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.
When a correlation set of "rendezvous" or "yes" initiation style is used
with a start activity, the "rendezvous" or "yes" initiated correlation set
MAY be the only correlation set used in the activity.
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".
Another illegal example that worths some highlighting:
<receive ... createInstance="yes">
<correlations>
<correlation set="bar" initiate="no" />
</correlations>
</receive>
A correlation set used in a start activity must be un-initialized.
Therefore, the initiate="no" pattern will definitely trigger an execution
time fault.
Affected Sections:
6.2. The Structure of a Business Process
10.2. Defining and Using Correlation Sets
14.4. Correlation
Appendix D. XSD Schema
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php
.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]