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 - 222 - What's the state of a receive after acorrelationViolation?



Hi,

I understand what Yaron suggested here ... However, it clearly differs 
from the BPEL 1.1  spec and existing BPEL 2.0 spec. Having this 
less-than-trivial semantics change in this stage of spec would not be 
good idea.

Given a multiple correlation set situation and one of them having this 
consistency constraint violation problem, it is easier for users to 
debug the problem, if the <receive> got faulted compared with the 
message got struck and not delivered / routed to the process instance.

Think of a situation where a process instance always got struck in the 
"in-progress" state and never got completed/faulted. It keeps waiting 
for a message which it cannot receive due to this consistency violation 
problem.

And, if my reading is correct, Satish would have a relatively strong 
opinion on this also. (Of course, he is on sabbatical ... it would be 
difficult for me to confirm.)

Thanks!


Regards,
Alex Yiu


Yaron Y. Goland wrote:

> I think Danny is right.
>
> The core of the problem is that we shouldn't allow a message to arrive 
> if it doesn't match the specified correlation sets. We should specify 
> that it is impossible for a message to be received without proper 
> correlation sets and we should further specify that the 
> correlationViolation fault can only occur on a receive/pick in the 
> case that an un-initialized correlation set is used with 
> 'initiate='no'' or an initialized correlation set is used with 
> 'initiate='yes''.
>
>     Yaron
>
> Danny van der Rijn wrote:
>
>>   I would agree with you on principle, but I believe that the spec 
>> disagrees with us:
>>
>> from 14.4:
>>
>>           o 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.
>>
>> This has always confused me greatly and I'd love to get rid of it.
>>
>> Danny
>>
>> Dieter Koenig1 wrote:
>>
>>> Such conflicts should be resolved before a message is delivered to a
>>> particular process instance. There is no obvious preference in 
>>> evaluating
>>> (potentially contradicting) correlation mechanisms -- in other 
>>> words, it is
>>> not clear why one would draw the conclusion that the WS-Addressing
>>> information is correct in this case and the BPEL information is not.
>>> Kind Regards
>>> DK
>>>
>>>
>>>
>>>                                                                           
>>>             ws-bpel 
>>> issues                                                            
>>> list editor                                                   
>>>             
>>> <peter.furniss@ch                                          To 
>>>             oreology.com> 
>>> <mailto:peter.furniss@chTooreology.com>             
>>> wsbpel@lists.oasis-open.org 
>>> <mailto:wsbpel@lists.oasis-open.org>         
>>>                                                                        
>>> cc             19.07.2005 
>>> 10:59                                              
>>>                                                                   
>>> Subject                                       [wsbpel] Issue - 222 - 
>>> What's the               Please respond to         state of a 
>>> receive after a                           wsbpel               
>>> correlationViolation?               
>>>                                                                           
>>>                                                                           
>>>                                                                           
>>>                                                                           
>>>                                                                           
>>>                                                                           
>>>
>>>
>>>
>>>
>>> This issue has been added to the wsbpel issue list with a status of
>>> "received". The status will be changed to "open" if a motion to open 
>>> the
>>> issue is proposed and that motion is approved by the TC. A motion could
>>> also be proposed to close it without further consideration. 
>>> Otherwise it
>>> will remain as "received".
>>>
>>>
>>> The issues list is posted as a Technical Committee document to the 
>>> OASIS
>>> WSBPEL TC pages on a regular basis. The current edition, as a TC 
>>> document,
>>> is the most recent version of the document entitled in the "Issues" 
>>> folder
>>> of the WSBPEL TC document list - the next posting as a TC document will
>>> include this issue. The list editor's working copy, which will normally
>>> include an issue when it is announced, is available at this constant 
>>> URL.
>>> Issue - 222 - What's the state of a receive after a 
>>> correlationViolation?
>>>
>>>
>>> Status: received
>>> Date added: 19 Jul 2005
>>> Categories: Correlation
>>> Date submitted: 18 July 2005
>>> Submitter: Yaron Y. Goland
>>> Description: Imagine receiving a request/response which is being 
>>> correlated
>>> using both BPEL correlation sets as well as some underlying 
>>> mechanism like
>>> WS-Addressing. It turns out that that the WS-Addressing correlation 
>>> matched
>>> so the message was delivered but it then turns out that the BPEL
>>> correlation sets didn't match so a correlationViolation was thrown.
>>>
>>>
>>> Question #1 - Was the message received? In other words, when do we 
>>> define
>>> the fault as having been thrown, before or after the message is 
>>> received?
>>>
>>>
>>> Question #2 - Can a reply be sent?
>>>
>>>
>>> Question #3 - Is this scenario even legal? If a message doesn't 
>>> match the
>>> BPEL level correlation sets then is reception simply a 'non-event'?
>>> Submitter’s proposal: We should either make this entire scenario 
>>> illegal or
>>> we should put in language into the spec that states that this 
>>> scenario is
>>> legal, the message MUST be received and that a reply is allowed.
>>> Changes: 19 Jul 2005 - new issue
>>>
>>>
>>>
>>> To comment on this issue (including whether it should be accepted), 
>>> please
>>> follow-up to this announcement on the wsbpel@lists.oasis-open.org 
>>> <mailto:wsbpel@lists.oasis-open.org> list
>>> (replying to this message should automatically send your message to 
>>> that
>>> list), or ensure the subject line as you send it starts "Issue - 222 -
>>> [anything]" or is a reply to such a message. If you want to formally
>>> propose a resolution to an open issue, please start the subject line 
>>> "Issue
>>> - 222 - Proposed resolution", without any Re: or similar.
>>>
>>>
>>> To add a new issue, see the issues procedures document (but the 
>>> address for
>>> new issue submission is the sender of this announcement).
>>>
>>>
>>>
>>>
>>> Choreology Anti virus scan completed
>>>
>>>  
>>>
>> --------------------------------------------------------------------- 
>> To unsubscribe from this mail list, you must leave the OASIS TC that 
>> generates this mail. You may a link to this group and all your TCs in 
>> OASIS at: 
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php





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