[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, Well .... the issue is in the "received" stage only. Regardless which direction we pick: "dispatch the message and fault process instance" or "not dispatching the message at all", I guess all of us would agree that the spec underspecifies what should happen when multiple CS are used (one matched; one mismatched). So, I guess we should officially open the bug first. :-) ... Regarding to which direction we should pick, this is a typical choice between different QoS styles. I think we should ask ourselves what are the common usecase scenario where multiple CS are used and then decide which service style matches users the most. I tend to interprete the usage of multiple CS and post an open question as follows: Clearly, the extra CS are not for message dispatching. One CS (engine-managed CS or vanilla CS) would be good enough. More likely, those extra CS are extra message verification logic, which the business process needs. When there is a mismatch in the extra CS, who should be notified? the process instance itself? the process caller (via a mechanism not defined in this spec)? Thanks! Regards, Alex Yiu Yaron Y. Goland wrote: > I disagree with Alex's characterization of the proposal as a change to > BPEL's existing semantics. I believe that the proposal is completely > consistent with BPEL's semantics which have always been based on the > idea that you receive a message based on the correlation set values > you specify. If a message comes in that has values that don't match > the correlation set then it isn't delivered. > > In fact, my memory vaguely claims that we discussed this previously > under the topic of what to do with messages that arrived and were > correlated but didn't match the underlying WSDL. The answer was - the > message isn't delivered. > > So I believe the only error here is that there is a confusing > statement in the current definition of the correlationViolation fault > that would lead an implementer to erroneously believe they are allowed > to deliver a message that doesn't match the associated correlation > sets. We should fix that problem. > > Yaron > > Danny van der Rijn wrote: > >> >> >> 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 >> > >> > >> > >> > >> > >> > > > --------------------------------------------------------------------- > 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]