IMO they are both there for validation reasons, and if the validation
fails, then the last sentence of 14.4 pervails:
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
|