[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 96.1 - Proposal For Vote
Your proposal says: 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. The authorization angle here is different from an ordinary receive. The filter is reasonably INTERPRETED AS an authorization check, thus adding an authorization feature to BPEL. This is maybe not what you had in mind but then you have to explain what the scenario is where anything gets rejected but not as an authorization failure. Satish -----Original Message----- From: Yaron Y. Goland [mailto:ygoland@bea.com] Sent: Thursday, March 31, 2005 1:54 PM To: Satish Thatte Cc: wsbpeltc Subject: Re: [wsbpel] Issue 96.1 - Proposal For Vote The behavior in the proposal takes advantage of a feature provided by WS-Addressing - a standard I think we can agree is 'in progress': the ability to identify source endpoints. For example, two communicating entities can agree that their messages will always contain source endpoint information (e.g. the from header). This then provides the basis for filtering incoming messages based on the partnerRole EPR. The obvious security/authorization issues this raises apply to all RECEIVE/PICK/etc. activities in BPEL so 96.1 is not introducing any new concerns. For example, any time a message is received we must assume some sort of authorization process is in place that could cause a message to be filtered out and treated as an intrusion. This proposal doesn't exacerbate that problem. Can you provide concrete examples of problems this issue raises that don't already exist in the BPEL specification's messaging behavior? Thanks, Yaron Satish Thatte wrote: > 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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]