Re: Issue 96.1 considered extremely useful

["Yaron Y. Goland" <ygoland@bea.com>]

Satish and I have agreed that further discussion of 96.1 needs to await 
the resolution to issue 96.
	Yaron

Satish Thatte wrote:
> Yaron, I am talking about how you interpret the non-delivery of the
> message. 
> 
> If a message is NOT correlated it never shows up at your doorstep.  If a
> message IS correlated then you need another reason to reject it.  Thus
> 96.1 must be interpreted as a correlation extension, in which case
> non-delivery  is in the first camp, or authorization, in which case it
> is in the second.  I see no escape from this conclusion.
> 
> -----Original Message-----
> From: Yaron Y. Goland [mailto:ygoland@bea.com]
> Sent: Monday, April 18, 2005 12:05 PM
> To: Satish Thatte
> Cc: wsbpel@lists.oasis-open.org
> Subject: Re: Issue 96.1 considered extremely useful
> 
> Applying this to 96 doesn't work because 96 is morphing into an
> extension of message exchange and not into a generic opaque correlation
> mechanism.
> 
> Also, the 'what happens to the message' argument applies as much to all
> existing BPEL messaging so 96.1 doesn't cause anything new. For example,
> 
>   what happens if a message is sent in using WS-Addressing which
> identifies what port and operation the message is using. However it
> turns out that the message is actually syntactically illegal and so is
> rejected before it ever gets to the process instance? Where did the
> rejected message go? In other words, 96.1 introduces nothing new.
> 
>                 Yaron
> 
> 
> 
> Satish Thatte wrote:
>  > Forgive the allusion in the subject line to a famous ancient
>  > communication from Dijkstra.  This is the e-mail I had promised Yaron
> I
>  > would send.
>  >
>  > The proposal associated with issue 96.1 is to add a switch (presumably
>  > to the partnerLink) which allows "filtering" of inbound messages by
>  > admitting only those messages that are from the same "source" as the
>  > endpoint associated with the partnerRole in that partnerLink.  The
>  > proposal does not state what happens to messages that would otherwise
> be
>  > received but for this restriction, i.e., those which correlate to the
>  > instance and are of the right message type.
>  >
>  > There are two ways to interpret this proposal.
>  >
>  > One is to think of this as an additional correlation feature in
> addition
>  > to the opaque correlation that we are discussing in issue 96.  In
> other
>  > words, the switch may state that the EPR in the partnerRole is part of
>  > the opaque correlation.  This seems very much like a special case of
> 96
>  > and I see no reason to elevate this special case to a BPEL feature,
>  > especially because I don't see the use case where the filtering would
> in
>  > fact be needed, i.e., why one would receive messages that would be
>  > rejected because of this switch.
>  >
>  > Which brings me back to "what happens to messages that would otherwise
>  > be received but for this restriction", which suggests the second, and
> to
>  > me more credible, interpretation.  The interpretation is that the
>  > rejected messages are either in error or an intrusion.  In other
> words,
>  > this is not so much a filter as a guard that only allows messages
> *from
>  > the right party* into the process instance.  Which sounds to me very
>  > much like an authorization feature rather than a correlation feature.
>  > And this would then be definitely out of bounds for BPEL.
>  >
>  > Given this analysis I conclude that the proposal represented by 96.1
> is
>  > either a very special case of 96 for which we do not need a BPEL
> feature
>  > (not least because the use case is unclear), or it is an authorization
>  > (guard) feature that is out of scope.  I therefore propose that the
>  > issue be closed with no change.
>  >
>  > Satish
>  >
>