RE: Issue 96.1 considered extremely useful

["Satish Thatte" <satisht@microsoft.com>]

I want to reiterate my opposition to adopting 96.1 because it is either
a very special case of a feature (opaque correlation) that we have
already decided against adding, or it is an authorization feature that
is out of scope.  See below for more detailed explanations.

Satish

-----Original Message-----
From: Satish Thatte 
Sent: Monday, April 18, 2005 3:00 PM
To: ygoland@bea.com
Cc: wsbpel@lists.oasis-open.org
Subject: RE: Issue 96.1 considered extremely useful

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
>