Re: Revised positions for closed/open world assumptions

Regarding the first point: Could clarify that one alternative is chosen, 
perhaps by reference back to the quoted text.

Regarding the second point: I take it that by Initiator you mean 
"initator of a behaviour ". Is this an endpoint which
first places a soap header starting a ws* interaction?

I was taking the word as the initator of the intersection, which I could 
not understand.

Can both contributors to a policy intersection be initators (perhaps of 
different behaviour types?)

Tom
Christopher B Ferris wrote:
>
> Tom,
>
> Please see my responses below.
>
> Cheers,
>
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
> phone: +1 508 377 9295
>
> Tom Rutt <tom@coastin.com> wrote on 05/21/2007 02:01:01 PM:
>
> >
> > Chris,
> > More clarification is needed to understand two important aspects of the
> > latest IBM proposal:
> >
> > 1. Use of only one policy alternative (not a mixture of several, 
> just one)
> > 2. The meaning of 'initiating entity'
> >
> > I would like us to investigate these two questions briefly in hopes of
> > bringing together
> > ideas that will lead to consensus. Note, that the word ENTITY is used
> > until an
> > appropriate term is identified by the WG.
> >
> > 1. Use of only one policy alternative (not a mixture of several, just
> > one) in explicit text.
> > Could we add something like th following to your existing text?:
> > * [add] AN ENTITY can engage the behaviors of a compatible policy
> > alternative
> > when the policy alternative is part of the intersection result. 
> Although
> > more than
> > one policy alternative may exist in an intersection result, only one 
> policy
> > alternative of all the expected behaviors is engaged.
>
> Well, clearly, I think that this is a given. Quoting from section 3.4 [1]
>
> "A requester MAY choose any alternative since each is a valid 
> configuration for interaction with the service,
> but a requester MUST choose only a single alternative for an 
> interaction with a service since each represents
> an alternative configuration. "
>
> [1] http://www.w3.org/TR/2007/CR-ws-policy-20070330/#Web_services
>
> > * [add] If an ENTITY includes a policy assertion type A in its policy,
> > and this
> > policy assertion type A does not occur in an intersected policy, then
> > that ENTITY
> > does not apply the behavior implied by assertion type A.
>
> You have changed things a bit by using the word ENTITY. In the IBM
> proposal, this is limited to the entity that engages/initiates an
> interchange based on policy framework/attachments processing. We cannot
> really say anything about other entity(s) within the system since
> they are not influenced by policy framework processing.
>
> > 2. The meaning of 'initiating entity':
> > * This term is ambiguous - what is the scope of this entity -
> > the policy intersection or the web service initiator? What
> > about intermediaries? The term needs to be unambiguous to
> > identify the ENTITY that engages the service. This is
> > somewhat challenging because the ENTITY that engages the
> > service may or may not know what that policy assertion type
> > A was in the policy of the policy requester/consumer/etc.
>
> What needs to be clearly understood is that Web services interactions
> are about more than synchronous request/response.
>
> In the asynchronous case, the entity known in other contexts as the
> "provider" may in fact use some means of determining the policy of the
> [response endpoint] before engaging in an interaction with that
> [response endpoint].
>
> The entity sometimes referred to as "client" or "web services consumer"
> will typically, either at runtime or deploy-time, determine the policy
> of the web services provider to determine a) whether its policy and that
> of the provider are compatible, and will select an alternative with
> which to engage an interaction with that endpoint.
>
> >
> > For example, there probably will be scenarios where two entities put
> > forth policy
> > expressions for intersection, and each is then only made aware of the
> > policy
> > intersection result. Each ENTITY may or may not have knowledge of the
> > policy
> > expression the other ENTITY put forth for the intersection.
>
> In our proposal, the initiating entity merely needs to know its own
> policy and the compatible alternative with which it will engage an
> interaction.
>
> >
> > Tom Rutt
> >
> > Christopher B Ferris wrote:
> > >
> > > Ashok,
> > >
> > > Maybe "initiating entity" is unclear. Basically, I intend it to be 
> the
> > > entity that engages an interaction
> > > by retrieving the other side's policy and intersecting it.
> > >
> > > If we expand this with a request/response MEP
> > >
> > > Requestor = R
> > > Provider = P
> > >
> > > If A is in R's policy, but not in P's policy R does not engage that
> > > behavior.
> > > If A is in P's policy, but not in R's policy, P does not engage that
> > > behavior
> > > If P does not use A's policy to engage the interaction, then
> > > everything is out of scope.
> > > One would presume that P would deal with the behaviors represented 
> in the
> > > messages received from R in a manner consistent with their 
> specification.
> > >
> > > I recognize that the intersection algorithm is direction independent.
> > > The proposed
> > > language does not affect intersection, it just places constraints on
> > > the entity that
> > > uses the intersected policy to engage an interaction, limiting the 
> set
> > > of behaviors
> > > applied to those that are implied by assertions IN the intersected
> > > policy and (possibly, but we
> > > don't say anything about them since they are out of scope) those 
> which
> > > are NOT IN
> > > the initiating entity's policy.
> > >
> > > Those behaviors that are IN the initiating entity's policy but NOT IN
> > > the intersected policy
> > > are RIGHT OUT:-)
> > >
> > > Make sense?
> > >
> > > Cheers,
> > >
> > > Christopher Ferris
> > > STSM, Software Group Standards Strategy
> > > email: chrisfer@us.ibm.com
> > > blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
> > > phone: +1 508 377 9295
> > >
> > > "Ashok Malhotra" <ashok.malhotra@oracle.com> wrote on 05/17/2007
> > > 07:06:31 PM:
> > >
> > > > Chris:
> > > > In your latest note in this thread you proposed
> > > >
> > > > Proposed text added to section 4.5:
> > > >
> > > > If an initiating entity includes a policy assertion type A in
> > > > its policy, and this policy assertion type A
> > > > does not occur in an intersected policy, then the initiating
> > > > entity does not apply the behavior implied by
> > > > assertion type A.
> > > >
> > > > I have two concerns about this proposal:
> > > >
> > > > 1. It does not say anything about the policy of the responder. Is
> > > > the behavior different in the other direction? I think not.
> > > > 2. The policy intersection algorithm is direction independent. This
> > > > proposal introduces direction dependency and I’m wary of that. If
> > > > we go that way then I would like to bring up the complex of ideas
> > > > that say that the initiator expresses constraints – what you must
> > > > do, and the responder expresses capabilities – what I can do and
> > > > intersection works differently if viewed from the two directions.
> > > > If we go that route then this leads naturally into the wildcard
> > > > matching that DaveO and I have been proposing.
> > > >
> > > > All the best, Ashok
> >
> > --
> > ----------------------------------------------------
> > Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com
> > Tel: +1 732 801 5744 Fax: +1 732 774 5133
> >
> >

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Monday, 21 May 2007 21:50:09 UTC