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?


The issue of what happens to the dropped message was explicitly 
discussed during the BEA hosted SF F2F. The outcome of the discussion 
was an agreement that this was an elephant issue and out of scope of BPEL.

Specific examples that my memory claims were discussed at the F2F include:

  * Is it legal for a message to be copied and simultaneously received 
by two BPEL's or is that illegal in the BPEL model, e.g. is there some 
kind of implicit guarantee of one message/one receiver?

  * What happens to messages that somehow are identified (e.g. using 
WS-Addressing) as belonging to a particular process instance but can't 
be matched against any outstanding receives (even after holding the 
message for a while) and so can't be delivered?

  * What happens to messages that are identified as belonging to a 
process (e.g. by matching a URI that is shared by all process instances) 
but can't be matched to a particular process instance?

  * If a message does show up at a particular instance but can't be 
matched to an existing receive can you specify some kind of error 
message to be returned?

The answer to all of these questions were the same - out of scope.

It is worth pointing out that a discussion is not a vote and without a 
vote there is no normative change to the spec. The purpose of the 
discussion was to illuminate the design decisions that had gone into 
BPEL's message handling decisions by the original authors and I believe 
the group at the time had rough consensus that it agreed with these 
decisions. Nevertheless, nothing is binding without a vote.

Personally I think that keeping the elephant undefined is the only 
productive choice we have available to us given the agendas of the 
members of the group.

	Thanks,

		Yaron

Chris Keller wrote:
> 
> 
> Hi Prasad,
> 
> I believe that a correlationViolation could still be thrown by an invoke or
> reply with an initiate="no".  I have always thought of it as a double-check
> that the data sent or received had the correct properties.  So since 
> section
> 14.4 doesn't restrict itself to receive, onEvent or onMessage (Pick) it
> seems that the fault can still occur.
> 
> But your question about messages being dropped is an interesting one. I
> would think it would be up to the undefined "dispatch" infrastructure to do
> intelligent there (e.g. fault the request).
> 
> Regards,
> Chris
> 
> -----Original Message-----
> From: Prasad Yendluri [mailto:pyendluri@webmethods.com]
> Sent: Tuesday, July 26, 2005 6:25 PM
> To: ygoland@bea.com
> Cc: Danny van der Rijn; Alex Yiu; Dieter Koenig1; wsbpeltc
> Subject: Re: [wsbpel] Issue - 222 - What's the state of a receive after a
> correlationViolation?
> 
> +1
> 
>  I think we should get rid off the clause in 14.4 that calls for
> correlationViolation fault which is impossible I suppose.
> 
> However does the message simply get dropped on the floor or is there a
> way to somehow let the message sender know of the error?
> 
> Regards, Prasad
> 
> Yaron Y. Goland wrote:
> 
>  > I disagree with Alex's characterization of the proposal as a change to
>  > BPEL's existing semantics. I believe that the proposal is completely
>  > consistent with BPEL's semantics which have always been based on the
>  > idea that you receive a message based on the correlation set values
>  > you specify. If a message comes in that has values that don't match
>  > the correlation set then it isn't delivered.
>  >
>  > In fact, my memory vaguely claims that we discussed this previously
>  > under the topic of what to do with messages that arrived and were
>  > correlated but didn't match the underlying WSDL. The answer was - the
>  > message isn't delivered.
>  >
>  > So I believe the only error here is that there is a confusing
>  > statement in the current definition of the correlationViolation fault
>  > that would lead an implementer to erroneously believe they are allowed
>  > to deliver a message that doesn't match the associated correlation
>  > sets. We should fix that problem.
>  >
>  >         Yaron
>  >
>  > Danny van der Rijn wrote:
>  >
>  >>
>  >>
>  >> If there's only one correlationSet, then mis-"addressed" messages won't
>  >> get delivered, and the process will get stuck.  There really isn't any
>  >> difference to me if there are multiple correlationSets.  If the message
>  >> doesn't match, then don't deliver it.
>  >>
>  >> The current spec doesn't *require* the elephant to deliver the message,
>  >> and then fault the receive, it only says that it's possible.  A loosely
>  >> worded *MAY*.  I think that leads to a lot of confusion, not to mention
>  >> portability problems.
>  >>
>  >> Danny
>  >>
>  >> Alex Yiu wrote:
>  >>
>  >>  >
>  >>  > Hi,
>  >>  >
>  >>  > I understand what Yaron suggested here ... However, it clearly
>  >> differs
>  >>  > from the BPEL 1.1  spec and existing BPEL 2.0 spec. Having this
>  >>  > less-than-trivial semantics change in this stage of spec would 
> not be
>  >>  > good idea.
>  >>  >
>  >>  > Given a multiple correlation set situation and one of them having
>  >> this
>  >>  > consistency constraint violation problem, it is easier for users to
>  >>  > debug the problem, if the <receive> got faulted compared with the
>  >>  > message got struck and not delivered / routed to the process
>  >> instance.
>  >>  >
>  >>  > Think of a situation where a process instance always got struck in
>  >> the
>  >>  > "in-progress" state and never got completed/faulted. It keeps 
> waiting
>  >>  > for a message which it cannot receive due to this consistency
>  >>  > violation problem.
>  >>  >
>  >>  > And, if my reading is correct, Satish would have a relatively strong
>  >>  > opinion on this also. (Of course, he is on sabbatical ... it 
> would be
>  >>  > difficult for me to confirm.)
>  >>  >
>  >>  > Thanks!
>  >>  >
>  >>  >
>  >>  > Regards,
>  >>  > Alex Yiu
>  >>  >
>  >>  >
>  >>  > Yaron Y. Goland wrote:
>  >>  >
>  >>  >> I think Danny is right.
>  >>  >>
>  >>  >> The core of the problem is that we shouldn't allow a message to
>  >>  >> arrive if it doesn't match the specified correlation sets. We 
> should
>  >>  >> specify that it is impossible for a message to be received without
>  >>  >> proper correlation sets and we should further specify that the
>  >>  >> correlationViolation fault can only occur on a receive/pick in the
>  >>  >> case that an un-initialized correlation set is used with
>  >>  >> 'initiate='no'' or an initialized correlation set is used with
>  >>  >> 'initiate='yes''.
>  >>  >>
>  >>  >>     Yaron
>  >>  >>
>  >>  >> Danny van der Rijn wrote:
>  >>  >>
>  >>  >>>   I would agree with you on principle, but I believe that the spec
>  >>  >>> disagrees with us:
>  >>  >>>
>  >>  >>> from 14.4:
>  >>  >>>
>  >>  >>>           o 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>
>  >>  >>>> <mailto:peter.furniss@chTooreology.com>             >>>>
>  >> wsbpel@lists.oasis-open.org
>  >>  >>>> <mailto: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
>  >>  >>>> <mailto: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
>  >>  >>
>  >>  >>
>  >>  >>
>  >>  >>
>  >>  >>
>  >> ---------------------------------------------------------------------
>  >>  >> 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]