You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2008/08/14 16:14:15 UTC
[DISCUSS] Areas for policy improvement
A couple more JIRA have come up recently related to improving policy
support. Are there any more big ticket items that people are aware of? Would
be good to get the ones people know of on the table in case of overlaps
rationalizing policy extension model - TUSCANY-2541
We have two extension models a.t.m
definitions.xml processing - TUSCANY-2499
Contribution definitions.xml only processed in the context of the
contribution in a node
Related to the previous one - the domain needs to be able to configure nodes
more precisely w.r.t appropriate intents/policy sets - no JIRA
A.t.m the node just gets what is in the contributions that are part of
the import/export hierarchy
"applies to" processing - no JIRA
"Applies to" are only processed right at the start of composite
processing. I have a feeling that this causes problems with at least nested
composites. Don't have proof of this one though. It just doesn't feel like
there might be problems lurking.
Simon
Re: [DISCUSS] Areas for policy improvement
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> I didn't get anyone to bite with this post but I've been updating the
> models on the wiki page [1] over the last few days. I hassled Sebastien
> off line and got feeback on the idealized model so that's so that's
> starting to look a little cleaner.
...
More comments on the policy model diagram on [1]. I'm now happier with
the blue part of the diagram, but I think that the yellow part is still
too tied to the XML representation of the logical model.
Here's a first cut of what I envisioned:
Yellow classes:
- PolicyConfiguration, a set of policy configuration info
- PolicySet, a top level PolicyConfiguration (like line 339 of the spec)
- QualifiedPolicyConfiguration, an inner PolicyConfiguration (like line
346 of the spec)
- Policy, a policy declaration
- WSPPolicy and WSPPolicyAttachment represent WSP policy declarations
Relationships:
- PolicySet extends PolicyConfiguration
- QualifiedPolicyConfiguration extends PolicyConfiguration
- PolicyConfiguration extends IntentProvider
(as it provides Intents)
- PolicyConfiguration contains 0..n QualifiedPolicyConfigurations
(analog to Intent contains 0..n QualifiedIntents)
- PolicyConfiguration references 0..1 default
QualifiedPolicyConfiguration (which indicates how to qualify a
non-qualified intent requirement)
- WSPPolicy, WSPPolicyAttachement and PolicySet extend Policy
- PolicyConfiguration references 0..n (included) Policy (declarations or
capabilities)
So, basically we don't try to model the XML noise (IntentMaps and
Qualifiers), we model the core classes and their logical relationships.
The green part of the diagram and the 'policy and assembly' model need
work too but I suggest to look at them later once we're happy with the
yellow part of the diagram, as it's simpler to take things one at a time.
> [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Policy
--
Jean-Sebastien
Re: [DISCUSS] Areas for policy improvement
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Aug 22, 2008 at 11:34 PM, Simon Laws <si...@googlemail.com>wrote:
>
>
> On Tue, Aug 19, 2008 at 7:27 AM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
>
>> Simon Laws wrote:
>>
>>> A couple more JIRA have come up recently related to improving policy
>>> support. Are there any more big ticket items that people are aware of? Would
>>> be good to get the ones people know of on the table in case of overlaps
>>>
>>> rationalizing policy extension model - TUSCANY-2541
>>> We have two extension models a.t.m
>>>
>>> definitions.xml processing - TUSCANY-2499
>>> Contribution definitions.xml only processed in the context of the
>>> contribution in a node
>>>
>>> Related to the previous one - the domain needs to be able to configure
>>> nodes more precisely w.r.t appropriate intents/policy sets - no JIRA
>>> A.t.m the node just gets what is in the contributions that are part of
>>> the import/export hierarchy
>>>
>>> "applies to" processing - no JIRA
>>> "Applies to" are only processed right at the start of composite
>>> processing. I have a feeling that this causes problems with at least nested
>>> composites. Don't have proof of this one though. It just doesn't feel like
>>> there might be problems lurking.
>>>
>>> Simon
>>>
>>>
>> I think it'll help to start with a systematic cleanup of the Policy model
>> interfaces as they're really the base for all the Policy work.
>>
>> More info in http://issues.apache.org/jira/browse/TUSCANY-2553.
>> --
>> Jean-Sebastien
>>
>
> In between other things I've started getting back into policy, with a view
> to fixing some of these issues, by recording some thoughts here [1]. Any
> thoughts or hidden gems of info gratefully received.
>
> Simon
>
> [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Policy
>
I didn't get anyone to bite with this post but I've been updating the models
on the wiki page [1] over the last few days. I hassled Sebastien off line
and got feeback on the idealized model so that's so that's starting to look
a little cleaner. By way of variety I've started looking at the runtime end
of things (see separate post) and my plan is to fix up some of the issues
there while people think about the policy model itself.
Any thoughts most welcome.
Simon
[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Policy
Re: [DISCUSS] Areas for policy improvement
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Aug 19, 2008 at 7:27 AM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> Simon Laws wrote:
>
>> A couple more JIRA have come up recently related to improving policy
>> support. Are there any more big ticket items that people are aware of? Would
>> be good to get the ones people know of on the table in case of overlaps
>>
>> rationalizing policy extension model - TUSCANY-2541
>> We have two extension models a.t.m
>>
>> definitions.xml processing - TUSCANY-2499
>> Contribution definitions.xml only processed in the context of the
>> contribution in a node
>>
>> Related to the previous one - the domain needs to be able to configure
>> nodes more precisely w.r.t appropriate intents/policy sets - no JIRA
>> A.t.m the node just gets what is in the contributions that are part of
>> the import/export hierarchy
>>
>> "applies to" processing - no JIRA
>> "Applies to" are only processed right at the start of composite
>> processing. I have a feeling that this causes problems with at least nested
>> composites. Don't have proof of this one though. It just doesn't feel like
>> there might be problems lurking.
>>
>> Simon
>>
>>
> I think it'll help to start with a systematic cleanup of the Policy model
> interfaces as they're really the base for all the Policy work.
>
> More info in http://issues.apache.org/jira/browse/TUSCANY-2553.
> --
> Jean-Sebastien
>
In between other things I've started getting back into policy, with a view
to fixing some of these issues, by recording some thoughts here [1]. Any
thoughts or hidden gems of info gratefully received.
Simon
[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Policy
Re: [DISCUSS] Areas for policy improvement
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> A couple more JIRA have come up recently related to improving policy
> support. Are there any more big ticket items that people are aware of?
> Would be good to get the ones people know of on the table in case of
> overlaps
>
> rationalizing policy extension model - TUSCANY-2541
> We have two extension models a.t.m
>
> definitions.xml processing - TUSCANY-2499
> Contribution definitions.xml only processed in the context of the
> contribution in a node
>
> Related to the previous one - the domain needs to be able to configure
> nodes more precisely w.r.t appropriate intents/policy sets - no JIRA
> A.t.m the node just gets what is in the contributions that are part
> of the import/export hierarchy
>
> "applies to" processing - no JIRA
> "Applies to" are only processed right at the start of composite
> processing. I have a feeling that this causes problems with at least
> nested composites. Don't have proof of this one though. It just doesn't
> feel like there might be problems lurking.
>
> Simon
>
I think it'll help to start with a systematic cleanup of the Policy
model interfaces as they're really the base for all the Policy work.
More info in http://issues.apache.org/jira/browse/TUSCANY-2553.
--
Jean-Sebastien