OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-policy message

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


Subject: Re: [sca-policy] Discussion re Issue 79



Ashok,

I am truly surprised by some of your comments here.

You seem opposed to the concept of intents.  The whole idea of intents is to mark requirements
that individual components or composites might have.  As such, intents are truly part of the
composition - and mark out where specific policies need to be applied when the materials
are deployed.

To envisage that the External Attachment of policy would *never* have anything to do with intents
is to undermine the whole idea of intents.  Perhaps this is your aim, but I am sure that the SCA model
would be the poorer for it.

In practice, I believe that intents in the SCDL will make it easier to use external attachment of Policy.
Without intents marking out specific requirements, which can then be utilized in the attachment
expressions, the writing of attachment expressions will get very complex.


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: 19/08/2009 21:51
Subject: Re: [sca-policy] Discussion re Issue 79





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









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








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