Re: Revised positions for closed/open world assumptions

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