Re: [wsbpel] Issue 37 - Proposal for vote

["Yaron Y. Goland" <ygoland@bea.com>]

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.
>