[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?
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]