[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?
If there's only one correlationSet, then mis-"addressed" messages won't get delivered, and the process will get stuck. There really isn't any difference to me if there are multiple correlationSets. If the message doesn't match, then don't deliver it. The current spec doesn't *require* the elephant to deliver the message, and then fault the receive, it only says that it's possible. A loosely worded *MAY*. I think that leads to a lot of confusion, not to mention portability problems. Danny Alex Yiu wrote: > > 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]