Hi all,
I tend to interprete the situation described by Yaron as follows:
- An inbound message operation is using multiple correlations
situation.
- One of correlations (maybe WS-Addr or not) is used for the actual
message routing.
- The other correlations are used for extra message correlation
validation (I forgot what exact terms Satish used to describe this
concept before).
- If extra message correlation fails, a correlationViolation fault
will be thrown.
To Yaron's questions, I tend to answer:
- Q #1: The message was routed to the process instance.
Otherwise, extra correlation sets will not be used to perform the extra
validation.
But, whether the actual <receive> activity is considered "performed".
E.g.: whether the message related variable is populated / changed
before the correlationViolation fault is thrown? I don't have a strong
position on this. My current gut feeling is the <receive>
activity is considered "not-performed" (from transactional
message semantic viewpoint).
- Q #2:
- If we pick "not-performed" route in the above question, I would
say we cannot perform reply.
- If we pick "performed" route in the above question, I would say
we can perform reply.
- Q #3: I am not sure this Yaron's question. I would say, it is an
event to BPEL in the sense of at least a correlationViolation will be
thrown.
Regards,
Alex Yiu
Danny van der Rijn wrote:
I would agree with you on principle, but I believe that the spec
disagrees with us:
from 14.4:
- 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> 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 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
|