[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]