Re: [wsbpel] Correlation sets on invoke

[Alex Yiu <alex.yiu@oracle.com>]

+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