RE: [wsbpel] Issue 96.1 - Proposal For Vote

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

I am not saying that this isn't useful.  But I don't even know if the
right way to think about this is an authorization check or simple
filter.  The difference being that in the former case a message that
gets filtered out needs to be investigated as an intrusion.  In other
words, I have two separate problems with this proposal

1.  when you get to this level of sophistication in thinking about
engine managed behavior, there is almost always a lot more complexity
than meets the eye, and providing something in BPEL as a partial
solution can be misleading at best and an albatross for the real
solution at worst.

2.  it seems very risky to me (in the Pandora's box sense) to add
"engine managed" features that someone thinks are useful without a
compelling reason such as supporting protocol-level sessions for which
companion standards are in progress. This is why I am not objecting to
engine manage opaque correlation in principle if we can get the details
sorted out and come up with something simple and compelling.  I don't
see this specific engine managed feature as falling into the same
category.

Hope that helps.

Satish

-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com] 
Sent: Wednesday, March 30, 2005 11:34 AM
To: Satish Thatte
Cc: wsbpeltc
Subject: Re: [wsbpel] Issue 96.1 - Proposal For Vote

I'm sorry but this seems a little strange to me. The ability in BPEL to 
say "I would like to receive a message from X" is something people 
should be forced to use proprietary extensions for?

On what basis do you think this feature is so rare and unusual that BPEL

should fail to provide a portable solution for it?

	Thanks,

		Yaron

Satish Thatte wrote:
> I believe this idea belongs in a private extension not in the core
BPEL
> spec.  There are probably many such interesting and useful ideas that
> will come up over time but I just can't see something like this being
> core to the spec at this point.
> 
> Satish
> 
> -----Original Message-----
> From: Yaron Y. Goland [mailto:ygoland@bea.com]
> Sent: Tuesday, March 15, 2005 1:26 PM
> To: wsbpeltc
> Subject: [wsbpel] Issue 96.1 - Proposal For Vote
> 
> Issue 96.1 - filterOnPartnerRole
> 
> Proposal: Add for use on receive/pick/onEvent the
'filterOnPartnerRole'
> attribute. This specifies that any message accepted by the
> receive/pick/onEvent activity must be sent from the partner identified
> by the EPR in the partnerRole. This proposal assumes that issue 194 is
> accepted and resolved by introducing a new uninitializedPartner fault.
> This proposal also introduces a canNotFilterOnPartnerRole fault for
EPRs
> 
> that are only useful in sending but not receiving.
> 
> Rationale: One of the most common BPEL scenarios out there is that
> someone receives a message from a partner and then later on wants to
> receive another message but only from that specific partner. The issue
> 139 proposal defines that the default behavior for BPEL will be that
the
> 
> partnerRole value is ignored by default on receive/pick/onEvent. This
> attribute would allow that default behavior to be overridden and for
the
> 
> partnerRole EPR to be used as a filter on incoming messages.
> 
> Section 11.4
> 
> From: Note that the value of the partnerRole on the partner link is
not
> used when processing a receive activity, that is, there is no
filtering
> of incoming messages based on the partnerRole's value.
> 
> To: The value of the filterOnPartnerRole attribute determines what
role,
> 
> if any, the value of the partnerRole EPR plays in a receive. If
> filterOnPartnerRole="no" then the partnerRole EPR value is ignored in
> determining what messages to receive. If filterOnPartnerRole="yes"
then
> messages accepted by the receive MUST originate from the a partner
whose
> 
> EPR matches the EPR in the partnerRole. BPEL engines MUST statically
> check if the EPR in a partnerRole cannot be used to filter incoming
> messages and reject any BPELs that use filterOnPartnerRole="yes" with
> such unsuitable EPRs. However it is not always possible to statically
> check for this error as partnerRole values can be dynamically
assigned.
> In that case if a partnerRole EPR, at runtime, contains a value that
> cannot be used to filter incoming messages then the
> canNotFilterOnPartnerRole fault MUST be thrown.
> 
> Section 13.5.1.
> 
> From: As with <receive> the  partnerRole EPR is ignored for purposes
of
> determining which messages to receive and may be initialized/updated
as
> a consequence of receiving a message using a binding that is able to
> provide EPR information about the partner.
> 
> To: As with <receive> the partnerRole EPR is only used for filtering
> incoming messages if the filterOnPartnerRole attribute is set to yes.
> Also, the partnerRole value may be initialized/updated as a
consequence
> of receiving a message using a binding that is able to provide EPR
> information about the partner.
> 
> Add to Appendix A:
> 
> canNotFilterOnPartnerRole  - Thrown when a receive/pick/onEvent
> specifies filterOnPartnerRole but the EPR in the partnerRole value
> cannot be used to filter incoming messages.
> 
> Change BNFS in 11.4 and 6.2 to:
> From:
> <receive partnerLink="ncname" portType="qname"? operation="ncname"
>         variable="ncname"? createInstance="yes|no"?
>          messageExchange="ncname"? filterOnPartnerRole="yes|no"?
>         standard-attributes>
>        standard-elements
>        <correlations>?
>         <correlation set="ncname" initiate="yes|no"?/>+
>        </correlations>
> </receive>
> 
> Section 12.4 and 6.2:
> <pick createInstance="yes|no"? standard-attributes>
>        standard-elements
>     <onMessage partnerLink="ncname" portType="qname"?
>         operation="ncname" variable="ncname"?
>          messageExchange="ncname"? filterOnPartnerRole="yes|no">+
>       <correlations>?
>         <correlation set="ncname" initiate="yes|no"?/>+
>       </correlations>
>       activity
>     </onMessage>
>     <onAlarm>*
>           ( <for expressionLanguage="anyURI"?>duration-expr</for> |
>             <until expressionLanguage="anyURI"?>deadline-expr</until>
)?
>             <repeatEvery
> expressionLanguage="anyURI"?>duration-expr</repeatEvery>?
>        activity
>     </onAlarm>
> </pick>
> 
> Section 13.5 and 6.2:
> <eventHandlers>?
>         <!-- there must be at least one onEvent or onAlarm handler -->
>         <onEvent partnerLink="ncname" portType="qname"?
>              operation="ncname"  messageType="qname"
>              variable="ncname"
>               (messageType="qname" | element="qname")?
>               messageExchange="ncname"? filterOnPartnerRole="yes|no">*
>             <correlations>?
>                 <correlation set="ncname" initiate="yes|no"/>+
>             </correlations>
>             activity
>         </onEvent>
>         <onAlarm>*
>           ( <for expressionLanguage="anyURI"?>duration-expr</for> |
>             <until expressionLanguage="anyURI"?>deadline-expr</until>
)?
>             <repeatEvery
> expressionLanguage="anyURI"?>duration-expr</repeatEvery>?
>              activity
>         </onAlarm>
> </eventHandlers>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>