Re: [wsbpel] Issue 37 - Proposal for vote

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

Hi, all,

I am not 100% sure whether proposed resolution answers question raised by the original issue description. I think we should at least I want to separate the problem raised in Issue 37 into two parts.


(I) Clarification of "initiate" attribute (Applicable to Section 10.2)

Quoting from the spec: I suggest to add the italic-and-bold part.
"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 its completion. The semantics of a process in which this consistency constraint is violated is undefined, regardless of value of initiate attribute."

(In Executable Extension Section 14.4, the bpws:correlationViolation fault must be thrown to BPEL process execution in the above case. E.g. receive, invoke, reply).

Quoting from the spec:
"Similarly undefined is the semantics of a process in which an activity with the initiate attribute set to no attempts to use a correlation set that has not been previously initiated."

(In Executable Extension Section 14.4, the bpws:correlationViolation fault must be thrown to BPEL process execution in the above case. E.g. receive, invoke, reply).

Quoting from the spec:
"The initiate attribute is used to indicate whether the set is being initiated."
I would suggest to change it to:
"The initiate attribute is used to indicate whether the set is allowed to be initiated."


(II) More Clarification of correlationViolation Semantics (Applicable to Execution Extension Section of the Spec 14.4)

It seems to me that most of focus of Issue 37 is at the usage of CS on the receiving sides. A reminder: a CS can be used in "invoke" and "reply" also. And, the correlationViolation semantics are slightly different and need to be specified in more details in the spec, especially where bpws:correlationViolation is thrown to. We may want to add some of the following elaboration points to section 14.4:

• Receive/OnMessage/OnEvent: When a message for an operation arrives at the BPEL container:
  
• If there are active <receive> of matching operation with createInstance="true"
  
• then a new BPEL process instance will be created.
  
• Else if there are no active <receive> (createInstance="no") with a matched initiated CS or a not-initiated-yet CS with initiate="no"
  
• then bpws:correlationViolation fault must be thrown to the External Caller of the target operation of the <receive>, if the WSDL definition allows sending back a fault. (That is, a receive activity will never trigger a correlationViolation fault internal to the BPEL process execution.)
  
• An active <receive> (createInstance="false") with a mismatched CS will not receive the message.
  [A remake of a sentence from part-1 of Yuzo's proposal: "All the pending and future activities in the same process instance referencing the same correlation set will not receive any messages that do not match the correlation set.".]
• Invoke: If the data in the reply coming back from the invoked service mismatches with the already initiated CS, then bpws:correlationViolation fault must be  thrown to BPEL process execution  (E.g. the reply carries a CS value different from the already initiated CS of pattern "in").
• Reply: If the data used in the reply going out to the invoker mismatches with the already initiated CS, then bpws:correlationViolation fault must be  thrown to BPEL process execution

Multiple Start sharing the same CS: For example, two <receive> are actively listening messages and they are marked with createInstance="yes" and they are sharing the same CS. Once one of the start <receive> activities is completed, then other start <receive> activity will not be used as createInstance activity. It will just become yet another ordinary <receive>. It will obey the same rules for CS matching and initation.


(I agree with Yaron's viewpoint if part-1 of Yuzo's resolution exists without part-2, it can allows more bugs or unintended behavior expressed in BPEL. I also agree Yaron's viewpoint on that, for part-2, developers will be forced to explicitly specify noInitiate = "true" for 80% of  cases.)




Regards,
Alex Yiu


Yaron Y. Goland wrote:

Resolution 1, by itself, would enable a whole class of programmer bugs
that are impossible today.

Resolution 1 + 2, if I understand the semantics correctly means that a
message operation with noInitiate="false" will:

	Case 1 - Correlation Set is Uninitialized - The message activity is
available for use and if a message is received then the correlation set
will be initialized.

	Case 2 - Correlation Set is Initialized - The message activity is
available for use but will only accept messages that match the
initialized correlation set.

I think that noInitiate="false" allows for ambiguity in specifying the
programmer's intentions. I'm having trouble imagining compelling
scenarios, outside of start activities, where someone would explicitly
want a message activity that will run regardless of the initialized
status of its correlation set. In the specific case of start activities
I'm actually going to propose a different solution targeted at just that
problem.

I also think that noInitiate puts the burden in the wrong place in
regards to guarding message activities. In a world with noInitiate every
time a programmer has a message activity that wants to make sure to use
an initialized correlation set, which I believe will be the 80% case,
they will be forced to explicitly specify noInitiate = "true". I think
the burden should be reversed. Programmers should only be required to
specify something if they don't expect the correlation set to be initiated.

	Thanks,

		Yaron

Yuzo Fujishima wrote:

  

Dear WSBPEL members:

In hope of expediting the discussion, I would like to propose a resolution
for Issue - 37 - Initiating Correlation Set More Than Once.
http://lists.oasis-open.org/archives/wsbpel/200307/msg00070.html

The proposed resolution has two parts. The second part is viable only when
the first part is accepted. In my opinion, the first part should accomodate
the multiple start activity scenario and the second part lends itself to
avoid inadvertent errors.

Proposed resolution part-1:
Abolish the "initiate" attribute of the "correlation" element. A correlation
set is initiated by the first activity that references it and completes.
All the pending and future activities in the same process instance
referencing the same correlation set will not receive any messages that
do not match the correlation set.

Proposed resolution part-2:
Introduce "noInitiation" attribute with default value "false" to the
correlation element. If the attribute is set to "true", the correlation
set must be already initiated when the referencing activity starts. If the
correlation set is not initiated, the bpws:correlationViolation fault must
be thrown.

Sincerely,

Yuzo Fujishima
NEC Corporation


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.

    

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.