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 37 - Proposal for vote

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

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.



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.

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