[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Correlation sets on invoke
Oh by the way, I would take this as a friendly comment to the editor's group and not along the lines of an issue . I guess you guys could piggyback it as part of the text of one of the other issues. Either way, there's not much discussion to be had here so just wanted to point it out . thanks, rania Rania Khalaf wrote: > Hi Alex, > > I was thinking specifically of the case of 'response to an invoke'. In > that case, routing is not intended. In the other cases, it could be > intended though. > > Alex Yiu wrote: > >> >> +1 to the need of the clarification. >> >> Basically, the notion of using correlationSet is the validation >> mechanism for message-correlation was first mentioned in the 96 issue >> related discussion and mainly backed by Satish. We should capture >> that consensus on paper by saying something like: >> >> "correlationSet is used as the validation mechanism for >> message-correlation. It can be used in the message routing mechanism, >> when WS-BPEL engine do not provide or is configured not to provide an >> engine-managed message routing mechansim." >> >> Danny, do you think this is suitable to piggy back the clarification >> to the resolution of Issue 120 and Issue 120.1? >> >> >> Regards, >> Alex Yiu >> >> >> Rania Khalaf wrote: >> >>> Danny van der Rijn wrote: >>> >>>> IMO they are both there for validation reasons, and if the >>>> validation fails, then the last sentence of 14.4 pervails: >>>> >>> Ah that's where that is(correlationViolation) ! I was a bit >>> surprised coz I was reading 10.2 - and that one says 'behavior is >>> undefined' ! Forgot about the spec structure. >>> >>> Yup, I would agree with validation as the only thing that makes >>> sense, so we should probably just state in the spec that they are >>> not used for routing the response to the correct instance because >>> although I've insisted otherwise as the only thing that makes any >>> sense - I got pointed to the spec with that >>> 'show-me-where-it-says-that'-look and came up blank. >>> >>>> If one of initiated correlation set does NOT match with the >>>> message, the standard fault bpws:correlationViolation MUST be >>>> thrown by a compliant implementation. >>>> >>> >>> >>> >>> >>>> >>>> Rania Khalaf wrote: >>>> >>>>> Hi guys, >>>>> >>>>> I was having a discussion with a student today regarding BPEL >>>>> correlation sets, and realized that something is ambiguous about >>>>> them. >>>>> >>>>> For initiate='yes|rendezvous' on an invoke corrset, it's pretty >>>>> clear what the person is doing - but why would anyone want to have >>>>> correlationSet='no' ? >>>>> >>>>> -If I have a correlation set on an invoke, but initiate='no' and >>>>> pattern='out': Looking at the spec, one could say it means that >>>>> one checks that the value of the field is consistent with the >>>>> value of the correlation set and if not nothing happens anyway >>>>> (behavior is undefined acc to author's draft). So I guess, this is >>>>> harmless at worst. >>>>> >>>>> -If I have a correlation set on an invoke, with initiate='no' and >>>>> pattern='in' does that mean that the response to the invocation >>>>> is treated it as if it is coming to a 'receive' and so the >>>>> correlation is used for routing ? If so, that is strange and does >>>>> appear to have been the intention of the authors - especially >>>>> since we have a 'conflicting receive fault' but no >>>>> 'conflictingInvokeResponse' fault. ie: The engine matches >>>>> responses to requests of req/resp operations (many mechanisms >>>>> exist. Who cares which one is used). So, we can tell which >>>>> instance the response is coming to, without using correlation. Now >>>>> again, we could say it's for some business data validation case >>>>> (check that the properties are in fact correct) - but if that >>>>> fails again the behavior is undefined so who cares ? >>>>> >>>>> I was explaining to the student that the latter case is redundant >>>>> and not useful for BPEL. Even the first one is strange to me since >>>>> I don't see why you would ever want to have correlation on invoke >>>>> if you're not either setting it (or using rendezvous or whatever >>>>> that thing is called now - where you could have been setting it). >>>>> I think the spec should either say something to this effect, >>>>> otherwise it is confusing to some people just reading the spec >>>>> whether or not, for example, they need to use correlation on a >>>>> request-response invoke if their engine does not support something >>>>> like WS-Addressing. It is clear that for receive you would need it >>>>> - but for invoke the spec doesn't tell you explicitly that you don't. >>>>> >>>>> Regards, >>>>> Rania >>>>> >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 > > > > > > --------------------------------------------------------------------- > 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]