OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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?



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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]