Re: [sca-policy] Discussion re Issue 79

[David Booz <booz@us.ibm.com>]

The point of external attachment is a separation of lifecycles, not separation of policy from SCDL. It separates the lifecycle of policy configuration from the lifecycle of the SCDL itself. With direct attachment, a change in policy config (which might require attachment of a new policySet) would require the SCDL to be updated. That is undesirable because it usually leads to the need to involve a developer or assembler. We decided that it should be possible to change policy without affecting the lifecycle of the application, and thus external attachment was born. As far as I can recall, external attachment never intended to change the semantics of policySets to satisfy intents. I looked at the original proposal documents and they confirm my memory.

WRT POL40018, it says:

All intents in the required intent set for an element MUST be provided by the directly provided intents set and the set of policySets that apply to the element.

The directly provided intent set is defined as:

"1432 The directly provided intent set for an element is the set of intents listed in the
1433 @alwaysProvides attribute combined with the set of intents listed in the @mayProvides
1434 attribute of the bindingType or implementationType declaration for a binding or
1435 implementation element respectively."

Line numbers are from CD02-rev3.

POL40018 does talk about intents being satisfied by bindings.

Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com

ashok malhotra <ashok.malhotra@oracle.com> wrote on 08/19/2009 04:50:27 PM:

> [image removed]
>
> Re: [sca-policy] Discussion re Issue 79
>
> ashok malhotra
>
> to:
>
> OASIS Policy
>
> 08/19/2009 04:51 PM
>
> Please respond to ashok.malhotra
>
> Mike:
> When we added External Attachment to the spec the idea was to separate
> Policy from SCDL.
> This is a worthy goal and we agreed to allow policySets to be attached
> externally to the SCDL.
> There was no mention of intents.  The Externally attached policySets
> would be processed late
> in the cycle, perhaps just before deployment although this was not spelt
> out.
>
> Then we realized we needed intents to allow them to be used in the XPath
> functions written as the
> value of the @attachTo (I'm not convinced this is a great usecase but,
> whatever).  More importantly
> we need to be able to attach what I call configuration intents such as
> JMS which would guide the
> selection of bindings.
>
> There is not, and never has been any notion of satisfying intents in the
> External Attachment scenario and
> I am resistant to it.
>
> Re. the para you quote from 4.12.1 I'm a bit mystified because I don't
> remember how or when it got into the
> spec.  I say this because it seems to directly contradict 40018 just
> above.  We need to discuss.  40018 should
> also say something about intents being satisfied by bindings.
>
> All the best, Ashok
>
>
> Mike Edwards wrote:
> >
> > Ashok,
> >
> > I disagree with your proposed rewording of POL40018.
> >
> > "the set of policySets that apply to the element" include both
> > directly attached policySets and also externally attached policySets.
> > Your rewording attempts to remove the latter policySets, which is not
> > at all helpful.  Intents can be just as useful when attaching
> > policySets externally.
> >
> > I would be happy to add words to make it clear that the policySets can
> > be attached by any means.
> >
> >
> > Now to deal with your point "All intents need not be satisfied".
> >
> > In general, I think this is bad practice.  The whole point of intents
> > is that they mark a requirement that the code/assembly has on
> > some policy feature.  In principle, it is possible that the code will
> > fail to work correctly unless the intent is honoured.  So to simply
> > ignore intents is not a good idea.
> >
> > Section 4.12.1 says:
> >
> > "If the combination of implementationType / bindingType / collection
> > of policySets does not satisfy all of the intents which apply
> > to the element, the configuration is not valid. When the configuration
> > is not valid, it means that the intents are not being correctly
> > satisfied. However, an SCA Runtime can allow a deployer to force
> > deployment even in the presence of such errors. The
> > behaviors and options enforced by a deployer are not specified."
> >
> > - this makes it clear that a configuration with unsatisfied intents is
> > not valid - but that deployment */CAN BE FORCED/* in the presence
> > of errors.  This isn't normative, but perhaps it should be, to make it
> > clearer that this really is an error situation.  I note that there is
> > no requirement here for the runtime to report an error - there should
> > be such a requirement.
> >
> >
> > Yours,  Mike.
> >
> > Strategist - Emerging Technologies, SCA & SDO.
> > Co Chair OASIS SCA Assembly TC.
> > IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
> > Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
> > Email:  mike_edwards@uk.ibm.com
> >
> >
> > From:    ashok malhotra <ashok.malhotra@oracle.com>
> > To:    OASIS Policy <sca-policy@lists.oasis-open.org>
> > Date:    17/08/2009 19:28
> > Subject:    [sca-policy] Discussion re Issue 79
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> >
> > The current spec says
> > All intents in the required intent set for an element MUST be provided
> > by the directly provided intents set and the set of policySets that
> > apply to the element./ /[POL40018 <#POL40018>]
> >
> > First, I think this should read
> > All intents in the required intent set for an element MUST be provided
> > by the directly provided policySets that apply to the element./
> > /[POL40018 <#POL40018>]
> >
> > Second, this addresses  only the direct attachment case.  I think we
> > need some words for the External
> > Attachment case.  For this case, I think we need to say:
> > a. Intents MUST be recognized by a runtime that supports External
> > Attachment.
> > b. The presence of intents can be used in XPath functions that make up
> > the value of the @attachTo
> > attribute for Externally Attached policySets.
> > c. Intents may be satisfied by bindings or policySets.
> > d. All intents need not be satisfied.
> > --
> > All the best, Ashok
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > /
> > /
> >
> > /Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with
> > number 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> > 3AU/
> >
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>