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 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
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]