[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 agree with Alex that for the purposes of the first vote on 222 the only issue is - is there an issue? But in response to Alex's specific point about how, if we decide there is an issue, that issue may be resolved. I would disagree with the characterization that only a single correlation is necessary. Business level message correlation often involves multi-part correlation identifiers. E.g. you might identify a message as belonging to your process based on a combination of a customer ID and a purchase ID that is only guaranteed to be unique when combined with that customer ID. So I don't believe it is safe to assume that multiple correlation IDs are only be used for validation purposes on incoming messages. Obviously however the only purpose of correlation IDs on outgoing messages is validation. Yaron Alex Yiu wrote: > > > 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]