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


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


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