Sorry this is a long post but seems like a good idea to write this
down as I go along.
I'm looking at policy in relation to the policy matching requirement
of ASM_6015/6016. Before getting to that however we need to do all of
the required policy processing. Looking at the code there is an
incomplete builder (CompositePolicyBuilderImpl) which I believe looks
at the static model and configures endpoints with suitable policy
information based on what it finds. It does this without updates to
the static assembly model. I'm wondering if this approach is going to
be clear and understandable given the rules defined by the SCA policy
spec. I can't answer that question immediately so as an aid to help me
understand what we need to do here is my initial understanding of how
I think the rules work generally.
Here "implementatation hierarchy" refers to the component/component
type/component/component type hierarchy. We use the term promotion in
the context of the implementation hierarchy. The term "structural
hierarchy" refers to the composite/component/reference/binding
hierarchy. Generally policy artifacts flow up the implementation
hierarchy and down the structural hierarchy.
For intents
========
Implementation hierarchy
858 - Rule1 [POL40014] - The intents declared on elements lower in the
implementation hierarchy of a given element MUST be applied to the
element.
This means
A) component service/binding, reference/binding,
implementation adopt the intents from their component type equivalents
B) composite service/binding, reference/binding,
implementation adopt the intents from their equivalents in the
components that they promote
859 - Rule1 [POL40004] - A qualifiable intent expressed lower in the
hierarchy can be qualified further up the hierarchy, in which case the
qualified version of the intent MUST apply to thehigher level element.
This means
C) if a qualified intent is already applied to the higher
level element it remains there and the unqualified intent is not
aggregated
845 - [POL40009] - Any two intents applied to a given element MUST NOT
be mutually exclusive
This means
D) when intents are aggregated and are found to be mutually
exclusive an error occurs
842 - the @constrains attribute of each relevant intent is checked
against the element. If the intent in question does not apply to that
element it is simply discarded.
This means
E) any intent in an element's requires list that does not
constrain that element is ignored
1025 - [POL40016] - When calculating the set of intents and set of
policySets which apply to either a service element or to a reference
element of a component, intents and policySets from the interface
definition and from the interface declaration(s) MUST be applied to
the service or reference element and to the binding element(s)
belonging to that element.
This means
F) for components collect intents and policy set from the
<interface.type/> elements and from the interface referenced by this
element
G) for component types collect intents and policy sets from
the implementation artifact, e.g. java interface or child components,
and from any <interface/> elements and referenced interfaces in
component type side file.
Structural hierarchy
878 - Rule2 [POL40005] - The intents declared on elements higher in
the structural hierarchy of a given element MUST be applied to the
element EXCEPT:
- if any of the inherited intents is mutually exclusive with an
intent applied on the element, then the inherited intent MUST be
ignored
- if the overall set of intents from the element itself and
from its structural hierarchy contains both an unqualified version and
a qualified version of the same intent, the qualified version of the
intent MUST be used.
This means
H) Intents are pushed down from composite to component to
service/reference/implementation to binding
I) when intents are aggregated and are found to be mutually
exclusive then intents being pushed down are ignored
J) qualified intents are retained in favour of their
unqualified versions
The spec states [POL40015] that the implementation hierarchy
processing (Rule1) must be applied before the structural hierarchy
processing (Rule2). However we can't just sweep through the model
doing all the implementation hierarchy processing followed by the
structural hierarchy processing as I think we need to consider each
implementation level (composite) in turn and apply both rules to that
the total result is suitably promoted.
For Policy Sets
===========
It's not clear to me, from the spec, what the general rules are for
processing policy sets (indirectly and directly attached) in the
implementation and structural hierarchies. However the assembly schema
implies that directly attached policy sets can appear anywhere in the
structural hierarchy and [POL40006] implies that, in some
circumstances at least, the component type must be taken into account.
So I'll assume the processing is the same as for intents minus the
detail about qualification.
1000 - [POL40006] - If a component has any policySets attached to it
(by any means), then any policySets attached to the componentType MUST
be ignored.
This means
K) Slight awkwardly we have to build up the list of policy
sets associated with a component's elements ("by any means" presumably
includies from the structural hierarchy) before checking whether the
policy sets from the component type should be considered. This is the
reverse of the intent rules A) and F) where the implementation
hierarchy is considered before the structural hierarchy
So now I'm going to examine CompositePolicyBuilderImpl in a little
more detail and compare that with what we could do in the
ModelBuilderImpl and see if there is an obvious way through.
Simon
