Issue 96.1 considered harmful

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

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